1. 28 Jan, 2019 8 commits
  2. 27 Jan, 2019 17 commits
    • Timothy Arceri's avatar
      radv/ac: fix some fp16 handling · 0907ae35
      Timothy Arceri authored
      Fixes: b722b29f ("radv: add support for 16bit input/output")
      Reviewed-by: Bas Nieuwenhuizen's avatarBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
    • Eric Anholt's avatar
      v3d: Create separate sampler states for the various blend formats. · c496b60e
      Eric Anholt authored
      The sampler border color is encoded in the TMU's blending format (half
      floats, 32-bit floats, or integers) and must be clamped to the format's
      range unorm/snorm/int ranges by the driver.  Additionally, the TMU doesn't
      know about how we're abusing the swizzle to support BGRA, A, and LA, so we
      have to pre-swizzle the border color for those.
      We don't really want to spend half a kb on sampler states in most cases,
      so skip generating the variants when the border color is unused or is
    • Eric Anholt's avatar
      v3d: Move the sampler state to the long-lived state uploader. · 5fe4250a
      Eric Anholt authored
      Samplers are small (8-24 bytes), so allocating 4k for them is a huge
    • Eric Anholt's avatar
    • Eric Anholt's avatar
      v3d: Fix stencil sampling from a separate-stencil buffer. · c51d125d
      Eric Anholt authored
      When the sampler view is in sample-stencil mode, we need to return uint
      stencil values.  To do that, fill in the format table to return R8I, and
      have the sampler view point at the separate stencil buffer.
      Fixes dEQP-GLES31.functional.stencil_texturing.format.depth32f_stencil8_2d
    • Eric Anholt's avatar
      v3d: Fix stencil sampling from packed depth/stencil. · 8a0b0a8f
      Eric Anholt authored
      We need to pick the 8-bit unorm value out, not the depth component.
    • Eric Anholt's avatar
    • Eric Anholt's avatar
      v3d: Flush blit jobs immediately after generating them. · edb1fcd9
      Eric Anholt authored
      Fixes OOMs in the CTS's packed_pixels.varied_rectangle.* tests -- the
      series of texture uploads at the start before texturing occurred would end
      up all sitting around as cached jobs for reuse.  By flushing immediately,
      peak active BO usage goes from 150M to 40M.
      We could maybe put some limits on how many jobs we keep around, but blits
      seem particularly unlikely to get reused for other drawing.
    • Eric Anholt's avatar
    • Eric Anholt's avatar
      v3d: Drop maximum number of texture units down to 16. · 060575be
      Eric Anholt authored
      This is the GLES 3.2 minmax, and also what the closed source driver does.
      Avoids hitting OOMs in the CTS's
    • Eric Anholt's avatar
      v3d: Avoid duplicating limits defines between gallium and v3d core. · 3e743d8c
      Eric Anholt authored
      We don't want to pull the compiler into every include in the gallium
      driver, so just make a new little header to store the limits.
    • Eric Anholt's avatar
      v3d: Fix overly-large vattr_sizes structs. · fe6a21c8
      Eric Anholt authored
      We want one vector size per vector, not per component.
    • Eric Anholt's avatar
      v3d: Rename gallium-local limits defines from VC5 to V3D. · 533b3f05
      Eric Anholt authored
      The compiler has its limits under V3D_* (like most V3D stuff), so sync up
      with that.
    • Bas Nieuwenhuizen's avatar
      radv: Remove unused variable. · b4870a15
      Bas Nieuwenhuizen authored
    • Niklas Haas's avatar
      radv: add device->instance extension dependencies · 804cc44d
      Niklas Haas authored
      From the vulkan spec 33.3 "Extension Dependencies":
      "Any device extension that has an instance extension dependency that is
      not enabled by vkCreateInstance is considered to be unsupported, hence
      it must not be returned by vkEnumerateDeviceExtensionProperties for any
      VkPhysicalDevice child of the instance."
      Therefore we need to check whether the instance-level extensions are
      actually enabled when deciding to support a device-level extension or
      Furthermore, we need to do this for all instance-level extensions of any
      (transitive) device-level extension dependency, due to the following
      "If an extension is supported (as queried by
      vkEnumerateInstanceExtensionProperties or
      vkEnumerateDeviceExtensionProperties), then required extensions of that
      extension must also be supported for the same instance or physical
      Finally, because some of these vulkan extensions may be implicitly
      promoted to future vulkan core API versions, we can also satisfy the
      dependency if the vulkan API version is high enough.
      Reviewed-by: Bas Nieuwenhuizen's avatarBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
    • Niklas Haas's avatar
      radv: correctly use vulkan 1.0 by default · d12dc393
      Niklas Haas authored
      From the vulkan spec 3.2 "Instances":
      "Providing a NULL VkInstanceCreateInfo::pApplicationInfo or providing an
      apiVersion of 0 is equivalent to providing an apiVersion of
      Fixes: ffa15861 "radv: UseEnumerateInstanceVersion for the default version."
      Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric.engestrom@intel.com>
      Reviewed-by: Bas Nieuwenhuizen's avatarBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
    • Niklas Haas's avatar
      glsl: fix block member alignment validation for vec3 · d9bd3b1c
      Niklas Haas authored
      Section (Standard Uniform Block Layout) of the GL spec says:
          The base offset of the first member of a structure is taken from the
          aligned offset of the structure itself. The base offset of all other
          structure members is derived by taking the offset of the last basic
          machine unit consumed by the previous member and adding one.
      The current code does not reflect this last sentence - it effectively
      instead aligns up the next offset up to the alignment of the previous
      member. This causes an issue in exactly one case:
      layout(std140) uniform block {
          layout(offset=0) vec3 var1;
          layout(offset=12) float var2;
      As per section (Uniform Buffer Object Storage) and elsewhere, a
      vec3 consumes 3 floats, i.e. 12 basic machine units. Therefore, `var1`
      in the example above consumes units 0-11, with 12 being the first
      available offset afterwards. However, before this commit, mesa
      incorrectly assumes `var2` must start at offset=16 when using explicit
      offsets, which results in a compile-time error. Without explicit
      offsets, the shaders actually work fine, indicating that mesa is already
      correctly aligning these fields internally. (Just not in the code that
      handles explicit buffer offset parsing)
      This patch should fix piglit tests:
      Signed-off-by: default avatarNiklas Haas <git@haasn.xyz>
      Reviewed-by: Ilia Mirkin's avatarIlia Mirkin <imirkin@alum.mit.edu>
  3. 26 Jan, 2019 15 commits