Need a test case to repro this with. The format doesn't exist in DXGI so it wasn't really tested, but even hacking it in manually doesn't trigger a crash here.
Based on the log it's trying to store stencil into a format that has no stencil aspect, I don't really see how this can happen if the frontend doesn't make invalid calls.
OK, I think I see the problem. For some stupid reason, we map all formats to D24S8 but use D24X8 as the 'packed' format, so we end up hallucinating a stencil aspect out of nowhere. Needless to say, this shouldn't happen, but it's probably easier to just paper over it in the backend for now.
Glad you could spot it, because the only use case I have for reproducing this involves D7VK and some now ancient games which are a bit of a pain to run even in Proton/Wine 😅. I'll check and get back to you on the fix in a bit.
Nothing extracted yet.
Ever since #5531 was merged, I've had failures (granted in D7VK) whenever D24X8 depth was read from or written to. D16 appears fine. Depth read/write support is needed in cursed early D3D because some games do their own depth on the CPU... yes, lovely indeed.
As to the crashes, I get the classic:
Assertion failed: !status && "vkCreateGraphicsPipelines", file dlls/winevulkan/loader_thunks.c, line 3578And just before that the backend is trying to do:
Here are the full logs: dxvk.log
Suppressing any D24X8 depth writes/reads magically makes things work again, at least to the point where affected games start just fine instead of crashing, however that will break rendering in some cases, for obvious reasons.
P.S.: This isn't happening in a MSAA context, just with plain old regular depth.