[Mesa-dev] [PATCH 0/4] Resolving Android + desktop OpenGL 'hack'

Emil Velikov emil.l.velikov at gmail.com
Tue Aug 30 13:48:32 UTC 2016


On 27 August 2016 at 13:04, Tomasz Figa <tfiga at chromium.org> wrote:
> On Sat, Aug 27, 2016 at 4:12 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Fri, Aug 26, 2016 at 3:01 PM, Ryan Houdek <sonicadvance1 at gmail.com> wrote:
>>> Most of the Tegra devices (K1 and above) provide desktop GL, except for the
>>> Nexus devices which cut out that functionality.
>>> Not sure how front buffers differ there, never checked.
>>> Dolphin relies on a large amount of extensions, both for performance and
>>> proper emulation standpoint..
>>> For performance, GLES 3.0, base_vertex, blend_func_extended, and
>>> buffer_storage are good enough there.
>>> For accurate emulation there are a few features that desktop GL provide that
>>> just can't be done in ES (Even 3.2, although it adds a bunch) due to the
>>> lack of a feature either in extensions or in core.
>>> I don't have a list of all the features it needs in front of me at the
>>> moment(Requires grepping the codebase to figure out what all it is using
>>> again)
>>
>> The most recent example that comes to mind is depth clamping instead
>> of clipping, available in GL 3.2 (or GL_ARB_depth_clamp), but no GL ES
>> extension available for the functionality.
>
> Okay, thanks guys for in depth explanation. Looks like it might be
> worth figuring out how to implement front buffers and enable desktop
> GL.
>
> In fact I had a patch which did that by keeping a reference to last
> back buffer and using it as front, but I doubt it's the correct way,
> since a depth buffer after being queued back to the winsys might hit
> another client.
>
> Still, I think this series does not really make anything worse. We can
> revert some of the patches as soon as someone figures out how handle
> front buffers and other are actually useful even if desktop GL gets
> enabled, like removing the config postprocessing.
>
Pretty much agree with the above:
 - Having desktop GL would be beneficial.
 - (Last time I've looked) neither the winsys nor the libEGL dispatch
was capable on handling desktop GL.

As those get fixed, we can:
 - Fix the GL dispatch in libGLES_mesa to provide the desktop GL entry
point. Should be mostly building/linking the correct bits.
 - Revert patches 1 and 3.

Thanks for the discussion all !
Emil


More information about the mesa-dev mailing list