Dolphin, the GameCube and Wii emulator - Forums

GLES is supported by Intel, Nvidia and AMD on linux and if I'm not mistaken the android version has to have GLES support. Besides there might be some cases which it might be faster than the regular Opengl for some games.

(06-08-2017, 12:04 PM)M46M4 Wrote: [ -> ]GLES is supported by Intel, Nvidia and AMD on linux and if I'm not mistaken the android version has to have GLES support. Besides there might be some cases which it might be faster than the regular Opengl for some games.

OpenGLES is effectively a subset of OpenGL - the code paths for "Full OpenGL" and "OpenGL|ES" are pretty much the same.

I believe *all* desktop drivers implement their OpenGL and OpenGL|ES drivers using the same codebase.

Why does OpenGL ES exists then if it's almost the same as OpenGL?

(06-08-2017, 12:24 PM)M46M4 Wrote: [ -> ]Why does OpenGL ES exists then if it's almost the same as OpenGL?  

As it's a subset - it removes some of the rarely used/deprecated and replaced/difficult to implement features that still exist in OpenGL. It also tends to be a bit behind - For example, most of useful OpenGL 3.0 "new" features were pulled into OpenGLES 3.0. OpenGL 3.0 was released in 2008, while OpenGL|ES 3.0 was in 2012. This gives us ES guys a chance to look at which features get used by what, and can decide if they're "worth" pulling into the next ES version.

For the most part, a "modern" well written app would look no different between the two, as it wouldn't be using any deprecated or unusual features anyway.

(06-08-2017, 12:36 PM)JonnyH Wrote: [ -> ]As it's a subset - it removes some of the rarely used/deprecated and replaced/difficult to implement features that still exist in OpenGL. It also tends to be a bit behind - For example, most of useful OpenGL 3.0 "new" features were pulled into OpenGLES 3.0. OpenGL 3.0 was released in 2008, while OpenGL|ES 3.0 was in 2012. This gives us ES guys a chance to look at which features get used by what, and can decide if they're "worth" pulling into the next ES version.

For the most part, a "modern" well written app would look no different between the two, as it wouldn't be using any deprecated or unusual features anyway.

Not to mention ES just strips out a lot of niche extensions dolphin likes, which is why OpenGL 4.5 is still faster than ES3.2. With the way feature levels are broken up there is no advantage to running in ES contexts.

(06-09-2017, 08:23 AM)Nintonito Wrote: [ -> ]Not to mention ES just strips out a lot of niche extensions dolphin likes,  which is why OpenGL 4.5 is still faster than ES3.2.  With the way feature levels are broken up there is no advantage to running in ES contexts.

A big list of "Nice To Have Extensions" would probably be pretty interesting for me.

But emulators (like dolphin) often jump through hoops that may not be the same as if you were trying to get the same graphical quality on a mobile device, as they're hobbled by decisions made in the original hardware. Which means you're more likely to hit the "weird" edge cases that aren't often a priority.

(06-08-2017, 12:36 PM)JonnyH Wrote: [ -> ]This gives us ES guys a chance to look at which features get used ...

... and to start implementing them before they are core in ES. Most of them have ES extensions as well. I'm just dreaming

JonnyH Wrote:A big list of "Nice To Have Extensions" would probably be pretty interesting for me.

Our performance depends a lot on buffer_storage for persistent mapped buffers. For compatibility, we miss blend_func_extended as quite a lot hardware should support it for D3D. A few games also require logic ops, but I see why nobody is willing to implement such a crap.

Everything else should be in ES 3.2 (base_vertex for an offset in the vertex buffer, geometry shader for custom assembling, compute shaders for texture convertion).

There are additional feature request for more enhanced accuracy, but not implemented right now in dolphin:
- shader_framebuffer_fetch / fragment_shader_interlock: Custom blending to match strange hardware blending behavior or Z compression.
- conservative_rasterization: With an additional rasterization check in the shader, this will yield pixel perfect rasterization. It would also allow to merge 4 pixel in one shader execution to get perfect filtering.
- shader_explicit_vertex_parameter: With all 3 vertex data as integers, we should be able to generate bit perfect texturing as well without a passthrough geometry shader.
- parallel_shader_compile: To reduce stuttering. +1 if you manage to queue draw calls without stuttering while the compilation isn't done yet.
- sparse_buffer: This would allow us to create the physical memory mapping of a shared memory console within a single buffer, so it would simplify memory management.
- floating point rounding behavior: AFAIK GPUs support different modes eg for D3D9 and D3D10. It would be nice to query the available modes and to select them within the shader.

I see, half of this would likely be only useful for emulation, or general compute workloads. But in total this would yield a pixel perfect GPU emulation. Now we only need to find a way to accurately accumulate the GPU timing, maybe a relaxed (no return value) version of shader_atomic_counter_ops?

Dolphin will use ES on Linux already if you meet a few requirements.
1) Compile with EGL
2) Run a PC that doesn't support desktop GL
3) It'll automatically fallback to ES if the computer doesn't support GL.