Surkow|laptop has quit [Remote host closed the connection]
senquack has quit [Ping timeout: 258 seconds]
Surkow|laptop has joined #etnaviv
Surkow|laptop is now known as Surkow
senquack has joined #etnaviv
pcercuei has quit [Quit: bbl]
<lynxeye>
austriancoder: Since the 20.3 branching slipped a bit I hope to still land the ZSA fixes in time. Do you expect to have some time to take another look at the updated last patch?
<mntmn>
btw i will test the zsa patch later today, sorry i didn't have time yet
<lynxeye>
mntmn: I'm already pretty confident that it works as intended. ;) I've tested this on multiple GPU generations in the meantime, to make sure I didn't break anything.
<lynxeye>
mntmn: But testing with a real app, i.e. KiCad, instead of simple test application would be much appreciated, as we now dynamically switch between early and late Z as needed.
<marex>
lynxeye: which zsa fixes ?
<marex>
lynxeye: the gc7000 ones ?
<lynxeye>
marex: yep
<marex>
lynxeye: btw did you notice the etnaviv performance generally isnt all that great recently ?
<marex>
lynxeye: I wonder if its the locking, some ftrace might be needed
<lynxeye>
marex: I haven't seen any real issues on the platforms I care about, however the resource hash tracking is really eating a good CPU time chunk.
<marex>
lynxeye: well that entire code is a bit ... could use improvement (thats also where the locking happens)
<lynxeye>
I guess we should just get rid of the possibility of a single resource being pending in multiple contexts. Get back to the simple list head in the resource and flush conflicting contexts, even if the conflict is just a read conflict.
<lynxeye>
My guess is that being able to have a resource pending for read in multiple contexts is not getting us anything GPU performance wise, but eats CPU time.
<lynxeye>
marex: And the CPU time isn't just a guess. I've seen the mesa hash functions show up near the top in a perf trace.
<mntmn>
lynxeye: ok cool
<marex>
lynxeye: try webgl demos in qtwebengine
<marex>
lynxeye: try webgl demos in qtwebengine >= 5.12
<marex>
lynxeye: then you will see failure
<lynxeye>
marex: What failure? Removing this resource can be pending for read in multiple contexts optimization will not in any way affect the correctness added by your locking patches. If at all it will cause some more flushes.