02:43fdobridge: <airlied> @gfxstrand @dwlsalmeida found the bug, just sent patch to the list
02:44airlied: dakr: ^ patch on list fixes a bug in the uvmm code
02:45fdobridge: <airlied> https://patchwork.freedesktop.org/patch/585178/
02:51fdobridge: <airlied> bleh now I hit a bug in another place, but I think that fix is good for one bug
02:53fdobridge: <airlied> uggh this is one from a page fault which is like one we've seen elsewhere
03:00fdobridge: <gfxstrand> I'm going to pull that into my branch now
03:06fdobridge: <airlied> it fixes the oops in the unmap path, but I think there is still a vram page fault bug somewhere that is something different
03:52fdobridge: <gfxstrand> Well, I eagerly await your next patch. 😅
05:52fdobridge: <airlied> I expect the racey vram mapping one will be harder to find, probably need to add a few WARN_ONs to see wtf is null in that scenario
06:17fdobridge: <redsheep> Hmm. Doom 2016 seems like it might last a little longer now, hard to say. Doom eternal however no longer works, and it doesn't seem to be an nvapi issue like it was before.
06:20fdobridge: <Sid> regression :o
06:22fdobridge: <redsheep> I guess I will see if reverting the control flow patches gets it working again
06:31Sid127: mhm
06:33fdobridge: <redsheep> ... I hate this so much, I get weird shit like this every time I go to test. I don't get to easily test if reverting those commits fixes it because simply pointing doom eternal at my devenv icd fixes whatever is crashing it.
06:35fdobridge: <redsheep> My installed build and the completely plain dev build I did are exactly the same commit and are only very very slightly modified versions of the same build script, just one is turned into an aur pkgbuild. So, something about what the aur or arch does with the package breaks it.
06:41fdobridge: <redsheep> Alright, I did the next best thing and made my aur packages use the last commit before !28300 merged, let's see if that does it.
06:49fdobridge: <redsheep> Oh. It also crashes when installed to the commit before that MR, so that isn't the problem. That's good news, except now I have no idea what else changed in the last week or two to break doom eternal on my system.
06:50fdobridge: <airlied> does it build with lto?
06:58fdobridge: <redsheep> Yes it does appear that my arch is set up to do lto when building with makepkg, as well as stripping
07:06fdobridge: <redsheep> Hmm did some performance testing while I am messing with this issue and it seems that even with control flow happy doom eternal the performance is not measurably different with or without 28300
07:28fdobridge: <redsheep> Hmm not lto, I put my makepkg options at complete default per the config file and I got a build that would launch it, then I just tested with my original config minus lto, and it crashes again. Guess I will have to add back these options one.
07:29fdobridge: <redsheep> *these options one by one
07:31fdobridge: <tom3026> @redsheep is wine from repos or self built?
07:31fdobridge: <redsheep> Hmm? What does this have to do with wine? I am only rebuilding mesa between tests
07:32fdobridge: <tom3026> @redsheep currently i had issues with vkd3d being lto, some games crashed. so rebuilt dxvk and vkd3d without it. now im just having diablo2 crashing on system wine but works in steam/proton so there is still some weird compiling thing
07:33fdobridge: <tom3026> diablo2 is using glide to opengl so its not even using vkd3d/dxvk which i assume means either wine or some of its deps
07:34fdobridge: <redsheep> I have now done builds with and without lto that work, so it doesn't seem to be the issue. I am testing stripping next.
07:35fdobridge: <redsheep> I am just using proton experimental from steam, not building any of that stuff, so that is not the variable under test here.
07:35fdobridge: <tom3026> okay 🙂
07:36fdobridge: <tom3026> yeah im running most things in system wine because well razor1911
07:37fdobridge: <tom3026> and lately wine 9.x so i can use the wayland driver heh
07:38fdobridge: <!DodoNVK (she) 🇱🇹> https://youtu.be/htbDeD-wv7s
08:06karolherbst: Lyude: ever encountered this issue: https://gitlab.freedesktop.org/drm/nouveau/-/issues/344
08:06karolherbst: looks like something weird is going on, either with the cursor or something else
08:14fdobridge: <redsheep> Turns out it was not LTO, but was in fact the debug option in makepkg. Go figure. It's not even makepkg default, really weird that was on.
08:28fdobridge: <redsheep> What kernel should I run if I want to file an issue for doom 2016, and should I file in mesa or in drm/nouveau given the error crops up in dmesg?
08:29fdobridge: <redsheep> I assume we're well past the point where vulkan 1.0 games would be expected to be working
08:32fdobridge: <redsheep> I am able to get in game for much longer now, so whatever it's hammering has gotten quite a bit more resilient. Still, it does die pretty fast and consistently.
08:34airlied: if it's an mmu fault or something like that it's probably mesa
08:34airlied: if it oops with a backtrace, probably kernel
08:34fdobridge: <redsheep> It's an mmu fault, so mesa it is. Thanks!
08:38fdobridge: <tom3026> so it crashes just because of -g ? thats odd
08:40fdobridge: <redsheep> Dunno, I was toggling it in /etc/makepkg.conf since that is what I found in the man pages
08:40fdobridge: <redsheep> If that flag is the same thing, then yes
08:40fdobridge: <tom3026> it pretty much just uses the DEBUG_CFLAGS from makepkg i think the defaults is just -g
08:41fdobridge: <Sid> makepkg -g just generates integrity checks
08:41fdobridge: <Sid> for the source files
08:41fdobridge: <tom3026> makepkg.conf options=(debug) thats default from a few weeks ago
08:42fdobridge: <tom3026> enabled DEBUG_CFLAGS from makepkg.conf thats last i checked just -g
08:42fdobridge: <tom3026> compiler cflag -g :p
08:44fdobridge: <redsheep> Yeah I had to do !debug in the options there to get a mesa build that doesn't crash doom eternal. Doesn't make sense, but hey, it works.
08:44fdobridge: <tom3026> sounds like UB going on and for some reason -g finds it harder xD
09:16fdobridge: <ahuillet> do you have a stack trace somewhere?
09:17fdobridge: <redsheep> I wonder if maybe the proton logs would catch that? Let me see
09:17fdobridge: <redsheep> Getting any logs out of steam games sucks
09:19fdobridge: <ahuillet> it's probably worth figuring out exactly what compiler option triggers the problem, and then in some cases you can drill down into a specific object file (not so with LTO...)
09:22fdobridge: <ahuillet> I'd be very surprised if -g on its own was doing that.
09:24fdobridge: <redsheep> Hmm I am not sure how to do any that... I am not exactly a developer, yet. In any case, I am recreating a broken build to see if I can get a trace.
09:25fdobridge: <redsheep> I think that issue I just opened for the other doom game is probably my first formal bug report ever 😛
09:26fdobridge: <ahuillet> congrats!
09:34fdobridge: <redsheep> I don't think I found the smoking gun, but it's hard to be certain with a 156k line log file. If anybody cares to check into this I will go ahead and attach it.
09:34fdobridge: <redsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1222841308322992168/steam-782330.log?ex=6617aeb7&is=660539b7&hm=5c901106c875ad0347ab62e7ad77aa79d73258a1328fd1a4a81ed687c68b1df4&
09:35fdobridge: <redsheep> I would keep looking through it but I have to sleep some time lol
09:35fdobridge: <ahuillet> was there anything in dmesg?
09:35fdobridge: <redsheep> No
09:37fdobridge: <ahuillet> backtrace: --- Exception 0xc0000005 at 0x79f8e4daaf66: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/vulkan/0/libvulkan_nouveau.so + 0x5aaf66.
09:37fdobridge: <ahuillet> can you please addr2line this?
09:38fdobridge: <ahuillet> the log mentions the following a couple of lines below, so I assume you'll end up in that function
09:38fdobridge: <ahuillet> 2987.098:0154:01cc:err:msvcrt:_wassert (L"!status && \"vkCreateComputePipelines\"",L"../src-wine/dlls/winevulkan/loader_thunks.c",2738)
09:38fdobridge: <ahuillet> so yes, please attach it (compressed), it seems relevant. but the addr2line thing will be useful because nobody can analyze that address without having at least a copy of the DSO
09:40fdobridge: <redsheep> That message showing the log has the attachment, all 14 MB. Not sure on browser but on the electron app it has an arrow in the bottom right.
09:40fdobridge: <ahuillet> I thought you had a bug report open somewhere
09:40fdobridge: <ahuillet> anyway. addr2line please and if you don't mind, the .so file also
09:41fdobridge: <ahuillet> might as well have some fun with Ida on a holiday :)
09:41fdobridge: <redsheep> Oh, sorry to be confusing I opened a report for doom 2016 since that one is much easier to explain, plain and simple mmu fault in dmesg
09:42fdobridge: <redsheep> This doom eternal issue where it depends on debug seemed less actionable so I have not filed it yet
09:44fdobridge: <magic_rb.> Completely unrelated, but its been bugging me for a while. Do you guys remember the doom eternal issue on release? The one where on nvidia proprietary the game would barely run and the fps seemed to be tied purely framerate. Anyone know what that was about? I tried to read up on it back then but i didnt get anywhere due to a lack of previous knowledge
09:49fdobridge: <ahuillet> @magic_rb. yes, application was requesting that their render targets be placed in system memory
09:49fdobridge: <ahuillet> or textures, I don't recall, anyway -- super bad app bug, sysmem murders your perf.
09:50fdobridge: <magic_rb.> Ah so it was copying across the pci bus, why wasnt this an issue on windows? Isnt the driver essentially the same between windows linux?
09:50fdobridge: <ahuillet> I don't believe we communicated all that much about it, and I don't have a great recollection of why this only affected the blob, but it was an app bug
09:51fdobridge: <magic_rb.> No worries, the pci copying would explain why it explain the ties to resolution
09:51fdobridge: <ahuillet> GPUs have forever had the ability to texture from sysmem over the PCI bus (that's what AGP was all about), and usually also the ability to render to sysmem
09:52fdobridge: <ahuillet> it's OK-ish when you run out of VRAM of course but otherwise perf murder.
09:52fdobridge: <ahuillet> so anyway GL handles that for you behind your back, Vk doesn't and gives the app full explicit control
09:53fdobridge: <magic_rb.> I assume when allocating a buffer you can specify where you want it, is there a "swap out" feature so when a buffer isnt used in some time it gets copied out to sysmem?
09:55fdobridge: <ahuillet> in GL yes, more or less, behind the app's back
09:55fdobridge: <ahuillet> in Vk, no, you have to write it yourself
09:55fdobridge: <redsheep> I seem to be hitting an issue where the directory from the log isn't real, that was probably from inside the steam runtime funny business
09:55fdobridge: <redsheep> A naive search of my system for libvulkan_nouveau.so returns way too many results, not sure how to sort out what file is actually used
09:56fdobridge: <magic_rb.> @ahuillet thanks for the explanation
09:57fdobridge: <ahuillet> @redsheep the one in /usr/lib or similar? give full list if you need help
09:57fdobridge: <ahuillet> np
09:57fdobridge: <ahuillet> so anyway the "full explicit control" is a bit of a myth in practice, because apps get things wrong, and OSes (Windows) don't want to give them full explicit control
09:58fdobridge: <ahuillet> for obvious reasons, (local DoS if I eat all your VRAM)
09:58fdobridge: <ahuillet> therefore in practice there's some migration going on even in Vk behind your back, see https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_memory_priority.html
09:59fdobridge: <magic_rb.> I really should learn opengl basics and then transfer that to vulkan. Its interesting, i just dont have the time to sink into it right now :/
10:01fdobridge: <magic_rb.> And im missing quite a lot of what i feel like is expected math knowledge, linear algebra and stuff
10:02fdobridge: <redsheep> Ok I broke out of my confusion loop and found the .so file
10:02fdobridge: <redsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1222848242723586048/libvulkan_nouveau.so?ex=6617b52c&is=6605402c&hm=b5e43bfb5a8030bb169e685b264240d61d76fe50d4c93522b00f7f9e3fe9d5f6&
10:03fdobridge: <redsheep> I have never used addr2line before but uh... Maybe this is what you were asking for?
10:03fdobridge: <redsheep>
10:03fdobridge: <redsheep> ```addr2line -e libvulkan_nouveau.so -a 0x5aaf66
10:03fdobridge: <redsheep> 0x00000000005aaf66
10:03fdobridge: <redsheep> /usr/src/debug/rust/rustc-1.77.0-src/library/core/src/../../stdarch/crates/core_arch/src/x86/sse2.rs:845```
10:05fdobridge: <redsheep> So based on context clues, NAK blew up while dealing with a compute shader.
10:06fdobridge: <ahuillet> it was, but that's not immensely useful sadly. it would be good to be able to get an actual stack trace from Proton but I don't know how to do that
10:10fdobridge: <redsheep> I feel like both of these would probably benefit from playing around with them with renderdoc, but I haven't made too much headway in understanding how to use that tool just yet.
10:11fdobridge: <redsheep> Like, maybe it would just make the offending compute shader really obvious by it being the last thing the app tried?
10:12fdobridge: <!DodoNVK (she) 🇱🇹> Segfault in unsafe Rust function :ferris:
10:12fdobridge: <!DodoNVK (she) 🇱🇹> <https://github.com/rust-lang/stdarch/blob/f4528dd6e85d97bb802240d7cd048b6e1bf72540/crates/core_arch/src/x86/sse2.rs#L845>
10:13fdobridge: <redsheep> Lovely. I imagine it was fed something nasty, surely rust itself isn't at fault.
10:14fdobridge: <marysaka> can't you try to run a debug version?
10:15fdobridge: <redsheep> Debug version of what part though? The bizarre thing is that this can only be replicated on a build of mesa where I have makepkg set to enable debug, which causes it to build an extra -debug package, but that doesn't appear to be what the application loaded
10:16fdobridge: <redsheep> It's probably just that it is doing more than just creating the separate debug package
10:16fdobridge: <!DodoNVK (she) 🇱🇹> So does the segfault only happen with debug package?
10:16fdobridge: <redsheep> Let me remove the debug package entirely so it's out of the picture and confirm if I still get a crash
10:17fdobridge: <redsheep> It still crashes, so yeah that wasn't it.
10:19fdobridge: <redsheep> If I could replicate with my dev build this would all be so much easier
10:20fdobridge: <tom3026> essentially it only happends when -g is added to cflags
10:20fdobridge: <!DodoNVK (she) 🇱🇹> I mean using the NVK package not compiled with the debug option
10:22fdobridge: <redsheep> Just to be clear I am not on your AUR package anymore since I wanted to unify my mesa and nvk packages. When the options area of /etc/makepkg.conf has !debug set then it builds a package that works, and when it is set to debug it builds a package that doesn't.
10:23fdobridge: <ahuillet> that's hard to believe
10:23fdobridge: <ahuillet> there is likely another difference, such as a different -O flag
10:24fdobridge: <tom3026> @ahuillet https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/blob/main/makepkg.conf?ref_type=heads#L55 well unless changed thats all it does
10:24fdobridge: <tom3026> or should do atleast, unless there is some hidden magic behind it
10:26fdobridge: <redsheep> Oh the rustflags thing it lists could be it, maybe?
10:26fdobridge: <ahuillet> is it DEBUG_CFLAGS concatenated to CFLAGS ?
10:26fdobridge: <ahuillet> 'cause if it's just DEBUG_CFLAGS then that drops -O2 and the world changes
10:27fdobridge: <ahuillet> Super dumb question but where's Rust used in nvk?
10:27fdobridge: <!DodoNVK (she) 🇱🇹> The compiler
10:29fdobridge: <redsheep> Which if it is choking on a compute shader it does make sense it would be an issue with debug stuff getting turned on in rust
10:29fdobridge: <redsheep> Or other stuff getting turned off, depending how all this actually works
10:29fdobridge: <ahuillet> I'm not sure the line is correct tohugh
10:30fdobridge: <ahuillet> I'm not sure the line is correct though (edited)
10:30fdobridge: <redsheep> Hmm okay. Oh btw best to avoid edits for the sake of those over on IRC, it can make a mess
10:36fdobridge: <ahuillet> btw.. 2987.098:0154:01cc:err:seh:handle_syscall_fault Syscall stack overrun.
10:36fdobridge: <ahuillet> backtrace: --- Exception 0xc0000005 at 0x79f8e4daaf66: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/vulkan/0/libvulkan_nouveau.so + 0x5aaf66.
10:37fdobridge: <ahuillet> I don't see that error message in vanilla Wine's source code
10:37fdobridge: <ahuillet> I also don't see where the syscall is
10:37fdobridge: <!DodoNVK (she) 🇱🇹> Yes
10:38fdobridge: <ahuillet> I'm not sure you gave me the right file. that one doesn't have debug symbols and the address points at another place
10:40fdobridge: <tom3026> im fairly sure it should only add -g ontop of the normal CFLAGS otherwise it would be major breakage of arch imo
10:40fdobridge: <tom3026> since debug began being default recently
10:41fdobridge: <tom3026> cant test tho, im rolling my world with emerge as of late heh
10:41fdobridge: <ahuillet> there's little need to guess anyway, when we can dump the actual build commandline used (and play with it)
10:41fdobridge: <ahuillet> maybe rust reacts differently too and its debug option changes things
10:42fdobridge: <redsheep> That's what I suspect. And yeah I am not sure that's the right file, steam is weird.
10:42fdobridge: <!DodoNVK (she) 🇱🇹> What happens if you enable `debug` option but set the `DEBUG_RUSTFLAGS` variable to empty in /etc/makepkg.conf?
10:42fdobridge: <ahuillet> (definitely not the right file)
10:44fdobridge: <redsheep> Arch also strips as part of building. I can try again to get the right file in about 7 hours
10:45fdobridge: <ahuillet> yeah remove the strip thing too. but you probably want to build from git directly without a PKGBUILD if you're going to be debugging Nouveau
10:47fdobridge: <redsheep> Yeah I've been doing that but it's useful to prove out actually installing and running your system on it too, there are probably only 5-10 people doing that total
10:49fdobridge: <redsheep> I'll try that next chance I get
11:27fdobridge: <valentineburley> Please bear with me because I can be slow sometimes:
11:27fdobridge: <valentineburley> How would I do that more efficiently without a function that basically looks like my first attempt?
11:27fdobridge: <valentineburley> Otherwise I seem to end up with a ton of duplicate code
11:28fdobridge: <valentineburley> And sorry for the dumb questions 😅
12:01fdobridge: <ahuillet> Absolutely, but for the purpose of debugging the problem that you're encountering, you'll need more fine grained control over the build process
12:01fdobridge: <ahuillet> for debugging anything really...
12:21fdobridge: <ahuillet> haven't seen the first attempt, but I think she means that nvk_push_descriptor_set_update(push_set, set_layout, <<-- needs to be there for both possible values of push_set
12:22fdobridge: <ahuillet> (if both stage_flags are set, your current code only does graphics)
12:27fdobridge: <valentineburley> This is what I got now and it's not pretty:
12:27fdobridge: <valentineburley> ```
12:27fdobridge: <valentineburley> VKAPI_ATTR void VKAPI_CALL
12:27fdobridge: <valentineburley> nvk_CmdPushDescriptorSet2KHR(VkCommandBuffer commandBuffer,
12:27fdobridge: <valentineburley> const VkPushDescriptorSetInfoKHR *pPushDescriptorSetInfo)
12:27fdobridge: <valentineburley> {
12:27fdobridge: <valentineburley> VK_FROM_HANDLE(nvk_cmd_buffer, cmd, commandBuffer);
12:27fdobridge: <valentineburley> VK_FROM_HANDLE(vk_pipeline_layout, pipeline_layout, pPushDescriptorSetInfo->layout);
12:27fdobridge: <valentineburley>
12:27fdobridge: <valentineburley> struct nvk_push_descriptor_set *push_set_compute = NULL;
12:27fdobridge: <valentineburley> struct nvk_push_descriptor_set *push_set_graphics = NULL;
12:27fdobridge: <valentineburley>
12:27fdobridge: <valentineburley> if (pPushDescriptorSetInfo->stageFlags & VK_SHADER_STAGE_COMPUTE_BIT) {
12:27fdobridge: <valentineburley> push_set = nvk_cmd_push_descriptors(cmd, VK_PIPELINE_BIND_POINT_COMPUTE, pPushDescriptorSetInfo->set);
12:27fdobridge: <valentineburley> }
12:27fdobridge: <valentineburley>
12:27fdobridge: <valentineburley> if (pPushDescriptorSetInfo->stageFlags & VK_SHADER_STAGE_ALL_GRAPHICS) {
12:27fdobridge: <valentineburley> push_set = nvk_cmd_push_descriptors(cmd, VK_PIPELINE_BIND_POINT_GRAPHICS, pPushDescriptorSetInfo->set);
12:27fdobridge: <valentineburley> }
12:27fdobridge: <valentineburley>
12:28fdobridge: <valentineburley> if (unlikely(push_set_compute == NULL && push_set_graphics == NULL))
12:28fdobridge: <valentineburley> return;
12:28fdobridge: <valentineburley>
12:28fdobridge: <valentineburley> struct nvk_descriptor_set_layout *set_layout_compute = NULL;
12:28fdobridge: <valentineburley> struct nvk_descriptor_set_layout *set_layout_graphics = NULL;
12:28fdobridge: <valentineburley>
12:28fdobridge: <valentineburley> if (push_set_compute) {
12:28fdobridge: <valentineburley> set_layout_compute = vk_to_nvk_descriptor_set_layout(pipeline_layout->set_layouts[pPushDescriptorSetInfo->set]);
12:28fdobridge: <valentineburley> nvk_push_descriptor_set_update(push_set_compute, set_layout_compute,
12:28fdobridge: <valentineburley> pPushDescriptorSetInfo->descriptorWriteCount, pPushDescriptorSetInfo->pDescriptorWrites);
12:28fdobridge: <valentineburley> }
12:28fdobridge: <valentineburley>
12:28fdobridge: <ahuillet> it's also wrong, you're setting "push_set"
12:29fdobridge: <valentineburley> yeah i forgot to copy that
12:29fdobridge: <ahuillet> so anyway it's a stylistic problem, let's see
12:29fdobridge: <ahuillet> either a for loop, which is "elegant" but more painful to read
12:30fdobridge: <valentineburley> And we'll have to make a third one for RT later
12:30fdobridge: <ahuillet> then the for loop becomes more justified
12:31fdobridge: <valentineburley> My initial attempt was what RADV and ANV did:
12:31fdobridge: <valentineburley> https://gitlab.freedesktop.org/Valentine/mesa/-/blob/15ae09b34243f566ff633b8ef20d9157b5a2a56d/src/nouveau/vulkan/nvk_cmd_buffer.c#L741
12:31fdobridge: <ahuillet> yes, is that not good?
12:32fdobridge: <valentineburley> I'll have to ask Faith again
12:32fdobridge: <valentineburley> But she left a comment there
12:33fdobridge: <valentineburley> https://gitlab.freedesktop.org/Valentine/mesa/-/commit/15ae09b34243f566ff633b8ef20d9157b5a2a56d#note_2344574
12:33fdobridge: <ahuillet> https://pastebin.com/GkBFnAUX
12:33fdobridge: <ahuillet> for loop might be something like that
12:33fdobridge: <valentineburley> Yeah that's nice
12:34fdobridge: <ahuillet> OK, I don't know if I understand her reasoning because your original version is way more elegant, and if somebody is claiming a perf thing they should verify it (= that's probably on you)
12:34fdobridge: <valentineburley> Yeah
12:34fdobridge: <valentineburley> Thanks for the help btw
12:34fdobridge: <ahuillet> anyway if you have more stages eventually, the for loop is the way to go
12:34fdobridge: <ahuillet> and if perf wise you /need/ an unroll you force the compiler to do that (and you measure it before sqrt(evil))
12:34fdobridge: <ahuillet> and if perf wise you /need/ an unroll you force the compiler to do that (and you measure it before because sqrt(evil)) (edited)
12:35fdobridge: <valentineburley> An NV dev writing NVK code btw 😛
12:35fdobridge: <ahuillet> can also do it with a while where you clear the bit and check for != 0 in order to cut on some looping, but again, sqrt(evil) stuff
12:35fdobridge: <valentineburley> isn't there a rule against that?
12:36fdobridge: <ahuillet> my middle name is Danger
12:37fdobridge: <valentineburley> ```
12:37fdobridge: <valentineburley> VKAPI_ATTR void VKAPI_CALL
12:37fdobridge: <valentineburley> nvk_CmdPushDescriptorSet2KHR(VkCommandBuffer commandBuffer,
12:37fdobridge: <valentineburley> const VkPushDescriptorSetInfoKHR *pPushDescriptorSetInfo)
12:37fdobridge: <valentineburley> {
12:37fdobridge: <valentineburley> VK_FROM_HANDLE(nvk_cmd_buffer, cmd, commandBuffer);
12:37fdobridge: <valentineburley> VK_FROM_HANDLE(vk_pipeline_layout, pipeline_layout, pPushDescriptorSetInfo->layout);
12:37fdobridge: <valentineburley>
12:37fdobridge: <valentineburley> struct nvk_push_descriptor_set *push_set_compute = NULL;
12:37fdobridge: <valentineburley> struct nvk_push_descriptor_set *push_set_graphics = NULL;
12:37fdobridge: <valentineburley>
12:37fdobridge: <valentineburley> if (pPushDescriptorSetInfo->stageFlags & VK_SHADER_STAGE_COMPUTE_BIT) {
12:37fdobridge: <valentineburley> push_set_compute = nvk_cmd_push_descriptors(cmd, VK_PIPELINE_BIND_POINT_COMPUTE, pPushDescriptorSetInfo->set);
12:37fdobridge: <valentineburley> }
12:37fdobridge: <valentineburley>
12:37fdobridge: <valentineburley> if (pPushDescriptorSetInfo->stageFlags & VK_SHADER_STAGE_ALL_GRAPHICS) {
12:37fdobridge: <valentineburley> push_set_graphics = nvk_cmd_push_descriptors(cmd, VK_PIPELINE_BIND_POINT_GRAPHICS, pPushDescriptorSetInfo->set);
12:37fdobridge: <valentineburley> }
12:37fdobridge: <valentineburley>
12:37fdobridge: <valentineburley> if (unlikely(push_set_compute == NULL && push_set_graphics == NULL))
12:37fdobridge: <valentineburley> return;
12:37fdobridge: <valentineburley>
12:37fdobridge: <valentineburley> struct nvk_descriptor_set_layout *set_layout_compute = NULL;
12:37fdobridge: <valentineburley> struct nvk_descriptor_set_layout *set_layout_graphics = NULL;
12:37fdobridge: <valentineburley>
12:37fdobridge: <valentineburley> if (push_set_compute) {
12:37fdobridge: <valentineburley> set_layout_compute = vk_to_nvk_descriptor_set_layout(pipeline_layout->set_layouts[pPushDescriptorSetInfo->set]);
12:37fdobridge: <valentineburley> nvk_push_descriptor_set_update(push_set_compute, set_layout_compute,
12:37fdobridge: <valentineburley> pPushDescriptorSetInfo->descriptorWriteCount, pPushDescriptorSetInfo->pDescriptorWrites);
12:37fdobridge: <valentineburley> }
12:37fdobridge: <valentineburley>
12:40fdobridge: <!DodoNVK (she) 🇱🇹> Also ex-nouveau developer
12:49fdobridge: <triang3l> TIL null pipeline layout was a `VK_NV_per_stage_descriptor_set` feature rather than `VK_KHR_maintenance6` 👀
12:49fdobridge: <triang3l> (`dynamicPipelineLayout` to be more precise)
12:52fdobridge: <triang3l> though I guess that's trivial for NVK
12:53fdobridge: <triang3l> for 🪳 going to have to turn the insides of my `vkCreatePipelineLayout` into a "next iteration" function with a context structure 🤷♂️
12:55fdobridge: <triang3l> accumulating things like set base offsets in hardware binding spaces, which samplers are static, dynamic offset offsets (this part is relevant to all drivers btw)
14:25fdobridge: <dwlsalmeida> fyi: that indeed fixed it for me as well, thanks Dave
14:27fdobridge: <dwlsalmeida> @gfxstrand also fixed the VK_OUT_OF_DEVICE_MEMORY stuff, I think these two things were related
15:20fdobridge: <valentineburley> This is what I've got now:
15:20fdobridge: <valentineburley> https://gitlab.freedesktop.org/Valentine/mesa/-/commit/cf46f6b9407f14642372fed201204e643d6cb9ec
15:21fdobridge: <valentineburley> I haven't rerun the CTS yet, I was just wondering if you think this is the right direction
15:33fdobridge: <valentineburley> Oops, wrong commit, 1 sec
15:38fdobridge: <valentineburley> Here it is with CmdPushConstants2KHR with a loop too:
15:38fdobridge: <valentineburley> https://gitlab.freedesktop.org/Valentine/mesa/-/blob/b060cd1663d6fb43501db9a91b24605d1565ab00/src/nouveau/vulkan/nvk_cmd_buffer.c
16:40fdobridge: <valentineburley> This is what I've got now:
16:40fdobridge: <valentineburley> https://gitlab.freedesktop.org/Valentine/mesa/-/blob/585568ee58fabef333dfa53d644200f036a718a4/src/nouveau/vulkan/nvk_cmd_buffer.c#L600 (edited)
18:05fdobridge: <triang3l> What's that non-thread-safe `push_runout` for? :cursedgears: :blobcatnotlikethis:
18:06fdobridge: <triang3l> or is it thread-safe?
18:07fdobridge: <triang3l> but still a global array for something that seems local to a command buffer seems sus 🤔
18:45fdobridge: <gfxstrand> It's a very "safe enough" hack.
18:48fdobridge: <gfxstrand> Apart for updating offsets (I really need to fix that), we only ever write the pushbuf data and never read it. The runnout is used in the case where we've OOM'd the command buffer and so we can't provide more push data. This gives us a fixed blob of data that we can write to in that case. Since we're going to discard the whole command buffer anyway, it doesn't matter where those writes go as long as they don't segfault. So when we OOM, we p
18:53fdobridge: <gfxstrand> Yeah, I may have misunderstood what was going on there.
18:55fdobridge: <gfxstrand> Yeah, I think that looks fine.
18:55fdobridge: <gfxstrand> And it means we're ready for VK_NV_per_stage_descriptor_set
20:26fdobridge: <gfxstrand> Because NVIDIA can't do it. NVIDIA swizzles are entirely about switching around which bits of the texture data get red and have nothing to do with border color.
20:27fdobridge: <gfxstrand> Same with AMD or so I thought
20:29fdobridge: <gfxstrand> In other news, I kinda hate the NIL format table.
20:29fdobridge: <gfxstrand> I'm starting to think I just want a mapping from `PIPE_FORMAT` to render format and a "is color blending supported?" bit and then I just want to derive everything else from `util_format_info`
20:36fdobridge: <gfxstrand> There's just so much of that table that's a duplicate of what we already have in `util_format_description`
20:36fdobridge: <gfxstrand> Why are we doing this again in NIL?
20:38fdobridge: <gfxstrand> I mean, `util_format_description` is a bit clunky
20:51fdobridge: <gfxstrand> I do hate this CSV less. I will say that much
22:05fdobridge: <zmike.> I replied and said disregard when I remembered
22:06fdobridge: <zmike.> the profile is weird/broken
22:17fdobridge: <georgeouzou> Managed to get correct results for texel buffers when binding the heap as a descriptor buffer !
22:58fdobridge: <gfxstrand> 🎉
22:58fdobridge: <gfxstrand> @dwlsalmeida FYI: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28453