dx12_dxil.inc has every raster shader and the HDR output's as DXIL,
shader model 6.0, made by dxc and signed, each held to the raster root
signature (-verifyrootsignature); kernels_dx12.sh update-dxil makes it,
and check compares it. DX12Pipelines::Init() asks the device for its
shader model before the pipeline file is read: DXIL from 6.0 on, DXBC
below, a pipeline's shaders always of one kind. The pipeline file's sum is
of the shaders chosen.
tools/rend/d3d_dxil.sh runs the test discs on Direct3D 12 as the device
answers and with it saying 5.1 (d3d_hdr.c's D3DH_SM51): the shaders are
DXIL only where the device takes it, every pipeline is made, and the
pictures are the DXBC ones.
The polygon pixel shader writes a second colour, and the factors of the
TSP's instructions that read only the source - zero, one, its alpha and
one less it, and for the destination also its colour and one less it -
are applied there: the pipeline has one for the source and the second
colour for the destination (dual-source blending). DX12PsoKey::Pack()
folds the key to match, so the 64 pairs of instructions are 15 pipelines,
all of them made at the start, and the startup set is queued with the keys
from earlier runs first and the commonest pipelines before the rare ones.
On the test disc no pipeline is made in a frame any more (two or three
were, a run).
The pipeline file is version 3 and keeps a sum of the shaders' bytecode:
a library made with other shaders is started again (a pipeline kept for
other bytecode never loaded and its name could not be stored again), and
a version 2 file's keys are folded. kernels_dx12.sh update-raster makes
only dx12_dxbc.inc again; the raster and HDR DXBC are made with the
d3dcompiler_47.dll that made hdr_encode_dxbc.inc.
tools/rend/dx12_blend_fold_test.sh checks every pair of instructions, with
colours in and out of range, against the PowerVR's blend.
A game waiting on the beam reads SPG_STATUS hundreds of times a line,
and each read found the next line due and divided twice to place the
beam. spg_beam() now keeps what it found - the line, the pending
event's end, the cycles that bound the line - and answers a read on the
same line, aimed by the same event, with a subtraction. Aiming the
event, a timing change or a state loaded starts it afresh.
The headless disc runs 3000 frames in 11.5 s, from 17.8 s.
tools/pvr/spg_beam_test.sh makes every read twice, kept and afresh,
straight and with every frame run ahead, and fails where they differ.
Where the adapter's memory is the processor's, kept coherent with its
cache (CacheCoherentUMA), the frame's vertices, indices and modifier
volumes' triangles are parsed straight into a buffer of a custom heap
with write-back pages, mapped for good, in four slices
(dx12/parse_arena_d3d12.h, C89): no copy into the upload ring. The
sorted passes' indices go after the frame's there. A slice is taken when
the context's fence has passed the value of the submission that last
drew from it, polled; with none free, or another adapter, the frame is
copied as ever. Render() is the base's, final, around RenderFrame().
d3d_hdr.c's D3DH_NOT_UMA has the adapter say otherwise and D3DH_EVERY
prints every frame's sum; d3d_parse_arena.sh checks every render drawn
from where it was parsed and every frame the one of the lists copied,
under wine.
The headless job installs gcc-aarch64-linux-gnu without what it
recommends, so libc6-dev-arm64-cross, which has the C library's headers,
is installed by name. ta_index_test.sh builds and runs a program with
those headers under qemu before it takes the NEON lane; without them it
says so and goes on, and with NEON=required, as the job runs it, fails
saying why.
With ARB_buffer_storage (OpenGL 4.4) the frame's vertices and indices are
parsed straight into a vertex and an index buffer the card reads, of
immutable storage mapped persistently in the client's memory, one pair a
frame in flight (gles/parse_arena_gl.h, C89): no glBufferData() copy of
them each frame. A slot is taken when the fence after the last frame
drawn from it has passed, asked without waiting; with none free, or where
the mapping reads back slowly, the frame is copied as ever. Both renderers
draw their strips from the frame's buffers and their own quads (VMU
screens, crosshairs, framebuffer) through their own. parse_arena.h's
slices can be bound apart, a buffer each.
A desktop build on an OpenGL ES context clears depth with glClearDepthf():
glClearDepth() is not ES's, and left the clear value as it was.
gl_parse_arena.sh checks every frame against the copy (GLF_NO_STORAGE),
no OpenGL error under MESA_DEBUG, and OpenGL ES as ever; gl_frames counts
no persistent mapping as a read.
The fast vertex loop tests each vertex it converts for being left out
of the indices - three words at once with SSE2 or NEON, as it has them
in hand - and marks a strip it wrote whole with none such in a bit a
polygon (ta_strip_ok, ta_index.h). make_index() then reads none of that
strip's vertices again. Any other strip is looked at as before. The
parse is 21-26% faster on the heavy disc (2.17 to 1.60 ns a vertex
with no vertex left out), its output the same on every test disc.
The heavy disc has three strips a list with a vertex left out (an
infinite x, a NaN depth, a huge y). ta_parse_bench.sh parses each frame
once more with no strip known good and fails if anything differs;
ta_index_test.sh tests the many-at-once test against the reference, as
SSE2, scalar and NEON (under qemu where there is an AArch64 compiler).
The frame's lists are ta_list.c's (C89): List<T> is a typed facade over
it. A strip's indices are ta_index.c's C89 kernel: one branch-free check
of the whole strip, then a straight run of indices; the per-vertex loop
only where a vertex is bad or the room runs out. The parse is about 20%
faster (2.74 to 2.17 ns a vertex on the heavy disc), its output the same
byte for byte.
With Vulkan on a machine whose video memory the CPU reads back fast (one
memory, as lavapipe's and integrated GPUs'), the vertices and indices
are parsed straight into a slice of memory the card reads, one slice a
frame in flight (rend/parse_arena.h, vulkan/parse_arena_vk.h), and the
translucent sort writes after them: no copy into the main buffer. Other
machines copy as ever.
Tests: tools/pvr/ta_index_test.sh (against the old loop, 1M strips),
tools/rend/parse_arena_test.sh, tools/vulkan/vk_parse_arena.sh (every
render in place, pictures those of the copy, each renderer, threaded,
upscaler, a change of size), tools/pvr/ta_parse_bench.sh; vk_hdr gains
VKH_UNCACHED, VKH_OPTS_AT and VKH_BUFFERS.
glsm's glFenceSync returns a void *, which clang does not make a GLsync
without a cast, and glsm has no glFlush: the copies off the card are now
flushed by a wait of no time on the last one's fence, with
GL_SYNC_FLUSH_COMMANDS_BIT.
tools/gl/gl_shapes.sh compiles the OpenGL renderers on Linux as macOS
(clang) and the Switch (libnx's GL symbols) build them, in CI.
A state saved or loaded copied the Dreamcast's SRAM, which it does not
have: no memory and a size of 0, a copy from or to a null pointer
(UBSan). Parts of no size are now nothing to copy.
headless.sh's run-ahead stage passes: its do-nothing OpenGL read back
from the mapping the core writes through, so what it fetched off the
card depended on the core's history, and frames run from a state loaded
were not the frames run straight. Readbacks are now the same bytes every
time. headless.sh runs in CI (Headless).
gl_frames runs frames ahead (GLF_AHEAD), and tools/gl/gl_ahead.sh runs a
disc (live_disc.py --keep) that renders to a texture at the very end of
a frame and only draws with it after: every frame run ahead has to show
what a plain run shows, the picture saved in the state while still on
the card. On OpenGL and OpenGL ES, and under ASan and UBSan in CI.
A block holds the blocks that jump to it, so two that jump to each other
hold each other. At the end the block tables were left as they were, and
when they went with the core's statics - the core unloaded with
dlclose(), or the process ending - those blocks and what they held were
never freed: about half a megabyte for a few hundred frames of the test
disc, each time a frontend unloads the core. bm_Term() now cuts the
links between them and empties the tables, nothing running the code by
then.
tools/threads/unload_leaks.sh runs the test discs' frames with the core
built with AddressSanitizer, unloads it, ends the process and fails on
anything LeakSanitizer finds; the sanitizers workflow runs it.
gl_frames.c unloads the core when no frame was drawn too.
The per-triangle and per-strip renderer's program discards what is
inside the clipping rectangle when the polygon asks to be drawn outside
it, as the per-pixel one's does: it compared the flag with -1, which it
never is, and drew the whole polygon. tools/gl/gl_clip.sh draws three
such polygons of one program, the middle one's rectangle another, on
each renderer with OpenGL and OpenGL ES (the test disc built with
-DLIVE_CLIP: tools/threads/live_disc.py --clip), and is run in CI.
That renderer sets a polygon's trilinear blend, palette and clipping
uniforms only when they differ from what its program was last given,
and its textures' LOD bias and anisotropy only when they differ from
what the texture has. The texture parameters are kept by texture name
in a table, not a map, and every texture deleted goes through the cache.
The sorter keeps its lists in memory only ever grown (grow_buf.h): a
SortList of draws a render pass, no std::vector anywhere in it or in the
renderers that call it. Triangles are sorted by depth with a stable
radix sort of (key, index) pairs (rend/sort_pairs.h, C89: three passes of
11 bits, a pass of one digit skipped; merged runs below 512, insertion
below 64), the same order a stable sort by < gives - about 8 times
std::stable_sort at 20,000 triangles. The strips (per-strip sorting) and
the prepass's runs go the same way, by the radix sort and a C merge sort.
SortPassesTo() sorts every pass and its prepass into one index array, and
SortPassesRoom() says how large it can be: Vulkan, Direct3D 11 and 12 call
these instead of each having the loop. Direct3D 9 now sorts straight into
its locked index buffer, as the others do into their mapped ones, instead
of into a vector per pass copied in after. OpenGL sorts into one buffer
and narrows it to 16 bits in place where the indices are.
tools/rend/sort_pairs_test.sh checks the sort against a stable sort by <
(CI). tools/rend/d3d9_frames.c is a Direct3D 9 frontend that checksums
every frame, and tools/rend/d3d_same.sh compares two Windows builds with
it and with d3d_hdr (Direct3D 9 needs Microsoft's d3dcompiler_47 under
wine: D3DCOMPILER).
A block copy into video memory (PVR-DMA, the channel 2 texture path) does
once, for the whole of it, what its writes did a page at a time through
faults: a picture rendered there that it replaces whole is dropped instead
of read back from the card and overwritten, one it covers in part is
fetched first, and the protected pages are opened and marked written with
one change of protection a run. A picture that settles is copied off the
card the frame before it is read, several fetched at once share one batch
and one wait, and a slot taken when all are full is the oldest one's.
Vulkan, Direct3D 11 and 12 and OpenGL 3 copy into memory of their own per
picture (Vulkan without a staging image at the console's scale, OpenGL
into pixel buffers, mapped and handed over with no copy of this side's,
its framebuffers kept). tools/threads/live_prog.c has a DMA build;
vk_dma.sh, gl_dma.sh (gl_frames.c: OpenGL on Mesa's surfaceless EGL),
d3d_dma.sh and rtt_watch_test.sh check it, in CI.
A CHD was read through one decoded hunk and a thread that decoded one
hunk ahead. A game that plays CD audio while it streams data reads the
two from different places a sector at a time, so each threw out the
other's hunk and aimed the thread away from it, and the hunks were
decoded on the emulation thread: a stutter a GDI never shows.
Each stream (data tracks, audio tracks) now reads through its own
libretro-common vfs_prefetch, whose thread decodes the hunks ahead on an
image handle of its own, one window per hunk; sectors are lent from the
windows in place, and a read command's Prefetch() sets the data
stream's thread going before the first sector is asked for. The core
defines HAVE_THREADS where it builds threads, so the prefetcher is not
compiled to stubs. tools/chd/chd_streams_test, run from tools/chd/run.sh
and now in CI, reads audio and data at once and fails when the reading
thread does the decoding.
The per-triangle Vulkan renderer draws for RetroArch's temporal upscaler
(RETRO_ENVIRONMENT_GET_HW_RENDER_UPSCALER_INTERFACE): it renders at the
size the upscaler asks for, under a Halton jitter, keeps each frame's
depth and draws its motion vectors, and hands both over with the
picture. The frontend then upscales to its viewport.
The Dreamcast sends screen-space vertices and no camera, so motion
vectors cannot come from a matrix. rend/upscaler.cpp matches each
opaque and punch-through strip of a frame with the strip of the frame
before that was sent under the same polygon header with the same number
of vertices, in order; the motion vector pass (shaders/mv.vert) draws
the difference over the frame's depth, equal or nearer, in pixels of
the render. A strip with no match, or one that jumped, stands still.
While the upscaler has the frames, the TA is parsed on the CPU (the
match needs its strips) and SSAA is off (the upscaler is the
anti-aliasing, and reads a single-sample depth). The other renderers
draw as ever, and the upscaler is told nothing.
tools/rend/upscaler_test.sh pins the matching, the request and the
inputs; tools/vulkan/vk_hdr.c gains a frontend with an upscaler
(VKH_UPSCALER), which vk_hdr.sh and vk_sanitize.sh run: the core draws
at the size asked for and hands over motion vectors and depth of that
size, read back and checked, under the validation layer and the
sanitizers.
With the HDR output, the screen's walk of Direct3D 12's compute renderer
also stores each pixel's channel sums, as Vulkan's does. It does so with
SSAA and with the X scaler's pairs of pixels. The sums are written into
the per-pixel renderer's R16G16B16A16_UINT image, so the encode
(hdr_encode.hlsl's HDR_ENCODE_SUMS) takes the exact average of the
samples where the picture is their resolve, and does not dither. The
walk is pvr_compute.h's with PVRC_SUMS: sumsImage at u1 of space 2,
which a second view in each piece's table holds, a null view for the
other kernels. Its variants for 1, 2, 4 and 8 samples, sorted and
unsorted, are DXIL of their own in dx12_compute_hdr_dxil.inc, made with
kernels_dx12.sh update-compute-hdr. Their pipelines are made at Init()
only with the HDR output on, so at 24-bit none of this exists. The sums
count where the walk alone wrote the picture, as on Vulkan: no Y filter
over it. Renders to a texture keep their walks without the sums.
dx12_compute_dxil.inc is unchanged: its sources still leave the
PVRC_SUMS blocks out. The new kernels are made by dxc 1.9.2609 with the
open-source validator (libdxil.so), which signs them. Each one is also
held to the compute renderer's root signature (-verifyrootsignature);
every kernel in both incs fits it. tools/rend/dxil_bindings.c
(kernels_dx12.sh bindings, in CI) reads the bindings each kernel
declares from its DXIL's PSV0 part. It checks that every HDR walk is
signed, binds what its walk binds plus the sums as a typed UAV of a 2D
texture, and that no other kernel binds the sums. It needs neither
Direct3D 12 nor dxc. Wine's vkd3d cannot make the compute renderer's
DXIL kernels, so under wine its frames are the per-pixel renderer's
(d3d_hdr.sh says so). Pipelines are now also released when frames on
the GPU are done with them, the walk's unsorted variants included.
With the HDR output and SSAA, Direct3D 12's per-pixel renderer now
encodes the exact average of the samples, as Vulkan's does, rather than
the byte the picture rounded it to, and does not dither. The screen's
last resolve also stores each pixel's channel sums. It uses a pipeline
of its own (DX12_RATE_PIXEL_SUMS), with the OIT_FINAL shader built with
DX12_OIT_SUMS, writing into an R16G16B16A16_UINT image. The sums are
scaled to HDR_SUMS_SAMPLES (16), now in hdr_output.h for every backend.
The image is made the first time, grown only, and is bound at u4 by a
root table of its own (DX12Context::OitSumsSlot). The encode reads the
sums (hdr_encode.hlsl's HDR_ENCODE_SUMS, PS_SUMS and PS_SUMS_LINEAR for
the post effects) where the picture is their resolve by
pvr_resolve_join(). Where something was drawn over it, the encode reads
the picture as before. Renders to a texture store no sums, and frames
with the write-out are encoded from the picture.
The new shader is built into an inc of its own, dx12_hdr_dxbc.inc,
with kernels_dx12.sh update-hdr. kernels_dx12.sh leaves the
DX12_OIT_SUMS block out of the other shaders' source, so
dx12_dxbc.inc and its sums are unchanged. At 24-bit none of this runs.
tools/hdr/hdr_d3d.sh 12sums gives the encoder the sums as the resolve
stores them, with an overdrawn strip, and holds the encode, then the
post effects' (bloom and aberration), to the exact average's. The old
code fails it (up to 10.7 times the tolerance, dithered).
tools/hdr/d3d_hdr.sh now also runs the Direct3D 12 core on wine's own
vkd3d with VKD3D_CONFIG=virtual_heaps: 24-bit, HDR10, scRGB and the
post effects, on every renderer. Without virtual_heaps the root
signature takes more than lavapipe's eight descriptor sets. It runs no
SSAA there: wine's vkd3d has no eval_snapped. CI runs
kernels_dx12.sh check.
The core options of beetle-psx's HDR post effects: HDR Bloom (and its
Selection, Range and Convolution), HDR Halation, HDR Chromatic Aberration
and HDR Post: Compact Intermediates. They are shown with an HDR Color
Format, on Vulkan, Direct3D 11 and Direct3D 12, every renderer of each.
With them on, the encode is three steps on every backend. First the
picture, or SSAA's channel sums, goes into scene-linear light in a
half-float image of its size (or 11/11/10 with Compact Intermediates,
where the device draws, blends and filters it). Then the bloom is built
from that image by the passes of one plan, hdr_post_plan_make(): the
bright pass, then either the two-band blur or the six-octave pyramid.
Last, the composite adds the aberration and the tinted bloom and encodes
as before. The shaders are beetle-psx's, in GLSL and in HLSL (one DXBC
for both Direct3D backends). What they need is made the first time they
are on, and the rasterizers' fused HDR subpass is left undrawn while
they are. Off, none of it runs, and nothing of it exists.
tools/hdr/hdr_post_ref.c runs the same three steps on the CPU from the
24-bit picture, rounding each image to its storage format and tapping
where the shaders tap, and reads the options the way the core reads
them. vk_hdr --post holds the scRGB picture to it:
- tools/vulkan/vk_hdr.sh runs every Vulkan renderer, with and without
SSAA, and each setting, and checks that other settings than the
picture's fail;
- tools/hdr/d3d_hdr.sh runs the Direct3D core;
- tools/hdr/hdr_d3d.sh post11 and post12 run the Direct3D 11 and 12
encoders under wine.
vk_sanitize.sh runs them under ASan and UBSan.
Each is fixed where it is, and the result is the same as before where
the old code was defined: the flash ROM's CRC (flashrom.h) and the AICA
filter's fraction (sgc_if.cpp) no longer shift negative values left;
div1 subtracts b modulo 2^32 rather than negating INT_MIN; the x86 and
x64 recompilers keep their host registers in an s8 and the ARM ones
have a -1 enumerator, so the lists' -1 end is a value the type has; the
modifier volumes' bounds read a vertex's x and y with an unaligned 8-byte
load (rend/shadows.h). xbrz's debugger break is MSVC's own, and is now
only there: make DEBUG_ASAN=1 and DEBUG_UBSAN=1 build with gcc and clang.
A renderer that cannot be set up on the frontend's context (Direct3D 12
or 11 with no device or queue) no longer takes the frontend down: the
frames run, none is drawn, and the next context reset tries again.
The Sanitizers workflow builds the core with each sanitizer and runs the
test disc on every Vulkan renderer at 24-bit and HDR, failing on any
report (tools/vulkan/vk_sanitize.sh); tools/hdr/d3d_hdr.sh runs the
Windows build on a refused Direct3D 11 and 12 device, threaded rendering
on and off.
A Color Format core option hands the frontend 30-bit HDR10 or 64-bit
scRGB instead of the 24-bit picture, on Vulkan, Direct3D 11 and Direct3D
12 and every renderer of each, through the libretro HDR API (the pixel
formats, GET_DISPLAY_METADATA, GET_HDR_METADATA). The picture is placed at
the frontend's paper white and mapped onto the display through a Display
Transform (beetle-psx's, vendored in rend/hdr/: Reinhard knee by default,
which keeps everything below paper white as it was, ACES, ACES 2.0, AgX,
PBR Neutral, GT, Hable and others), with optional HDR Expansion. At
24-bit, or when the frontend refuses, none of it runs and the picture is
the same to the byte. On Vulkan the encode is the last subpass of the
frame's render pass on the rasterizers and one draw on the compute
renderer and CPU framebuffers, recorded into the frame's own submission
(after the chip's write-out on a frame that has one);
on Direct3D 11 and 12 it is one draw in the frame's context or command
list, from one shared DXBC blob (tools/rend/kernels_dxbc.sh update-hdr).
Nothing is copied and no submission or wait is added. ACES 2.0 (Full)'s
cube is baked off the frame by a worker thread handed its jobs through
atomics and an eventcount, without locks.
tools/vulkan/vk_hdr.sh runs every Vulkan renderer at each Color Format
and judges the pictures; tools/hdr/d3d_hdr.sh does the same with the
Windows build on Direct3D 11 under wine; tools/vulkan/hdr_hlsl.sh and
tools/hdr/hdr_d3d.sh hold the HLSL, and the Direct3D 11 and 12 encoders
under wine, to the GLSL over every curve and setting; tools/hdr/hdr_cube.sh
holds the worker's cube to the cube baked in place, under TSan and
ASan/UBSan. All of them run in the Vulkan negotiation workflow.
The C++11 backend hands the value argument straight to std::atomic_init,
std::atomic_store_explicit and the std::atomic_fetch_*_explicit templates.
Before P0558R1 (libstdc++ 8 and older) those deduce the element type from
the value as well as from the pointer, so EmuBaton's unnamed enumerators
and PsoState fail to deduce and the core does not build on GCC 8 (#1215).
The macros now cast the value to int, as the size_t ones already do, which
is what the member-function forms of the same operations do anyway.
tools/threads/old_stl.sh keeps it that way: it builds a TU with the core's
uses of every value macro against the host <atomic> and runs it, then
parses it again against a stand-in <atomic> with the pre-P0558R1
signatures, so the failure shows on any compiler. The old-stl workflow
runs it under GCC and clang.
Where the frontend supports Vulkan context negotiation v2, the core
offers create_device2 and makes its device with the frontend's
vkCreateDevice wrapper, which adds the extensions and features the
frontend wants - in RetroArch, VK_NV_low_latency2 or VK_AMD_anti_lag for
Driver Pacing, which a device the core makes itself never has (Driver
Pacing: "Off: the core made the device without it"). A frontend without
v2 is offered version 1 as before.
tools/vulkan/vk_negotiate.sh negotiates the device both ways under the
validation layer, as RetroArch (where the device must be made through
the wrapper) and as a frontend without v2; the new Vulkan negotiation
workflow runs it on lavapipe.
libretroadmin