Announcement
Collapse
No announcement yet.
AMD's Position On Gallium3D Support
Collapse
X
-
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:
-
Originally posted by bridgman View PostSo... 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
Leave a comment:
-
Originally posted by sylware View PostAllow 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:
-
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:
-
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:
-
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:
-
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:
-
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:
Leave a comment: