00:48 mareko: zmike: it's exposed by default
00:48 mareko: for all drivers
00:48 mareko: only iris doesn't expose it
00:48 mareko: for some gens
00:54 zmike: oh, right
00:54 zmike: pipe caps 🤕
13:34 sima: airlied, https://lore.kernel.org/dri-devel/e64f641d-44b7-4019-866d-1050277ef885@redhat.com/ that mgag200 has a really cursed cpu :-/
13:35 sima: streaming wb->wc transfers somehow destroying latency on other cores
14:04 tzimmermann: sima, jfalempe, can we please make this a kconfig parameter?
14:04 sima: I guess kconfig also works, or both
14:05 jfalempe: tzimmermann: yes, I can do a kconfig parameter if you prefer.
14:10 jfalempe: tzimmermann: would it work for you if I add DRM_MGAG200_WRITE_COMBINE, and default to n if PREEMPT_RT is set ?
15:04 sima: emersion, thx for pushing other's kerneldoc fixes!
15:04 emersion: :)
15:29 edt_: is there a way to force a reset of an amd gpu? I am on 6.7.3 with mesa 23.3
15:33 edt_: eg using /sys/class/drm/card1/device/reset ?
15:33 edt_: what do I write to the file?
15:46 tzimmermann: jfalempe, IIRC the problem got exposed by 0b34d58b6c32 ("drm/mgag200: Enable caching for SHMEM pages") ?
15:47 jfalempe: Yes, before this commit, the latency was good.
15:48 tzimmermann: the caching can already be disabled like this: https://elixir.bootlin.com/linux/v6.7/source/drivers/gpu/drm/lima/lima_gem.c#L230
15:48 tzimmermann: lima and panfrost do that for their hardware
15:50 tzimmermann: and the cleaned patch seems to be for mgag200 to have a drm_driver.gem_create_object that sets the map_wc flag
15:51 jfalempe: tzimmermann: this is what I've done on centos-stream, like this: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/3373/diffs ?
15:52 tzimmermann: jfalempe, ok. so it would be that patch
15:53 tzimmermann: and the kconfig option would depend on DRM_MGAG200 and PREEMPT_RT and maybe X86
15:53 zamundaaa[m]: edt_: sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover will do it
15:53 jfalempe: tzimmermann: ok, and the cache flush is still needed, that used to be implicit with mmap/unmap
15:54 tzimmermann: i'd hide that behind the kconfig option, even if that limits the workaround to x86.
15:54 tzimmermann: if we get reports from other architectures, we can expand the coverage
15:55 tzimmermann: i'm still no friend of all this, but everyone else disagrees. so let's at least limit the exposure of the workaround to the minimum necessary
16:00 edt_: zamundaaa[m] thanks
19:21 airlied: eric_engestrom: i though the whole idea of the vulkan job was to build vulkan bits without gallium
19:21 airlied: so why do you want to build lavapipe?
19:23 eric_engestrom: well, it does point out bugs like the "misaligned address"
19:23 eric_engestrom: but I take it the idea was to make sure none of the gallium bits need to be compiled in a vulkan driver?
19:24 airlied: sima: all cpus are cursed the same if you put a pci 1x device with slow ram and stream to it :-p
19:25 eric_engestrom: I guess instead we can add these checks to another build like `debian-testing`
19:25 airlied: eric_engestrom: yeah it was to make sure vulkan drivers were buildable standalone
19:26 eric_engestrom: ack
19:26 airlied: because it got screwed up enough times
19:26 eric_engestrom: (/me has to go now though; I'll just close the MR with a comment)
20:31 sima: airlied, you think it's just that a lot of wc writes pile up and then some other core does something which causes a flush and stall because the endpoint is just so slow?
20:31 sima: I figured wc buffer flush would only ever impact the local core, no others
20:48 airlied: sima: I think if someone else does a pci read you have to flush your wc buffers, and then the transactions jsut go slow because shitty endpoint
20:58 sima: oh the timer might need a pci read indeed and flush stuff
20:58 sima: or mmio read at least
23:30 alyssa:wonders if (('isub', ('ishl', 1, a), 1), ('inot', ('ishl', ~0, a))) would be profitable
23:30 alyssa: for !has_bfm hardware
23:30 alyssa: I guess Mali would like it
23:33 alyssa: (LLVM does this one)
23:33 alyssa: (and it's a win on CPUs)
23:35 alyssa: no changes on rob's shader-db on either m1 or g57, fun
23:38 glehmann: alyssa: that's not valid for a == 0
23:38 kisak: anyone happen to know why the configure of mesa 24.0 in i386 with intel-clc and rusticl off has a new libLLVMSPIRVLib requirement? The buildlog hints it's a change in src/gallium/targets/opencl/libMesaOpenCL.so.1.0.0
23:39 glehmann: oh, nvm, my math was wrong
23:40 kisak: (luckily it doesn't functionally matter for me since the Ubuntu i386 allowlist let me rebuild spirv-llvm-translator-15 with fresh i386 packages.
23:41 glehmann: we could try to optimize it to bfm, I'll take a look at our shaders tomorrow