Thanks for the detailed report. Is there any real app that even runs into this, and is this causing real issues right now? Don't think I've ever seen this.
I have some ideas; 99.99% of the time we suballocate buffers from something larger anyway so in those cases we can just use the backing storage and round up to the nearest multiple of 4 (or even all the way up to 256, since that's our minimum allocation alignment), and if for whatever reason we have a dedicated VkBuffer with a weird size we can just copy from the zero buffer.
Hi, sorry for taking a bit of time to respond. Yes, this does happen in some games I was testing with DXVK (Flat Out 2 to name one). It's not causing any visual issues as far as I know, just validation errors which I noticed while going through them.
Nothing extracted yet.
System information
Log files
Issue description
This validation error is caused by trying to clear a buffer with a non-multiple of 4 size (as a multiple of 4 is required by
vkCmdFillBuffer) which happens in some games. Currently DXVK attempts to mitigate this by aligning the size to 4 here, but aligning upwards violates another requirement ofvkCmdFillBuffer, specifically that the clear size must be smaller than the buffer size, leading to this validation error.Unfortunately Vulkan seems to have no good way to clear a buffer like this with the fill command, even using
VK_WHOLE_SIZEwill only fill to the nearest smaller multiple of 4, leaving a few bytes at the end uncleared potentially. As such the best fix to this is probably to usealignDowninstead ofalignto mimic the behavior ofVK_WHOLE_SIZEand to eliminate this validation error. This buffer clearing seems to be only done for compatibility anyways (e.g. for games erroneously relying on buffers to be initialized with zeroed contents even though it's meant to be undefined), so missing clearing a few bytes at the end of the buffer probably isn't the end of the world, but maybe there's a better solution than this.