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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
