1. 02 Jun, 2019 1 commit
    • Niklas Haas's avatar
      config: replace PL_FIX_VER/PL_VERSION by runtime functions · 22a99191
      Niklas Haas authored
      Since the fix version is not part of the ABI, we can't use a header
      define for it. (And indeed, users can't use this information as part of
      any preprocessor check - nor should they need to)
      
      I won't bother bumping the API version for this change because it's
      unlikely to result in any breakage.
      22a99191
  2. 31 May, 2019 1 commit
    • Philip Langdale's avatar
      vulkan: Suppress validation errors when binding imported image memory · dc1059b2
      Philip Langdale authored
      Importing image memory is a funny thing; there's no core mechanism
      to communicate the layout of the image. Depending on how exactly
      the memory was imported, and where it was imported from, it might
      be possible to manage without explicit knowledge of layout, or
      out-of-band mechanisms might exist to communicate it.
      
      Today, we specifically can handle importing of memory via dma_buf
      fds. While there is a Vulakn extension defined that could help
      to communicate layout (VK_EXT_image_drm_format_modifier), this
      extension isn't actually implemented in any driver and it doesn't
      look like it will happen any time soon.
      
      Without it, we have to hope that imported memory has the same layout
      that Vulkan expects, based on the declared image format. In
      practice, this has proven to be true for the real world scenario
      we care about - which is importing decoded video from VAAPI - there
      are only a couple of relevant formats, and the drivers for both
      Vulkan and VAAPI are written by the same sets of people following
      the same hardware driven recommendations for layout.
      
      However, just because layouts match in practice, doesn't mean that
      they pass validation. What we see is that, for some formats,
      validation will fail when binding memory, saying that the memory
      segment is smaller than the vulkan-calcuated memory size. I assume
      this happens due to a difference in memory alignment (pretty much
      any other cause would lead to visible errors).
      
      As we would like to be able to use VAAPI imported surfaces without
      sacrificing validation, we need a way to filter out these expected
      errors, and let validation proceed as normal elsewhere.
      
      The mechanism we've decided on is to provide a way to ignore
      errors on a specified vulkan object (in our specific case, the
      VkImage). We store the object ID before the bind call, and clear
      it afterwards. While it is set, errors on that object will be
      suppressed.
      
      It's a simple mechanism that isn't thread safe, but could be made
      so if/when the need arises.
      dc1059b2
  3. 26 May, 2019 1 commit
    • Niklas Haas's avatar
      vulkan: change infinite loop polls to block indefinitely · 644f9d57
      Niklas Haas authored
      I forgot what the original justification was for using short timeouts
      here (perhaps some driver bug?) but in any case, it doesn't seem to make
      any sense anymore.
      
      This reduces CPU usage drastically on some drivers. I kept one loop at
      10 ms since it shouldn't be hit anyways, and this way we know it's stuck
      in that loop for absurd amounts of time.
      644f9d57
  4. 24 May, 2019 2 commits
    • Niklas Haas's avatar
      vulkan: respect swapchain surface format feature flags · 16744b29
      Niklas Haas authored
      Currently we only look at the swapchain-specific feature flags, but we
      also still need to respect the image format's own limitations.
      16744b29
    • Niklas Haas's avatar
      vulkan: don't force large vertex buffers to be host visible · e71cfe26
      Niklas Haas authored
      The current logic could end up with a buffer that needs to be both
      device-local (for vertex information) and host-visible (for updates).
      This is obviously nonsensical, so work around this case instead.
      
      The ideal solution is to use a separate staging buffer, but that
      requires more logic changes than this workaround, and the only
      difference is that this might be possibly slower.
      e71cfe26
  5. 15 May, 2019 1 commit
  6. 15 Apr, 2019 1 commit
    • Philip Langdale's avatar
      xtalloc: Re-prefix all ta_* symbols to xta_* · 12aab84a
      Philip Langdale authored
      xtalloc was copied from mpv, which means that we see symbol
      collisions if libplacebo is statically linked into mpv. So
      use an `xta_` prefix for all the functions. In practice, this
      has almost no effect on the consuming code because everything
      is accessed via macros.
      12aab84a
  7. 14 Apr, 2019 1 commit
    • Philip Langdale's avatar
      spirv: Prefix spirv compiler function struct names · 4912e344
      Philip Langdale authored
      These structs are included via extern declarations, so they can
      silently conflict with equivalently named declarations in an
      application if libplacebo is included statically.
      
      And this happens with mpv, which also declares a `spirv_shaderc`
      struct.
      
      So, prefix the struct names with `pl_` to avoid this.
      4912e344
  8. 01 Apr, 2019 2 commits
  9. 18 Mar, 2019 1 commit
    • Niklas Haas's avatar
      vulkan: fix overzealous misalignment check on texture transfers · e16dd395
      Niklas Haas authored
      These made it so that the async transfer queue was never actually used.
      This is obviously a massive performance regression on all drivers
      supporting asynchronous transfer (e.g. AMDVLK).
      
      The spec explicitly allows the case where the transfer spans the entire
      image, i.e. offset+extent = size.
      e16dd395
  10. 07 Mar, 2019 1 commit
    • Niklas Haas's avatar
      shaders/av1: release under MIT · 2ee4b041
      Niklas Haas authored
      dav1d people want this to be permissive so they can adapt it for
      documentation purposes. I have no problems releasing this specific file
      under a permissive license.
      
      Note that since both the header and source code heavily depend on the
      LGPLv2.1+ parts of libplacebo, this licensing change isn't terribly
      useful unless you're just interested in copying fragments of the glsl
      code or some of the C helper functions.
      2ee4b041
  11. 24 Feb, 2019 6 commits
    • Niklas Haas's avatar
      vulkan: fix external memory vs external semaphore type confusion · cd7d4be8
      Niklas Haas authored
      These are different enums, with different legal members. Not only does
      this avoid a warning, it also avoids future disaster by conflating the
      two.
      cd7d4be8
    • Niklas Haas's avatar
      shaders: compat for GLSL < 130 · bd502804
      Niklas Haas authored
      We need to use the explicitly named functions like texture2D(),
      texture3D() etc. for low GLSL versions. Add a bunch of shitty
      compatibility code to template out the function name.
      
      The specific way I solved it also opens us up to allowing e.g. rectangle
      textures in the future.
      bd502804
    • Niklas Haas's avatar
      shaders: cosmetic (code moving) · 02a2f7bd
      Niklas Haas authored
      Make this a function instead of a static inline, since it's complicated
      enough.
      02a2f7bd
    • Niklas Haas's avatar
      shaders: allow overriding shader GLSL version explicitly · 27835a8b
      Niklas Haas authored
      This can be useful for API users that don't want to go through the
      bother of setting up a dummy `pl_gpu` just to create some shaders.
      27835a8b
    • Niklas Haas's avatar
      shaders: refactor shader creation API · 729e4aee
      Niklas Haas authored
      - I wanted to add new parameters, and rather than having the function
        signature grow out of control, I decided to switch to the same
        `params`-style as the rest of libplacebo, for future forwards
        compatibility.
      
      - We need to expose the identifier, because users of raw shaders might
        want to combine multiple shaders into the same GLSL program.
      
      This kills off the hacky `_ex` functions and uses a params struct. Also
      organizes some fields around, for reasons.
      729e4aee
    • Niklas Haas's avatar
      shaders: change implicit GLSL version assumptions · 44b4f779
      Niklas Haas authored
      Instead of assuming the lowest possible, assume GLSL 130 as the
      baseline. This requires bumping the API version because it is a breaking
      change to some use cases.
      
      Also a missing GLSL version compat check to the dither code.
      44b4f779
  12. 03 Feb, 2019 1 commit
  13. 31 Jan, 2019 1 commit
  14. 29 Jan, 2019 1 commit
    • Niklas Haas's avatar
      swapchain: add resizing API · ad242535
      Niklas Haas authored
      This is used both for updating the size and querying the size. I don't
      want to make these separate functions because it should be painfully
      obvious that the size you get may not be the size you request.
      
      This allows libplacebo to work on wayland, which mediates the concept of
      swapchain resizing to protocols like xdg_shell that mesa/vulkan can't
      know anything about (by design).
      ad242535
  15. 28 Jan, 2019 1 commit
  16. 11 Jan, 2019 9 commits
  17. 05 Jan, 2019 9 commits
    • Niklas Haas's avatar
      tests: update benchmark for HDR peak changes · 762de151
      Niklas Haas authored
      Forgot to update this, now it compiles again (and tests sensible stuff)
      762de151
    • Niklas Haas's avatar
      gpu: actually generalize `pl_tex_export` · 3294a29e
      Niklas Haas authored
      We accidentally implemented this inside vulkan/gpu.c instead of the
      general purpose wrapper code. That also meant we never tested the
      `tex->params.export_handle` condition.
      
      However, I realized that this condition is actually too restrictive for
      our test framework, and working around it there would be sort of
      annoying. So just drop the restriction.
      
      I won't bother updating the API version for this change, since the
      actual behavior hasn't changed. (And even if it had, it would only
      matter for our own test framework)
      
      As an aside, fix a bunch of related comments that still had outdated
      field names in the documentation.
      3294a29e
    • Niklas Haas's avatar
      vulkan: implement proper buffer queue tracking · 70946fc9
      Niklas Haas authored
      Turns out that this actually causes problems when e.g. trying to reuse
      an SSBO between a compute shader and a fragment shader, which comes up
      when using the new peak detection code.
      
      One annoying thing about the implementation is that we will always need
      to make sure that buf_flush happens after buf_signal, since the former
      depends on the stage variable set by the latter. Maybe I'll change this
      in the future if it gets annoying.
      
      Fixes #49.
      70946fc9
    • Niklas Haas's avatar
      renderer: perform color management on image->color · a6ccb671
      Niklas Haas authored
      The whole reason this `prelinearized` field *exists* is because we
      still want to pass the original colorspace when performing color
      management or constructing the 3DLUT. It's weird how we never used it.
      Fix this oversight.
      a6ccb671
    • Niklas Haas's avatar
      renderer: implement new peak detection · 10670ff8
      Niklas Haas authored
      This also allows us to finally separate peak detection from color
      management. The current place in the code actually has almost no
      drawbacks, since it's effectively free unless FBOs are disabled.
      
      One annoying consequence is that this means we will now always perform
      peak detection at the source resolution, even if the display is smaller.
      In the relatively common case of 4K video on 1080p displays, this is a
      performance regression. To fix it, we could try investigating whether to
      do the analysis after up/downscaling, but then we have more special
      cases to think about, so I think I'll live with the status quo for now.
      Peak detection isn't the end of the world even at 4K.
      
      Closes #40.
      10670ff8
    • Niklas Haas's avatar
      renderer: destroy the peak detect state object on flush_cache · 893ba13c
      Niklas Haas authored
      Now we actually have a use for this!
      893ba13c
    • Niklas Haas's avatar
      shaders/colorspace: style · 8acf086e
      Niklas Haas authored
      8acf086e
    • Niklas Haas's avatar
      shaders/colorspace: completely refactor HDR peak detection · 9b4aecb1
      Niklas Haas authored
      The previous approach of using an FIR with tunable hard threshold for
      scene changes had several problems:
      
      - the FIR involved annoying dynamic buffer sizes, high VRAM usage,
        and the FIR sum was prone to numerical overflow which limited the
        number of frames we could average over.
      
      - the hard scene change detection was prone to both false positives and
        false negatives, each with their own (annoying) issues.
      
      Scrap this entirely and switch to a dual approach of using a simple
      single-pole IIR low pass filter to smooth out noise, while using a
      softer scene change curve (with tunable low and high thresholds), based
      on `smoothstep`. The IIR filter is extremely simple in its
      implementation and has an arbitrarily user-tunable cutoff frequency,
      while the smoothstep-based scene change curve provides a good, tunable
      tradeoff between adaptation speed and stability - without exhibiting
      either of the traditional issues associated with the hard cutoff.
      
      Another way to think about the new options is that the "low threshold"
      provides a margin of error within which we don't care about small
      fluctuations in the scene (which will therefore be smoothed out by the
      IIR filter).
      
      While redesigning the algorithm, I also redesigned the API - so that
      peak detection and tone mapping are separate, discrete steps that can be
      done as part of two different shaders. (Or as part of the same shader)
      This is required for #40, and in particular, means that issue is now
      within reach.
      
      cf. https://github.com/mpv-player/mpv/pull/6415
      9b4aecb1
    • Niklas Haas's avatar
      shaders: don't reattach the same buffer twice · 9d10601f
      Niklas Haas authored
      Annoying special case needed to allow us to split up peak detection and
      tone mapping into two passes, each of which may end up attaching the
      same SSBO to the same shader.
      9d10601f