Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Gallium3D Confusion: State Tracker and DRM

  1. #1
    Join Date
    Aug 2008
    Location
    California, USA
    Posts
    196

    Default Gallium3D Confusion: State Tracker and DRM

    So Wikipedia says:

    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...
    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.

    So...

    Does Gallium3D talk directly to DRI2, or is there another layer in between for each hardware driver?

  2. #2
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    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 02:14 PM.

  3. #3
    Join Date
    Aug 2008
    Location
    California, USA
    Posts
    196

    Default

    Quote Originally Posted by bridgman View Post
    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.
    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.

  4. #4
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    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 02:46 PM.

  5. #5
    Join Date
    Jul 2007
    Posts
    53

    Default

    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.

  6. #6
    Join Date
    Nov 2008
    Posts
    767

    Default

    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.

  7. #7
    Join Date
    Jul 2007
    Posts
    53

    Default

    Quote Originally Posted by rohcQaH View Post
    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.
    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.

  8. #8
    Join Date
    Aug 2008
    Location
    California, USA
    Posts
    196

    Default

    I wonder if Gallium3D can be used with Wayland.

  9. #9
    Join Date
    Nov 2008
    Posts
    767

    Default

    Quote Originally Posted by wswartzendruber View Post
    I wonder if Gallium3D can be used with
    Wayland.
    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.

  10. #10
    Join Date
    Aug 2008
    Location
    California, USA
    Posts
    196

    Default

    Nice. Because it seems like desktop Linux could lose a lot of bloat if we ditched X11.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •