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: dodod]
cphealy has quit [Read error: Connection reset by peer]
cphealy has joined #etnaviv
CoLa-M1 has joined #etnaviv
<CoLa-M1> after update to Mesa 20.0.7, I see transparent surfaces rendered (well I do not see them actually :D) when using texture blitter, anybody ever saw something like this? actually, I am just using this Qt method: https://code.woboq.org/qt5/qtwayland/src/compositor/compositor_api/qwaylandcompositor.cpp.html#_ZN18QWaylandCompositor11grabSurfaceEP22QWaylandSurfaceGrabberRK17QWaylandBufferRef
pcercuei has joined #etnaviv
lynxeye has joined #etnaviv
lynxeye has quit [Quit: Leaving.]
lynxeye has joined #etnaviv
berton has joined #etnaviv
<cphealy> CoLa-M1: Which Vivante GPU are you using?
<CoLa-M1> cphealy: I have an imx6quad, thus GC2000
<marex> CoLa-M1: bump to 20.1.y
<marex> CoLa-M1: there are a few fixes and WL should work on that
<marex> CoLa-M1: can you pastebin the weston log btw ?
<CoLa-M1> well, I am not running weston but a qtwayland compositor ;)
<marex> uh, I dont think I ever tried that one
<marex> I only ever used either qt on weston or on KMS framebuffer (eglfs)
<CoLa-M1> the qtwayland compositor is running on eglfs, but the internals (linux-dmabuf) are implemented very similar to weston
<CoLa-M1> and actually, qtwaylandcompositor is more a framework to create your own customized compositor
<mntmn> (austriancoder about etnaviv at XDC2020)
<marex> CoLa-M1: I saw it at some point
<marex> mntmn: AH
<marex> CoLa-M1: I mean, I was looking into it, but I didn't find out why I would want to use that instead of weston and qt5 -platform wayland :)
<CoLa-M1> if you have an embedded hardware and your ui designer has some weird ideas for global touch gestures or window animations, it is quite helpful
<marex> CoLa-M1: is that something you cannot do with eglfs or wayland ?
<marex> pardon my ignorance
<CoLa-M1> you want to implement the effects/gestures in the compositor, so the other option is to implement them inside weston or start your own compositor
<marex> austriancoder: nice !
<CoLa-M1> it's mostly a way that makes it easy for application developers to create their own compositor, without diving too deep into the Wayland protocol internals and re-implementing Wayland functionality themselves
<CoLa-M1> I know quite a lot of automotive/embedded projects going this route
<marex> ha, OK
<marex> CoLa-M1: so anyway, mind trying the newer mesa real quick ?
<CoLa-M1> I will give it a try, sure
<CoLa-M1> but will need to wait until next week, it's a somewhat heavy change, as I have to do some yocto rebuilds for it
<marex> bitbake -c cleansstate mesa ; bitbake -C compile -c package mesa
<marex> takes really minutes
<CoLa-M1> in theory yes, in practice I have a kernel patch compiling right now and need to wait (and test) that before doing anything else
<pcercuei> mntmn: nice!
<cphealy> Regarding GC2000 in the i.MX6q, I did some benchmark comparisons using glmark2-es2 between Mesa 19.3.2 and the Vivante blob. One finding was that all the texture sampling use cases are slower with etnaviv. For use cases where compositing is being done using the 3D GPU, this is quite likely to effect performance.
<cphealy> I'm not aware of any changes that have gone in since Mesa 19.3.2 that would resolve this.
<marex> cphealy: mesa 19.3 is quite old
<cphealy> marex: You are correct. That said, I've not seen any work since then that would drive a change to texture sampling performance. I'll retest with Mesa 20.2 once it comes out though none the less.
<marex> cphealy: what makes you think the sampling performance problem is due to etnaviv, is there any difference in the sampler configuration / usage ?
<cphealy> marex: I can't answer that question. I only looked at the benchmark from a users perspective. Running the same test with the GC3000 and GC7000L resulted in similar performance to the blob driver so it seems to be unique to the GC2000.
<cphealy> In all etnaviv cases, I was running with 5.4.22 kernel and same Mesa build and same glmark2-es2 build.
<BobB3> austriancoder: I just watched your xdc presentation, very nice overview!
<BobB3> Currently it works with my WIP modifications to etnaviv for out of frame reporting at https://gitlab.collabora.com/bbeckett/linux/-/tree/etnaviv_perfmon_ioctls_master
<BobB3> The perfetto changes are waiting on testing for panfrost (I refactored the panfrost support blind, due to lack of HW). Once the panfrost support is confirmed (and fixed), and a review is done, it should be mergable
<BobB3> Regarding the perfetto work to genericise the GPU handling, you can check out my WIP branch https://gitlab.freedesktop.org/Fahien/gfx-pps/-/tree/generic-gpu
<BobB3> Regarding the etnaviv changes, I did hit a potential HW issue. When switching pipes to accumulate per pipe counters, I see dropped completion events. It seems to actually progress past a submission, but the completion event does not raise an interrupt.
<BobB3> Currently I've no idea why that would be. Initial speculation was maybe due to the switch register holding status bits written from GPU and bits for writing from CPU to change pipe. I though maybe lost updates due to both writing at the same clock, but multiple r-m-w each time didn't solve it, so presumably I am missing something else
<BobB3> I was interested to see that you stop the FE while sampling perf counters. Is this strictly necessary? would I need to do that when sampling out of band?
<BobB3> Any other ideas about the dropped completion events would be welcome!
<BobB3> My next check is going to be to refactor the sampling loop to be pipe major instead of register major to reduce the amount of pipe switching to see if it helps
<marex> agx_: are you using rsi9116 wifi in that purism phone ?
<marex> BobB3: nice :)
<dos1> marex: Librem 5 has rsi9116, that's right
JohnnyonF has joined #etnaviv
JohnnyonFlame has quit [Ping timeout: 265 seconds]
lynxeye has quit [Quit: Leaving.]
<marex> dos1: does it work well ?
<marex> dos1: that is, is the wifi stable and all ?
berton has quit [Remote host closed the connection]
JohnnyonFlame has joined #etnaviv
JohnnyonF has quit [Ping timeout: 272 seconds]