GitLab

Fixes #96 by
making it clear to API users that such invocations are not supported by
the API. (Probably doesn't fix the actual bug there, but that seems to
be downstream)

There were some FIXMEs that needed addressing.

VK_ is the vulkan namespace, so we shouldn't introduce upon it.

Using GL_ARB_timer_query and GL_TIME_ELAPSED, which matches the
semantics of pl_timer almost exactly identically.

The current memory barriers were either used illegally
(tex_gl->target??), overspecified (e.g. the forced barrier after
glDispatchCompute), or just plain missing (e.g. barriers for storage
images that might also be used in other ways).

Fix this mess by making the barrier usage consistent:
1. Only submit memory barriers on descriptors when unbinding them from
   shaders that might write to the resource
2. Skip unnecessary memory barriers for readonly resources
3. Submit *all* the barriers required for the object's usage flags

This commit introduces the ability to explicitly mark storage buffers as
coherent, but that requires an API change. To avoid breaking API of this
release branch, we hard-code all storage buffers as coherent. This
shouldn't matter much in practice.

This warns about the cast from anonymous enum to named enum, so use a
preprocessor symbol for them instead.

This was done using one scale, but it should have been done with a
separate scale factor for the width and height.

Suggested by @jojo61

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

Instead, implement a fallback path.

GLES 2.0 doesn't allow querying the default framebuffer like this.

We request the pbuffer surface type anyway, so might as well actually
create a pbuffer surface and test the swapchain, right?

Make it point at the actual HTML coverage report.

Use `expose_as` to link to the HTML report, and also attach the xml as a
cobertura artifact

Turns out:
1) utils_gen.py works on both py3 and py2,
2) meson can only use py3 anyway

This commit should guarantee it exists.

I'm not entirely convinced this is sane or needed, and that this isn't a
meson bug, but whatever, it's an easy work-around to carry in order to
solve a very real bug.

Fixes #97

This style of matching elements based on tag contents was introduced in
python3.7, breaking builds for some users stuck with older python
versions. Fix it by simply turning the xpath expression into a manual
loop/check.

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

xmfile -> xmlfile

Users complained about being confronted with a python stack trace. So
just catch the failure and give a better error message to more clearly
communicate to the user what must be done.

Fixes #93

Hard-code some common alternative locations to the vulkan XML, and
improve the error message otherwise.

Fixes https://github.com/haasn/libplacebo/issues/75
Fixes #95

This allows us to accept sampler types other than sampler2D. In
principle, any sampler type is supported, but due to shaders/sampling
being the only user of this API, we can restrict ourselves to only 2D
samplers in the implementation. Notably, though, we also support e.g.
PL_SAMPLER_RECT.

VLC needs this in order to integrate the pl_opengl abstraction into
their OpenGL-based video output module.

Closes #91

This just requires us to un-normalized the texture coordinates.

We need to generate the correct uniforms depending on the sampler type,
and also enable the OES_EGL_image_external extension crap.

Since objects may have to be sampled differently depending on the type
of texture, we need to encode this field into the `pl_tex` abstraction.

I broke the API of `pl_tex_dummy_create`, but hopefully in a way that
wasn't too bad.

The current algorithm can under-estimate the true peak due to smoothing,
causing clipping on sudden spikes in scene brightness. To help combat
this, simply stupidly add a 5% overshoot mergin to the detected peak
value. Values subject to change.

Since `p->pass` is NULL on failed passes, the raster_ok check segfaults.
Simply skip it in this case, since the pass is failed anyway so blend
parameters don't matter.

We make this the default tone mapping function because it's the de-facto
standard in the industry. Unfortunately, it's quite a bit heavier than
the other algorithms due to the extra PQ round trip needed during tone
mapping.

It's entirely possible that we could make the choice of whether to do
things in PQ space or in linear light a choice completely independent of
the tone mapping function itself, since arguably PQ's "perceptual
uniformity" quality makes it a suitable space to do tone mapping in
regardless of what function we use.

That being said, I don't currently want to consider the headache of
testing this all, so let's just implement it for BT.2390 and call it a
day.

The code as written allows 10-bit+linear, which is a bad combination. So
explicitly ban it.

Simple oversight. This should be PL_CHROMA_LEFT, not PL_CHROMA_TOP_LEFT.
Our own documentation gets it right, I just had the wrong name in my
head when writing the code.

Tested on KrigBilateral. Hopefully not too terribly broken.

Fixes #88

Rather than using the `params->rect`, we should generally be ignoring it
in favor of the raw texture dimensions, and only update the rect
accordingly.

A lot of subsampled content out there is untagged, but should be treated
as _TOP_LEFT content (the de-facto standard chroma subsampling mode).
However, we effectively treat _UNKNOWN as PL_CHROMA_CENTER. To fix this,
make pl_chroma_location_offset explicitly default the chroma location.

Since a lot of users currently just call that function on the chroma
planes always (regardless of subsampling), introduce a new helper
function `pl_image_set_chroma_location` to only set the plane shift for
actually subsampled planes.

Annoying API break, but it is what it is.

Yay coverage

No point in testing test code that's guaranteed to run, nor generated
code that's full of boilerplate switch/case statements.

This was UINT32_MAX, which explodes some of the shader logic. Pick
something more reasonable.

They can be interesting to look at.

I think that in theory, vkGetQueryPoolResults shouldn't have been
allowed to report VK_SUCCESS in this case, but at least AMDVLK still
does so. Explicitly check to see if the time is pending before
attempting to read from it.

These performance figures are quite a bit out of date. Many things have
changed in the meantime. Nuke the old results and re-measure them on
latest git master versions.

This was never updated for the pl_dispatch changes.