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

[Tomasz Figa]

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.

Best regards,
Tomasz