- Copy i915c's support for phases, that should allow us to run a coupe more shaders.
- Fix the error messages.
- Still try to proceed when we get a shader that's too long.
MOD_TO_FRACT was designed to lower the GLSL 1.20 mod() function, which
operates on floating point values. However, we also use ir_binop_mod
for GLSL 1.30's % operator, which operates on integers.
For now, make MOD_TO_FRACT only apply to floating-point mod operations.
In the future, we may want to add a lowering pass for integer-based mod.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
f2i results in an int/ivec; we need i2u to get a uint/uvec.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously, it would simply say "type error" in three different cases:
- The LHS is not an integer
- The RHS is not an integer
- The LHS and RHS have different base types (int vs. uint)
Now the error messages state the specific problem.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously, ir_function::matching_signature had a fatal bug: if a
function had more than one non-exact match, it would simply return NULL.
This occured, for example, when looking for max(uvec3, uvec3):
- max(vec3, vec3) -> score 1 (found first)
- max(ivec3, ivec3) -> score 1 (found second...used to return NULL here)
- max(uvec3, uvec3) -> score 0 (exact match...the right answer)
This did not occur for max(ivec3, ivec3) since the second match found
was an exact match.
The new behavior is to return a match with the lowest score. If there
is an exact match, that will be returned. Otherwise, a match with the
least number of implicit conversions is chosen.
Fixes piglit tests max-uvec3.vert and glsl-inexact-overloads.shader_test.
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
No MOV is necessary since signed/unsigned integers share the same
bit-representation; it's simply a question of interpretation. In
particular, the fs_reg::imm union shouldn't need updating.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Mesa IR actually stores all numbers as floating point, so this is
totally a farce, but we may as well keep it going.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reverts commit f41e1db327
"fix conversions from uint to bool and from float/bool to uint"
f2i, b2i, and b2i should not accept uint types. Use i2u and u2i.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
These are necessary to handle int/uint constructor conversions. For
example, the following code currently results in a type mismatch:
int x = 7;
uint y = uint(x);
In particular, uint(x) still has type int.
This commit simply adds the new operations; it does not generate them,
nor does it add backend support for them.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
We almost never want to specify a condition, and when we do we're
already thinking about it (because we're writing a lowering pass
generating the condition), so a default argument should make the code
more pleasant to read.
NOTE: This is a candidate for the 7.11 branch (we want to be able to
cherry-pick future code).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Our copy propagation tends to be bad at handling the later array
accesses of the matrix argument we moved to a temporary. Generally we
don't need to move it to a temporary, though, so this avoids needing
more copy propagation complexity.
Reduces instruction count of some Unigine Tropics and Sanctuary
fragment shaders that do operations on uniform matrix arrays by 5.9%
on gen6.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were constrained to using temporaries because we were assuming
variables all over. This simplifies things a bit.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This awkward typing was to avoid shadowing the function argument (the
matrix) with the temporary deref (the column) before the
get_column()/get_element()s were moved into the expression/assignment
constructors. They're about to become not-variables, so the current
names had to go. This change is almost mechanical (other than
column_expr), so it should make the next diff clearer.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I think this makes the code more obvious by moving the declarations to
their single usage (now that we aren't using them to get at the ->type
field for expression constructors).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Move defintion of M_PI (for the benefit of <math.h> which do not define it), to
before the first use of it
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Brian Paul <brianp@vmware.com>
Commit 1a339b6c(st/mesa: prefer native texture formats when possible)
introduced two new arguments to the st_choose_format() functions.
This patch fixes the order and passes the correct internal_target
rather than GL_NONE
NOTE: This is a candidate for the 7.11 branch
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
The api and the state tracker manager code as well as the state tracker code
assumed that only a single context could be bound to a drawable. That is not
a valid assumption, since multiple contexts can bind to the same drawable.
Fix this by making it the state tracker's responsibility to update all
contexts binding to a drawable
Note that the state trackers themselves don't use atomic stamps on
frame-buffers. Multiple context rendering to the same drawable should
be protected by the application.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Instead of using a chain of manually maintained if/else blocks to
handle "#extension" directives, we now consult a table that specifies,
for each extension, the circumstances under which it is available, and
what flags in _mesa_glsl_parse_state need to be set in order to
activate it.
This makes it easier to add new GLSL extensions in the future, and
fixes the following bugs:
- Previously, _mesa_glsl_process_extension would sometimes set the
"_enable" and "_warn" flags for an extension before checking whether
the extension was supported by the driver; as a result, specifying
"enable" behavior for an unsupported extension would sometimes cause
front-end support for that extension to be switched on in spite of
the fact that back-end support was not available, leading to strange
failures, such as those in
https://bugs.freedesktop.org/show_bug.cgi?id=38015.
- "#extension all: warn" and "#extension all: disable" had no effect.
Notes:
- All extensions are currently marked as unavailable in geometry
shaders. This should not have any adverse effects since geometry
shaders aren't supported yet. When we return to working on geometry
shader support, we'll need to update the table for those extensions
that are available in geometry shaders.
- Previous to this commit, if a shader mentioned
ARB_shader_texture_lod, extension ARB_texture_rectangle would be
automatically turned on in order to ensure that the types
sampler2DRect and sampler2DRectShadow would be defined. This was
unnecessary, because (a) ARB_shader_texture_lod works perfectly well
without those types provided that the builtin functions that
reference them are not called, and (b) ARB_texture_rectangle is
enabled by default in non-ES contexts anyway. I eliminated this
unnecessary behavior in order to make the behavior of all extensions
consistent.
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
These were previously 1-bit-wide bitfields. Changing them to bools
has a negligible performance impact, and allows them to be accessed by
offset as well as by direct structure access.
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
From the OpenGL docs for GL_ARB_explicit_attrib_location:
This extension provides a method to pre-assign attribute locations to
named vertex shader inputs and color numbers to named fragment shader
outputs.
This was accidentally implemented for fragment shader inputs. This
patch fixes it to apply to fragment shader outputs.
Fixes piglit tests
spec/ARB_explicit_attrib_location/1.{10,20}/compiler/layout-{01,03,06,07,08,09,10}.frag
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38624
The scissor state was incorrectly in a .prepare function instead of
.emit, so the packet would end up in the batch before the
STATE_BASE_ADDRESS. It appears that this doesn't actually hurt, as
the scissor address gets dereferenced according to the current SBA at
draw time.
All it's going to do is generate lots and lots and lots of
'warning: visibility attribute not supported in this configuration; ignored'
warnings
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
José Fonseca
Stéphane Marchesin
Chia-I Wu
Kenneth Graunke
Bryan Cain
Eric Anholt
Adam Jackson
Brian Paul
Jon TURNEY
Emil Velikov
Thomas Hellstrom
Andre Maasikas
Paul Berry
Alan Hourihane