| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| | |
test/linux-all-prs
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Once a texture is uploaded the host GPU has its own copy, and the guest
rarely reads that memory again, but it stayed in the emulator's working
set. Every 600 frames the guest ranges of images uploaded since (64 KiB
or more, not GPU-written or sparse) are marked cold through
HostMemory::HintCold, backing and CPU view, from a low-priority worker,
so the OS pages them out before anything else when it needs RAM. Their
contents stay; using them brings them back. Mario Kart World's title
screen at ~10 minutes: game memory in RAM 4.8-5.5 -> 3.6 GB, the
emulator's real RAM 10.6-11.9 -> 9.4 GB, frames over 100 ms not worse.
(cherry picked from commit ea36b2c5ca352f8c8cdcc829a2d3bde9bdc06ece)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With remap support Mario Kart World fills nine world-sized masks
(R8 16384x16384, RG16 and R16 8192x8192, one sparse region each) in its
own memory and then maps them in through 216. Nothing writes them through
the sparse region, so its blocks stayed unwritten and the texture cache
kept the images over them without memory, reading zero: the static world
(roads, buildings, rocks, trees) rendered unlit while karts and cars were
lit. Without remap support the game never maps them and lights the world
without them.
A tile map now counts its blocks as written and invalidates the caches
over the tile, so those images get memory and load what the game mapped.
That costs the masks' full size in device memory (about 2.9 GB in Mario
Kart World), which is what they need until the texture cache can back
single images tile by tile. DeviceMemoryManager::Unmap no longer needs
its flag to keep the caches.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Switch 2 games commit and release the memory behind sparse textures by
remapping tiles: nvnMemoryPoolMapVirtual goes through NvRm's remap into
nn::gpu::sdk::ExecuteSparseMapRequests, nx2:gpu sub-session command 216,
a batch of 40-byte requests. A map points a tile at the game's own
GPU-accessible memory (the handle sub 101 returned, plus an offset), an
unmap makes it read zero again; the sparse region itself never has memory.
NvRm only remaps when the GPU characteristics report
NVGPU_GPU_FLAGS_SUPPORT_REMAP (bit 35). Without it every remap failed
before reaching the server, so Mario Kart World streamed its terrain into
unmapped sparse memory and each 4 MiB block it touched got memory that
was never freed (2.5 GB after 10 minutes, still growing).
Report the flag (EDEN_NX2_SPARSE_REMAP=0 leaves it out) and serve 216:
- Sparse regions: a tile's device pages show the game's memory, or are
unmapped, in GPU thread order, without invalidating the caches over
them; the region keeps its GPU mapping, so the texture cache keeps its
images. A region the game maps tiles into gets no more blocks (writes
outside its tiles are dropped, as on the console), gives back the
blocks it already had, and marks a block written when the GPU first
writes it, so array layers it only maps tiles into get no memory or
uploads.
- GPU-only regions (214 without the sparse flag): the game also sends
216 for its render targets and, with remap support, for two texture
arrays (5.8 GB and 1.4 GB). Regions whose memory another GPU-only
region maps (render-target groups) keep the memory 214 gave them:
applied, the texture cache flushed and re-uploaded the overlapping
render targets every frame. Regions 214 backs as they are written
keep their blocks too, since the texture cache reads an image's memory
in full when it uploads it, which makes the game's pages resident on
the host (about 1 GB more 150 s in). The rest get the game's memory
the way 211 maps it, so writes through the game's own address reach
the same device pages; an unmap points the range back at the region's
own memory.
Mario Kart World, 10 minutes: no sparse blocks backed (2.5 GB before),
24.6 presents a second instead of 19.3. 216 totals are logged every 30 s.
|
| |/
|
|
|
|
| |
collision on some object, but can extend to more.
Assisted-by: Claude Opus 5.5 (debugging & implementation)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WalkBlock copies a run of physically contiguous device pages at once, using
each page's continuity_tracker. Unmap left the counts as they were, Map
without tracking did not touch them, and the pages before a changed range
kept counting into it. A read starting on such a page then copied the host
memory that followed the old mapping, or, starting on an unmapped page,
zero-filled the whole old run, mapped pages after it included.
Splatoon Raiders lost its dialogue text this way: the glyph vertex shader
reads its corner table from constant buffer 1 (the program's constants, at
device 0x5617d700), and the buffer cache uploaded the range from 0x5617c000,
an unmapped page still counted as the start of a long run, so the table
reached the GPU as zeros and every glyph sampled one empty texel.
Unmap and Map now reset the counts of their pages (Map recounts them when
tracking) and cut the runs of the pages before them at the range start.
|
| |
|
|
|
|
|
|
|
|
| |
DeviceMemoryManager kept one four-entry page translation cache for every thread. Map
(on a guest service thread, e.g. nx2:gpu 211 job mappings) cleared it while the GPU
thread was between its null check of an entry and the copy from it: the GPU thread
then read from address 0 plus the page offset. Title 1 crashed this way in about half
of its 150 s test runs (BindHostGraphicsUniformBuffer -> ReadBlockUnsafe, fault at
0x600). Each thread now keeps its own cache, which Map and Unmap invalidate through a
generation counter. 0 crashes in 6 runs after.
|
| |
|
|
|
|
|
|
|
| |
nx2:gpu 214 regions are memory the graphics server keeps itself, but Eden
took their pages from the application pool: title 4's six 300 MB regions
left it 1.8 GB less than the 9.55 GiB the kernel reports, all of which
its heap and VAMM plan to use. Add 8 GiB of DRAM to the 12 GB layout for
the non-secure system pool and back the regions from there; the device
memory tracker now covers 32 GiB of physical memory.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fences
- gsv 204: real syncpoint shared page (values mirrored from host1x, armed waits
acknowledged by a 500us poller); first handle is the writable request event.
- syncpt 22/201/202: per-slot events signalled through host1x guest actions.
- nx2:gpu sub 101 memory is identity-mapped (GPU VA == CPU VA) into every
nvhost-as-gpu GMMU via Nx2GpuMemoryRegistry; SMMU physical range widened to
34 bits for the 10/12 GiB layouts.
- Puller runs Ampere 3D/compute/copy classes on the Maxwell engines; class 0 unbinds.
- Turing+ macros are skipped (Eden only has the Fermi macro ISA).
- Submits with increment_value get Eden-side syncpoint increments, since NVN2
signals completion with semaphore releases only.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reduces the page entries from 32 bytes to 8 and rewrites `VirtualBuffer` to be more efficient in memory usage and specifically for large zero regions.
The page table will now only reserve 1GiB instead of 4GiB and of this memory it should only use at most ~8MiB.
This PR has the side effect of using Eden on Windows on low memory systems much more plausible since it would previously require ~10GiB of committable memory at front (despite using ~5-6 at most, inadvertently stalling other processes) where as now it should only require around the amount that it'll actually use.
Co-authored-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4219
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I think I may have attempted this before, but I doubt it.
Anyways this should reduce virtual buffers from 3 to just 1, also improved access times :)
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3677
Reviewed-by: crueter <crueter@eden-emu.dev>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GPU threading. (#3579)
(Merge of #3495 + #3108)
This PR works around to simplify math operations on hot pointers inside the access and requests to the cache of buffers and texture cache, removing previous logic of indirection and replaced by a PoD approach.
This will ensure less CPU times spended on the same request and flow directly into another chain of the render, in the same way, command queue currently uses an internal mutex that constraints the flow of data within the GPU threads, we're moving over a single command, I verified to keep using mutexes instead of internal mutex + mutex per operation, which are resolved by themselves.
In simplier words, this aims to improve performance on those games and devices where the waits for next orders on GPU commands were heavier than a single verification.
Co-Authored-by: @CamilleLaVey
Co-Authored-by: @Lizzie
Co-authored-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3579
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
fixes linking + comp issues but not the test themselves, who have now became invalid
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Co-authored-by: DraVee <caiooliveirafarias0@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3345
Reviewed-by: DraVee <dravee@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
| |
I added a batching/ coalescing of ranges in WordManager to reduce calls per pages in UpdatePagesCachedCount, also a test to verify if FlushCachedWrites coalesced (reduces callings to UpdatePagesCachedCount) callings and register each of them to inspect them.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3288
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: DraVee <dravee@eden-emu.dev>
Co-authored-by: CamilleLaVey <camillelavey99@gmail.com>
Co-committed-by: CamilleLaVey <camillelavey99@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#2695) (#2706)
revert [vk] Fast UBO: fix tracking, resize heuristics, add debug guard (#2695)
Well, stuff showed up after testing phase, that showed us this change break SMO and some mods after being merged directly into master, we will keep stuying why happens this and add a better handling later.
Co-authored-by: Ribbit <ribbit@placeholder.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2695
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Co-authored-by: Ribbit <ribbit@eden-emu.dev>
Co-committed-by: Ribbit <ribbit@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2706
Co-authored-by: CamilleLaVey <camillelavey99@gmail.com>
Co-committed-by: CamilleLaVey <camillelavey99@gmail.com>
|
| |
|
|
|
|
|
|
| |
Co-authored-by: Ribbit <ribbit@placeholder.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2695
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Co-authored-by: Ribbit <ribbit@eden-emu.dev>
Co-committed-by: Ribbit <ribbit@eden-emu.dev>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
