1. 19 Feb, 2020 1 commit
    • Danylo Piliaiev's avatar
      intel/compiler: Do not qsort zero sized array · d5931f28
      Danylo Piliaiev authored
      ../src/intel/compiler/brw_nir_analyze_ubo_ranges.c:316:4: runtime error: null pointer passed as argument 1, which is declared to never be null
          #0 0x7f78f5916611 in brw_nir_analyze_ubo_ranges ../src/intel/compiler/brw_nir_analyze_ubo_ranges.c:316
          #1 0x7f78f255c189 in brw_codegen_wm_prog ../src/mesa/drivers/dri/i965/brw_wm.c:97
          #2 0x7f78f2565571 in brw_fs_precompile ../src/mesa/drivers/dri/i965/brw_wm.c:608
          #3 0x7f78f24edd2c in brw_shader_precompile ../src/mesa/drivers/dri/i965/brw_link.cpp:56
          #4 0x7f78f24f3af8 in brw_link_shader ../src/mesa/drivers/dri/i965/brw_link.cpp:381
          #5 0x7f78f39a302a in _mesa_glsl_link_shader ../src/mesa/program/ir_to_mesa.cpp:3119
          #6 0x7f78f3a43826 in create_new_program ../src/mesa/main/ff_fragment_shader.cpp:1133
          #7 0x7f78f3a43d00 in _mesa_get_fixed_func_fragment_program ../src/mesa/main/ff_fragment_shader.cpp:1163
          #8 0x7f78f325ddcd in update_program ../src/mesa/main/state.c:134
          #9 0x7f78f325fe64 in _mesa_update_state_locked ../src/mesa/main/state.c:360
          #10 0x7f78f32600f1 in _mesa_update_state ../src/mesa/main/state.c:394
          #11 0x7f78f2b3e587 in clear ../src/mesa/main/clear.c:169
          #12 0x7f78f2b3e587 in _mesa_Clear ../src/mesa/main/clear.c:242
      Signed-off-by: default avatarDanylo Piliaiev <danylo.piliaiev@globallogic.com>
      Reviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3825>
  2. 21 Aug, 2019 1 commit
  3. 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.
      - ensure operations are no-op when allocation fails
      - in util_dynarray_clone, call resize_bytes with a compile-time constant element size
      - fix iris, lima, panfrost
      Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
  4. 08 Nov, 2018 1 commit
  5. 25 Oct, 2018 1 commit
  6. 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>
  7. 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]
  8. 13 Jun, 2018 2 commits
  9. 10 Feb, 2018 1 commit
  10. 20 Oct, 2017 1 commit
  11. 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>