summaryrefslogtreecommitdiffstats
path: root/src/glsl/glcpp/glcpp-parse.y
Commit message (Collapse)AuthorAgeFilesLines
* glsl: Extension tracking for EXT_shader_samples_indenticalIan Romanick2015-11-191-0/+3
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* glsl: add GL_EXT_blend_func_extended preprocessor defineRyan Houdek2015-11-191-0/+2
| | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* mesa: add ARB_enhanced_layoutsTimothy Arceri2015-11-121-0/+1
| | | | Reviewed-by: Emil Velikov <[email protected]>
* glsl: add ARB_shader_clock infrastructureEmil Velikov2015-10-301-0/+3
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* glsl: add ARB_shader_texture_image_samples infrastructureIlia Mirkin2015-09-101-0/+3
| | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: add support for OES_texture_storage_multisample_2d_arrayTapani Pälli2015-08-271-0/+2
| | | | | | | | | | | v2: use ARB_texture_multisample enable bit Patch adds extension enable bit and enables required keywords and builtin functions for the extension. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Marta Lofstedt <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* main: add extension GL_ARB_shader_image_sizeMartin Peres2015-08-201-0/+3
| | | | | | Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Signed-off-by: Martin Peres <[email protected]>
* glsl/glcpp: fix SIGSEGV when checking error condition for macro redefinitionSamuel Iglesias Gonsalvez2015-07-241-2/+2
| | | | | | | | | | | | | | | Commit a6e9cd14c does not take into account than node_{a,b}->next could be NULL in some circumstances, such as in a shader containing this code: #define A 1 /* comment */ #define A 1 /* comment */ This patch fixes the segmentation fault for cases like that. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91290 Signed-off-by: Samuel Iglesias Gonsalvez <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Cc: [email protected]
* glsl: Add extension plumbing and define for ARB_shader_subroutineChris Forbes2015-07-231-0/+3
| | | | | | | Reviewed-by: Tapani Pälli <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chris Forbes <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* glsl: add tessellation shader defines and built-in variables.Fabian Bieler2015-07-231-0/+3
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: define ARB_shader_storage_buffer_object extensionSamuel Iglesias Gonsalvez2015-07-141-0/+3
| | | | | Signed-off-by: Samuel Iglesias Gonsalvez <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* glsl: add ARB_vertex_attrib_64bit support. (v2)Dave Airlie2015-05-081-0/+3
| | | | | | | | | | | Just more boilerplate stuff. v2: bad fallthrough on versioning, this is my ugly but self contained solution (Ian) Reviewed-by: Ilia Mirkin <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* Fix a few typosZoë Blade2015-04-271-1/+1
| | | | Reviewed-by: Francisco Jerez <[email protected]>
* glsl: add ARB_gpu_shader_fp64 to the glsl extensions. (v2)Dave Airlie2015-02-191-0/+3
| | | | | | | | | | | | | v2: add define bit (Tapani Pälli) Patch makes following Piglit tests pass: arb_gpu_shader_fp64/preprocessor/define.vert arb_gpu_shader_fp64/preprocessor/define.frag Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* mesa: Add ARB_shader_precision infrastructureMicah Fedke2015-01-191-0/+3
| | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* mesa/glsl/glapi: enable GL_EXT_draw_buffers extensionTapani Pälli2015-01-141-0/+1
| | | | | | | | | | | | | | | | Patch enables ES2 extension that utilizes existing ES3 functionality. Changes make all the subtests to run and pass in WebGL conformance test 'webgl-draw-buffers' when running Chrome on OpenGL ES, also Piglit test 'draw_buffers_gles2' passes. v2: remove unused boolean (Ilia Mirkin) v3: proper error checking for invalid values (Chad Versace) v4: run error check explicitly for ES2 and ES3 (Kenneth Graunke) Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* glcpp: Fix `can not` to `cannot` in error messageChris Forbes2014-12-071-1/+1
| | | | Signed-off-by: Chris Forbes <[email protected]>
* glcpp: Disallow undefining GL_* builtin macros.Chris Forbes2014-12-071-1/+2
| | | | | | | | Fixes the piglit test: spec/glsl-es-3.00/compiler/undef-GL_ES.vert Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: add ARB_derivative control supportIlia Mirkin2014-08-141-0/+3
| | | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Fix handling of commas that result from macro expansionCarl Worth2014-08-071-12/+1
| | | | | | | | | | | | | | | | | | | | | | | | Here is some additional stress testing of nested macros where the expansion of macros involves commas, (and whether those commas are interpreted as argument separators or not in subsequent function-like macro calls). Credit to the GCC documentation that directed my attention toward this issue: https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/Argument-Prescan.html Fixing the bug required only removing code from glcpp. When first testing the details of expansions involving commas, I had come to the mistaken conclusion that an expanded comma should never be treated as an argument separator, (so had introduced the rather ugly COMMA_FINAL token to represent this). In fact, an expanded comma should be treated as a separator, (as tested here), and this treatment can be avoided by judicious use of parentheses (as also tested here). With this simple removal of the COMMA_FINAL token, the behavior of glcpp matches that of gcc's preprocessor for all of these hairy cases. Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Fix for macros that expand to include "defined" operatorsCarl Worth2014-08-071-45/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this commit, the following snippet would trigger an error in glcpp: #define FOO defined BAR #if FOO #endif The problem was that support for the "defined" operator was implemented within the grammar, (where the parser was parsing the tokens of the condition itself). But what is required is to interpret the "defined" operator that results after macro expansion is performed. I could not find any fix for this case by modifying the grammar alone. The difficulty is that outside of the grammar we already have a recursive function that performs macro expansion (_glcpp_parser_expand_token_list) and that function itself must be augmented to be made aware of the semantics of the "defined" operator. The reason we can't simply handle "defined" outside of the recursive expansion function is that not only must we scan for any "defined" operators in the original condition (before any macro expansion occurs); but at each level of the recursive expansion, we must again scan the list of tokens resulting from expansion and handle "defined" before entering the next level of recursion to further expand macros. And of course, all of this is context dependent. The evaluation of "defined" operators must only happen when we are handling preprocessor conditionals, (#if and #elif) and not when performing any other expansion, (such as in the main body). To implement this, we add a new "mode" parameter to all of the expansion functions to specify whether resulting DEFINED tokens should be evaluated or ignored. One side benefit of this change is that an ugly wart in the grammar is removed. We previously had "conditional_token" and "conditional_tokens" productions that were basically copies of "pp_token" and "pp_tokens" but with added productions for the various forms of DEFINED operators. With the new code here, those ugly copy-and-paste productions are eliminated from the grammar. A new "make check" test is added to stress-test the code here. This commit fixes the following Khronos GLES3 CTS tests: conditional_inclusion.basic_2_vertex conditional_inclusion.basic_2_fragment Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Add explicit error for "#define without macro name"Carl Worth2014-08-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Previously, glcpp would emit an error like this if <EOF> happened to occur immediately after the "#define", but in general would just get confused, (leading to un-helpful error messages). To fix things to generate a clean error message, we do a few things: 1. Don't require horizontal whitespace immediately after #define 2. Add a production for the error case, (DEFINE_TOKEN followed immediately by a NEWLINE token). 3. Make the lexer reset to the <INITIAL> state after every NEWLINE. This 3rd point prevents the lexer from getting so confused and generating further spurious errors in the file because it was stuck in the <DEFINE> start condition. We also drop the similar error message from the <EOF> rule since the newly-added rule will have already printed the error message. Reviewed-by: Ian Romanick <[email protected]>
* define GL_OES_standard_derivatives if extension is supportedKevin Rogovin2014-08-021-0/+2
| | | | | | | | | Define the macro GL_OES_standard_derivatives as 1 if the extension GL_OES_standard_derivatives is supported. V2 [Chris]: Correct trailing whitespace Reviewed-by: Chris Forbes <[email protected]>
* glsl/glcpp: rename ERROR to ERROR_TOKEN to fix MSVC buildBrian Paul2014-07-301-3/+3
| | | | | | | ERROR is a #define in the MSVC WinGDI.h header file. Add the _TOKEN suffix as we do for a few other lexer tokens. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/glcpp: Add (non)-support for ++ and -- operatorsCarl Worth2014-07-291-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | These operators aren't defined for preprocessor expressions, so we never implemented them. This led them to be misinterpreted as strings of unary '+' or '-' operators. In fact, what is actually desired is to generate an error if these operators appear in any preprocessor condition. So this commit looks like it is strictly adding support for these operators. And it is supporting them as far as passing them through to the subsequent compiler, (which was already happening anyway). What's less apparent in the commit is that with these tokens now being lexed, but with no change to the grammar for preprocessor expressions, these operators will now trigger errors there. A new "make check" test is added to verify the desired behavior. This commit fixes the following Khronos GLES3 CTS test: invalid_op_1_vertex invalid_op_1_fragment invalid_op_2_vertex invalid_op_2_fragment Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Emit error for duplicate parameter name in function-like macroCarl Worth2014-07-291-0/+29
| | | | | | | | | | | | | | | | | This will emit an error for something like: #define FOO(x,x) ... Obviously, it's not a legal thing to do, and it's easy to check. Add a "make check" test for this as well. This fixes the following Khronos GLES3 CTS tests: invalid_function_definitions.unique_param_name_vertex invalid_function_definitions.unique_param_name_fragment Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Add an explanatory comment for "loc != NULL" checkCarl Worth2014-07-291-0/+4
| | | | | | | | | | | Just reading the code, it looked like a bug that _define_object_macro had this check, but _define_function_macro did not. Upon further reading, that's because the check is to allow for our builtins to be defined, (and there are no builtin function-like macros). Add my new understanding as a comment to help the next reader. Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Drop the HASH_ prefix from token names like HASH_IFCarl Worth2014-07-291-25/+26
| | | | | | | | | | | | | | | | | | | Previously, we had a single token for "#if" but now that we have two separate tokens, it looks much better to see: HASH_TOKEN IF than: HASH_TOKEN HASH_IF (Note, that for the same reason we use HASH_TOKEN instead of HASH, we also use DEFINE_TOKEN instead of DEFINE to avoid a conflict with the <DEFINE> start condition in the lexer.) There should be no behavioral change from this commit. Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Correctly parse directives with intervening commentsCarl Worth2014-07-291-51/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's legal (though highly bizarre) for a pre-processor directive to look like this: # /* why? */ define FOO bar This behavior comes about since the specification defines separate logical phases in a precise order, and comment-removal occurs in a phase before the identification of directives. Our implementation does not use an actual separate phase for comment removal, so some extra care is necessary to correctly parse this. What we want is for '#' to introduce a directive iff it is the first token on a line, (ignoring whitespace and comments). Previously, we had a lexical rule that worked only for whitespace (not comments) with the following regular expression to find a directive-introducing '#' at the beginning of a line: HASH ^{HSPACE}*#{HSPACE}* In this commit, we switch to instead use a simple literal match of '#' to return a HASH_TOKEN token and add a new <HASH> start condition for whenever the HASH_TOKEN is the first non-space token of a line. This requires the addition of the new bit of state: first_non_space_token_this_line. This approach has a couple of implications on the glcpp parser: 1. The parser now sees two separate tokens, (such as HASH_TOKEN and HASH_DEFINE) where it previously saw one token (HASH_DEFINE) for the sequence "#define". This is a straightforward change throughout the grammar. 2. The parser may now see a SPACE token before the HASH_TOKEN token of a directive. Previously the lexical regular expression for {HASH} would eat up the space and there would be no SPACE token. This second implication is a bit of a nuisance for the parser. It causes a SPACE token to appear in a production of the grammar with the following two definitions of a control_line: control_line SPACE control_line This is really ugly, since normally a space would simply be a token separator, so it wouldn't appear in the tokens of a production. This leads to a further problem with interleaved spaces and comments: /* ... */ /* ... */ #define /* ..*/ For this, we must not return several consecutive SPACE tokens, or else we would need an arbitrary number of new productions: SPACE SPACE control_line SPACE SPACE SPACE control_line ad nauseam To avoid this problem, in this commit we also change the lexer to emit only a single SPACE token for any series of consecutive spaces, (whether from actual whitespace or comments). For this compression, we add a new bit of parser state: last_token_was_space. And we also update the expected results of all necessary test cases for the new compression of space tokens. Fortunately, the compression of spaces should not lead to any semantic changes in terms of what the eventual GLSL compiler sees. So there's a lot happening in this commit, (particularly for such a tiny feature). But fortunately, the lexer itself is looking cleaner than ever. The only ugly bit is all the state updating, but it is at least isolated to a single shared function. Of course, a new "make check" test is added for the new feature, (directives with comments and whitespace interleaved in many combinations). And this commit fixes the following Khronos GLES3 CTS tests: function_definition_with_comments_vertex function_definition_with_comments_fragment Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Rename HASH token to HASH_TOKENCarl Worth2014-07-291-4/+7
| | | | | | | | | | | This is in preparation for the planned addition of a new <HASH> start condition to the lexer. Both start conditions and token types are, of course, in the same default C namespace, so a start condition and a token type with the same name will collide. (And unfortunately, they are both apparently implemented as equivalent numeric types so the collision is undetected at compile time and simply leads to unpredictable behavior at run time.) Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Add a -d/--debug option to the standalone glcpp programCarl Worth2014-07-291-0/+2
| | | | | | | | | The verbose debug output from the parser is quite useful when debugging, and having this available as a command-line option is much more convenient than manually forcing this into the code when needed, (which is what I had been doing for too long previously). Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Minor tweak to wording of error messageCarl Worth2014-07-291-1/+1
| | | | | | It makes more sense to print the directive name with the preceding '#'. Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Stop using a lexer start condition (<SKIP>) for token skipping.Carl Worth2014-07-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here, "skipping" refers to the lexer not emitting any tokens for portions of the file within an #if condition (or similar) that evaluates to false. Previously, the lexer had a special <SKIP> start condition used to control this skipping. This start condition was not handled like a normal start condition. Instead, there was a particularly ugly block of code set to be included at the top of the generated lexing loop that would change from <INITIAL> to <SKIP> or from <SKIP> to <INITIAL> depending on various pieces of parser state, (such as parser->skip_state and parser->lexing_directive). Not only was that an ugly approach, but the <SKIP> start condition was complicating several glcpp bug fixes I attempted recently that want to use start conditions for other purposes, (such as a new <HASH> start condition). The recently added RETURN_TOKEN macro gives us a convenient way to implement skipping without using a lexer start condition. Now, at the top of the generated lexer, we examine all the necessary parser state and set a new parser->skipping bit. Then, in RETURN_TOKEN, we examine parser->skipping to determine whether to actually emit the token or not. Besides this, there are only a couple of other places where we need to examine the skipping bit (other than when returning a token): * To avoid emitting an error for #error if skipped. * To avoid entering the <DEFINE> start condition for a #define that is skipped. With all of this in place in the present commit, there are hopefully no behavioral changes with this patch, ("make check" still passes all of the glcpp tests at least). Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Drop extra, final newline from most outputCarl Worth2014-07-291-0/+1
| | | | | | | | | | | | | | | | | | | | The glcpp parser is line-based, so it needs to see a NEWLINE token at the end of each line. This causes a trick for files that end without a final newline. Previously, the lexer for glcpp punted in this case by unconditionally returning a NEWLINE token at end-of-file, (causing most files to have an extra blank line at the end). Here, we refine this by lexing end-of-file as a NEWLINE token only if the immediately preceding token was not a NEWLINE token. The patch is a minor change that only looks huge for two reasons: 1. Almost all glcpp test result ".expected" files are updated to drop the extra newline. 2. All return statements from the lexer are adjusted to use a new RETURN_TOKEN macro that tracks the last-token-was-a-newline state. Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: move macro declaration before code to fix MSVC buildBrian Paul2014-07-101-1/+2
| | | | Reviewed-by: Carl Worth <[email protected]>
* glsl/glcpp: Promote "extra token at end of directive" from warning to errorCarl Worth2014-07-091-1/+1
| | | | | | | | | | | | | | | | We've always warned about this case, but a recent confromance test expects this to be an error that causes compilation to fail. Make it so. Also add a "make check" test to ensure these errors are generated. This fixes the following Khronos GLES3 conformance tests: invalid_conditionals.tokens_after_ifdef_vertex invalid_conditionals.tokens_after_ifdef_fragment invalid_conditionals.tokens_after_ifndef_vertex invalid_conditionals.tokens_after_ifndef_fragment Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/glcpp: Once again report undefined macro name in error message.Carl Worth2014-07-091-35/+83
| | | | | | | | | | | While writing the previous commit message, I just felt bad documenting the shortcoming of the change, (that undefined macro names would not be reported in error messages). Fix this by preserving the first-encounterd undefined macro name and reporting that in any resulting error message. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/glcpp: Add short-circuiting for || and && in #if/#elif for OpenGL ES.Carl Worth2014-07-091-30/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GLSL ES Specification 3.00.4 says: #if, #ifdef, #ifndef, #else, #elif, and #endif are defined to operate as for C++ except for the following: ... • Undefined identifiers not consumed by the defined operator do not default to '0'. Use of such identifiers causes an error. [Page 11 (page 127 of the PDF file)] as well as: The semantics of applying operators in the preprocessor match those standard in the C++ preprocessor with the following exceptions: • The 2nd operand in a logical and ('&&') operation is evaluated if and only if the 1st operand evaluates to non-zero. • The 2nd operand in a logical or ('||') operation is evaluated if and only if the 1st operand evaluates to zero. If an operand is not evaluated, the presence of undefined identifiers in the operand will not cause an error. (Note that neither of these deviations from C++ preprocessor behavior apply to non-ES GLSL, at least as of specfication version 4.30.6). The first portion of this, (generating an error for an undefined macro in an (short-circuiting to squelch errors), was not implemented previously, but is implemented in this commit. A test is added for "make check" to ensure this behavior. Note: The change as implemented does make the error message a bit less precise, (it just states that an undefined macro was encountered, but not the name of the macro). This commit fixes the following Khronos GLES3 conformance test: undefined_identifiers.valid_undefined_identifier_1_vertex undefined_identifiers.valid_undefined_identifier_1_fragment undefined_identifiers.valid_undefined_identifier_2_vertex undefined_identifiers.valid_undefined_identifier_2_fragment Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/glcpp: Fix glcpp to catch garbage after #if 1 ... #elseCarl Worth2014-07-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, a line such as: #else garbage would flag an error if it followed "#if 0", but not if it followed "#if 1". We fix this by setting a new bit of state (lexing_else) that allows the lexer to defer switching to the <SKIP> start state until after the NEWLINE following the #else directive. A new test case is added for: #if 1 #else garbage #endif which was untested before, (and did not generate the desired error). This fixes the following Khronos GLES3 CTS tests: tokens_after_else_vertex tokens_after_else_fragment Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* glsl/glcpp: Fix preprocessor error condition for macro redefinitionAnuj Phogat2014-07-091-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch specifically fixes redefinition condition for white space changes. #define and #undef functionality in GLSL follows the standard for C++ preprocessors for macro definitions. From https://gcc.gnu.org/onlinedocs/cpp/Undefining-and-Redefining-Macros.html: These definitions are effectively the same: #define FOUR (2 + 2) #define FOUR (2 + 2) #define FOUR (2 /* two */ + 2) but these are not: #define FOUR (2 + 2) #define FOUR ( 2+2 ) #define FOUR (2 * 2) #define FOUR(score,and,seven,years,ago) (2 + 2) Fixes Khronos GLES3 CTS tests; invalid_object_whitespace_vertex invalid_object_whitespace_fragment Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Carl Worth <[email protected]>
* glsl/glcpp: Do not allow undefining the built-in macrosAnuj Phogat2014-07-091-0/+6
| | | | | | | | | | | | | | | | | Fixes piglit tests in spec/glsl-es-3.00/compile: undef-__FILE__.vert undef-GL_ES.vert undef-__LINE__.vert undef-__VERSION__.vert Also, fixes Khronos GLES3 CTS tests: undefine_invalid_object_1_vertex undefine_invalid_object_1_fragment undefine_invalid_object_2_vertex undefine_invalid_object_2_fragment Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Carl Worth <[email protected]>
* glsl: add support for AMD_vertex_shader_viewport_indexIlia Mirkin2014-07-021-0/+3
| | | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Tested-by: Tobias Droste <[email protected]>
* Partially revert "glsl: Add builtin define for ARB_fragment_layer_viewport"Chris Forbes2014-06-221-0/+6
| | | | | This partially reverts commit cc18b1ec2161c846109e921d7821dfeef7a06f3a, which dropped some unrelated code due to a fumbled rebase.
* glsl: Add builtin define for ARB_fragment_layer_viewportChris Forbes2014-06-221-6/+3
| | | | | | | | The spec doesn't actually mention adding this, but this is the usual pattern so I'm assuming it's a spec bug. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: parser changes for GL_ARB_explicit_uniform_locationTapani Pälli2014-06-161-0/+3
| | | | | | | | | | | | Patch adds a preprocessor define for the extension and stores explicit location data for uniforms during AST->HIR conversion. It also sets layout token to be available when having the extension in place. v2: change parser check to require GLSL 330 or enabling GL_ARB_explicit_attrib_location (Ian) v3: fix the check and comment in AST->HIR (Petri) Signed-off-by: Tapani Pälli <[email protected]>
* mesa: Enable GL_EXT_separate_shader_objects for OpenGL ESIan Romanick2014-05-021-0/+1
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa/sso: Enable GL_ARB_separate_shader_objects by defaultIan Romanick2014-05-021-3/+1
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl/sso: Add parser and AST-to-HIR support for separate shader object layoutsIan Romanick2014-02-211-0/+3
| | | | | | | | | | | | GL_ARB_separate_shader_objects adds the ability to specify location layouts for interstage inputs and outputs. In addition, this extension makes 'in' and 'out' generally available for shader inputs and outputs. This mimics the behavior of GL_ARB_explicit_attrib_location. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* glcpp: Only warn for macro names containing __Ian Romanick2014-02-191-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Section 3.3 (Preprocessor) of the GLSL 1.30 spec (and later) and the GLSL ES spec (all versions) say: "All macro names containing two consecutive underscores ( __ ) are reserved for future use as predefined macro names. All macro names prefixed with "GL_" ("GL" followed by a single underscore) are also reserved." The intention is that names containing __ are reserved for internal use by the implementation, and names prefixed with GL_ are reserved for use by Khronos. Since every extension adds a name prefixed with GL_ (i.e., the name of the extension), that should be an error. Names simply containing __ are dangerous to use, but should be allowed. In similar cases, the C++ preprocessor specification says, "no diagnostic is required." Per the Khronos bug mentioned below, a future version of the GLSL specification will clarify this. Signed-off-by: Ian Romanick <[email protected]> Cc: "9.2 10.0 10.1" <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Tested-by: Kenneth Graunke <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Tested-by: Darius Spitznagel <[email protected]> Cc: Tapani Pälli <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870 Bugzilla: Khronos #11702
* glcpp: Add built-in define for ARB_shader_image_load_store.Francisco Jerez2014-02-121-0/+3
| | | | Reviewed-by: Paul Berry <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 01:32:28 +0000