Printable View
Phoronix: Mesa Gets Patches For GBM, A Graphics Buffer Manager
Benjamin Franzke, a developer who as of the past several months has been hacking on Wayland and working to get it running over OpenWF along with making other improvements, has written a graphics buffer manager (GBM) for Mesa...
http://www.phoronix.com/vr.php?view=OTU4Nw
openWFD is a miss type both in the article and on the ml right????
(considering d and f are close to the keyboard)
Weren't EGL and DRI two different things?Quote:
This library replaces the previous hard-coded EGL calls to create buffers and instead uses Mesa's internal DRI interface and for the Gallium3D drivers it acts as a state tracker.
EGL for resource sharing DRI for drawing?
Can someone explain in layman's terms what exactly this adds and how it benefits users? I am not trying to say it is useless, the article is just a bit too technical for me to get a clear picture what is going on.
Also could some explain what OpenWF is, in layman terms. Cant find anything that doesn't already assume you know what exactly OpenWF is. :confused:
No typo, OpenWFD means OpenWF Display (for modesetting)Quote:
Originally Posted by 89c51
No real benifit. More of an internal thing.Quote:
Originally Posted by TheBlackCat
Its really just allocating buffers, pulled out of egl.
OpenWF (Display) is a modesetting api standardized by Khronos.Quote:
Originally Posted by Harsh
http://www.khronos.org/openwf/
I am assuming the D is for Display, as opposed to the other option, C for Composition.Quote:
Originally Posted by 89c51
http://www.khronos.org/openwf/
yes it probably is since i don't think the compositor part of openwf is used :DQuote:
Originally Posted by sandain
as for the people that asked about openwf as far as i understand it one part is similar to KMS but cross platform (which is better which has more functionality etc i don't know) and the other part is a compositor
this is what i get from reading around and it might be seriously wrong (you have been warned)
The sentence seemed to be a bit confusing.Quote:
Originally Posted by plonoma
EGL is a application API.
DRI is 'Direct Rendering Infrastructure'. It's part of Linux's graphic acceleration driver stack.
**Hardware** <---> **Linux Kernel DRM driver** <---(DRI Protocol)--> **Usespace Driver** <---(App APIs)-> **Applications.**
The usespace graphics driver uses the DRI protocol to communicate with the Linux kernel. That is why it's called a 'DRI Driver'. The old style drivers are typically called 'Mesa DRI Driver'. The new style is based on Gallium3D and are generally called 'Gallium driver'.
But they are both 'DRI' drivers. The difference is that the old Mesa DRI driver was geared towards just OpenGL. Gallium3D is suppose to support all sorts of different application APIs (2D, OpenGL, OpenCL, etc) through the use of various 'state trackers' and other things. Gallium is much more modern, flexible, and shares a lot more code between drivers then the old style.
I think, but not certain, what they are trying to say is that instead of hard coding the buffer managers directly into the DRI driver, they have developed a version that is based on EGL.. which is a standard API for display management.
http://www.khronos.org/egl/
Ah yes, I remember finding out this existed when it went and broke the Gentoo live ebuild for mesa. Apparently it's automatically enabled if EGL is enabled (which it is by default on Gentoo), but requires the decidedly non-default --enable-shared-glapi in order to actually work.