- 05 Nov, 2020 3 commits
-
-
Erik Faye-Lund authored
Now that we're using the right variable-mode, this is the same, and prepares us a bit more for the future where all variables will be in the same list.
-
Erik Faye-Lund authored
The variable here gets added to the nir_shader::system_values list rather than the nir_shader::inputs list, so it should have the nir_var_system_value variable mode instead of nir_var_shader_in. Not doing this will have horrible consequences when rebasing on upstream, because all of these variables will be stored in the same list there. This means the variable-mode is the only detail left to let us know what this is.
-
Erik Faye-Lund authored
-
- 03 Nov, 2020 3 commits
-
-
Erik Faye-Lund authored
-
Erik Faye-Lund authored
-
Erik Faye-Lund authored
-
- 02 Nov, 2020 4 commits
-
-
Erik Faye-Lund authored
When we expose this without exposing SSBOs, gallium gets confused and tries to use SSBOs for atomic operations, even if we explicitly suppory zero buffers.
-
Erik Faye-Lund authored
-
Connor Abbott authored
The st now does this for us. Part-of: <mesa/mesa!4732>
-
Connor Abbott authored
This was trying to emulate the effect of mapping GL -> TGSI -> NIR, but failed to handle VARYING_SLOT_PNTC which led to a kludgy workaround in freedreno. Part-of: <mesa/mesa!4732>
-
- 28 Oct, 2020 30 commits
-
-
Jesse Natalie authored
-
Erik Faye-Lund authored
-
Erik Faye-Lund authored
-
Erik Faye-Lund authored
-
Erik Faye-Lund authored
-
Erik Faye-Lund authored
If we don't use the pre-draw flag here, we won't end up transitioning these until some time after the draw, which isn't what we want.
-
Erik Faye-Lund authored
These flags are never set, so let's simplify the logic a bit here.
-
Erik Faye-Lund authored
This gets rid of some repeated code.
-
Louis-Francis Ratté-Boulianne authored
-
Louis-Francis Ratté-Boulianne authored
-
Louis-Francis Ratté-Boulianne authored
-
Louis-Francis Ratté-Boulianne authored
-
Jesse Natalie authored
-
Jesse Natalie authored
-
Jesse Natalie authored
-
Jesse Natalie authored
This is necessary to avoid having derefs with uniform mode, which lower_explicit_io would turn into address computations.
-
Jesse Natalie authored
-
Jesse Natalie authored
-
Jesse Natalie authored
-
Jesse Natalie authored
-
Jesse Natalie authored
-
Jesse Natalie authored
-
Jesse Natalie authored
-
Jesse Natalie authored
-
Jason Ekstrand authored
The OpenCL image_width/height/depth functions have variants which can take an LOD parameter. More importantly, LLVM-SPIRV-Translator always generates OpImageQuerySizeLod even if the LOD is guaranteed to be zero. Given that over half the hardware out there has an LOD field for image size queries (based on a rudimentary scan through their NIR -> whatever code), we may as well just add the source to the NIR intrinsic. If this is ever a problem for anyone, the lowering is pretty trivial. I've also added asserts to everyone's drivers that should alert them if they ever see an LOD other than zero. This will never happen with GL or Vulkan so there's no need for panic. Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org>
-
Jesse Natalie authored
This reverts commit d9d4a1ae.
-
Jesse Natalie authored
Delete unintentionally left debugging code
-
Jesse Natalie authored
-
Jesse Natalie authored
-
Jesse Natalie authored
-