AMD's Position On Gallium3D Support

[pvtcupcakes]

I just posted a bit of an update. After some discussion internally, we're thinking about starting a new copy of the r600 driver for Evergreen. The programming model is still very similar to earlier chips but the register addresses have moved around a lot. This gives us a good excuse to start a Gallium3D-based driver earlier - not sure if we are going to do it or not but we're going to look at it.

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

Not sure what will happen with ddx and Gallium3D driver yet; we'll revisit that after getting further on the Evergreen Mesa driver and discussing options with Jerome & Corbin.

I'm certainly no expert, but if only the register addresses are different, can't they just be #ifdef'd?

So you could do something like this:

#ifdef _R600
#define REGISTER_ADDRESS 0xDEADBEEF
#elif _R800
#define REGISTER_ADDRESS 0xFEEBDAED
#endif

[bridgman]

Yeah, I think the problem is that nearly every line had to be #ifdef'ed and it started to look like driver code hidden behind a wall of #ifdef statements.

I don't think it will be a problem; this just seemed like a good opportunity to kill two birds with one stone -- I didn't want to invest a lot of time designing a solution for the classic mesa driver if jumping across to Gallium3D also made the problem go away. The thought process basically went :

- merged 6xx/7xx/Evergreen classic driver
- toss the work already done on Evergreen/classic, jump to Gallium3D immediately
- copy r600 and hack up an Evergreen-specific copy quickly, in parallel decide whether to jump onto Gallium3D immediately

It was one of those unplanned replanning moments

[agd5f]

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.

[MaestroMaus]

Guys over at AMD,
other guys working on the OS ATI driver,

Your awesome, period! Thanks for the ongoing work.

[sylware]

Allow me to do my lazy bastard: where are the source headers which describe gallium3d API?

[Hephasteus]

Guys over at AMD,
other guys working on the OS ATI driver,

Your awesome, period! Thanks for the ongoing work.

Very easy to agree with that.

[bugmenot]

Sorry for not having a clue/getting it wrong, but reading this sounds to me as if AMD needs to make a working Evergreen 3D driver and is contemplating whether to use G3D.
This confuses me because I thought AMD already had a working Evergreen driver...

[nanonyme]

Sorry for not having a clue/getting it wrong, but reading this sounds to me as if AMD needs to make a working Evergreen 3D driver and is contemplating whether to use G3D.

It's mostly about opensource drivers and that Evergreen was unexpectedly dissimilar in some ways to R600/R700 (while being very similar in other ways) so opensource developers fork Evergreen code out of R600/R700 codebase but the end result will be separate opensource R600/R700 and opensource Evergreen drivers. (assuming I got it right) Very likely it just means more files to compile, nothing to worry about.

[bugmenot]

It's mostly about opensource drivers and that Evergreen was unexpectedly dissimilar in some ways to R600/R700 (while being very similar in other ways) so opensource developers fork Evergreen code out of R600/R700 codebase but the end result will be separate opensource R600/R700 and opensource Evergreen drivers. (assuming I got it right) Very likely it just means more files to compile, nothing to worry about.

Thank you for clearing that up!
Somehow I thought this was about the closed source drivers, with bridgman posting and all...

[bridgman]

Yeah, it's entirely about open source drivers. Work was already underway on adding 3D support for Evergreen to the classic 6xx/7xx mesa HW driver, the devs were spending more time dealing with register address changes than programming model changes, and we decided to make a copy of the 6xx/7xx code for Evergreen rather than try to make one copy support both 6xx/7xx and Evergreen.

Six months ago this would have caused maintenance problems over time because many of the bug fixes & enhancements would need to be made in both copies of the code, but given that a Gallium3D driver for 6xx and higher is a lot closer to reality we may end up jumping across to G3D anyways so the long term extensibility of the classic mesa driver becomes less important.

If it does turn out that we need to stay with the classic mesa driver for a long time, then we just need to finish the work that was already underway to let 6xx/7xx and Evergreen use the same code -- but this way you will already have Evergreen 3D support to use while we are doing that work, rather than having it be on the critical path.