13:11adavy: q4a: found a better fix
13:12q4a: will you show diff or push it to your branch?
13:16adavy: it was a leftover from removing the r500 patch that reworked vs constants
13:30adavy: q4a: I pushed after testing
13:31adavy: also there is a new env var to easily test the emulated features don't cause regressions
13:43q4a: hm.. builded `unsupported_features_for_merge` and got crash at start: `NineTests: ../src/util/xmlconfig.c:1287: driQueryOptioni: Assertion `cache->info[i].type == DRI_INT || cache->info[i].type == DRI_ENUM' failed.`
13:44q4a: I'll try to clean mesa build
14:08adavy: I had the fix locally and wasn't pushed somehow
14:10q4a: same error on clean build. `ctx->base.force_emulation = driQueryOptioni(&userInitOptions, "force_features_emulation");` - need to use `driQueryOptionb`
14:11adavy: yes I just pushed it
14:11q4a: yep, now I see it)
14:48q4a: adavy: btw, you got RB on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22583
14:48q4a: will you merge it this weekend?
15:34adavy: your RB ?
15:35q4a: no, I'm not mesa developer).. from Filip Gawin
16:05adavy: I'm not sure what he said means he gives his review
16:17q4a: I think that Rb means Reviewed by. But anyway - I asked him in comment. Let's check, what he mean
16:18adavy: q4a: After that, the unsupported features emulation can go
16:18adavy: thanks for your help for wfog btw
16:19adavy: not sure what I will work on next. You ?
16:19q4a: np, thanks for your work)
16:24q4a: I would like to test features emulation on arm rk3588. So I need to merge all nine patched + rk3588 mesa changes. About nine - I can see many comment here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8716
16:24q4a: May be I can test it.
16:25adavy: yes but that's not a bug nine can fix
16:43q4a: ah.. then I'm ready to help with anything else: https://gitlab.freedesktop.org/mesa/mesa/-/issues/?sort=created_date&state=opened&label_name%5B%5D=nine&first_page_size=50
17:01adavy: Tis there anything in the list that attracts your eye ?
17:03q4a: adavy: I need to check - I remember something interesting, but cant find right now.
17:04q4a: BTW: Filip Gawin said that it's rb) Yes. I'm not a d3d9 expert, but from graphics perspective this makes sense to me.
17:08q4a: I found.. https://gitlab.freedesktop.org/mesa/mesa/-/issues/5062 - I'm sure, that I can't handle it, but I would like to take your attention and may be you will say your thoughts abut this suggestions
17:14adavy: I'm aware of it, but it's delicate
17:16q4a: aware of it, - it's about rb or issue 5062?
17:16adavy: the issue
17:18q4a: Then https://gitlab.freedesktop.org/mesa/mesa/-/issues/8845 =)
17:18adavy: q4a: well if you wanted to do 5062 I can guide you
17:19q4a: No.. I mostly want to see your thoughts about 5062
17:21adavy: well is comes down to atomics
17:21adavy: when you write or read atomics that another thread uses it can involve some flushes
17:23adavy: so it's true that when we append to the csmt thread we use atomics when we bind resources
17:25adavy: there's also another issue is that we wait for the other thread at the end of a frame, while other don't (wined3d for example). I think windows waits, according to the doc, and it makes sense that if the app fetches the window it gets its most recent result. However when we use thread_submit=true (which I think is the default now) we this is not true anyway
17:26adavy: gains can be obtained by reworking things so that presentation is handled in the csmt thread
17:26adavy: Then there's stateblocks
17:26adavy: stateblocks are a recording of states
17:27adavy: they can be updated partially
17:27adavy: they are a bit tricky to optimize, but there are ways to reduce the amount of commands sent to the csmt buffer when the stateblock is applied
17:29q4a: Thanks. I got that it's tricky..
17:30adavy: - no more atomics shared between main and csmt thread - swapbuffers on the csmt thread - optimized stateblocks -> all these would reduce overhead in the main thread
17:31adavy: 8845 will reduce the overhead in the csmt thread
17:31adavy: it reduces cpu usage overall, which can help the game, memory bandwidth, and also it will help when the main thread was faster than the csmt thread
17:33adavy: the stateblocks and the atomics thing are related
17:35adavy: basically one way to optimize is to create csmt objects. You create a command to create an object that csmt only will manipulate. Be it a resource, a set of states, etc. When you are finished with this object (texture was deleted, stateblock is deleted) you send a command to delete the object
17:35adavy: that way you have a refcounting of the object on the main thread, but you never use this refcount in the csmt thread
17:36adavy: this avoids several threads accessing the same variable
17:37adavy: and you can still manipulate what is passed to the csmt thread in the main thread or the csmt thread outside of the encapsulator object
17:37adavy: this avoids a lot of rework (no need to defer texture deletion to the csmt thread like is suggested in the issue, etc), while having the same gain
17:38adavy: the drawback is that you still have overhead due to manipulating atomics in several threads when a texture, resource, etc is actually deleted by the app
17:38adavy: but if the app is optimized, it almost never happens during a frame
18:01adavy: q4a: that frightened you XD
18:01q4a: yea)
18:06adavy: 8845 is less delicate and will be still pretty helpful
18:09iive: adavy, this refcount remark reminds me a bit of RCU (read copy update) ... do you think it could be used instead of atomics?
18:16adavy: I'm not familiar with that. What can you tell about it
18:25iive: I know kernel uses it. I've read a paper once but I don't remember much of it.
18:30iive: i think it's a bit like cow of btrfs. when you modify structure, you make a new copy of it. the old one remains for the threads that still use it.
18:38adavy: in our case, we don't need to modify
21:17iive: well, it reminded me, because you are sending copy to the csmt thread, while the main thread keeps and modifies the original.
21:18adavy: no, the original is not modified
21:30adavy: iive: ok I get it the refcount is modified