[PATCH 07/20] glamor: Add simple upload/download functions in glamor_transfer

[Daniel Stone]

Hi,

On 20 March 2014 20:27, Eric Anholt <eric at anholt.net> wrote:
> Daniel Stone <daniel at fooishbar.org> writes:
>> This isn't natively supported on GLES; it requires
>> GL_EXT_unpack_subimage, which isn't available on the vast majority of
>> shipping GLES GPUs.
>>
>> (Yes, I know it's lame: it's seriously my #1 gripe about GLES.)
>
> I think that's an open question for glamor: What GLES drivers do we care
> to target?  For desktop GL I think we care about targeting modern Mesa,
> what's in use on Windows, and what's in use on Mac, and that's why I
> haven't made ARB_mbr required for it.  But for GLES, as far as I know
> the only people that have shown interest in glamor (Intel) also have
> control over the driver stack, and can just fix their driver.
>
> So, are lame GLES drivers something we really need to support?

Depends, and depends.

In order of number of volume running generic Linux, I'd say it'd be
Mali-400, PowerVR SGX, then Mali-600 (totally separate codebase), in
descending order of shipments / ascending order of quality.

Aside from Chromebooks (where most vendors are in a very easy position
to implement unpack_subimage - it's not a GPU limitation, just
driver), you've just got a (very) long tail of random scattershot
devices running X11. Personally I do my hardest to avoid server-side
rendering as much as possible by shifting to client-side rendering
and/or just use another window system; either way, the only relevant
path through Glamor a full-buffer copy and thus unaffected by the
presence or otherwise of unpack_subimage.

As such, I don't really have any skin in the game, so am not in a
position to demand anything wrt your priorities. Just trying to flag
up potential issues as and when I see them, so it's less surprising if
someone does try to use it later.

I suppose the most useful thing I can think of for this would be a
Mesa flag which restricts the EGL extension set to the
commonly-supported ones, so this could be validated on Mesa rather
than found by random OEMs trying to actually ship a system with X11
down the line. There used to be a lot of other pain points where Mesa
was much more permissive than core GLES strictly allowed (e.g. GLES SL
precision qualifiers used to catch everyone out), but the compliance
changes over the past year or so have reduced the problem space to
just the extensions. So you could get close enough to testing on these
stacks with just a fairly cut-down Mesa.

*shrug*
-d