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

[Dave Airlie]

On 19 July 2018 at 10:47, Dave Airlie <airlied at gmail.com> wrote:
> On 17 July 2018 at 05:53, Dave Airlie <airlied at gmail.com> wrote:
>> 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
>>> 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?
>>
>> My rough plans were to rebase down the gl-4.3 branch into a simple set of
>> patches.
>>
>> 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
>> into master,
>> 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.
>
> Okay I've got a gles3.1 branch cleaned up locally, and I'd like to get
> it into master
> in order. I won't post anything except the patches and we can
> concentrate on reviewing
> each piece of the pile in turn.
>
> Once we are happy with the ssbo patches and land them I'll post the
> image support,
> then the compute support. The branch may have some regressions vs the current
> work, but they should be trivial enough to track down I think, and I'd
> prefer to get a
> clean base landed.

I've put the patches in their formative stages in two branches

https://gitlab.freedesktop.org/airlied/virglrenderer/commits/gles31-submit
https://gitlab.freedesktop.org/airlied/mesa/commits/gles31-submit

This now contains a working framebuffer no attachments (passes deqp tests).

I don't really want to do any major development on these branches, if people
spot obvious mistakes or errors do point them out, but I'd like to just rework
the patches that are there and make them reviewer friendly and fixup commit
msgs etc.

I've got a complete deqp gles31 run from this on skylake host, I'll follow up
the results it gets.

Dave.