Announcement

Collapse
No announcement yet.

AMD's Position On Gallium3D Support

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

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

    Comment


    • #12
      Guys over at AMD,
      other guys working on the OS ATI driver,

      Your awesome, period! Thanks for the ongoing work.

      Comment


      • #13
        Allow me to do my lazy bastard: where are the source headers which describe gallium3d API?

        Comment


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


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


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


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


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

                  Comment


                  • #19
                    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.
                    Test signature

                    Comment


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

                      Working...
                      X