07:04 Mangix: Oh boy. Hit a mesa bug on this 7750
07:04 Mangix: In file ../mesa-25.3.1/src/amd/compiler/aco_assembler.cpp:1283
07:04 Mangix: Unsupported opcode: v1: %48:v[16] = v_mul_f16 0x2d4c, %37:v[3]
07:04 Mangix: it appears this is a bad idea in any case. RADV_DEBUG=llvm ends up working at a glacial speed
17:36 Venemo: Mangix: please open a bug report in Mesa and add steps to reproduce
17:37 Venemo: Mangix: we don't really maintain the llvm backend anymore. it would be better to fix this in aco
17:43 glehmann: Mangix: this doesn't sound like a bug, it just looks like you are compiling a shader with fp16 and hd 7750 (gfx6) does not support that
17:44 soreau: glehmann: is fp16 mediump or..?
17:45 Venemo: fp16 = floating point 16-bit
17:46 Venemo: glehmann: how can he even compile such a shader?
17:46 soreau: well I had some gfx6-8 and using mediump meant it just defaulted to highp
17:47 soreau: so when I got my new rig, the integrated gpu actually supported mediump and I started seeing subtle bugs like degraded assumptive anti-aliasing and such. So I switched everything to highp and now things are as they were with mediump on the old RX580 card
17:48 Venemo: we should lower mediump to 32-bit in this case
17:48 soreau: https://github.com/WayfireWM/wayfire/pull/2724#issuecomment-3067242949
17:49 soreau: and it made my water effect drift as if there was wind involved
17:49 soreau: using highp fixed a bunch of stuff
17:50 Venemo: either way, I don't think this is the same problem as Mangix is seeing
17:51 glehmann: Venemo: spir-v with unsupported features
17:51 Venemo: why does it work with llvm?
17:52 glehmann: probably either promotes to fp32 or does some other emulation of fp16
17:52 glehmann: what else would it do, the hw literally only support fp32 and fp64
17:52 Venemo: yeah. I'd like to take a closer look at it
19:56 Mangix: Venemo: glehmann: this is a GLSL shader
19:57 Mangix: apparently this is the code for it: https://github.com/Artoriuz/ArtCNN/blob/main/GLSL/ArtCNN_C4F32.glsl
20:07 Mangix: [vo/gpu/libplacebo] Spent 1471.857 ms creating pipeline (slow!) yeah not doable
21:03 glehmann: Mangix: well that shader uses fp16 by default, but it has a fp32 path if you comment out https://github.com/Artoriuz/ArtCNN/blob/main/GLSL/ArtCNN_C4F32.glsl#L32
21:05 glehmann: actually all occurrences of that line
21:46 Mangix: maybe GL_EXT_shader_explicit_arithmetic_types_float16 shouldn't be listed as supported on this GPU then
22:00 Mangix: huh. I'm finding more ways to break this.
22:00 Mangix: [ 3148.259219] amdgpu 0000:0d:00.0: amdgpu: VM memory stats for proc mpv(33827) task mpv:cs0(33812) is non-zero when fini
22:00 Mangix: [ 3322.326882] amdgpu 0000:0d:00.0: amdgpu: VM memory stats for proc mpv(33942) task mpv:cs0(33927) is non-zero when fini
22:00 Mangix: [ 4227.985802] [drm:amdgpu_uvd_cs_pass2 [amdgpu]] *ERROR* Invalid dpb_size in UVD message (21348352 / 60122880)!
22:01 johnny0: Mangix: this is with the SI card?
22:03 Mangix: yeah
22:03 Mangix: kernel 6.17.9
22:05 Mangix: I got this lovely output from mpv: AV: 00:00:05 / 00:24:25 (0%) A-V: 0.010 Dropped: 1 Cache: 329s/139MBamdgpu: The CS has been rejected, see dmesg for more information (-22).
22:06 Venemo: Mangix: yeah we shouldn't support that. I don't see why it would take that code path
22:07 Venemo: I've seen the "non-zero when fini" message on various gpus, but not sure what it means
22:07 Mangix: funny thing is, I got the crash by changing in mpv.conf profile=high-quality to profile=fast
22:11 Venemo: probably another kernel bug
22:11 Venemo: at the moment I don't have a SI GPU with me
22:12 Venemo: trying to figure out how to improve page fault handling
22:13 Venemo: I'm on Strix Halo
22:13 Venemo: it turns out that the code that configures which interrupts are enabled is not even called
22:13 Venemo: and it sets some bits to intentionally crash on page faults...
22:15 Venemo: I am pretty sure if I had submitted code like that, it wouldn't have been accepted
22:15 Mangix: I know that feeling
22:16 Venemo: I got it all but working
22:17 Venemo: I am hitting some issue with schedule_work(). it only starts to process anything after the soft IH ring is filled up