1. 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
  2. 28 Jan, 2019 1 commit
  3. 11 Jan, 2019 9 commits
  4. 05 Jan, 2019 15 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
    • Niklas Haas's avatar
      shaders/colorspace: gamut map after tone mapping · a8c2f1f1
      Niklas Haas authored
      Tone mapping really dislikes handling negative values, which are a
      natural result of the gamut mapping taking colors out-of-gamut. Resolve
      this fundamental conflict by tone mapping first.
      a8c2f1f1
    • Niklas Haas's avatar
      shaders/colorspace: refactor pl_shader_ootf · db71e7a0
      Niklas Haas authored
      Move the sig_scale handling into our concept of OOTF, and also move the
      dst/src_luma coeffs there. (We can do this now since the tone mapping
      algorithm no longer needs them)
      db71e7a0
    • Niklas Haas's avatar
      shaders/colorspace: apply the OOTF whenever linearizing · 2549b5b8
      Niklas Haas authored
      The current logic skips the OOTF when performing primary adaptation or
      tone mapping on scene-referred content, which was wrong. Instead, merge
      `need_ootf` and `need_linear` and always perform it whenever
      linearizing.
      2549b5b8
    • Niklas Haas's avatar
      gpu: add pl_var_int · 238e2f02
      Niklas Haas authored
      No reason not to have this, and it's useful.
      238e2f02
    • Niklas Haas's avatar
      tests: add way more renderer tests · 4ecb186c
      Niklas Haas authored
      Now we actually test a whole bunch of options, including different
      dithering modes, tone mapping curves, etc.
      
      Makes the tests quite a bit more slow and also quite a bit more verbose,
      but that's the price of not having bugs!
      
      Also bump up the queue count so that we actually test multi-queue
      scenarios properly.
      4ecb186c
    • Niklas Haas's avatar
      shaders/colorspace: redesign tone mapping algorithm · 65ddefba
      Niklas Haas authored
      Instead of hackily desaturating towards white, we instead perform tone
      mapping in per-channel ("desaturating") mode, and then desaturate
      towards that result. This helps significantly for very over-mastered
      content like Mad Max, and also makes sanely mastered content feel
      slightly more realistic/natural. More importantly, it's closer to what
      the mastering engineers expect TVs to do.
      
      We also allow the user to configure a bit of over-exposure for dark
      scenes, which can help with extremely dark movies like Annihilation.
      
      cf. https://github.com/mpv-player/mpv/issues/6405 and
          https://github.com/mpv-player/mpv/issues/6415
      65ddefba
  5. 31 Dec, 2018 1 commit
  6. 22 Dec, 2018 6 commits
    • Niklas Haas's avatar
      tests: rename vulkan_tests · 6110ec30
      Niklas Haas authored
      To emphasize that it's only testing interop, and also point out that we
      should keep these separate.
      6110ec30
    • Philip Langdale's avatar
      meson: bump version · 3cf69d90
      Philip Langdale authored
      3cf69d90
    • Philip Langdale's avatar
      vulkan: add basic import test · cc236bf2
      Philip Langdale authored
      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.
      cc236bf2
    • Philip Langdale's avatar
      gpu: add support for creating textures bound to imported memory · b38e65cc
      Philip Langdale authored
      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.
      b38e65cc
    • Philip Langdale's avatar
      vulkan: add support for external memory with dma_buf fds · 39f4809d
      Philip Langdale authored
      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.
      39f4809d
    • Niklas Haas's avatar
      gpu: split up import/export caps between tex and buf · 4c6d10d3
      Niklas Haas authored
      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.
      4c6d10d3
  7. 21 Dec, 2018 2 commits
    • Philip Langdale's avatar
      gpu: add import handle_caps · 5ef7b583
      Philip Langdale authored
      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.
      5ef7b583
    • Niklas Haas's avatar
      colorspace: add a sig_scale field to pl_color_space · 08566a4c
      Niklas Haas authored
      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.
      08566a4c
  8. 16 Dec, 2018 1 commit
  9. 15 Dec, 2018 1 commit
  10. 10 Dec, 2018 3 commits