Announcement

Collapse
No announcement yet.

AMD's Position On Gallium3D Support

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

  • #16
    Originally posted by MaestroMaus View Post
    Guys over at AMD,
    other guys working on the OS ATI driver,

    Your awesome, period! Thanks for the ongoing work.
    Very easy to agree with that.

    Comment


    • #17
      Sorry for not having a clue/getting it wrong, but reading this sounds to me as if AMD needs to make a working Evergreen 3D driver and is contemplating whether to use G3D.
      This confuses me because I thought AMD already had a working Evergreen driver...

      Comment


      • #18
        Originally posted by bugmenot View Post
        Sorry for not having a clue/getting it wrong, but reading this sounds to me as if AMD needs to make a working Evergreen 3D driver and is contemplating whether to use G3D.
        It's mostly about opensource drivers and that Evergreen was unexpectedly dissimilar in some ways to R600/R700 (while being very similar in other ways) so opensource developers fork Evergreen code out of R600/R700 codebase but the end result will be separate opensource R600/R700 and opensource Evergreen drivers. (assuming I got it right) Very likely it just means more files to compile, nothing to worry about.

        Comment


        • #19
          Originally posted by nanonyme View Post
          It's mostly about opensource drivers and that Evergreen was unexpectedly dissimilar in some ways to R600/R700 (while being very similar in other ways) so opensource developers fork Evergreen code out of R600/R700 codebase but the end result will be separate opensource R600/R700 and opensource Evergreen drivers. (assuming I got it right) Very likely it just means more files to compile, nothing to worry about.
          Thank you for clearing that up!
          Somehow I thought this was about the closed source drivers, with bridgman posting and all...

          Comment


          • #20
            Yeah, it's entirely about open source drivers. Work was already underway on adding 3D support for Evergreen to the classic 6xx/7xx mesa HW driver, the devs were spending more time dealing with register address changes than programming model changes, and we decided to make a copy of the 6xx/7xx code for Evergreen rather than try to make one copy support both 6xx/7xx and Evergreen.

            Six months ago this would have caused maintenance problems over time because many of the bug fixes & enhancements would need to be made in both copies of the code, but given that a Gallium3D driver for 6xx and higher is a lot closer to reality we may end up jumping across to G3D anyways so the long term extensibility of the classic mesa driver becomes less important.

            If it does turn out that we need to stay with the classic mesa driver for a long time, then we just need to finish the work that was already underway to let 6xx/7xx and Evergreen use the same code -- but this way you will already have Evergreen 3D support to use while we are doing that work, rather than having it be on the critical path.

            Comment


            • #21
              We started building the proprietary OpenGL drivers around a Gallium3D-like hardware layer several years ago.

              The new OpenGL driver appeared in the Linux driver stack in Sep 2007.

              Comment


              • #22
                Originally posted by agd5f View Post
                idfefs don't work so well if you want to have a single shared binary for all the asics. If you are going to ifdef it all, you might as well just copy the code to a new driver.

                We considered (and may still) rework the the r600 driver to better split the common code from the asic specific code. E.g., share common things like the draw setup and shader compiler, and create separate files for asic specific state setup/emit. Depending on how the initial work looks, that may or not make sense depending on where we consider our time best spent.

                One thing I was thinking is that it might be interesting to see what design impact a more elaborate macro/offline-code-generation framework might have on driver maintenence..

                In particular, I think aspect oriented languages would simplify the cache management/synchronisation calls. Of course, an aspect-oriented language would probably be too slow to implement the driver itself in, but used as a code generator, that might not be a problem.

                Comment


                • #23
                  You may have already thought about this, but this comes to mind as one path:

                  Instead of a complete copy, have a switch --select-driver=[r600/r800] to pick which to build. This way you can share everything except the generation-specific paths.

                  #ifdef r600
                  #include "r600_registers.h"
                  #elif r800
                  #include "r800_registers.h"
                  #endif
                  And no ifdef's around the code itself..

                  Comment


                  • #24
                    Originally posted by curaga View Post
                    Instead of a complete copy, have a switch --select-driver=[r600/r800] to pick which to build. This way you can share everything except the generation-specific paths.
                    All distros are going to want to compile both, not just one.

                    Comment


                    • #25
                      If I'm not mistaken, a lot of the accel code in the DDX already uses macros in order to use the same code to target both MMIO and DRM-context output (they simply compile the file twice, with different options both times, while another macro prefixes the function name with the output mode it's compiled with.)

                      Comment


                      • #26
                        Of course you would want to compile both, so you compile 2 times, once for r600 and once for r800. Most of the code is shared, so why create duplicate copies of the code?

                        Another problem is the build system, it shouldn't be made too odd, as that just makes it difficult to use at all.

                        But they will decide as to how it should go, lets not tell them how to do their job, they already know how to do it. :-)

                        Comment


                        • #27
                          The rationale for doing this was two-fold :

                          1. There is a good chance the classic driver code will be replaced with a Gallium3D driver, which would be different code anyways, so maintainability in that scenario is a non-issue

                          2. If it does turn out that we need to maintain the classic driver for a longer time, we would want to go back to a single code base. In that case we would end up doing roughly the same amount of work as if we stayed on the old plan but would end up making Evergreen support available sooner (since it wouldn't have to wait for a good co-existence strategy to be implemented).

                          Comment


                          • #28
                            3D hardware seems to move very quickly these days. It was only a few years ago that Dx9c seemed to be the norm in Windows. Now already onto dx 11 with major changes.

                            I notice that anything to do with Linux usually "oozes" along slowly. Which is not always a bad thing, because it doesn't rush into a disaster. Long term learning curve stays the same.

                            Comment


                            • #29
                              Yeah, there's something to be said for having all hard work done by three exceptional people rather than hundreds of pretty good people...

                              ... unless you're one of those three people, in which case it probably sucks

                              Comment


                              • #30
                                Originally posted by sylware View Post
                                Allow me to do my lazy bastard: where are the source headers which describe gallium3d API?
                                http://cgit.freedesktop.org/mesa/mes...m/include/pipe

                                It looks more or less like Direct3D 10. You can find the docs here:

                                http://cgit.freedesktop.org/mesa/mes...c/gallium/docs

                                However I recommend looking at the headers first.

                                Comment

                                Working...
                                X