<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> <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: </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: > 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. _______________________________________________ virglrenderer-devel mailing list <a href="mailto:virglrenderer-devel@lists.freedesktop.org" target="_blank">virglrenderer-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel</a> </blockquote></div>