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