[virglrenderer-devel] How to best move forward to get GLES 3.1 guest support?
airlied at gmail.com
Mon Jul 16 19:53:00 UTC 2018
On 17 July 2018 at 03:45, Gert Wollny <gert.wollny at collabora.com> wrote:
> 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
> 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
> 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?
My rough plans were to rebase down the gl-4.3 branch into a simple set of
One each adding shader support for ssbos, images, atomics, and compute shaders,
then renderer support for those, and enables etc.
I think we are likely at the place where we should be getting all this
I'm currently unlikely to get to this until later this week or early
next, but I think I can
at least prepare the first wave of it, and then we can figure out the in between
bits once the core is in master.
More information about the virglrenderer-devel