1. 08 Feb, 2020 2 commits
  2. 07 Feb, 2020 11 commits
  3. 06 Feb, 2020 6 commits
  4. 05 Feb, 2020 9 commits
  5. 04 Feb, 2020 12 commits
    • Lynne's avatar
      lavfi: bump minor version for the Vulkan filters · a71a5d92
      Lynne authored
      a71a5d92
    • Lynne's avatar
      doc/APIchanges: update with Vulkan commit info · ee81713f
      Lynne authored
      ee81713f
    • Lynne's avatar
      lavu: bump minor version for the Vulkan patchset · 73a8c8e6
      Lynne authored
      73a8c8e6
    • Philip Langdale's avatar
      lavu/hwcontext_cuda: refactor context initialisation · 7f149b04
      Philip Langdale authored
      There's enough going on here now that it should not be duplicated
      between cuda_device_create and cuda_device_derive.
      7f149b04
    • Lynne's avatar
      lavfi: add an chromaber_vulkan filter · 907ae87d
      Lynne authored
      This commit adds a chromatic aberration filter for Vulkan that attempts to
      emulate a lens chromatic aberration effect.
      For a YUV frame it will instead shift the chroma channels, providing a
      simple approximation.
      907ae87d
    • Lynne's avatar
      lavfi: add an avgblur_vulkan filter · a2db7343
      Lynne authored
      This commit adds a fast avgblur Vulkan filter.
      This will reset Intel GPUs on Linux due to a known, two-year-old driver bug
      (!834 on mesa's gitlab).
      a2db7343
    • Lynne's avatar
      lavfi: add an overlay_vulkan filter · 7bb44313
      Lynne authored
      This commit adds a basic, non-converting overlay filter for Vulkan.
      7bb44313
    • Lynne's avatar
      lavfi: add an scale_vulkan filter · d95c509c
      Lynne authored
      This commit adds a basic, non-converting Vulkan scaling filter.
      d95c509c
    • Lynne's avatar
      lavfi: add Vulkan filtering framework · 6fca61bb
      Lynne authored
      This commit adds a Vulkan filtering infrastructure for libavfilter.
      It attempts to abstract as much as possible of the Vulkan API from filters.
      
      The way the hwcontext and the framework are designed permits for parallel,
      non-CPU-blocking filtering throughout, with the exception of up/downloading
      and mapping.
      6fca61bb
    • Philip Langdale's avatar
      lavfi/vf_hwupload: Add support for HW -> HW transfers · 88d2ccbe
      Philip Langdale authored
      As we find ourselves wanting a way to transfer frames between
      HW devices (or more realistically, between APIs on the same device),
      it's desirable to have a way to describe the relationship. While
      we could imagine introducing a `hwtransfer` filter, there is
      almost no difference from `hwupload`. The main new feature we need
      is a way to specify the target device. Having a single device
      for the filter chain is obviously insufficient if we're dealing
      with two devices.
      
      So let's add a way to specify the upload target device, and if none
      is specified, continue with the existing behaviour.
      
      We must also correctly preserve the sw_format on such a transfer.
      88d2ccbe
    • Lynne's avatar
      lavu: add Vulkan hwcontext code · a88449ff
      Lynne authored
      This commit adds the necessary code to initialize and use a Vulkan device
      within the hwcontext libavutil framework.
      Currently direct mapping to VAAPI and DRM frames is functional, and
      transfers to CUDA and native frames are supported.
      
      Lets hope the future Vulkan video decode extension fits well within this
      framework.
      a88449ff
    • Philip Langdale's avatar
      lavu/hwcontext: Add support for HW -> HW transfers · d7210ce7
      Philip Langdale authored
      We are beginning to consider scenarios where a given HW Context
      may be able to transfer frames to another HW Context without
      passing via system memory - this would usually be when two
      contexts represent different APIs on the same device (eg: Vulkan
      and CUDA).
      
      This is modelled as a transfer, as we have today, but where both
      the src and the dst are hardware frames with hw contexts. We need
      to be careful to ensure the contexts are compatible - particularly,
      we cannot do transfers where one of the frames has been mapped via
      a derived frames context - we can only do transfers for frames that
      were directly allocated by the specified context.
      
      Additionally, as we have two hardware contexts, the transfer function
      could be implemented by either (or indeed both). To handle this
      uncertainty, we explicitly look for ENOSYS as an indicator to try
      the transfer in the other direction before giving up.
      d7210ce7