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

[Gert Wollny]

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. 

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.

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/