15:48 adavy: q4a: hey
15:49 adavy: I don't think except checking the terminal you can use the hud to see if you got nine or not
15:49 adavy: at some point there was discussion to add some nine statistics to the hud, that would have enabled it, but it wasn't done
15:51 adavy: what is the call that crashes your trace ?
15:51 adavy: I'm afraid I won't be able to run the trace for at least a week
15:57 q4a: adavy: Hi. "add some nine statistics" - ok
15:58 q4a: about crashing trace - I think, that problem was related to Wine version. Last stable Wine works good.
16:02 q4a: Is there any idea/guide to hack/fix mesa? Is better to analyze trace or just debugging if I have source code of engine+mesa and can reproduce problem booth in apitrace and engine?
16:06 q4a: And thanks for your work! I'm glad to see some upcoming stuff like this: https://gitlab.freedesktop.org/axeldavy/mesa/-/commits/unsupported_features_emulation/
16:06 adavy: which can of bug do you want to hack/fix ?
16:06 adavy: *kind
16:07 adavy: I have my ideas on what can be improved ofc, but I think all the easy stuff is already done
16:07 q4a: like this one https://gitlab.freedesktop.org/mesa/mesa/-/issues/8341
16:08 adavy: okay for this one here is how I would proceed:
16:08 adavy: . Trace that is very fast to run to the problem
16:08 adavy: . Get a system for which the trace works
16:09 adavy: . Filter in the qapitrace all the calls beginning with Draw
16:10 adavy: Pick a frame, do a search for the first Draw call where your render targets or textures look different when playing side by side the trace on the system that works, and the trace on the system that doesn't work
16:11 adavy: . When you found a call with a difference, note it, and then just to be sure continue a bit the search on random draw calls before to make sure the issue was not previously
16:12 adavy: . In particular compare the texture inputs are the same, except if the texture looks like the result of previous frame. Ofc this one differs, and it shouldn't impact current result
16:12 adavy: Sometimes hacks are needed in order to see all texture inputs, the depth buffer, the render target, etc. The ones apitrace cannot display are not shown
16:14 adavy: Once you find the draw call with the issue, inspect the shaders (can be fixed function shaders), the render states. Basically look at all things that would be non standard. If you find something non standard, verify it's not unactive because some other states disable it
16:15 adavy: Then look at the code if the support for the non standard stuff is correct. Eventually adding some debug info (printf) to check the paths taken and the variable values are those that make sense according to what the draw calls expects
16:16 adavy: also if you trace plays differently on different drivers/hw (all with nine), it could be nine using gallium api incorrectly, or in a different way than the ogl path, that the driver wouldn't support correctly
16:17 q4a: "playing side by side the trace on the system that works, and the trace on the system that doesn't work" - I can run same trace with 2 Wine prefixes: with Nine enabled and with disabled. If I see different result in frame, then I need to continue with Draws?
16:17 adavy: For switching between the systems, I can use two wineprefixes, for example one with dxvk or wine ogl, and one with nine. Or switch everytime I launch the draw call on the other qapitrace handle
16:18 q4a: Cool. Thanks. I'll try tomorrow.
16:18 adavy: Basically yes, find a frame number that is fast enough to play, where you see clearly the issue, and stick to it
16:19 adavy: then look for the first draw call with discrepancy
16:20 adavy: Once you find it, you can remove the filter to only see Draw* calls, and look at the calls before it more carefully
16:21 adavy: You can also compare with nine debug
16:21 adavy: for example replay the trace in a log file with wine d3dapitrace.exe thetrace.trace -D numberofdrawcall &> mylogpath
16:21 adavy: with the env vars NINE_DEBUG=all csmt_force=0
16:22 adavy: csmt_force=0 disables threading, which makes the log more readable
16:22 adavy: comparing the log and the calls made you can check for discrepancies
16:23 adavy: for example the log will print the key for the shaders used
16:23 adavy: and you can check for them in the log, to see if they are correctly interpreted
16:24 adavy: this is typically useful if fixed function is used
16:25 adavy: btw mylogpath will have a lot of (usually) useless info at the end, you need to remove everything after the last draw call. The locks, etc are to extract the texture contents to display in qapitrace
16:27 adavy: for the issue you are looking for, it could be alpha blending, fog, or some issue with the shaders
16:30 q4a: Thanks a lot! You gave a lot of useful information.
20:12 q4a: My CI fixes for wine-nine-standalone was not so good, but anyway it was fixed by Andre Heider. There is another tweak - this time about switching d3d9.dll
20:12 q4a: https://github.com/iXit/wine-nine-standalone/pull/147
20:23 adavy: I thought such a thing was already done
20:59 q4a: Yes.. I was also surprised when he deleted my d3d9.dll