No announcement yet.

AMD's Position On Gallium3D Support

  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    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"
    And no ifdef's around the code itself..


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


      • #23
        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.)


        • #24
          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. :-)


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


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


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


                • #28
                  Originally posted by sylware View Post
                  Allow me to do my lazy bastard: where are the source headers which describe gallium3d API?

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


                  However I recommend looking at the headers first.


                  • #29
                    Originally posted by bridgman View Post
                    So... the only "definitive" change in plans is that there is likely to be a separate mesa driver for Evergreen, basically an edited copy of the r600 driver. I guess we might call it r800 to make everyone happy, as long as you all accept that there is no r800 just Evergreen
                    Instead of r800, how about everGREEN ?


                    • #30
                      Actually, the released shader ISA documentation refers to it as an R800 as well (probably an oversight- the title in the PDF properties is "")