Caught by the CI.

This actually needs to test for the full format (pointer) equality, not
just the name. This fixes an issue where FBO format changes could
trigger validation errors.

MAX_UNIFORM_COMPONENTS is not available for GLES 2.0, but the similar
MAX_UNIFORM_VECTORS is. Neither of these map particularly well anyways.

Since we're using host-mapped buffers. This implies radically different
capabilities and limits.

This avoids spamming the log with benign errors, when host-mapped
textures are not available.

SDL has to be included before any possible system header includes,
as it defines some feature test macros like _DARWIN_C_SOURCE,
which is required to make memset_pattern4 available.
But if a system header is included before already, it did not have
the needed define and the function will be missing, leading to an error
like:

  SDL2/SDL_stdinc.h:434:5: error: implicit declaration of function
  'memset_pattern4' is invalid in C99

The simplest fix for this is to just swap the includes order.

D3D11 is Windows-exclusive, ensuring that these functions are always
available, avoiding a dependency on pthread

Turns out this is incredibly useful when testing kmsdrm stuff...

This prevents "flashing" due to delayed colorspace information on
startup. Also do the usual params struct shenanigans to make this API
less annoying.

Otherwise, on HDR / wide gamut swapchains, this results in hilariously
broken output.

As a side note, this may be somewhat undesirable for the background
color selector, since the actual chosen color in the UI will not
correspond to the color as seen on-screen. Maybe we should have
pl_renderer treat the background color as sRGB too. That would make it
impossible to have super-bright HDR backgrounds though. Does anybody
care about that?

Use ths new functionality introduced in the previous commit.

These set the exact HDR metadata from the content tagging.

In retrospect, I think I really regret not making these part of
`pl_frame` to begin with. But oh well, that bullet is swallowed for now.
I'm not breaking that API for a while.

Rather than only being able to set `prefer_hdr` on swapchain creation,
this API allows updating the swapchain colorspace hint at runtime.
Deprecate `prefer_hdr`, and also remove `surface_format` entirely as it
was getting very much in the way of this functionality (and also made
little sense apart from debugging use cases).

This allows dynamically turning on and off HDR mode, and also allows
picking the best output mode depending on the content even in the
absence of HDR metadata.

Currently only implemented for Vulkan, and only for drivers supporting
VK_EXT_swapchain_colorspace.

Partially addresses #152

Probably useful for debugging.

Also, apparently, a lot of things _aren't_ actually being tested
(specifically certain upscalers).

BT.709 -> sRGB requires tone-mapping, so pick something else.

These are randomly failing in the CI and I have no idea why. Time to
find out.

glfw3 and Vulkan disagree on the calling convention to use on x86
Windows, resulting in mismatching function definitions.

The underlying type of pthread_t is not guaranteed, and the check fails
if its not a numeric or pointer value.

Fixes building on some configurations on Windows.

clock_gettime is not available on Windows, instead query the
high-performance counters.

nanosleep is not available on Windows. Since Sleep is in milliseconds,
Sleep(0) can be used to yield the remainder of the current time slice,
but remain ready to run - avoiding a busy loop.

Fixes building with the vulkan headers in a separate directory.

time_t could be 32-bit, as is the case on e.g. MSVC winpthread. The spec
doesn't guaranteed anything here.

Easiest solution is to simply treat UINT64_T as a special case.
Arguably, this is more efficient, too.

Might be useful. Easy to support.

This matches the documentation and fixes a type mismatch when building
natively on Windows.

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 #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 #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.