On Sat, Apr 10, 2010 at 04:44:09PM +0100, Keith Whitwell wrote: > I haven't been following this very closely, so apologies if I'm going > over established ground. > > This patch appears to create new libraries from some subset of Mesa's > internals. At a guess you're selecting some internal interface(s) > within mesa to become the public API of those libraries? I'm pretty > sure that's not something we're trying to achieve in this project. Why is this not something that you're trying to achieve in this project? It seems like simply good software development practice. > We have public APIs which we respect and implement, and which are > maintained and evolved under the Khronos umbrella. > > We have a strong driver-level interface (ie gallium) which we benefit > greatly from being rev as fast and as hard as we can, to adapt to our > evolving understanding of the problem space. We really don't want to > subject that interface to the strictures that come with becoming a > public API or ABI. So you just do not want to provide the free software world with the ability to just update drivers, and instead want everyone to keep updating most of their installations when they encounter a bug? There is a need to have integrated driver stacks from all sides. The only involved party that is against this is some of the developers. Hardware vendors, distribution vendors, and all factions of users that you can name, they all have an explicit need on being able to update drivers without having to update the rest of their often extensively tested and trusted software. This is not a desire, like wanting windows/console like performance, and a really bling desktop. It is a tangible and clearly identifiable need. Without this ability to update graphics driver stacks without having to update the whole of the installation, we can rest assured that the free software desktop will never happen. You claim that you have a strong interface with gallium, but in the same sentence, you claim that you have a need to completely change that interface all the time. These two things don't really go together. By exporting this interface, you do not kill the ability to throw the interface around completely. You just cannot do so gratuitously anymore; you have to do some versioning and you have to updating what, in the end, will be external drivers. This is just more hassle over the current mode of working, and not exactly an unovercomable hurdle. The reward for that will be that driver developers can get their users to test updated drivers quickly and easily (as long as those updates do not depend on infrastructure changes), which vastly increases the likelyhood that these users get a good experience with their linux desktop in the near future. But having said that, going from one end of the scale to the completely opposite is impossible, and my patches are taking the first careful steps, showing the way forward, and are not forcing anything on the mesa developers. > We have a third interface, the Mesa driver interface, which may appear > relatively stable, but which is more accurately described as > neglected, veering towards deprecated. The shortcomings of this > interface, in particular its porous nature and inappropriate > abstraction level, were major catalysts provoking the development of > gallium. Those shortcomings would also make it less than appropriate > as a public API. At some point in the future, that interface will > either roar back into rapid evolution or truly be deprecated in favour > of either gallium or a low-level, legacy-free GL3/4 subset from > Khronos. > > I can't easily tell from your patch what interfaces these new > libraries have, or what expectations there would be for maintaining > compatibility on those interfaces going forward. I'd like to see that > spelled out explicitly. Without investigating further, I can say I'm > not aware of any interface within Mesa which we'd be happy to promote > to a public interface, nor one which we'd be happy to accept extra > restrictions on in terms of compatibility. The fact that the driver interface for mesa/dri is a mess, only aids my point here. If this SDK had been created earlier (as in, way before mesa 7.5, when gallium was pulled into master), then the mesa/dri interface would be much less of a mess today. The fact that you consider the mesa/dri mostly dead to me just means that this SDK is going to be rather stable and will not require much in the way of maintenance anymore after this. With the drivers and the SDKs i have created in my personaly git repos, I have gone all the way back to 7.0.3. I lost count on how many different versions there are with SDK, but i think somewhere between 15 and 20 currently. The changes to the SDK are all pretty managable, and i more often have had to spend time adjusting for build system changes and mesa internal dependencies than anything else. This quite effectively proves the long term feasibility of this SDK. Why do you like to see these "new" interfaces spelled out completely? You said yourself that this was just one big mess. It is not my job to go in and clean up this mess that was created over the timeframe of more than a decade, just to get you to see a clean API that you now apparently require before this very pragmatic patch can go in. What i do here is identify those bits of the API that are required for building the dri drivers externally. This is a very first step, one that does not hamper anyones abilities to work the way they are used to. If this does not evolve anymore because, as you said, you consider mesa/dri deprecated, then so be it, then this SDK is the actual API. How does this patch limit you in anyway? Could it be that you are more afraid of getting a ball rolling here, of being unable to mute existing demand with "impossible" (which, tbh, i haven't heard from you personally, but have heard frequently from others), than you are of this actual patch. To conclude, you basically state here that: a) you do not want any mesa internal APIs to become slightly more public as that might make it less easy to completely throw things around. b) mesa/dri is a mess that you consider deprecated, and you do not want the world to see what sort of a mess it became over the space of more than a decade and due to a). c) mesa/dri has no API, even though the fact that there are a dozen or so drivers using this "No-API" kind of points the other way. What i want to state is: a) Everyone needs the ability to get driver updates and bugfixes easily and painlessly, and the creation of an SDK, by formalizing existing library boundaries and headers can solve that with very little pain and only build system additions. b) It doesn't matter whether mesa/dri is considered deprecated, that just makes it easier to maintain this SDK. c) It doesn't matter what the api looks like, this patch is just a very pragmatic approach where we just pick what the drivers require. We actually might learn a thing or two here which might make gallium better software in future, without forcing a completely new mode of working on anybody today. If i had done the same work for mesa/gallium there would be a lot more protest, even though there are less drivers, and the existing API is supposed to be much much clean and beautiful, which inherently makes that a lot more practical than what i have now done for mesa/dri. Luc Verhaegen.
