We were forgetting to remap from our handle_type enum to the
Vulkan one.

To emphasize that it's only testing interop, and also point out that we
should keep these separate.

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

This change adds a test that exports a texture and then imports it
back in again. This round-tripping is explicitly supported by the
Vulkan spec.

The test only runs for dma_buf handles because that's the only one
we have an import implementation for.

I also fixed the existing test which didn't properly check the
fd value of the buffer.

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

This change introduces new capabilities to allow for external memory
to imported and bound to textures.

The specific use-case is supporting interop with vaapi hardware
decoding, where dma_buf is used to export decoded video surfaces.

The API basically involves passing a `pl_shared_mem` when creating
a texture, to describe the external memory to be used. When this
is done, the external memory is imported and used instead of making
a normal memory allocation.

Past that point, the texture behaves like a normal one, and destroying
the texture will free the imported allocation. Note that we will
repeatedly import a single allocation if it is passed for separate
textures. This happens in the vaapi case because each surface is
a single allocation but each plane must be imported as a separate
texture. The Vulkan spec explicitly required multiple-import to
work, so this is safe.

I have a corresponding mpv change that demonstrates this all works.

Note that this implementation is more fragile than you'd want because
we can't use `VK_EXT_image_drm_format_modifier`. This extension has
yet to be enabled in the Mesa vulkan drivers, and until it is enabled,
we cannot communicate detailed format information from vaapi to
Vulkan. Examples of this include the pitch, tiling configuration and
exact image format. For the common cases we deal with in vaapi, this
is not fatal - it happens to be the case that pitch and tiling work
out, and mpv is able to pick a compatible format based on its
existing format mapping code.

Note that this code may not pass validation, as a result. In my
mpv tests, I see validation failures when mpv is doing format
probing, reflecting that some of the more exotic formats cannot
be matched up without `VK_EXT_image_drm_format_modifier`. However,
once probing is complete, they decode and display run without
validation errors.

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

dma_buf fds are treated as a distinct type (vs OPAQUE_FD) in
Vulkan, and so we need to treat them separately too. While the
basic interactions are the same as for OPAQUE_FD, there is one
distinct difference, which is that dma_buf fds cannot be used
for external semaphores, so we have to separate the handle type
lists when probing for support.

Note that vkGetMemoryFdPropertiesKHR function import is currently
unused, but is necessary for importing dma_buf fds down the line.
While the method is part of the generic external_fd extension, the
spec says it cannot be used for OPAQUE_FD (seriously?) and so it's
really only relevant for dma_buf fds.

In practice, these can be different enough (e.g. dmabufs, which are only
supported for buffers on RADV, but not images). So split them up in
preparation for future commits.

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

In prepartion for supporting importing external memory, we need to
define separate caps for import handle types. In theory, a Vulkan
implementation is free to only support a handle type for one
direction and not the other.

This also means we have a field for import caps for `pl_sync`. This is
always set to 0 for now as we don't have a use-case for importing
semaphores.

This can be used to reinterpret what the brightness range of values
mean. A typical use case is for linear-light content which is
technically encoded as 0.0 - 1.0, but practically supposed to extend to
HDR values far beyond the typical SDR brightness. OpenEXR files in
integer mode are encoded like this, for example.

This also unifies/replaces the hacky old "hdr emulation" mode with the
new concept, it being simply applied to the target csp in this mode of
operation.

Niklas Haas authored 6 years ago and Niklas Haas committed 6 years ago

Needed for win32 handle code.

Niklas Haas authored 6 years ago and Niklas Haas committed 6 years ago

We can't link the subproejcts as dependencies directly, because meson
incorrectly emits the linker flags (and omits the objects). Solve it
manually instead by directly including the relevant object files.

This commit can and should be reverted as soon as the meson bugs are
fixed upstream, since it's an ugly hack.

cf. https://github.com/mesonbuild/meson/issues/4598

meson: fix include on slightly older meson

See merge request videolan/libplacebo!61

Turns out this one included is needed for older versions of meson, so
make sure to add it regardless.

Instead of having to awkwardly include "include/bstr.h", just add its
own include path when building the library itself.

We had a lot of redundancy, especially in the test framework handling.
This commit fixes it by grouping as much as possible into a single
`tdep` object.

Mercifully much easier than buffers/images

Just try asking the driver if it would be okay with a TRANSFER_DST
buffer for this handle type. If tha fails, so should certainly
everything else.

Unfortunately, we have no good way of testing which handle types are
supported for images. We could also use trials here, but we don't really
distinguish between images and buffers at all in the pl_gpu.handle_caps.

Hopefully this should normally either be supported for both buffers and
images, or for neither. It's probably best the user just relies on
`pl_tex_create` failing in environments where buffers are supported but
images are not.

Similar to the previous commit, we need to ensure compatibility with the
handle type we are interested in to avoid UB.

Also rewrite the image format compatibility check logic in general to
make it more future-proof. Also fixes a few memleaks on error (due to
`return NULL` when it should have done `goto error`).

Spec says we need to test for compatibility with vkGet*BufferProps
before creating the VkBuffer, else it's undefined behavior - the driver
won't signal incompatible handle types by buffer creation failure.

After postponing this issue previously because we had no permanent
context associated with user-provided instances, and no way of
retroactively knowing what instance-level extensions were provided, the
solution hit me on the head:

We can just load them as part of the device-level extensions that depend
on them. Duplicates in this list don't matter, since loading the same
pointer twice is idempotent.

There were a bunch of disjointed switch statements all over the place.
Reduce these in favor of one helper function, since we'll end up needing
this more as we go on.

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

No idea if this actually works, but perhaps we'll find out.

If you wanted the test to run and pass on windows 7, you'd
presumably not want the NT Handle test to run.

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

There are two win32 specific handle types, which we believe to be
the ones that would be primarily used by a win32 client.

There is the 'NT Handle', which is available on Windows 8 or newer,
and the 'Global share Handle' (abbreviated as KMT in the Vulkan spec),
which is available on Windows 7 and newer, but which apparently
shouldn't be used when the 'NT Handle' type is available. We do not
attempt to judge usage, and it is up to the client to decide which
of the two types it wants to use.

Note that the existing logic for identifying the handle_caps is not
actually sufficient. We need to call specific functions to identify
what is possible for buffers, images, and semaphores.

* vkGetPhysicalDeviceImageFormatProperties2KHR
* vkGetPhysicalDeviceExternalBufferPropertiesKHR
* vkGetPhysicalDeviceExternalSemaphorePropertiesKHR

and these need to be called with the specific flags and parameters,
so I think it basically ends up being that you can't tell if your
image/buffer/semaphore is exportable until you create it. Anyway.

I am not in a position to test any of these changes. Someone who
can build on win32 must do that.

This was still called 'lib3rdparty' from a previous iteration of the
meson subprojects refactor.

No longer needed thanks to our new gitlab overlords

So the world can point and laugh at our awful test suite

Still not really the effect we want, but better than nothing.

Right now, pl_shader_sample_polar and pl_shader_sample_ortho had
distinct sampler object types - but this was unclear and actually caused
issues in e.g. the pl_renderer code. Fix it to use the same sampler
object type instead.

This order was weird.

We were using both the old Von Kries LMS matrix (for color blindness
simulation), as well as the CIECAM97-derived non-linear Bradford matrix
for chromatic adaptation - despite not introducing the required
nonlinearity. (Note that ICC etc. also have the same error)

Switch to the revised CIECAM97 matrix which is designed with a linear
transform in mind. This also requires extending the logic of the color
blindness simulation matrices to ensure white continues mapping to white
- which previously only worked sort of by accident, and only to within
1e-3 accuracy.

Improves coverage, and uncovered a few bugs!

This was not equal-energy.

And change the way we write these switch statements to prevent similar
bugs in the future.

Major refactor of the source code structure. Now uses meson subprojects
for "third party" dependencies (including bstr and talloc), and moves a
lot of the meson boilerplate from src/meson.build to the top-level
meson.build.

We choose the name 'xtalloc' to make sure we don't collide with samba
libtalloc, and to reflect the fact that our wrappers abort on OOM.