[Mesa-dev] Mesa/Gallium overall design

[Bridgman, John]

John Bridgman wrote :
> OK, file this under "be careful what you wish for"...
> 
> It turns out that while the programming model of Evergreen is 
> very similar to 7xx, the register offsets are totally 
> different, which has been causing a bunch of header file pain 
> trying to merge Evergreen support into the existing r600 driver. 
> 
> As a result of this discussion, we're thinking about changing 
> plans a bit - making a copy of the r600 driver and hacking it 
> up to be Evergreen only, then seeing if we can use that code 
> to jump-start an Evergreen Gallium3D driver sooner rather 
> than later. I guess we got our architectural break after all, 
> just not the way I expected.
> 
> We'll need to figure out how this would co-exist with the 
> work that Jerome and Corbin are doing - I'm thinking of it as 
> a "quick and dirty" proof of concept driver that might live 
> alongside the 600g code and eventually be replaced by it - 
> whatever works. Part of the rationale here is that we have 
> the same register-shuffling problem with the ddx driver so we 
> might end up with a new copy of the accel code anyways - if 
> so it might be a good time to play with using Gallium3D calls 
> for EXA and Xv. 
> 
> We're obviously not very far into this and I wouldn't 
> normally mention anything this soon if I hadn't just posted 
> something *different* an hour ago ;)
> 
> Regarding the "Gallium vs Classic" interfaces for Mesa, it 
> seems to me that the medium term plan should be to fork off a 
> copy of Mesa for pre-Gallium3D drivers and limit it to GL2 or 
> lower (the non-shaderful chips can't do GL2 anyways, can they 
> ?) and then let Mesa evolve as a Gallium3D-only state 
> tracker. This would *have* to be done on a schedule that 
> allowed all of the existing "shader-based GPU on classic 
> mesa" drivers (Intel, AMD, probably others) to comfortably 
> migrate to Gallium3D-based drivers, which might not be fast, 
> but at least there would be a plan. I wouldn't want to see 
> support for our "classic" 3D drivers go away too quickly either.
> 
> I'm a bit out of touch on the GL3 support going in now, so 
> it's not clear whether this is Gallium3D only or whether GL3 
> on the classic driver is practical. If GL3 is going to be 
> Gallium3D only then I assume it's just a matter of time 
> before all the active drivers move over, and the key is 
> finding the right point to start cutting over ? I know our 
> decision to go with "classic" Mesa drivers for 6xx/7xx was 
> not easy and it's probably not going to be any easier for the 
> Intel folks to make a decision to start moving to Gallium3D.
> 
> Anyways, does this all make sense ? I think things will work 
> best if we all ooze across to Gallium3D at more or less the 
> same time (say within 6 months at most) and I don't mind 
> trying to push our plans ahead or holding them back a bit to 
> make sure that we end up with a Gallium3D abstraction that 
> works for everyone.
> 
> BTW I received an out-of-office bounce from our OpenGL 
> architect, so probably won't hear back about deprecating 
> older GL functionality until next Monday. I'll ask some other 
> folks but I would rather get the definitive word from Pierre.
> 
> JB

Realized afterwards that my post about "oozing to Gallium3D
together" was kind of ambiguous - I meant "moving within 6
months of each other" not "moving within 6 months of today".

Also fixed up line spacing, sorry about that.