1. 13 May, 2020 1 commit
  2. 14 Nov, 2019 1 commit
  3. 28 Oct, 2019 1 commit
  4. 23 Oct, 2019 1 commit
  5. 21 Oct, 2019 1 commit
  6. 17 Oct, 2019 4 commits
  7. 10 Oct, 2019 1 commit
  8. 30 Sep, 2019 1 commit
  9. 06 Sep, 2019 1 commit
  10. 13 Aug, 2019 1 commit
    • Iago Toral's avatar
      vc4: clamp gl_PointSize to a minimum of 1.0 · 2353f7f7
      Iago Toral authored
      The OpenGL ES spec requires that the value of gl_PointSize is clamped
      to an implementation-dependent range matching what is advertised by
      GL_ALIASED_POINT_SIZE_RANGE. For VC4 this is [1.0, 512.0], but the
      hardware won't clamp to the minimum side of the range and won't render
      points with a size strictly smaller than 1.0 either, so we need to
      clamp manually. For points larger than the maximum size of the range
      the hardware clamps automatically.
      
      Fixes piglit test:
      spec/!opengl 2.0/vs-point_size-zero
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      2353f7f7
  11. 01 Jul, 2019 1 commit
  12. 05 Jun, 2019 1 commit
  13. 24 May, 2019 1 commit
  14. 10 May, 2019 1 commit
  15. 09 May, 2019 1 commit
  16. 07 May, 2019 2 commits
    • Ian Romanick's avatar
      nir: Use the flrp lowering pass instead of nir_opt_algebraic · d41cdef2
      Ian Romanick authored
      I tried to be very careful while updating all the various drivers, but I
      don't have any of that hardware for testing. :(
      
      i965 is the only platform that sets always_precise = true, and it is
      only set true for fragment shaders.  Gen4 and Gen5 both set lower_flrp32
      only for vertex shaders.  For fragment shaders, nir_op_flrp is lowered
      during code generation as a(1-c)+bc.  On all other platforms 64-bit
      nir_op_flrp and on Gen11 32-bit nir_op_flrp are lowered using the old
      nir_opt_algebraic method.
      
      No changes on any other Intel platforms.
      
      v2: Add panfrost changes.
      
      Iron Lake and GM45 had similar results. (Iron Lake shown)
      total cycles in shared programs: 188647754 -> 188647748 (<.01%)
      cycles in affected programs: 5096 -> 5090 (-0.12%)
      helped: 3
      HURT: 0
      helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
      helped stats (rel) min: 0.12% max: 0.12% x̄: 0.12% x̃: 0.12%
      Reviewed-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
      d41cdef2
    • Christian Gmeiner's avatar
      nir: nir_shader_compiler_options: drop native_integers · 4e110eca
      Christian Gmeiner authored
      Driver which do not support native integers should use a lowering
      pass to go from integers to floats.
      Signed-off-by: Christian Gmeiner's avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      4e110eca
  17. 14 Apr, 2019 1 commit
  18. 12 Apr, 2019 1 commit
  19. 10 Apr, 2019 3 commits
    • Eric Anholt's avatar
      vc4: Upload CS/VS UBO uniforms together. · afad1f7d
      Eric Anholt authored
      Same as I did for V3D, drop all this code trying to GC the
      non-indirectly-loaded uniforms from the UBO that's used for indirect
      access of gallium cb[0].  While it does successfully drop some of those,
      it came at the cost of uploading the VS's indirect unifroms twice, for the
      bin and render versions of the shader.
      
      With the UBO loads simplified, I was also able to easily backport V3D's
      change to pack a UBO offset into the uniform_data[] field so that we don't
      need to do the add of the uniform base in the shader.
      
      As a bonus, now vc4 doesn't depend on mesa/st type_size functions.
      
      total uniforms in shared programs: 25514 -> 25490 (-0.09%)
      total instructions in shared programs: 77019 -> 76836 (-0.24%)
      afad1f7d
    • Eric Anholt's avatar
      vc4: Split UBO0 and UBO1 address uniform handling. · 0204fb77
      Eric Anholt authored
      I'm going to extend how UBO0 works in a moment.
      0204fb77
    • Eric Anholt's avatar
      st: Lower uniforms in st in the !PIPE_CAP_PACKED_UNIFORMS case as well. · 771adffe
      Eric Anholt authored
      PIPE_CAP_PACKED_UNIFORMS conflates several things: Lowering uniforms i/o
      at the st level instead of the backend, packing uniforms with no padding
      at all, and lowering to UBOs.
      
      Requiring backends to lower uniforms i/o for !PIPE_CAP_PACKED_UNIFORMS
      leads to the driver needing to either link against the type size function
      in mesa/st, or duplicating it in the backend.  Given that all backends
      want this lower-io as far as I can tell, just move it to mesa/st to
      resolve the link issue and avoid the driver author needing to understand
      st's uniforms layout.
      
      Incidentally, fixes uniform layout failures in nouveau in:
      
      dEQP-GLES2.functional.shaders.struct.uniform.sampler_nested_fragment
      dEQP-GLES2.functional.shaders.struct.uniform.sampler_nested_vertex
      dEQP-GLES2.functional.shaders.struct.uniform.sampler_array_fragment
      dEQP-GLES2.functional.shaders.struct.uniform.sampler_array_vertex
      
      and I think in Lima as well.
      
      v2: fix indents
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      771adffe
  20. 09 Apr, 2019 1 commit
  21. 07 Apr, 2019 1 commit
  22. 05 Mar, 2019 1 commit
  23. 19 Jan, 2019 1 commit
  24. 08 Jan, 2019 1 commit
    • Karol Herbst's avatar
      nir: rename global/local to private/function memory · d0c6ef27
      Karol Herbst authored
      the naming is a bit confusing no matter how you look at it. Within SPIR-V
      "global" memory is memory accessible from all threads. glsl "global" memory
      normally refers to shader thread private memory declared at global scope. As
      we already use "shared" for memory shared across all thrads of a work group
      the solution where everybody could be happy with is to rename "global" to
      "private" and use "global" later for memory usually stored within system
      accessible memory (be it VRAM or system RAM if keeping SVM in mind).
      glsl "local" memory is memory only accessible within a function, while SPIR-V
      "local" memory is memory accessible within the same workgroup.
      
      v2: rename local to function as well
      v3: rename vtn_variable_mode_local as well
      Signed-off-by: Karol Herbst's avatarKarol Herbst <kherbst@redhat.com>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      d0c6ef27
  25. 17 Dec, 2018 2 commits
  26. 16 Dec, 2018 2 commits
    • Jason Ekstrand's avatar
      nir: Add a bool to int32 lowering pass · 11dc1307
      Jason Ekstrand authored
      We also enable it in all of the NIR drivers.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Bas Nieuwenhuizen's avatarBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
      Tested-by: Bas Nieuwenhuizen's avatarBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
      11dc1307
    • Jason Ekstrand's avatar
      nir: Rename Boolean-related opcodes to include 32 in the name · 80e8dfe9
      Jason Ekstrand authored
      This is a squash of a bunch of individual changes:
      
          nir/builder: Generate 32-bit bool opcodes transparently
      
          nir/algebraic: Remap Boolean opcodes to the 32-bit variant
      
          Use 32-bit opcodes in the NIR producers and optimizations
      
              Generated with a little hand-editing and the following sed commands:
      
              sed -i 's/nir_op_ball_fequal/nir_op_b32all_fequal/g' **/*.c
              sed -i 's/nir_op_bany_fnequal/nir_op_b32any_fnequal/g' **/*.c
              sed -i 's/nir_op_ball_iequal/nir_op_b32all_iequal/g' **/*.c
              sed -i 's/nir_op_bany_inequal/nir_op_b32any_inequal/g' **/*.c
              sed -i 's/nir_op_\([fiu]lt\)/nir_op_\132/g' **/*.c
              sed -i 's/nir_op_\([fiu]ge\)/nir_op_\132/g' **/*.c
              sed -i 's/nir_op_\([fiu]ne\)/nir_op_\132/g' **/*.c
              sed -i 's/nir_op_\([fiu]eq\)/nir_op_\132/g' **/*.c
              sed -i 's/nir_op_\([fi]\)ne32g/nir_op_\1neg/g' **/*.c
              sed -i 's/nir_op_bcsel/nir_op_b32csel/g' **/*.c
      
           Use 32-bit opcodes in the NIR back-ends
      
              Generated with a little hand-editing and the following sed commands:
      
              sed -i 's/nir_op_ball_fequal/nir_op_b32all_fequal/g' **/*.c
              sed -i 's/nir_op_bany_fnequal/nir_op_b32any_fnequal/g' **/*.c
              sed -i 's/nir_op_ball_iequal/nir_op_b32all_iequal/g' **/*.c
              sed -i 's/nir_op_bany_inequal/nir_op_b32any_inequal/g' **/*.c
              sed -i 's/nir_op_\([fiu]lt\)/nir_op_\132/g' **/*.c
              sed -i 's/nir_op_\([fiu]ge\)/nir_op_\132/g' **/*.c
              sed -i 's/nir_op_\([fiu]ne\)/nir_op_\132/g' **/*.c
              sed -i 's/nir_op_\([fiu]eq\)/nir_op_\132/g' **/*.c
              sed -i 's/nir_op_\([fi]\)ne32g/nir_op_\1neg/g' **/*.c
              sed -i 's/nir_op_bcsel/nir_op_b32csel/g' **/*.c
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Bas Nieuwenhuizen's avatarBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
      Tested-by: Bas Nieuwenhuizen's avatarBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
      80e8dfe9
  27. 05 Dec, 2018 1 commit
  28. 19 Nov, 2018 1 commit
    • Kenneth Graunke's avatar
      nir: Make nir_lower_clip_vs optionally work with variables. · 5b682143
      Kenneth Graunke authored
      The way nir_lower_clip_vs() works with store_output intrinsics makes a
      ton of assumptions about the driver_location field.
      
      In i965 and iris, I'd rather do this lowering early and work with
      variables.  v3d may want to switch to that as well, and ir3 could too,
      but I'm not sure exactly what would need updating.  For now, handle
      both methods.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      5b682143
  29. 30 Oct, 2018 1 commit
  30. 25 Oct, 2018 1 commit
  31. 16 Oct, 2018 1 commit
  32. 22 Sep, 2018 1 commit