00:11redsheep[d]: If your display is oled I think all of the triangles are organic
00:12gfxstrand[d]: No, just the pixels are organic. The triangles may still be synthetic or contain NaNs or something.
00:13redsheep[d]: We just need to build a gpu entirely out of NaN gates and we can achieve the ultimate ideal
00:13redsheep[d]: https://www.youtube.com/watch?v=5TFDG-y-EHs
00:14gfxstrand[d]: But with NVK, we filter out all those NaNs and degenerate triangles for you and ensure that you only get the highest quality organic, non-GMO triangles.
00:15redsheep[d]: Aww the GMO triangles were my favorite
00:16gfxstrand[d]: Hrm... Does GMO mean "Geometry shader MOdified"? Because if it does I should probably turn off `.geometryShader`. :frog_clown:
00:17redsheep[d]: I'm curious what performance you'll see in doom eternal, last time I tested it was... pretty rough
00:18karolherbst[d]: ahhhhh...
00:18karolherbst[d]: mesa doens't implement `NonWritable` correctly...
00:18karolherbst[d]: faith will hate this
00:18karolherbst[d]: "Missing before version 1.4: An object in the Private or Function storage classes. This indicates that this module does not write to the memory holding the variable. It does not prevent the use of initializers on a declaration."
00:18gfxstrand[d]: Uh oh
00:18karolherbst[d]: the last part :blobcatnotlikethis:
00:19gfxstrand[d]: You can't use an initializer on an SSBO. We're fine.
00:19karolherbst[d]: yeah, but it's crashing on me on private
00:19gfxstrand[d]: What's crashing?
00:19karolherbst[d]: `nir_lower_vars_to_ssa` asserting
00:20karolherbst[d]: the "assert(node->path.path[0]->var->constant_initializer == NULL && node->path.path[0]->var->pointer_initializer == NULL);" fails
00:20gfxstrand[d]: That's just because you're not calling lower_initializers
00:20karolherbst[d]: I think I do...
00:21gfxstrand[d]: lower_initializers should be one of the first passes called.
00:21karolherbst[d]: ehh wait..
00:21gfxstrand[d]: We only don't do it in spirv_to_nir because it's a pain to know where to put the initializers there.
00:21karolherbst[d]: which pass specifically do you mean
00:21gfxstrand[d]: nir_lower_variable_initializers
00:21karolherbst[d]: yeah.. I call that one
00:21karolherbst[d]: well
00:22karolherbst[d]: only on mem_constant...
00:22karolherbst[d]: oops
00:22karolherbst[d]: mhh
00:22gfxstrand[d]: Yeah, it needs to be called on lots of stuff
00:22karolherbst[d]: and on function_temp...
00:22karolherbst[d]: I might need to debug it then...
00:24karolherbst[d]: yeah ehhh... apparently I call it too late, my fault then
00:25gfxstrand[d]: We could potentially make `vars_to_ssa` initializer-aware. I'm not sure how hard that would be. But it's easier to have that logic in one place, especially since initializers are kinda dumb anyway.
00:25karolherbst[d]: tell me all about them
00:26karolherbst[d]: that reminds me
00:26karolherbst[d]: global var initializers :blobcatnotlikethis:
00:26karolherbst[d]: the biggest pain of them all
00:27gfxstrand[d]: Yup
00:27gfxstrand[d]: Because those have to be their own kernel. :frog_clown:
00:29karolherbst[d]: soo recently I've added an interface to gallium (or have an MR) so I can assign addresses to buffers, would be real funny if I can just pass in a constant for the base address ~~but then I realized I still have to deal with derefs and on the spirv_to_nir level that's just pure pain~~
00:30karolherbst[d]: I think I should just complete writing the code....
00:31karolherbst[d]: actually.... uhm....
00:32karolherbst[d]: the thing is... the driver also can't just replace the underlying buffer for no reason on those allocations.. pain
00:37gfxstrand[d]: DOOM on the Vulkan spec:
00:38gfxstrand[d]: https://tenor.com/view/guidlines-pirates-of-the-caribbean-hector-babossa-georffrey-rush-gif-7844913
00:38karolherbst[d]: mhh since when are we supporting SPIR-V 1.6 btw?
00:38karolherbst[d]: heh
00:38gfxstrand[d]: karolherbst[d]: Since a long time ago, I though.
00:38karolherbst[d]: yeah, just curious because I haven't add support for anything beyond 1.4 🙃
00:39karolherbst[d]: 1.5 works, but 1.6 fails but I'm sure that's something weird going wrong somewhere
00:40karolherbst[d]: "constexpr spv_target_env spirv_target = SPV_ENV_UNIVERSAL_1_5;" ah yeah...
00:41karolherbst[d]: oh wow.. that's old
00:41karolherbst[d]: 1.6 that is..
00:42redsheep[d]: gfxstrand[d]: What guidelines are being crossed?
00:43gfxstrand[d]: Buffer ranges having to be in-bounds for one.
00:44redsheep[d]: Oh yeah, this is doom 2016? I remember that being one of the issues, it helped make it run to turn off the checks
00:45karolherbst[d]: .... oh no
00:47gfxstrand[d]: Making it a clamp gets it further but a door is missing and it crashes when I try to open the missing door.
00:49karolherbst[d]: that little OOB access, I'm sure it's entirely fine
00:50redsheep[d]: The game is just thinking OOTB
00:50karolherbst[d]: OOBing but instead of the player it's the game
00:53redsheep[d]: I wonder whether it's a bug, or the crazy devs at id doing some insane hack to optimize
00:54karolherbst[d]: both
00:54karolherbst[d]: or they tested against nvidia and nvidia simply goes: bound check just hurt perf sooo..... let's not
00:55redsheep[d]: It's funny, the hardware has bounds checking... I wonder if that just exists for the sake of cuda or safety stuff
00:56orowith2os[d]: probably enterprise
00:56karolherbst[d]: nvidia doesn't have bound checking on buffers
00:56karolherbst[d]: it's just raw memory loads
00:57karolherbst[d]: or well.. if you consider your MMU the bound checker, I guess that's valid
00:57redsheep[d]: I remember there at least being bounds checking on something that Faith had to deliberately turn off. Not sure what it was checking on
00:57karolherbst[d]: usually you do that in software
00:58redsheep[d]: It wasn't turning off a software check, some change to tell the hardware not to throw exceptions
00:58karolherbst[d]: well you can do that on textures
00:58redsheep[d]: That's probably what it was
00:59redsheep[d]: Soooo... that means doom is doing OOB on both textures and buffers then. Fun
00:59karolherbst[d]: or images
00:59karolherbst[d]: but whatever, gotta go fast
01:02mhenning[d]: I think it was load/store local iirc
01:03karolherbst[d]: well the ops on local don't have bound checks either, though there might be global flags somewhere for it
01:03karolherbst[d]: or maybe on the class?
02:45gfxstrand[d]: They do (sort of). They don't fault. They throw a shader exception, which you can turn off.
02:51gfxstrand[d]: redsheep[d]: Doom is just OOBing on buffers. Textures and images bounds-check for free.
02:51gfxstrand[d]: I'm not sure if the fault is an OOB or if they're just messing up their memory management.
09:40karolherbst[d]: probably the latter
09:41karolherbst[d]: well at least it wouldn't hurt to check what happens without bound checks
09:44Pheoxy[AWSTUTC8][m]: gfxstrand[d]: I see your doing some more work on vkd3d-proton. Found an interesting issue with smoke and fire effects weirdly relating to HDR in logs with NVK_DEBUG=all just spits out a heap of HDR shader stuff. Found this specifically with Warthunder which is vulkan and not vkd3d-proton but it seems I get the same issues with Warframe with DX12 as backend. Massive FPS drops down to 3-5 FPS.
09:44Pheoxy[AWSTUTC8][m]: I also if you wouldn't mind I would like to add this to your tracker sheet at https://gitlab.freedesktop.org/mesa/mesa/-/issues/11066 for Warthunder and possibly Warframe when I do some more debugging.
09:44Pheoxy[AWSTUTC8][m]: I was using mesa-24.3.4 with kernel-6.12.11 on NixOS.
09:46Pheoxy[AWSTUTC8][m]: Trying to find an easy way to contact you because I read you didn't want to clog up the issue but I remembered matrix just in time.
09:47Pheoxy[AWSTUTC8][m]: * logs with `NVK_DEBUG=all, * NVK_DEBUG=all` just
13:54zmike[d]: gfxstrand[d]: igpu disabled in bios, problem still occurs
13:55zmike[d]: NVIDIA GeForce RTX 2070 (NVK TU106)
14:51pixelcluster[d]: redsheep[d]: Eternal has the issue too
15:12gfxstrand[d]: zmike[d]: Ugh... I wonder what we're doing differently. Mine is also TU106. :blobcatnotlikethis:
15:13gfxstrand[d]: Can you get me a backtrace?
15:16zmike[d]: the backtrace isn't super useful cuz it's a whole chain of fuckery
15:16zmike[d]: detecting rebar enables HIC, which hits the hackaround you have to delete device-local memory, which breaks texture creation
15:16zmike[d]: and deleting your hackaround causes stuff to just silently not work
15:58gfxstrand[d]: Then why can't I repro?!?
15:58gfxstrand[d]: 😫
16:01gfxstrand[d]: It doesn't delete all device-local, just host-invisible.
16:02gfxstrand[d]: There should still be a BAR-sized heap of device-local available.
16:38zmike[d]: There is
16:38zmike[d]: But zink refuses to use it since it's not detected as a texture heap
16:38zmike[d]: Which is beside the point
17:22gfxstrand[d]: Wait, why is it not a texture heap. You can put textures anywhere.
17:39zmike[d]: can, yes, but I've avoided putting swapchain images on rebar heaps
17:40gfxstrand[d]: So it's a swapchain image?
17:40gfxstrand[d]: I'm trying to understand what case is actually blowing up here.
17:41zmike[d]: it's some kind of rendertarget image, I don't recall if swapchain or not
17:41zmike[d]: but this is just incidental
17:42zmike[d]: with a rebar setup, that HIC workaround should be removed
17:42zmike[d]: and yet removing it breaks things
17:42gfxstrand[d]: Wait, so you are in a ReBAR setu
17:42zmike[d]: yes, that's what I've been saying all along
17:43gfxstrand[d]: In that case, it should do nothing because we should be advertising 100% mappable types.
17:43gfxstrand[d]: So that loop is a noop
17:44zmike[d]: it is not
17:44gfxstrand[d]: Also, I didn't think ReBAR worked on Turing.
17:44zmike[d]: but also I'm not working any more today, so if you need further info e.g., vulkaninfo output that'll have to wait
17:44gfxstrand[d]: That's fine. We can work on it next week.
17:45zmike[d]: rebar does exist on the 2000 series, and it does seem to work on blob
17:53karolherbst[d]: yeah.. there are GPUs where you can enable it through firmware updates as well
17:53karolherbst[d]: it doesn't work on mine...
17:54karolherbst[d]: but it's like a FE early model thing
18:41tiredchiku[d]: zmike[d]: since when :myy_TinyThink:
18:42tiredchiku[d]: prop driver doesn't enable rebar on turing
18:42karolherbst[d]: it does
18:42karolherbst[d]: on some GPUs
18:43karolherbst[d]: turing GPUs can get rebar support through a vbios update
18:43tiredchiku[d]: source?
18:43karolherbst[d]: ~~trust me~~ https://github.com/terminatorul/NvStrapsReBar
18:43tiredchiku[d]: that was for ampere back when nvidia was rolling out rebar
18:44tiredchiku[d]: karolherbst[d]: yeah, I did that on my laptop
18:44karolherbst[d]: but there are some official docs
18:44tiredchiku[d]: which is why I'm asking :p
18:44tiredchiku[d]: I looked into rebar on turing, nvidia doesn't support it officially anywhere
18:45karolherbst[d]: mhhh
18:46karolherbst[d]: _maybe_ it was vendors enabling it through bios updates...
18:46tiredchiku[d]: :doubt:
18:47tiredchiku[d]: if that was the case I could've downloaded a dumped vbios
18:47tiredchiku[d]: instead of learning to patch uefi firmware
18:47tiredchiku[d]: unless you mean motherboard BIOS updates
18:47karolherbst[d]: motherboard bios
18:48tiredchiku[d]: which I also couldn't find anything about for turing
18:48tiredchiku[d]: apart from ReBAR-UEFI and NvStraps
18:49karolherbst[d]: doesn't help that the results are swamped with the hacky thing 😄
18:49tiredchiku[d]: :p
18:50karolherbst[d]: yeah dunno.. apparently it was indeed ampere where nvidia allowed enabling rebar, but there is some chatter about mb vendors patching it into their uefi firmware
18:50karolherbst[d]: but
18:50karolherbst[d]: maybe it's just the same hack
18:51karolherbst[d]: and like "custom firwmares"
18:51tiredchiku[d]: :roojuice:
18:52tiredchiku[d]: https://nvidia.custhelp.com/app/answers/detail/a_id/5165/~/nvidia-resizable-bar-firmware-update-tool
18:52tiredchiku[d]: the rebar fw update was for ampere only
18:57karolherbst[d]: oh no
18:58tiredchiku[d]: ?
19:10karolherbst[d]: "oh no" as in "oops, guess I'm wrong here"
19:11tiredchiku[d]: ahhh 😅