austriancoder changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://freenode.irclog.whitequark.org/etnaviv
pcercuei has quit [Quit: dodo]
_whitelogger has joined #etnaviv
JohnnyonFlame has quit [Read error: Connection reset by peer]
_whitelogger has joined #etnaviv
okias has joined #etnaviv
pcercuei has joined #etnaviv
Net147 has quit [Quit: Quit]
Net147 has joined #etnaviv
karolherbst has quit [Quit: duh 🐧]
karolherbst has joined #etnaviv
<marex> BobB3: was it you who reported transparent surfaces are broken in etnaviv ?
<CoLa-M1> marex: if you mean: blitting a texture to another framebuffer and getting a transparent texture in return, that was me
<marex> CoLa-M1: on GC2000, right ?
<marex> CoLa-M1: do you have a trivial testcase ?
<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 ?
<marex> CoLa-M1: I think I might be seeing it on GC400T
<CoLa-M1> I am using a GC2000
<marex> CoLa-M1: do you also have a weston and weston-keyboard on your machine ?
<marex> CoLa-M1: what I noticed is that if I run weston-editor , there was some odd corruption of the window header
<marex> but it could be unrelated
<CoLa-M1> I could integrate it, but it is not integrated
<marex> and it was more visible when the weston-keyboard was raised
<marex> I think the keyboard does use some transparency
<CoLa-M1> if I recall correctly, the surface/texture that I want to blit is an opaque one, but I have to check
<marex> CoLa-M1: it would be nice to ahve a really simple test , like https://github.com/yuq/gfx.git
<marex> CoLa-M1: such a minimal test makes it easy to debug the issue
<CoLa-M1> could be possible... will check with my college on Monday who is currently deeper into this issue
<marex> CoLa-M1: nice, thanks !
<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 ;)
* CoLa-M1 had to use vivante before...
<marex> austriancoder: ^
<marex> CoLa-M1: the vivante driver used to be bad, it did improve over time
<marex> CoLa-M1: but the upside really is that you can rebuild your userspace without blobs
<marex> CoLa-M1: that makes the long-term maintenance of hardware viable
<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
<marex> CoLa-M1: which mesa are you running again ?
<marex> CoLa-M1: upgrade to 20.1.y, really ... a lot of races should be fixed there
<CoLa-M1> I know, I know :)
<CoLa-M1> 20.0.7 currently, because MSAA made the least problems in that version
<CoLa-M1> and if you are on an embedded device and exactly know your use cases, you might take the risk
<marex> CoLa-M1: ... and then someone accidentally triggers a new use case ? :)
<CoLa-M1> such new use cases go over my desk, so I am the first burning his figers :)
<marex> CoLa-M1: if the system really is closed, good ... if you have e.g. a browser, well, you have a problem anyway
JohnnyonFlame has joined #etnaviv
JohnnyonFlame has quit [Read error: Connection reset by peer]
okias has quit [Remote host closed the connection]
flto has quit [Remote host closed the connection]
JohnnyonFlame has joined #etnaviv