14:21robclark: karolherbst: was tgamma brokenness also a libclc thing?
14:22karolherbst: robclark: yes
14:22robclark: is there a PR?
14:22karolherbst: robclark: build from here if you want to have it fixed: https://gitlab.freedesktop.org/karolherbst/mesa-libclc
14:22robclark: ð
14:22karolherbst: robclark: it's fixed in llvm-23 and 22 is EoL
14:22karolherbst: but 23 has other problems soo...
14:23karolherbst: anyway.. I'm considering having the fork above which will have branches with known issues fixed, etc.. and some build system changes to make use of it or something
14:27robclark: ok, that works for me
14:32robclark: hmm, I think that fixed fp16 tgamma but not fp32?
14:33karolherbst: robclark: works for me on all the other drivers at least
14:34mareko: have you tried running gpu-ratemeter on nvidia
14:34robclark: hmm, this _used_ to pass for me w/ 3.0 cts... idk if it changed in newer cts
14:34mareko: nvk vs nvidia
14:35mareko: it's also a benchmark of spreadsheet SW because the pix subtest produces 300k results
14:37karolherbst: Mel has a patched ratemeter but we used it to compare performance of shader vs 2D vs copy for copies and fills
14:37karolherbst: also compared with nvidia, but they kinda seem to do magic
14:38mareko: try draw vs compute for clears and copies
14:38karolherbst: the shader isn't the issue, it's more about compression, etc..
14:39karolherbst: we still haven't wired up all the compression bits afaik
14:40karolherbst: well draw vs compute will or might also make a difference
14:40karolherbst: robclark: might need https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43140/diffs?commit_id=512a5bdea0ff248ce12e0e85609e1961e1dc92c2 if you don't clear the shader cache
14:42robclark: oh, that could be..
14:42mareko: compute might be able to take advantage of all memory bandwidth and compression might amplify it, while draws are likely to underutilize memory bandwidth because the pixel pipeline might not have enough fixed-func throughput in HW
14:42karolherbst: robclark: the problem is that even on iris I get 15.99 ULPs and we need to be below 16.0 ...
14:43karolherbst: soo it could be that your hw is a tiny bit too imprecise somewhere
14:48robclark: hmm, still get:
14:48robclark: https://www.irccloud.com/pastebin/FyGA3qma/
14:50karolherbst: mareko: yeah could be.. but we do hit memory limits in draws at least. We know that 2D doesn't have enough hw to meet memory bandwidth. But we also do e.g. buffer copies on compute shaders. Not sure what's the status with using compute also for image copies, but I think Mel ran into issues where compute was slower
14:50karolherbst: but we also have the issue that we can't alternative 3D and compute without stalling the hardware
14:50karolherbst: *alternate
14:51karolherbst: but I think nvidia uses primarily compute there
14:51mareko: RTX 5090 has 1.42 TB/s of 32bpp pixel throughput, but 1.792 TB/s of memory bandwidth according to wikipedia, and that's a public example where pixel throughput is lower by design
14:52karolherbst: yeah not saying that you are wrong in terms of raw bandwidth, but due to whatever reasons compute wasn't necessarily faster than 3D for us. There might be other perf issues somewhere
14:53mareko: for buffer copy, doing byte loads/stores could be a bottleneck, try 4x32 loads/stores and try to make each subgroup lane 0 store address to be 256B-aligned
14:54karolherbst: yeah I don't know what the meta shaders is doing, because it wasn't me who looked into this
14:55mareko: we also have tiling-specific and memory channel optimizations in our image copy shaders
14:55karolherbst: at least for buffer copies we use compute and seem to be able to match nvidia
14:56karolherbst: mareko: are you aware of any games that are pretty sensitive to those being slow?
14:57mareko: yes, buffer uploads between draws
14:57karolherbst: we have a few where the perf gap is bigger and we were able to close some gaps with doing meta instead of the copy engine
14:57mareko: the target is paper bandwidth, the closed driver might be slower
14:57karolherbst: well for buffer uploads using shaders isn't necessarily faster for us, because we also have inline uploads for smaller copies which are faster
14:58karolherbst: but anyway.. more interested in testing this with real games and see if we can close some gaps
14:58karolherbst: so would be good to know which are more sensitive to it
15:00mareko: see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43096
15:00karolherbst: mhhhhh
15:00karolherbst: we know that our copy engines is faster than PCIe afaik
15:00karolherbst: but maybe I should double check that
15:02karolherbst: but yeah I have access to wolfenstein 2 at least
15:02karolherbst: thanks
15:06karolherbst: robclark: mhh yeah that looks like arithmetic precision at least...
15:07karolherbst: so what stands out is that it's doing a lot of fmad... let me check something...
15:08robclark: fp is the gift that keeps on giving
15:08karolherbst: yeah.. I wonder if the impl relies on fma precision somewhere implicitly...
15:09robclark: we aren't fused, so could be?
15:10robclark: unrelated, also getting CL_IMAGE_SLICE_PITCH fails (./images/clGetInfo/test_cl_get_info).. idk if that is known issue already? That and nir_validate fail in test_printf but that might be related to the 64b+32b-offset address mode that recently landed
15:11karolherbst: "ERROR: tgamma: -17.062418 ulp error at -0x1.ef7ep-1 (0xbf77bf00): *-0x1.f7c08p+4 vs. -0x1.f7c0a2p+4" mhhh...
15:11karolherbst: with fmad instead of ffma_weak for mad...
15:12karolherbst: but what's interesting is, that lp has a very low ULP
15:12karolherbst: but also fails implementing mad as fmad, not ffma ð
15:12karolherbst: robclark: mind replacing all "__clc_mad" with "__clc_fma" inside clc/lib/generic/math/clc_tgamma.inc and see if that helps?
15:17robclark: karolherbst: yup that works, in specific:
15:17robclark: https://www.irccloud.com/pastebin/ZlE2CyvN/
15:17robclark: (also had to change the #include)
15:18karolherbst: ohh right..
15:18karolherbst: robclark: given that fma is _pretty_ expensive, mind checking if it's needed for all or just some?
15:18robclark: so yeah, seems to be ffma vs mad.. idk if _all_ need to be changed
15:18robclark: ok, I'll see if I can narrow it down in a bit
15:19karolherbst: cool, you can submit an MR against the repo.. though I guess it's also needs fixing for the 23 version...
15:19karolherbst: let me check if there has been a fix I didn't pull
15:19karolherbst: nope.. it's the same impl as on main
15:37karolherbst: robclark: not sure what's wrong about CL_IMAGE_SLICE_PITCH, seems to work fine on iris
15:38karolherbst: mhh
15:38karolherbst: maybe ...
15:38karolherbst: what's the error you are seeing?
15:56robclark: karolherbst: a bunch of ERROR: CL_IMAGE_SLICE_PITCH mismatch for image type CL_MEM_OBJECT_IMAGE2D (flags=0x4 slice_pitch=0): expected 0, got 114821
15:56robclark: if you're not seeing that, I'll debug further, just wanted to make sure it wasn't known issue first
15:57karolherbst: mhhhhhh
15:57karolherbst: yeah... I think that's just stale stack memory in the CTS...
15:57karolherbst: maybe.. dunno
15:57karolherbst: I think there was an odd bug somewhere
15:58karolherbst: robclark: but technically the spec says we should return 0 even if the application passes a non 0 value in...
16:00karolherbst: robclark: probably fixed by this: https://gist.github.com/karolherbst/45493092e1c4328095b0c0790791c3c6
16:03karolherbst: not sure why I only did this for 1D ones...
16:05robclark: hmm, there was also: ERROR: CL_IMAGE_SLICE_PITCH mismatch for image type CL_MEM_OBJECT_IMAGE2D (flags=0x4 slice_pitch=0): expected 0, got 459284 ... although I'm not seeing that now (but I also pulled in patches from the MR you pasted)
16:06robclark: oh, nm, I'm still seeing that one two
16:06robclark: (multiplied by all formats)
16:08karolherbst: robclark: okay.. if you can check if the linked patch helps I can MR it
16:10robclark: karolherbst: yup, the gist you pasted fixes them all
16:10robclark: not sure why you don't see that on other drivers, but fix is t-b
16:10karolherbst: the CTS allocates things on the stack in those tests I think..
16:11karolherbst: so I think it's just luck
16:11robclark: ahh, test UB?
16:12karolherbst: noooooot sure
16:12karolherbst: I think applications can leave the value undefined
16:13karolherbst: CL_IMAGE_SLICE_PITCH is just image_slice_pitch of the image_descriptor the image was created with and I think it's not illegal to not have it 0 if not supported by the type
16:14karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43200
16:14karolherbst: ohh we are reaching 43210 soon
16:14robclark: :-)
16:15robclark: for clc tgamma, I guess I can drop the double case... since we don't support that.. but no idea if double actually requires the same treatment
16:15karolherbst: you can do RUSTICL_FEATURES=fp64 but that could be hopelessly broken
16:16karolherbst: ehh wait
16:16karolherbst: it will be because we have no fp64 fma emulation...
16:16karolherbst: soo...
16:17robclark: well, also blows up in ir3
16:17karolherbst: at least it's optional in CL.. but libreoffice requires it for it's CL acceleration....
16:17robclark: idk if there is a way some way to for llvmpipe mad vs fma? Might be a convenient way to test..
16:17karolherbst: *its
16:18karolherbst: robclark: yeah.. but fma isn't wired up in llvmpipe so far
16:19robclark: hmm, then it should have same tgamma fail?
16:19karolherbst: atm we only use llvm.fmuladd.* which can be either
16:19karolherbst: nah.. so CL mad becomes ffma_weak and llvmpipe keeps ffma_weak around, and that gets translated to "llvm.fmuladd" which is "might be fused, but might also be unfused if that's faster"
16:20karolherbst: so I'm sure it's going to fail on CPUs without fma..
16:20karolherbst: but at least on my CPUs it passes
16:21robclark: no way to force it to unfused?
16:21karolherbst: it could also fail on other drivers if the backend decides to unfuse ffma_weak
16:21karolherbst: mhh well..
16:21karolherbst: yes and no
16:21karolherbst: it does fail on lp if I implement mad as fmad (which is always unfused)
16:21karolherbst: but we don't really have a way to force it through an env variable
16:22karolherbst: or something
16:22robclark: right, I was thinking we should have a debug env var flag
16:22karolherbst: *well always unfused for nocontract, etc...
16:22karolherbst: yeah.. maybe
16:22karolherbst: sooo
16:22karolherbst: there is a path
16:23karolherbst: maybe.. dunno...
16:23karolherbst: I'll have to think about it..
16:24karolherbst: but I think I prefer a frontend flag and pass it through the codegen somehow..
16:24robclark: I was mostly just thinking of having a way to CI libclc itself
16:25karolherbst: yeah...
16:25karolherbst: that would help, but it's also a big painful depending on how far we want to go there
16:26robclark: or at least easier repro/debug when you don't have specific gpu hw
16:27karolherbst: robclark: we do have the CTS in CI now: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42073 so might be interesting to wire that up for freedreno
16:28robclark: true
16:30robclark: hmm, the "quick" tests still take some time.. IIRC the just exclude the allocation tests?
16:31karolherbst: yeah.... but it is what it is
17:07robclark: karolherbst: fwiw, I narrowed down a bit the tgamma thing.. basically dropped double (no way to test).. and just kept ffma when 3rd component was not const. (Also, all the failures seemded to be the ax<16.0 case so dropped the others)
17:07robclark: https://www.irccloud.com/pastebin/8Le6Iwl7/
17:10karolherbst: robclark: ahh nice, then the shader shouldn't be all too terrible..
19:22rupansh: Hello, I am working on venus support for windows and have made significant progress. I am trying to do zero-copy scanouts with SET_SCANOUT_BLOB, however in qemu it seems to assume LINEAR layout for scanouts and OPTIMAL layouts is not supported at all. Is this intentional? I understand this may be a venus, virglrenderer, or qemu issue so feel free
19:22rupansh: to redirect me to an appropriate channel if this is not the appropriate channel to discuss this
19:40anonymix007[m]: rupansh: there's already more than one Venus port for Windows, including my draft MR. Any reason to not use those? There's no need to do blob scanouts actually, you can get away with 3d resources.
20:12rupansh: anonymix007[m]: I was not aware of their current status, and I was interested in a rust implementation myself. I have Doom 2016 running at max fps and FireStrike DX11 working (but via Indirect Display, not directly scanned out to qemu). can you describe a bit how i can display 3d resources?
20:43anonymix007[m]: VIRTIO_GPU_CMD_SET_SCANOUT works for 3d resources. Anyway, you may want to take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38731 for more details.
20:49anonymix007[m]: I have quite a bit more stuff which isn't public yet (but planned to be released soon-ish), including a completely new KMD (some spoilers: it's written in Rust and is full WDDM2 driver, so both render and display functionality works), and the current goal is a better D3D UMD. I already have all the puzzle pieces ready, it's just a matter of assembling them together.
20:52rupansh: alright thanks, i think i have your virtiogpu for reference but it was using WDDM 1.3, while i was doing wddm 2.1 (and render-only in the beginning) so i stopped referencing it at some point
21:03anonymix007[m]: WDDM2 is not that different from 1.3 unless you want to advertise MMU support. Otherwise it's basically the same