[virglrenderer-devel] How to best move forward to get GLES 3.1 guest support?

[Gert Wollny]

Hello Dave and everybody else interested in virgl,

today we at Collabora were discussing about what might be the best way
forward to get full GLES 3.1 support exposed with virgl.

It seems that most required features are already available in the
experimental tree, and that now work is needed to get this code into
shape for master before we can focus on fixing the more subtle
failures.

Ideally we would like to start upstreaming features to master in small
pieces and as independently as possible, and doing so requires us to be
able to prove that our patchsets work by running dEQP tests on master.

One of the major problems we see is that currently deqp-gles31 aborts
when run on master (and overriding the GLES version) because
GL_MAX_ATOMIC_COUNTER_BUFFER_BINDINGS, GL_ATOMIC_COUNTER_BUFFER, and
GL_MAX_IMAGE_UNITS are not available (i.e. ARB_shader_atomic_counters
and ARB_shader_image_load_store are missing), which makes it impossible
to use this test suite in a reasonable way todevelop and test on
master.

Hence, the first question would be: what would it take to get these two
extensions supported in a way that is acceptable for being included in
the master tree, and also good enough to satisfy deqp to not abort the
test run?

Then we were also wondering what we could do to get the code from the
experimental tree into shape. Since a lot of the experimental code is
written by you, Dave, this also raises the question how do we deal with
authorship when we clean up the code to make it master-ready. Do you
prefer to be the sole responsible for upstreaming your experimental
work, or would you be okay if we take care of some of it and then find
a proper way to acknowledge your original authorship?

many thanks for your comments,  
Gert