| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
It apparently regressed a bunch of ES2 cases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From section 5.9 of the GLSL 1.20 spec:
The operator modulus (%) is reserved for future use.
From section 5.8 of the GLSL 1.20 spec:
The assignments modulus into (%=), left shift by (<<=), right shift by
(>>=), inclusive or into ( |=), and exclusive or into ( ^=). These
operators are reserved for future use.
The GLSL ES 1.00 spec and GLSL 1.10 spec have similiar language.
Fixes bug:
https://bugs.freedesktop.org//show_bug.cgi?id=33916
Fixes Piglit tests:
spec/glsl-1.00/compiler/arithmetic-operators/modulus-00.frag
spec/glsl-1.00/compiler/assignment-operators/modulus-assign-00.frag
spec/glsl-1.10/compiler/arithmetic-operators/modulus-00.frag
spec/glsl-1.10/compiler/assignment-operators/modulus-assign-00.frag
spec/glsl-1.20/compiler/arithmetic-operators/modulus-00.frag
spec/glsl-1.20/compiler/assignment-operators/modulus-assign-00.frag
|
|
|
|
|
|
| |
ES requires that a vertex shader and a fragment shader be present.
Fixes bugzilla #32214.
|
|
|
|
| |
Fixes SCons build.
|
|
|
|
| |
These are already stripped by opt_constant_folding.cpp.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch cleans up many of the extra copies in GLSL IR introduced by
i965's scalarizing passes. It doesn't result in a statistically
significant performance difference on nexuiz high settings (n=3) or my
demo (n=10), due to brw_fs.cpp's register coalescing covering most of
those extra moves anyway. However, it does make the debug of wine's
GLSL shaders much more tractable, and reduces instruction count of
glsl-fs-convolution-2 from 376 to 288.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Standard library functions in C++ are in the std namespace. When using
C++-style header files for the standard library, some compilers, such as
Sun Studio, provide symbols only for the std namespace and not for the
global namespace.
This patch adds using statements for standard library functions. Another
option could have been to prepend standard library function calls with
'std::'.
This patch fixes several compilation errors with Sun Studio.
|
|
|
|
|
|
|
|
|
|
| |
For example, this now raises an error:
#define XXX 1 / 0
Fixes bug: https://bugs.freedesktop.org//show_bug.cgi?id=33507
Fixes Piglit test: spec/glsl-1.10/preprocessor/modulus-by-zero.vert
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid division-by-zero when constant-folding the following expression
types:
ir_unop_rsq
ir_binop_div
ir_binop_mod
Fixes bugs:
https://bugs.freedesktop.org//show_bug.cgi?id=33306
https://bugs.freedesktop.org//show_bug.cgi?id=33508
Fixes Piglit tests:
glslparsertest/glsl2/div-by-zero-01.frag
glslparsertest/glsl2/div-by-zero-02.frag
glslparsertest/glsl2/div-by-zero-03.frag
glslparsertest/glsl2/modulus-zero-01.frag
glslparsertest/glsl2/modulus-zero-02.frag
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not constant-fold a reciprocal if any component of the reciprocated
expression is 0. For example, do not constant-fold `1 / vec4(0, 1, 2, 3)`.
Incorrect, previous behavior
----------------------------
Reciprocals were constant-folded even when some component of the
reciprocated expression was 0. The incorrectly applied arithmetic was:
1 / 0 := 0
For example,
1 / vec4(0, 1, 2, 3) = vec4(0, 1, 1/2, 1/3)
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
|
|
|
|
|
| |
This has probably existed since e5e34ab18eeaffa465 or so.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
|
|
|
|
|
|
|
| |
This was my mistake when converting from talloc to ralloc. I was
confused because the other calls in the function are to asprintf_append
and the original code used str as the context rather than NULL.
Fixes bug #33823.
|
| |
|
|
|
|
|
|
|
|
| |
Passing ralloc_vasprintf_append a 0-byte allocation doesn't work. If
passed a non-NULL argument, ralloc calls strlen to find the end of the
string. Since there's no terminating '\0', it runs off the end.
Fixes a crash introduced in 14880a510a1a288df0778395097d5a52806abfb0.
|
| |
|
|
|
|
| |
For the previous commit.
|
|
|
|
|
|
|
|
| |
Previously we'd happily compile GLSL 1.30 shaders on any driver. We'd
also happily compile GLSL 1.10 and 1.20 shaders in an ES2 context.
This has been a long standing FINISHME in the compiler.
NOTE: This is a candidate for the 7.9 and 7.10 branches
|
|
|
|
| |
NOTE: This is a candidate for the 7.9 and 7.10 branches
|
| |
|
| |
|
|
|
|
| |
To silence warning about missing prototype.
|
|
|
|
|
| |
To avoid using the /usr/include/GL/gl.h file which may be lacking
some special #defines.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Rather than passing "True", pass a bitfield describing the particular
variant's features - either projection or offset.
This should make the code a bit more readable ("Proj" instead of "True")
and make it easier to support offsets in the future.
|
|
|
|
|
| |
For offsets, we'll want the straight sampler dimensionality, without the
+1 for array types. Create a new function to do that; refactor.
|
|
|
|
|
|
|
|
| |
This annotation is for an "in" function parameter for which it is only legal
to pass constant expressions. The only known example of this, currently,
is the textureOffset functions.
This should never be used for globals.
|
|
|
|
|
|
|
|
|
|
|
| |
Having these as actual integer values makes it difficult to implement
the texture*Offset built-in functions, since the offset is actually a
function parameter (which doesn't have a constant value).
The original rationale was that some hardware needs these offset baked
into the instruction opcode. However, at least i965 should be able to
support non-constant offsets. Others should be able to rely on inlining
and constant propagation.
|
|
|
|
|
|
| |
Since the introduction of ir_var_system_value, system variables would be
printed as "temporary" and temporaries would result in out-of-bounds
array access, showing up as garbage in printed IR.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit d3df641f0aba99b0b65ecd4d9b06798bca090a29.
The original commit had sat unpushed on my machine for months. By the
time I found it again, I had forgotten that we had decided not to use
this change after all, (the relevant test was removed long ago).
|
|
|
|
|
|
|
|
|
|
| |
The GLSL specification is vague here, (just says "as is standard for
C++"), though the C specifications seem quite clear that this should
be an error.
However, an existing piglit test (CorrectPreprocess11.frag) expects
this to be a warning, not an error, so we change this, and document in
README the deviation from the specification.
|
|
|
|
| |
For previous commit.
|
|
|
|
|
|
| |
I found this parenthetical usage of parentheses to be extraneously
extraneous:
(yyextra->ARB_fragment_coord_conventions_enable)
|
|
|
|
|
| |
All the necessary compiler infrastructure for AMD_conservative_depth is in
place, so it's safe to enable it in the parser.
|
|
|
|
|
|
|
|
|
| |
From the AMD_conservative_depth spec:
If gl_FragDepth is redeclared in any fragment shader in a program, it
must be redeclared in all fragment shaders in that program that have
static assignments to gl_FragDepth. All redeclarations of gl_FragDepth in
all fragment shaders in a single program must have the same set of
qualifiers.
|
| |
|
| |
|
|
|
|
|
|
| |
For commits titled:
glcpp: Conditionally define macro GL_AMD_conservative_depth
glsl: Add support for AMD_conservative_depth to parser
|
|
|
|
|
|
|
|
|
|
| |
When AMD_conservative_depth is enabled:
* Let 'layout' be a token.
* Extend the production rule of layout_qualifier_id to process the tokens:
depth_any
depth_greater
depth_less
depth_unchanged
|
| |
|
|
|
|
|
| |
Define macro GL_AMD_conservative_depth to 1 when its extension is
enabled.
|