1. 05 Jan, 2019 2 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.
      3294a29e
    • Niklas Haas's avatar
      gpu: add pl_var_int · 238e2f02
      Niklas Haas authored
      No reason not to have this, and it's useful.
      238e2f02
  2. 22 Dec, 2018 2 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.
      b38e65cc
    • 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
  3. 21 Dec, 2018 1 commit
    • 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
  4. 30 Nov, 2018 1 commit
  5. 24 Nov, 2018 1 commit
  6. 21 Nov, 2018 3 commits
    • 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.
      b0fddcc5
    • 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
      textures.
      5198e156
    • Philip Langdale's avatar
      gpu: assert texture ext_handles are supported by gpu caps · a07caf54
      Philip Langdale authored
      I missed this assertion when I added support for exportable textures.
      a07caf54
  7. 17 Nov, 2018 1 commit
    • 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
      place.
      
      Makes some code arguably a bit uglier, but whatever.
      573cf43c
  8. 16 Nov, 2018 1 commit
    • Niklas Haas's avatar
      gpu: drop the dynamic ubo/ssbo/pushc layouts · 51379b3f
      Niklas Haas authored
      Ever since SPIRV-Cross has started emulating std140 layout when
      cross-compiling SPIR-V to D3D11, there's no more real justification for
      us to make this dependent on the backend type.
      
      In theory, metal could require something different here - but even then
      we should work around it in SPIRV-Cross rather than trying to make our
      code depend on it at runtime.
      51379b3f
  9. 04 Nov, 2018 3 commits
  10. 30 Oct, 2018 1 commit
  11. 27 Oct, 2018 1 commit
  12. 26 Oct, 2018 3 commits
  13. 25 Oct, 2018 1 commit
    • Niklas Haas's avatar
      gpu: add pl_gpu_finish · 2e742f53
      Niklas Haas authored
      Much like glFinish, this can be useful when you want to force all GPU
      work to be completed (for any number of reasons, e.g. deinit logic or
      for benchmarking purposes).
      2e742f53
  14. 28 Sep, 2018 1 commit
    • Niklas Haas's avatar
      dispatch: fix std140/std430 packing rules · e6a3f6f0
      Niklas Haas authored
      Actually, turns out our rules were wrong after all: vec3 only consumes 3
      words even though it's aligned to 4, which we were not correctly
      accounting for.
      
      So in the struct { vec3; float; vec2 } the float and vec3 can be packed
      into the same vec4, whereas our code was assuming the vec3 consumed all
      four words (like its alignment).
      e6a3f6f0
  15. 27 Sep, 2018 1 commit
    • Niklas Haas's avatar
      dispatch: rework the shader identification mechanism · 5cbcbcec
      Niklas Haas authored
      Rather than having the uint8_t be public, which makes little sense with
      no public way to merge shaders (sh_subpass is private), just add an
      internal _ex function for the (relatively few) cases where we actually
      need this merging stuff.
      
      For the most cases, we can just always use identifier 0, this also gives
      us better caching for stuff like OSD passes etc.
      5cbcbcec
  16. 28 May, 2018 1 commit
  17. 20 May, 2018 1 commit
    • Niklas Haas's avatar
      vulkan: correctly align texture transfer buffer offsets · 94e0ba67
      Niklas Haas authored
      These need to be aligned to the texel size as well, rather than just
      being a multiple of 4. Document and assert this fact for the user-facing
      field.
      
      We also need to make sure to align PL_BUF_TEX_TRANSFER buffers' memory
      offsets ahead of time, so just use the LCM of all supported texture
      formats in order to ensure we always get a valid allocation.
      
      In addition to this, I also realized that PL_ALIGN cannot be used to
      combine multiple non-PoT alignment requirements. So just define and use
      `pl_lcm` (which we need anyway) to be on the safe side.
      94e0ba67
  18. 10 Mar, 2018 2 commits
    • Niklas Haas's avatar
      gpu: change semantics of pl_tex_transfer_params.stride_w/h · a81d22de
      Niklas Haas authored
      Instead of inferring these from the image size, infer them from the rect
      to be transferred. This is the more common convention. Annoyingly, this
      is a rather subtle API break, but I expect all existing users to be
      unaffected since in all common cases it doesn't change a thing.
      a81d22de
    • Niklas Haas's avatar
      gpu: relax the pl_tex_transfer size requirements · 0a892546
      Niklas Haas authored
      In cases where the stride exceeds the rect being transferred, the
      existing rules could also include superfluous padding as part of the
      transfer size requirements. But this is unnecessary, strictly speaking.
      0a892546
  19. 26 Feb, 2018 1 commit
    • Niklas Haas's avatar
      gpu: be more explicit about GPU limit types · e3f1813d
      Niklas Haas authored
      Give them explicit size information and make them unsigned where it
      matters. This solves an issue where platforms setting one or more of
      these limits as UINT32_MAX would end up overflowing to (-1) due to the
      representation as `int`.
      
      Now the valid value range is a more explicit part of the API semantics,
      with GPU implementations being required to convert and clamp as needed.
      
      As an aside, also log the missing field max_buffer_texels.
      e3f1813d
  20. 15 Feb, 2018 1 commit
  21. 08 Feb, 2018 6 commits
  22. 02 Feb, 2018 2 commits
    • Niklas Haas's avatar
      gpu: increase pl_tex_recreate verbosity · 03b818d7
      Niklas Haas authored
      Since we use this more aggressively now
      03b818d7
    • Niklas Haas's avatar
      ra: rename ra to pl_gpu, change ra_ to pl_ · 3e881060
      Niklas Haas authored
      This is a very major rewrite operation, but all of the actual logic is
      unaffected. The change is completely cosmetic.
      
      The idea behind this is to avoid clashing the mpv ra_ namespace when
      libplacebo eventually makes its way back into mpv, allowing it to
      coexist with vo_gpu peacefully (at least for the transition period).
      
      It's also sort of weirdly inconsistent with the rest of libplacebo
      anyway.
      3e881060
  23. 01 Feb, 2018 1 commit
  24. 25 Jan, 2018 1 commit
    • Niklas Haas's avatar
      dispatch: implement support for blending · 0f518e7e
      Niklas Haas authored
      I also made some RA changes for convenience, so we can pass around the
      blending configuration as a single struct.
      
      I also implemented blending emulation for compute shaders.
      0f518e7e
  25. 16 Jan, 2018 1 commit
    • Niklas Haas's avatar
      ra: fix bounds checks on ra_tex_blit · a1198f4b
      Niklas Haas authored
      These were invalid for 1D/2D textures. Also add another check to make
      sure we aren't blitting from a higher-dimensional texture to a
      lower-dimensional one.
      a1198f4b