Emmanuel Gil Peyrot authored 3 years ago and Niklas Haas committed 3 years ago

EGL_EXT_image_dma_buf_import_modifiers defines two functions, one to
query the supported formats and one to query each format’s modifiers.

This patch removes the spurious EGL_BAD_PARAMETER that were displayed
when running the opengl_surfaceless test on Mesa (tested on Lima and
Iris), by only querying modifiers for formats we know are supported.

Also noteworthy is that out of the tested formats, only R8 and R16 are
supported on Iris, only R8 on Lima.  On both tested drivers, RG88 isn’t
supported (GR88 is though), neither is RA24 (rgba8, but AR24/argb8 is)
nor RG24 (rgb8).  It might make sense to change our component ordering
preferences in order to support Mesa drivers better.

If iterations is 0, we can skip generating this header (and the
associated specialization constants).

Oops.

The DRM fourcc formats are specified in little-endian MSB to LSB order,
which is the exact opposite of the memory order convention that we use.
So we simply have to reverse all of these format modifiers.

Closes https://github.com/haasn/libplacebo/issues/103

Compound Literals are not valid in C++, which breaks C++ compilers
which do not include non-standard extensions for C++ Compound Literals.

In particular, this fixes building against libplacebo with MSVC in a C++
project.

While MSVC has its own deprecation attribute, its more restrictive in
positioning and does not work for PL_DEPRECATED without further changes
- hence disable it for now.

Since this needs to be rounded up, not down, for odd sized images.

It really makes little sense to auto-detect peaks below SDR nominal
white. If this happens, it's far more likely that the scene is simply
dark (or black), and we should avoid over-compensating the tone mapping
for this scenario.

Fix it by adding a configurable lower bound, defaulting to 1.0.

Closes videolan/libplacebo#161

The dependency may not specifically specify the include directories, but
contain compiler arguments to find the include directory.

This fixes building with vulkan-link=false in certain configurations.

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

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.