| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that process_array_type never returns NULL, and let
process_array_type handle the case where the supplied base type is NULL.
Fixes issues identified by Klocwork analysis:
Pointer 'type' returned from call to function 'get_type' at line
1907 may be NULL and may be dereferenced at line 1912.
and
Pointer 'field_type' checked for NULL at line 4160 will be
dereferenced at line 4165. Also there is one similar error on line
4174.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ast_process_structure_or_interface_block
Fixes issue identified by Klocwork analysis:
Pointer 'field_type' returned from call to function 'glsl_type' at
line 4126 may be NULL and may be dereferenced at line 4139. Also
there are 2 similar errors on line(s) 4165, 4174.
In practice, it should be impossible to actually get NULL in here
because a syntax error would have already caused compilation to halt.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The comment above glsl_type::name claimed that it could sometimes be
NULL. This was wrong--it is never NULL. Many error handling paths
would segfault if it were. (Anonymous structs are assigned names like
"#anon_struct_0001"--see the ast_struct_specifier constructor in
glsl_parser_extras.cpp.)
Fix the comment and add assertions to validate that it really is never
NULL.
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the mailing list discussion of "glsl/linker: fix varying packing
for non-flat integer varyings." (commit 7862bde), we concluded that
since the bug only applies to integral variables, it is safer to just
apply the bug fix to integer varyings. I forgot to make the change
before pushing the patch upstream. (Note: we aren't aware of any bugs
in commit 7862bde; it just seems wise to be on the safe side).
This patch makes the change. Assuming commit 7862bde gets
cherry-picked back to 9.1, this commit should be cherry-picked too.
NOTE: This is a candidate for the 9.1 release branch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a varying is consumed by transform feedback, but is not used by
the fragment shader, assign_varying_locations() sets its interpolation
type to "flat" in order to ensure that lower_packed_varyings never has
to deal with non-flat integral varyings (the GLSL spec doesn't require
integral vertex outputs to be flat if they aren't consumed by the
fragment shader).
A similar situation will arise when geometry shader support is added,
since the GLSL spec only requires integral vertex shader outputs to be
flat when they are consumed by the fragment shader. This patch
modifies the linker to handle this situation too.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To minimize the variety of type conversions that lower_packed_varyings
needs to perform, it assumes that integral varyings are always
qualified as "flat". link_varyings.cpp takes care of ensuring that
this is the case (even in the circumstances where GLSL doesn't require
it).
This patch documents the assumption with an assertion, for ease in
future debugging.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit dfb57e7 (glsl: Fix error checking on "flat" keyword to match
GLSL ES 3.00, GLSL 1.50) relaxed the rules for integral varyings: they
only need to be declared as "flat" if they are a fragment shader
inputs. This allowed for the possibility of a vertex shader output
being a non-flat integer, provided that it was not matched to a
fragment shader input. A non-contrived situation where this might
arise is if a vertex shader generates some integral outputs which are
consumed by tranform feedback, but not by the fragment shader.
Unfortunately, lower_packed_varyings assumes that *all* integral
varyings are flat, regardless of whether they are consumed by the
fragment shader. As a result, attempting to create a non-flat
integral vertex output of a size that required packing (i.e. a size
other than ivec4 or uvec4) would cause an assertion failure in
lower_packed_varyings.
This patch prevents the assertion failure by forcing vertex shader
outputs to be "flat" whenever they are not consumed by the fragment
shader. This should have no effect on rendering since the "flat"
keyword only affects the behaviour of fragment shader inputs.
Fixes piglit test "spec/EXT_transform_feedback/nonflat-integral".
NOTE: This is a candidate for the 9.1 release branch.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
ir_print_visitor::visit(ir_variable *)'s mode[] array needs to match
the declaration of the enum ir_variable_mode. It's hard to verify
that at compile time, but at least we can use a STATIC_ASSERT to make
sure it's the right size.
This required adding ir_var_mode_count to the enum.
|
|
|
|
|
|
|
|
|
|
|
| |
This patch updates the interp[] array to match the enum
glsl_interp_qualifier.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
v2: Add a STATIC_ASSERT to make sure the array is the correct size.
This required adding INTERP_QUALIFIER_COUNT to the enum.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check the type of the array operand and the index operand before doing
other checks. This simplifies the code a bit now (eliminating the
error_emitted parameter), and enables some later functional changes.
The shader
uniform float x[6];
uniform sampler2D s;
void main() { gl_Position.x = xx[s + 1]; }
still generates (only) the two expected errors:
0:3(33): error: `xx' undeclared
0:3(39): error: Operands to arithmetic operators must be numeric
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the shader
uniform float x[6];
void main() { gl_Position.x = x[1.0]; }
would have generated the errors
0:2(33): error: array index must be integer type
0:2(36): error: array index must be < 6
Now only
0:2(33): error: array index must be integer type
will be generated.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This puts all of the checks togeher for easier reading. It also means
that all the checks are blocked on array->type->is_array. Shortly this
will allow elimination of some is_error check work-arounds in this
function.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Also, document the reason for not checking for type->is_array in some of
the bound-checking cases.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
That last consumer of the return value was changed to not use it by the
previous commit.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The error_emitted flag is used in semantic checking to prevent spurious
cascading errors. For example,
void foo(sampler2D s, float a)
{
float x = a + (1.2 + s);
...
}
should only generate a single error. Without the error_emitted flag for
the first error, "a + ..." would also generate an error.
However, a bunch of cases in _mesa_ast_array_index_to_hir that were
setting error_emitted would mask legitimate errors. For example,
vec4 a[7];
float b = a[3.14];
should generate two error (float index and type mismatch in assignment).
The uses of error_emitted would cause only the first to be emitted.
This patch removes most of the places in _mesa_ast_array_index_to_hir
that would set the error_emitted flag.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
I love 800+ line switch-statements as much as the next guy... Future
commits will make changes to this part of the AST-to-HIR conversion, and
extracting this code will make that a bit easier.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
A future commit will try to use this function in a different file.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLBenchmark 2.7's shaders contain conditional blocks like:
if (x) {
if (y) {
...
}
}
where the outer conditional's then clause contains exactly one statement
(the nested if) and there are no else clauses. This can easily be
optimized into:
if (x && y) {
...
}
This saves a few instructions in GLBenchmark 2.7:
total instructions in shared programs: 11833 -> 11649 (-1.55%)
instructions in affected programs: 8234 -> 8050 (-2.23%)
It also helps CS:GO slightly (-0.05%/-0.22%). More importantly,
however, it simplifies the control flow graph, which could enable other
optimizations.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
This reverts commit dbf94d105a48b7aafb2c8cf64d8b4392d87efea1, which
was working around a bug in the handling of array indexing when
constant folding built-in functions. Now that the constant folding
bug has been fixed, the workaround is no longer needed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mesa constant-folds built-in functions by using a miniature GLSL
interpreter (see
ir_function_signature::constant_expression_evaluate_expression_list()).
This interpreter had a bug in its handling of array indexing, which
caused expressions like "m[i][j]" (where m is a matrix) to be handled
incorrectly. Specifically, it incorrectly treated j as indexing into
the whole matrix (rather than indexing just into the vector m[i]); as
a result the offset computed for m[i] was lost and m[i][j] was treated
as m[j][0].
Fixes piglit tests inverse-mat[234].{vert,frag}.
NOTE: This is a candidate for the 9.1 and 9.0 branches.
Reviewed-by: Ian Romanick <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57436
|
|
|
|
|
|
|
|
|
| |
A fix for lower_jumps progress reporting, very much like similar in
c1e591eed.
NOTE: This is a candidate for stable branches.
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When reading a column from a row-major matrix, we would slot the single
value read into the vector using an ir_dereference_array of the vector
with a constant index. This will (eventually) get optimized to a
masked-write, so just generate the masked write in the first place.
v2: Remove unused variable 'chan'. Suggested by Ken.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Cc: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Cc: Eric Anholt <[email protected]>
Cc: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Search and replace:
][0] -> ].x
][1] -> ].y
][2] -> ].z
][3] -> ].w
Fixes piglit tests inverse-mat[234].{vert,frag}. These tests call the
inverse function with constant parameters and expect proper constant
folding to happen. My suspicion is that this patch papers over some bug
in constant propagation involving array accesses.
Either way, all of these accesses eventually get lowered to swizzles.
This cuts out the middle man (saving a trivial amount of CPU).
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Cc: Eric Anholt <[email protected]>
Cc: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the case was missing bec4->get_scalar_type() would return bvec4,
but vec4->get_scalar_type() would return float.
NOTE: This is a candidate for stable branches.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
v2 [mattst88]:
- Rebase.
- #define GL_ARB_texture_query_lod to 1.
- Remove comma after ir_lod in ir.h for MSVC.
- Handled ir_lod in ir_hv_accept.cpp, ir_rvalue_visitor.cpp,
opt_tree_grafting.cpp.
- Rename textureQueryLOD to textureQueryLod, see
https://www.khronos.org/bugzilla/show_bug.cgi?id=821
- Fix ir_reader of (lod ...).
v3 [mattst88]:
- Rename textureQueryLod to textureQueryLOD, pending resolution of
Khronos 821.
- Add ir_lod case to ir_to_mesa.cpp.
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Since half of ir_validate uses asserts() (the other using printf() then
abort()), there's not much use to calling it in a release build. Cuts
6.3% of the startup time of TF2.
NOTE: This is a candidate for the stable branches.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes basic built-in functions work in GLSL 1.50. It supports
everything except the new Geometry Shader functions.
The new 150.glsl file is 140.glsl plus ARB_texture_multisample.glsl;
150.frag is identical to 140.frag except for the #version bump.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
|
|
|
|
|
|
|
|
|
| |
GLSL 1.50 includes support for the new sampler types introduced by
the ARB_texture_multisample extension.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
|
|
|
|
|
|
|
|
| |
The version bumps are necessary in order to compile built-ins for 1.50.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes the following search-and-replace changes:
gl_frag_attrib -> gl_varying_slot
FRAG_ATTRIB_* -> VARYING_SLOT_*
FRAG_BIT_* -> VARYING_BIT_*
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes the following search-and-replace changes:
gl_vert_result -> gl_varying_slot
VERT_RESULT_* -> VARYING_SLOT_*
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
This ends up reusing the dynamic ID support, so a silly enum gets to go
away. We don't assign good IDs to different messages yet, but at least
that's tractable now.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
V2: - emit `sample` parameter properly for multisample texelFetch()
- fix spurious whitespace change
- introduce a new opcode ir_txf_ms rather than overloading the
existing ir_txf further. This makes doing the right thing in
the driver somewhat simpler.
V3: - fix weird whitespace
V4: - don't forget to include the new opcode in tex_opcode_strs[]
(thanks Kenneth for spotting this)
Signed-off-by: Chris Forbes <[email protected]>
[V2] Reviewed-by: Eric Anholt <[email protected]>
[V2] Reviewed-by: Paul Berry <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although GLSL 1.50 compiler support is not available,
this change will allow MESA_GLSL_VERSION_OVERRIDE=150 to be
used while 1.50 support is being developed.
Since no drivers claim 1.50 GLSL support, this change should
only impact Mesa when MESA_GLSL_VERSION_OVERRIDE=150 is set.
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many GPUs have an instruction to do linear interpolation which is more
efficient than simply performing the algebra necessary (two multiplies,
an add, and a subtract).
Pattern matching or peepholing this is more desirable, but can be
tricky. By using an opcode, we can at least make shaders which use the
mix() built-in get the more efficient behavior.
Currently, all consumers lower ir_triop_lrp. Subsequent patches will
actually generate different code.
v2 [mattst88]:
- Add LRP_TO_ARITH flag to ir_to_mesa.cpp. Will be removed in a
subsequent patch and ir_triop_lrp translated directly.
v3 [mattst88]:
- Move changes from the next patch to opt_algebraic.cpp to accept
3-src operations.
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Matt Turner <[email protected]>
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we had separate constructors for one, two, and four operand
expressions. This patch consolidates them into a single constructor
which uses NULL default parameters.
The unary and binary operator constructors had assertions to verify that
the caller supplied the correct number of operands for the expression,
but the four-operand version did not. Since get_num_operands for
ir_quadop_vector returns the number of vector_elements, we can safely
add that without breaking the semantics of ir_quadop_vector.
This also paves the way for expressions with three operands. Currently,
none can be constructed since get_num_operands() never returns 3.
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously when an input varying was optimized out of the
FS we would still retain it as an output of the VS.
We now build a hash of live FS input varyings rather
than looking in the FS symbol table. (The FS symbol table
will still contain the optimized out varyings.)
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Fixes uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of the GLSL specs from GLSL 1.30 (and GLSL ES 3.00) onward contain
language requiring certain integer variables to be declared with the
"flat" keyword, but they differ in exactly *when* the rule is
enforced:
(a) GLSL 1.30 and 1.40 say that vertex shader outputs having integral
type must be declared as "flat". There is no restriction on fragment
shader inputs.
(b) GLSL 1.50 through 4.30 say that fragment shader inputs having
integral type must be declared as "flat". There is no restriction on
vertex shader outputs.
(c) GLSL ES 3.00 says that both vertex shader outputs and fragment
shader inputs having integral type must be declared as "flat".
Previously, Mesa's behaviour was consistent with (a). This patch
makes it consistent with (b) when compiling desktop shaders, and (c)
when compiling ES shaders.
Rationale for desktop shaders: once we add geometry shaders, (b) really
seems like the right choice, because it requires "flat" in just the
situations where it matters. Since we may want to extend geometry
shader support back before GLSL 1.50 (via ARB_geometry_shader4), it
seems sensible to apply this rule to all GLSL versions. Also, this
matches the behaviour of the nVidia proprietary driver for Linux, and
the expectations of Intel's oglconform test suite.
Rationale for ES shaders: since the behaviour specified in GLSL ES
3.00 matches neither pre-GLSL-1.50 nor post-GLSL-1.50 behaviour, it
seems likely that this was a deliberate choice on the part of the GLES
folks to be more restrictive. Also, the argument in favor of (b)
doesn't apply to GLES, since it doesn't support geometry shaders at
all.
Some discussion about this has already happened on the Mesa-dev list.
See:
http://lists.freedesktop.org/archives/mesa-dev/2013-February/034199.html
Fixes piglit tests:
- glsl-1.30/compiler/interpolation-qualifiers/nonflat-*.frag
- glsl-1.30/compiler/interpolation-qualifiers/vs-flat-int-0{2,3,4,5}.vert
- glsl-es-3.00/compiler/interpolation-qualifiers/varying-struct-nonflat-{int,uint}.frag
Fixes oglconform tests:
- glsl-q-inperpol negative.fragin.{int,uint,ivec,uvec}
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the GLSL 1.30 spec, section 4.3.6 ("Outputs") says:
"If a vertex output is a signed or unsigned integer or integer
vector, then it must be qualified with the interpolation qualifier
flat."
The GLSL ES 3.00 spec further clarifies, in section 4.3.6 ("Output
Variables"):
"Vertex shader outputs that are, *or contain*, signed or unsigned
integers or integer vectors must be qualified with the
interpolation qualifier flat."
(Emphasis mine.)
The language in the GLSL ES 3.00 spec is clearly correct and should be
applied to all shading language versions, since varyings that contain
ints can't be interpolated, regardless of which shading language
version is in use.
(Note that in GLSL 1.50 the restriction is changed to apply to
fragment shader inputs rather than vertex shader outputs, to
accommodate the fact that in the presence of geometry shaders, vertex
shader outputs are not necessarily interpolated. That will be
addressed by a future patch).
NOTE: This is a candidate for stable branches.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From GLSL ES 3.00 section 4.5.4 ("Default Precision Qualifiers"):
"The precision statement
precision precision-qualifier type;
can be used to establish a default precision qualifier. The type
field can be either int or float or any of the sampler types, and
the precision-qualifier can be lowp, mediump, or highp."
GLSL ES 1.00 has similar language. GLSL 1.30 doesn't allow precision
qualifiers on sampler types, but this seems like an oversight (since
the intention of including these in GLSL 1.30 is to allow
compatibility with ES shaders).
Previously, Mesa followed GLSL 1.30 and only allowed default precision
qualifiers to be set for float and int. This patch makes it follow
GLSL ES rules in all cases.
Fixes Piglit tests default-precision-sampler.{vert,frag}.
Partially addresses https://bugs.freedesktop.org/show_bug.cgi?id=60737.
NOTE: This is a candidate for stable branches.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the user specifies an unsupported GLSL version,
_mesa_glsl_parse_state::process_version_directive() nicely gives them
an error message telling them which GLSL versions are supported.
Previous to this patch, the logic for determining whether a given
language version was supported was independent from the logic to
generate this error message string; as a result, we had a bug where
GLSL 3.00 would never be listed in the error message as an available
language version, even if it was really available.
To make matters worse, the code for generating the error message
string assumed that desktop GL versions were always separated by 0.10,
an assumption that will be wrong as soon as we support GLSL 3.30.
This patch fixes both problems by adding a table of supported GLSL
versions to _mesa_glsl_parse_state; this table is used both to
generate the error message and to check whether a given version is
supported.
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
| |
Fixes uninitialized scalar field defects reported by Coverity.
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
Fixes uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the loop_state was allocated in the loop_analysis
constructor, but not freed in the (nonexistent) destructor. Moving
the allocation of the loop_state makes this code appear less sketchy.
Either way, there is no actual leak. The loop_state is freed by the
single caller of analyze_loop_variables.
Signed-off-by: Ian Romanick <[email protected]>
Cc: Dave Airlie <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57753
|
| |
|