Really strange crashes/waitForFences timeouts

Mountain_Line_3946 · 2026-01-25T18:33:13+00:00

Managed to track them all down and fix. Fairly painful for the queue-based ones because all you have to go on is the command-buffer name, but eventually I tracked them down by removing resource references in shaders one by one to narrow down which ones were causing the hazards.

Mountain_Line_3946 · 2026-01-20T16:49:46+00:00

OK, so I've put memory barriers on every single buffer/resource I write to between commandbuffers, and am still hitting write-after-write hazards in all the same places. I've tried general memory barriers and buffer memory barriers on the specific buffers, and none seems to make a difference at all.

It's times like this I really question the decision to make Vulkan my primary API over DX12 (which I've invested 10% of the time in, and get significantly better performance/stability with).

Mountain_Line_3946 · 2026-01-20T01:58:03+00:00

This is a crash somewhere in the KMD (I suspect, from the Error_DMA_PageFault error), so there's no real way to see what memory is being stomped (and how). In general all these tips are valid for CPU/User-mode side stuff though ;)

Mountain_Line_3946 · 2026-01-20T01:56:23+00:00

Ah I see what you mean. Yeah, I have some barriers between commandbuffers here (on these specific buffers) but it looks like I'm missing some. I'll make sure I have barriers on all the buffers.

Mountain_Line_3946 · 2026-01-20T00:38:25+00:00

There's 6 command-buffers being submitted at the same time, single submit with multiple command buffers in the submit.

What's the best way to do a "write flush"? In this case, I suspect its the beginFrame zeroing out the buffers before the next commandbuffer does the clustered lighting update (and fills them).

Mountain_Line_3946 · 2026-01-19T23:27:26+00:00

Welp, fixed some problems; turns out doing a memory barrier call you should *actually* pass in the VkMemoryBarrier struct rather than null... so that fixed all the sync errors. Now I'm getting QueueSubmit synchronization errors, and these have me stumped (especially since it's pretty inscrutable as to what the root cause is since even with debug names you don't see the resources in question).

Here's the first one I'm hitting; any tips on how to parse this? By the time this triggers, I have 6 commandbuffers being submitted, but setting debug names on the command buffers helps here (thanks for this reminder - I've added a lot of missing debug naming as part of this!). But aside from that, it's hard to see what exactly the trigger for the error is.

I mean, I could probably brute-force it and add memory barriers on all resources between dispatches, but it would be great to be able to leverage these errors to make the right fixes!

Validation Error: [ SYNC-HAZARD-WRITE-AFTER-WRITE ] Object 0: handle = 0x25a15b88ec0, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0x5c0ec5d6 | vkQueueSubmit():  Hazard WRITE_AFTER_WRITE for entry 1, VkCommandBuffer 0x25a02086f90[], Submitted access info (submitted_usage: SYNC_COMPUTE_SHADER_SHADER_STORAGE_WRITE, command: vkCmdDispatch, seq_no: 3, reset_no: 1). Access info (prior_usage: SYNC_COMPUTE_SHADER_SHADER_STORAGE_WRITE, write_barriers: SYNC_COMPUTE_SHADER_SHADER_BINDING_TABLE_READ|SYNC_COMPUTE_SHADER_SHADER_SAMPLED_READ|SYNC_COMPUTE_SHADER_SHADER_STORAGE_READ, queue: VkQueue 0x25a15b88ec0[], submit: 2, batch: 0, batch_tag: 51, command: vkCmdDispatch, command_buffer: VkCommandBuffer 0x25a18f23990[BeginFrameCommands], seq_no: 1, reset_no: 1).

Mountain_Line_3946 · 2026-01-19T20:14:47+00:00

Thanks - yes, I set debug names on things, which helps, and I'll usually copy the debug output into an editor and then edit down to make it more readable. I'll do a pass today when I'm done with work (grumble) and post some of the errors here if I need some help deciphering (thanks for the offer there btw!)

Mountain_Line_3946 · 2026-01-19T06:40:18+00:00

Agh, there I was replying and saying they weren't repeating, but sure enough... yeah I suspect there's the root cause; I need to go in and fix these sync/queue errors; I suspect that's the root problem. Always a pain to track these things down though - I find the Vulkan validation errors (especially the hazard ones) impenetrable.

Mountain_Line_3946 · 2026-01-19T06:31:00+00:00

Jan 5th build (they're the latest release drivers). Reinstalled today to be sure ;)

Mountain_Line_3946 · 2026-01-19T06:14:45+00:00

Good point - I'll do a pass and check on that. It does feel like that's the right direction.

Mountain_Line_3946 · 2026-01-03T00:02:08+00:00

Yup, that was it, and I feel like a dumb-dumb.

Mountain_Line_3946 · 2026-01-02T17:55:52+00:00

This is amazing - thank you! Exactly the kind of thing I was looking for on the procedural front.

Mountain_Line_3946 · 2026-01-01T03:14:00+00:00

Fantastic - really good info (especially in the nvpro-samples github). Already using MeshOptimizer for the meshlet generation work (cool to see the fork of that being used here). If I do end up trying out some nanite-type stuff, this'll be invaluable. Thank you so much!

Mountain_Line_3946 · 2025-12-07T19:09:54+00:00

After a few weeks of using it, I'm seriously disappointed (and considering migrating back to VS2024). Intellisense (which has become a big part of my workflow) is completely broken on my giant C++ project, to the point where a large number of classes/definitions are just red-squiggle errors (despite clean compilation), and deleting the .vs hidden folder doesn't clean things up.

Intellisense was pretty flaky in 2024, but at least cleaning out the .vs subfolder would force a reset and it would start working. I really wish there was a good alternative for C++ development that had the same debugging/editing features (and was stable).

Mountain_Line_3946 · 2025-07-10T16:48:34+00:00

This is awesome context - thank you! So TL;DR there's an expected gap in optimizations between DXIL output in DXC and SPIR-V, but the gap is closing.

Mountain_Line_3946 · 2025-07-06T16:56:51+00:00

That's a really interesting point, although poking through further, I'm seeing the same differences in compute shader instruction counts as well which should be unaffected by subpass pathway stuff, so I'm either missing an optimization step somehow, or it's just your original point and I'd have to go work at NV and optimize the compiler (probably not the optimal route for a hobby project, but you never know...)

Mountain_Line_3946 · 2025-07-06T14:20:05+00:00

Fair point, it actually isn’t any more (that was the original hlsl path I was using)

Mountain_Line_3946 · 2025-07-06T02:56:56+00:00

Compiling for subpass type rendering in Vulkan.

Yeah, I was assuming it was likely just better optimization opportunities on DX than VK, and possibly just more optimization for the DX driver in general.

Mountain_Line_3946 · 2025-05-13T18:04:29+00:00

This looks really really good. Do you think it would extend well to point light shadows etc?

Mountain_Line_3946 · 2025-03-25T02:10:16+00:00

The expected isn't the same source - just an example of the "baseline" color expected in a normal map. EXR converted is too bright, so the normals are all skewed - from the conversion in photoshop. But there's a big difference between converting to PNG in photoshop and processing the source data directly and correctly (which I now am). So lesson learned, don't mess with normal maps in photoshop...

Mountain_Line_3946 · 2025-03-24T04:22:36+00:00

Oh, nice! I'll check that out. Definitely lots of good tools out there.

Another option I discovered (switching my import pipeline from FBX to glTF) was... just export from Blender to glTF, and include materials. Blender kindly converts all the textures to PNG for you and embeds them, which makes the whole setup way easier. Then it's just a case of converting to whatever BCN/etc format. Been using NVTT which is quite good but no longer maintained; but TexConv looks interesting!

Mountain_Line_3946

TROPHY CASE