00:50 zf: I'm encountering a problem on radeonsi where adding "invariant gl_Position;" to a shader causes artifacts. this is bizarre since, if I'm not misreading, nothing anywhere in mesa actualy cares whether a variable is invariant or not. does anyone have any hints or guesses as to what may be going on here?
00:55 JoshuaAshton: zf: Invariant will disable certain optimizations on a path to the result of that variable such that any two shaders with the same shader code producing that variable will produce identical outcomes
00:55 JoshuaAshton: Looks pretty implemented to me?
00:56 zf: I'm fully aware of what invariant does
00:56 zf: as far as I can tell, on mesa, invariant is implemented, it sets a boolean field "invariant" to true; that's propagated to nir and tgsi, there's a pass to propagate it to dependent stores, but nothing actually *interprets* it
00:58 zf: presumably because the default behaviour is as if it's always set. that's fine, but then it's baffling that adding that declaration makes a difference
00:59 JoshuaAshton: The glsl -> nir interprets that, same as the Vulkan path, no?
00:59 zf: interprets how?
01:01 zf: it sets the equivalent nir attribute, but I can't find any consumer of nir that consumes that attribute in turn
01:01 zf: same with tgs
01:01 zf: *tgsi
01:02 cwabbott: invariant and precise are turned into "exact" in NIR here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/glsl/glsl_to_nir.cpp?ref_type=heads#L1589
01:03 JoshuaAshton: It marks it as exact in nir_propagate_invariant
01:03 JoshuaAshton: Oh cwabbott beat me, it also does it on the glsl side it seems
01:03 zf: ahhh, I'm just blind, thank you
01:03 cwabbott: yeah, nir_propagate_invariant is for spir-v
01:04 JoshuaAshton: If GL drivers are not running nir_propagate_invariant, does thatt mean GL SPIRV is broken? :-)
01:04 cwabbott: I think mesa/st should be doing it?
01:04 cwabbott: if nothing does it then yeah, it's broken
01:05 JoshuaAshton: Doesn't seem like it
01:05 cwabbott: you have to do it early, before any optimizations
01:05 cwabbott: so it would have to be in mesa/st
01:05 zf: sorry for the noise :x
01:05 cwabbott: idk if it's run automatically by spirv-to-nir, maybe it is?
01:06 JoshuaAshton: Doesn't seem like it's run by anything but Vulkan drivers grepping
01:19 alyssa:wonders if transform-feedback-uniform-buffer-object piglit is bogus
01:20 alyssa: missing glMemoryBarriers, I think...?
01:22 alyssa: ditto for spec@ext_transform_feedback@immediate-reuse*
01:51 karolherbst: mhhhh
01:51 karolherbst: what pass is supposed to scalarize vectorized load_scratches and why does it sometimes not happen :D
01:54 karolherbst: mhhhh
01:55 karolherbst: looks like it's nir_lower_mem_access_bit_sizes messing up
01:56 karolherbst: `div 16 %166 = @load_scratch (%19 (0x3)) (align_mul=256, align_offset=3)` yo.. pain
01:57 karolherbst: and that gets lowered to a 32x2 load_scratch thing.. mhh
01:57 karolherbst: I mean.. yes, but also.. no
03:27 karolherbst: uhhh...
03:27 karolherbst: I think our scratch memory lowering needs to be smarter
03:27 karolherbst: but this code is also cursed
03:44 karolherbst: gfxstrand: we might want to align scratch memory a bit less optimal in lower_explicit_io, I've encountered a kernel where it has u8[3] arrays, but the first two components are loaded as a 16 bit value, which leads to unaligned accesses if two of them are after each other (like 2 u8[3] arrays) and the second one causes the nir shader to do a 16 = load_scratch(0x3) access...
03:45 karolherbst: but the source code is also heavily obfuscated, so no idea if we mess it up by ignoring some alignment or something else is going wrong here ...
03:46 karolherbst: but that also let us ran into a intel backend compiler bug, so there is that...
04:39 jenatali: karolherbst: yeah, seems like a tradeoff between consuming less memory vs providing better alignments. Sounds like a hard problem to solve
06:34 karolherbst: jenatali: it sounds more like an optimal placement problem, but yeah...
08:04 luc: hello, i notice that mesa pbo upload fs disallows any pipe_texture_target other than PIPE_BUFFER(0) while download one allows others. https://elixir.bootlin.com/mesa/latest/source/src/mesa/state_tracker/st_pbo.c#L602
08:08 luc: i wonder if there is any technical reason why we don't upload other texture targets (e.g. 2D_ARRAY) in pixel buffer. or it is just no such use case
08:43 karolherbst: jenatali: the biggest problem is just, that the source code is so obfuscated, that I can't tell if those 8 bit arrays even exist or if something else is going on 🙃
08:49 karolherbst: mhhh...
08:49 karolherbst: maybe it's an union thing...
13:59 alyssa: karolherbst: why does llvm not like 16-bit math
15:09 jenatali: alyssa: in what context?
15:13 alyssa: jenatali: clc is turning 16-bit math into 32-bit math + piles of conversions
15:13 alyssa: wheee
15:14 jenatali: That... sounds wrong
15:14 alyssa: wheeeeeeeee
15:15 jenatali: What kind of math? Basic arithmetic?
15:19 alyssa: Yes
18:31 mareko: luc: PBO is a buffer, not a texture
18:31 mareko: the source is a buffer, the destination is a texture
19:21 karolherbst: alyssa: I guess it depends on the code and what LLVM does with it
19:22 karolherbst: but yeah.. LLVM is sometimes.. a bit silly
19:22 karolherbst: I _hope_ it becomes better with the LLVM SPIR-V backend
19:22 karolherbst: then we can also enable optimizations
19:22 karolherbst: and I know that LLVM has some to reduce the bit size as well
19:24 karolherbst: but libclc is also implementing some 32 bit ops using 64 bit math, so there is that as well
19:39 mareko: I'm considering removing AMD from the CI again and this time for real because the libdrm upgrade isn't progressing
19:40 mareko: and it's been almost 2 weeks
19:42 karolherbst: That's fine, though I'd be careful with making statements which could be read as "I'm disappointed nobody did the work I need during holiday season". People where on vacation and wanted to take time of, so I wouldn't hold them against it if they didn't want to work on stuff
19:56 mareko: you are making incorrect assumptions
20:00 mareko: when bug fixes depend on the latest libdrm, and libdrm isn't possible to upgrade, then hard choices have to be made
20:02 mareko: that's made after all other options have been exhausted
20:02 mareko: it's really a fuckup of the CI maintainers making it hard to upgrade libdrm in the first place
20:05 mareko: it was not a fuckup, it was a lack of communication between Mesa developers and CI developers because Mesa developers who understand how things work don't often review CI changes, so CI developers unknowingly made the wrong choices
20:06 mareko: or decisions
20:10 mareko: there is nobody to blame for anything, shit just happens
20:17 karolherbst: yeah.. and I'm also not saying that it's not a pain. It's fine to disable the CI if that makes you fix the bug in the short term and we can enable it later
20:17 karolherbst: I just would be careful about expecting people to work during holiday season
20:33 mareko: upstream never sleeps
21:27 emersion: mareko: what makes libdrm difficult to upgrade?
21:36 mareko: emersion: gitlab CI uses libdrm from the distro instead of building it
21:36 emersion: ah, i see
21:36 mareko: can't update libdrm if the distro doesn't do it, which is sully
21:36 mareko: silly*
23:03 DavidHeidelberg: emersion: WIP, I haven't forgot.
23:03 DavidHeidelberg: I just having issue with some weirdness on ppc64 and s390x, otherwise it's resolved
23:05 DavidHeidelberg: (weirdness different dependencies)