JB>>The reality is that we don't have a conveniently timed architectural break to force the writing of an all new driver, and I imagine you don't either, so we're all going to have to "ooze" across to Gallium3D.
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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
