| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Assisted-by: Claude Opus 5.5 (review, cleanup and log analysis)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Unmapped GPU addresses get a stand-in CPU address fixed by the GPU
address. A fresh one per lookup meant FindImage never found an image
there again: title 1's bloom chain at 0xf0000-0x15b600 was re-created
on every use (~5,400 images per 600 frames), filling VRAM.
- ASTC whose blocks carry no alpha (exact endpoint-mode scan reusing the
decoder's block parsing) is re-compressed to BC1 instead of BC3, half
the size; about 70% of title 1's ASTC qualifies. Copies between BC1
and BC3 hosts are skipped (their guest data is uploaded instead).
EDEN_NX2_ASTC_BC1=0 turns it off.
- Deleting an image cancels every decode still queued for it. An image
re-decoded mid-decode has two; the first to finish cleared IsDecoding,
the second was not cancelled and was uploaded into the next image to
take the slot: garbage textures (the title logo, road patches) and a
staging overrun when that image was smaller.
- Diagnostics: images created and deleted per 600 frames by shape,
collector deletions, async decodes, BC1/BC3 split; collector
thresholds overridable (EDEN_NX2_TC_EXPECTED_MIB/CRITICAL_MIB); GPU
ASTC decode wait timing (EDEN_NX2_ASTC_FLUSH=1 submits without it).
Title 1 attract loop: device memory 4.8-5.1 GB instead of 5.9-6.1 GB, no
decoded textures evicted, ~17 -> 22-23 fps.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From changes.patch: the TU104/GA10x MME interpreter (shared macro context for
the process's channels, also on the compute class), native compute with QMD
3.0 dependency scheduling, the Ampere-to-Maxwell shader lowering, native
vertex stream sizes, and the console's GOB swizzle for textures, DMA copies
and the host unswizzle shaders. Switch 2 channels turn all of it on at init.
The lowering is widened for title 4 (all 32 of its programs lower): general
TEX (any dimension/LOD/mask, operand split 1+1/2+1/2+2/4+n, any but consistent
descriptor buffer), cube/array, SULD channel masks, 128-bit STG, indexed IPA,
VOTE, SHFL with any immediate or predicate output, R2P/P2R byte select,
uniform ULOP3/ULEA/UBREV/UFLO.SH/UISETP signed/UMOV URZ, IMNMX cbuf, IADD3
and FFMA uniform operands, FMUL /4 /8 x8, and BSSY/BSYNC/BREAK/WARPSYNC as
no-ops. The capture stops at unmapped memory. EDEN_NX2_SHADER_DUMP dumps every
native program; tools in C:\dev\nx2work test the lowering offline.
|
| |
|
|
|
|
|
|
|
| |
This increases MAX_MIP_LEVELS from 14 to 16, according to specs.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2965
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Co-authored-by: MaranBr <maranbr@outlook.com>
Co-committed-by: MaranBr <maranbr@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will bypass the check and continue execution,
preventing crashes in cases where games (like CTGP-DX) may request
more mip levels than supported. This is a temporary solution to bypass
instead of ending the crashing when asserts fail.
Co-authored-by: MaranBr <maranbr@outlook.com>
Co-authored-by: JPikachu <jpikachu.eden@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2914
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Co-authored-by: JPikachu <jpikachu@eden-emu.dev>
Co-committed-by: JPikachu <jpikachu@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Compilation and CMake fixes for both Windows on ARM and clang-cl, meaning Windows can now be built on both MSVC and clang on both amd64 and aarch64.
Compiling on clang is *dramatically* faster so this should be useful for CI.
Co-authored-by: crueter <crueter@eden-emu.dev>
Co-authored-by: crueter <crueter@crueter.xyz>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/348
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: crueter <crueter@eden-emu.dev>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
merge/lookup images. (#196)
Previously, the merging strategy is permissive but the lookup strategy is strict. Together they create a infinite merge loop because lookup always fails and merges are always executed.
The last attempt to fix this issue made the lookup strategy more permissive which created unexpected aliased textures.
This commit implements an alternative: make the merging strategy strict.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/196
Reviewed-by: Shinmegumi <shinmegumi@eden-emu.dev>
Co-authored-by: weakboson <weakboson@quantum-field.net>
Co-committed-by: weakboson <weakboson@quantum-field.net>
|
| |
|
|
|
|
|
|
|
|
| |
When looking for existing images, ImageBase::TryFindBase checks the depth of the existing image to be greater than the layer of the base + depth of the candidate.
However the depth of images are not updated when cache were merged causing the lookup to fail.
This commit disables this faulty check to fix a critical memory leak that crashes the emulator in some games.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/164
Co-authored-by: weakboson <weakboson@quantum-field.net>
Co-committed-by: weakboson <weakboson@quantum-field.net>
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
[crash fix]brings back the removed if statement in util.cpp and adds the num_level test to it like previous discontinued PR
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This resolves the out of bounds read/writes in the linear swizzler, it brings back the scaled TOTK Recall bug however, pending further work in the block size calculation.
Recall is not glitched in the Dynamic FPS resolution mod to the degree that it is in the native yuzu scaler, this can be a workaround for the time being.
The recall effect is constructed from multiple 320x180 texture slices, it breaking may have a similar origin to https://github.com/Ryujinx/Ryujinx/pull/5640
but it may also be connected to the other deficiencies identified in the Yuzu size calculations, such as no apparent implementation of slice testing for end of slce depth as opposed to full aligned size as implemented in https://github.com/Ryujinx/Ryujinx/pull/5220
|
| |\|
| |
| | |
Fix mistaken usage of info.block instead of level_info.block
|
| | |
| |
| |
| |
| |
| | |
Fixed an error on my part, in the last change I had mistakenly passed unadjusted block info into FullUploadSwizzles and UnswizzleImage
Revert (my mistaken changing of) the construction of SwizzleParameters in UnswizzleImage and FullUploadSwizzles to use level_info.block instead of info.block. This ensures that the block information used in the swizzling process is correctly adjusted for each mip level.
|
| |\|
| |
| | |
Partial revert of #10433 (Texture Cache Util: Fix block depth adjustment on slices)
|
| | |
| |
| |
| |
| |
| | |
AdjustMipBlockSize
The partial revert was not enough for Tsukihime, this might do the trick
|
| | |
| |
| |
| |
| | |
The If block in this change was causing some 2D textures to be treated as if their mip 0 was a 3D Slice, this could be ascertained as the same texture viewed from different distances would render fine, but then close up would look like a decoding failure.
It also resulted in some 3D ASTC textures not being scaled appropriate leading to broken graphical effects such as the jagged TOTK recall animation being a circle, as the If block was only accepting the image based on its original info without any adjustments applied.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Follow-up to 2b87305d319f0bd04da36fb96314934f37b12637
|
| |
|
|
|
| |
This formats all copyright comments according to SPDX formatting guidelines.
Additionally, this resolves the remaining GPLv2 only licensed files by relicensing them to GPLv2.0-or-later.
|
| | |
|
| |
|
|
| |
This call was reading GPU memory into the dst buffer, which is then overwritten by the SwizzleTexture call.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
supported.
|
| | |
|
| |
|
|
| |
algorithm to be smarter.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On the texture cache we handle multisampled images by keeping their real
size in samples (e.g. 1920x1080 with 4 samples is 3840x2160).
This works nicely with size matches and other comparisons, but the
calculation for guest sizes was not having this in mind, and the size
was being multiplied (again) by the number of samples per dimension.
For example a 3840x2160 texture cache image had its width and height
multiplied by 2, resulting in a much larger texture.
Fix this issue.
- Fixes performance regression on cooking related titles when an
unrelated bug was fixed.
|