James Ross-Gowan authored 3 years ago and Niklas Haas committed 3 years ago

libplacebo requires formats to be sampleable if they are gatherable.
With the real D3D11 runtime, that isn't a problem, since FL11_1 has no
gatherable UINT or SINT formats. However, DXVK seems to expose
gatherable UINT and SINT formats. Since we never consider integer
formats to be sampleable, we unset the sampleable flag (but not the
gatherable flag) which made libplacebo assert when verifying the format
list (in gpu.c.) Instead, only set gatherable when sampleable is set.

For most D3D11 debug layer messages, we map the message severity code to
a libplacebo log level, however there are certain messages that are
logged very frequently, often every frame, that deserve a lower log
level than the D3D11 severity code would suggest.

For those messages, add a function to map the log level of certain
message IDs so we can manually lower them to PL_LOG_TRACE without
affecting other messages with the same severity code.

Specifically, this change should prevent log spam from creating and
destroying view objects for swapchain backbuffers on every frame by
forcing all object creation and destruction messages to be PL_LOG_TRACE.
It also maps some query-related messages that were previously disabled,
since they might be useful to know at the trace log level.

Fixes https://github.com/haasn/libplacebo/issues/118

Fixes some build warnings. Might as well start only depending on stable
tags from now on.

Rather than messing about with a (highly symmetric) matrix, just expand
out the raw mathematical operations. Saves some cycles on the GPU, and
in exchange for this I'm comfortable "wasting" those cycles in the
luminance mode, in exchange for code simplicity.

In particular, fixes an issue introduced in the previous commit where
PL_TONE_MAP_HYBRID no longer benefited from the crosstalk math.

Incorporate the improvements from BT.2446a luminance mode, and also make
sure to avoid potential clipping of low brightness details by reverting
back to RGB near the target black point.

Fixes https://github.com/mpv-player/mpv/issues/9781

Older versions of the Direct3D 11 runtime return an error code from
D3D11CreateDevice when they don't recognise one of the requested feature
levels. Previously, we'd try to work around those errors by retrying
device creation with a smaller set of feature levels, but since we did
that regardless of the error code, when device creation failed for
reasons other than invalid feature levels, we'd still try creating the
device up to 6 times, and we'd never actually log the error code until
the last attempt, which might have failed for a different reason.

These unnecessary retries could also be especially annoying under Wine,
which can log debug messages for every failed attempt.

When D3D11CreateDevice fails due to unrecognised feature levels, it
returns E_INVALIDARG, so only adjust the feature levels on E_INVALIDARG.
When falling back to the WARP driver, log the error code. That way we
always know the error code when device creation fails, and we eliminate
some unnecessary retries.

The Direct3D 11.0 debug layer in the June 2010 DirectX SDK will
segfault if ID3D11Device::CheckFormatSupport is called on Direct3D 11.1
formats.

Previously, we used the DXGI_ERROR_SDK_COMPONENT_MISSING status code to
determine the if the debug layer failed to load, however that didn't
work with Direct3D 11.0, because it returns E_FAIL instead. A more
reliable method, which is used in Microsoft sample code, is to determine
the presence of the debug layer before the actual device creation by
attempting to create a device with the NULL driver and the debug layer
enabled.

This change also raises the log level of the message printed when the
debug layer is missing, since it should be easy to tell if a lack of
debug messages is because the debug flag was disabled or the debug layer
was not installed correctly.

ClearUnorderedAccessView is only available in float and unsigned
int formats, so when emulating signed int formats one has to
cast across the sign.

Technically possibly evil, but as the same data type is utilized
(int32_t pointer <-> uint32_t pointer) one would hopefully expect
this to work.

James Ross-Gowan authored 3 years ago and Niklas Haas committed 3 years ago

Blit emulation in FL10_1 and below uses a render pass, which means
textures are blittable if they're sampleable and renderable. So this was
a typo...

Some formats don't support this cap, and we don't strictly need it
(since we can work around it using pl_tex_blit_raster).

I plan on perhaps refactoring PL_FMT_CAP_BLITTABLE into
PL_FMT_CAP_BLITTABLE_1D_3D in the future, but for now, this fix is
needed.

And fall back to linking against -latomic otherwise, which seems to be
annoyingly needed on some platforms.

Fixes videolan/libplacebo#181

64-bit is way overkill here and requires the presence of 8-byte atomic
operations, which may even have to be emulated on some platforms.

Arguably even 32-bit is overkill, but should be on the safe side.

Over the years this has failed sporadically on various older GL versions
and I'm at my wit's end trying to keep track of them all. So just ignore
failures here.

Fixes https://github.com/mpv-android/mpv-android/issues/482

Test on a synthetic combination of 8-bit color values and 10-bit sample
depth, and also split the decoding into a separate normalize step to
more closely mimic what happens in the actual renderer.

When e.g. normalizing 10-bits-in-16 color values, the resulting color
values are as they would be for a 16-bit sample, not for a 10-bit
sample. So we need to set the color depth to the sample depth, not the
other way around.

Otherwise, this breaks YCbCr decoding later on, resulting in a green
shift (among other issues).

Should fix https://github.com/mpv-player/mpv/issues/9403

The caps check was wrong, since both caps are needed.

Previously, HLSL registers were allocated based on `pass->descriptors`,
however it's simpler if resource allocation, and hence the arrays saved
with the cached program, only depend on the shader code. This changes
register allocation to use only information provided by SPIRV-Cross'
reflection API instead of `pass->descriptors`.

As a side effect of this change, a few aspects of shader compilation
have been improved and simplified. There is no longer a separate
function to compile GLSL to SPIR-V and SPIR-V to HLSL, since there's no
longer any reason not to do one step right after the other. Also, during
compilation, the resource arrays are now a list of binding numbers
instead of descriptor indexes, which means that the shader cache no
longer depends on the order of the `pass->descriptors` array.

Note that this includes code to support uniform samplerBuffers, however
it's untested since `PL_DESC_BUF_TEXEL_UNIFORM` is only used in
`pl_tex_upload_texel`, which isn't used by d3d11 (yet.)

James Ross-Gowan authored 3 years ago and Niklas Haas committed 3 years ago

The do {} while(0) style of multi-statement macro swallows the
following semicolon (not that it matters here.)

Even for no-op shaders. Failure to do so can lead to shader compiler
errors due to signature mismatch if this is the only pl_shader function
call.

Users can still override this explicitly in practice, and compiling with
-O0 is almost never what you want to do unless you're explicitly
developing the library (in which case, by all means, override it)

By default, with -O0, this uses ~1 MB of stack, which exceeds the
default stack frame size on Windows. There's really no good reason for
us to keep this state on the stack, when static memory would work just
as well.

This is a regression of e85d27f6 introduced in 2b66d74a.

For compatibility with mpv. Requires some minor restructuring of the
code flow to make the aliasing logic conditional, but IMO the code is
better overall for it.

Oops.

Rather than storing the compiler version and name explicitly, just merge
them into the (pre-existing) signature hash. Also, offload the hashing
to the spirv compiler itself.

Make sure struct changes don't suddenly break this pl_mem_hash call.

This reverts commit a3271f80.

This fix was ineffective and, in practice, MSAN already catches the use
of `pl_mem_hash` on unpadded structs for me, e.g.:

==105503==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x509c6c in finalize_pass /home/nand/dev/placebo/build.msan/../src/dispatch.c:867:13
    #1 0x51c2e5 in pl_dispatch_vertex /home/nand/dev/placebo/build.msan/../src/dispatch.c:1492:25
    #2 0x64ecc6 in draw_overlays /home/nand/dev/placebo/build.msan/../src/renderer.c:833:19
    #3 0x61530a in pass_scale_main /home/nand/dev/placebo/build.msan/../src/renderer.c:1749:5
    #4 0x5fa090 in pl_render_image /home/nand/dev/placebo/build.msan/../src/renderer.c:2550:10
    #5 0x4acb0f in pl_render_tests /home/nand/dev/placebo/build.msan/../src/tests/gpu_tests.h:1095:5
    #6 0x4897af in gpu_shader_tests /home/nand/dev/placebo/build.msan/../src/tests/gpu_tests.h:1447:5
    #7 0x487be3 in main /home/nand/dev/placebo/build.msan/../src/tests/vulkan.c:194:9

(At least the one in dispatch.c. It doesn't catch the ones in renderer.c
for some reason, but I'm also less worried about those because they
don't have any relevance outside the renderer's internal state invalidation,
where a false positive doesn't cause real harm)

If the source has multiple pivots for more than one component, the
current code fails compiling, with a macro redefinition error.

This is a safer way to hash structs than calling pl_mem_hash on them,
since it avoids hashing indeterminate values from padding bytes.

Combined into `pl_hash_merge` due to shortcomings of the C macro system
(cannot make this an expression).

This should be bgra8, for consistency with desktop GL. The actual format
is non-opaque and represented using 8 bits. Allows users to use
pl_find_name_fmt(gpu, "bgra8") across all platforms.

Rather than having a separate shader per number of pivots, simply
subdivide into the two cases "no pivots" and "N pivots". The "no pivots"
optimization still covers the (very common) case of there being no
pivots for chroma MMR.

Change the N pivots case from a loop to a tree-style branching select,
which is faster anyways. This helps recover the lost performance (and
then some).

Significantly reduces mid-stream shader recompilation overhead.

In saturation intent, we want to directly stretch from the source
mastering primaries to the target mastering primaries. In either intent,
we want to apply gamut clipping etc. to be relative to the target
mastering primaries, not the nominal encoding gamut.

Change the way this is handled. As an aside, also perform primary
conversion in normalized space, which I believe fixes some sort of
regression in the way gamut mapping is done.

This reverts commit c80ba5d2.

There's no reason for this revert other than that it causes problems
with the CI msan for unfathomable reasons, and I don't have time to
debug it right now. Plus the fact that there's no real motivating case
here anyway.