haasn / libplacebo

Official mirror of libplacebo

libplacebo

libplacebo is, in a nutshell, the core rendering algorithms and ideas of mpv rewritten as an independent library. As of today, libplacebo contains a large assortment of video processing shaders, focusing on both quality and performance. These include features such as the following:

• High-quality, optimized upscaling and downscaling including support for polar filters ("Jinc"), anti-aliasing, anti-ringing and gamma correct scaling.
• Dynamic HDR tone mapping, including real-time measurement of scene histogram, scene change detection, dynamic exposure control, perceptual gamut stretching, contrast recovery and more.
• Native support for Dolby Vision HDR, including Profile 5 conversion to HDR/PQ or SDR, reading DV side data, and reshaping. (BL only, currently)
• A colorimetrically accurate color management engine with support for soft gamut mapping, ICC profiles, accurate ITU-R BT.1886 emulation, black point compensation, and custom 3DLUTs (.cube).
• A pluggable, extensible custom shader system. This can be used to arbitrarily extend the range of custom shaders to include popular user shaders like RAVU, FSRCNNX, or Anime4K. See the mpv wiki on user scripts for more information.
• High performance film grain synthesis for AV1 and H.274, allowing media players to offload this part of decoding from the CPU to the GPU.
• Tunable, fast debanding and deinterlacing shaders.
• High quality gamma-correct dithering, including error diffusion modes.

Every attempt was made to provide these features at a high level of abstraction, taking away all the messy details of GPU programming, color spaces, obscure subsampling modes, image metadata manipulation, and so on. Expert-level functionality is packed into easy-to-use functions like pl_frame_from_avframe and pl_render_image.

Hardware requirements

libplacebo currently supports Vulkan (including MoltenVK), OpenGL, and Direct3D 11. It currently has the following minimum hardware requirements:

• Vulkan: Core version 1.2
• OpenGL: GLSL version >= 130 (GL >= 3.0, GL ES >= 3.0)
• Direct3D: Feature level >= 9_1

For more documentation, including an introduction to the API, see the project website.

Examples

This screenshot from the included plplay demo program highlights just some of the features supported by the libplacebo rendering code, all of which are adjustable dynamically during video playback.

History

This project grew out of an interest to accomplish the following goals:

• Clean up mpv's internal RA API and make it reusable for other projects, as a general high-level backend-agnostic graphics API wrapper.
• Provide a standard library of useful GPU-accelerated image processing primitives based on GLSL, so projects like media players or browsers can use them without incurring a heavy dependency on libmpv.
• Rewrite core parts of mpv's GPU-accelerated video renderer on top of redesigned abstractions, in order to modernize it and allow supporting more features.

It has since been adopted by VLC as their optional Vulkan-based video output path, and is provided as a Vulkan-based video filter in the FFmpeg project.

API Overview

The public API of libplacebo is currently split up into the following components, the header files (and documentation) for which are available inside the src/include/libplacebo directory. The API is available in different "tiers", representing levels of abstraction inside libplacebo. The APIs in higher tiers depend on those in lower tiers. Which tier is used by a user depends on how much power/control they want over the actual rendering. The low-level tiers are more suitable for big projects that need strong control over the entire rendering pipeline; whereas the high-level tiers are more suitable for smaller or simpler projects that want libplacebo to take care of everything.

Tier 0 (logging, raw math primitives)

• cache.h: Caching subsystem. Used to cache large or computationally heavy binary blobs, such as compiled shaders, 3DLUTs, and so on.
• colorspace.h: A collection of enums and structs for describing color spaces, as well as a collection of helper functions for computing various color space transformation matrices.
• common.h: A collection of miscellaneous utility types and macros that are shared among multiple subsystems. Usually does not need to be included directly.
• log.h: Logging subsystem.
• config.h: Macros defining information about the way libplacebo was built, including the version strings and compiled-in features/dependencies. Usually does not need to be included directly. May be useful for feature tests.
• dither.h: Some helper functions for generating various noise and dithering matrices. Might be useful for somebody else.
• filters.h: A collection of reusable reconstruction filter kernels, which can be used for scaling. The generated weights arrays are semi-tailored to the needs of libplacebo, but may be useful to somebody else regardless. Also contains the structs needed to define a filter kernel for the purposes of libplacebo's upscaling routines.
• tone_mapping.h: A collection of tone mapping functions, used for conversions between HDR and SDR content.
• gamut_mapping.h: A collection of gamut mapping functions, used for conversions between wide gamut and standard gamut content, as well as for gamut recompression after tone-mapping.

The API functions in this tier are either used throughout the program (context, common etc.) or are low-level implementations of filter kernels, color space conversion logic etc.; which are entirely independent of GLSL and even the GPU in general.

Tier 1 (rendering abstraction)

• gpu.h: Exports the GPU abstraction API used by libplacebo internally.
• swapchain.h: Exports an API for wrapping platform-specific swapchains and other display APIs. This is the API used to actually queue up rendered frames for presentation (e.g. to a window or display device).
• vulkan.h: GPU API implementation based on Vulkan.
• opengl.h: GPU API implementation based on OpenGL.
• d3d11.h: GPU API implementation based on Direct3D 11.
• dummy.h: Dummy GPI API (interfaces with CPU only, no shader support)

As part of the public API, libplacebo exports a middle-level abstraction for dealing with GPU objects and state. Basically, this is the API libplacebo uses internally to wrap OpenGL, Vulkan, Direct3D etc. into a single unifying API subset that abstracts away state, messy details, synchronization etc. into a fairly high-level API suitable for libplacebo's image processing tasks.

It's made public both because it constitutes part of the public API of various image processing functions, but also in the hopes that it will be useful for other developers of GPU-accelerated image processing software.

Tier 2 (GLSL generating primitives)

• shaders.h: The low-level interface to shader generation. This can be used to generate GLSL stubs suitable for inclusion in other programs, as part of larger shaders. For example, a program might use this interface to generate a specialized tone-mapping function for performing color space conversions, then call that from their own fragment shader code. This abstraction has an optional dependency on gpu.h, but can also be used independently from it.

In addition to this low-level interface, there are several available shader routines which libplacebo exports:

• shaders/colorspace.h: Shader routines for decoding and transforming colors, tone mapping, and so forth.
• shaders/custom.h: Allows directly ingesting custom GLSL logic into the pl_shader abstraction, either as bare GLSL or in mpv .hook format.
• shaders/deinterlacing.h: GPU deinterlacing shader based on yadif.
• shaders/dithering.h: Shader routine for various GPU dithering methods.
• shaders/film_grain.h: Film grain synthesis shaders for AV1 and H.274.
• shaders/icc.h: Shader for ICC profile based color management.
• shaders/lut.h: Code for applying arbitrary 1D/3D LUTs.
• shaders/sampling.h: Shader routines for various algorithms that sample from images, such as debanding and scaling.

Tier 3 (shader dispatch)

• dispatch.h: A higher-level interface to the pl_shader system, based on gpu.h. This dispatch mechanism generates+executes complete GLSL shaders, subject to the constraints and limitations of the underlying GPU.

This shader dispatch mechanism is designed to be combined with the shader processing routines exported by shaders/*.h, but takes care of the low-level translation of the resulting pl_shader_res objects into legal GLSL. It also takes care of resource binding, shader input placement, as well as shader caching and resource pooling; and makes sure all generated shaders have unique identifiers (so they can be freely merged together).

Tier 4 (high level renderer)

• options.h: A high-level options framework which wraps all of the options comprising pl_render_params into a memory-managed, serializable struct that can also be treated as a key/value dictionary. Also includes an options parser to load options provided by the API user in string format.
• renderer.h: A high-level renderer which combines the shader primitives and dispatch mechanism into a fully-fledged rendering pipeline that takes raw texture data and transforms it into the desired output image.
• utils/frame_queue.h: A high-level frame queuing abstraction. This API can be used to interface with a decoder (or other source of frames), and takes care of translating timestamped frames into a virtual stream of presentation events suitable for use with renderer.h, including any extra context required for frame interpolation (pl_frame_mix).
• utils/upload.h: A high-level helper for uploading generic data in some user-described format to a plane texture suitable for use with renderer.h. These helpers essentially take care of picking/mapping a good image format supported by the GPU. (Note: Eventually, this function will also support on-CPU conversions to a different format where necessary, but for now, it will just fail)
• utils/dav1d.h: High level helper for translating between Dav1dPicture and libplacebo's pl_frame. (Single header library)
• utils/libav.h: High-level helpers for interoperation between libplacebo and FFmpeg's libav* abstractions. (Single header library)

This is the "primary" interface to libplacebo, and the one most users will be interested in. It takes care of internal details such as degrading to simpler algorithms depending on the hardware's capabilities, combining the correct sequence of colorspace transformations and shader passes in order to get the best overall image quality, and so forth.

Authors

libplacebo was founded and primarily developed by Niklas Haas (@haasn), but it would not be possible without the contributions of others, especially support for windows.

License

libplacebo is currently available under the terms of the LGPLv2.1 (or later) license. However, it's possible to release it under a more permissive license (e.g. BSD2) if a use case emerges.

Please open an issue if you have a use case for a BSD2-licensed libplacebo.

Installing

Obtaining

When cloning libplacebo, make sure to provide the `--recursive``` flag:

$ git clone --recursive https://code.videolan.org/videolan/libplacebo

Alternatively (on an existing clone):

$ git submodule update --init

Doing either of these pulls in a handful of bundled 3rdparty dependencies. Alternatively, they can be provided via the system.

Building from source

libplacebo is built using the meson build system. You can build the project using the following steps:

$ DIR=./build
$ meson $DIR
$ ninja -C$DIR

To rebuild the project on changes, re-run ninja -Cbuild. If you wish to install the build products to the configured prefix (typically /usr/local/), you can run ninja -Cbuild install. Note that this is normally ill-advised except for developers who know what they're doing. Regular users should rely on distro packages.

Dependencies

In principle, libplacebo has no mandatory dependencies - only optional ones. However, to get a useful version of libplacebo. you most likely want to build with support for either opengl, vulkan or d3d11. libplacebo built without these can still be used (e.g. to generate GLSL shaders such as the ones used in VLC), but the usefulness is severely impacted since most components will be missing, impaired or otherwise not functional.

A full list of optional dependencies each feature requires:

• glslang: glslang + its related libraries (e.g. libSPIRV.so)
• lcms: liblcms2
• libdovi: libdovi
• opengl: glad2 (*)
• shaderc: libshaderc
• vulkan: libvulkan, python3-jinja2 (*)
• xxhash: libxxhash

(*) This dependency is bundled automatically when doing a recursive clone.

Vulkan support

Because the vulkan backend requires on code generation at compile time, python3-Jinja2 is a hard dependency of the build system. In addition to this, the path to the Vulkan registry (vk.xml) must be locatable, ideally by explicitly providing it via the -Dvulkan-registry=/path/to/vk.xml option, unless it can be found in one of the built-in hard-coded locations.

Configuring

To get a list of configuration options supported by libplacebo, after running meson $DIR you can run meson configure $DIR, e.g.:

$ meson $DIR
$ meson configure $DIR

If you want to disable a component, for example Vulkan support, you can explicitly set it to false, i.e.:

$ meson configure $DIR -Dvulkan=disabled -Dshaderc=disabled
$ ninja -C$DIR

Testing

To enable building and executing the tests, you need to build with tests enabled, i.e.:

$ meson configure $DIR -Dtests=true
$ ninja -C$DIR test

Benchmarking

A naive benchmark suite is provided as an extra test case, disabled by default (due to the high execution time required). To enable it, use the bench option:

$ meson configure $DIR -Dbench=true
$ meson test -C$DIR benchmark --verbose

Using

For a full documentation of the API, refer to the above API Overview as well as the public header files. You can find additional examples of how to use the various components in the demo programs as well as in the unit tests.

libplacebo's Issues

Allow toggling on "frame perfect" mode for the tone mapping code

The current tone mapping / peak detection algorithm has its results delayed by a frame for performance/simplicity reasons. Often times, it's undesirable to have results delayed like this - e.g. when transcoding offline, or when used on a still image scenario. We should have an option to allow turning on "frame perfect" mode at the cost of performance.

Possible ways to achieve this:

1. Duplicate the current shader up to that point and run it in a second pass to measure the peak (more compute time, less texture bandwidth/memory required)
2. Finalize the current shader and render it out to a cache texture while measuring the peak, then dispatch a lightweight second pass that just samples from this cache (no redundant computations, more texture sampling/bandwidth/memory required)

In either case, the intermediate step would require dispatching some shader - so the use of a pl_dispatch becomes unavoidable. As such, the tone mapping shader would have to be split up into two passes, each of which gets called separately by the parent (e.g. pl_renderer).

In order to determine which strategy of the above two is best, we could support both and apply some heuristics in pl_renderer to guess whether or not the shader would be cheaper to re-execute or not, either based on the settings or based on some property of the pl_shader itself (e.g. how many texture samples have been recorded into it)

Or we could just agree on one of the two strategies and use that always.

Implement RAVU / FSRCNN / NNEDI3 / SuperXBR / whatever

Too many memes, too little time. Most of these are open source and have more-or-less compatible licenses, so we could potentially attempt implementing them natively. cf. https://github.com/bjin/mpv-prescalers

Might be scrapped in favor of letting users provide them manually, see #19. An open question would be figuring out how we want to handle the trained weights - one idea would be to keep them in a separate repository as a git remote and make it an optional build-time dependency.

Track cross-queue vulkan buffer dependencies

We do this for images, but not for buffers - the assumption so far was that buffers wouldn't need cross-queue dependencies. However, this assumption may have changed with the introduction of texture format emulation.

We might get a performance boost from leveraging the DMA engine to do the TEX_TRANSFER -> TEXEL_UNIFORM buffer copy, but this requires the texel buffer to undergo TRANSFER->COMPUTE transition, which our current buf_barrier infrastructure is incapable of dealing with.

We could probably just copy/paste the vk_signal abstraction here, (i.e. use it for buffers in addition to images), although I'm worried about incurring unnecessary events for buffers as well.

Merge similar planes before debanding/scaling

For performance

Port OpenGL backend

An OpenGL RA backend already exists for mpv's version of RA. But porting it is non-trivial:

1. Many RA API changes were made, most of which exist to make state more explicit. As such, more about e.g. OpenGL texture formats needs to be double-checked. This requires a lot of difficult cross-referencing between different OpenGL specs and versions.

2. A new public API (similar to libplacebo/vulkan.h) needs to be designed and implemented, in order to allow users to actually use it.

swapchain frames are not cleared

When I use a swapchain I get the frames with the old Image on it. That is unfortunate if I render on this frame only a smaller Image than before e.g. render the frame into a small rectangle to show it in the OSD. Is there a way to get cleared frames from the swapchain ?
I know that I can clear the received frame but that is an additional renderstep.

Implement support for OSD/overlays

Many projects need to overlay additional textures (subtitles, on-screen controllers, etc.) on top of the video being rendered. We need to design an API for this, and of course implement it as well.

Most likely, the API will look something like the user providing a list of ra_texs (or perhaps pl_planes?) plus a pl_rect2d for each. In addition, the meaning of the pl_rect2d would have to be decided, probably by using an enum. For example, we could support giving the coordinate as any one of:

• relative to video reference rect (0, 0, image.width, image.height) in absolute coordinates
• relative to the src_rect in relative coordinates (0.0, 0.0, 1.0, 1.0)
• relative to the dst_rect in relative coordinates
• relative to the target in absolute coordinates (0, 0, fbo.width, fbo.height)
• (possibly?) relative to the source or target in relative coordinates

This should provide projects with the greatest deal of flexibility while keeping the conversion boilerplate as inside libplacebo as possible.

In addition, we will have to figure out how to handle OSD mixing with respect to interpolation, as well as OSD plane colorimetry. We might need to support multiple locations where users can set OSDs, either at the pl_image level or at the pl_target level. Perhaps the aforementioned enum could simply distinguish between absolute | relative_to_size | relative_to_rect, with one OSD struct being attached to the pl_image and pl_target respectively.

Scale texture data on the first sample

10-in-16 is handled very badly at the moment when combined with debanding, due to the lack of first-sample range corrections. In addition, we potentially lose some precision.

This is best done in two steps:

1. Add a field scale to pl_sample_src, which will cause the samplers to multiply the output by this value
2. Make the other sample-like functions (e.g. debanding) also take a pl_sample_src

As a bonus effect of this, we gain a few potential benefits:

1. Faster debanding when cropping
2. Free bilinear sampling when debanding
3. Debanding even without FBOs

Add external image interop API

If a user has their own VkImage created from the same VkDevice (e.g. via hwdec interop), there's currently no public way to get that wrapped into a ra_tex for consumption by libplacebo. This obviously needs to be remedied.

The appropriate function more or less already exists internally (ra_vk_wrap_swapchain_image -> vk_init_image). A similar function needs to be created for wrapping generic VkImages, perhaps even replacing the one specialized for swapchains, made public, and documented.

Some thought and research needs to be done in order to figure out the best API for this.

Implement inverse BT.2020-C and XYZ

The decoding functions for these exist, but the corresponding inverse ("encoding") function has the cases unimplemented.

This should be a relatively straightforward change. The math just needs to be reversed. Some care needs to be taken in order to apply the bit shift and alpha handling in the correct order. The bottom line is that these functions should round trip, which is easily testable.

Missing semaphore on buffer queue changes

For use cases where we use the same buffer from different queues, we absolutely need to use a semaphore to synchronize the buffer properly. We currently don't. This is a bug.

An example of where this causes an issue is when using a shader storage buffer to dispatch the peak detection shader on multiple images at the same time - each compute shader will end up on a different VkQueue, but they all access the same storage buffer. Since the user is using multiple images, the image semaphores are not sufficient to cover the buffer as well.

Some questions

After implementing the library in my project I still have some minor questions on using it.

1. Your default lightscene for BT709 is PL_COLOR_LIGHT_DISPLAY. Isn't PL_COLOR_LIGHT_SCENE_709_1886 the correct one ?

2. When using pl_render_image does it presacle the UV plane before converting the colors to RGB ?
   If not what scaler could I use to do this beforehand ?

3. Do you plan to provide more shaders e.g. for sharpening, denoising, etc ?

4. Have you read about the Darbee Picture Optimization (http://www.darbeevision.com/technology-briefs/). Would it be possible to write a shader for this ?

Provide function to copy nvdec device memory to vulkan texture

I would like to have the possibility to copy device memory from nvdec to a vulkan texture as Device-to-Device copy. At the moment I need to copy it via cuda_memcpy2d to host memory and then upload it to the vulkan texture. This is not very fast. In mpv this is already done and it would be great if libplacebo could provide this also.

Support palette formats

Uploading a palette and sampling from it is absolutely trivial for us. There's basically no reason not to support them natively except laziness.

Texel-buffer based texture upload can fail due to size limits

Solution: Use multiple texel buffers and multiple dispatches somehow. Or perhaps a texel buffer array and a single dispatch.

Either way, the immediate work-around would be to disable format emulation if texel buffers are not large enough to cover the largest possible 2D/3D texture.

bstr.c needs <limits.h> to build with Android gnustl

I get following error when trying to compile VLC 3.0.x using stl "gnustl" with Android NDK r14b with ABI 9:

/media/data1/libvlc_trunk/toolchains/arm/bin/clang -march=armv7-a -mfpu=vfpv3-d16 -mcpu=cortex-a8 -mthumb -mfloat-abi=softfp -MMD -MP -fpic -ffunction-sections -funwind-tables -fstack-protector-strong -Wno-invalid-command-line-argument -Wno-unused-command-line-argument -no-canonical-prefixes -fno-integrated-as -DNDEBUG -I/media/data1/libvlc_trunk/vlc/contrib/arm-linux-androideabi/include -g -O2 -fPIC -D_ISOC99_SOURCE -D_GNU_SOURCE -Isrc -Isrc/osdep -Isrc/include -fvisibility=hidden -Wall -Wundef -Wmissing-prototypes -Wshadow -Wparentheses -Wpointer-arith -Wno-pointer-sign -march=armv7-a -mfpu=vfpv3-d16 -mcpu=cortex-a8 -mthumb -mfloat-abi=softfp -MMD -MP -fpic -ffunction-sections -funwind-tables -fstack-protector-strong -Wno-invalid-command-line-argument -Wno-unused-command-line-argument -no-canonical-prefixes -fno-integrated-as -DNDEBUG -I/media/data1/libvlc_trunk/vlc/contrib/arm-linux-androideabi/include -fPIC -c -o src/bstr/bstr.o src/bstr/bstr.c
src/bstr/bstr.c:277:21: error: use of undeclared identifier 'SIZE_MAX'
if (size >= SIZE_MAX / 2 || append_min >= SIZE_MAX / 2)
^
src/bstr/bstr.c:277:51: error: use of undeclared identifier 'SIZE_MAX'
if (size >= SIZE_MAX / 2 || append_min >= SIZE_MAX / 2)
^
2 errors generated.
make[1]: *** [src/bstr/bstr.o] Error 1
make[1]: Leaving directory `/media/data1/libvlc_trunk/vlc/contrib/contrib-android-arm-linux-androideabi/libplacebo'
make: *** [.libplacebo] Error 2

Adding '#include <limits.h>' does fix the error.

Is there any other solution?

Get rid of libshaderc

libshaderc is licensed under Apache v2.0, which is incompatible in such a way that it forces VLC to be GPLv3 on some platforms.

Getting rid of a libshaderc dependency in favor of our own C++ wrapper stub would be important.

Avoid dependent fetches using nearest sampling

We can potentially avoid having to use dependent texture fetches by abusing the GPU's built-in nearest neighbour sampling to get the base texel coordinate for us, and then combining this with textureOffset (or similar techniques) to read in the texel coordinate directly.

Avoiding dependent texture fetches might significantly improve the texture fill throughput as well as the pipelining of texture loads within the shader.

crash in pl_vulkan_destroy

With the latest sources I get a crash when trying to destroy vulkan at the end of my program. Here a Backtrace:
#0 0x00007fabd653fcbd in () at /usr/lib64/libnvidia-glcore.so.415.18
#1 0x00007fabd653a3e7 in () at /usr/lib64/libnvidia-glcore.so.415.18
#2 0x00007fabd653ccd1 in () at /usr/lib64/libnvidia-glcore.so.415.18
#3 0x00007fabf20404f8 in slab_free (vk=0x25b8780, slab=0x7fab8011d4b0)
at ../src/vulkan/malloc.c:111
PRETTY_FUNCTION = "slab_free"
#4 0x00007fabf204115c in heap_uninit (vk=0x25b8780, heap=0x7fab80e6a2f0)
at ../src/vulkan/malloc.c:295
i = 0
#5 0x00007fabf204136f in vk_malloc_destroy (ma_ptr=0x2872a48) at ../src/vulkan/malloc.c:331
i = 0
ma = 0x2903e80
#6 0x00007fabf20381ee in vk_destroy_gpu (gpu=0x2872930) at ../src/vulkan/gpu.c:129
p = 0x2872a40
vk = 0x25b8780
#7 0x00007fabf20187c1 in pl_gpu_destroy (gpu=0x2872930) at ../src/gpu.c:33
#8 0x00007fabf2035ecd in pl_vulkan_destroy (pl_vk=0x25787b8) at ../src/vulkan/context.c:246
vk = 0xe924390
PRETTY_FUNCTION = "pl_vulkan_destroy"
#9 0x00007fabf5cd2521 in VideoExit () at video.c:6410
#10 0x00007fabf5ccb416 in StopVideo () at softhddev.c:2036

Add shader hooking mechanism

Much like mpv, we need some sort of “hooking” mechanism to allow users to insert their own processing (shaders etc.) into the rendering pipeline. This is needed in particular to retain compatibility with the mpv user shader system, but is surely also interesting for others.

Some design goals/notes:

1. Instead of bothering with difficult text parsing like mpv, just communicate everything as C structs and raw textures
2. We could either use a callback-oriented architecture (user provides a function which gets called with some useful arguments, user can do what they want) or a static struct/metadata architecture. The former would most likely make the most sense, in order to allow users to leverage our whole shader system - in which case we need to figure out what state to expose and how to do so safely
3. Obviously, users will need some ability to wrap custom shaders into our pl_shader abstraction. Most likely, we will allow users to provide their own verbatim functions which then get called (as appropriate for the signature type) by some function like pl_shader_custom_glsl
4. Maybe we will need to open up sh_lut, sh_bind etc. somehow to users? Possible, but requires tying off some loose ends. More likely, we'll allow users to just straight up name and specify their own descriptors and variables. The chance of a collision is basically nonexistant with our naming scheme.
5. (Optional) We could possibly reorganize the control flow of the renderer into CPS style or something and actually allow users to decide to cut off the rendering at that point rather than just inserting hooks. Basically, say a user only wants the LINEAR stage, but doesn't care about the rest. But I think this is rather unlikely, since complexity of the renderer logic is a heavy cost to pay for an obscure feature that can be implemented by users with the libplacebo shader system anyway.

Implement 3DLUT support

VLC wants this. The main question is: Which 3DLUT formats do we support? My considerations:

1. I don't want to do string->float parsing in libplacebo, so that rules out the "plaintext" formats
2. I would prefer a format that has as much metadata as possible describing the input and output space of the 3DLUT, otherwise the user would have to specify this
3. Preferably, the API in libplacebo itself should just take a pointer to the LUT + metadata in a struct, but we would provide a utils/ file to parse this information from a file

I've seen some samples of 3DLUT formats but none of them really matched my requirements. In particular, what I ideally want is something where the 3DLUT data itself can just be a raw pointer into the file itself. The closest so far is madVR's 3DLT format, but it has metadata as plaintext/string comments, which goes against my "no float parsing" rule.

We could NIH our own format + provide a dedicated command line tool to convert from format X to ours though (e.g. using setlocale + scanf).

Try using vulkan queue family ownership transfers?

Right now, the vulkan code assumes all resources are shared across all queue families - even resources that will only ever be used from a single queue family. This is because it's difficult for us to know in advance when to submit an optimal queue release operation, and also to predict whether or not we'll be using an image from multiple queues or not.

Ideally, we would want to

1. Submit and use queue family ownership operations in cases where resources infrequently transition between queue families
2. Identify cases where concurrent sharing is excessive (e.g. non-storable, non-transferrable image) and use exclusive sharing instead
3. Benchmark the above changes and determine when concurrent sharing is better than frequent queue family transfers

Redundant pow() in 2020-CL handling

Here, RGB is converted to R'G'B':

https://github.com/haasn/libplacebo/blob/master/src/shaders/colorspace.c#L87

However, the function already has Y'B'R' from an earlier step, so only the G' needs to be computed. I am not sure this will be faster in practice, so it needs to be benchmarked.

Add Metal backend

Add a RA implementation using the Metal graphics API (requested by VideoLAN)

This would have to be written from-scratch, and might involve RA API changes.

Add support for spherical video

mpv-player/mpv#4772 has a bunch of code for this already, could easily implement something like that in libplacebo (and maybe also hook it up to pl_renderer)

../src/renderer.c:571]: (error) Dead pointer usage

../src/renderer.c:571]: (error) Dead pointer usage. Pointer 'src' is dead if it has been assigned '&fixed' at line 557.

Unconditional use of VK_COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT

The VK_COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT is not available in some older Vulkan versions, as per discussion on IRC, it should be #ifdefed.

../src/vulkan/swapchain.c:80:10: error: use of undeclared identifier 'VK_COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT'; did you mean 'VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT'?
    case VK_COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT:
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Implement support for ICC profiles / 3DLUTs

Using LittleCMS (optionally) / user-provided 3DLUTs

mpv says "Exhausted the queued command limit…"

I've been fiddling about with mpv's vulkan backend, external upscaling shaders and motion-interpolation but then noticed that mpv produces such warning:

[vo/gpu/vulkan/libplacebo] Exhausted the queued command limit.. forcing a flush now. Consider using pl_gpu_flush after submitting a batch of work?

While searching in libplacebo sources I stumbled at this piece of code:

libplacebo/src/vulkan/common.h

Lines 45 to 47 in 1b96a0f

	// Hard-coded limit on the number of pending commands, to avoid OOM loops
	#define PL_VK_MAX_QUEUED_CMDS 64
	#define PL_VK_MAX_PENDING_CMDS 64

I'm using RX580 with amdgpu sched_hw_submission=1024 sched_jobs=2048 options and I'm pretty sure it has to handle much more than 64, so I patched it with 2048 for both and recompiled together with mpv. Warning seems to be gone and everything seems to be fine.

Error message spam with minimized video

I am running into this issue with mpv using the vulkan setting for gpu-api. It was suggested to me that I should file an issue with libplacebo due to it likely being issue with the library logging excessively.

The issue is that whenever video is minimized while playing, the console is continuously spammed with the following error messages:
[vo/gpu/vulkan/libplacebo] Failed resizing swapchain: unknown size? [vo/gpu/vulkan/libplacebo] Failed (re)creating swapchain!

Playback does not seem to be adversely affected as far as I can tell and the messages stop once the video is un-minimized, but it is annoying.

This is using the latest shinchiro Windows build of mpv, with an rx570 using latest drivers on Windows 10.
Here is the mpv log file if it is useful:
https://pastebin.com/TyP5hGKA

Switching filterchain corrupts first frame

When I change the size of the Image in my filterchain, then the first frame is distorted.
I use pl_render_image and only change the size of the input image.

I have attached a Trace of the problem with some comments from me. The Trace starts with a picture of the szie 1280x720 and then I switch to a new channel with size 720x576. There the first frame is distorted. The complete Source can be found at: https://github.com/jojo61/vdr-plugin-softhdcuvid
There look at the file video.c and search for PLACEBO. Everything is in ifdef PLACEBO capsuled.
I have disabled my prints but they are still in the souce.
PS: I use your branch master from today

trace.log.gz

Add support for push descriptors

Vulkan support using push descriptors to bypass the need for descriptor sets. We can and should use them where available for efficiency/performance.

I already found some code in my git stash for this. I forgot why I didn't commit it. Maybe it's incomplete, or maybe it was working but I didn't find any advantage so I decided to forgo the complexity for the time being.

Whatever the case, it should be investigated, and if possible, cleaned up / merged.

commit cc44485d4f599998efc01f421ea8a4c7e41b9c6b
Merge: ccba91d a5b81c2
Author: Niklas Haas <[e-mail]>
Date:   Tue Oct 17 12:30:01 2017 +0200

    On master: push_descriptors

diff --cc src/vulkan/ra_vk.c
index 4be6472,4be6472..0a5f2b9
--- a/src/vulkan/ra_vk.c
+++ b/src/vulkan/ra_vk.c
@@@ -35,6 -35,6 +35,9 @@@ struct ra_vk 
      struct vk_malloc *alloc;
      struct spirv_compiler *spirv;
  
++    // Some additional cached device limits
++    uint32_t max_push_descriptors;
++
      // The "currently recording" command. This will be queued and replaced by
      // a new command every time we need to "switch" between queue families.
      struct vk_cmd *cmd;
@@@ -212,6 -212,6 +215,18 @@@ const struct ra *ra_create_vk(struct vk
          .align_tex_xfer_offset = vk->limits.optimalBufferCopyOffsetAlignment,
      };
  
++    VkPhysicalDevicePushDescriptorPropertiesKHR pushd = {
++        .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PUSH_DESCRIPTOR_PROPERTIES_KHR,
++    };
++
++    VkPhysicalDeviceProperties2KHR props = {
++        .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2_KHR,
++        .pNext = &pushd,
++    };
++
++    vkGetPhysicalDeviceProperties2KHR(vk->physd, &props);
++    p->max_push_descriptors = pushd.maxPushDescriptors;
++
      if (vk->pool_compute) {
          ra->caps |= RA_CAP_COMPUTE;
          ra->limits.max_shmem_size = vk->limits.maxComputeSharedMemorySize;
@@@ -1087,6 -1087,6 +1102,7 @@@ struct ra_pass_vk 
      VkAccessFlags initialAccess;
      VkAccessFlags finalAccess;
      // Descriptor set (bindings)
++    bool use_pushd;
      VkDescriptorSetLayout dsLayout;
      VkDescriptorPool dsPool;
      // To keep track of which descriptor sets are and aren't available, we
@@@ -1255,53 -1255,53 +1271,61 @@@ static const struct ra_pass *vk_pass_cr
          };
      }
  
--    VkDescriptorPoolSize *dsPoolSizes = NULL;
--    int poolSizeCount = 0;
--
--    for (enum ra_desc_type t = 0; t < RA_DESC_TYPE_COUNT; t++) {
--        if (dsSize[t] > 0) {
--            VkDescriptorPoolSize dssize = {
--                .type = dsType[t],
--                .descriptorCount = dsSize[t] * NUM_DS,
--            };
--
--            TARRAY_APPEND(tmp, dsPoolSizes, poolSizeCount, dssize);
--        }
--    }
--
--    if (poolSizeCount) {
--        VkDescriptorPoolCreateInfo pinfo = {
--            .sType = VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_CREATE_INFO,
--            .maxSets = NUM_DS,
--            .pPoolSizes = dsPoolSizes,
--            .poolSizeCount = poolSizeCount,
--        };
--
--        VK(vkCreateDescriptorPool(vk->dev, &pinfo, VK_ALLOC, &pass_vk->dsPool));
--    }
--
      VkDescriptorSetLayoutCreateInfo dinfo = {
          .sType = VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO,
          .pBindings = bindings,
          .bindingCount = num_desc,
      };
  
++    if (num_desc <= p->max_push_descriptors) {
++        dinfo.flags |= VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR;
++        pass_vk->use_pushd = true;
++    }
++
      VK(vkCreateDescriptorSetLayout(vk->dev, &dinfo, VK_ALLOC,
                                     &pass_vk->dsLayout));
  
--    VkDescriptorSetLayout layouts[NUM_DS];
--    for (int i = 0; i < NUM_DS; i++)
--        layouts[i] = pass_vk->dsLayout;
  
--    if (pass_vk->dsPool) {
--        VkDescriptorSetAllocateInfo ainfo = {
--            .sType = VK_STRUCTURE_TYPE_DESCRIPTOR_SET_ALLOCATE_INFO,
--            .descriptorPool = pass_vk->dsPool,
--            .descriptorSetCount = NUM_DS,
--            .pSetLayouts = layouts,
--        };
++    if (!pass_vk->use_pushd) {
++        VkDescriptorPoolSize *dsPoolSizes = NULL;
++        int poolSizeCount = 0;
++
++        for (enum ra_desc_type t = 0; t < RA_DESC_TYPE_COUNT; t++) {
++            if (dsSize[t] > 0) {
++                VkDescriptorPoolSize dssize = {
++                    .type = dsType[t],
++                    .descriptorCount = dsSize[t] * NUM_DS,
++                };
  
--        VK(vkAllocateDescriptorSets(vk->dev, &ainfo, pass_vk->dss));
++                TARRAY_APPEND(tmp, dsPoolSizes, poolSizeCount, dssize);
++            }
++        }
++
++        if (poolSizeCount) {
++            VkDescriptorPoolCreateInfo pinfo = {
++                .sType = VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_CREATE_INFO,
++                .maxSets = NUM_DS,
++                .pPoolSizes = dsPoolSizes,
++                .poolSizeCount = poolSizeCount,
++            };
++
++            VK(vkCreateDescriptorPool(vk->dev, &pinfo, VK_ALLOC, &pass_vk->dsPool));
++        }
++
++        VkDescriptorSetLayout layouts[NUM_DS];
++        for (int i = 0; i < NUM_DS; i++)
++            layouts[i] = pass_vk->dsLayout;
++
++        if (pass_vk->dsPool) {
++            VkDescriptorSetAllocateInfo ainfo = {
++                .sType = VK_STRUCTURE_TYPE_DESCRIPTOR_SET_ALLOCATE_INFO,
++                .descriptorPool = pass_vk->dsPool,
++                .descriptorSetCount = NUM_DS,
++                .pSetLayouts = layouts,
++            };
++
++            VK(vkAllocateDescriptorSets(vk->dev, &ainfo, pass_vk->dss));
++        }
      }
  
      VkPipelineLayoutCreateInfo linfo = {
@@@ -1612,7 -1612,7 +1636,6 @@@ static void vk_update_descriptor(const 
  {
      struct ra_pass_vk *pass_vk = pass->priv;
      struct ra_desc *desc = &pass->params.descriptors[idx];
--    assert(ds);
  
      VkWriteDescriptorSet *wds = &pass_vk->dswrite[idx];
      *wds = (VkWriteDescriptorSet) {
@@@ -1723,13 -1723,13 +1746,6 @@@ static void vk_pass_run(const struct r
          [RA_PASS_COMPUTE] = COMPUTE,
      };
  
--    // Wait for a free descriptor set
--    while (!pass_vk->dmask) {
--        PL_TRACE(ra, "No free descriptor sets! ...blocking (slow path)");
--        vk_submit(ra);
--        vk_poll_commands(vk, 1000000); // 1ms
--    }
--
      struct vk_cmd *cmd = vk_require_cmd(ra, types[pass->params.type]);
      if (!cmd)
          goto error;
@@@ -1742,23 -1742,23 +1758,41 @@@
      vkCmdBindPipeline(cmd->buf, bindPoint[pass->params.type], pass_vk->pipe);
  
      VkDescriptorSet ds = NULL;
--    for (int i = 0; i < PL_ARRAY_SIZE(pass_vk->dss); i++) {
--        uint16_t dsbit = 1u << i;
--        if (pass_vk->dmask & dsbit) {
--            ds = pass_vk->dss[i];
--            pass_vk->dmask &= ~dsbit; // unset
--            vk_cmd_callback(cmd, (vk_cb) set_ds, pass_vk,
--                            (void *)(uintptr_t) dsbit);
--            break;
++    if (!pass_vk->use_pushd) {
++        // Wait for a free descriptor set
++        while (!pass_vk->dmask) {
++            PL_TRACE(ra, "No free descriptor sets! ...blocking (slow path)");
++            vk_submit(ra);
++            vk_poll_commands(vk, 1000000); // 1ms
          }
++
++        for (int i = 0; i < PL_ARRAY_SIZE(pass_vk->dss); i++) {
++            uint16_t dsbit = 1u << i;
++            if (pass_vk->dmask & dsbit) {
++                ds = pass_vk->dss[i];
++                pass_vk->dmask &= ~dsbit; // unset
++                vk_cmd_callback(cmd, (vk_cb) set_ds, pass_vk,
++                                (void *)(uintptr_t) dsbit);
++                break;
++            }
++        }
++
++        assert(ds);
      }
  
      for (int i = 0; i < pass->params.num_descriptors; i++)
          vk_update_descriptor(ra, cmd, pass, params->desc_bindings[i], ds, i);
  
      if (pass->params.num_descriptors > 0) {
--        vkUpdateDescriptorSets(vk->dev, pass->params.num_descriptors,
--                               pass_vk->dswrite, 0, NULL);
++        if (pass_vk->use_pushd) {
++            vkCmdPushDescriptorSetKHR(cmd->buf, bindPoint[pass->params.type],
++                                      pass_vk->pipeLayout, 0,
++                                      pass->params.num_descriptors,
++                                      pass_vk->dswrite);
++        } else {
++            vkUpdateDescriptorSets(vk->dev, pass->params.num_descriptors,
++                                   pass_vk->dswrite, 0, NULL);
++        }
      }
  
      if (ds) {

Implement support for frame caching

When re-rendering the same frame many times, we should cache the pre-processed result (before the output to screen) and re-blit it for performance.

In addition, we should also re-blit instead of aborting when trying to use a compute shader in an environment where the swapchain is not storable. This would likely be handled by the same code.

Add more test cases

We desperately need more tests for the renderer. The shaders, dispatch and stuff are all fairly covered, but the renderer is basically completely untouched in the test framework.

We need lots of automated tests for stuff like src_rect/dst_rect permutations, different combinations of render_params flags, chroma subsampling, plane permutation, plane shifts etc.

1.21.0: build fails

+ /usr/bin/meson --buildtype=plain --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/libexec --bindir=/usr/bin --sbindir=/usr/sbin --includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man --infodir=/usr/share/info --localedir=/usr/share/locale --sysconfdir=/etc --localstatedir=/var --sharedstatedir=/var/lib --wrap-mode=nodownload --auto-features=enabled . x86_64-redhat-linux-gnu
The Meson build system
Version: 0.52.1
Source dir: /home/tkloczko/rpmbuild/BUILD/libplacebo-1.21.0
Build dir: /home/tkloczko/rpmbuild/BUILD/libplacebo-1.21.0/x86_64-redhat-linux-gnu
Build type: native build
Project name: libplacebo
Project version: 1.21.0
Appending CFLAGS from environment: '-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none'
Appending LDFLAGS from environment: ['-Wl,-z,relro', '-Wl,--as-needed', '-Wl,-z,now', '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld', '-flto=auto', '-flto-partition=none', '-fuse-linker-plugin']
Appending CXXFLAGS from environment: '-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none'
Appending LDFLAGS from environment: ['-Wl,-z,relro', '-Wl,--as-needed', '-Wl,-z,now', '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld', '-flto=auto', '-flto-partition=none', '-fuse-linker-plugin']
Appending CFLAGS from environment: '-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none'
Appending LDFLAGS from environment: ['-Wl,-z,relro', '-Wl,--as-needed', '-Wl,-z,now', '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld', '-flto=auto', '-flto-partition=none', '-fuse-linker-plugin']
C compiler for the host machine: gcc (gcc 9.2.1 "gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)")
C linker for the host machine: GNU ld.bfd 2.33.1-9
Appending CXXFLAGS from environment: '-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none'
Appending LDFLAGS from environment: ['-Wl,-z,relro', '-Wl,--as-needed', '-Wl,-z,now', '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld', '-flto=auto', '-flto-partition=none', '-fuse-linker-plugin']
C++ compiler for the host machine: g++ (gcc 9.2.1 "g++ (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)")
C++ linker for the host machine: GNU ld.bfd 2.33.1-9
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program git found: YES (/usr/bin/git)
Compiler for C supports arguments -Wincompatible-pointer-types: YES 
Compiler for C supports link arguments -Wl,--exclude-libs=ALL: YES 
WARNING: Consider using the builtin warning_level option instead of adding warning flags by hand.
WARNING: Consider using the builtin warning_level option instead of adding warning flags by hand.
WARNING: Consider using the builtin option for language standard version rather than adding flags by hand.
Library m found: YES

|Executing subproject xtalloc method meson 
|
|Project name: xtalloc
|Project version: undefined
|C compiler for the host machine: gcc (gcc 9.2.1 "gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)")
|C linker for the host machine: GNU ld.bfd 2.33.1-9
|Run-time dependency threads found: YES 
|Build targets in project: 1
|Subproject xtalloc finished.


|Executing subproject bstr method meson 
|
|Project name: bstr
|Project version: undefined
|C compiler for the host machine: gcc (gcc 9.2.1 "gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)")
|C linker for the host machine: GNU ld.bfd 2.33.1-9
|Build targets in project: 2
|Subproject bstr finished.

Found pkg-config: /usr/bin/pkg-config (1.6.3)
Run-time dependency vulkan found: YES 1.1.126
Library shaderc_shared found: YES
Header <shaderc/shaderc.h> has symbol "shaderc_optimization_level_performance" with dependency -lshaderc_shared: YES 
Library glslang found: YES
Library HLSL found: YES
Library OGLCompiler found: YES
Library OSDependent found: YES
Library SPIRV found: YES
Library SPVRemapper found: YES
Library SPIRV-Tools found: YES
Library SPIRV-Tools-opt found: YES
Fetching value of define "GLSLANG_PATCH_LEVEL" : 3496 
Library pthread found: YES
Run-time dependency lcms2 found: YES 2.9
Configuring config.h using configuration
Configuring config_internal.h using configuration
Dependency threads found: YES (cached)
Build targets in project: 3
Found ninja-1.9.0 at /usr/bin/ninja
+ /usr/bin/ninja -v -j1 -C x86_64-redhat-linux-gnu
ninja: Entering directory `x86_64-redhat-linux-gnu'
[1/36] gcc -Isubprojects/xtalloc/f0d261a@@xtalloc@sta -Isubprojects/xtalloc -I../subprojects/xtalloc -I../subprojects/xtalloc/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'subprojects/xtalloc/f0d261a@@xtalloc@sta/ta.c.o' -MF 'subprojects/xtalloc/f0d261a@@xtalloc@sta/ta.c.o.d' -o 'subprojects/xtalloc/f0d261a@@xtalloc@sta/ta.c.o' -c ../subprojects/xtalloc/ta.c
[2/36] gcc -Isubprojects/xtalloc/f0d261a@@xtalloc@sta -Isubprojects/xtalloc -I../subprojects/xtalloc -I../subprojects/xtalloc/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'subprojects/xtalloc/f0d261a@@xtalloc@sta/ta_utils.c.o' -MF 'subprojects/xtalloc/f0d261a@@xtalloc@sta/ta_utils.c.o.d' -o 'subprojects/xtalloc/f0d261a@@xtalloc@sta/ta_utils.c.o' -c ../subprojects/xtalloc/ta_utils.c
[3/36] gcc -Isubprojects/xtalloc/f0d261a@@xtalloc@sta -Isubprojects/xtalloc -I../subprojects/xtalloc -I../subprojects/xtalloc/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'subprojects/xtalloc/f0d261a@@xtalloc@sta/xtalloc.c.o' -MF 'subprojects/xtalloc/f0d261a@@xtalloc@sta/xtalloc.c.o.d' -o 'subprojects/xtalloc/f0d261a@@xtalloc@sta/xtalloc.c.o' -c ../subprojects/xtalloc/xtalloc.c
[4/36] rm -f subprojects/xtalloc/libxtalloc.a && /usr/bin/gcc-ar csrD subprojects/xtalloc/libxtalloc.a 'subprojects/xtalloc/f0d261a@@xtalloc@sta/ta.c.o' 'subprojects/xtalloc/f0d261a@@xtalloc@sta/ta_utils.c.o' 'subprojects/xtalloc/f0d261a@@xtalloc@sta/xtalloc.c.o'
[5/36] gcc -Isubprojects/bstr/0ab0a38@@bstr@sta -Isubprojects/bstr -I../subprojects/bstr -I../subprojects/bstr/include -I../subprojects/xtalloc/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -MD -MQ 'subprojects/bstr/0ab0a38@@bstr@sta/bstr.c.o' -MF 'subprojects/bstr/0ab0a38@@bstr@sta/bstr.c.o.d' -o 'subprojects/bstr/0ab0a38@@bstr@sta/bstr.c.o' -c ../subprojects/bstr/bstr.c
[6/36] gcc -Isubprojects/bstr/0ab0a38@@bstr@sta -Isubprojects/bstr -I../subprojects/bstr -I../subprojects/bstr/include -I../subprojects/xtalloc/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -MD -MQ 'subprojects/bstr/0ab0a38@@bstr@sta/format.c.o' -MF 'subprojects/bstr/0ab0a38@@bstr@sta/format.c.o.d' -o 'subprojects/bstr/0ab0a38@@bstr@sta/format.c.o' -c ../subprojects/bstr/format.c
[7/36] gcc -Isubprojects/bstr/0ab0a38@@bstr@sta -Isubprojects/bstr -I../subprojects/bstr -I../subprojects/bstr/include -I../subprojects/xtalloc/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -MD -MQ 'subprojects/bstr/0ab0a38@@bstr@sta/siphash.c.o' -MF 'subprojects/bstr/0ab0a38@@bstr@sta/siphash.c.o.d' -o 'subprojects/bstr/0ab0a38@@bstr@sta/siphash.c.o' -c ../subprojects/bstr/siphash.c
[8/36] rm -f subprojects/bstr/libbstr.a && /usr/bin/gcc-ar csrD subprojects/bstr/libbstr.a 'subprojects/bstr/0ab0a38@@bstr@sta/bstr.c.o' 'subprojects/bstr/0ab0a38@@bstr@sta/format.c.o' 'subprojects/bstr/0ab0a38@@bstr@sta/siphash.c.o'
[9/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/colorspace.c.o' -MF 'src/25a6634@@placebo@sha/colorspace.c.o.d' -o 'src/25a6634@@placebo@sha/colorspace.c.o' -c ../src/colorspace.c
[10/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/common.c.o' -MF 'src/25a6634@@placebo@sha/common.c.o.d' -o 'src/25a6634@@placebo@sha/common.c.o' -c ../src/common.c
[11/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/context.c.o' -MF 'src/25a6634@@placebo@sha/context.c.o.d' -o 'src/25a6634@@placebo@sha/context.c.o' -c ../src/context.c
[12/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/dither.c.o' -MF 'src/25a6634@@placebo@sha/dither.c.o.d' -o 'src/25a6634@@placebo@sha/dither.c.o' -c ../src/dither.c
[13/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/dispatch.c.o' -MF 'src/25a6634@@placebo@sha/dispatch.c.o.d' -o 'src/25a6634@@placebo@sha/dispatch.c.o' -c ../src/dispatch.c
[14/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/dummy.c.o' -MF 'src/25a6634@@placebo@sha/dummy.c.o.d' -o 'src/25a6634@@placebo@sha/dummy.c.o' -c ../src/dummy.c
[15/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/filters.c.o' -MF 'src/25a6634@@placebo@sha/filters.c.o.d' -o 'src/25a6634@@placebo@sha/filters.c.o' -c ../src/filters.c
[16/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/gpu.c.o' -MF 'src/25a6634@@placebo@sha/gpu.c.o.d' -o 'src/25a6634@@placebo@sha/gpu.c.o' -c ../src/gpu.c
[17/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/renderer.c.o' -MF 'src/25a6634@@placebo@sha/renderer.c.o.d' -o 'src/25a6634@@placebo@sha/renderer.c.o' -c ../src/renderer.c
[18/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/shaders.c.o' -MF 'src/25a6634@@placebo@sha/shaders.c.o.d' -o 'src/25a6634@@placebo@sha/shaders.c.o' -c ../src/shaders.c
[19/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/shaders_av1.c.o' -MF 'src/25a6634@@placebo@sha/shaders_av1.c.o.d' -o 'src/25a6634@@placebo@sha/shaders_av1.c.o' -c ../src/shaders/av1.c
[20/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/shaders_colorspace.c.o' -MF 'src/25a6634@@placebo@sha/shaders_colorspace.c.o.d' -o 'src/25a6634@@placebo@sha/shaders_colorspace.c.o' -c ../src/shaders/colorspace.c
[21/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/shaders_sampling.c.o' -MF 'src/25a6634@@placebo@sha/shaders_sampling.c.o.d' -o 'src/25a6634@@placebo@sha/shaders_sampling.c.o' -c ../src/shaders/sampling.c
[22/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/spirv.c.o' -MF 'src/25a6634@@placebo@sha/spirv.c.o.d' -o 'src/25a6634@@placebo@sha/spirv.c.o' -c ../src/spirv.c
[23/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/swapchain.c.o' -MF 'src/25a6634@@placebo@sha/swapchain.c.o.d' -o 'src/25a6634@@placebo@sha/swapchain.c.o' -c ../src/swapchain.c
[24/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/utils_upload.c.o' -MF 'src/25a6634@@placebo@sha/utils_upload.c.o.d' -o 'src/25a6634@@placebo@sha/utils_upload.c.o' -c ../src/utils/upload.c
[25/36] gcc -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/lcms.c.o' -MF 'src/25a6634@@placebo@sha/lcms.c.o.d' -o 'src/25a6634@@placebo@sha/lcms.c.o' -c ../src/lcms.c
[26/36] g++ -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -std=c++11 -fvisibility=hidden -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/glsl_glslang.cc.o' -MF 'src/25a6634@@placebo@sha/glsl_glslang.cc.o.d' -o 'src/25a6634@@placebo@sha/glsl_glslang.cc.o' -c ../src/glsl/glslang.cc
FAILED: src/25a6634@@placebo@sha/glsl_glslang.cc.o 
g++ -Isrc/25a6634@@placebo@sha -Isrc -I../src -I../src/./include -I../subprojects/xtalloc/include -I../subprojects/bstr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -std=c++11 -fvisibility=hidden -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fPIC -pthread -MD -MQ 'src/25a6634@@placebo@sha/glsl_glslang.cc.o' -MF 'src/25a6634@@placebo@sha/glsl_glslang.cc.o.d' -o 'src/25a6634@@placebo@sha/glsl_glslang.cc.o' -c ../src/glsl/glslang.cc
../src/glsl/glslang.cc:28:10: fatal error: SPIRV/GlslangToSpv.h: No such file or directory
   28 | #include <SPIRV/GlslangToSpv.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.
error: Bad exit status from /var/tmp/rpm-tmp.WLHhZ6 (%build)

Add support for vulkan format emulation

Some vulkan formats such as VK_FORMAT_R8G8B8_UNORM (“rgb24”) exist in theory but not in hardware. Unfortunately, this is a pretty common format for packed data to live in (basically all computer images without an alpha channel).

Being able to support uploading this somehow without requiring acrobatics from the user would be useful. There are two main methods of accomplishing this:

1. Soft-convert using a library like zimg on the CPU, before uploading. While it sounds simple, this unfortunately has a compilcation: the data might be in a VkBuffer already (e.g. host-mapped ra_buf), so we'd have to copy from one VkBuffer to another first) and it's also a drain on RAM bandwidth (which is often more of a bottleneck than VRAM bandwidth for high res content). However, this method would be preferred in a scenario where we're already forced to copy the data around (e.g. ra_tex_upload from a source pointer instead of a ra_buf).

2. Silently substitute a suitable “replacement” format, such as VK_FORMAT_R8G8B8A8_UNORM, and use this for all texture operations from the point of view of the GPU. The major complication here is figuring out how to upload data from a 3-component VkBuffer into a 4-component VkImage. One possibility here would be a compute shader that reads from the VkBuffer and directly writes to the VkImage. Unfortunately, this requires the VkBuffer be shader-visible as a storage buffer. It also has certain complications due to potential SSBO range limits. In the most likely scenario, we might need to copy from a host-mapped VkBuffer into an intermediate VkBuffer using the DMA engine, followed by a compute shader to write to the VkImage.

With Intel VA Colorconversion from BT2020 to BT709 crashes

Hi
when using an Intel VA Driver and showing a UHD HDR file, then the Intel driver crashes with:
kernel: [ 597.131638] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0

This happens when I convert from BT2020 to BT709 only. Without the conversion everything works fine. I know this is an Intel issue, but I wonder what shader commands you use that crashes the driver. It will compile without errors. Maybe libplacebo can use some other commands that will not crash the driver.

Port Direct3D 11 backend

A RA D3D11 backend already exists for mpv's RA, but porting it to libplacebo may be nontrivial. See #17 for more information.

cannot build libplacebo

Hi,
i cannot build libplacebo.

vdr01_64 tmp # git clone https://github.com/haasn/libplacebo
Klone nach 'libplacebo' ...
remote: Enumerating objects: 130, done.
remote: Counting objects: 100% (130/130), done.
remote: Compressing objects: 100% (64/64), done.
remote: Total 3895 (delta 71), reused 99 (delta 59), pack-reused 3765
Empfange Objekte: 100% (3895/3895), 1.22 MiB | 2.67 MiB/s, Fertig.
Löse Unterschiede auf: 100% (2800/2800), Fertig.
vdr01_64 tmp # cd libplacebo
vdr01_64 libplacebo # DIR=./build
vdr01_64 libplacebo # meson $DIR
The Meson build system
Version: 0.48.1
Source dir: /tmp/libplacebo
Build dir: /tmp/libplacebo/build
Build type: native build
Project name: libplacebo
Project version: undefined
Native C compiler: ccache cc (gcc 7.3.0 "gcc (Gentoo 7.3.0-r3 p1.4) 7.3.0")
Native C++ compiler: ccache c++ (gcc 7.3.0 "c++ (Gentoo 7.3.0-r3 p1.4) 7.3.0")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Compiler for C supports arguments -Wincompatible-pointer-types: YES
Compiler for C supports link arguments -Wl,--exclude-libs=ALL: YES
Dependency threads found: YES
Library m found: YES
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Dependency vulkan found: YES 1.1.82
Library glslang found: YES
Library HLSL found: YES
Library OGLCompiler found: YES
Library OSDependent found: YES
Library SPIRV found: YES
Library SPVRemapper found: YES
Fetching value of define "GLSLANG_PATCH_LEVEL": 2888
Dependency lcms2 found: YES 2.9
Library shaderc_shared found: YES
Program git found: YES (/usr/bin/git)
Configuring config.h using configuration
Build targets in project: 1
Found ninja-1.8.2 at /usr/bin/ninja
vdr01_64 libplacebo # LC_MESSAGES=C ninja -C$DIR
ninja: Entering directory `./build'
[32/33] Compiling C object 'src/src@@placebo@sha/spirv_shaderc.c.o'.
FAILED: src/src@@placebo@sha/spirv_shaderc.c.o
ccache cc -Isrc/src@@placebo@sha -Isrc -I../src -I../src/./include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -g -Wall -Wundef -Wshadow -Wparentheses -Wpointer-arith -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -D_ISOC99_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes -Wno-pointer-sign -fPIC -pthread  -MD -MQ 'src/src@@placebo@sha/spirv_shaderc.c.o' -MF 'src/src@@placebo@sha/spirv_shaderc.c.o.d' -o 'src/src@@placebo@sha/spirv_shaderc.c.o' -c ../src/spirv_shaderc.c
../src/spirv_shaderc.c: In function ‘shaderc_init’:
../src/spirv_shaderc.c:49:13: error: ‘shaderc_optimization_level_performance’ undeclared (first use in this function); did you mean ‘shaderc_optimization_level_zero’?
             shaderc_optimization_level_performance);
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             shaderc_optimization_level_zero
../src/spirv_shaderc.c:49:13: note: each undeclared identifier is reported only once for each function it appears in
ninja: build stopped: subcommand failed.
vdr01_64 libplacebo #

What do i wrong?

Is it possible to port this library to vcpkg?

vcpkg is a C++ library manager for Windows, Linux and macOS written by Microsoft. It supports CMake, meson and many other build systems.

Implement deinterlacing

This feature roughly consists of two separate aspects:

1. Adding an API to represent interlaced content in the renderer. Maybe tie this into the interpolation API somehow? Since interlacing is a fundamentally temporal thing - but unlike interpolation, it needs to be done on the opposite end. Tricky. If this turns out to be too involved, we could just regress to a single-field only representation, which would just require a change to pl_plane / pl_image.
2. Implement the corresponding deinterlacing shaders. Ideally, we want something high quality here - but even a simple bob deinterlacer wouldn't be useless.

Implement 16f -> 16hf texture emulation

There's currently no way to upload a 16-bit float texture using 32-bit host floats via vulkan, but that's a common/useful thing (especially for LUTs).

We should implement texture format emulation for this format mapping pair as well.

Implement support for frame mixing / temporal interpolation

The API for this has been sketched out already, but there's currently no implementation. This will be a very difficult change, with lots of knowledge about the current mpv interpolation (tscale) algorithm and careful testing required.

Blocked by #12
See also https://github.com/mpv-player/mpv/wiki/Interpolation

Implement support for more vulkan swapchain colorspaces

Vulkan swapchains support many colorspaces (various primaries, HDR, and so forth). We should try and use those if requested / possible.

This is a relatively straightforward change, since all of the vulkan colorspaces map 1:1 to libplacebo colorspaces, which the swapchain already tags (and the renderer already respects).

The most difficult part will be figuring out how to test it.

how to build for armv7 & arm64 on iPhone

Hi, I see vlc use this code, and it can build using Makefile.
I want to build the lib for armv7 and arm64, I use this ：
CC="$(xcrun --sdk iphoneos --find clang) -isysroot $(xcrun --sdk iphoneos --show-sdk-path) -arch arm64 -arch armv7" make
but , that don't work.

the Makefile is below:
SRCS := colorspace.c common.c context.c dither.c dispatch.c filters.c renderer.c shaders.c
shaders/colorspace.c shaders/sampling.c spirv.c bstr/bstr.c bstr/format.c 3rdparty/siphash.c
ta/ta.c ta/ta_utils.c ta/talloc.c

lpthread_libs = $(shell $(LD) -lpthread && echo "-lpthread" || echo "")

OBJS = $(patsubst %.c, $(OBJDIR)src/%.o, $(SRCS))

CFLAGS += -D_ISOC99_SOURCE -D_GNU_SOURCE
-Isrc -Isrc/osdep -Isrc/include
-fvisibility=hidden -Wall -Wundef -Wmissing-prototypes -Wshadow
-Wparentheses -Wpointer-arith -Wno-pointer-sign

targets = libplacebo.a

all: $(targets)

install: $(targets)
rm -rf $(PREFIX)/include/libplacebo
mkdir -p $(PREFIX)/lib/pkgconfig/ $(PREFIX)/include/libplacebo
cp -r src/include/libplacebo $(PREFIX)/include
cp src/config.h $(PREFIX)/include/libplacebo
cp libplacebo.a $(PREFIX)/lib/
@echo "Name: libplacebo" > $(PREFIX)/lib/pkgconfig/libplacebo.pc
@echo "Description: Reusable library for GPU-accelerated video/image rendering" >> $(PREFIX)/lib/pkgconfig/libplacebo.pc
@echo "Version: 0.2.1" >> $(PREFIX)/lib/pkgconfig/libplacebo.pc
@echo "Libs: -L$(PREFIX)/lib -lplacebo $(lpthread_libs)" &gt;&gt; $(PREFIX)/lib/pkgconfig/libplacebo.pc
@echo "Cflags: -I$(PREFIX)/include" >> $(PREFIX)/lib/pkgconfig/libplacebo.pc

$(OBJDIR)/%.o: src/%.c
$(CC) -c $(CFLAGS) $&lt; -o $@

libplacebo.a: $(OBJS)
$(AR) csr $@ $^

clean:
rm -f *.o
rm -f $(targets)

Implement support for debanding in the renderer

The shaders for this already exist, they just need to actually be called by the renderer.

swapchain creation on second screen fails

When I try to create a swapchain with a surface from another screen eg.g.. :0.1 then this fails
Here is the debug output:
debug: Requested image count: 2 (min 2 max 8)
info: (Re)creating swapchain of size 1920x1080
error: vkCreateSwapchainKHR(vk->dev, &sinfo, VK_ALLOC, &p->swapchain): VK_ERROR_INITIALIZATION_FAILED
error: Failed (re)creating swapchain!
Is this a shortcoming from vulkan or is it a problem in libplacebo ? The surfacecreation itself is successfull.

// create XCB surface for swapchain
xcbinfo.sType = VK_STRUCTURE_TYPE_XCB_SURFACE_CREATE_INFO_KHR;
xcbinfo.pNext = NULL;
xcbinfo.flags = 0;
xcbinfo.connection = Connection;
xcbinfo.window = VideoWindow;

if (vkCreateXcbSurfaceKHR(p->vk_inst->instance,&xcbinfo,NULL,&p->pSurface) != VK_SUCCESS) {
	Fatal(_("Failed to create XCB Surface\n"));
}

Hide internal symbols

If one builds libplacebo with glslang support enabled, the shared library exposes pl_glslang_* symbols as part of its ABI. Those symbols appear to be internal, though, since they do not appear in any of the installed header files. Could you please hide them, e.g. with __attribute__((visibility("hidden"))) or build with -fvisibility=hidden and explicitly mark all public functions with default visibility? Alternatively one could also use a version script, which would have the additional benefit that the glslang symbols don't leak as part of libplacebo's interface.

gentoo ebuild doesn´t work

Use attached patch
ebuild.diff.gz

Fails to build without git

When downloading the tarball corresponding to tag and then building libplacebo without git installed, meson fails with:

Meson encountered an error in file src/meson.build, line 104, column 0:
Program or command 'git' not foundor not executable

Please handle this case the same way a failing git describe is handled.