ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
sinanmoh- has joined #zink
sinanmohd has quit [Ping timeout: 480 seconds]
<anholt_> zmike: "tilers prefer out-of-renderpass queries for perf reasons" definitely does not imply "ending the render pass so you can query outside it" is desired
<zmike> anholt_: hm?
<anholt_> zink_query.c
<zmike> ...yes, that's where queries happen? :)
<anholt_> I quoted something you said
<anholt_> which I disagreed with
<zmike> oh
<zmike> ohh yes
<anholt_> was looking at how the RP is getting split a ton in the sauer trace, which is causing a bunch of extra PCs on intel even
<zmike> I think that was just an extra note for potential future refactors
<zmike> the main issue was queries used to be mismatched and begin/end in different renderpass states
<zmike> I think the sauer trace is down to some bizarre wsi interaction though
<zmike> not sure how else to explain the massive gaps in activity
<anholt_> the idle time is definitely an issue
<anholt_> I think anv has some over-syncing that needs the equivalent of the last commit of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19309/commits
<zmike> could be
<zmike> not an anv expert
<zmike> but I suppose this is as good a time as any to try that query refactor I've been putting off
<anholt_> ok, my equivalent change from tu wouldn't help with wsi implicit syncing on i915, just a bit of cpu overhead for buffer-migration tracking.
dj-death has joined #zink
<dj-death> hey anholt_
<dj-death> zmike mentioned you have an implicit sync change for anv
<dj-death> just wondering how you remove the buffer from the execbuffer list
illwieckz has quit [Read error: Connection reset by peer]
<anholt_> but also I just concluded "<anholt_> ok, my equivalent change from tu wouldn't help with wsi implicit syncing on i915, just a bit of cpu overhead for buffer-migration tracking."
<anholt_> anv-wsi-ownership branch has the updated commit
<dj-death> anholt_: why wouldn't it help?
<anholt_> dj-death: in msm, we don't distinguish between tracking fences and implicit sync fences. so we have to get the BO entirely out of the list, or the implicit syncer will sync on the submit. it sounds like EXEC_OBJECT_ASYNC updates just a tracking fence and not any fence that would be used by an implicit sync.
illwieckz has joined #zink
<anholt_> for debugging wtf is up with wsi stalls, I really want to add data associated with MESA_TRACE_SCOPEs.
<anholt_> but trying to get at perfetto from C continues to be pain
<dj-death> oh yeah
<dj-death> I still don't get it, if the BO is removed and it was the source of over synchronization, then we should be good
<dj-death> any way not having the BO in the list is good if it's not used
<anholt_> dj-death: writing this commit was just speculation about a potential issue, since I had previously decided it was an issue for tu. then I went and looked and it sounds like it should not be one of our issues.
<dj-death> okay
<dj-death> sounded like a good lead
<anholt_> well, maybe my commit would affect android! Check out its ANV_BO_ALLOC_IMPLICIT_SYNC
<anholt_> which looks pretty bogus to me -- android's supposed to be all about the explicit sync
avane has quit [Remote host closed the connection]
avane has joined #zink
avane has quit [Remote host closed the connection]
avane has joined #zink