I'm afraid that the situation is still pretty much what it was. We have a working solution which supports everything that we have a business case to support; we have a good idea of how much maintenance effort our current solution is; and we don't have the spare resources available to produce a new 3D driver without a clear business case while still maintaining the old one until it was in a usable state (which we would have to obviously, and which is a rather unpredictable time frame).
I seem to recall that you were planning to have a go at a G3D driver yourself - I am interested to know how far you got, and what you learned/what the problems were which stopped you getting further. For the record, I have also investigated Gallium3D a bit, and it seems to me to be less than ideal for our purposes. For a start, it is not an API, but a framework for writing drivers, and one which evolves over time. So we would need to either have our driver upstream (which we have not yet committed to, not least because it would need a decision about keeping our ABI stable) or we would need to fork Gallium3D, which means forking Mesa. Which leads to the next problem: the main purpose of Gallium3D (yes, I know there are lots of secondary ones) is to produce DRI drivers. However, DRI does not have a stable API either, but is tied into Mesa (and is therefore dependent on the Mesa version) in a way which I don't feel very happy with. So forking Mesa would lead to problems as soon as we wanted to be compatible with the DRI subsystem installed on a random guest system. Our current DRI driver uses some not very nice hacks to get around that, and I am more inclined to spend time making those hacks nicer than trying to get two different and random versions of Mesa to play together.
I would be interested to hear your thoughts about this, but I don't think that we are likely to rethink our position just now.
