Add a pl_gpu implementation that uses Direct3D 11. This uses SPIRV-Cross
to translate shaders from GLSL to HLSL. In its current state, plplay
works and the test suite passes with feature level 10_0 and up. (9_x is
unlikely to ever pass due to runtime-enforced shader complexity limits.)

Missing features include emulated texture formats, cached_program,
`pl_gpu_limits.thread_safe`, and HDR/high bit depth support in
pl_swapchain, though these shouldn't be too hard to implement.

This also updates the GLFW demos to be able to use Direct3D 11 through
GLFW_NO_API.

Closes #18

Rather than fixing/determining the pl_glsl_version at compiler creation
time, this is now taken dynamically as a compilation parameter. In
addition to this, the exact API / target version to compile against will
be inferred from the GLSL description, rather than set explicitly. This
allows us to take into account some of these limits during shader
compilation.

Move stuff into the common glsl/ subdir, mostly to allow the creation of
glsl/utils.h which contains shared helpers between C and C++ that can't
be placed into spirv.h directly due to C99/C++ incompatibility.

Finally, rename some usage sites for consistency, enabling `stage` to
always refer to the shader stage, `shader` to refer to the shader
itself, and `glsl` to refer to the pl_glsl_version struct.

Requires bumping the shaderc dependency. Fortunately, none of the usual
candidates (debian stable etc.) even *package* ubuntu, so we're fine.

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

`pl_pass_run_params.target` should only be used for PL_PASS_RASTER and
ignored for PL_PASS_COMPUTE, however pl_pass_run was invalidating the
texture for both types of passes.

This was found because `pl_dispatch_finish` unconditionally sets
`target` for both types of passes. That should be harmless, but since
`load_target` only gets set for raster passes, it resulted in
`pl_dispatch_params.target` always being invalidated for compute passes.

Since our libav helpers rejects BE formats, using the NE-dependent
aliases here is wrong. This makes the test framework pass on BE
platforms. Though I'm not very convinced that the code actually works
correctly, it's probably impossible to test in the absence of BE GPUs to
test against.

Closes videolan/libplacebo#160

Required to be able to include the header.

Not entirely happy with the presentation, but I also can't particularly
be bothered to prettify it. It serves its purpose of illustrating this
functionality.

Forwards the information from the dispatch to the renderer API user, in
the most transparent way, while also adding metadata about what "kind"
of operation we're performing (frame rendering or blending).

Closes videolan/libplacebo#156

Minor refactor to avoid carrying around `params` everywhere.

This quasi-deprecates the raw `pl_timer` API with something nicer that
also gives you some extra metadata, including integrated pooling of the
timer results.

These are a much better way to figure out what's actually going on
inside a shader than relying on the shader text alone.

GL_KHR_vulkan_glsl requires this version, even though we let the user
(in theory) override the GLSL version to arbitrarily low values.

This prevents undefined behavior in the hypothetical case of these
limits being very low.

Technically this omits some limits such as checking against
maxPerStageDescriptorSamplers for PL_DESC_SAMPLED_TEX, but I'm going out
on a limb here and assuming that maxPerStageDescriptorSampledImages will
never be lower than maxPerStageDescriptorSamplers.

CI doesn't catch this patch because CI doesn't have DRM modifiers.

Same justification as for vulkan. I decided not to create `gpu_buf.c`
because the OpenGL buffer code is comparatively tiny.

This was a pretty monolithic file that was getting hard to work with or
view changes in. Split it up as best I can.

Refactored some things along the way, such as reducing the use of
mostly-obsolete helpers, and fixing a thread safety bug for the lazy
destructors.

D3D11 only supports readonly or writeonly access for a lot of otherwise
storable formats, because readwrite access is its own special thing in
D3D11. To support this, restrict the ability to use READWRITE access
behind a new capability, since its usage is relatively rare (only really
mattering for the compute shader blend emulation code, in which case
this cap merely exists to prevent us from accidentally auto-upgrading
shaders for non-readwritable storage images).

Turns out D3D11 is actually a special enough snowflake to not support
buffer<->texture copies, instead they introduce "shadow textures" to
serve as quasi-buffers that can only be used for buffer transfers.

They don't really fit into our architecture, and nothing *really*
depends on it anyway (except mapped buffers, for which a check is easily
introduced in the few places that use them).

I wasn't happy with this bit field. It was clumsy, interfered with
rebases, limited to 64 entries, awkward to work with, and didn't really
serve any practical purpose.

Additionally, a lot of these fields make far more sense in
`pl_glsl_desc` rather than `pl_gpu_limits`, especially the ones that
only affect shader generation, as these are also useful for `pl_shader`.

Rename it to `pl_glsl_version` while we're breaking everything, to
prevent confusion with descriptors  which are also confusingly called
`*_desc` everywhere.

The various `blacklist_caps` fields were deleted without a deprecation
because I don't think they had any users other than our own CI.

This was missing a check, print-out and `dummy` entry.

Biswapriyo Nath authored 3 years ago and Niklas Haas committed 3 years ago

The gnu_printf format attribute is specific for GCC toolchain.
If clang/llvm is used in MinGW environment that attribute is
shown as compiler warning not supported 'format' attribute.

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

It's valid for pl_pass_create not to write a cached program. In this
case, pl_dispatch_save should only write the number of passes that have
a program to save, in order to prevent a buffer overread in
pl_dispatch_load.

This also updates pl_shader_tests to handle passes that don't write
a cached program.

I think it's becoming increasingly clear that users expect the look and
feel of the desaturated tone mapping, probably due to the fact that it's
also the easiest to implement and therefore the most common. But more
importantly, it avoids very weird results for strongly saturated
highlights.

This mainly affects the users of `pl_color_space_infer`, i.e.
pl_renderer and pl_shader_color_map.

Now that we handle black points correctly (and infer a 1000:1 contrast
as well), I think this results in marginally better results than the
naive gamma 2.2 fallback.

As a slight exception, still infer gamma 2.2 for linear light content,
to avoid unnecessary black point adaptation. This is very unlikely to
affect most users.

This is far better than ping-ponging between this and `image.color`,
especially because it avoids e.g. unnecessarily adapting the black point
back and forth between it and linear light. In the ideal case, this
makes it a no-op.

It also means we now effectively perform frame blending in linear light,
which I think is a net gain anyways, especially because it also avoids
needing to unlinearize every single frame in the mixing shader (though
one could in theory also easily fix that problem by moving it to the
previous step).

Also fixes an issue where this adaptation resulted in incorrect results,
although truthfully I'm not entirely sure why.

Too lazy to write a proper getopt() loop atm, I just need this for some
quick debugging.

Useful for debugging tone mapping and stuff, especially by explicitly
setting the output color space to PQ.

One annoying thing is that switching from an SDR curve to PQ doesn't
inherit an SDR contrast, unless you switch to BT.1886 first. Could
probably be handled smarter in some ways, but I suppose this is good
enough.

Another annoying thing is the lack of precision for nuklear's float
properties, but oh well.

This is a massive change, and a big departure from the current way of
handling colorspaces / black points (which was passing it off to the ICC
backend or else just defaulting to gamma 2.2).

We now fully track black points, giving rise to effective contrast
information, in particular for absolute luminance EOTFs (PQ, HLG,
BT.1886). The tone mapping shaders have been adapted to adjust the black
point as required.

This also means that we now effectively correctly handle BT.1886
emulation even on displays without ICC profiles. This *would* ordinarily
severely alter the default presentation, so we also change the default
transfer of pl_color_space_monitor from gamma 2.2 to UNKNOWN, which
allows the color mapping to avoid adapting typical SDR signals for
unknown displays. (Something that should have been done a while ago, to
be honest)

Requires an unfortunate API break for `pl_shader_(de)linearize`, but as
far as I can tell, these APIs are very un-used, so I'm not too worried.

Also remove an undocumented and useless parameter from
PL_TONE_MAPPING_CLIP, which now does exactly what it says.

Closes #151

This incorrectly always clipped to the interval [0.0, 1.0] even for HDR
outputs where such clipping is completely wrong. Fix it by clipping to
the correct volume.

These are unlikely to change to the extent that would make this
usage of specialization constants problematic.

Truthfully the only motivation for this commit is that I want to have
PL_COLOR_TRC_GAMMA24 exist for backwards compatibility with the legacy
handling of (non-black-scaled) BT.1886.

In theory we could also probably do something smarter like encoding the gamma
value into the enum value itself, but that can also be done later and I
don't want this commit to become that invasive. (And it sets a precedent
I don't like with regards to how to handle unknown enum members in
switch statements)

Missed by 3c705836

This is basically the reason that feature was added.

This can remove the recompilation overhead from programs such as
`plplay` which expose lots of settings as freely adjustable GUI sliders.
Normally, this would trigger a recompilation on every frame. Lifting
those constants to variables improves this.

Care needs to be taken not to lift constants that will be used as the
inputs of arrays, such as with the polar sampling code. Also, we now
need to avoid the `const` keyword on things that ingest `sh_const`.

Add an API for this to pl_dispatch and pl_renderer, respectively.

Not a whole lot to be done here.

As written, these continued pointing to the old data, perhaps
indefinitely. But it's in the spirit of `pl_shader_custom` (and the rest
of the libplacebo API) to allow these to go out of scope.

Fix it by correctly strduping these names.

Not much opportunity here.

For everything except values that depend on `sub_x` or `sub_y`, because
they're quite pervasive and unlikely to change dynamically.

Nothing too exciting.