Releases: xenia-project/release-builds-windows
v1.0.2844-master
Windows release build for xenia-project/xenia@95a5c3e.
[GPU/WGF] Bind EDRAM to resolve dumping via ByteAddressBuffer
Simplifies binding by eliminating the need to switch between 32-bit and
64-bit views, and makes it possible to bind the EDRAM via a root descriptor
on Direct3D 12.
v1.0.2843-master
Windows release build for xenia-project/xenia@17bc5b4.
[GPU/D3D12] Remove now-unused typed shared memory descriptors
All usage instances changed to ByteAddressBuffer.
v1.0.2842-master
Windows release build for xenia-project/xenia@80dad41.
[GPU/WGF] Use ByteAddressBuffer in precompiled shaders
Drivers and hardware may provide more optimal paths for untyped buffers
compared to typed.
Also, ByteAddressBuffer may be bound via a root descriptor in Direct3D 12,
greatly simplifying the binding logic.
ByteAddressBuffer also doesn't have the 128 * 2^20 element count limit that
typed and structured buffers have, and doesn't require the structure stride
to be specified at resource creation time in Direct3D 11.
v1.0.2841-master
Windows release build for xenia-project/xenia@c7f6134.
[GPU/D3D12] Convert gamma-as-linear red to gamma in transfers to stencil
Co-authored-by: Herman S. 429230+has207@users.noreply.github.com
v1.0.2840-master
Windows release build for xenia-project/xenia@0a19234.
[GPU/D3D12] Add forgotten gamma conversion format check
v1.0.2839-master
Windows release build for xenia-project/xenia@cec9ca0.
[GPU] 8-bit PWL gamma RT as linear 16-bit UNorm on the host
With render target HLE, directly store linear values as R16G16B16A16_UNORM
without gamma conversion, as this format provides more than enough bits
(need at least 11 per component due to the maximum scale being 2^3 in the
piecewise linear gamma curve) to represent linear values without precision
loss.
This makes blending work correctly in linear space, improving quality of
transparency, lighting passes, and fixing issues such as transparent parts
of impact and footstep decals in 4D5307E6 being bright instead.
The new behavior is enabled by default, as it hugely improves the accuracy
of emulation of this format, that is pretty commonplace in Xbox 360 games,
with likely just a small GPU memory and bandwidth usage increase, compared
to the alternatives that were previously available on the HLE RB path.
It's currently implemented only on Direct3D 12, as most of the current GPU
emulation code is planned to be phased out and redone, and no methods other
than 8-bit with pre-conversion were implemented on Vulkan previously.
To implement on Vulkan later, same conversion as in the Direct3D 12
implementation will need to be done in ownership transfer and resolve
shaders. Currently it's somewhat inconvenient to decouple the conversion
functions in SpirvShaderTranslator from an instance of the translator due
to vector constant usage. Later, simpler SPIR-V generation functions may be
added (spv::Builder usage in general is overly verbose).
The previously default method (8-bit storage with pre-conversion in shaders
and incorrect blending) can be re-enabled by setting the
"gamma_render_target_as_unorm16" configuration option to false. This may
be useful if the game, for instance, switches between 8_8_8_8_GAMMA and
8_8_8_8 formats for the same data frequently, as switching will result in
EDRAM range ownership transfer data copying now. Also, the old path is
preserved for Vulkan devices not supporting R16G16B16A16_UNORM with
blending.
The other workaround that was available previously, replacing the PWL
encoding with host hardware sRGB with linear-space blending in render
target management and in texture fetching, was also inherently inaccurate
in many ways (especially when games have their own PWL encoding math, like
4541080F that displayed incorrect colors on the loading screen), and
required tracking of the encoding needed for ranges in the memory.
The sRGB workaround therefore was deleted in this commit, greatly
simplifying the code in the parts of render target, texture and memory
management and shader generation that were involved in it.
v1.0.2838-master
Windows release build for xenia-project/xenia@f2fabfd.
[GPU] Change "bpe" to "bpb" (bytes per block) in comments
Forgotten in the other "element" to "block" change.
v1.0.2837-master
Windows release build for xenia-project/xenia@88f95a8.
[GPU] Change "element" name back to "block" in texture addressing
The 32_32_32_FLOAT format seems to be vertex-only, so it looks like there
can't be storage elements smaller than a single texel.
So, use a more precise name that can't be confused with "picture element"
(pixel) or "texture element" (texel) that represents a single logical pixel
rather than a storage block of pixels.
v1.0.2836-master
Windows release build for xenia-project/xenia@c4e1242.
[D3D12] Include recent D3D12 headers from the Microsoft GitHub
v1.0.2835-master
Windows release build for xenia-project/xenia@9535e61.
[GPU] Change texture address local X offsetting back to addition
More likely to be emitted as an immediate load/store offset in host
hardware shaders.