The GPU thread publishes a picture's description into one of four slots
and the generation naming it into an atomic word; the frontend's thread
claims it with a CAS that sets a taken bit, and the GPU thread reclaims
an untaken target with a CAS on the same word, so exactly one of them
owns it. What is being handed over and what was handed are atomic
tags only the frontend's thread writes, the first before its claim.
No slock on either side.
The frontend picks the adapter and hands over its device, so the core no
longer loads dxgi.dll, creates DXGI factories, enumerates adapters or
creates throwaway D3D11/D3D12 devices to query AA modes and logic op
support at load. Until the device arrives the AA modes are the counts
every device has; the context reset fills them in from the real device
(D3D12 now too) and re-validates the MSAA setting against them.
Nothing in the core starts a recording or a playback, so a movie is
never active. Each call site keeps its no-movie path: no determinism
toggle, the real clock for the RTC, the configured memory cards, no
pad/Wiimote input mirroring into display strings on every poll. The
state keeps the movie counters' bytes, written as zeroes, so existing
savestates still load.
D3D11 sets logic op support from the device again (off on UWP) and
always reports object names: the UWP check's else had swallowed the
object-name line and logic op was never on. The Android input backend
is no longer created, so its source, include and CIFACE_USE_ANDROID go.
Core.h declarations indented with spaces like the rest of the file.
Serial devices lend their Rx bytes in place and take Tx as pointer plus
size; JVS frames unescape onto the stack and are consumed without a
scope guard. IO port inputs and outputs are plain pointers with fixed
counts. Mediaboard addresses resolve to a lent pointer and size; the
game table is a flat array. Bluetooth passthrough keeps its link keys
in a fixed sorted array, links live transfers through the header that
already fronts each buffer, and lends ACL packets as pointer and size.
AsU8Span/AsWritableU8Span are gone from BitUtils.
SHA1, HMAC, hex dumps, PNG loading, file search, DHCP options, HTTP
posts and DirectIOFile reads and writes take pointer plus size; callers
pass their buffers straight through. Contains.h is gone; lookups are
plain loops. File search and FAT FST sorting are in-place heap sorts;
min/max/clamp/copy/fill become ternaries, memcpy and memset. Watch
string import and export had no callers and are removed.
Names, game IDs, patch lists, LBA ranges and hash exceptions are passed
as pointer plus count. min/max/fill/copy become ternaries, memset and
memcpy; FST entries sort with an in-place heap sort, partitions with an
insertion sort. WAD content checks decrypt and hash in 2 KiB chunks
straight from the borrowed input; banner names read onto the stack.
Guest handles index one of sixteen host file slots; the last handle to
close a path closes its file. No shared_ptr, weak_ptr or map. Directory
order is an insertion sort over FST positions; lookups are plain loops.
Signed blobs, TMDs, tickets, certs and signatures are lent as pointer
plus size; readers are filled in place from guest memory and disc
reads. Algorithm calls become plain loops and memcpy. WiiUtils keeps
only WAD install, TMD recovery and the Bluetooth getters the core uses.
A TMD view and a ticket view are written straight into the guest's
output buffer, the TMD view's size computed rather than measured off a
view built to be thrown away. A ticket, a signature and a public key are
spans into the blob they are part of instead of copies in vectors. A TMD
or ticket the guest passes to the DI view calls is read into its reader
straight from guest memory.
A ticket, TMD or certificate holds its bytes in one malloc'd buffer and
hands them out as a span. ResizeBytes() gives the room to fill, so a
ticket or TMD is read from the NAND, a disc, a WAD or guest memory
straight into its reader instead of into a std::vector that is then
moved or copied in.
Ticket, TMD and certificate chain imports take spans, and the IPC
handlers pass the guest's buffers where they lie instead of copying
them out into vectors first. A certificate is read where it lies and
only its own bytes are copied, so parsing a chain no longer copies the
rest of the chain once per certificate. Deleting a ticket closes up the
ones kept in place. The savestate layout is unchanged.
The GBA core's files open as an mGBA VFile over a libretro-common
filestream (GBAVFile.c). A read-only map of a mapped file lends the
mapping itself, so the ROM and the BIOS are read where they lie; a save
is mapped into a buffer of its own and written back when mGBA syncs it.
A ROM in an archive or a zip is read or inflated straight into the
memory file mGBA maps, with no buffer in between.
The state and save import/export, e-Reader card queueing, ROM info and
forced disconnect entry points nothing calls are gone.
TextureInfo hashes textures and palettes with libretro-common's
xxh64(), the same value XXH64() gives, so dumped and custom texture
names stay as they are. The pipeline hash helpers nothing calls are
gone, and with them Externals/xxhash.
VKHeap.c takes large blocks from the driver and hands out offsets in
them: the lowest free span that fits, spans kept sorted so a free is a
binary search and a merge. The handle is a small struct kept by value,
so nothing is allocated per allocation. Host-visible blocks are mapped
once and stay mapped; stream buffers and staging buffers write straight
into the memory the GPU reads. Buffers and linear images keep to blocks
of their own, apart from optimal images. What the driver requires or
prefers dedicated, and anything of half a block or more, gets memory of
its own sized to fit. Host blocks are 16 MiB, device blocks 64 MiB, and
neither more than an eighth of its driver heap; one empty block of each
kind is kept and the rest go back to the driver.
The Vulkan Memory Allocator is gone, and with it the memory budget
extension only it used.
A memory patch's value file is lent through File::LoanFile and handed to
the patcher as a span, and a value given inline is used where the parser
left it, instead of either being copied into a fresh std::vector each
time a patch is applied.
LoanFile() lends a whole file for reading: straight from its mapping
where the file is mapped, from one malloc'd buffer otherwise; EndLoan()
gives it back. The SSL certificates are loaned through it.
The disc header, BI2, apploader, FST, partition table, region data and
H3 table are each put together in the shared allocation the content
chunk serves them from - read from the host file or the wrapped volume
straight into it, then patched in place - instead of in a std::vector
that Add() copied. The partition header and the bytes read from
header.bin and region.bin go through stack arrays. The FST sort compares
names case-folded in place instead of upper-casing two std::string
copies per comparison.
A disc's content chunks sit in one malloc'd array sorted by end offset
and found by binary search, in place of a std::set walked node by node.
A chunk is plain data - offset, size, kind, source offset - read through
a switch rather than a std::variant visited per read.
Where a chunk's bytes come from is a small C struct; the bytes it needs
(a host file's path, a run of memory) live in one reference-counted
allocation shared by every chunk and copy that refers to them, in place
of a std::string per chunk and a shared_ptr to a std::vector. Splitting
a memory chunk for a Riivolution patch moves its offset into the shared
bytes instead of copying the tail into a new vector.
The reference counts and the open-file slots' flags are retro_atomic.
A read from an extracted game's file no longer opens, maps, unmaps and
closes the file every time. The reader keeps 16 slots of open (and,
where the platform maps, mapped) files, picked by a hash of the path; a
read owns its slot for its length through an atomic flag, so reads stay
lock-free, and copies straight out of the mapping. A read finding its
slot taken opens the file for itself, as before. No allocation: the
slots, paths included, live in the reader.
An extracted disc streaming two 600 KiB pictures alternately: 2 opens
over 120 frames instead of 218, pictures identical.
The built-in client certificate, key and root CA are hashed and handed
to mbedtls straight from the mapped file instead of a vector filled by
a read; where the file can't be mapped, one malloc'd buffer holds it.
The path is put together in a stack buffer.
IOFile, DirectIOFile and the FileUtil primitives (Exists, IsDirectory,
IsFile, GetSize, CreateDir, Delete, DeleteDir, Rename) take C strings;
the std::string forms are inline forwards, so callers holding a literal
or a stack buffer build no temporary. DirectIOFile keeps its path in one
malloc'd buffer. CreateDirs and CreateFullPath cut the directory part
into a stack buffer instead of a heap string.
An encrypted block of a plain image is decrypted straight from the
image's mapping; one the reader cannot lend is read into the volume's
own block buffer, not a new allocation per read. A read that covers a
block's whole data is decrypted straight into the caller's buffer; only
a partial one goes through the decrypted-block cache.
The line reader's window, the disk cache's append and alignment
buffers, and the DVD thread's result buffers are malloc'd and grow to
the largest request, then stay. Pending lent DVD reads are a fixed
array, and results are plain structs taken from and given back to the
free stack. A memory card's dirty blocks are a bitmap walked a word at
a time. A GCI flush job is one malloc - the job, its blocks, its name -
and the flush walks the drained chain itself. A page programmed over
EXI is written a run at a time, not a byte at a time.
A DOL or ELF on the host is read where it lies in its mapped file, or
read once into a malloc'd buffer where it cannot be mapped; one handed
over by the caller is used in place, freed by the reader only when it
takes ownership. A DOL's sections are a fixed array of pointers into
it, copied straight into emulated memory, and an ancast body is
decrypted straight into emulated memory behind its header. An ELF,
whose headers are swapped in place, is copied out of a mapping only
then; the ARM binary IOS boots is swapped where it was read, its ELF
never copied out.
A result the DVD thread made goes back to it once the CPU thread has
finished with it, buffer and all, through a lock-free stack the DVD
thread drains when it runs out. Reads of compressed, encrypted and
assembled images allocate nothing once there are as many results as
reads in flight.
Shader caches are walked where their entries lie in the mapped file,
each value handed to its reader from there - copied only when
misaligned for its type - with no allocation or read call per entry.
An entry is appended in one write. The Vulkan pipeline cache is made
from the stored blob in place, and stored again only when it changed,
atomically.
A raw memory card writes back only the blocks that changed, a run of
them at a time, keeping a block marked until it is written. A GCI save
is replaced whole or not at all, in two writes. The Gecko code handler
is read from its file straight into emulated memory, the DSP ROMs are
swapped out of the mapping, and system menu files go into the NAND from
the mapping.
A GameCube disc in a plain image is lent by the volume as it lies in
the mapped file. Such a read never goes to the DVD thread and has no
buffer: it starts by asking the OS to prefetch its pages, and when it
is due its bytes go from the mapping into emulated memory, or to the
DTK stream, in one copy. Compressed, encrypted and assembled images
keep the DVD thread.
A savestate stores pending lent reads as the results the DVD thread
would have made, so states keep their format, and a disc change turns
them into results before the old image goes.
Every file the core touches goes through libretro-common's filestream,
path and dirent layers, taken from RetroArch: vfs_hybrid opens local
paths with libretro-common's own implementation and hands URI paths
(and, on Android, anything a local open cannot reach) to the
frontend's VFS. File::IOFile and File::DirectIOFile sit on RFILE, and
FileUtil, FileSearch and the directory walks on path_stat, path_mkdir
and retro_opendir. Dolphin's fopen, POSIX and Win32 file code,
std::filesystem and std::fstream are gone, with the dual VFS paths and
the core option that chose between them.
Files opened for reading alone are memory-mapped where the platform
can: reads copy straight out of the page cache, DirectIOFile's offset
reads on one mapped object are thread safe, and GetMappedPtr(), View()
and Prefetch() lend and warm without a copy. Text files are read a
line at a time through File::LineReader, lent from the mapping or a
window refilled a block at a time, never a byte at a time; JSON is
parsed straight from the mapping. Ini files and the cheat file are
built in memory and written once, an ini only when it changed and
then atomically.
Every savestate load clears the JIT cache. A code block keeps how far
into its region code may have been written since it was last poisoned:
the pointer its emitter leaves and the one it takes up, through
SetCodePtr and ResetCodePtr, and where it is when cleared. A clear
poisons up to there, and the untouched rest of the near and far code
regions, over a hundred megabytes, is neither written nor committed.
On x86-64 and the cached interpreter everything written lies below that
mark. AArch64's JIT writes its regions through other blocks' emitters,
so its blocks poison their regions whole.
A savestate load, repeated as rewind and run-ahead do, takes 10 to 12
ms; the first one 70.
The software and null renderers run without a hardware context. They
come up at the end of retro_load_game, where a frontend with a context
would call context_reset, and go down with the rest at unload.
The software renderer's picture goes to video_refresh straight from its
XFB texture, in one pass into XRGB8888 order, into a buffer that grows
only with the picture: no GL texture upload, no draw, no window of its
own. The GPU thread's g_gfx is the backend's own from the start.
Where the driver compiles on threads of its own
(GL_KHR_parallel_shader_compile or the ARB one), the asynchronous
shader modes on OpenGL compile in the background on the frontend's
context alone: a missing program's compile and link are started, a
couple of work items a frame, and its draws use the ubershaders, or
are skipped, until GL_COMPLETION_STATUS says the link is done; its
link is checked, its variables set and its binary written to the cache
then. A program drawn with before it is done is waited for there. A
software rasterizer, which compiles when it first draws, compiles on
the spot as before.
The shader compiler gets a deferred mode for it, without threads,
compiling the items waiting a few at a time, and AbstractPipeline tells
whether a pipeline's compile is still running and whether it can be
drawn with. With the driver's threads alone, every ubershader pipeline
there can be is not built in the background.
The OpenGL renderer draws on the context the frontend hands over
through libretro GL, and the core makes no context of its own: the
platform context code goes, EGL, EGLX11, EGL for Android, WGL, AGL,
BGL and the GLX window, with the shared contexts made for the shader
compiler's threads, and GLContext::Create makes the libretro context
alone. Programs are compiled on the frontend's context, so the OpenGL
backend reports no background compiling and its shader compiler runs
no threads; the shared-context compiler, its glFinish and VAO rebinds
and the driver bug that switched it off go with it. Android no longer
links libEGL.
The shader compiler's threads on OpenGL get contexts sharing the
frontend's on every platform but Apple's: EGL, then GLX, on Linux, the
other Unixes and Android, and WGL on Windows, each loaded at runtime
from the library the frontend has loaded, so the core links none of
them. With compiler threads OpenGL draws with ubershaders while each
draw's own program compiles in the background, as the other backends
do, instead of compiling it on the spot.
GLX finds the frontend's FBConfig among the screen's by its ID where
glXChooseFBConfig matches none, as Mesa's does; WGL makes its contexts
current on a 1x1 pbuffer of the frontend's pixel format, or on the
frontend's DC without WGL_ARB_pbuffer.
Where the device has VK_EXT_graphics_pipeline_library with fast
linking, an ubershader pipeline, the one built on the spot when a draw
first needs it, is linked from libraries of its four parts instead of
built whole: the vertex input, the vertex and geometry shaders, the
pixel shader and the colour output, each found or built with only what
that part takes. With cull mode, depth state and blending set per draw
the parts are shared widely; a pipeline whose parts exist is linked in
well under a millisecond, where building it whole took tens, and only
a shader's first use builds its library.
The libraries live in the shared pipeline table until the backend
shuts down. A link that fails builds the pipeline whole.
Where the device has VK_EXT_extended_dynamic_state3's colour blend
enable, equation and write mask, a GX or ubershader pipeline's blending
is set per draw with its cull mode and depth state, and left out of the
pipeline and of the key it is shared by: pipelines that differ only in
blend enable, factors, equations or which channels are written are one
VkPipeline. Logic op and dual-source blending stay in the pipeline, the
latter as it decides the shader's outputs. The state tracker sets the
blending for every colour attachment when it, or the attachments,
differ from what the command buffer has set already.
Loading a state on OpenGL no longer throws the texture cache away after
restoring it: the EFB copies the state carries, the XFB copies among
them, are found again as on the other backends, instead of the next
picture being decoded from RAM, which the copies never wrote, and shown
as garbage.
In single core the FIFO player's CPU core is injected and left for
RunSingleFrame to run a field at a time, as the CPU thread function
leaves the PowerPC core, instead of entering its blocking run loop on
the frontend's thread, which never returned from the first retro_run.
It is taken out again at unload, before the hardware it drives is shut
down.
The FIFO player waits after each frame for the GPU to be idle; it now
stops waiting as soon as the CPU is asked to pause, as it already does
while the FIFO is full. A savestate taken while a FIFO log played
waited for the FIFO player's thread to pause, which waited for a GPU
loop that only runs inside retro_run: retro_serialize_size never
returned.
Where the device has VK_EXT_extended_dynamic_state, the cull mode and
the depth test, write and compare function of a GX or ubershader
pipeline are set per draw, and pipelines that differ only there are one
VkPipeline: a pipeline asked for whose shaders, vertex layout, blending,
topology and framebuffer match one already built takes that one at once
instead of being compiled. Fewer pipelines are compiled, in the
background and on the spot alike.
The shared pipelines sit in a fixed open-addressed table every thread
building pipelines reads and adds to without a lock, counted by the
pipelines using them; a shader is told apart by a number given it when
it is made, not by its address. The state tracker sets only what
differs from what the command buffer has set already, and sets it again
after a pipeline with the state built in.
The colour blend attachments of a pipeline are kept on the stack.
The application info the core hands the frontend for its instance asks
for the highest version the Vulkan loader has, up to 1.2, instead of
1.0. The backend calls the 1.1 queries (vkGetPhysicalDeviceProperties2
and Features2) where the device has them; on a 1.0 instance those were
invalid, and the loader answered them by emulation that drops the
structures chained to them, so no extension feature could be queried.
The memory allocator is told the lower of the instance's and the
device's versions.
The shader compiler's worker threads run at a lower priority than the
threads that emulate, on Windows (below normal) and Linux (nice 5): on
a machine with fewer cores than busy threads, what compiles in the
background waits, not the frame being emulated. Common gets
LowerCurrentThreadPriority for it.
A uniform block a shader declares and never reads is no longer declared
in its DXBC, as fxc does: on Direct3D 12 every constant buffer declared
must have a slot in the root signature, so pipeline creation failed for
any shader that declared one it had none for. Dolphin's ubershader
vertex shader with the dynamic vertex loader declares its geometry
block without reading it, and every ubershader pipeline on D3D12 failed
to build: draws that needed one were skipped.
On OpenGL and Direct3D 11, and on Vulkan and Direct3D 12 in single core,
the GPU loop runs inside retro_run, and a run after one that ran out of
time catches up on two fields: both presented, and the frontend's
video_refresh was called twice in one run. A picture drawn or handed
over on the hardware is now reported once, at the end of the run, the
last one drawn, as the threaded outputs already did.
Direct3D 11 version 1 is the exception, as the frontend reads its
texture inside the callback: that output reports at once, the first
picture of a run, and drops a second. So do pictures in memory
(software rendering).
What the output hands over in place, the XFB texture itself, may have
been read in a layout of the core's own since it was presented, as a
copy's source say: before the frontend is told, it goes back to the one
the frontend reads it in, as it already did before a repeat
(FrameOutput::KeepReadable, which Repeat was).
Shader compilation defaults to Async (UberShaders): a draw whose own
pipeline is not built yet is drawn with an ubershader one, exact
rendering, while its own builds on the compiler threads, which now
number as many as the machine has to spare (cores - 3, 1 to 4) instead
of one.
What is left to stutter is an ubershader pipeline itself, built on the
spot the first time a draw needs one: one per vertex layout and fixed
function state. Every ubershader pipeline a draw uses is now recorded,
in <game id>.uberuidcache next to the specialized UID cache, and those
are built before the game starts the next time it boots; every other
ubershader pipeline there can be, and the specialized pipelines known,
build in the background while it runs instead of before it starts,
which took 21 s on lavapipe. The record is written when the cache
closes, into room reserved when it opens, so recording allocates
nothing in the middle of a game.
Without compiler threads (OpenGL here, with no shared context for
them), asking for a pipeline in the background builds it on the spot
and an ubershader one besides: the asynchronous modes draw as
Synchronous does then, and nothing extra is built before the game
starts.
Booting a FIFO log no longer hangs: the CPU thread clears the EFB, which
waits on the GPU, before it reaches its run loop, and the frontend's
thread waited for that run loop without running the GPU. It runs the
GPU until then.
On Vulkan and Direct3D 12, in dual core, the GPU loop runs on a thread
of its own, as the frontend interface for both lets another thread
submit: retro_run starts the field, waits for it no longer than two of
the frontend's frames (40 ms at most), hands over the newest picture
finished and returns. A shader compiled, or anything else slow on the
GPU side, holds up the GPU thread only. The loop runs in slices of 5 ms,
so a request to park or quit is seen that soon; a slice that ends a
field counts it for retro_run.
Pictures go from the GPU thread to the frontend's through a queue: the
newest published, the one being handed over and the one shown, any of
which the frontend may read. Each output draws into images of its own,
three of them: a picture published and not yet handed over is drawn
into again in place. EndFrame hands over with set_image, or
set_texture_fenced and set_texture, on the frontend's thread, and an
image is free again once the frontend's frame that read it is
submitted. An XFB copy handed on in place is kept alive by the
presenter while the output holds it, and the output puts it back in the
layout or state the frontend reads it in before every submission of
the core's, as the frontend submits on its own thread whenever its
frame is due.
Savestates, cheats and disc changes let the field in flight end on the
GPU thread and park it while the frontend's thread has the video state;
unloading and a context destroyed stop it, and the next retro_run starts
it again.
Direct3D 11 and OpenGL keep the GPU loop on the frontend's thread: the
immediate context is shared with the frontend through lock_context,
which a thread holding it through a slow compile would hold the
frontend's frame up on, and the OpenGL context is the frontend's
thread's.
retro_run runs the GPU until the CPU thread ends the field, and the
field ends only as fast as the CPU thread gets through it: a disc read
or anything else holding that thread up held the frontend's frame up
with it, and the frontend counted no frames.
The GPU loop now has a deadline on the wall clock, two of the
frontend's frames and never more than 40 ms: it is checked every 64
chunks of the fifo, and the loop's sleep waiting for work is bounded by
it. Past it the run reports a repeat and returns, the CPU thread goes on
with its field, and the next run takes the rest of the field's work.
A field's end that comes while the loop is out of time is kept for that
next run. Every run reports one frame, before the first picture too,
with the size the frontend was told.
A field swapped while a state is saved or loaded, outside retro_run,
is not presented: the frontend takes pictures only inside retro_run, so
the next field is presented instead.
Whatever pauses the CPU thread from the frontend's (savestates,
cheats, a disc change, unloading) first runs the GPU until the field in
flight ends, so the CPU thread is paused at a field's end as after a
full run, never waiting on GPU work only this thread runs.
LibretroAdmin