Quote Originally Posted by DuSTman View Post
Point is, they aren't writing a complete driver - they're copying the r600 one. The evergreen microcode format is almost identical to that of r600/r700, with the exceptions of needing interpolation instructions for texture reads, so the compiler could probably be used with very little modification. Then there's apparently been some changes to the register offsets, but that, again, is something that should be straightforward to fixup for someone with the information.
It's a bit more involved than that. Parameter interpolation moves from hardware into the shaders, the hardware that was used for managing constants in the 6xx/7xx driver is gone (my understanding is that there were two ways to handle constants and one of them was removed), and there's a few not-particularly-well-documented bits that we're still figuring out. We knew about the first one, figured out the second one part way through the implementation, and are still struggling with the third. Plus the register offsets changed.

My guess is that we'll finish IP review about the same time we finish figuring out the hardware.

Quote Originally Posted by DuSTman View Post
I mean, from what we're told, it's so similar that it would probably take a full-time dev who's familiar with the codebase and has all the info no more than a week to adapt a copy of the r600 classic driver, whereas a gallium driver would probably take a couple of months at least before it reaches the same level of maturity.
Getting running on mesa is much faster for this generation (600g picked up texture code today; textures have been running for a while on Evergreen), but I'm hoping we can bring up the next hardware generation directly on the Gallium3D driver.