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

[Gurchetan Singh]

On Tue, Mar 19, 2019 at 2:48 AM Gert Wollny <gert.wollny at collabora.com> wrote:
>
> Dear all,
>
> now that with the latest patches we are actually able to expose GL 4.1
> on GLES hosts

Very nice!

> I thought that it is time to look at the limitations
> (apart from our lying about fp64)
> 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)
>  - 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)
>  - everything involving depth blits with a multisample target seems
>    close to impossible to be implemented correctly because it needs
>    the GL fallback path and resolving multisample for depth textures
>    requires information about how the depth is stored (linear or
>    inverse and in the latter case also zNear and zFar), and  Gallium
>    doesn't provide this information and likely doesn't even have
>    access to it.
>  - gl_ClipVertex is not supported, and the virglrenderer workaround to
>    translate this to gl_ClipDistance doesn't seem to cover what the
>    game "The Talos Principle" is using them for.
>  - some applications seem to have a very weird sRGB-linear handling,
>    namely Valve titles like Portal, HL2, and L4D2 all render too dark
>    on GLES (but work correctly on GL with [4] applied). It might be
>    possible to fix this by digging even deeper into it, but it seems
>    to be a real time sink, one "fix" I found regresses tests and
>    breaks other applications. On the other  hand, these games are
>    high profile and should probably be fixed somehow.
>  - for occlusion query, GL_SAMPLES_PASSED is not supported, it can be
>    faked by using GL_ANY_SAMPLES_PASSED and returning some scaled up
>    value [5], but this value may have to be tuned on a per application
>    basis.
>
> The last two points raise the question whether it would make sense to
> implement some possibility to add application specific tweaks to
> virglrenderer. On the guest side we could make use of drirc [6] and
> then send this information application dependent to the host as a
> string similar to how the debug flags are passed.
>
> In addition, I wonder whether we should set up some kind of database of
> tested applications (similar to winehq)? This could be done either in-
> tree, in the wiki, or in another repo were non-developers could also
> contribute and it would also give us some more direction in considering
> which general workarounds and application dependend tweaks are worth
> implementing.

Application specific workaround seem fine, especially when dealing
with lossly GL on GLES.





>
> many thanks for your input,
> Gert
>
> [1] h
> ttps://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/188
> [2] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/444
> [3]
> https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/196
> [4]
> https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/173
> [5]
> https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/172
> [6] https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/
>