Khronos really, *really* loves dropping the KHR/EXT suffixes when
promoting extensions to core. And we really, *really* don't like
hard-coding multiple function names for every function in existence.

Brute force the problem by trying to load every function with the suffix
stripped, in case of failure.

When VK_KHR_get_physical_device_properties2 is missing. Currently, it
just segfaults.

This can be used by the config scripts of other projects without having
to do actual header feature testing. (In particular, we do the same for
libepoxy in our build script)

"string literal"[constant] is not always considered a constant
expression, apparently. Simple to work-around.

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

This is supposed to be equal to 1 even for non-array types. Oops!

This is needed for a later commit, but good for consistency in any case.
Note that array types are still ignored, since they don't usually form a
part of the GLSL type name.

Turns out that not having egl.h in place requires hiding a lot of
existing code behind EPOXY_HAS_EGL.

Annoying, but oh well.

This only exists if `epoxy_has_egl` is true (in the pkg-config file).
Bumped up the meson ver to 0.51 in order to use .get_variable().

Note: I noticed also that opengl_surfaceless.c unconditionally assumes
EGL's presence, and fixed that as well.

Seems like glslang upstream is more than happy to make their patch level
go back down to 0 now. To handle the mishmash of old and new versioning
schemes, we map the old patch level to version 0.0.x, which ensures it's
forwards-compatible with the new versioning scheme (that was fortunately
introduced after every relevant check of ours).

Fixes https://github.com/haasn/libplacebo/issues/83 again, properly this
time.

Vasilis Liaskovitis authored 4 years ago and Niklas Haas committed 4 years ago

Implements PL_HANDLE_DMA_BUF for opengl.

This commit also introduces a public-facing concept of DRM fourccs,
which are useful/needed by OpenGL to mediate the texture format. We
blend this into the pl_fmt concept because of parallels to how this is
done in other APIs, and because `pl_fmt` is already required to specify
upon import.

See !116 for discussion.

Co-authored-by: Niklas Haas <git@haasn.xyz>

This uses round(), which requires GLSL 130+

Instead of raw identifiers of the form 0x%x. We can leverage our lovely
vk.xml-parsing utils generator to generate friendly name boilerplate
code for this.

Closes #107

This updates our checks to use the new header locations as introduced in
https://github.com/KhronosGroup/glslang/pull/2277. Fortunately, it seems
that the new version scheme is backwards compatible with the old one, so
we don't need any excessively complicated logic updates.

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

Something something, empty function lists get interpreted as "unknown
signature" rather than "void signature". Dunno if this is still relevant
for C++, but may as well get into the habit.

Mirroring logic from mpv's vo_gpu. Motivated by the fact that many
GPU-less build environments have barely functioning or broken software
rasterizer fallbacks. The status of this bool is controlled explicitly
for the CI by the new `CI_ALLOW_SW` define, to allow gitlab tests to
continue using (new enough versions of) llvmpipe.

Closes videolan/libplacebo#109

Treating 0x0 as "all types allowed" was a very terrible default, because
it completely masked the failure case of there actually being no types
allowed. I have no idea what the justification for this was, but it
doesn't make sense anyway.

Leaving this struct partially initialized on the failure path caused a
double-free when the error code for pl_buf_create tried freeing this
slab a second time (via pl_buf_deref).

As an aside, also make sure we `goto error` on every possible failure
path, rather than `return false`.

This is required to support GLSL ES 1.0 and GLSL 110, which forbid the
use of literal arrays in shaders. Since SH_LUT_LITERAL is now no longer
a safe fallback, we instead always fallback to SH_LUT_UNIFORM.

This is technically an API break, since in the past, the naked pl_shader
API would always generate literal shaders, but now they may have arrays
attached as uniforms - to prevent this, users can still set small LUT
sizes (which is what e.g. VLC does anyway)

This pretty much only really affects the polar sampling code, which uses
a small linear LUT. I found that the performance gain depends on whether
or not we're using compute shaders, with the non-compute shader path
being the only one to really benefit from this change.

By providing fallback code to linearly interpolate between array values
on the GPU. The motivating use case here is not just a concern of
semantics/correctness, but more importantly, because doing so might
actually be faster than going through a texture sample, for small LUTs.

This allows such tex transfers to avoid an extra memcpy in most cases,
except where the pointer happens to be horrifically misaligned with
respect to the texel size - but in these cases, the alignment-fixing
memcpy will happen inside VRAM (PL_BUF_MEM_DEVICE), which should still
be faster than doing an extra memcpy in RAM.

Also, I realized it makes no sense to have tex_download_pbo use a buffer
pool at all, because it's synchronous anyway - there can only ever be
one buffer. And doing it this way avoids code duplication between the
import branch and the non-import branch.

Side note: We could do the same for pl_tex_upload_pbo with the same
justification, but I decided to test the waters with this commit first.

This allows us to bypass the page-alignment restriction on host pointer
imports, by simply sufficiently extending the host pointer base, the
buffer offset, and the memory size in the respective direction. Thus
ensuring that our memory import is always page-aligned.

This *should* technically be safe, because the MMU can only enforce
virtual memory access safety on a per-page granularity, and our code
should never end up reading outside the bounds of a vk_memslice. But on
the other hand, what we're doing is absolutely insane. Beware nasal
demons. I only wrote this logic because I enjoy sharing an address space
with a malevolent agent of chaos.

As an aside, also fix some errors related to imported buffer size
calculation and alignment validation that I noticed along the way.

This is intended for stuff like probing functions, to avoid generating
bogus error messages. We directly make use of this function to clean up
the format probing code, which is notoriously prone to generating error
spam.

Mostly so I can test the improvements that leveraging host-mapped
pointers will give us.

To prevent logic errors when overflowing e.g. the BT.2390 function, and
also make functions behave more predictably on overflow in general.

This ensures no function will ever see something larger than sig_peak.
Requires changes to `clip` and `linear` to make them work properly
again.

These are not included as part of the GCC visibility pragma.

A hilariously awkward mix-up. This probably meant the ICC profile code
never actually produced correct results in practice unless the two color
spaces happened to coincide.

Good thing nobody used it in production yet (tm)

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

This is still a pretty bad hack-patch as of currently, because no driver
actually implements the drm format modifier extension. But this way of
doing it at least allows us to differentiate between linear and
non-linear, which we assume (blindly) is equal to optimal, and is needed
to get vaapi hwdec working on AMD.

We also get rid of the plane offset check because this also conflicts
with the requirements of drm format modifiers, which we again can't
respect properly. We already suppress validation errors for the image
bind, and it works in practice.

For consistency, and because these technically serve a useful purpose
(e.g. allowing static array sizing or bounds checks).

I was growing unhappy by the use of the non-explanatory, confusing and
misleading 'TV' and 'PC' enum names. Replace them by the more
descriptive terms 'LIMITED' and 'FULL', respectively.

No API bump because this is not a breaking change, as the old enum names
are still defined.

1. VkBuffer sharing mode doesn't actually affect anything in real-world
   drivers (e.g. RADV, ANV, AMDVLK).
2. VkBuffers are not part of the interop API so we don't care about
   having to communicate this to the user.
3. Having to somehow transition all buffers would be a pain anyway

Fixes videolan/libplacebo#85

This combines the function with the previously hidden pl_opengl_wrap_fb,
allowing users to either provide their own framebuffers (in addition to
the texture) or just wrap a plain framebuffer directly.

In addition to merging these two functions, we also significantly
overhaul the `gl_fb_query` function for inferring `pl_fmt` details from
an opaque framebuffer. In particular, our wrapped framebuffers can now
support PL_FMT_CAP_HOST_READABLE.

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

With the recent series of refactors to the vulkan malloc layer,
host-visible device-local memory types exist and are allocatable, so we
can directly serve host-readable uniform buffers.

For the scenarios in which it's not possible, working around it should
probably be done inside the pl_gpu, not the application code. (i.e.
'host visibility emulation')

Now that we support the existence of 'optimal' memory type properties,
we can make device-local memory be the 'optimal' type by default. We can
also split up `host_mapped` into scenarios where it's required and
scenarios where it's merely recommended.

Imported noncoherent memory is not implicitly invalidated.

1. Log the proper pointer on unimport
2. Add missing test case

Philip Langdale authored 4 years ago and Niklas Haas committed 4 years ago

Dedicated allocations are ones where memory is allocated with
a single image or buffer specified at allocation time, and only
that buffer or image can be bound to the memory.

Our first use-case for supporting it is to handle importing dma_bufs
on AMD hardware, where the driver says dedicated allocations are
required.

I've tested this on Intel hardware, which doesn't require dedicated
allocations, but works fine if you force them.

Modified-by: Niklas Haas <git@haasn.xyz>

Rebased on top of the vulkan malloc API refactor, and also added support
for allocating dedicated slabs directly - which allows us to also
allocate dedicated memory for images which advertise preferring
dedicated allocations. Finally, add some extra verification.

Closes: videolan/libplacebo!72

Major refactor, accomplishing the following:

- group args into a params struct
- unified API for importing, generic and buffers
- move buffer importing boilerplate to the malloc layer
- split up the property flags into required and optimal properties
- better memory type scoring
- enforce heap size when allocating large slabs
- fix some buggy checks for optionally visible/coherent memory

And probably more that I'm forgetting.