[Mesa3d-dev] [PATCH] Provide dri shared library building and SDK installation.
Luc Verhaegen
libv at skynet.be
Tue Apr 13 04:37:12 PDT 2010
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.
More information about the dri-devel
mailing list