<div dir="ltr">So the plan is to issue pull requests to the gl-4.3 branch?  That sounds good to me.  Is there a Mesa gl-4.3 Gitlab branch that we should also issue PRs for (I've found an issue that needs a guest side fix)? </div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 13, 2018 at 7:07 PM Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14 June 2018 at 01:33, Gert Wollny <<a href="mailto:gert.wollny@collabora.com" target="_blank">gert.wollny@collabora.com</a>> wrote:<br>
> Am Montag, den 11.06.2018, 15:07 +1000 schrieb Dave Airlie:<br>
>><br>
>> > > I'll try and drop a branch today with Gurchetan's fixes merged<br>
>> > > into mine<br>
>> > > and maybe a bit of cleaner history.<br>
>> ><br>
>> > Okay I've pushed a gl-4.5 branch to my tree[1].<br>
>><br>
>> This branch is updated again, I've merged all the tess shader fixes I<br>
>> got from CTS into that,<br>
><br>
> Thanks a lot, I've now started to look closer into this focusing on<br>
> gles31. At least one of the tests crashes qemu (still working to figure<br>
> out which one that is) and another one crashes in the guest because of<br>
> a bug in gallium<br>
> (GLES31.functional.copy_image.non_compressed.viewclass_96_bits.rgb32f_r<br>
> gb32i.texture*_to_texture*).<br>
><br>
> How would you prefer syncronize the work on fixing these bugs (and<br>
> adding new features), so that we don't do double work? One option would<br>
> be to track the bugs in the gitlab issue tracker, another one to<br>
> comment in the tracker bug the chromium team is using [1] (IMHO it is<br>
> better to do a more fine grained tracking then just one bug)<br>
<br>
I think doing it in a gitlab issue should be fine.<br>
<br>
Now that tessellation is landed, I might back off a bit on GL until you<br>
have a chance to get GLES3.1 into shape. I think the basic concepts<br>
are nearly all there for compute/ssbo/images, but I suspect there is a<br>
world of corner cases to dig ourselves out of.<br>
<br>
For GL4.3 I think just getting texture view merged and copy image<br>
should be things I can do if you have time to focus on the more GLES3.1<br>
features. GL4.4 brings ARB_buffer_storage and that opens up the world<br>
of problems that coherent memory is needed for. I'm not sure I'm going<br>
to get to solve that myself, but it's definitely an area where we need to<br>
try something to get an idea of what works (though it also overlaps with<br>
Vulkan work).<br>
<br>
I've posted some of the refactoring patches that we can land in master<br>
and will make rebasing a lot easier, and going forward on GLES3.1<br>
we could just work in a shared branch in the main repo and either<br>
PRs from our private repos or just straight commits, and maybe use irc or<br>
the issue to give advance warning if we think a rebase is needed.<br>
<br>
I've pushed a gl-4.3 branch which is contains all the work, and that<br>
advertises GL4.3/GLES3.1. I've removed my gl-4.5 branch and it was<br>
mostly lies.<br>
<br>
Dave.<br>
_______________________________________________<br>
virglrenderer-devel mailing list<br>
<a href="mailto:virglrenderer-devel@lists.freedesktop.org" target="_blank">virglrenderer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel</a><br>
</blockquote></div>