eglantine-cirakg/src/video_core/texture_cache/image_base.h, branch nx2

texture_cache: back large sparse 2D images by sparse block

2026-11-01T16:29:56+00:00

Mario Kart World's nine world-sized masks (R8 16384x16384, RG16 and R16 8192x8192, 170-341 MB each) live in sparse regions the game maps its own memory into, a few MiB of each. Since a mapped tile counts as written, the texture cache backed and uploaded each mask in full: about 2.9 GB of device memory, and a whole-mask upload for every tile the game streamed in. Such images (single layer, one texel per block, colour, in a sparse region, 32 MiB or more) are now unbacked SparseTiles images. The texture cache records the guest ranges written to them; Image::BindTiles gives the host sparse blocks under those ranges memory, and only those rectangles are unswizzled, a row of whole GOB blocks at a time, and uploaded. A new image starts with the tiles the game maps there (nx2:gpu 216 now records them per 64 KiB), or the written blocks where it maps none. Unmapped tiles keep their blocks and are loaded as zeros. Checked against the full unswizzle on 400 ordinary game images (row padding, mip chains, odd sizes): no row differs. Not on AMD drivers, which cannot sample images with unbound memory. Mario Kart World title screen, 150 s, against backing the masks whole: dedicated VRAM 6.6 -> 6.2 GB, shared 1.0 -> 0.3 GB, peak 8.2 -> 6.9 GB.

vulkan: bind memory to sparse terrain arrays layer by layer

2026-10-30T16:27:04+00:00

The written part of Mario Kart World's sparse terrain arrays is small: 13-26% of their blocks. The two 1.45 GB ASTC arrays were backed in full on the host, and the two 5.8 GB BC6H arrays, too large to back, stayed unbacked, so what the game streamed into them never showed. A color array of 32 MiB or more lying in one sparse region, in a format uploaded layer by layer (huge ASTC arrays decoded on the GPU, or formats sampled as they are), is now a sparse resident image (SparseLayers). When it is refreshed, the layers written since (or, for a new image, the layers any of whose blocks was written) get device memory bound with vkQueueBindSparse (under the submit lock, waited on, as the multi-range buffer cache does) and only those layers are uploaded. Unwritten layers read zero. One image binds at most 768 MiB (384 MiB on GPUs with less than 7 GiB); rendering into one binds all its layers. Mario Kart World, 180 s: the ASTC arrays hold 1.4 MiB per written layer, four BC6H layers (341 MiB) now have their data, device memory in use 4.8-5.0 GB instead of 6.0-7.1 GB with the texture cache below its collection threshold, 16.8-17.2 ms average frames, peak working set 13.4 GB.

texture_cache: give images over unwritten sparse blocks no device memory

2026-10-30T16:27:04+00:00

Mario Kart World creates nine terrain layer pools in sparse regions (four R8 16384x16384, four RG16 8192x8192, one R16 8192x8192: 2.9 GB of device memory). In 180 s of title and attract demo not one of their blocks is written and nothing renders into them, so they hold zeros; on the console only the few tiles the game maps have memory. nx2:gpu now publishes which 4 MiB blocks of each sparse region have been written (nx2.h, a leaf lock the texture cache may take). An image of 32 MiB or more lying in one sparse region with no written block is created as a sparse resident image with nothing bound: reads return zero, as an unmapped tile does. The first write into its range, or the first time the GPU renders into it (that range then counts as written), marks it remapped, so a backed image replaces it at its next use. Mario Kart World, 180 s: the collector deletes 0-80 images per 600 frames instead of thousands, frames over 100 ms per 600 presents drop from 1-9 to 0-1, peak working set 14.7 GB. One render target in a small sparse region gets replaced once (logged).

texture_cache: re-decode only the written layers of large ASTC arrays

2026-10-30T16:27:04+00:00

Any write into an image marked all of it CPU-modified, so each terrain tile Mario Kart World streams into its 8192x8192x68 ASTC arrays re-read and re-decoded the whole 1.45 GB array: a 2 GiB staging buffer and a full GPU wait each time, 15-16 GB of uploads per 600 frames. Large layered images on the accelerated ASTC path (64 MiB and up) now record the layers written since their last upload and stay tracked; a refresh reads and decodes only those layers, one dispatch per layer and level into a single-layer storage view. The texture cache's 600-frame report counts uploads from guest memory, their size and how many went by layer. Upload scratch buffers grown past 64 MiB for one huge image (341 MiB for the terrain layer pools) are freed at the next frame instead of kept for the session. Mario Kart World, 180 s: after loading, uploads drop from 15-16 GB to 0.2-0.5 GB per 600 frames, the largest from 1453 MiB to 2-15 MiB.

ASTC: decode and re-compress to BC1/BC3 on the GPU; texture cache budget

2026-10-29T00:43:01+00:00

- accelerate_astc=Gpu with astc_recompression=Bc1/Bc3 now decodes ASTC with the GPU decoder into a temporary RGBA8 image (dedicated memory, freed once the GPU is past it) and compresses it with a new compute shader (bc_encoder.comp: bounding-box endpoints along the colours' covariance, inset 1/16, nearest palette entry; BC3 alpha ramp; BC1 punch-through), then copies the blocks into the image. No CPU decode, so streamed textures are ready the frame they are first used instead of showing placeholders for seconds; the decode pass no longer waits for the GPU on this path. - The CPU path (CpuAsynchronous) fills a new image with zero blocks before its first decode instead of showing stale VRAM, and the transcode pool is a quarter of the hardware threads. - Switch 2 titles: collector thresholds near the device budget, re-read every 60 frames from VK_EXT_memory_budget (another game shrank it from 7.0 to 5.4 GB). - EDEN_NX2_HIDE_WINDOW=0 now leaves the window visible.

Keep huge ASTC arrays from a lower mip on the host (title 1 terrain)

2026-10-28T19:37:34+00:00

Title 1's terrain virtual textures are 8192x8192x68 ASTC 8x8 sRGB arrays with 12 levels: 1.5 GB in guest memory (fully backed) but 23 GB each as the RGBA8 Eden decodes ASTC to, so they were created unbacked and the near terrain sampled black. A GPU-decoded ASTC 2D array over 1 GiB decoded now keeps only the levels from the first one that fits in 512 MiB (here 3: 1024x1024, 380 MiB); host mip 0 is that guest level. Uploads read each layer's tail of the mip chain into a compact buffer and decode only those levels, views shift their level range, and these images are never downloaded. Normalized coordinates and derivative LOD address the smaller image correctly; the nearest terrain is lower resolution than on the console. Also logs how unbacked images are used (views, render targets, blits, DMA).

Vulkan: unbacked sparse images for textures too large to back

2026-10-28T17:55:29+00:00

Title 1 samples an 8192x8192, 12-level, 68-layer array (a sparse virtual texture, ~23 GB): vkCreateImage failed and Eden aborted, or VMA put it in system memory and staged a full upload (34 GB private). Images over 2^28 texels are now created sparse-resident with no memory bound; the texture cache neither uploads nor downloads them. Images merely over the VRAM budget are allocated without the budget limit instead of failing.

[vulkan] Adjustments on MSAA and BlitHelpers (#4287)

2026-08-23T15:31:09+00:00

PR/Commit Owner: CamilleLaVey This PR contains changes complementary to the MSAA refactor from some weeks ago, adds proper shader convert to depth, stencil for msaa and non msaa convertions; removes redundant helpers and unify paths on the resolve functions, just to make the readability and maintainability better; includes fixes for the blit operations on Nvidia, Intel/Windows (previously banned) and ensures Linux retain the fix without extra burden; fixes the QCOM driver bug on resolution upscaling on any games above x1 (includes turnip on A8xx series) and fixes crashes/ resolution upscaled bugs on certain games that used to have wrong viewporting effect on screen or directly device loss on Vulkan. Adds fixes for regressions caused by previous MSAA refactor on games as Fire Emblem: Engage. Special Thanks 1.- Big Smolio (@Gidoly) Co-authored-by: CamilleLaVey Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4287 Reviewed-by: CamilleLaVey Reviewed-by: Samuel

ci: fix new codespell errors

2023-10-02T22:03:05+00:00

Remove memory allocations in some hot paths

2023-06-22T07:05:10+00:00