| Age | Commit message (Collapse) | Author |
|---|
|
Previously _LinkedShaders was a compact array of the linked shaders
for each shader stage. Now it is arranged such that each slot,
indexed by the MESA_SHADER_* defines, refers to a specific shader
stage. As a result, some slots will be NULL. This makes things a
little more complex in the linker, but it simplifies things in other
places.
As a side effect _NumLinkedShaders is removed.
NOTE: This may be a candidate for the 7.9 branch. If there are other
patches that get backported to 7.9 that use _LinkedShader, this patch
should be cherry picked also.
|
|
Also, update ir_to_mesa's "1.30 is unsupported" case to "handle" it.
|
|
|
|
This assertion was added in commit f1c1ee11, but it did not notice
that the array is accessed with 'size-1' instead of 'size'. As a
result, the assertion was off by one. This caused failures in at
least glsl-orangebook-ch06-bump.
|
|
|
|
I'm still not pleased with how builtin uniforms are handled, but as
long as we're relying on the prog_statevar stuff this seems about as
good as it'll get.
|
|
|
|
Fixes: glsl-mat-from-int-ctor-03
|
|
It turns out that most people new to this IR are surprised when an
assignment to (say) 3 components on the LHS takes 4 components on the
RHS. It also makes for quite strange IR output:
(assign (constant bool (1)) (x) (var_ref color) (swiz x (var_ref v) ))
(assign (constant bool (1)) (y) (var_ref color) (swiz yy (var_ref v) ))
(assign (constant bool (1)) (z) (var_ref color) (swiz zzz (var_ref v) ))
But even worse, even we get it wrong, as shown by this line of our
current step(float, vec4):
(assign (constant bool (1)) (w)
(var_ref t)
(expression float b2f (expression bool >=
(swiz w (var_ref x))(var_ref edge))))
where we try to assign a float to the writemasked-out x channel and
don't supply anything for the actual w channel we're writing. Drivers
right now just get lucky since ir_to_mesa spams the float value across
all the source channels of a vec4.
Instead, the RHS will now have a number of components equal to the
number of components actually being written. Hopefully this confuses
everyone less, and it also makes codegen for a scalar target simpler.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Fixes this GCC warning.
warning: missing initializer for member 'statevar_element::array_indexed'
|
|
|
|
|
|
Currently GLSL IR forbids any vector comparisons, and defines "ir_binop_equal"
and "ir_binop_nequal" to compare all elements and give a single bool.
This is highly unintuitive and prevents generation of optimal Mesa IR.
Hence, first rename "ir_binop_equal" to "ir_binop_all_equal" and
"ir_binop_nequal" to "ir_binop_any_nequal".
Second, readd "ir_binop_equal" and "ir_binop_nequal" with the same semantics
as less, lequal, etc.
Third, allow all comparisons to acts on vectors.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
|
|
|
|
This increases the chance that GLSL programs will actually work.
Note that continues and returns are not yet lowered, so linking
will just fail if not supported.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
This allows us to specify different options, especially useful for chips
without unified shaders.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Also define it if #version 100 is encountered.
|
|
Bug #30040.
|
|
This should only occur if glCompileShader is called without a prior call
to glShaderSource. An empty source program should be the empty string.
|
|
I swear there was some git option for "don't push things when you've
got uncommitted changes", but I can't find it now.
|
|
Like the constant handling and the handling of other uniforms, we add
the whole thing to the Parameters, avoiding messy, incomplete logic
for adding just the elements of a builting uniform that get used.
This means that a driver that relies only on ParameterValues[] for its
parameters will have an increased parameter load, but drivers
generally don't do that (since they have other params they need to
handle, too).
Fixes glsl-fs-statevar-call (testcase for Ember). Bug #29687.
v2: Continue referencing the STATE_VAR[] file directly when the
uniform will land in STATE_VAR[] formatted exactly as we'd put into a
temporary. When there's array dereferencing, we don't copy-propagate
in Mesa IR (not knowing where the array is in register space), so
smarts here are required or we'll massively increase the temp count.
|
|
a temp."
This reverts commit 5ad74779cea07cc6a19a52874cdaef8b018e2f1b.
Sorry, but I had to revert this.
Any commit which needlessly increases the number of temporaries is wrong.
More temporaries mean less shader performance because of reduced parallelism
and therefore less efficient latency hiding. In this case, there is possible
performance degradation of every shader which uses GL state variables.
I cannot accept this.
|
|
The downside of our talloc usage is that we can't really make static
(i.e., not created with new) instances of our IR types. This leads to
a lot of unnecessary dynamic allocation in this patch.
|
|
The CMP instruction needed to be flipped to properly handle
operand==0.
Fixes fd.o bug 29923.
|
|
Like the constant handling and the handling of other uniforms, we add
the whole thing to the Parameters, avoiding messy, incomplete logic
for adding just the elements of a builting uniform that get used.
This means that a driver that relies only on ParameterValues[] for its
parameters will have an increased parameter load, but drivers
generally don't do that (since they have other params they need to
handle, too).
Fixes glsl-fs-statevar-call (testcase for Ember). Bug #29687.
Regresses glsl-vs-array-04 on 965. Thanks to a slight change in
register allocation, this test of undefined behavior now wraps around
the register space and unexpectedly reads the constant value it's
trying to compare to. The test should probably not look at the
resulting color, since behavior is undefined.
|
|
|
|
Both i965 and swrast rely on UsesKill to determine whether to do early
depth writes. Fixes glsl-fs-discard-02.
Bug #29835.
|
|
Fixes glsl-uniform-linking-1 and failure to link a shader in Unigine.
An alternative here would be to just ditch using _mesa_add_parameter
and build the initial params list on our own, but that would require
two walks of the list as well.
Bug #29822
|
|
|
|
cond_update wasn't being set by emit_op3, leading to valgrind
complaints, and failures in several piglit tests when built with
clang.
|
|
sqrt(x) = 1/rsq(x) = x*rsq(x)
This optimization already was in the old GLSL compiler.
Acked on irc by Eric Anholt.
|
|
Addresses the warnings:
warning: ‘target’ may be used uninitialized in this function
warning: ‘target_string’ may be used uninitialized in this function
|
|
Fixes piglit glsl-fs-loop valgrind uninitialized value error on softpipe
and llvmpipe.
|
|
Fixes:
glsl-array-bounds-02 (software)
glsl-array-bounds-04
glsl-array-bounds-06 (software)
glsl-array-bounds-08
|
|
Fixes:
glsl-fs-uniform-sampler-struct
glsl-fs-sampler-numbering-3
Bug #29690
|
|
Fixes: glsl-fs-uniform-array-4.
|
|
This was in place for uniform handling, but nothing actually needs the
value now, since presence in a parameter list indicates that the
uniform was used as far as the linker was concerned.
|
|
This fixes relative addressing of temporaries (and maybe others)
in all gallium drivers.
Acked on irc by Eric Anholt.
|
|
Previously, uniform initializers were handled by ir_to_mesa as it made
its Parameters list. However, uniform values are global to all
shaders, and the value set in one Parameters list wasn't propagated to
the other gl_program->Parameters lists. By going back through the
general Mesa uniform handling, we make sure that all gl_programs get
updated values, and also successfully separate uniform initializer
handling from ir_to_mesa gl_program generation.
Fixes:
glsl-uniform-initializer-5.
|
|
The previous any() implementation would generate arg0.x || arg0.y ||
arg0.z. Having an expression operation for this makes it easy for the
backend to generate something easier (DPn + SNE for 915 FS, .any
predication on 965 VS)
|
|
Fixes: glsl-fs-any
|
|
We ended up returning CONST[loc] rather than TEMP[loc2]. Things would
*usually* end up working out OK, since the constants often ended up
getting allocated to CONST[loc..loc+columns] with no swizzle. But for
the case where the contigous temporary copy of the swizzled constant
vec4 args was actually needed, we'd end up reading some other constant
values, possibly including ones not actually allocated.
Fixes: glsl-varying-mat3x2.
|
|
The default constructor did not initialize some member variables.
|
|
|
|
|
|
Again, this is a one-element struct that was incorrectly missing the
field.
|
|
This was triggered by the previous bug, but is a separate problem
in the general sense.
|
|
According to both GLSL 1.20 and 4.0, these are a struct with one field
called "sceneColor".
Fixes a crash on loading in FlightGear.
|
