03:55fdobridge: <gfxstrand> Ugh... stupid runpm bug...
04:04fdobridge: <gfxstrand> Now that I set `nouveau.runpm=0`, maybe the CTS run on my laptop won't die randomly. 😩
04:05fdobridge: <gfxstrand> I would bet a good chunk of our extant fault bugs are some variant of that.
07:09fdobridge: <airlied> the number of times I gave up on llvmpipe/lvp conformance because it I was too lazy to deal with local patches
07:10fdobridge: <airlied> it was always, burst of effort, open gerrits, forget about it for 3-4 months
07:16ahuillet: airlied : in case you missed it above, do you recall what tests were failing with your S8 UINT patch? what I have right now seems to pass the vkcts tests that match "s8uint" (I grepped through the case list)
07:16ahuillet: and it's.. not very different from what you had, so...
08:12fdobridge: <airlied> Oh maybe we fixed in elsewhere in the meantime I should throw a CTS run at my machine next week
08:20ahuillet: airlied : I shared my patch in /query for you to try, just so we're looking at the same thing.
08:20ahuillet: there's one unrelated but connex thing in nouveau/nil/image.rs that I found interesting, it is the default to page kind 0x0 (pitch linear)
08:21ahuillet: I've hit seen that default case hit for format 53 which IIRC is some ARGB_UNORM thing, which would deserve not being pitch linear
12:52harimoto: bitsets and this ai is so unprofessional programming it's just so bad code property graphs are also scala spec, so they rely on such things, and random-edge-coding and multiset-compressor i can not read at all, do not understand, long story short, it's just much quicker and simpler to code your own compiler.
15:51fdobridge: <gfxstrand> ahuillet: On Turing+, you only need a PTE kind for Z/S. Everything else gets all the information it needs from the texture headers.
15:51fdobridge: <gfxstrand> That said, that may only be true for uncompressed. I wouldn't be at all surprised if compressed doesn't need a PTE kind
15:51fdobridge: <gfxstrand> And... That might explain why I never saw compression do anything at all on Turing. 🤔
16:00fdobridge: <loothelion (Liam Middlebrook)> There are some non Z/S kinds that exist on Turing+: https://github.com/NVIDIA/open-gpu-doc/blob/2ef75cf8d6cc6311625c772171834c465e0319d0/manuals/turing/tu104/dev_mmu.ref.txt#L22
17:11fdobridge: <!DodoNVK (she) 🇱🇹> Why could DOOM be triggering this assert on :triangle_nvk:?: `m\SteamLibrary\steamapps\common\DOOM\DOOMx64.exe: ../mesa/src/vulkan/runtime/vk_buffer.h:69: vk_buffer_range: Assertion 'range + offset <= buffer->size' failed.`
18:38fdobridge: <gfxstrand> Yeah, those COMPRESSIBLE ones look tasty.
18:39fdobridge: <gfxstrand> It's trying to go out of bounds somewhere. I can't know where without a backtrace.
18:39fdobridge: <!DodoNVK (she) 🇱🇹> So that `assert` is actually accurate? 🤔
18:40fdobridge: <gfxstrand> Probably. That one's pretty reliable
18:44fdobridge: <ahuillet> if you're using a PITCH_LINEAR PTE kind I think there's something wrong, but I'll double check your claims.
18:44fdobridge: <ahuillet> probably not the immediate priority anyway.
18:44fdobridge: <gfxstrand> Also, I should pull those headers into Mesa if the licenses work out.
19:18fdobridge: <!DodoNVK (she) 🇱🇹> Is a range of `-1` concerning?
19:19fdobridge: <!DodoNVK (she) 🇱🇹> I think it's probably `VK_WHOLE_SIZE`
19:45fdobridge: <!DodoNVK (she) 🇱🇹> I currently have `Buffer size exceeded 2 (range 65536, offset 0, size 49152)` (this is inside `nvk_buffer.h`)
19:54fdobridge: <!DodoNVK (she) 🇱🇹> I isolated the issue further to nvk_UpdateDescriptorSets() in the `VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER`/`STORAGE_BUFFER` path
19:56fdobridge: <pixelcluster> fwiw there’s an app bug in doot eternal triggering that same assert on radv as well
19:56fdobridge: <pixelcluster> could be a similar story
19:59fdobridge: <!DodoNVK (she) 🇱🇹> This is 2016
19:59fdobridge: <pixelcluster> I know
20:52fdobridge: <gfxstrand> That's not -1, though. That's `-1_i16` but not VK_WHOLE_SIZE. Are we casting through a `uint16_t` somewhere?
20:53fdobridge: <!DodoNVK (she) 🇱🇹> That's the actual thing that triggers the assert
20:54fdobridge: <gfxstrand> If those numbers are accurate, that sounds very much like an app bug
20:55fdobridge: <!DodoNVK (she) 🇱🇹> So the only option is to add an app-specific workaround here, right?
20:56fdobridge: <gfxstrand> If the app is binding more than is in the buffer, there's not a lot of working around we can do. I guess we could clamp it.
20:56fdobridge: <gfxstrand> If the app renders okay in release builds, I wouldn't worry about it at all.;
20:56fdobridge: <gfxstrand> If the app renders okay in release builds, I wouldn't worry about it at all. (edited)
20:59fdobridge: <!DodoNVK (she) 🇱🇹> I have assertions enabled on my NVK package
21:00fdobridge: <!DodoNVK (she) 🇱🇹> So should I comment out that assert and see if the game works?
21:01fdobridge: <gfxstrand> sure
21:17fdobridge: <!DodoNVK (she) 🇱🇹> Ryujinx seems to still work (at least with homebrew) :triangle_nvk:
21:17fdobridge: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1228816354090422272/Screenshot_20240414_001338.png?ex=662d6b69&is=661af669&hm=cd45b80bc66c12771482c2c73852de3bac651756478e510012d1efd4a961362d&
21:37fdobridge: <huntercz122> GPU: 24
21:38fdobridge: <!DodoNVK (she) 🇱🇹> So should I test a higher resolution?
21:39fdobridge: <huntercz122> i thought it was gpu string
21:53fdobridge: <pac85> Nvidia gpu emulated on an nvidia gpu
21:56fdobridge: <!DodoNVK (she) 🇱🇹> Don't give Mary ideas for a native GPU backend