Hi, On 20 March 2014 20:27, Eric Anholt <[email protected]> wrote: > Daniel Stone <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
