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

[Gurchetan Singh]

On Thu, Jul 19, 2018 at 1:25 AM Dave Airlie <airlied at gmail.com> wrote:
>
> On 19 July 2018 at 13:53, Gurchetan Singh <gurchetansingh at chromium.org> wrote:
> > 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
>
> Is anyone else seeing mem corruption in deqp?
>
> I was getting completed runs, applied a few of these, now it dies mid run.
>
> Dave.

Actually, I haven't done a full run with these applied.  I guess they
can wait until after this branch lands and further testing on my part.

> >
> >
> >> 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