Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 50

Thread: The Status Of Gallium3D Drivers, State Trackers

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

    Default

    I was thinking of VirtualBox.

  2. #12
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,567

    Default

    Quote Originally Posted by wswartzendruber View Post
    I was thinking of VirtualBox.
    That'd be less native, not more.
    Edit: Technically it might in time work if hooked up with Gallium3D but I've been hearing very contradictory opinions on whether these new CPU emulation technologies actually help at all with speed.
    Last edited by nanonyme; 08-08-2009 at 10:06 AM.

  3. #13
    Join Date
    Aug 2007
    Posts
    153

    Default

    All signs point to Tungsten/VMWare having an internal DirectDraw/Direct3D state tracker already, but they haven't confirmed this.

    Mesa's core has already been adapted into a state tracker for OpenGL 1.0-2.1 support. A few developers (mostly idr and osiris) have been submitting patches for various extensions belonging to OpenGL 3.x. Fortunately, it looks like we're not too far behind the ball this time; the important stuff, like FBO handling changes, will be really easy to adapt to, since we're using real memory managers on the Gallium drivers.

    I seem to recall zackr mentioning that somebody was working on an OpenCL Gallium state tracker. Also, the preferred video decoding interface would be VDPAU; supporting it or either of the other two advanced video APIs (VA-API, XvBA) will require augmenting g3dvl with a true pipeline. (If you're serious about this, ping me and ymanton on IRC. #nouveau or #dri-devel.)

    Regarding writing Gallium code... There's really no way around reading the code, but I'll give you a few places to start. Read the headers in src/gallium/include/pipe/p_*.h. The main class of drivers is pipe_context, which contains a few dozen methods for setting state and issuing draw commands. There's also pipe_screen, which contains things like the capabilities of the card you're on, and buffer management.

    If you're writing a driver, you'll probably fill out your pipe_screen, and then your pipe_context, and most of the code you write will be for managing the state connected to the pipe_context.

    If you're writing a state tracker, you'll want to get a pipe_screen and pipe_context, and then send drawing commands to it, while interfacing with your frontend.

    The API is constantly shifting bit by bit to be more sane, but all drivers and state trackers that are in-tree enjoy maintenance and testing on a semi-regular basis, just like the kernel, so it's really not that bad. (I don't know anybody actually using the Cell driver except for the occasional guy on the mailing list, but it still receives updates and API fixes.)

    Again, if you're serious about writing code, come into #dri-devel; we're more than happy to help you start understanding the code. :3

    ~ C.

  4. #14
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,567

    Default

    Quote Originally Posted by MostAwesomeDude View Post
    All signs point to Tungsten/VMWare having an internal DirectDraw/Direct3D state tracker already, but they haven't confirmed this.
    Wonder if it's "DirectDraw/Direct3D-like" state tracker or the real thing. (just wondering because with the former you don't need WinAPI at all but might still get trivial mappings of functions and less trivial but still possible mapping of HLSL to TGSI and would work with all Gallium3D drivers)
    As in, something that's easy to wrap up with VMWare virtualization products later on to get a code path without OpenGL in-between there. Would be a good thing in any case.

  5. #15
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by nanonyme View Post
    As in, something that's easy to wrap up with VMWare virtualization products later on to get a code path without OpenGL in-between there. Would be a good thing in any case.
    Would MS be able in the future to forbid other implementations than their own?

  6. #16
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,567

    Default

    Quote Originally Posted by Louise View Post
    Would MS be able in the future to forbid other implementations than their own?
    Afaik no, the API is fully free to use. (which implies you're also fully free to implement it) It's mostly just that their implementation isn't free to use. (you need a valid Windows license to fully legally use Microsoft's DX libraries) That was Microsoft's decision long time ago that made development on Windows easier since every developer could just trivially look up the function descriptions from MSDN.

  7. #17
    Join Date
    Aug 2008
    Posts
    22

    Default One driver per ST per chipset??

    Hi,

    There is something i do not quite understand in this matrix. I thought the aim of Gallium was to write only one driver per pipe and once this driver written, all state trackers would work automatically, unlike current mesa in which you have to rewrite all the stacks in each driver. So why is it that the completion state for each state tracker depends on the pipe? It looks like we are losing the advantage of gallium but i must be misunderstanding something. I would appreciate if someone could explain me where i am wrong. Many thanks!

  8. #18
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by Med_ View Post
    Hi,

    There is something i do not quite understand in this matrix. I thought the aim of Gallium was to write only one driver per pipe and once this driver written, all state trackers would work automatically, unlike current mesa in which you have to rewrite all the stacks in each driver. So why is it that the completion state for each state tracker depends on the pipe? It looks like we are losing the advantage of gallium but i must be misunderstanding something. I would appreciate if someone could explain me where i am wrong. Many thanks!
    The way I understand it is, that e.g. in the case of "egl" state tracker that is DONE, this will also work for all the other GPU's once they get Gallium support.

    If that's the case, perhaps it would be more clear to just color the titles, and then just set X once the GPU have Gallium support and the particular state tracker have been written.

    ???

  9. #19
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by nanonyme View Post
    Afaik no, the API is fully free to use. (which implies you're also fully free to implement it) It's mostly just that their implementation isn't free to use. (you need a valid Windows license to fully legally use Microsoft's DX libraries) That was Microsoft's decision long time ago that made development on Windows easier since every developer could just trivially look up the function descriptions from MSDN.
    Cool. Also I guess if MS could forbid use of their API, they would have stopped WINE a long time ago

  10. #20
    Join Date
    May 2008
    Location
    Germany/NRW
    Posts
    510

    Default

    Quote Originally Posted by Med_ View Post
    So why is it that the completion state for each state tracker depends on the pipe? It looks like we are losing the advantage of gallium but i must be misunderstanding something. I would appreciate if someone could explain me where i am wrong. Many thanks!
    You're reading the table wrong: It doesn't show the completion state of the state-trackers, but it shows the ability of the drivers to run the state-trackers. So there's really just one state-tracker for each functionality (which afaik are more or less complete), but the drivers are not yet able to run them.

Posting Permissions

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