<div dir="ltr">Most of the Tegra devices (K1 and above) provide desktop GL, except for the Nexus devices which cut out that functionality.<div>Not sure how front buffers differ there, never checked.</div><div>Dolphin relies on a large amount of extensions, both for performance and proper emulation standpoint..</div><div>For performance, GLES 3.0, base_vertex, blend_func_extended, and buffer_storage are good enough there.</div><div>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.</div><div>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)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 25, 2016 at 10:53 PM, Tomasz Figa <span dir="ltr"><<a href="mailto:tfiga@chromium.org" target="_blank">tfiga@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 26, 2016 at 1:06 PM, Ryan Houdek <<a href="mailto:sonicadvance1@gmail.com">sonicadvance1@gmail.com</a>> wrote:<br>
> Dolphin Emulator does ;)<br>
<br>
Do we really have any devices that provide desktop OpenGL? If yes, any<br>
idea how front buffers are implemented there? Android's windowing<br>
system is quite specific and in my understanding it generally provides<br>
only a back buffer to the producer.<br>
<br>
What are the specific features that Dolphin relies on? Are they<br>
missing even on newer versions of OpenGL ES (3.0/3.1)?<br>
<br>
Best regards,<br>
Tomasz<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Thu, Aug 25, 2016 at 4:47 PM, Tomasz Figa <<a href="mailto:tfiga@chromium.org">tfiga@chromium.org</a>> wrote:<br>
>><br>
>> Hi Emil,<br>
>><br>
>> On Fri, Aug 26, 2016 at 1:07 AM, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>><br>
>> wrote:<br>
>> > Hi all,<br>
>> ><br>
>> > While in the area, I've noticed an odd behaviour (and somewhat of a bug)<br>
>> > in the egl/android code.<br>
>> ><br>
>> > Namely: although we allow binding the EGL_OPENGL_API we explicitly clear<br>
>> > the OPENGL_BIT for all the configs at eglInitalize time.<br>
>> ><br>
>> > I've reworked things in a less(?) hacky way, although there's the<br>
>> > question of - is any of that needed and should we bother all together.<br>
>> ><br>
>> > IIRC on the dispatch side desktop GL isn't supported by libGLES_mesa.so<br>
>> > (which is essentially libEGL.so with a fancy name).<br>
>> ><br>
>> > Tomasz, is desktop OpenGL a thing for ARC ? Can you check with<br>
>> > someone from the team(s) on the above.<br>
>><br>
>> AFAIK nothing in Android really cares about desktop OpenGL.<br>
>><br>
>> For the complete series:<br>
>> Reviewed-by: Tomasz Figa <<a href="mailto:tfiga@chromium.org">tfiga@chromium.org</a>><br>
>><br>
>> Thanks,<br>
>> Tomasz<br>
>> ______________________________<wbr>_________________<br>
>> mesa-dev mailing list<br>
>> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
>> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>