[virglrenderer-devel] Towards gles 3.1

[Gurchetan Singh]

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

On Wed, Jun 13, 2018 at 7:07 PM Dave Airlie <airlied at gmail.com> wrote:

> 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.
> _______________________________________________
> virglrenderer-devel mailing list
> virglrenderer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/virglrenderer-devel/attachments/20180615/97e9b3d7/attachment-0001.html>