1. 10 Dec, 2018 2 commits
  2. 07 Dec, 2018 4 commits
  3. 06 Dec, 2018 9 commits
    • Niklas Haas's avatar
      vulkan: explicitly query supported semaphore handle types · a3e1c43d
      Niklas Haas authored
      Mercifully much easier than buffers/images
    • Niklas Haas's avatar
      malloc: determine the set of supported handles by trial · ec190ee7
      Niklas Haas authored
      Just try asking the driver if it would be okay with a TRANSFER_DST
      buffer for this handle type. If tha fails, so should certainly
      everything else.
      Unfortunately, we have no good way of testing which handle types are
      supported for images. We could also use trials here, but we don't really
      distinguish between images and buffers at all in the pl_gpu.handle_caps.
      Hopefully this should normally either be supported for both buffers and
      images, or for neither. It's probably best the user just relies on
      `pl_tex_create` failing in environments where buffers are supported but
      images are not.
    • Niklas Haas's avatar
      vulkan: enforce image format compatibility with handle type · 6c29d3e1
      Niklas Haas authored
      Similar to the previous commit, we need to ensure compatibility with the
      handle type we are interested in to avoid UB.
      Also rewrite the image format compatibility check logic in general to
      make it more future-proof. Also fixes a few memleaks on error (due to
      `return NULL` when it should have done `goto error`).
    • Niklas Haas's avatar
      vulkan: ensure compatibility of buffer handle types · 61b7ec94
      Niklas Haas authored
      Spec says we need to test for compatibility with vkGet*BufferProps
      before creating the VkBuffer, else it's undefined behavior - the driver
      won't signal incompatible handle types by buffer creation failure.
    • Niklas Haas's avatar
      vulkan: add support for loading instance-level functions · bc7fce86
      Niklas Haas authored
      After postponing this issue previously because we had no permanent
      context associated with user-provided instances, and no way of
      retroactively knowing what instance-level extensions were provided, the
      solution hit me on the head:
      We can just load them as part of the device-level extensions that depend
      on them. Duplicates in this list don't matter, since loading the same
      pointer twice is idempotent.
    • Niklas Haas's avatar
      vulkan: reduce handle_type boilerplate · aff6b549
      Niklas Haas authored
      There were a bunch of disjointed switch statements all over the place.
      Reduce these in favor of one helper function, since we'll end up needing
      this more as we go on.
    • Philip Langdale's avatar
      tests: add coverage for win32 handle types · 3a70f258
      Philip Langdale authored
      No idea if this actually works, but perhaps we'll find out.
      If you wanted the test to run and pass on windows 7, you'd
      presumably not want the NT Handle test to run.
    • 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.
    • Niklas Haas's avatar
      bstr: rename subproject lib · 08b45ede
      Niklas Haas authored
      This was still called 'lib3rdparty' from a previous iteration of the
      meson subprojects refactor.
  4. 05 Dec, 2018 12 commits
  5. 04 Dec, 2018 4 commits
  6. 02 Dec, 2018 4 commits
    • Niklas Haas's avatar
      ta: assert successful list delink · 8f41c6c5
      Niklas Haas authored
      ta_free ends up inadvertently modifying eh->children.next as part of
      unlinking that value itself from teh linked list. But, clang doesn't
      understand this - to clang, it looks as though we're freeing the same
      value over and over again. Add a simple assertion to convince clang that
      this is actually a different pointer.
    • Niklas Haas's avatar
      ta: assert linked list to make clang scan-build happy · 8a8b1c63
      Niklas Haas authored
      This is a doubly linked list that gets initialized with the cycles
      pointing to themselves - so leak_next/prev are never NULL. But, clang
      doesn't know this, so teach it.
    • Niklas Haas's avatar
      talloc: add assertion to make clang scan-build happy · 3a663e94
      Niklas Haas authored
      It doesn't understand that TARRAY_GROW never returns NULL, so teach it.
    • Niklas Haas's avatar
      lcms: assert s_r, s_g, s_b > 1 · f3b3251b
      Niklas Haas authored
      Turns out clang was right in warnung us about the possible division by
      zero: we only asserted > 0, but > 1 is the minimum assertion needed to
      make the code safe.
  7. 30 Nov, 2018 5 commits