Re: [PATCH V3 00/11] Mesa upgrade/improvements

[Phil Blundell <philb@gnu.org>]

On Mon, 2012-08-06 at 15:04 +0100, Richard Purdie wrote:
> Ok, we need to do something about this mess, period. Its not going to
> get any better and we need to sort it out. I can't "force" changes in
> but on the other hand I'm not going to tie the hands of everyone just
> because the ARM world in particular is a total mess in this area.
> 
> As such, I'm likely going to allow architecture overrides in core mesa
> so for example, IA can enable gles and egl for everyone and cleanup
> their binary blobs to override them on platforms where it makes sense. I
> suspect someone will start sending patches to enable a generic arm core
> and I am going to have a *really* hard time refusing the patches due to
> any one silicon provider's binary blob issues.

It's not obvious to me that this is really an architecture-level problem
or that having different Mesa feature sets enabled on different
architectures is a positive thing. 

I'm also not totally convinced that any insurmountable problem actually
exists today with evil vendor blobs.  If they install themselves into
some directory that isn't /usr/lib and arrange for the dynamic linker to
find their libEGL.so (etc) ahead of the Mesa one then it seems like
everything should "just work" with today's technology.  As you observed,
sort of the whole point of the EGL/GL/GLES abstraction is that you have
a common API/ABI to write to irrespective of the implementation.

(Realistically, it seems fairly unlikely that there are very many
situations where using Mesa libGL on top of a vendor libEGL is going to
make much sense.  If you have vendor libEGL but not libGL then the
chances are you have GLES instead and this is probably what you want to
be using.)

So, all in all, I tend to think that we should just apply these patches
and then do whatever else is necessary for the evil-binary-vendor stuff
to be correctly packageable.

p.