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

[Gurchetan Singh]

On Wed, Jul 18, 2018 at 7:10 PM 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.

FYI here's some branches with some pretty straightforward image fixes.
Your call on whether to squash them with the initial support:

https://gitlab.freedesktop.org/airlied/mesa/merge_requests/4/diffs?commit_id=037c1aecff0f983f6e022c2529a9b8e87306a47f
https://gitlab.freedesktop.org/gurchetansingh/virglrenderer/commits/gl-4.3



> I've got a complete deqp gles31 run from this on skylake host, I'll follow up
> the results it gets.
>
> Dave.
> _______________________________________________
> virglrenderer-devel mailing list
> virglrenderer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel