13:56 <marex> BobB3: was it you who reported transparent surfaces are broken in etnaviv ?

15:16 <CoLa-M1> marex: if you mean: blitting a texture to another framebuffer and getting a transparent texture in return, that was me

15:18 <marex> CoLa-M1: on GC2000, right ?

15:18 <marex> CoLa-M1: do you have a trivial testcase ?

15:19 <marex> mntmn: there was that depth test on GC7000L problem you had, I once gave you a really simple code to replicate it, is that still available somewhere ?

15:19 <CoLa-M1> depends... I am using this method in my qtwayland compositor: https://code.woboq.org/qt5/qtwayland/src/compositor/compositor_api/qwaylandcompositor.cpp.html#_ZN18QWaylandCompositor11grabSurfaceEP22QWaylandSurfaceGrabberRK17QWaylandBufferRef

15:19 <marex> CoLa-M1: I think I might be seeing it on GC400T

15:20 <CoLa-M1> I am using a GC2000

15:20 <marex> CoLa-M1: do you also have a weston and weston-keyboard on your machine ?

15:20 <marex> CoLa-M1: what I noticed is that if I run weston-editor , there was some odd corruption of the window header

15:21 <marex> but it could be unrelated

15:21 <CoLa-M1> I could integrate it, but it is not integrated

15:21 <marex> and it was more visible when the weston-keyboard was raised

15:21 <marex> I think the keyboard does use some transparency

15:22 <CoLa-M1> if I recall correctly, the surface/texture that I want to blit is an opaque one, but I have to check

15:23 <marex> CoLa-M1: it would be nice to ahve a really simple test , like https://github.com/yuq/gfx.git

15:23 <marex> CoLa-M1: such a minimal test makes it easy to debug the issue

15:24 <CoLa-M1> could be possible... will check with my college on Monday who is currently deeper into this issue

15:31 <marex> CoLa-M1: nice, thanks !

15:35 <CoLa-M1> thanks you for this awesome driver! everytime I hit one issue here (which does not happen often), I know that I would have found at least 10x as many crashes and memory leaks in vivante ;)

15:36 <marex> austriancoder: ^

15:36 <marex> CoLa-M1: the vivante driver used to be bad, it did improve over time

15:36 <marex> CoLa-M1: but the upside really is that you can rebuild your userspace without blobs

15:36 <marex> CoLa-M1: that makes the long-term maintenance of hardware viable

15:37 <CoLa-M1> I still have quite a lot of not common use cases, which are completely valid in Wayland spec, but which triggers race conditions in vivante

15:37 <marex> CoLa-M1: which mesa are you running again ?

15:37 <marex> CoLa-M1: upgrade to 20.1.y, really ... a lot of races should be fixed there

15:38 <CoLa-M1> I know, I know :)

15:38 <CoLa-M1> 20.0.7 currently, because MSAA made the least problems in that version

15:39 <CoLa-M1> and if you are on an embedded device and exactly know your use cases, you might take the risk

15:40 <marex> CoLa-M1: ... and then someone accidentally triggers a new use case ? :)

15:40 <CoLa-M1> such new use cases go over my desk, so I am the first burning his figers :)

15:52 <marex> CoLa-M1: if the system really is closed, good ... if you have e.g. a browser, well, you have a problem anyway