[virglrenderer-devel] Towards gles 3.1

[Dave Airlie]

On 14 June 2018 at 01:33, Gert Wollny <gert.wollny at collabora.com> wrote:
> Am Montag, den 11.06.2018, 15:07 +1000 schrieb Dave Airlie:
>>
>> > > I'll try and drop a branch today with Gurchetan's fixes merged
>> > > into mine
>> > > and maybe a bit of cleaner history.
>> >
>> > Okay I've pushed a gl-4.5 branch to my tree[1].
>>
>> This branch is updated again, I've merged all the tess shader fixes I
>> got from CTS into that,
>
> Thanks a lot, I've now started to look closer into this focusing on
> gles31. At least one of the tests crashes qemu (still working to figure
> out which one that is) and another one crashes in the guest because of
> a bug in gallium
> (GLES31.functional.copy_image.non_compressed.viewclass_96_bits.rgb32f_r
> gb32i.texture*_to_texture*).
>
> How would you prefer syncronize the work on fixing these bugs (and
> adding new features), so that we don't do double work? One option would
> be to track the bugs in the gitlab issue tracker, another one to
> comment in the tracker bug the chromium team is using [1] (IMHO it is
> better to do a more fine grained tracking then just one bug)

I think doing it in a gitlab issue should be fine.

Now that tessellation is landed, I might back off a bit on GL until you
have a chance to get GLES3.1 into shape. I think the basic concepts
are nearly all there for compute/ssbo/images, but I suspect there is a
world of corner cases to dig ourselves out of.

For GL4.3 I think just getting texture view merged and copy image
should be things I can do if you have time to focus on the more GLES3.1
features. GL4.4 brings ARB_buffer_storage and that opens up the world
of problems that coherent memory is needed for. I'm not sure I'm going
to get to solve that myself, but it's definitely an area where we need to
try something to get an idea of what works (though it also overlaps with
Vulkan work).

I've posted some of the refactoring patches that we can land in master
and will make rebasing a lot easier, and going forward on GLES3.1
we could just work in a shared branch in the main repo and either
PRs from our private repos or just straight commits, and maybe use irc or
the issue to give advance warning if we think a rebase is needed.

I've pushed a gl-4.3 branch which is contains all the work, and that
advertises GL4.3/GLES3.1. I've removed my gl-4.5 branch and it was
mostly lies.

Dave.