1 Commits
Author SHA1 Message Date
LibretroAdmin 74772279e0 tools/rend: textures made on the GPU against the CPU's, byte for byte
texdecode_test.sh builds texdecode_test.c, a C program, against the
texture cache itself (core/rend/TexCache.o, through the small C++ shim
texdecode_cpu.cpp) and runs it on a Vulkan device - Mesa's software one,
lavapipe, when it is installed - with the validation layer on when that
is.

Close to 8000 textures: every pixel format, the reserved one too;
twiddled, compressed, planar and planar compressed; with and without
mipmaps, every mipmapped size, and sizes from 8x8 to 1024x1024 square and
not; planar ones with no stride, narrower, wider and empty strides, and
running into the end of video memory; paletted ones with every palette
format and random selections, as colours and as the indices the GPU
looks up itself; 16-bit formats to 16 bits and to 32; Force Texture LOD0;
then 2000 random ones. Each is made by the texture cache, which converts
it on the CPU and says what it would hand a renderer that converts on
the GPU. From those bytes the C text of the kernel, and then the kernel
on the device, into images made as the renderer makes them, have to
make every level the CPU made, byte for byte. A planar 16-bit texture
the renderer copies to its image as it is has to read, texel by texel,
as the same colour the CPU's texels do.

The script also builds the header as C89 and C++, compiles the three
GLSL kernels and the HLSL one (texdecode_kernel.hlsl, the shape a
Direct3D renderer will have) with glslangValidator, and checks that
core/rend/texdecode_text.inc is still the header ('update' makes it
again).
2026-10-15 13:48:14 +02:00