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

[Dave Airlie]

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