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

[Dave Airlie]

On Tue, 19 Mar 2019 at 19:48, 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 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)
>  - 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.

I'm not against app specific workloads, but they'd have to be a pretty
obviously sustainable thing.

Really I think this should all be app not test workload driven, if we
can identify an application that we want to support and uses any of
the above features, then we should try and implement something for it,
but we shouldn't be driven by chasing CTS/piglit numbers here at all.

Like I'd like to fix Talos, as the clipvertex stuff should work.

> 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.
>

Maybe a wiki of non-working apps, or just an issue tag for apps.

Dave.