06:02 fdobridge: <n​anokatze> tbf desc buffer intent in proposal is just "replace vkUpdateDescriptorSets with memcpy" 🐸
06:02 fdobridge: <n​anokatze> so I guess it wasn't really supposed to be a fix for indirection on nv and intel
06:37 fdobridge: <d​jdeath3483> It does because the application is now aware of the HW limits, while before you would have to support unlimited amount of descriptors
06:38 fdobridge: <d​jdeath3483> namely VkPhysicalDeviceDescriptorBufferPropertiesEXT::maxResourceDescriptorBufferRange, maxSamplerDescriptorBufferRange, samplerDescriptorBufferAddressSpaceSize, resourceDescriptorBufferAddressSpaceSize & descriptorBufferAddressSpaceSize
06:44 fdobridge: <n​anokatze> what I meant is that the drivers still have an option to do the old thing and just have their descriptors be indices
06:48 fdobridge: <n​anokatze> well saving for texel buffer things, those are yeah
06:48 fdobridge: <n​anokatze> well save for texel buffer things, those are yeah (edited)
06:50 fdobridge: <d​jdeath3483> true, but at least for intel that's a win not to have an indirection
06:50 fdobridge: <n​anokatze> I guess on the upside it works as a cross-vendor VALVE_descriptor_set_host_mapping
06:50 fdobridge: <d​jdeath3483> double digit
06:52 fdobridge: <n​anokatze> ye I absolutely agree removal of indirection is nice and desirable, it's just that if removal of indirection was the intent behind the ext, it appears it was badly communicated internally somehow because clearly at least one vendor didn't really get the memo and didn't request appropriate changes
06:52 fdobridge: <n​anokatze> one of the intents
06:52 fdobridge: <n​anokatze> ye I absolutely agree removal of indirection is nice and desirable, it's just that if removal of indirection was one of the intents behind the ext, it appears it was badly communicated internally somehow because clearly at least one vendor didn't really get the memo and didn't request appropriate changes (edited)
06:53 fdobridge: <d​jdeath3483> from what I remember one of nv's heap is too small to meet the dx12 requirement
06:54 fdobridge: <d​jdeath3483> so they have no other choice than indirection
06:54 fdobridge: <d​jdeath3483> I guess they optimize the hell out of it enough that it doesn't matter
06:55 fdobridge: <n​anokatze> the sampler heap indeed maxes out at 4096 samplers, but that's still somewhat above dx12 limit
06:58 fdobridge: <n​anokatze> db doesn't provide any mechanism for driver-internal shaders where src is an image (so copies, blits, resolves) to work without changing heaps to driver-internal ones, so that kinda sucks, and I think there's also some issues with combined image-sampler
10:29 fdobridge: <r​edsheep> @mohamexiety Just getting back around to attempting to test your modifiers draft and I have a new build error
10:29 fdobridge: <r​edsheep> ```/usr/bin/ld: src/nouveau/nil/liblibnil.a(libnil.libnil.c59c5db00e17beea-cgu.0.rcgu.o): in function `libnil::modifiers::drm_format_mods_for_format':
10:29 fdobridge: <r​edsheep> libnil.c59c5db00e17beea-cgu.0:(.text._ZN6libnil9modifiers26drm_format_mods_for_format17h8fb25a14dc4e52acE+0x171): undefined reference to `drm_format_mod_block_linear_2D'```
10:38 fdobridge: <m​ohamexiety> that is odd.. it builds fine here on a clean setup
10:38 fdobridge: <r​edsheep> Mine should be clean as well, I am not applying it as a patch on top of anything else. I am building a package with your branch as the source
10:41 fdobridge: <r​edsheep> I wonder what could be different. Here is the more complete error:
10:41 fdobridge: <r​edsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1233729747821789264/modifiersBuildError.txt?ex=662e27dd&is=662cd65d&hm=0db819bd04ec09297007ef887135748600c5d4dcb8b8399fd390e6c922099174&
10:48 fdobridge: <r​edsheep> I was hoping to see if it fixes gamescope and gets my zink session running faster. I am not sure what I could be doing wrong, my environment and this same script builds mesa main just fine
10:52 fdobridge: <m​ohamexiety> I did test it with gamescope and there's something missing still (it chooses the wrong format mod, likely I messed up the modifier selection), but I need to do some stuff for uni these days so couldn't look into it much
10:53 fdobridge: <r​edsheep> Ok no worries, I will set that aside and go back to trying to figure out why heaven is flashing blue
11:01 fdobridge: <m​ohamexiety> yeee sorry for disappointing :c I'll look into it later today/tomorrow
11:02 fdobridge: <r​edsheep> You're all good, focus on your school, my tinkering is much less important
11:59 fdobridge: <r​edsheep> I have managed to get it to be pretty consistent to get captures of the blue frames in renderdoc, unfortunately every time I get close to what appears to be the problematic area it crashes
12:07 fdobridge: <r​edsheep> Wonderful, the crashes are segfaults in libvulkan_nouveau.so
12:07 fdobridge: <r​edsheep> ```[ 7447.933931] ReplayManager[52668]: segfault at 0 ip 00007f85c4ee1161 sp 00007f85967fe7e0 error 4 in libvulkan_nouveau.so[7f85c4e5b000+57b000] likely on CPU 11 (core 11, socket 0)
12:07 fdobridge: <r​edsheep> [ 7447.933941] Code: 89 f7 48 c1 ef 20 c7 00 18 0e 03 a0 89 78 08 89 70 0c 48 89 93 a0 27 00 00 41 83 c4 01 49 83 c5 08 41 39 cc 0f 84 90 00 00 00 <4b> 8b 04 2f 48 85 c0 74 e6 31 d2 4d 85 f6 74 04 4b 8b 14 2e 48 8b```
12:37 fdobridge: <r​edsheep> In case I don't get to the bottom of this myself here are capture settings that should get 1-3 blue frames pretty consistently
12:37 fdobridge: <r​edsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1233758838277144617/blueFrameGrabber.cap?ex=662e42f5&is=662cf175&hm=23c5a9eff892c068954534123a186a9e8f8341c9830252ffe06e9ddf60f5cd6d&
12:38 fdobridge: <r​edsheep> Just edit the directories to point at your download of unigine heaven and that should do it. If I need to upload a capture myself I will, but it's probably easier to locally capture.
20:29 f_: karolherbst: I've been having several kernel oopses related to nouveau lately, but no graphics lockup
20:29 f_: I'll have a look tomorrow (dmesg etc), just wanted to let you know.