Artefacts (BC problem)

[GlinkoNeverhood]

I have a lot of graphic bugs (artefacts) in some games in winlator in my exynos2400 - i think that its BC problem.
here is formats from vulcan for my proc:
https://vulkan.gpuinfo.org/displayreport.php?id=38484#formats

i'm not a dev, just a simple user, but if im right vkd3d takes commands from D3D12 and converts them into corresponding Vulkan API calls, then, as I understand it, Vulkan sends data already to the GPU, at this stage, apparently there is some kind of texture handler? (probably a decompressor BC) which probably already renders them for output? the question is, is it possible to embed something like a texture handler in a different format in this chain?
D3D12 - > VKD3d -> Vulkan -> BC -> GPU -> Render (image)
something like this -
https://github.com/jhinzuo/bcdec

mb its not a correct question to place it here. sorry for that.

[leegao]

Hi there @GlinkoNeverhood

Yes, in fact that approach is exactly what Vortek does:

D3D9-12 -> 
DXVK / D3D12 -> 
libvulkan_vortek.so -IPC-> 
libvortekrenderer.so (*) -> 
libvulkan.so -> 
libvulkan.adrenoXXX/mtkXXX/libvulkan.turnip.so/... -> 
mali_kbase.ko/adreno.ko -> 
GPU

From here, the GPU performs the necessary computes and rendering onto an output image, which is then sent back to the application to present (actually show the image to the end user)

Of special interest is that libvortekrenderer.so (*), which intercepts the Vulkan APIs from the application, and emulates BCn support by decompressing BCn texture data on the fly into uncompressed (what's typically known as rgba8_unorm) image data using, exactly as you mentioned, bcdec (at least I believe it's bcdec as the structure and the # of passes per format mirrors bcdec)

For this project, since it's more of a programming challenge for myself, I'm actually setting out to perform this decompression using GPU-assisted mini-programs (called compute shaders in the gfx programming world). With bcdec, what you're effectively doing is:

1. Take the compressed data
2. On the CPU (an arm64 processor), decompress it, maybe with advanced vectorization to speed things up a bit, into a temporary memory storage
3. Upload that temporary memory storage to the GPU, and then later copy that storage into the final image

This has a couple of drawbacks:

1. BCn decoding is a (set of) extremely high-parallelism friendly algorithms. They can heavily benefit from hardware acceleration with a GPU because it's designed to independently decode small blocks of the image in parallel. Doing this on the GPU is much much faster than doing this on the CPU
2. Keeping all of the data on the GPU without additional CPU -> GPU uploads is also a major source of slowness in graphics programming, so using a GPU-side decompressor will avoid the IO and battery problems associated with moving memory around (that's typically the biggest power draw from desktop GPUs, though it's somewhat mitigated with integrated vram on mobile devices, reducing CPU->GPU IO is still good practice)
3. Lower RAM usage - in order to perform CPU-side decompression, you need to have a. the original compressed data buffer, b. the original final uncompressed image buffer, and c. the temporary staging buffer that must hold the uncompressed data. The GPU-side design allows us to bypass the temporary staging buffer completely. This is usually not too big of a deal, but many game engines will try to stuff as many texture loads as they can in one go, so these staging buffers may stick around with lots of other staging buffers and quickly lead to OOMs