02:29 fdobridge: <g​fxstrand> Ah. Yeah...
09:14 fdobridge: <a​irlied> now I can't get lotsa flakes at all, even built a new kernel, will try on turing tomorrow
09:59 fdobridge: <m​aba_kalox> @gfxstrand stupid question, I have read through your post about vulkan driver dev (https://www.collabora.com/news-and-blog/blog/2022/03/23/how-to-write-vulkan-driver-in-2022/), and there you mentioned that there is almost no reason to implement vulkan v1.0, as implementation can be auto filled from vulkan v1.1, then why do we track vulkan v1.0 implementation?
09:59 fdobridge: <m​aba_kalox> @gfxstrand stupid question, I have read through your post about vulkan driver dev (https://www.collabora.com/news-and-blog/blog/2022/03/23/how-to-write-vulkan-driver-in-2022/), and there you mentioned that there is almost no reason to implement vulkan v1.0, as implementation can be auto filled from vulkan v1.1, then why do we track vulkan v1.0 implementation, if we will implement v1.1 anyways ? (edited)
10:00 fdobridge: <m​aba_kalox> @gfxstrand stupid question, I have read through your post about vulkan driver dev (https://www.collabora.com/news-and-blog/blog/2022/03/23/how-to-write-vulkan-driver-in-2022/), and there you mentioned that there is almost no reason to implement vulkan v1.0, as implementation can be auto filled from vulkan v1.1, then why do we track vulkan v1.0 implementation? (edited)
10:01 fdobridge: <m​aba_kalox> Or is it like a milestone? And the plan is to implement later version of vulkan that much, that auto generated vulkan 1.0 is fully implemented?
10:01 fdobridge: <m​aba_kalox> Or is it like a milestone? The plan is to implement later version of vulkan that much, that auto generated vulkan 1.0 is fully implemented? (edited)
10:03 fdobridge: <m​aba_kalox> @gfxstrand stupid question, I have read through your post about vulkan driver dev (https://www.collabora.com/news-and-blog/blog/2022/03/23/how-to-write-vulkan-driver-in-2022/), and there you mentioned that there is almost no reason to implement vulkan v1.0, as implementation can be auto filled from vulkan v1.1(1.3?), then why do we track vulkan v1.0 implementation? (edited)
13:18 fdobridge: <g​fxstrand> In terms of the tracker bugs? Its just a nice way to break up features and maybe provide a bit of order to them.
13:19 fdobridge: <g​fxstrand> Most of the features that are currently tied to a core version are going to go really quick once I finish up NAK.
13:19 fdobridge: <m​aba_kalox> I see, thanks 8)
14:11 fdobridge: <g​fxstrand> @maba_kalox you were asking for something to work on... Want to take a crack at https://gitlab.freedesktop.org/mesa/mesa/-/issues/9642 ? It's a good entrypoint (*giggle*) into Vulkan driver development.
14:11 fdobridge: <g​fxstrand> @maba_kalox you were asking for something to work on... Want to take a crack at https://gitlab.freedesktop.org/mesa/mesa/-/issues/9642 ? It's a good entrypoint (*giggle*) into Vulkan driver development. (edited)
14:13 fdobridge: <g​fxstrand> IDK that it'll make much difference in Zink perf (NVK's state flush is fast) but it's always good to try and keep @zmike happy. 😅
14:48 fdobridge: <m​aba_kalox> I have no idea how to make it, but I am interested! I will take it.
14:48 fdobridge: <m​aba_kalox> I have no idea how to make it, but I am interested! I will take it 8) thanks! (edited)
14:53 fdobridge: <m​aba_kalox> Side question, a have heard that there is some work in making nouveau(kernel) use GSP, and that would allow to match proprietary driver performance (at least, limiting factor would not be kernel-space driver) - can you suggest, where I can check status of this effort? (I was able to find only some outdated posts)
14:57 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Currently hwmon and display output support are missing
14:58 fdobridge: <e​sdrastarsis> Display output works for me
15:01 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I mean displays that are connected to the NVIDIA GPU
15:01 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Unless that got fixed recently
15:03 fdobridge: <k​arolherbst🐧🦀> that should work
15:04 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> It didn't the last time I tried GSP
15:04 fdobridge: <k​arolherbst🐧🦀> I tried it like a month ago with the update to 535 I think
15:06 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> How about hwmon though?
15:09 fdobridge: <k​arolherbst🐧🦀> yeah, probably doesn't work, but should be fairly easy to wire up
15:48 fdobridge: <e​sdrastarsis> It's working, I'm using HDMI (TMDS)
15:49 fdobridge: <e​sdrastarsis> I've been using nouveau gsp for a month on a daily basis, I think I'm insane
15:49 fdobridge: <e​sdrastarsis> how exactly?
15:50 fdobridge: <k​arolherbst🐧🦀> by doing the RPC calls necessary to retrieve the info from GSP
15:51 fdobridge: <k​arolherbst🐧🦀> the problem will be overhead though, so not sure if we can have hwmon initiate those RPC calls directly
15:52 fdobridge: <k​arolherbst🐧🦀> dunno... but at least GSP has interfaces for this kinda stuff, just didn't look into it in great detail if there is also a mechanism to share memory with GSP to just have update values on the fly or something
16:05 fdobridge: <k​arolherbst🐧🦀> anyway, Ben's tree contains dumps of the GSP relevant code with some header files describing all the RPC calls and structures (kinda)
17:08 fdobridge: <g​eorgeouzou> I played a bit with a very WIP implementation of EXT_shader_object:
17:08 fdobridge: <g​eorgeouzou> Pass: 62238, Fail: 377, Crash: 158, Skip: 179188, Flake: 1, Duration: 2:47, Remaining: 0
17:10 fdobridge: <g​eorgeouzou> I return the input spirv code as binary for now 🤣
17:10 fdobridge: <g​eorgeouzou> I played a bit with a very WIP implementation of EXT_shader_object:
17:10 fdobridge: <g​eorgeouzou> CTS tests for shader-object.txt
17:10 fdobridge: <g​eorgeouzou> Pass: 62238, Fail: 377, Crash: 158, Skip: 179188, Flake: 1, Duration: 2:47, Remaining: 0 (edited)
17:34 fdobridge: <g​fxstrand> That's not a bad plan. 😂 @phomes signed up for pipeline caching and that's going to involve figuring out proper serializing. The two of you are going to be sort-of stomping all over each other, I'm afraid, so probably best to coordinate some.
17:37 fdobridge: <g​eorgeouzou> Of course! I will leave the serializing part for now then and focus on making this work semi-ok!
17:43 fdobridge: <g​eorgeouzou> Ok i added an very WIP MR. First of all, all state should be dynamic and some refactoring is needed where pipeline layouts are used in nir_lowering etc...
17:44 fdobridge: <g​eorgeouzou> One thing that is a little odd is that this extension does not use a pipeline layout at all, but CmdBindDescriptorSets needs one..
17:55 fdobridge: <a​irlied> The gsp branch had broken DVI monitor for me, I hacked up a patch to fix it
18:03 dakr: @gfxstrand: In case you don't follow the conversation: https://lore.kernel.org/dri-devel/9072642e-f4f6-4ff1-e11f-9bda8730750c@redhat.com/
18:26 fdobridge: <a​irlied> Maybe it makes sense to report a max to userspace and split it there then
18:33 dakr: @airlied: Yes, absolutely. However, I think the max should be as large as possible. The problem is more that the scheduler always accounts for the max rather than the actual size.
18:34 dakr: Which again limits the max size artificially..
19:45 anholt: nak folks: anyone have rust-analyzer working with vscode?
19:46 fdobridge: <g​fxstrand> dakr: Yeah, Cristian is working with a mental model that just doesn't apply to NV hardware.
19:47 fdobridge: <g​fxstrand> anholt: I've never used either.
19:51 anholt: apparently it's just 'rust-analyzer.linkedProjects": [ "build/rust-project.json" ] ' thanks to dcbaker.
19:51 fdobridge: <g​fxstrand> I think it's reasonable to have to split in userspace somewhat. But I also don't want to artificially lower the limit to workaround gpu/sched
20:30 karolherbst_: anholt: yeah, should be enough
20:30 karolherbst_: just need some new enough meson generating that file
21:02 fdobridge: <s​amantas5855> https://www.phoronix.com/news/NVIDIA-Lock-Broken
21:02 fdobridge: <s​amantas5855> pretty huge
21:06 fdobridge: <e​sdrastarsis> I don't think this would help Nouveau, it seems illegal
21:07 karolherbst_: ehh.. it's just about modyfing the vbios
21:08 fdobridge: <a​irlied> might help reverse engineering but not fw
21:08 fdobridge: <k​arolherbst🐧🦀> yeah.. the thing is.. on GPUs where the unknown bits are useful are also the GPUs we can mess with the VBIOS
21:09 fdobridge: <k​arolherbst🐧🦀> the vbios contains a lot of reclocking related stuff, but it's pointless if we can't reclock
21:09 fdobridge: <k​arolherbst🐧🦀> for the display related stuff we can poke nvidia to get proper documentation as we already got some: https://nvidia.github.io/open-gpu-doc/DCB/DCB-4.x-Specification.html
21:47 fdobridge: <i​llwieckz> Would there be ways to let the users do things themself, but then, if it's done, nouveau can benefit from it?
21:47 fdobridge: <i​llwieckz> Like, if some tools exist in the wild that can modify and upload some vbios, and by some incredible luck, the modification would make things easier for nouveau (what a luck!), would it be OK for the code in Mesa repository to recognize the patched vbios is there and do things that can be done when such modified vbios is in place (so much unexpected luck, again!)?
21:47 fdobridge: <i​llwieckz>
21:47 fdobridge: <i​llwieckz> And do nouveau has something to benefit from such scenario where a vbios is modified by a third party tool on which Mesa would not be involved at all?
21:47 fdobridge: <k​arolherbst🐧🦀> live patching vbios isn't viable and also makes no sense outside of overclocking
21:47 fdobridge: <i​llwieckz> okok
21:48 fdobridge: <k​arolherbst🐧🦀> the vbios basically describes the GPU
21:48 fdobridge: <k​arolherbst🐧🦀> and it has to match the actual hardware
22:03 fdobridge: <b​utterflies> Hm
22:03 fdobridge: <b​utterflies> Can we actually not reclock
22:03 fdobridge: <k​arolherbst🐧🦀> well
22:03 fdobridge: <k​arolherbst🐧🦀> we can change clocks, but we can't change the voltage/fans
22:04 fdobridge: <b​utterflies> Reviewing again what light secure can do
22:04 fdobridge: <b​utterflies> Hm
22:04 fdobridge: <k​arolherbst🐧🦀> yeah...
22:04 fdobridge: <k​arolherbst🐧🦀> we might be able to wiggle the clocks a little upwards _if_ the GPU booted overvolted, but...
22:47 fdobridge: <b​utterflies> hm
22:47 fdobridge: <b​utterflies> do you actually not control the voltage