Reply With QuoteMy understanding is that Gallium3D talks directly to DRI2, since DRI2 is an X server protocol not a driver-level protocol.
I haven't walked through that part of the code, however.
Senior Member
Gallium3D Confusion: State Tracker and DRM
So Wikipedia says:
This leads me to believe that Gallium3D talks directly to DRI2. But the article says later on that Intel and Cell drivers are still under development.Gallium3D provides a unified API exposing standard hardware functions such as shader units found on modern hardware. Thus, 3D APIs such as OpenGL 1.x/2.x, OpenGL 3.x, OpenVG, GPGPU infrastructure or even Direct3D (as found in the Wine compatibility layer) will need only a single back-end, called state tracker, targeting Gallium3D API. By contrast Mesa 3D requires a different backend for each hardware platform...
So...
Does Gallium3D talk directly to DRI2, or is there another layer in between for each hardware driver?
AMD Linux
My understanding is that Gallium3D talks directly to DRI2, since DRI2 is an X server protocol not a driver-level protocol.
I haven't walked through that part of the code, however.
Last edited by bridgman; 04-10-2009 at 01:14 PM.
Senior Member
So I would think then that all you need to make Gallium3D work is a DRI2 driver. Or wait, maybe DRI2 is, in fact, Mesa. I was thinking that Gallium3D might be able to use the kernel's DRM drivers directly.Originally Posted by bridgman
AMD Linux
Hold on thar'
One of the great sources of confusion with X drivers is that people talk about "DRI drivers" when they really mean "the 3D driver, which uses DRI to find out where it should draw on the screen". 99% of the 3D driver has nothing to do with DRI.
It depends on whether you are talking about the DRI protocol or the DRI architecture, I guess.
What you need to make Gallium3D work on a new GPU is a pipe and a winsys driver. Pipe drivers (eg gallium/drivers/r300) are totally GPU-specific, while winsys drivers (eg. gallium/winsys/drm/radeon) are theoretically only OS- and environment-specific but actually end up being a bit HW-specific as wel because drm implementations vary from one GPU to the next.
Gallium3D drivers should be able to use the existing drm drivers -- but in practice most of the existing drm drivers are based on DRI(1) and no memory management, while the current Gallium3D implementations assume the existence of DRI2 and a kernel memory manager. Six months from now I expect that Gallium3D drivers and classic Mesa drivers will be using the same drm.
Last edited by bridgman; 04-10-2009 at 01:46 PM.
Phoronix Member
So, in theory, if Wine were to move the Direct3D support directly into Gallium, would it be able to use parts of the DirectX API regarding hardware information that OpenGL has no equivalent of?
I remember awhile ago that Wine has to fake the hardware information because OpenGL does not provide an API equivalent to the DirectX one regarding VRAM and chip type, etc.
Senior Member
There are no plans inside Wine to implement DirectX on top of Gallium 3D.
Wine is meant to support platforms that don't use Gallium3D (Apple, *BSD, the DX-replacement on VirtualBox etc), so the D3D->OGL wrapper needs to be maintained anyway.
yeah, making more hardware information available would probably help wine, but it doesn't take a whole DX implementation for that.
Phoronix Member
That is why the question was theoretical. In all practicality, the Wine Project would never move DirectX to Gallium3D for the reason you stated. However, Wine could hook into the Gallium framework to get info like that if it were possible. Just like it could do the same with the respective frameworks on Mac OS X, BSD, and even Windows.
Senior Member
I wonder if Gallium3D can be used with Wayland.
Senior Member
I don't see why not. G3D is a part of Mesa, not a part of X. Since wayland allows the use of Mesa, G3D should be usable.
Senior Member
Nice. Because it seems like desktop Linux could lose a lot of bloat if we ditched X11.
Posting Permissions
