1. 21 Aug, 2019 1 commit
  2. 12 Jun, 2019 1 commit
    • Nicolai Hähnle's avatar
      u_dynarray: turn util_dynarray_{grow, resize} into element-oriented macros · de8a9197
      Nicolai Hähnle authored
      The main motivation for this change is API ergonomics: most operations
      on dynarrays are really on elements, not on bytes, so it's weird to have
      grow and resize as the odd operations out.
      
      The secondary motivation is memory safety. Users of the old byte-oriented
      functions would often multiply a number of elements with the element size,
      which could overflow, and checking for overflow is tedious.
      
      With this change, we only need to implement the overflow checks once.
      The checks are cheap: since eltsize is a compile-time constant and the
      functions should be inlined, they only add a single comparison and an
      unlikely branch.
      
      v2:
      - ensure operations are no-op when allocation fails
      - in util_dynarray_clone, call resize_bytes with a compile-time constant element size
      
      v3:
      - fix iris, lima, panfrost
      Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
      de8a9197
  3. 08 Nov, 2018 1 commit
  4. 25 Oct, 2018 1 commit
  5. 23 Jul, 2018 1 commit
    • Jason Ekstrand's avatar
      intel/compiler: Account for built-in uniforms in analyze_ubo_ranges · 820d5e51
      Jason Ekstrand authored
      The original pass only looked for load_uniform intrinsics but there are
      a number of other places that could end up loading a push constant.  One
      obvious omission was images which always implicitly use a push constant.
      Legacy VS clip planes also get pushed into the shader.  This fixes some
      new Vulkan CTS tests that test random combinations of bindings and, in
      particular, test lots of UBOs and images together.
      
      Cc: mesa-stable@lists.freedesktop.org
      Cc: Kenneth Graunke <kenneth@whitecape.org>
      820d5e51
  6. 14 Jun, 2018 1 commit
    • Kenneth Graunke's avatar
      intel/compiler: Properly consider UBO loads that cross 32B boundaries. · f6898f2b
      Kenneth Graunke authored
      The UBO push analysis pass incorrectly assumed that all values would fit
      within a 32B chunk, and only recorded a bit for the 32B chunk containing
      the starting offset.
      
      For example, if a UBO contained the following, tightly packed:
      
         vec4 a;  // [0, 16)
         float b; // [16, 20)
         vec4 c;  // [20, 36)
      
      then, c would start at offset 20 / 32 = 0 and end at 36 / 32 = 1,
      which means that we ought to record two 32B chunks in the bitfield.
      
      Similarly, dvec4s would suffer from the same problem.
      
      v2: Rewrite the accounting, my calculations were wrong.
      v3: Write a comment about partial values (requested by Jason).
      
      Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com> [v1]
      Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> [v3]
      f6898f2b
  7. 13 Jun, 2018 2 commits
  8. 10 Feb, 2018 1 commit
  9. 20 Oct, 2017 1 commit
  10. 14 Jul, 2017 1 commit
    • Kenneth Graunke's avatar
      i965: Select ranges of UBO data to be uploaded as push constants. · 6d28c6e5
      Kenneth Graunke authored
      This adds a NIR pass that decides which portions of UBOS we should
      upload as push constants, rather than pull constants.
      
      v2: Switch to uint16_t for the UBO block number, because we may
          have a lot of them in Vulkan (suggested by Jason).  Add more
          comments about bitfield trickery (requested by Matt).
      
      v3: Skip vec4 stages for now...I haven't finished wiring up support
          in the vec4 backend, and so pushing the data but not using it
          will just be wasteful.
      Reviewed-by: default avatarMatt Turner <mattst88@gmail.com>
      6d28c6e5