Announcement

Collapse
No announcement yet.

The Status Of Gallium3D Drivers, State Trackers

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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.

    Comment


    • #17
      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!

      Comment


      • #18
        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.

        ???

        Comment


        • #19
          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

          Comment


          • #20
            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.

            Comment


            • #21
              Originally posted by Zhick View Post
              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.
              Ah thanks, i think i see what you mean. So for instance an incomplete pipe driver might be able to run only some ST for instance due to some missing implementations?

              Comment


              • #22
                Anything that Wine has done regarding w32api implementation has been more or less accepted as legal. Most of the ReactOS code is also okay.

                Originally posted by Med_ View Post
                Ah thanks, i think i see what you mean. So for instance an incomplete pipe driver might be able to run only some ST for instance due to some missing implementations?
                Pretty much. This is also going back to the idea of conformance tests. State trackers should demand precise or predictable results from pipes, so if a pipe has a small bug that only affects one state tracker, we shouldn't mark the entire pipe as broken. This is similar to how we have a table of games on r300; the table shows that occasionally certain games might have defects, but it doesn't mean that the entire driver is bad.

                Comment


                • #23
                  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.
                  Even if they do, it wouldn't be of much use for Linux/Wine. Windows D3D drivers don't implement the entire API like Windows OpenGL drivers do. There's a huge chunk of the D3D API that's written by Microsoft and then layered on top of a simpler API the drivers implement. You'd need to reimplement all that code as well before you'd have a complete Direct3D state tracker usable on Linux, and at that point it's probably easier to just make a native D3D state tracker.

                  Comment


                  • #24
                    Originally posted by nanonyme View Post
                    You don't believe getting rid of an emulation level would yield higher performance? (as in, you wouldn't have to do D3D->OpenGL conversion anymore)
                    I do believe that native D3D support within drivers would speed up things (uhm, that's what I acutally said).

                    Originally posted by nanonyme View Post
                    It's mostly a matter on whether Wine developers want to keep using OpenGL or not for D3D.
                    That would mean we'd replace a quite well tested and optimized (and pretty well working) framework with a framework which would be damn buggy for at least two years and won't be supported properly by _any_ driver within the same time period. That's why we'd need to keep the old code for compatibility and even just making it possible to switch between redirecting OpenGL->D3D and native D3D support would be such an invasive change that half of today's supported applications would break due to some regressions...

                    Originally posted by nanonyme View Post
                    Right, so we can't go for the likely better implementation (not using OpenGL) just because closed drivers aren't going to support that (they only want to use OpenGL)?
                    Only because OSS drivers would get a 20% boost in performance (which is unlikely) that doesn't mean it would work better than the closed driver. Note that I would not expect any speed improvement on the OSS side since the D3D driver simply wouldn't be on pair with the OGL one performance-wise. The OSS OpenGL drivers have been in development for so many years now (that is: optimized) that a D3D driver would need at least 5 years to catch up.

                    Originally posted by nanonyme View Post
                    Since when did Linux userland development start depending on the whim of proprietary driver coders? This is as close as native D3D as you can get.
                    It's not that we depended on what the ATI devs are willing to do, but it's a matter of fact that they are pretty unlikely to implement it (remember they mostly implement stuff the workstation market uses). BUT there are Wine users who do not want to pay 200 for their brand new X4950 to use the OSS drivers and only get 30% of the binary driver's performance (uhm, seeing that no OSS driver can run SM2 games, that should be the vast majority), so if we simply "dropped" support for binary drivers we'd lose like 80% of our users

                    Comment


                    • #25
                      Did I say somewhere I said things need to be dropped now in favour of something else? The development timeline will probably be anyway from months to years, no end-user would be seeing any differences for a long time regardless of what they did... And note, the biggest benefits of D3D over G3D aren't in speed but in that like WineHQ's wiki says, you currently need a much newer card with the OpenGL emulation than with native D3D because the emulation is a tad lossy.

                      Comment


                      • #26
                        Originally posted by wien View Post
                        You'd need to reimplement all that code as well before you'd have a complete Direct3D state tracker usable on Linux, and at that point it's probably easier to just make a native D3D state tracker.
                        Gallium3D D3D would pretty much be a native D3D state tracker...

                        Comment


                        • #27
                          Originally posted by nanonyme View Post
                          Gallium3D D3D would pretty much be a native D3D state tracker...
                          Not the one VMWare (probably) already have, which was my point.

                          Comment


                          • #28
                            Originally posted by wien View Post
                            Not the one VMWare (probably) already have, which was my point.
                            Well, no one said the state tracker couldn't be used also for other use than just for VM's, did they? It's probably just a new API for userspace applications to use. If it's close to the real D3D API, shouldn't be impossible to have eg have a fork of Wine that maps D3D functions against functions in Gallium3D D3D API. There'd be guaranteed to be equivalents for every function then.
                            EDIT: Edit functionality sucks, I think it has actually increases the amount of typos since you know you can correct them and don't pay as much attention.

                            Comment


                            • #29
                              Originally posted by nanonyme View Post
                              Well, no one said the state tracker couldn't be used also for other use than just for VM's, did they?
                              No, but this has nothing to do with VMs. It has to do with the Windows driver model.

                              Originally posted by nanonyme View Post
                              It's probably just a new API for userspace applications to use. If it's close to the real D3D API, shouldn't be impossible to have eg have a fork of Wine that maps D3D functions against functions in Gallium3D D3D API. There'd be guaranteed to be equivalents for every function then.
                              Look, Windows Direct3D applications use the Direct3D API. Windows Direct3D drivers, and thus the probable Gallium D3D state tracker, implement the DDI API. Between these two there's a whole mess of stuff, the Direct3D runtime, that's written by Microsoft and that houses among other things the HLSL compiler. This is a lot of code.

                              Unless Wine's Direct3D layer also uses an intermediate DDI that matches the one in Windows (and why would it?), the D3D state tracker VMware probably already have would be of little use as you wouldn't have the runtime. At that point it's probably easier to just map the entire Direct3D API on top of Gallium in a separate state tracker instead of trying to shoehorn DDI in there.

                              That's my point. Nothing more, nothing less.
                              Last edited by wien; 08-16-2009, 12:20 PM.

                              Comment


                              • #30
                                There could be a partial D3D state tracker as well, something that would take over the non-convertible parts, like HLSL

                                Comment

                                Working...
                                X