00:49karolherbst: airlied: ... I debugged why optimizing libclc regresses llvmpipe perf only to find out that it didn't has the shader cache enabled in rusticl, because... llvmpipe_screen_late_init
00:49karolherbst: any suggestion on how to deal with that?
00:49karolherbst: ohh wait...
00:49karolherbst: mhhh
00:49karolherbst: I could just create the helper context before that
00:49karolherbst: let me do this then
09:19karolherbst: dcbaker: another thing: you might want to allow providing custom/additional rust flags for test targets, as you could end up with new warnings for unused code or something
10:13daniels: pls give +1 or otherwise for commit access for koike https://gitlab.freedesktop.org/mesa/mesa/-/issues/9237
10:18javierm: daniels: oh, nice to know that she is back at collabora! I would give you a +1 but I'm not a mesa developer :)
10:18daniels: javierm: <3
14:10alyssa: DavidHeidelberg[m]: I seem to have some crashing radeonsi-stoney-traces
14:11alyssa: any chance this wasn't me? because I haven't a clue how to go about debugging otherwise
14:11alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/44227882
14:12daniels: alyssa: following the link in that log to https://mesa.pages.freedesktop.org/-/mesa/-/jobs/44227882/artifacts/results/summary/problems.html
14:12daniels: then following the link in that page to https://mesa.pages.freedesktop.org/-/mesa/-/jobs/44227882/artifacts/results/summary/results/trace@gl-radeonsi-stoney@supertuxkart@supertuxkart-antediluvian-abyss.rdc.html
14:12daniels: gets you to ../src/gallium/auxiliary/nir/tgsi_to_nir.c:2027: ttn_emit_instruction: Assertion `dst->num_components == 4' failed.\
14:13DavidHeidelberg[m]: alyssa: it was you `: ../src/gallium/auxiliary/nir/tgsi_to_nir.c:2027: ttn_emit_instruction: Assertion `dst->num_components == 4' failed.` I guess :D
14:14alyssa: thanks!
14:14alyssa: oh, I see what happened
14:14alyssa: I clicked the link and it 404'd:
14:14alyssa: https://mesa.pages.freedesktop.org/-/mesa/-/jobs/44227882/artifacts/results/summary/problems.html'
14:14alyssa: since Firefox decided the following ' was part of the link
14:15daniels: ah yes
14:15daniels: there's another one in bold red without the trailing ' just beneath it
14:15alyssa: missed that one because it's low contrast and I'm colour blind ^_^
14:15alyssa: anyway, yes, I see the assert fail now
14:16alyssa: I can work with that!
14:16alyssa: thank you both for the pointers
14:16daniels: np
14:17alyssa: CI is really showing its value here
14:18alyssa: "rewrite the heart of Mesa touching every driver significantly, and only own 2 vendors hardware"
14:18daniels: yeah, traces sure are handy given the amount of real-world coverage we get from CTS
14:18alyssa: I'm a little surprised piglit didn't hit that one
14:19alyssa: meanwhile I finally set up t860 deqp locally
14:20alyssa: so ironically I have better local midgard coverage than I did when I was actually on the hook for midgard :~P
14:25alyssa: the thought of `nir_def *` is keeping me going ngl
14:28austriancoder: ci question: I rebased https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23673 to current master and want to give it a quick test with ./.gitlab-ci/bin/ci_run_n_monitor.py --target gc2000_piglit but the rebased pipeline has no etnaviv targets (since the rebase). what I am doing wrong?
14:48jenatali: austriancoder: I think the farm is/was down so it was disabled
15:54alyssa:glares at glsl_type
16:02alyssa: I just need to swap out the base type why is this thing a const *
16:05austriancoder: jenatali: only the lima farm is down atm
16:07austriancoder: if I make an unrelated change - like adding a comment somewhere in src/gallium/drivers/etnaviv and do a force push the pipeline has now a etnaviv stage
16:12jenatali: Oh, right, ci-run-n-monitor uses the fork pipeline, which gets generated based on changes since the last push, since there's not a direct compare branch like in a MR
16:12jenatali: I've been burned by that before, it's annoying
16:33alyssa: https://gitlab.freedesktop.org/alyssa/mesa/-/jobs/44237002
16:33alyssa: Ok this one I'm pretty sure isn't me *sweat*
16:35jenatali: You sure about that? Maybe the change was so potent it broke docker before it even got pulled
16:46daniels: https://gitlab.freedesktop.org/alyssa/mesa/-/jobs/44235984 hasn’t yet finished
16:53dcbaker: karolherbst: ... well that's embarrassing. The code for passing additional arguments to rust.test exists, but it's not in the listed keyword arguments so passing it will be an error
16:53karolherbst: :'(
16:56karolherbst: oh well, as long as it's there with 1.2 that's fine at least for me :D
16:58karolherbst: dcbaker: any idea what might be wrong with the stdlibc++ part? It's kinda weird, because it might also be a order of deps problem or _something_ I honestly have no idea. The current way I made it work is this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23775/diffs?commit_id=9b5baa55c7a35da9a95378891e86adecc71222ad#1017b32183f9ee3ced5bf560b2c26d256794affe_351_355
16:59karolherbst: I also have to move my C++ dep after it somehow, dunno. It also highly depends on the linker used
16:59karolherbst: usually seems to work with mold no matter what, but bfd and lld are more picky here
17:05dcbaker: Hmmmmmmmmmmmmmmmmm
17:07karolherbst: but not adding the libstdc++ dep makes it fail in either case... I also tried to use g++ as the linker but that didn't really change much
17:09dcbaker: that makes sense. I'm assuming that libstdc++ needs to be the last library linked to, or at least it needs to be linked after the other c++ libraries
17:10karolherbst: mhh.. maybe
17:13dcbaker: either way, we should just solve this in Meson and not make you do it yourself
17:13karolherbst: I agree :)
17:31karolherbst: dcbaker: btw, from CI: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/44240264#L2156
17:31karolherbst: I think `rust.test` should strip all C/C++ flags
17:31karolherbst: or something...
17:31karolherbst: it came up a few times where e.g. if you also have C sources in the deps that stuff kinda not work
17:32karolherbst: or is that already fixed? mhh
17:34dcbaker: no, it hasn't been yet. It's on my list of things to fix
17:34karolherbst: ahh okay
17:35dcbaker: Rust is finding all of our C assumptions, lol
17:35karolherbst: :3
17:42dcbaker: karolherbst: https://github.com/mesonbuild/meson/pull/11902 is a draft, needs tests but I wanted it on the milestone
17:45karolherbst: let me see if that fixes the issues :)
17:46dcbaker: I haven't even tested it, just wrote some code, so no promises :D
17:46karolherbst: it doesn't even run
17:46karolherbst: `ImportError: cannot import name 'BothLibraries' from partially initialized module 'mesonbuild.build' (most likely due to a circular import) (/home/kherbst/git/meson/mesonbuild/build.py)`
17:48dcbaker: yeah... I just fixed that
17:48dcbaker: things that were supposed to be in the T.TYPE_CHECKING: block that weren't :/
17:49karolherbst: ohh that bindgen thing also kinda came up in the past, glad that you also try to fix that one :)
17:55karolherbst: dcbaker: okay, the link_args and rust_args work perfectly it seems, not so much the libstdc++ one
17:55karolherbst: dcbaker: output https://gist.githubusercontent.com/karolherbst/ed6346ec8792d357cbdd3cb4070c6ec5/raw/605119b03705211c499579122a58f1998213d6de/gistfile1.txt
17:57karolherbst: anyway, gotta eat something
18:03dcbaker: thanks. I wonder if this is an issue that gcc can't link it and we need to use g++... I'll have to do some testing
18:07karolherbst: yeah.. just pull https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23775 and remove the libstdc++ thing
18:10alyssa: jenatali: I'm not sure what to do re: derefs
18:11alyssa: I have barely seen a deref before today and wanted to keep it that way =P
18:11alyssa: I was just trying to fix a preexisting bug in llvmpipe, sigh
18:13jenatali: alyssa: Is there a question, or just complete no idea what's going on?
18:16alyssa: Kinda #2
18:16alyssa: like I agree that this is probably broken
18:16alyssa: I just don't know what I'm to do about it :-p
18:16alyssa: (and I am several yak shaves away from where I started by now)
18:18alyssa: which reminds me I have a nir-to-tgsi bug to get to
18:57dcbaker: karolherbst: Apparently my distro doesn't package a new enough spirv-llvm-translator.... we're still at 11.x
18:57dcbaker: I did push an updated, can you see if that works now?
18:57karolherbst: oof
18:57karolherbst: dcbaker: sure you pushed?
18:58dcbaker: we did have 14.x packaged at one point, but I guess that wouldn't help now..
18:58dcbaker: no
18:58dcbaker: now I pushed
19:03karolherbst: dcbaker: yep, that seems to have done the trick
19:04dcbaker: Sweet. Another case where rust suffers from being special :/
19:55bluetail: isn't Rust communicated as the savior?
19:56psykose: supply-side rust evangelion
20:21penguin42: karolherbst: hi, just trying to get to grips with get_timestamp and whether to return a result - is nora in here as well?
20:22karolherbst: penguin42: so for get_timestamp itself it is fine to just return the timestamp or Option in case we want to make it an optional feature, but the CL API functions have to return the proper error codes. API validation should all happen inside `api/`
20:23penguin42: karolherbst: OK great, that's the way I was going - I tried to stuff a Result into get_timestamp but it looks to me like none of the stuff in that half of the code uses Result or any of the API errors
20:24penguin42: karolherbst: Another thing I wasn't sure about is you were suggesting doing *device_timestamp = *host_timestamp; - but we're using write_checked for pointer writes, do we have a read_checked as well, if not why not?
20:24karolherbst: jenatali: sooo.. one thing I was thinking about was to shortcut linking of programs with just one object, but I'm not sure if we can just skip over spirv-tools linker. Any ideas here? Otherwise I'll just try things out and see how well it goes
20:24karolherbst: penguin42: because you can't read from a null pointer and any result would be invalid
20:25karolherbst: so you could return an Option, but you can also just check for is_null()
20:25jenatali: IIRC we run the linker so that it strips the linkage annotations and removes unreachable SPIR-V
20:25karolherbst: `write_checked` point was really just to not bother with null pointer checks
20:25karolherbst: jenatali: right... but none of this matters when translating to nir, does it?
20:25karolherbst: spirv_to_nir only translates function called by the entrypoint
20:26jenatali: Well, at one point NIR didn't like the linkage annotations :)
20:26karolherbst: mhhhh
20:26penguin42: karolherbst: I guess we should probably check for the null pointers to spit out the right CL error?
20:26karolherbst: penguin42: correct
20:27karolherbst: write_checked is really just done to e.g. return the event object or other things which are not API errors, but like optional arguments
20:27penguin42: karolherbst: OK, let me see where I go with that lot
20:28penguin42: karolherbst: Switching bug; did we get the patch in which turns vectorisation on for fload4 and stuff? That made a hell of a difference for me
20:29karolherbst: not yet, I think last time I asked mareko he said he wasn't sure about the benefits. But I think that might have ment GL or maybe he just didn't see your results, dunno
20:30penguin42: karolherbst: OK, I tried to forward port it but it had got upset by an intervening patch (I think the raytracing stuff), I think I added comments on there showing the benefit so it's a clear win here
20:30karolherbst: yeah.. I've rebased it somewhere
20:30karolherbst: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/fbbbaf0acab37cb3b012a073146918432f241283
20:31penguin42: great
20:32penguin42: karolherbst: It's actually a real pain for anyone writing OpenCL to write code that will work well on different cards/stacks - you try something like the vector ops and find they make a big difference for you and then someone else comes along and says it's worse on their card/stack/phase of moon
20:32karolherbst: yeah.....
20:32karolherbst: we know the pain
20:33karolherbst: but for us it really shouldn't matter if you use vecs or not in code at least
20:33karolherbst: it's just.. uhh... vecs in CL are just wrong
20:34karolherbst: but then there are GPU ISAs doing vectors in compute, but I doubt anybody actually does that anymore
20:34karolherbst: vecs are really only useful these days to ensure that loads are all vectorized, but that's it
20:34karolherbst: I suspect in non GPU world it can look different
20:35alyssa: karolherbst: Is there any way to scalarize in vtn or something like that, so we don't need vec8+ in NIR?
20:35alyssa: I'm sure I've asked before
20:35karolherbst: but on GPUs almost everything is scalar these days
20:35karolherbst: alyssa: yeah.. this one pass I want to wire up
20:35karolherbst: what was it called?
20:35karolherbst: ohh
20:35karolherbst: in vtn?
20:35karolherbst: uhhh
20:35karolherbst: mhhh
20:35alyssa: or LLVM I guess
20:35alyssa: although that doesn't help for SPIR-V kernels
20:36karolherbst: we might be able to do it, but....
20:36karolherbst: I suspect it's not worth the effort making vtn do it
20:36karolherbst: vec5 is already a thing and I think somebody wanted a vec6 as well.. or evne higher?
20:36karolherbst: wasn't freedreno doing like vec10 stuff somewhere?
20:37karolherbst: alyssa: do we actually still have a constant cost from supporting vec8/vec16 in nir?
20:38karolherbst: I thought we kinda got rid of most of it
20:38karolherbst: ehh.. I guess the swizzle is still there...
20:42alyssa: the swizzle is massive and I want it gone
20:42alyssa: removing swizzles from NIR at this point would be a nonstarter
20:43alyssa: next best is only storing swizzles for up to k components, where k is certainly less than 8
20:44alyssa: I don't totally hate nir_alu_src having a vec4 swizzle, ignored if src->num_components > 4 (implied to be identity)
20:45alyssa: + an intrinsic to swizzle larger vectors
20:45alyssa: I think that'd probably be workable to generate in vtn
20:46jenatali: That sounds fine to me
20:46alyssa: I don't really understand what the vec5 stuff is about.
20:47alyssa: If CL were the only producer of big vectors, that plan would be straightforward, since lower_alu_to_scalar could run immediately after vtn so no other passes have to know about the big swizzles
20:47jenatali: I assumed it's for sparse resource accesses, 4-component result + 1 status component
20:47alyssa: oof. ok.
20:47jenatali: (I haven't confirmed that, just a hunch, I saw similar code in our WARP driver)
20:47alyssa: Yeah
20:48alyssa: Yeah, it's sparse, that makes sense
20:48alyssa: I would *almost* rather nir_tex_instr produce two defs for sparse
20:49jenatali: FWIW in DXIL it returns a struct
20:49jenatali: Which then you have to use intrinsics to get components out of
20:49jenatali: I could see NIR having it return an opaque single-component SSA with an intrinsic to get the 4-component result, and a different one to get the status
20:50alyssa: Oh, I kinda like that too
20:50alyssa:doesn't want to be the person to implement this though
20:50alyssa: maybe I'm just salty from being in the nir_register salt mines
20:52HdkR: Season those registers well
20:52HdkR: Salt, pepper, paprika
20:52ccr: perhaps some chili!
20:53ccr:offers a bottle of million scoville hot sauce
20:53penguin42:waits for alyssa to curry the arguments
20:53alyssa: penguin42: I'm a C programmer
20:53alyssa: all we have is water and salt
20:53alyssa: no curry
20:54HdkR: C++20 is the spice of life
20:56penguin42: it's all those crunchy <'s
20:57alyssa: mmm, piglit crashing in common code on radeonsi but not llvmpipe
20:57karolherbst: alyssa: yeah.. I strictly don't mind handling it all in vtn, or doing something smart about the swizzle. Though I do think that limiting the max components is probably the sanes way out here
20:58alyssa: karolherbst: CL requires vec16 no?
20:58jenatali: Yeah
20:58karolherbst: well yes.. but...
20:59karolherbst: if we go after CL it's going to bite us sooner or later probably :D
20:59jenatali: alyssa: Can't some hardware also do 16-component 8-bit UBO loads?
20:59jenatali: I thought that was another reason for vec16
20:59karolherbst: it's not really component based
20:59karolherbst: but more like.. bytes
20:59karolherbst: so you can just convert to higher bit size and destruct it later
21:00alyssa: yeah, that will generate ~same code as 4-component 32-bit UBO load
21:00alyssa: + unpacks
21:00jenatali: You can do ulong16 in CL though...
21:00HdkR: uint8x16_t is just a vector, you can't lie to me vec16
21:00karolherbst: sure, and we could just split it up inside vtn
21:00alyssa: jenatali: that's what we're talking about, right
21:00jenatali: Right, sure
21:01karolherbst: I just don't know how painful that might look in vtn..
21:01karolherbst: but let me check something...
21:01jenatali: I just meant you can't upconvert the bitsize of that, you have to split it into multiple instructions
21:02alyssa: jenatali: right, the question is how painful it is to do that in vtn, versus supporting Just Enough vec16 in NIR to run lower_mem_access_bit_size and lower_alu_to_scalar and nothing else
21:02jenatali: Yeah that makes sense
21:03karolherbst: mhh so spirv-tools doesn't have an option to reduce vector component size sadly :D
21:03alyssa: Speaking as the author of the only(?) NIR backend for hardware with legitimate vec16 SIMD ALU
21:03alyssa: I do not want vec16 ALU in NIR :~P
21:03karolherbst: alyssa: CL has full swizzles on vec16 though
21:04alyssa: karolherbst: So?
21:04alyssa: In the "vtn splits it up" plan, that includes dealing with the swizzles in vtn
21:04karolherbst: how would you encode that in nir if you want to optimize the space siwzzles take
21:04karolherbst: ahh right
21:04karolherbst: I meant the other plan
21:04alyssa: In the other plan, vtn inserts swizzle intrinsics for every vec16 source
21:05alyssa: (every vec16 source with a nonidentity swizzle, I mean)
21:05karolherbst: that might actually be not too bad
21:05karolherbst: soo.. we only support swizzles for 4 components, everything else has to check in the source
21:05karolherbst: if somebody _doesn't_ want to check the source, they have to lower to vec4 + thise magic vec8/16 lowering pass
21:05karolherbst: *swizzle lowering
21:06karolherbst: or it's just part of the vec lowering
21:06karolherbst: yeah...
21:06karolherbst: I think that's the path of least resistence
21:06karolherbst: we might want to ditch vec8/16 from some backends (iris, radeonsi, llvmpipe?) first I think
21:08alyssa: meanwhile I've reproduced my TTN crash
21:08alyssa: thanks to radeonsi drm-shim
21:09alyssa: so glad I set up all those aliases so I can just prefix tests with a driver name and it works :p
21:12alyssa: fp64 in tgsi-to-nir, for some inexplicable reason
21:13alyssa: fs_pack_color_zs, I guess
21:36alyssa: https://alyssa.pages.freedesktop.org/-/mesa/-/jobs/44255420/artifacts/results/summary/results/trace@gl-zink-anv-tgl@gputest@pixmark-piano-v2.trace.html
21:36alyssa: Where's the reference image? /:(
21:58zmike: you have to use your imagination
22:00Sachiel: wrong driver for imagination
22:02dj-death: alyssa: this trace is known to change hash every time we make compiler changes
22:06alyssa: dj-death: Alllright
22:06alyssa: (It's changing on zink+turnip too fwiw)
22:07alyssa: if this is a case of "inserting moves in slightly different places causes random butterfly effects that result in imperceptible hash differences", whatever
22:07alyssa: just concerned that it's a real fail and not spurious trace CI being trace CI
22:12dj-death: imperceptible indeed
22:12dj-death: on the edges
22:13dj-death: my guess it catches one edge of a triangle once, the other the next time
22:15alyssa: alright
22:15alyssa: ignore it then?
22:15alyssa: it's fine I still have this LLVM crash to deal with
22:16dj-death: once you
22:17dj-death: once you're done with the MR, update to the latest hash ;)
22:18alyssa: sounds good
22:18alyssa: I don't understand how LLVM is segfaulting
22:18alyssa: not llvmpipe
22:18alyssa: LLVM
22:20airlied: where's the explosion?
22:23alyssa: airlied: #0 0x0000ffff7c1cb71c in llvm::ConstantVector::getSplat(llvm::ElementCount, llvm::Constant*) () from /lib/aarch64-linux-gnu/libLLVM-15.so.1
22:28airlied: imma gonna need more backtrace :-P
22:29alyssa: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23089#note_1971435
22:29alyssa: dj-death: perhaps we should remove that trace then if it's known to be especially sensitive
22:34dj-death: alyssa: you should ask anholt_
22:35alyssa:shrug
22:35alyssa: If I can update the checksum for that one I don't care too much right now
22:39alyssa: airlied: to be clear, it only happens after my "gallivm: rewrite the world" commit so it's something I've changed, but I don't know how to go about debugging that appropriately named splat
22:42alyssa: --
22:42alyssa: LLVMValueRef indirect_val = lp_build_const_int_vec(gallivm, uint_bld->type, base);
22:42alyssa: indirect_val = LLVMBuildAdd(builder, indirect_val, indir_src, "");
22:42alyssa: if I comment out the second line, it compiles. so I guess I'm feeding in a bogus indir_src
22:45alyssa: uhh
22:46alyssa: inserting a cast_type to uint32 makes the crash go away
22:46alyssa: I definitely do not know enough LLVM to know why
22:48airlied: I'm guessing llvm ir validation would explode somewhere but isn't enabled
22:49alyssa: oh, that I would 100% believe
22:49airlied: have you tried with a debug mesa build?
22:49alyssa: this is debugoptimized mesa
22:49alyssa: but system llvm
22:51airlied: no try with a real debug
22:51airlied: or uncomment if DEBUG section in gallivm_verify_function
22:51alyssa: Oh, I see. Will do
22:53alyssa: airlied: Mystery solved :-)
22:53alyssa: https://rosenzweig.io/ah.txt
22:53airlied: seems sane!
22:55alyssa: llvm being typed is ridiculous
22:59alyssa: OK, kicked off another CI run
22:59alyssa: Any guesses how many regressions I've introduced since a few hours ago?
22:59alyssa: :P
23:04psykose: three
23:50karolherbst: dcbaker: ohh.. did you end up ignoring -I flags in deps? Because that's something I can't test locally really... or maybe I can? dunno... but you know, debian adds paths like "-I/usr/include/x86_64-linux-gnu" to random deps