1. 01 Apr, 2019 1 commit
  2. 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.
  3. 24 Feb, 2019 2 commits
    • 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.
    • 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
      - 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.
  4. 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).
  5. 28 Jan, 2019 1 commit
  6. 11 Jan, 2019 5 commits
    • Niklas Haas's avatar
      gpu: allow attaching arbitrary user data to tex/buf · eec7dbc5
      Niklas Haas authored
      Not implemented for the other types of objects, because the chances of a
      user needing to associate unique data for objects is much less likely.
      It helps for buf/tex in particular since the user can use this to e.g.
      hold extra state that needs to be tracked for synchronization / external
      API usage.
      It's also motivated by the `pl_tex_dummy_create`, which can benefit from
      allowing users to attach their own objects to dummy textures so they
      know which one corresponds to what.
    • Niklas Haas's avatar
      gpu: add dummy pl_gpu backend · 5d0c1f8d
      Niklas Haas authored
      This is basically a software emulated `pl_gpu`, which does all
      texture/buffer operations in host memory using CPU instructions.
      Attempting to somehow soft-emulate shaders or rasterize is _way_ out of
      scope for this dumb thing, so we don't support `pl_tex_blit` or
      `pl_pass` at all. Literally the only point is to let users generate
      "faux" shaders, while keeping track of the generated LUTs etc.
    • Niklas Haas's avatar
      shaders: hide `uint8_t ident` from `pl_shader_reset` · 21d079b8
      Niklas Haas authored
      This was accidentally left exposed from a previous version of the API.
      It makes no sense in the public-facing code, so move it to the private
      Also swap the order of parameters for consistency.
    • Niklas Haas's avatar
      shaders: fix paramater name typo · 1f8956f0
      Niklas Haas authored
      This was supposed to be `index`, not `ident`. No change to semantics,
      but possibly confusing for users.
    • Niklas Haas's avatar
      gpu: clarify `initial_data` layout · 7c6dbf7c
      Niklas Haas authored
  7. 05 Jan, 2019 6 commits
    • 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.
    • 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.
    • 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
    • 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.
    • Niklas Haas's avatar
      gpu: add pl_var_int · 238e2f02
      Niklas Haas authored
      No reason not to have this, and it's useful.
    • 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
  8. 22 Dec, 2018 3 commits
    • 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.
    • 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.
    • 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.
  9. 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
    • 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
  10. 06 Dec, 2018 1 commit
    • Philip Langdale's avatar
      vulkan: add support for win32 handle types · 8dea6887
      Philip Langdale authored
      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.
  11. 05 Dec, 2018 2 commits
  12. 30 Nov, 2018 1 commit
  13. 24 Nov, 2018 6 commits
  14. 23 Nov, 2018 1 commit
  15. 21 Nov, 2018 3 commits
    • Niklas Haas's avatar
      gpu: add pl_tex_export, replacing pl_vulkan_hold_external · 5d2be6e5
      Niklas Haas authored
      This is similar to the old vulkan hold/release_external but more
      generalized and more powerful. It also cleans up some of the semantics
      related to external image interop. To avoid headaches, just delete the
      old vulkan interop code in the same commit.
      To make sure we don't keep around references to destroyed sync objects,
      we refcount them. (This also means we don't need a lazy destructor,
      since a sync object that's not in use can be destroyed immediately -
      whereas a sync object that's in use will only be deref'd when the cmd
      callback fires)
    • Philip Langdale's avatar
      gpu: add pl_sync (a semaphore pair) · b0fddcc5
      Philip Langdale authored
      This change introduces the generic definition of an exported semaphore
      pair. Such a pair can be imported by an external API for signalling and
      waiting, and will be passable to _hold() and _release() methods once
      those get introduced.
      Semaphores for internal use should just be created directly.
    • Philip Langdale's avatar
      gpu: refactor shared memory handle API · 5198e156
      Philip Langdale authored
      When we introduce exportable semaphores, we'll have handles which are
      not memory-backed. To avoid a sloppy API, let's explicitly separate the
      two ideas. This also presents an opportunity to pull the object offset
      within the memory into the mem_handle definition. We also refactor the
      way the handle caps are presented to the user, to allow distinguishing
      between caps for shared memory and those for semaphores.
      We also turn the struct pl_gpu_handle into a union, since in practice,
      it is not going to be useful to export a given resource as multiple
      types of external handle - it will just one or another type. (This is
      mostly a simple substitution, but we must also note that vk_slabs must
      also carry the handle type explicitly, as we can no longer look at which
      field(s) are set in a pl_gpu_handle.)
      This is obviously an API break for any external usage of buffers or
  16. 19 Nov, 2018 1 commit
    • Niklas Haas's avatar
      swapchain: improve latency consistency and documentation · 52c21bbc
      Niklas Haas authored
      This mirrors a similar change in mpv, which helped reduce vsync jitter
      measurements by including the time of frame acquisition in the
      `swap_buffers` call. In general, doing things this way around is nicer
      for the user. In typical swapchain implementations, it also "does the
      right thing" w.r.t actually blocking until the buffer swap.
      As a side effect of the necessary internal cache metadata, we also make
      the vulkan swapchain more robust against API misuse (especially
      out-of-order / non-lockstepped swapchain calls).
  17. 18 Nov, 2018 1 commit
    • Philip Langdale's avatar
      vulkan: Implement exporting of textures · 9d0067c4
      Philip Langdale authored
      This is analogous to the existing functionality for buffers. A
      texture may be created, requesting that it be exported. A
      texture is transitioned between external and internal use with
      pl_vulkan_hold (with export set to true) and pl_vulkan_release.
  18. 17 Nov, 2018 2 commits
    • Niklas Haas's avatar
      gpu: move pl_buffer_var from gpu.h to shaders.h · 573cf43c
      Niklas Haas authored
      This makes no real sense in gpu.h, since the pl_gpu doesn't actually
      need this information in any way. It's only needed for the shader header
      generation inside dispatch.h, so having it in shaders.h is the right
      Makes some code arguably a bit uglier, but whatever.
    • Niklas Haas's avatar
      gpu: fix typo · 7a80dfd4
      Niklas Haas authored