13:11 adavy: q4a: found a better fix
13:12 q4a: will you show diff or push it to your branch?
13:16 adavy: it was a leftover from removing the r500 patch that reworked vs constants
13:30 adavy: q4a: I pushed after testing
13:31 adavy: also there is a new env var to easily test the emulated features don't cause regressions
13:43 q4a: 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:44 q4a: I'll try to clean mesa build
14:08 adavy: I had the fix locally and wasn't pushed somehow
14:10 q4a: same error on clean build. `ctx->base.force_emulation = driQueryOptioni(&userInitOptions, "force_features_emulation");` - need to use `driQueryOptionb`
14:11 adavy: yes I just pushed it
14:11 q4a: yep, now I see it)
14:48 q4a: adavy: btw, you got RB on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22583
14:48 q4a: will you merge it this weekend?
15:34 adavy: your RB ?
15:35 q4a: no, I'm not mesa developer).. from Filip Gawin
16:05 adavy: I'm not sure what he said means he gives his review
16:17 q4a: I think that Rb means Reviewed by. But anyway - I asked him in comment. Let's check, what he mean
16:18 adavy: q4a: After that, the unsupported features emulation can go
16:18 adavy: thanks for your help for wfog btw
16:19 adavy: not sure what I will work on next. You ?
16:19 q4a: np, thanks for your work)
16:24 q4a: 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:24 q4a: May be I can test it.
16:25 adavy: yes but that's not a bug nine can fix
16:43 q4a: 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:01 adavy: Tis there anything in the list that attracts your eye ?
17:03 q4a: adavy: I need to check - I remember something interesting, but cant find right now.
17:04 q4a: 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:08 q4a: 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:14 adavy: I'm aware of it, but it's delicate
17:16 q4a: aware of it, - it's about rb or issue 5062?
17:16 adavy: the issue
17:18 q4a: Then https://gitlab.freedesktop.org/mesa/mesa/-/issues/8845 =)
17:18 adavy: q4a: well if you wanted to do 5062 I can guide you
17:19 q4a: No.. I mostly want to see your thoughts about 5062
17:21 adavy: well is comes down to atomics
17:21 adavy: when you write or read atomics that another thread uses it can involve some flushes
17:23 adavy: so it's true that when we append to the csmt thread we use atomics when we bind resources
17:25 adavy: 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:26 adavy: gains can be obtained by reworking things so that presentation is handled in the csmt thread
17:26 adavy: Then there's stateblocks
17:26 adavy: stateblocks are a recording of states
17:27 adavy: they can be updated partially
17:27 adavy: 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:29 q4a: Thanks. I got that it's tricky..
17:30 adavy: - 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:31 adavy: 8845 will reduce the overhead in the csmt thread
17:31 adavy: 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:33 adavy: the stateblocks and the atomics thing are related
17:35 adavy: 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:35 adavy: that way you have a refcounting of the object on the main thread, but you never use this refcount in the csmt thread
17:36 adavy: this avoids several threads accessing the same variable
17:37 adavy: 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:37 adavy: 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:38 adavy: 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:38 adavy: but if the app is optimized, it almost never happens during a frame
18:01 adavy: q4a: that frightened you XD
18:01 q4a: yea)
18:06 adavy: 8845 is less delicate and will be still pretty helpful
18:09 iive: adavy, this refcount remark reminds me a bit of RCU (read copy update) ... do you think it could be used instead of atomics?
18:16 adavy: I'm not familiar with that. What can you tell about it
18:25 iive: I know kernel uses it. I've read a paper once but I don't remember much of it.
18:30 iive: 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:38 adavy: in our case, we don't need to modify
21:17 iive: well, it reminded me, because you are sending copy to the csmt thread, while the main thread keeps and modifies the original.
21:18 adavy: no, the original is not modified
21:30 adavy: iive: ok I get it the refcount is modified