00:15 anholt_: anyone know the webgl cts? how do I run a single test without hacking up a bunch of html and js?
00:32 zmike: try praying?
00:33 anholt_: https://registry.khronos.org/webgl/sdk/tests/deqp/functional/gles3/shaderoperator/unary_operator_01.html?filter=shaderop.unary_operator.pre_decrement_effect.lowp_uint_vertex was the trick
00:33 anholt_: (the underlying trick was "don't try to use google these days, just go rooting around the repository for a readme")
00:34 anholt_: however, I have to say, webgl cts failing to run stuff when shader cache is disabled: extremely rude. how am I supposed to debug webgl like this, nuke my shader cache every run?
01:04 zmike: caching is cheating apparently
02:01 karolherbst: says who
03:18 karolherbst: gfxstrand: I think we can only do opt_replace_struct_wrapper_cast _if_ the cast type matches
03:22 rmckeever: Does anyone know what these Vulkan CTS results mean?
03:22 rmckeever: Fail (occlusion, result:16, expected:48)
03:22 rmckeever: Fail (timestamp)
03:23 karolherbst: mhh.. we actually check for that, but still.. it looks a bit odd
03:23 airlied: rmckeever: the qpa has no more info?
03:26 rmckeever: I'll check
03:45 karolherbst: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21458 :(
03:47 jenatali: karolherbst: Cool, makes sense. I was brainstorming but couldn't come up with anything better really
03:48 jenatali: Unless you looked for uses to see if it's ever used with ptr_as_array and skip replacing those uses?
03:48 karolherbst: I'd rather not
03:49 karolherbst: I am sure gfxstrand has some ideas :)
03:49 karolherbst: my biggest worry is, that for most field the explicit_stride is going to be 0 and that this opt is effectively dead code with this patch
04:06 jenatali: Better dead than wrong. But better right than dead :)
09:53 kusma: Did someone forget to update some intel reference images? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21182#note_1785312
09:57 dj-death: kusma: doesn't that get checked with every MR being merged?
10:22 eric_engestrom: speaking of, how does one update the traces?
10:23 eric_engestrom: I mean, update the reference image for a trace
10:35 eric_engestrom: (to be clear, I'm not asking to go change the one for intel, but because we also have one on broadcom that needs to be updated)
10:54 daniels: eric_engestrom: edit the traces yaml file and just change the checksum to the checksum of the new one
10:56 eric_engestrom: daniels: oh right, I had missed that file (src/broadcom/ci/traces-broadcom.yml); thanks :)
10:57 daniels: np!
11:14 kusma: dj-death: I don't think every MR... But retriggering it made it pass, so I guess it's a flaky test :/
11:47 dj-death: kusma: yeah, seen it flaky before
13:56 karolherbst: dcbaker: https://github.com/mesonbuild/meson/issues/11438
14:13 hazl: i was here yesterday to ask about ds3/elden ring to see if something really weird was going on, and i reverted the uma change in bios and ran cryobyte's utilities to enable the tweaks there and it isn't locking at 45-50fps anymore in ds3. i don't know if that means there isn't something weird going on still, just that 60fps isn't actively barred by the renderer
14:16 ishitatsuyuki: good to hear you have better perf now, we also have some ongoing performance investigation on our side
14:17 hazl: that's good to hear, gpu developers are on a level i can't even pretend to understand as an amateur reverse engineer
14:47 hakzsam: could someone help to triage the a618 failures/flakes with CTS 1.3.5.0, it's basically to unstable for me (see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21390#note_1783406)? thanks!
14:50 hakzsam: cwabbott: danylo: ^
15:01 gawin: dj-death: this one can be assigned to marge? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19876
15:10 Ristovski: hazl: Given RE interesting, you are already on a good path towards understanding everything :P
15:11 Ristovski: interest*
15:11 hazl: you'd think so but the last thing i did a lot of digging into was the switch port of ff8, which afaict uses an in-house x86 interpreter running the pc release from like 2003, which i think actually did cosmic horror damage to me
15:12 Ristovski: Look at the bright side, at least it's not low level firmware you are reverse engineering lol
15:21 dj-death: gawin: huh yeah
15:26 dj-death: dumb question, how do backend compilers select the right type to execute nir_iadd() ?
15:27 dj-death: in particular the type of the sources
15:27 dj-death: is it signed or unsigned?
15:27 cwabbott: dj-death: signed and unsigned add are the same
15:27 cwabbott: the wonders of two's complement :)
15:34 dj-death: cwabbott: hm thanks
15:35 cwabbott: on qualcomm we have the ability to do a sign extension or zero extension in-place, and for that there are two different opcodes - we handle it in the backend by changing the opcode when folding in a sign extension
15:37 cwabbott: hakzsam: I don't have a usable a618 device atm, I'll try later unless someone answered your question
15:38 cwabbott: how exactly is it unstable? is the runner failing to run or are a lot of tests randomly failing?
15:38 cwabbott: if it's the former, ping anholt_, if the latter I can look into it
15:38 cwabbott: I've stabilized 1.3.4 already but haven't looked at 1.3.5 yet
15:39 cwabbott: if it's a large category of new tests that are flaking or something it's almost certainly sth dumb
15:40 hakzsam: danylo replied and suggested to mark a bunch of tests as flakes, so I will do that
15:40 cwabbott: was it all transfer queue tests that were flaking?
15:40 hakzsam: yeah
15:41 cwabbott: yeah, we can ignore those for now
15:41 hakzsam: okay, I will update and try again the "full" job
15:41 danylo: cwabbott: Do you know why they are failing? Or it needs to be investigated
15:41 cwabbott: danylo: no idea
15:42 cwabbott: almost certainly a simple fix though
15:42 cwabbott: I think they're new in 1.3.5 and I've only looked at 1.3.4
15:45 dj-death: cwabbott: I'm chasing a nir_iadd_imm(ssa=0x80000000, 0x240000000) that is generating a 0x1c0000000 instead of 0x2c0000000
15:45 dj-death: cwabbott: still not sure where the bug is, int64 lowering
15:50 dj-death: or backend
15:55 dj-death: I don't quite get lower_i2i64()
15:58 dj-death: dammit
15:58 dj-death: I'm using i2i64 instead of u2u64...
16:08 gfxstrand: karolherbst: Uh... maybe? I saw the MR, I'll take a look and give it a think.
16:08 karolherbst: I can share you the shaders if that helps
17:09 karolherbst: gfxstrand: the annoying part of the code I was hiting was, that it only looked like a cast into the inner struct by accident. The kernel was just doing a parallel copy of the struct and casted to int*, so each thread can copy 4 bytes :)
17:09 karolherbst: I think we'll be seeing more cursed code like that
17:22 Ristovski: yikes
19:06 jenatali: Wow, what a mess. D3D specs that quadrilateral lines are supposed to be 1.4 pixels wide (for no good reason) but apparently only our software rasterizer actually fully respects that, and we didn't have tests to enforce it
19:06 jenatali: Absolutely amazing
19:06 zmike: another day, another graphics calamity
19:07 jenatali: Yep
19:10 kisak: check what common driver do and change to spec to be better?
19:10 kisak: s/driver/drivers/
19:10 jenatali: I only found this out because we're already making a change to support 1.0 and I wrote a test for it
19:10 jenatali: (Because Vulkan requires 1.0 if you're not supporting wide lines)
19:34 zmike: vulkan 💪
20:38 zmike: mareko: can I get an ack on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21365
21:24 robclark: hmm, so what changed w/ new version of meson?
21:24 robclark: https://www.irccloud.com/pastebin/bfomqgSJ/
21:26 mattst88: opengl is apparently a boolean
21:26 mattst88: heh, since 2017 :)
21:30 robclark: heh, ok, opengles2/opengles1 are enabled/disabled/auto but opengl is still bool :facepalm: