| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we recorded just the GLSL version, with the knowledge that
100 means GLSL 1.00 ES. With the advent of GLSL 3.00 ES, this is
going to get more complex, and eventually will probably become
ambiguous (GLSL 4.00 already exists, and GLSL 4.00 ES is likely to be
created some day).
To reduce confusion, this patch simply records whether the shader is
GLSL ES as an explicit boolean.
[v2, idr]: s/IsEs(Shader|Prog)/IsES/ Suggested by Ken and Eric.
Reviewed-by: Ian Romanick <[email protected]> [v1]
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that GLSL 1.00 is selected using "#version 100", so "#version 100
es" is prohibited.
v2: Check for GLES3 before allowing '#version 300 es'
v3: Make sure a correct language_version is set in
_mesa_glsl_parse_state::process_version_directive.
Signed-off-by: Paul Berry <[email protected]>
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Version directive handling is going to have to be used within two
parser rules, one for desktop-style version directives (e.g. "#version
130") and one for the new ES-style version directive (e.g. "#version
300 es"), so this patch moves it to a function that can be called from
both rules.
No functional change.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Version directive handling is going to have to be used within two
parser rules, one for desktop-style version directives (e.g. "#version
130") and one for the new ES-style version directive (e.g. "#version
300 es"), so this patch moves it to a function that can be called from
both rules.
No functional change.
[mattst88] v2: Use intmax_t instead of int for version argument. Would
otherwise write garbage after #version since PRIiMAX was reading 64-bits
instead of 32.
[idr] v3: A later commit fixes the caller of
_glcpp_parser_handle_version_declaration to pass the correct number of
parameters. Fix it in the patch that changes the interface instead.
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch turns on the following features for GLSL ES 3.00:
- Array constructors, whole array assignment, and array comparisons.
- Second and third operands of ?: may be arrays.
- Use of "in" and "out" qualifiers on globals.
- Bitwise and modulus operators.
- Integral vertex shader inputs.
- Range-checking of literal integers.
- array.length method.
- Function calls may be constant expressions.
- Integral varyings must be qualified with "flat".
- Interpolation and centroid qualifiers may not be applied to vertex
shader inputs.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLSL ES 3.00 adds the following keywords over GLSL 1.00: uint,
uvec[2-4], matNxM, centroid, flat, smooth, various samplers, layout,
switch, default, and case.
Additionally, it reserves a large number of keywords, some of which
were already reserved in versions of desktop GL that Mesa supports,
some of which are new to Mesa.
A few of the reserved keywords in GLSL ES 3.00 are keywords that are
supported in all other versions of GLSL: attribute, varying,
sampler1D, sampler1DShador, sampler2DRect, and sampler2DRectShadow.
This patch updates the lexer to handle all of the new keywords
correctly when the language being parsed is GLSL 3.00 ES.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch expands the lexer KEYWORD macro to take two additional
arguments: the GLSL ES versions in which the given keyword was first
reserved, and supported, respectively. This will allow us to
trivially add support for GLSL 3.00 ES keywords, even though the set
of GLSL 3.00 ES keywords is neither a subset or a superset of the
keywords corresponding to any desktop GLSL version.
The new KEYWORD macro makes use of the
_mesa_glsl_parse_state::is_version() function, so it accepts 0 as
meaning "unsupported" (rather than 999, which we used previously).
Note that a few keywords ("packed" and "row_major") are supported
*either* when GLSL 1.40 is in use or when ARB_uniform_buffer_obj
support is enabled. Previously, we handled these by cleverly taking
advantage of the fact that the KEYWORD macro didn't parenthesize its
arguments in the usual way. Now they are handled more
straightforwardly, with a new macro, KEYWORD_WITH_ALT.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous to this patch, we were not very consistent about the errors
we generate when a shader tried to use a feature that is prohibited in
the current GLSL version. Some error messages failed to mention the
GLSL version currently in use (or did so inaccurately), and some error
messages failed to mention the first GLSL version in which the given
feature is allowed.
This patch reworks all of the error checks to use the check_version()
function, which produces error messages in a standard form
(approximately "$FEATURE forbidden in $CURRENT_GLSL_VERSION
($REQUIRED_GLSL_VERSION required).").
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the advent of GLSL 3.00 ES, the version checks we perform in the
GLSL compiler (to determine which language features are present) will
become more complicated. To reduce the complexity, this patch adds
functions check_version() and is_version() to _mesa_glsl_parse_state.
These functions take two version numbers: a desktop GLSL version and a
GLSL ES version, and return a boolean indicating whether the GLSL
version being compiled is at least the required version. So, for
example, is_version(130, 300) returns true if the GLSL version being
compiled is at least desktop GLSL 1.30 or GLSL 3.00.
The check_version() function additionally produces an error message if
the version check fails, informing the user of which GLSL version(s)
support the given feature.
[v2, idr]: Add PRINTFLIKE annotation to the new method. The numbering of th
parameters is correct because GCC is silly.
[v3, idr]: Fix copy-and-paste error in the comment before
_mesa_glsl_parse_state::is_version. Noticed by Ken.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes a bug where version_string would be left uninitialized if no
GLSL "#version" directive was used.
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This will be useful in generating more helpful error messages,
especially with the addition of GLSL 3.00 ES support.
[v2, idr]: Rename ctx parameter to mem_ctx
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we stored the GLSL language version in the
glsl_symbol_table struct. But this was unnecessary--all
glsl_symbol_table needs to know is whether functions and variables
have separate namespaces (they do in GLSL 1.10 only).
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding this now makes it easier to develop and test GLES3 features, since we
can do initial development and testing using desktop GL. Later GLSL compiler
patches check for either ctx->Extensions.ARB_ES3_compatibility or
_mesa_is_gles3 to allow certain features (i.e., "#version 300 es").
[v2, idr]: Just edits to the commit message.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Carl Worth <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
|
|
|
|
|
|
|
|
|
| |
Coverity pointed out this uninitialised class member.
Note: This is a candidate for stable branches.
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
| |
coverity pointed out this field was being used uninitialised.
Note: This is a candidate for stable branches.
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reported by coverity scan.
v2: fix second case
Note: This is a candidate for stable branches.
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
This reverts commit 962a1c07b44fe500b79b3ca6806d72a432c1f055.
Further testing revealed that this commit can cause the pre-processor to enter
infinite loops. For now, simply revert this code until a cleaner,
better-tested version is available.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we were only supporting line-continuation backslash characters
within lines of pre-processor directives, (as per the specification). With
OpenGL 4.2 and GLES3, line continuations are now supported anywhere within a
shader.
While changing this, also fix a bug where the preprocessor was ignoring
line continuation characters when a line ended in multiple backslash
characters.
The new code is also more efficient than the old. Previously, we would
perform a ralloc copy at each newline. We now perform copies only at each
occurrence of a line-continuation.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Drop these from the known limitations list since support was recently added
for these.
Also, fix a typo while in the area, (and the oddly missing final newline).
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test file is very similar to test 113-line-and-file-macros but uses token
pasting for cleaner quiz answers (without spaces between the digits). This
test passes thanks to the recent addition of support for pasting INTEGER
tokens, (but would have failed without that).
(Note that this test is distinct from test 059-token-pasting-integer which
pastes integers parsed from the source. Those are parsed to INTEGER_STRING
tokens and are already pasted correctly as verified by that test. The only way
to generate the INTEGER tokens which currently fail to paste is with an
internal define such as __LINE__ that results in an integer.)
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
| |
By generalizing the current code designed to paste string tokens of various
types.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
| |
As recently tested in the additions to the invalid paste test, it is illegal
to paste a non-digit sequence onto the end of an integer.
The 082-invalid-paste test should now pass again.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
The current code lets a few invalid pastes through, such as an string pasted
onto the end of an integer. Extend the invalid-paste test to catch some of
these.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
This time creating a new _token_list_create_with_one_integer function
modeled after the existing _token_list_create_with_one_space function
(both implemented with new _token_list_create_with_one_ival).
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
| |
This function is getting a little long too read. Simplify it by pulling
up one assignment from every condition.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These tokens are easy to expand by just looking at the current, tracked
location values, (and no need to look anything up in the hash table).
Add a test which verifies __LINE__ with several values, (and verifies __FILE__
for the single value of 0). Our testing framework isn't sophisticated enough
here to have a test with multiple file inputs.
This commit fixes part of es3conform's preprocess16_frag test.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This should help avoid confusion now that we're using the gl_api enum
to distinguishing between core and compatibility API's. The
corresponding enum value for core API's is API_OPENGL_CORE.
Acked-by: Eric Anholt <[email protected]>
Acked-by: Matt Turner <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
And add test cases to ensure that this works
- 110 verifies that glcpp rejects #elif<digits> which glcpp
previously accepted.
- 111 verifies that glcpp accepts #if followed immediately by
(, +, -, !, or ~.
- 112 does the same as 111 but for #elif.
See 17f9beb6 for #if change.
Reviewed-by: Carl Worth <[email protected]>
|
|
|
|
|
| |
Fixes part of es3conform's preprocess16_frag test.
Reviewed-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
| |
Fixes es3conform's explicit_attrib_location_integer_constants.
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-and-tested-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal of that change was to skip counting things that aren't actually
outputs from the VS to the FS. However, explicit_location isn't set in
the case of linker-assigned locations (the common case), so basically
varying component counting got disabled. At this stage of the linker,
we've already ensured that var->location is set, so we can just look at
it without worrying.
Fixes i965 assertion failure with the new
piglit glsl-max-varyings --exceed-limits.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51545
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes SCons build regression introduced with commit
a665cf1226b80ec52a0c1a4a38378df4389e8ebf.
Signed-off-by: Vinson Lee <[email protected]>
Tested-by: Vinson Lee <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Vector indexing on matrixes generates several copy of the
constant matrix, for instance vec=mat4[i][j] generates :
vec=mat4[i].x;
vec=(j==1)?mat4[i].y;
vec=(j==2)?mat4[i].z;
vec=(j==3)?mat4[i].w;
In the case of constant matrixes, the mat4[i] expression generates
copy of the 16 elements of the matrix 4 times ; indirect addressing
also prevents some conservative CSE algorithms (like the one in LLVM)
from factoring the mat4[i] expression.
This patch will make the vec_index_to_cond pass generates :
temp = mat4[i];
vec=temp.x;
vec=(j==1)?temp.y;
vec=(j==2)?temp.z;
vec=(j==3)?temp.w;
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes a regression caused by commit 9948a3365.
https://bugs.freedesktop.org/show_bug.cgi?id=56787
https://bugs.freedesktop.org/show_bug.cgi?id=56685
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51802
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51506
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41152
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By moving the HASH_LINE rule out of control_line: and into line:, we avoid
adding control_line's additional \n (as seen in the first hunk).
mattst88: Carl and I determined independently of Fabian that the 091
test needed to be modified identically to this, and our patch to fix the
test was more complicated.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51506
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Carl Worth <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were accepting garbage after #else and #endif tokens when
the previous preprocessor conditional evaluated to false (eg, #if 0).
When the preprocessor hits a false conditional, it switches the lexer
into the SKIP state, in which it ignores non-control tokens. The parser
pops the SKIP state off the stack when it reaches the associated #elif,
#else, or #endif. Unfortunately, that meant that it only left the SKIP
state after the lexing the entire line containing the #token and thus
would accept garbage after the #token.
To fix this we use a mid-rule, which is executed immediately after the
#token is parsed.
NOTE: This is a candidate for the stable branch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56442
Fixes: preprocess17_frag.test from oglconform
Reviewed-by: Carl Worth <[email protected]> (glcpp-parse.y)
Acked-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds all the new builtins + the new sampler types,
and hooks them up if the extension is supported.
v2: fix missing signatures for grad/lod
fix missing textureSize clarifications
fix compare vs starts with usage
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
| |
ir_variable is a class, not a struct. Fixes an MSVC warning.
Reviewed-by: Jose Fonseca <[email protected]>
|