[Mesa3d-dev] [PATCH] Provide dri shared library building and SDK installation.

[Luc Verhaegen]

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.