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.
As on Direct3D 11 and Vulkan, a picture whose draw would be a plain copy
is not drawn: the XFB texture goes over in the state the frontend reads
it in, with the fence its work completes on for version 2, and is read
where it is; version 1 copies it inside video_refresh, which spares the
draw in front of that copy. Nothing is created for it.
The texture is not one of the output's, so no sync index is waited on.
Version 2 keeps reading it in the frames that repeat it, so before each
repeat the output puts it back in that state if the core used it in
another one meanwhile.
A retro_run that draws nothing new allocates nothing; before, it made
some thirty-six allocations:
- Option lookups by key (IsUpdated and GetCached, about thirty a run)
made a std::string of the key for an unordered_map. The options are
now an array in the order of their definitions with an index sorted
by key, searched with strcmp.
- The JIT asks for its thread's stack bounds each time it starts
running, every run with frame stepping, and glibc's
pthread_getattr_np allocates. A thread's stack does not move: the
bounds are kept per thread after the first time.
- Every event pushed to the video thread, two a field for the XFB
swap, was built with new. Events are now built in a ring of fixed
slots: at most the queue's 1024 wait and one runs, so a slot comes
round again only once its event is done.
- A frame step, every run, posted a resume command to the real
Wiimote manager, built with new. A momentary state change no longer
resumes the remotes; a reported one still does.
A render target of one layer in a 2D array, which is what an XFB copy
is, gets a second view at creation, 2D, of that layer, and keeps it for
its life. Handing an XFB copy to the frontend in place uses it, so
presenting creates and destroys nothing: before, every new picture made
a view and queued the last one for destruction.
As on Direct3D 11, a picture whose draw would be a plain copy is not
drawn: the XFB image is handed over with set_image and the frontend
reads it where it is. It goes over in shader-read layout, submitted on
the core's thread before the frontend is told, through a 2D view of its
one layer made for that picture: the frontend's shaders read a 2D
image, and a view is not kept for the next picture, as an image's
handle can come back for another image once it is destroyed. The view
goes once the core's next submission completes, which follows every
frontend frame that read it.
The image is not one of the output's, so no sync index is waited on.
The frontend keeps reading it in the frames that repeat it, so before
each repeat the output puts it back in shader-read layout if the core
used it in another one meanwhile, a copy's source say: FrameOutput gains
Repeat(), called at the end of a run that reports a repeat.
With version 2 of the frontend interface, a picture whose draw would be
a plain copy is not drawn: the XFB texture itself is named with
set_texture and the frontend reads it where it is. That is the case
when the XFB fills the whole output from its top-left corner at the
same size, with one layer, no stereo, no colour correction and the
default resampling; with crop overscan on, a full-height XFB at the
internal resolution. Anything else is drawn into the output's targets
as before.
The immediate context orders the frontend's reads before anything later
drawn into the texture, so no sync index is waited on. Fields that
repeat the picture keep its XFB copy locked as the one being shown, and
fields that blank the screen lock it until another picture replaces it,
so the copy the frontend shows again is never written meanwhile.
The hook is FrameOutput::PresentTexture, reached through
AbstractGfx::PresentTexture: an output that only hands on its own
targets returns false and the picture is drawn.
Every retro_run hands the frontend exactly one frame. A field that only
repeats the picture before it is not drawn on any backend, OpenGL and
Direct3D on Xbox included: the frontend is told at the end of the run
that the last picture repeats (video_refresh with no data, at the last
picture's size), and shows again what it already has, the target it
reads in place or its own copy. A run that shows something new hands
it over as before, now always as a valid frame.
Loading a state no longer presents from inside retro_unserialize, where
the frontend takes no pictures. The next field presents the loaded
picture inside the next run and is never taken for a repeat of what was
shown before the load.
The core asks for version 2 of the D3D11 interface and, when it gets
it, shares the immediate context with the frontend by taking turns: it
holds the context lock around the frame's emulation, savestates, the
context reset and destroy and unloading, and releases it around
video_refresh and the sync index wait. It keeps one output texture per
sync index and names the frame's with set_texture, so a frontend
presenting from another thread reads it in place instead of copying
it.
When the frontend has used the context since the core last held it,
everything the core relies on is bound again: the state manager's
graphics and compute bindings and the viewport and scissor, which the
backend now keeps. Version 1 rebinds the same way after video_refresh.
The vendored rslc expands calls where they are made instead of
emitting subroutines, so Wine's Direct3D 11 and 12 accept every
generated stage and the D3D backends boot there.
The frontend owns the window and presents, so the D3D11, D3D12 and
Vulkan backends draw their picture into a FrameOutput, a render target
the frontend reads where it is, rather than a swap chain. D3D11 hands
over one texture at pixel shader slot 0. D3D12 negotiates version 2 of
its interface and keeps one texture per sync index, handed over with
the fence its picture completes on, falling back to set_texture on
version 1. Vulkan keeps one image per sync index and hands it over with
set_image, so the fake swap chain and the WSI calls hooked under it are
gone, and the device may come without a surface. The outputs are RGBA8
and report that format to the presenter.
The DXGI and Vulkan swap chains, the backends' standalone device
creation and exclusive fullscreen are removed.
The vendored rslc takes gl_Layer in a pixel stage, so the stereoscopic
pixel shaders, which read the layer the geometry stage chose, compile
for Vulkan and Direct3D.
The geometry shader generator and the layered pass-through geometry
stage now write GLSL for Direct3D too, as for OpenGL and Vulkan, and the
vendored rslc compiles them to DXBC like the other stages. Direct3D
binds the geometry block at b0.
With every stage compiled by rslc, the runtime compiler is no longer
used: d3dcompiler_47.dll is not loaded, D3DCompile and its target table
are gone, and the core no longer needs the DLL on the system.
GenerateVSOutputMembers loses its Direct3D geometry-stage case and its
HLSL semantics, which only the HLSL generators used.
The vendored rslc compiles the generators' GLSL straight to DXBC of the
feature level's shader model, so these stages no longer go through HLSL
and the runtime compiler. The geometry stage is written in HLSL and is
still compiled by D3DCompile.
The vendored rslc prints subgroup operations, so a device that runs them
in the pixel stage gets the subgroup header back: each subgroup reduces
its bounding box and one invocation writes it. Vulkan offers it where
the device has the basic, arithmetic, ballot and shuffle operations in
the fragment stage; Metal on Mac2 and Apple7 GPUs, whose
simd_is_helper_thread is probed at init for the inverted answer some AMD
drivers give. The driver bug that breaks the reduction with discard
still keeps it off.
The vendored rslc reads a subpassInput and prints it to MSL as the
colour attachment's [[color(N)]] value, so the pixel header defines
INPUT_ATTACHMENT_BINDING and FB_FETCH_VALUE again and the backend
reports framebuffer fetch on Apple GPUs and on the Intel GPUs whose
probe draws a pixel that reads back doubled.
Each stage gets its own header whose bindings are the Metal indices the
backend binds at, as the SPIRV-Cross resource table had them: the vertex
stage's blocks at buffers 1 and 2 and its vertex loader input at 0, the
pixel stage's blocks at 0 and 1 and the bounding box at 2, compute's
block at 0, its buffers at 2 and 3 and its image after the eight
samplers. A stage rslc refuses is logged and written to the dump
directory.
rslc has no 8- and 16-bit types, so the texture decoders and the palette
converter read Metal's texel buffers a word at a time, picking bytes and
halves out of it; the buffers are allocated 16-byte aligned. It has no
subpass input or subgroup operations either: framebuffer fetch is no
longer reported, and the subgroup header, the helper-invocation probe
and the Intel framebuffer-fetch probe go.
Array, multisampled and buffer textures, further blocks, storage buffers,
clip distances and compute in MSL, laid out as SPIRV-Cross laid them out
with the Metal backend's bindings.
Vulkan and D3D compile through rslc, so glslang only serves Metal's path
through SPIRV-Cross. It and VideoCommon/Spirv.cpp are built with
SPIRV-Cross on Apple platforms and nowhere else.
Nothing ever made one: every backend was handed a null includer, and the
OpenGL backend's #include resolver returned the source untouched. The
parameter goes from CreateShaderFromSource and everything beneath it,
and ShaderCompileUtils with it.
LibretroAdmin