Announcement

Collapse
No announcement yet.

AMD's Position On Gallium3D Support

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

  • bridgman
    replied

    Leave a comment:


  • DuSTman
    replied
    Actually, the released shader ISA documentation refers to it as an R800 as well (probably an oversight- the title in the PDF properties is "R800_ISA--TRUNCATED.book")

    Leave a comment:


  • chaos386
    replied
    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 ?

    Leave a comment:


  • marek
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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

    Leave a comment:


  • b15hop
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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).

    Leave a comment:


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

    Leave a comment:


  • DuSTman
    replied
    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.)

    Leave a comment:


  • nanonyme
    replied
    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.

    Leave a comment:

Working...
X