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

[Dave Airlie]

On 19 July 2018 at 12:10, Dave Airlie <airlied at gmail.com> wrote:
> 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.
>

Test run totals:
  Passed:        21435/36139 (59.3%)
  Failed:        662/36139 (1.8%)
  Not supported: 14026/36139 (38.8%)
  Warnings:      16/36139 (0.0%)

Dave.