Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 33

Thread: AMD's Position On Gallium3D Support

  1. #21
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    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.

  2. #22
    Join Date
    Jan 2009
    Posts
    86

    Default

    Quote 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.

  3. #23
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,186

    Default

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

  4. #24
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,672

    Default

    Quote 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.

  5. #25
    Join Date
    Jan 2009
    Posts
    86

    Default

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

  6. #26
    Join Date
    Jan 2008
    Location
    South Africa
    Posts
    234

    Default

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

  7. #27
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

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

  8. #28
    Join Date
    Mar 2007
    Location
    West Australia
    Posts
    368

    Default

    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.

  9. #29
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    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

  10. #30
    Join Date
    Jan 2009
    Posts
    625

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •