Gallium3D Gets Xorg, DRI2 State Trackers

[phoronix]

Phoronix: Gallium3D Gets Xorg, DRI2 State Trackers

Gallium3D recently landed in Mesa's mainline code-base and work on it continues to move forward in a steadfast manner. Committed to Mesa's master branch last night for Gallium3D were state trackers for Xorg and DRI2. State trackers are used in Gallium3D to track the state of something (such as Mesa's state) and to then translate that into operations...

http://www.phoronix.com/vr.php?view=NzExMA

[Pfanne]

what?
i always thought gallium was just for rendering oder gpgpu stuff and the rest like modesetting was handled by radeonhd for example o_O

[Gentooer]

So when will Intel start adding gallium support to their driver? Does experimental code already exist somewhere?

[elanthis]

what?
i always thought gallium was just for rendering oder gpgpu stuff and the rest like modesetting was handled by radeonhd for example o_O

I'm a bit fuzzy on most of it, but from what I understand, Gallium is a general-purpose low-level graphics engine. The state trackers are essentially the plug between a high-level API (be it OpenGL/Mesa, Cairo, Xorg/EXA, or any of a number of others). The winsys layer is then the plug between the OS, which is what would include the bits to talk to KMS and the kernel bits of DRI2/DRM. The middle layer of Gallium is then the actual "driver" that takes Gallium commands (generated by the state trackers) and converts them into hardware commands and submits them to the hardware (using the winsys layer as appropriate).

The state trackers are pretty flexible. In OpenGL, for example, you have a drawing context. You don't say "draw a red triangle here," but instead you say, "set the drawing color to red; now add these three coordinates; now connect the coordinates I gave you to render a triangle." The state tracker tracks the 'state' of the OpenGL context and eventually generates real drawing commands. Cairo uses a similar context-based drawing API, and hence can be accelerated in a very similar fashion. The Cairo state tracker would simply be tracking 2D-only state and be doing some tesselation to generate triangle-based rendering commands for the hardware, but otherwise is really the same as the OpenGL state tracker in general. EXA works less with contexts and more with complete drawing commands (very simplistic ones), so the EXA state tracker would be even simpler -- it would just translate EXA commands into Gallium commands without actually even needing to track much state.

I'm a little unclear on exactly what a KMS/DRI2 state tracker is good for... I think it's meant to help writing nested window systems. One binary can talk over the same interface to both the actual hardware drivers (drawing to the framebuffer and resizing the actual output) or to an 'emulated' display (drawing to a buffer and resizing that buffer) without needing or even being able to know the difference.

[Pfanne]

so everything that radeon/hd does, like modesetting exa etc will be ported to gallium3d which than handles all this stuff?

[Vighy]

the lack of a drawing showing the real structure of the whole thing, makes understanding gallium and Co. a bit difficult

[elanthis]

so everything that radeon/hd does, like modesetting exa etc will be ported to gallium3d which than handles all this stuff?

Modesetting is going into KMS. The only reason radeon/radeonhd does that now is because they had to before KMS was in mainline and ready to go. All modesetting is going into the kernel and out of the individual Xorg drivers.

The drawing acceleration is all going into Mesa/OpenGL. Right now the drivers include hardware acceleration in EXA due to a lack of solid OpenGL driver support. The eventual plan was to get Xorg to just have a generic OpenGL-based rendering backend, which is what XGL does and what the glucose project for Xorg is supposed to accomplish.

Xorg then uses DRI2 and a standardized video memory management API (be it GEM, TTM, or whatever everyone eventually settle on) for allocating buffers and the like.

At that point I think the only thing left is video playback acceleration. Gallium has some shader-based implementations of that, but I don't know if there are plans to provide a proper video acceleration API in Gallium or what. I imagine the eventual plan is to have a standardized API and driver set for that which is independent of Xorg as well.

Basically, radeon/radeonhd only exist right now because until very recently Xorg had to have all the hardware support in its drivers. That is all going away, and eventually Xorg will not have any hardware specific drivers in it at all. It's just going to be a layer that interfaces between applications (managing windows and events and protocol and such) and the underlying system (input drivers, KMS, DRI2, Mesa/OpenGL, etc.)

That is all completely orthogonal to Gallium. Gallium's purpose as I understand is just that it makes implementing many parts of that future graphics stack much easier and more efficient, particularly because it makes it possible to write an Xorg backend or Cairo backend that can talk directly in modern-hardware-friendly operations instead of needing to translate Xorg drawing into OpenGL which then gets translated into those hardware-friendly operations. Gallium is a modern hardware-accelerated rendering layer that sits between the low-level OS interfaces and the high-level user-friendly APIs.

[Pfanne]

so radeonhd will basicly disappear, when everything is ported to gallium3d?

[MaestroMaus]

Modesetting is going into KMS. The only reason radeon/radeonhd does that now is because they had to before KMS was in mainline and ready to go. All modesetting is going into the kernel and out of the individual Xorg drivers.

The drawing acceleration is all going into Mesa/OpenGL. Right now the drivers include hardware acceleration in EXA due to a lack of solid OpenGL driver support. The eventual plan was to get Xorg to just have a generic OpenGL-based rendering backend, which is what XGL does and what the glucose project for Xorg is supposed to accomplish.

Xorg then uses DRI2 and a standardized video memory management API (be it GEM, TTM, or whatever everyone eventually settle on) for allocating buffers and the like.

At that point I think the only thing left is video playback acceleration. Gallium has some shader-based implementations of that, but I don't know if there are plans to provide a proper video acceleration API in Gallium or what. I imagine the eventual plan is to have a standardized API and driver set for that which is independent of Xorg as well.

Basically, radeon/radeonhd only exist right now because until very recently Xorg had to have all the hardware support in its drivers. That is all going away, and eventually Xorg will not have any hardware specific drivers in it at all. It's just going to be a layer that interfaces between applications (managing windows and events and protocol and such) and the underlying system (input drivers, KMS, DRI2, Mesa/OpenGL, etc.)

That is all completely orthogonal to Gallium. Gallium's purpose as I understand is just that it makes implementing many parts of that future graphics stack much easier and more efficient, particularly because it makes it possible to write an Xorg backend or Cairo backend that can talk directly in modern-hardware-friendly operations instead of needing to translate Xorg drawing into OpenGL which then gets translated into those hardware-friendly operations. Gallium is a modern hardware-accelerated rendering layer that sits between the low-level OS interfaces and the high-level user-friendly APIs.

Thanks, you exactly told what I wanted to know about Gallium.

[russofris]

The state trackers are pretty flexible. In OpenGL, for example, you have a drawing context. You don't say "draw a red triangle here," but instead you say, "set the drawing color to red; now add these three coordinates; now connect the coordinates I gave you to render a triangle." The state tracker tracks the 'state' of the OpenGL context and eventually generates real drawing commands. Cairo uses a similar context-based drawing API, and hence can be accelerated in a very similar fashion. The Cairo state tracker would simply be tracking 2D-only state and be doing some tesselation to generate triangle-based rendering commands for the hardware, but otherwise is really the same as the OpenGL state tracker in general. EXA works less with contexts and more with complete drawing commands (very simplistic ones), so the EXA state tracker would be even simpler -- it would just translate EXA commands into Gallium commands without actually even needing to track much state.

Does Gallium/Mesa have the "WGL" style limitation of a single OpenGL context, or can I open multiple contexts? If I have multiple cards, can I open multiple OpenGL contexts per card?

Frank