00:00fdobridge: <gfxstrand> Kewl
00:00fdobridge: <zmike.> I don't think that `hardware_driver + dri3_disabled` has ever really been tested with zink and now that swrast supports dmabuf I'm not sure how much more tinkering I want to do to make esoteric paths like this work
00:00fdobridge: <zmike.> @airlied see! I told you it'd be useful!
00:01fdobridge: <gfxstrand> It's running now
00:01fdobridge: <gfxstrand> 24 hours and we should know if it passed
00:02fdobridge: <zmike.> if it doesn't I'll see about rustling up another combination of esoteric env vars for you
00:02fdobridge: <gfxstrand> Heh
01:52fdobridge: <gfxstrand> Now I'm getting `EGL_BAD_MATCH`
01:52fdobridge: <gfxstrand> `./glcts --deqp-caselist-file=gl_cts/data/mustpass/gl/khronos_mustpass/main/gl46-main.txt --deqp-screen-rotation=unspecified --deqp-surface-width=64 --deqp-surface-height=64 --deqp-watchdog=disable --deqp-base-seed=1 --deqp-surface-type=window --deqp-gl-config-id=1 --deqp-gl-context-type=egl --deqp-log-filename=../../../../reports/gl46/ampere/config-gl46-main-cfg-1-run-0-width-64-height-64-seed-1.qpa --deqp-log-images=disable --deqp-log-sha
02:22fdobridge: <gfxstrand> Yeah, looks like DRI2 doesn't like those tests for some reason. 😢
02:23fdobridge: <gfxstrand> `FATAL ERROR: Got EGL_NOT_INITIALIZED: initialize(m_eglDisplay, &major, &minor) at egluGLContextFactory.cpp:331`
03:11fdobridge: <gfxstrand> No, DRI2 just doesn't like Zink. It was trying to load nouveau.
03:12fdobridge: <airlied> are you using NOUVEAU_USE_ZINK=1 or the MESA_LOADER override?
03:14fdobridge: <gfxstrand> ALl of them?
03:15fdobridge: <gfxstrand> `NOUVEAU_USE_ZINK=1 MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=silent LIBGL_DRI3_DISABLE=1 LIBGL_KOPPER_DISABLE=1`
03:15fdobridge: <gfxstrand> I think we just need to fix DRI3
03:17fdobridge: <airlied> yeah if it doesn't work with just the first one we need to fix it
03:17fdobridge: <airlied> instead of adding move env vars
03:17fdobridge: <airlied> it's bad enough zmike thinks this is okay for fucked qcom drivers
03:17fdobridge: <gfxstrand> `./glcts --deqp-gl-context-type=egl -n dEQP-GL45-ES3.info.vendor` if you want to go digging
03:18fdobridge: <gfxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10994
03:18fdobridge: <gfxstrand> TBH, I don't think it's that bad for someone who knows how Zink ties into the window system code.
03:18fdobridge: <airlied> nobody knows that 😛
03:18fdobridge: <airlied> does it fail with BAD_WINDOW for you?
03:18fdobridge: <gfxstrand> Ah, so we're all screwed then. 😂
03:18fdobridge: <airlied> EGL_BAD_NATIVE_WINDOW rather
03:19fdobridge: <gfxstrand> That test? Yes
03:19fdobridge: <gfxstrand> It's because dri3_swap_buffers fails
03:22fdobridge: <gfxstrand> I thought Zink was supposed to be taking the swrast path when it's not kopper
03:26fdobridge: <airlied> it should take the swrast path when it is kopper
03:28fdobridge: <gfxstrand> So what does it do when not kopper?
03:29fdobridge: <airlied> should use the dri2/3 paths
03:29fdobridge: <airlied> it should never not be kopper, that path is left over hack and should be burned to the ground
03:29fdobridge: <gfxstrand> Wait, so which one is the modifiers path?
03:30fdobridge: <airlied> kopper
03:30fdobridge: <zmike.> yeah this was an attempt to get around the fact that nvk is not a software driver but also doesn't have modifiers
03:31fdobridge: <zmike.> which is entirely unique in the ecosystem
03:31fdobridge: <zmike.> I'll see if I can hack something in tomorrow I guess
03:31fdobridge: <gfxstrand> Maybe I should run on top of the modifiers branch. 🤔
03:32fdobridge: <gfxstrand> But that requires rebasing the modifiers branch
03:32fdobridge: <zmike.> I mean that would be the easier solution than having me add extra hacks to make this work for a week or whatever before you land modifiers
03:32fdobridge: <airlied> ah so kopper won't initialise without modifiers so falls back and explodes?
03:32fdobridge: <gfxstrand> We need a plan for landing modifiers. :blobcatnotlikethis:
03:32fdobridge: <gfxstrand> We still need a plan for landing modifiers. :blobcatnotlikethis: (edited)
03:33fdobridge: <zmike.> no, kopper initializes fine but then this test hits a weird path where it's expecting to be able to use a modifier-capable swapbuffers and isn't
03:33fdobridge: <airlied> no it really looks like kopper isn't initialised
03:33fdobridge: <zmike.> 🤔
03:33fdobridge: <gfxstrand> Yeah, I have no kopper
03:33fdobridge: <airlied> 948 struct dri2_egl_surface *dri2_surf = dri2_egl_surface(draw);
03:33fdobridge: <airlied> (gdb) print dri2_dpy->kopper
03:33fdobridge: <airlied> $10 = (const __DRIkopperExtension *) 0x0
03:34fdobridge: <zmike.> oh you meant the extension
03:34fdobridge: <zmike.> yes
03:34fdobridge: <zmike.> this happens when you don't have modifiers
03:34fdobridge: <zmike.> there is "kopper" and then there is "the dri kopper extension"
03:34fdobridge: <zmike.> they are not the same
03:35fdobridge: <zmike.> though previously the only case where they were not the same was lavapipe
03:35fdobridge: <airlied> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
03:35fdobridge: <airlied> index 1533c4939d9..be1a9527381 100644
03:35fdobridge: <airlied> --- a/src/egl/drivers/dri2/egl_dri2.c
03:35fdobridge: <airlied> +++ b/src/egl/drivers/dri2/egl_dri2.c
03:35fdobridge: <airlied> @@ -948,7 +948,7 @@ dri2_setup_extensions(_EGLDisplay *disp)
03:35fdobridge: <airlied>
03:35fdobridge: <airlied> extensions = dri2_dpy->core->getExtensions(dri2_dpy->dri_screen_render_gpu);
03:35fdobridge: <airlied>
03:35fdobridge: <airlied> - if (dri2_dpy->image_driver || dri2_dpy->dri2 || disp->Options.Zink) {
03:35fdobridge: <airlied> + if (dri2_dpy->image_driver || dri2_dpy->dri2) {
03:35fdobridge: <airlied> if (!loader_bind_extensions(dri2_dpy, dri2_core_extensions,
03:35fdobridge: <airlied> ARRAY_SIZE(dri2_core_extensions), extensions))
03:35fdobridge: <airlied> return EGL_FALSE;
03:35fdobridge: <airlied> that fixes it
03:35fdobridge: <zmike.> hm
03:36fdobridge: <gfxstrand> Seems to
03:37fdobridge: <zmike.> seems plausible
03:37fdobridge: <gfxstrand> I'm going to let it run overnight with that. I have no idea why it does anything useful but it seems to fix one set of tests and not immediately break everything else.
03:38fdobridge: <zmike.> I'll do some further testing on it tomorrow and rb a MR
03:38fdobridge: <zmike.> but now I need sleep
03:38fdobridge: <zmike.> wsi was a mistake
03:38fdobridge: <gfxstrand> No argument there.
03:39fdobridge: <gfxstrand> Graphics was not meant to be put on screens.
03:39fdobridge: <zmike.> amen
03:40fdobridge: <airlied> I'll go fuel the flamethrower for my fuck all those non-kopper zink paths all the way out of the tree
03:41fdobridge: <airlied> @zmike. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28707
03:41fdobridge: <airlied> for when you get some sleep
05:57ahuillet: airlied : I should be able to take a look.
09:40fdobridge: <mohamexiety> Working on that, I should be done with it by tonight or tomorrow I hope.
13:26fdobridge: <ahuillet> Rust question. I'm touching fn tu102_choose_pte_kind(format: Format, compressed: bool) -> u8 {
13:27fdobridge: <ahuillet> match pipe_format::from(format) {
13:27fdobridge: <ahuillet> in src/nouveau/nil/image.rs
13:27fdobridge: <ahuillet> I understand this is a switch-case thing where _ is C's "default"
13:27fdobridge: <ahuillet> is there a way for me to /print/ the value?
13:27fdobridge: <ahuillet> actually that's very Googleable ignore me
13:32fdobridge: <karolherbst🐧🦀> `println!("{}", value)`, but that depends if the type implements `fmt::Display`, or for `{:?}` it needs to be `ftm::Debug`
13:32fdobridge: <ahuillet> so what does ! stand for, is it because you REALLY want it to print something?
13:32fdobridge: <karolherbst🐧🦀> `!` means it's a macro
13:33fdobridge: <ahuillet> thanks :)
13:35fdobridge: <ahuillet> I kinda like my version better though
13:36fdobridge: <karolherbst🐧🦀> heh
13:38fdobridge: <mtijanic> switch/case is selling it short, it's possibly the best rust feature. If we had that, maybe we wouldn't have needed to write a custom compiler just to generate this beast: https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia/generated/g_gpu_nvoc.c#L750-L778 :)
13:39fdobridge: <mtijanic> I envy anyone writing HAL code in rust, for that alone.
13:42fdobridge: <karolherbst🐧🦀> ahh yeah...
13:50fdobridge: <marysaka> NVOC :painpeko:
13:59fdobridge: <ahuillet> what does OC stand for btw?
14:01fdobridge: <ahuillet> do you recall what failed exactly? the two listed tests in the MR? 'cause these pass with the patch I have right now
14:38fdobridge: <rinlovesyou> NV - Nvidia
14:38fdobridge: <rinlovesyou> OC Object Compiler
15:06fdobridge: <marysaka> ~~I was going to say Objective C~~
15:26fdobridge: <gfxstrand> NVIDIA Objective C: The fancy graphics API they wrote just for Apple to try and convince them to start buying their cards again.
15:29fdobridge: <rinlovesyou> haha
15:40fdobridge: <redsheep> Hell would sooner freeze over
15:45fdobridge: <zmike.> @gfxstrand how is the run going?
15:49fdobridge: <gfxstrand> 16 failures so far so at least the WSI stuff seems to be working
15:50fdobridge: <gfxstrand> `GTF-GL46.gtf21.GL.acos.acos_vec2_frag_xvary` fails
15:50fdobridge: <gfxstrand> And `GTF-GL46.gtf21.GL.acos.acos_vec3_frag_xvary`
15:50fdobridge: <gfxstrand> But not float?
15:51fdobridge: <zmike.> hm I think I remember something like those having issues many years ago
15:51fdobridge: <zmike.> but I also thought @airlied fixed them
15:54fdobridge: <zmike.> (it was test bugs)
15:55fdobridge: <zmike.> strange, they pass on radv and lavapipe...
15:56fdobridge: <zmike.> and anv...
15:56fdobridge: <zmike.> and turnip...
15:57fdobridge: <zmike.> are you on the wrong side of history? 🤔
15:57fdobridge: <gfxstrand> There's a very slight possibility
15:58fdobridge: <gfxstrand> If the GTF arccos tests are what finally finds that last compiler bug...
16:31fdobridge: <gfxstrand> @karolherbst Are you aware of any LLVM issues in F40 or any other fresh hell that might await me on upgrade?
16:31fdobridge: <gfxstrand> (Now that liblzma is fixed, that is.)
16:31fdobridge: <karolherbst🐧🦀> nope
16:31fdobridge: <karolherbst🐧🦀> I fixed llvm-18 support a while back, and somebody else fixed main
16:32fdobridge: <karolherbst🐧🦀> if there are issues, should be something minor or very recent
16:34fdobridge: <gfxstrand> sweet
16:34fdobridge: <gfxstrand> Weirdly, it's the reference shader that's broken, not our `acos()` impl
16:45fdobridge: <redsheep> Guess you were right when you said NVK has no bugs
17:09fdobridge: <zmike.> so probably the same issue as the atan tests
17:12fdobridge: <gfxstrand> What's wrong with atan?
17:14fdobridge: <zmike.> the gtf tests were broken, probably in the same way
17:15fdobridge: <zmike.> https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/3488
17:16fdobridge: <gfxstrand> Maybe?
17:17fdobridge: <zmike.> legends say that either in the past or the future @airlied has seen and fixed all bugs
17:17fdobridge: <gfxstrand> Yup! Shutting off float16 fixed it
17:17fdobridge: <gfxstrand> See! NVK has no bugs. 😛
17:18fdobridge: <gfxstrand> I'll gerrit a fix
17:19fdobridge: <zmike.> this one is gitlab
17:19fdobridge: <zmike.> not gerrit
17:19fdobridge: <gfxstrand> Oh, sweet.
17:23fdobridge: <zmike.> sort of
17:23fdobridge: <zmike.> ping me with your MR and I'll try to get it on the next cts call agenda
17:23fdobridge: <zmike.> somehow it's hard with kc
17:56fdobridge: <gfxstrand> WTH Discord?!? I guess I'm not human...
18:01fdobridge: <karolherbst🐧🦀> :blobcatnotlikethis:
18:01fdobridge: <karolherbst🐧🦀> to be fair, how can you be human with the amount of code you write each day!
18:03fdobridge: <gfxstrand> If I were an AI, would any of the code work?
18:03fdobridge: <rinlovesyou> i was about to say
18:03fdobridge: <rinlovesyou> it would be pretty obvious if it was made by an LLM, because nothing would owkr
18:03fdobridge: <rinlovesyou> it would be pretty obvious if it was made by an LLM, because nothing would work (edited)
18:03fdobridge: <rinlovesyou> :Hehe:
18:10fdobridge: <karolherbst🐧🦀> I didn't imply you are an AI, more like a vulkan god 😛
18:13fdobridge: <gfxstrand> Sometimes I'm really glad we're using discord over IRC and then sometimes this happens. 🤬
18:13fdobridge: <karolherbst🐧🦀> :blobcatnotlikethis:
18:14fdobridge: <karolherbst🐧🦀> I should try the new bridge, but for that I need to get a VPS and :blobcatnotlikethis:
18:14fdobridge: <karolherbst🐧🦀> (the new bridge looks like the matrix one, so the integration is really nice)
18:15fdobridge: <pixelcluster> goddess of vulkan, bringer of common code :frog_pray:
18:15fdobridge: <karolherbst🐧🦀> sounds like a job title
18:16fdobridge: <karolherbst🐧🦀> would be a banger business card with that on it
18:16fdobridge: <karolherbst🐧🦀> however
18:17fdobridge: <karolherbst🐧🦀> it might come around as a bit too ... dunno.. arrogant? 😄
18:24fdobridge: <zmike.> I didn't get around to https://gitlab.freedesktop.org/mesa/mesa/-/issues/10993 today but I did fix the tomb raider regression
18:25fdobridge: <zmike.> surely I will get to this next week
18:35fdobridge: <gfxstrand> Meanwhile... https://mastodon.gamedev.place/@gfxstrand/112259621301349918
18:37fdobridge: <Sid> can use my vps
18:44fdobridge: <zmike.> F
18:46fdobridge: <Joshie with Max-Q Design> What "energy requirements"
18:46fdobridge: <Joshie with Max-Q Design> I am confused, is there some policy from something where you are not allowed to disable suspend?
18:51fdobridge: <gfxstrand> I'm not sure on the details but there's some regulatory requirement which is why distros enable auto-suspend by default. It used to only apply to laptops but it applies to desktops now, too.
19:23fdobridge: <gfxstrand> Ugh... kc-cts doesn't build on F40
19:24fdobridge: <karolherbst🐧🦀> :blobcatnotlikethis:
19:24fdobridge: <karolherbst🐧🦀> new gcc error?
19:48fdobridge: <gfxstrand> Yup
19:49fdobridge: <gfxstrand> @zmike. There's two kc-cts MRs open now. One to build on F40 and one to fix the precision thing
19:56fdobridge: <gfxstrand> Now I'm running again. Woo...
19:56fdobridge: <gfxstrand> On a distro kernel, apparently. 😅
19:58fdobridge: <gfxstrand> That's not going to bite me....
19:59ad__: hi, so i just sent a v2 of ada lovelace backlight, best i can do for now
20:00ad__: the fix for proper max at 255 is https://lists.freedesktop.org/archives/nouveau/2024-April/044390.html
21:01fdobridge: <zmike.> subscribe and follow https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/5080
21:05fdobridge: <gfxstrand> Is there going to need to be a gerrit change to pull in the new kc-cts revision, too?
21:05fdobridge: <zmike.> yes
21:05fdobridge: <zmike.> but that comes after
21:05fdobridge: <gfxstrand> woo
21:06fdobridge: <zmike.> and I can maybe get someone to help us out on that since it's a one-liner
21:06fdobridge: <gfxstrand> Yeah, I'm just annoyed by the fact that his needs two round trips and the latency for anything CTS related is a minimum of 2 weeks.
21:07fdobridge: <zmike.> realistically it's longer since you're waiting on a release?
21:07fdobridge: <gfxstrand> I don't need a release
21:07fdobridge: <zmike.> or are you trying to do a conformance submission with a stack of local patches
21:07fdobridge: <gfxstrand> I can cherry-pick patches.
21:07fdobridge: <zmike.> I don't think you have to wait for the patches to be accepted to do that
21:07fdobridge: <gfxstrand> But I'm supposed to cherry-pick with -x so they need to be upstream
21:08fdobridge: <zmike.> I think technically as long as you provide justification for your patches and the relevant WG doesn't object then that's legit
21:08fdobridge: <gfxstrand> But I'm actually not sure that the kc-cts stuff is checked by the CTS scripts at all
21:08fdobridge: <zmike.> very hard to say
21:08fdobridge: <zmike.> we're looking forward to deleting kc-cts and never looking back
21:08fdobridge: <gfxstrand> So say we all
21:08fdobridge: <zmike.> unfortunately the road is still many months long
21:09fdobridge: <zmike.> but it is a road that we are progressing along
21:44fdobridge: <gfxstrand> And... I'm not human again. 🙄
21:45fdobridge: <gfxstrand> But also, I think I'm going to call it there for the week. I've got the GL CTS running on two GPUs. Hopefully I get two passes out of it.
21:46juri_: gfxstrand: you're not the only one feeling not human lately. ;)
21:47fdobridge: <gfxstrand> Lol
21:47fdobridge: <gfxstrand> I really don't want to suggest we move to matrix but damn...
21:56fdobridge: <redsheep> Am I reading into this too much or was this a Battlestar reference?
22:05juri_: not on my end. I'm just working with AIs every moment i can.. which is not making me a very good human, to start with.
22:11fdobridge: <gfxstrand> It's a Battlestar reference