[virglrenderer-devel] State on Desktop GL on GLES and possible directions from here

[Erik Faye-Lund]

Just some more detail on a few of these (inline)

On Tue, 2019-03-19 at 10:48 +0100, Gert Wollny wrote:
> Dear all, 
> 
> now that with the latest patches we are actually able to expose GL
> 4.1
> on GLES hosts I thought that it is time to look at the limitations
> (apart from our lying about fp64) and consider ways how to deal with
> them.
> 
> When running piglits, the CTS for OpenGL 3.3, 4.0, and 4.1, and some
> applications and games the following limitations came to light:
>     
> Not supported on GLES: 
>  - glPolygonMode, could be emulated but it would need unpacking
>    the geometry etc. If a shader program doesn't have a GS shader
> one 
>    could probably do the work there. 
>  - glPointSize, could be passed as uniform and assigned to
> gl_PointSize
>  - provoking vertex, it may be possible to handle this in the client 
>    by reordering the vertices
>  - GL_ARB_seamless_cube_map, could be emulated by a normal 2D
> texture 
>    but this is probably not worth the effort 
>  - shadow1DArray lookup with bias is not supported: we emulate 1D
>    texture arrays by using 2D texture arrays, and there is no 
>    equivalent for float texture(sampler1DArrayShadow, vec3, float)
>    with a 2D shadow array sampeler (Maybe 1D texture arrays could be
>    emulated by using a 2D texture)
>  - nonperspective (linear) interpolation for shader inputs is not 
>    supported (one might be able to emulate this by setting z=const 
>    in VS, pass the real Z on)

We'd need to modify W for this, not Z. But doing so will affect *all*
varyings, which isn't what we want. So there's some more work to it; we
might have to generate barycentric coordinates and perform perspective
correction and interpolation manually for all varyings or something
like that. Hopefully we can come up with something simpler, though.

>  - transform feedback 3 is not available, so we can only use the 
>    default stream (0), 
>    * ARB_gpu_shader5 (GL 4.0) requires a minimum of 4 streams 
>    * ARB_transform_feedback3 actually allows MAX_VERTEX_STREAMS=1,
> but
>      this must be communicated to the guest (fix: [1,2]).
>  - imageLoad and imageStore on the same image work only for r32f,
>    r32ui, r32i, all other image types must be declared either as
>    readonly or writeonly on GLES.  The result  with the CTS and
> piglit
>    is that tests with rgba32* images fail because the shaders don't
>    compile. A possible workaround could be to emulate rgba32* image
> by
>    using r32* images with "width*4" and rewriting the access code,
> the
>    question is whether this is actually worth the effort.
>  - LogicOps are not supported, but they can be emulated when 
>    EXT_framebuffer_fetch(_non_coherent) is available [3]
>  - With ARB_texture_rg tests are failing because it is not supported
>    as read-back format (Erik is currently looking into problems with 
>    reading back from textures in GLES and is also touching this area)

Yeah, this is the work here (also needs some mesa patches, linked in
the MR):
https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/191

The actual problem is quite a bit worse than this, but it's currently
being masked by mesa being out of spec and allowing any non-compressed
format to be read back as itself. This isn't allowed by the OpenGL 3.2
spec, and will likely bite us if we test on other implementations
before this work lands.