02:15 fdobridge: <i​509vcb> I've done some more spelunking around nvgpu and it seems that the firmware is referred to in code partially as "netlist", which is a term I'd think you'd see in an fpga. But I think this might just be weird naming in the code.
02:15 fdobridge: <i​509vcb>
02:15 fdobridge: <i​509vcb> Image is the package from l4t which has all the firmware for ga10b
02:15 fdobridge: <i​509vcb> https://cdn.discordapp.com/attachments/1034184951790305330/1222368281403592735/Screenshot_20240319_213631.png?ex=6615f62c&is=6603812c&hm=bcf51234fdd217b62dd723de67492d4b2647ef50d91db780d5f38828eeb7750d&
02:16 fdobridge: <i​509vcb> from what I can tell gm20b, gp10b and gv11b all have 4 slots but also a constant defining the "final" one
02:18 fdobridge: <i​509vcb> I think I have enough info to start up the gsp for ga10b, but I know nova exists now and I want to do Rust :ferris:
03:26 fdobridge: <a​irlied> @gfxstrand okay managed to get it to crash here at least
03:27 fdobridge: <g​fxstrand> 👍🏻
07:26 fdobridge: <m​arysaka> I think noueau already handle parsing those netlist for tegra no?
10:10 fdobridge: <k​arolherbst🐧🦀> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10876#note_2344157 :blobcatnotlikethis:
10:11 fdobridge: <k​arolherbst🐧🦀> I'm impressed that people are still using those GPUs with a modern software stack 😄
10:11 fdobridge: <k​arolherbst🐧🦀> but god dammit
10:27 fdobridge: <a​irlied> @gfxstrand I reproduced it with linear cts Test case 'dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.512_256_6'..
10:27 fdobridge: <a​irlied> Pass (Passed)
10:27 fdobridge: <a​irlied>
10:27 fdobridge: <a​irlied> Test case 'dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8'..
10:27 fdobridge: <a​irlied> MESA: error: ../src/nouveau/vulkan/nvk_device_memory.c:203: VK_ERROR_OUT_OF_DEVICE_MEMORY
10:27 fdobridge: <a​irlied> will dig in a bit more tomorrow if I can find some time
10:27 fdobridge: <a​irlied> at least I think it was that, my dmesg spam scrolled away
10:27 fdobridge: <a​irlied> (misplaced in #Rusticl earlier)
11:59 fdobridge: <d​wlsalmeida> @airlied getting plenty of VK_ERROR_OUT_OF_DEVICE_MEMORY here as well :/
12:43 fdobridge: <z​mike.> oh is that new and not expected?
12:43 fdobridge: <z​mike.> piglit streaming-texture-leak hits it immediately
13:05 fdobridge: <v​alentineburley> @gfxstrand https://gitlab.freedesktop.org/Valentine/mesa/-/commit/15ae09b34243f566ff633b8ef20d9157b5a2a56d
13:05 fdobridge: <v​alentineburley> ```
13:05 fdobridge: <v​alentineburley> Test run totals:
13:05 fdobridge: <v​alentineburley> Passed: 173/657 (26.3%)
13:05 fdobridge: <v​alentineburley> Failed: 0/657 (0.0%)
13:05 fdobridge: <v​alentineburley> Not supported: 484/657 (73.7%)
13:05 fdobridge: <v​alentineburley> Warnings: 0/657 (0.0%)
13:05 fdobridge: <v​alentineburley> Waived: 0/657 (0.0%)
13:05 fdobridge: <v​alentineburley> ```
13:24 fdobridge: <g​fxstrand> It's not something the Vulkan CTS hit before, at least not reliably. It seems to reproduce quite nicely on tip-of-tree CTS, though. 😅
13:24 fdobridge: <g​fxstrand> It's not something the Vulkan CTS didn't hit before, at least not reliably. It seems to reproduce quite nicely on tip-of-tree CTS, though. 😅 (edited)
13:26 fdobridge: <v​alentineburley> The not supported tests need VK_KHR_fragment_shading_rate or VK_EXT_memory_priority
13:27 fdobridge: <z​mike.> I just updated the base of my branch and got it on some piglits
13:53 fdobridge: <d​wlsalmeida> Hey there! 🙂 I wonder if there's a workaround for this for now?
13:58 fdobridge: <g​fxstrand> Not yet but Dave has a reproducer so we're half-way there.
15:12 fdobridge: <v​alentineburley> @gfxstrand I don't get it, isn't this how RADV did it? Why do we need to do it differently?
17:20 fdobridge: <g​fxstrand> IDK how RADV did it. But we have the fallbacks and I'd rather use them. RADV should be using the fallbacks, too, unless they've got perf numbers that prove that it's a big enough bottlekneck to be worth it.
17:20 fdobridge: <g​fxstrand> It's possible that RADV did it that way because they have a giant pile of meta code that they would have to rework if they used the fallbacks. That tends to be an issue with RADV.
17:21 fdobridge: <g​fxstrand> NVK doesn't have that problem.
17:21 fdobridge: <a​huillet> fallbacks for what?
17:22 fdobridge: <g​fxstrand> That implement `vkFoo()` in terms of `vkFoo2KHR()`
17:24 fdobridge: <g​fxstrand> That way drivers can just roll forward and never look back.
17:30 fdobridge: <!​DodoNVK (she) 🇱🇹> Could RADV be rewritten to use the Vulkan runtime stuff?
17:31 fdobridge: <p​ac85> The pipeline stuff?
17:32 fdobridge: <!​DodoNVK (she) 🇱🇹> I think RADV implements functions that are already exist in the runtime too
17:32 fdobridge: <t​riang3l> IMO meta shouldn't be meta in the first place
17:33 fdobridge: <n​anokatze> what
17:34 fdobridge: <t​riang3l> Like done on top of the internal structures of the implementation rather than the entry points designed for applications
17:34 fdobridge: <n​anokatze> how about
17:34 fdobridge: <n​anokatze> entry points designed for applications + mesa-specific extras
17:35 fdobridge: <p​ixelcluster> i.e. current meta, p much
17:35 fdobridge: <p​ixelcluster> 🐸
17:35 fdobridge: <t​riang3l> That's the worst path IMO, because in this case you have to implement those entry points with the rules of two specifications at once
17:36 fdobridge: <t​riang3l> just following the Vulkan spec alone randomly becomes not enough
17:36 fdobridge: <n​anokatze> it's not two specifications at once
17:36 fdobridge: <p​ixelcluster> what would "the internal structures of the implementation" even be though, you usually want to just have some compute shader, give it some resources, and dispatch it
17:36 fdobridge: <t​riang3l> and you may not even quickly find when you have to consider Mesa-specific things
17:37 fdobridge: <n​anokatze> it's just a specification with more requirements, but also these added requirements can be changed if necessary or opted out of if so desired
17:37 fdobridge: <p​ixelcluster> the existing structure there would really just be the api concepts like push constants (or descriptors if necessary) and vkCmdDispatch
17:38 fdobridge: <p​ixelcluster> there isn’t really a lower-level kind of thing you could use there without that being a huge PITA to punch through all layers of shader compiler+command emission
17:39 fdobridge: <n​anokatze> also idk trongle, your other opinions are like "we need 65535 descriptor sets" so I'm starting to hallucinate a pattern here of wanting something for the sake of it/ideological="it would be neater that way" reasons 🐸
17:39 fdobridge: <p​ixelcluster> and why would you try making a custom api when a vulkan cs with a few descriptors or push constants is exactly what you need
17:39 fdobridge: <t​riang3l> depends on the driver, in my case I have the "hardware state" layer, with "application state" and "meta" being its two clients
17:40 fdobridge: <p​ixelcluster> no it doesn’t depend on the driver, we’re talking about just one
17:40 fdobridge: <t​riang3l> meta stuff only makes things in the "application state" part dirty
17:40 fdobridge: <t​riang3l> but doesn't modify them, for instance
17:40 fdobridge: <t​riang3l> just defers re-applying of them to the next draw
17:40 fdobridge: <p​ixelcluster> maybe terakan does things this way but I don’t see a lot of sense in trying to make radv do that
17:41 fdobridge: <n​anokatze> vk 1.0 should've shipped with buffer device address required tbh 🐸
17:41 fdobridge: <n​anokatze> it would solve the cockroach issue
17:41 fdobridge: <n​anokatze> for good
17:41 fdobridge: <n​anokatze> would've
17:41 fdobridge: <n​anokatze> vk 1.0 should've shipped with buffer device address, required, tbh 🐸 (edited)
17:42 fdobridge: <p​ixelcluster> ~~imagine not using 1.3 anyway~~
17:42 fdobridge: <t​riang3l> well, yeah, there are other Terakan-specific details here that don't apply to RADV, so that makes sense
17:44 fdobridge: <t​riang3l> like the push constant buffer passed to application shaders containing driver-internal constants (like draw ID, sample locations) glued to the user push constants, but meta doesn't need any of that
17:45 fdobridge: <t​riang3l> although it'd just work if Terakan meta used NIR
17:45 fdobridge: <t​riang3l> although it'd just work "for free" if Terakan meta used NIR (edited)
17:46 fdobridge: <p​ixelcluster> tfw not using at least nir 🐸
17:47 fdobridge: <t​riang3l> well, there are some nice things in the hardware like gl_FragCoord.xy passed directly as integers
17:48 fdobridge: <t​riang3l> although some optimization passes utilizing that feature would've definitely been nice for application shaders too
17:49 fdobridge: <t​riang3l> yeah, well, all things beyond what you can do in normal SPIR-V can of course be done by adding new intrinsics
17:50 fdobridge: <v​alentineburley> Oh no, what did I start? 🐸
17:50 fdobridge: <k​arolherbst🐧🦀> what is it using instead
17:51 fdobridge: <t​riang3l> instruction field shift #defines and bitwise ORs 🥵
17:52 fdobridge: <t​riang3l> `static const`
17:52 fdobridge: <t​riang3l> applications start so quickly 🦔
17:53 fdobridge: <k​arolherbst🐧🦀> you get the same with a shader cache tho
17:53 fdobridge: <t​riang3l> but I have to target only two ISA revisions anyway
17:53 fdobridge: <k​arolherbst🐧🦀> yeah..
17:53 fdobridge: <k​arolherbst🐧🦀> or you do it the asahi+intel way and just use OpenCL C and compile to native ISA 😄
19:17 fdobridge: <a​irlied> @dwlsalmeida probably just stick if (pgd == NULL) somewhere and returning might "fix" it. I'd hope to find it today, but my calendar is suggesting it's unlikely 😛
19:17 fdobridge: <d​wlsalmeida> @airlied sounds good!
19:18 fdobridge: <d​wlsalmeida> I have 0 idea what is going on in that particular piece of code, I wouldn't dare to try and fix it anyways 😂
19:19 fdobridge: <d​wlsalmeida> I have 0 idea what is going on in that particular piece of code, I wouldn't dare to try and fix it for real anyways 😂 (edited)
19:27 fdobridge: <g​fxstrand> Yeah, it just requires a search-and-replace on their meta code.
19:33 fdobridge: <a​irlied> wierd, unmap 0x10000 range in userspace, kernel unmaps 0x100000
19:39 fdobridge: <g​fxstrand> Those aren't the same number...
19:46 fdobridge: <a​irlied> indeed 🙂
19:47 fdobridge: <g​fxstrand> @airlied Is someone dividing by PAGE_SIZE and then multiplying by the wrong PAGE_SIZE?
19:50 fdobridge: <a​irlied> hmm it appears the wierdness happens before the unmap gets called from userspace which is also wierd
20:00 fdobridge: <a​irlied> probably going to be the gpuvm somewhere, will try and get to it once I exit meeting alley
20:41 fdobridge: <v​alentineburley> Is this what I'm supposed to be doing? @gfxstrand
20:41 fdobridge: <v​alentineburley> https://pastebin.com/1mrkmanA
20:59 fdobridge: <g​fxstrand> Yeah, except the `nvk_push_descriptor_set_update` needs to happen per-bind-point as well because they might set `COMPUTE` and a graphics stage.
21:00 fdobridge: <v​alentineburley> Sweet, I'll finish it up tomorrow, thanks