01:34 jenatali: Ugh. dEQP-VK.graphicsfuzz.cov-matching-if-always-true-inside-loop hits an infinite optimization loop with nir_opt_dead_cf
01:36 jenatali: I assume there's some other pass that can get rid of the problematic pattern but I have no idea what it is
01:43 jenatali: Loop { phi; if (a) break; else break; phi }. Opt_loop doesn't make progress because the block after the if isn't empty. Opt_dead_cf tries to delete the phi but it gets reinserted
01:49 jenatali: Hm. Probably opt_remove_phis
02:35 airlied: zmike: so if I wanted to fallback to zink by failing to load nouveau, how would we do that?
02:36 airlied:tried to hack dri2.c but that wasn't the right answer :-P
02:54 airlied: uggh going to be a bit horrible to have drivers control the fallback paths
03:26 zmike: 🤕
03:26 zmike: I guess you'd probably have to do it from pipe-loader?
03:28 airlied: yeah think I have to go even higher
03:29 airlied: like createNewScreen fails, try again, just not sure how to communicate GIMME ZINK over I failed
03:33 zmike: oh
03:33 zmike: yeah that's why I said pipe-loader
03:33 zmike: there's no way to propagate an error up that many levels
03:33 zmike: well, there is, but you gotta really want it
03:42 airlied: zmike: well I tried in pipe loader but we get the wrong driver extensions
03:42 airlied: since we need the kopper extensions not the dri2 ones
03:42 zmike: that's because by then you're in dri...yeah
03:42 zmike: ugh
03:42 zmike: so I guess yeah you do have to add error reporting all the way up the stack
03:43 airlied: at least the dri interface is private now :-P
03:43 mareko: mostly
03:49 airlied: zmike: considering some sort of callback to set a magic flag :-P
03:49 zmike: 🤕🤕🤕
03:49 airlied: no idea how that would fit either
03:58 jenatali: airlied: curious why you'd fail to load nouveau? Is this an NVK-only system where nouveau could work but just wasn't built?
04:00 airlied: jenatali: no I want to explicitly use zink over nouveau
04:01 airlied: for certain ranges of GPUs
04:01 airlied: nouveau could still work, but I don't want to use it
04:01 jenatali: Oh I see, you want nouveau to opt out, essentially?
04:01 airlied: yes
04:02 airlied: ideally we could have it all wrapped into one interface and make the decision really late, but that isn't where we have appeared to end up
04:02 jenatali: Makes sense. I... don't know that code so I don't have any ideas, just curious since I've done a lot of similar things in other various layering situations
04:27 airlied: hmm even where to add the callback is fun, I suppose imageLoaderExtension makes most sense
04:36 mareko: it looks like I'm stuck with "bisecting a commit failing CI by creating and merging a MR for every bisect step"
05:08 airlied: mareko: why don't use use the ci run script?
05:09 airlied: at least avoids marging it and you can specify just the failing job
05:12 airlied: geez the whole how to we load a driver dri2/dri3/drisw/zink interactions is all kindas fucked
05:15 mareko: airlied: what's that?
05:33 airlied: ./bin/ci/ci_run_n_monitor.sh
05:34 airlied: you push the MR, then run that --target the job that is failing
05:34 airlied: you need a gitlab access token
06:50 mareko: this is how far I was able to get with it: File "/home/marek/dev/mesa/bin/ci/ci_run_n_monitor.py", line 411 ... TypeError: Gitlab.__init__() got an unexpected keyword argument 'retry_transient_errors'
06:52 airlied: did you run the .sh and it setup all the pythony stuff?
06:52 airlied: DavidHeidelberg: ^ maybe?
07:03 mareko: airlied: only .py, the .sh one prints: python: command not found
07:04 mareko: it's only python3 here
07:04 airlied: ah maybe hack that to use python3 and rerun it, the sh sets up the venv
07:04 airlied: or rather hack the bin/python-venv.sh
07:24 mareko: it's stuck here now: ⏲ for the pipeline to appear in ['mesa/mesa', 'mareko/mesa']...... (keeps adding dots)
08:07 pepp: airlied: fwiw I have a similar need for virtio native context (try native ctx/radeonsi, fallback to virgl)
08:07 pepp: airlied: see the first commit of !21658
08:21 MrCooper: mareko: there should be no need to create an MR for running the CI pipeline, let alone merge it
08:56 pq: hwentlan, sorry I forgot to cc you on https://lists.freedesktop.org/archives/dri-devel/2024-February/441285.html
10:12 airlied: pepp: at least there I think both paths should be possible using dri2 loader fallback
10:39 swick[m]: pq: just had a look, the HDMI/CTA-861 InfoFrame implies either RGB or YCC. YCC implies a conversion matrix. There is a table mapping each InfoFrame value to some transfer characteristics...
10:40 swick[m]: so, uh, yeah, I'm starting to agree with vsyrjala
10:54 pq: swick[m], TF, really? Yeah, we need a table then, including making the difference which part if done by KMS manipulating pixel values itself and what userspace needs to set up on its own.
13:45 robclark: sima, jani: https://lore.kernel.org/dri-devel/CAF6AEGvT-U1uDoSZyEZbZm2K2YPjsQagHT2Z6UJyCzOXEUhL7A@mail.gmail.com/T/#t <-- needed to unblock CI
13:45 mairacanal: KungFuJesus, I'm not sure how you compiled DXC
13:48 sima: robclark, push to drm-misc-next? I'm confused what I'm needed for
13:49 robclark: we need it in -fixes
13:49 robclark: and also.. please start using gitlab-ci on -misc ;-)
13:51 sima: well then push to drm-misc-fixes?
13:52 sima: robclark, also I guess first we'd need to have gitlab ci in drm.git ...
13:52 sima: or wherever
13:53 robclark: it would be nice to get an a-b or r-b on that patch from someone outside of drm/msm .. I think lumag or dianders could push to drm-misc-fixes
13:54 robclark: not sure how to do gitlab ci w/ dim tooling, but it would be a worthwhile thing to figure out, I think.. maybe dim stuff pushes to a staging MR and then merge via gitlab? idk
13:54 lumag: robclark, sima, I can push it after going through CI, if that's overall consensus.
13:59 sima: robclark, lumag r-b stamped
13:59 sima: I also replied that maybe with linux/cleanup.h we can now do better, but not sure
14:06 robclark: we'd have to more clearly make the body of the retry part it's own scope.. but IMO that would be worthwhile.. I'd have to think on it
14:37 dianders: robclark: happy to push it to drm-misc-fixes if it's useful, but sounds as if lumag is already on it.
17:09 abhinav__: jani Hi, can you pls let us know if v4 looks okay https://patchwork.kernel.org/project/dri-devel/patch/20240212173355.1857757-1-quic_abhinavk@quicinc.com/ ? Need to rebase based on your ack/nack
17:16 mairacanal: KungFuJesus, could you provide a gfxreconstruct trace with the error?
17:17 mairacanal: KungFuJesus, https://vulkan.lunarg.com/doc/sdk/1.3.275.0/linux/capture_tools.html
18:17 alyssa: mareko: fwiw I'm reviewing opt_varyings now
18:26 zmike: mareko: is there some reason you're unable to file cts tickets?
18:27 zmike: I guess I'll file now
18:41 zmike: mareko: you'll need to follow along and test CLs to verify that they actually fix your issues
18:53 cmarcelo: process question: couldn't reach the mesa/vkrunner maintainer (Neil) in a while (about 3 months, also tried email & reaching to other people that might be connected to him), is it OK to merge a few changes there? the repo is in the fdo gitlab.
18:53 cmarcelo: samuelig: ^
19:03 mattst88: cmarcelo: dunno how badly you want to get bpeel's ack, but it looks like he's active on mastodon still -- https://mastodon.social/@bpeel@tech.lgbt
19:05 cmarcelo: mattst88: at this point I'm happy with anyone's ack :-) but will try to communicate through mastodon.
19:05 cmarcelo: tks
19:17 alyssa: normal
21:33 llyyr: it's not possible to build anv without llvm now because of opencl stuff, is it going to stay like this?
21:34 mattst88: yes, I believe so
21:38 karolherbst: oh wow.. why didn't I see !26797 before 🙃
22:01 alyssa: karolherbst: :-D
22:01 alyssa:so proud
22:01 karolherbst: I stopped reading at "An additional benefit is that we get to write Genxml style code in opencl shaders"
22:01 karolherbst: how cursed can GL drivers ever get
22:02 alyssa: karolherbst: that was my idea ;D
22:03 karolherbst: though I still have to write my clc meta code to accelerate some buffer operations
22:03 karolherbst: like strided buffer copies
22:03 alyssa: mattst88: dj-death: dcbaker: I don't think I understand the issue with cross-builds with intel_clc
22:03 karolherbst: does GL have silly APIs like that?
22:03 alyssa: Isn't meson supposed to sort that out with native:true?
22:04 karolherbst: If I'd known 6 years ago where this "would be a fun idea to support CL through nir" would get us....
22:05 mattst88: alyssa: I'll explain in a sec
22:06 dcbaker: alyssa: we need it for both machines
22:06 dcbaker: which means building a lot of helper libs for both machines
22:06 dcbaker: which is annoying
22:06 alyssa: mmh, right
22:06 alyssa: I guess I misunderstood native:true as telling meson to do that double-building
22:07 dcbaker: yeah, that option is badly named it really should be machine : 'build' | 'host'
22:08 dcbaker: I think I finally finished writing all of the stuff I need to rewrite to fix my patches to allow subprojects for both machines, which is the first step to fixing that problem
22:08 dcbaker: cross compiling is a pain
22:10 alyssa: wheeeeeeeee
22:10 alyssa: good luck
22:10 alyssa:is a chaos agent
22:19 mattst88: yeah, tl;dr is that intel_clc needs to be built for the build machine, which will be different from the machine a cross-compiled mesa runs on
22:20 alyssa: ~~qemu user~~delet
22:20 mattst88: and since intel_clc and the mesa drivers need nir compiled, meson identifies that intel_clc is including files compiled for the host machine, not the build machine
22:24 dcbaker:is agent of order
22:24 dcbaker: hopefully I will put everything in it's proper place soon
22:24 Sachiel: not control?
22:26 dcbaker: control is an illusion
22:31 alyssa: dcbaker: we agree there