On Sat, Aug 27, 2016 at 4:12 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Fri, Aug 26, 2016 at 3:01 PM, Ryan Houdek <sonicadvan...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
