No announcement yet.

AMD's Position On Gallium3D Support

  • Filter
  • Time
  • Show
Clear All
new posts

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


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


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


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


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


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


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


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


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


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