summaryrefslogtreecommitdiff
path: root/src/glsl
AgeCommit message (Collapse)AuthorFilesLines
2014-05-07glsl: fix bogus layout qualifier warningsTapani Pälli1-4/+7
Print out GL_ARB_explicit_attrib_location warnings only when parsing attribute that uses "location" qualifier. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77245 Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit e65917f94e5fd13eb75f874fac4d77a29737e808)
2014-05-05glsl: Apply the link error conditions to GL_ARB_fragment_coord_conventionsAnuj Phogat2-1/+8
Link error conditions added in previous patch are equally applicable to GL_ARB_fragment_coord_conventions implementation. Extension's spec says: "If gl_FragCoord is redeclared in any fragment shader in a program, it must be redeclared in all the fragment shaders in that program that have a static use of gl_FragCoord. All redeclarations of gl_FragCoord in all fragment shaders in a single program must have the same set of qualifiers." Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 9bcb0a85321c128b6e5ff8fc6694c2eff613e65a with some manual backporting)
2014-05-05glsl: Link error if fs defines conflicting qualifiers for gl_FragCoordAnuj Phogat4-1/+105
GLSL 1.50 spec says: "If gl_FragCoord is redeclared in any fragment shader in a program, it must be redeclared in all the fragment shaders in that program that have a static use gl_FragCoord. All redeclarations of gl_FragCoord in all fragment shaders in a single program must have the same set of qualifiers." This patch causes the shader link to fail if we have multiple fragment shaders with conflicting layout qualifiers for gl_FragCoord. V2: Restructure the code and add conditions to correctly handle the following case: fragment shader 1: layout(origin_upper_left) in vec4 gl_FragCoord; void main() { foo(); gl_FragColor = gl_FragData; } fragment shader 2: layout(pixel_center_integer) in vec4 gl_FragCoord; void foo() { } V3: Allow linking in the following case: fragment shader 1: void main() { foo(); gl_FragColor = gl_FragCoord; } fragment shader 2: in vec4 gl_FragCoord; void foo() { ... } Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 35f11e85cbe82b4bb77535e84e5515a5c49f67a6 with some manual backporting)
2014-05-05glsl: Use switch to allow adding more shader typesAnuj Phogat1-13/+20
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Cc: <mesa-stable@lists.freedesktop.org>
2014-05-05glsl: Compile error if fs uses gl_FragCoord before first redeclarationAnuj Phogat1-0/+17
Section 4.3.8.1, page 39 of GLSL 1.50 spec says: "Within any shader, the first redeclarations of gl_FragCoord must appear before any use of gl_FragCoord." GLSL compiler should generate an error in following case: vec4 p = gl_FragCoord; layout(origin_upper_left) in vec4 gl_FragCoord; void main() { } Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit a751adf07117ec4b3659fe60d0a833ebfcd4f840)
2014-05-05glsl: Compile error if fs defines conflicting qualifiers for gl_FragCoordAnuj Phogat2-0/+70
GLSL 1.50 spec says: "If gl_FragCoord is redeclared in any fragment shader in a program, it must be redeclared in all the fragment shaders in that program that have a static use gl_FragCoord. All redeclarations of gl_FragCoord in all fragment shaders in a single program must have the same set of qualifiers." This patch makes the glsl compiler to generate an error if we have a fragment shader defined with conflicting layout qualifier declarations for gl_FragCoord. For example: layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord; layout(pixel_center_integer) in vec4 gl_FragCoord; void main() { } V2: Some code refactoring for better readability. Add compiler error conditions for redeclarations like: layout(origin_upper_left) in vec4 gl_FragCoord; layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord; and in vec4 gl_FragCoord; layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord; V3: Simplify function is_conflicting_fragcoord_redeclaration() V4: Check for null pointer before doing strcmp(var->name, "gl_FragCoord"). Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 581e4acb0d68eb1063df3919e19e0ef9d86eebff)
2014-05-05glsl: Allow overlapping locations for vertex input attributesAnuj Phogat1-15/+72
Currently overlapping locations of input variables are not allowed for all the shader types in OpenGL and OpenGL ES. From OpenGL ES 3.0 spec, page 56: "Binding more than one attribute name to the same location is referred to as aliasing, and is not permitted in OpenGL ES Shading Language 3.00 vertex shaders. LinkProgram will fail when this condition exists. However, aliasing is possible in OpenGL ES Shading Language 1.00 vertex shaders." Taking in to account what different versions of OpenGL and OpenGL ES specs say about aliasing: - It is allowed only on vertex shader input attributes in OpenGL (2.0 and above) and OpenGL ES 2.0. - It is explictly disallowed in OpenGL ES 3.0. Fixes Khronos CTS failing test: explicit_attrib_location_vertex_input_aliased.test See more details about this at below mentioned khronos bug. V2: Fix the case where location exceeds the maximum allowed attribute location. V3: Simplify the condition added in V2. Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org> Bugzilla: Khronos #9609 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 8c61b6a99b221439a8109c5a5cd03b7bf065d373)
2014-04-23glsl: Only allow `invariant` on shader in/out between stages.Chris Forbes1-24/+9
Previously this was special-cased for VS and FS; it never got updated when geometry shaders came along. Generalize using is_varying_var() so this won't be broken again with tessellation. Note that there are two copies of the logic for `invariant`: It can be present as part of a new declaration, and also as a redeclaration of an existing variable or block member. Fixes the four new piglits: spec/glsl-1.50/compiler/invariant-qualifier-*.geom Note for stable: This won't quite pick cleanly due to whitespace and state->target -> state->stage renames. Should be straightforward adjustments though. Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org> Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 0dfa6e7cf5a1f5207b32140f48cd3870db8a189b) Conflicts: src/glsl/ast_to_hir.cpp
2014-04-18glsl: Try vectorizing when seeing a repeated assignment to a channel.Kenneth Graunke1-0/+1
When considering assignment expressions like: v.x += u.x; v.x += u.x; the vectorizer would incorrectly keep going, attempting to find more instructions to vectorize. It would overwrite the saved assignment to point at the second one, and increment channels a second time, resulting in try_vectorize thinking the expression was a vec2 instead of a float. Instead, if we see a repeated assignment to a channel, just try to vectorize everything we've found so far. This clears the saved state so it will start over. Fixes Piglit's repeated-channel-assignments.vert. Cc: "10.1" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit ae2a03b5736037128fb071595717f300d5b3afd5)
2014-04-18glsl: Propagate explicit binding information from the AST all the way to the ↵Ian Romanick4-2/+30
linker Information about the binding was not being properly communicated from the front-end compiler to the linker. As a result, the linker never knew that any UBOs had explicit bindings! Fixes the piglit test arb_shading_language_420pack-binding-layout. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: github@socker.lepus.uberspace.de [v0] Cc: "10.1" <mesa-stable@lists.freedesktop.org> Cc: github@socker.lepus.uberspace.de (cherry picked from commit 625cf8c874950a38e7afb404345611f0fad4d490)
2014-04-18linker: Set binding for all elements of UBO arrayIan Romanick1-2/+34
Previously, a UBO like layout(binding=2) uniform U { ... } my_constants[4]; wouldn't get any bindings set. The code would try to set the binding of U, but that would fail. It should instead set the bindings for U[0], U[1], ... Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "10.1" <mesa-stable@lists.freedesktop.org> Cc: github@socker.lepus.uberspace.de (cherry picked from commit 25a66568750c5826a077cbf549de92546c5fc6cf)
2014-04-18linker: Set block bindings based on UniformBlocks rather than UniformStorageIan Romanick1-11/+21
For blocks, gl_shader_program::UniformStorage isn't very useful. The names stored there are the names of the elements of the block, so finding blocks with an instance name is hard. There is also only one entry in ::UniformStorage for each element of a block array, and that is a deal breaker. Using ::UniformBlocks is what _mesa_GetUniformBlockIndex does. I contemplated sharing code between set_block_binding and _mesa_GetUniformBlockIndex, but building the stand-alone compiler and the unit tests make this hard. I plan to return to this effort shortly. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "10.1" <mesa-stable@lists.freedesktop.org> Cc: github@socker.lepus.uberspace.de (cherry picked from commit cc42717b50bd46c82ac7925c397cd105ac82d091)
2014-04-18linker: Clean up "unused parameter" warningsIan Romanick1-8/+4
../../src/glsl/link_uniform_initializers.cpp:87:1: warning: unused parameter 'mem_ctx' [-Wunused-parameter] ../../src/glsl/link_uniform_initializers.cpp:87:1: warning: unused parameter 'type' [-Wunused-parameter] ../../src/glsl/link_uniform_initializers.cpp:127:1: warning: unused parameter 'mem_ctx' [-Wunused-parameter] ../../src/glsl/link_uniform_initializers.cpp:127:1: warning: unused parameter 'type' [-Wunused-parameter] Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "10.1" <mesa-stable@lists.freedesktop.org> Cc: github@socker.lepus.uberspace.de (cherry picked from commit 157391a41bc3e0222888d0450405867139ab4c9d)
2014-04-18glsl: Allow explicit binding on atomics againCarl Worth1-1/+3
As of 943b2d52bf5, layout(binding) on an atomic would fail the assertion here. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 92840aabf7a96583619a01a8257ef6f117f0ca50) Conflicts: src/glsl/link_uniform_initializers.cpp
2014-04-16linker: Fold set_uniform_binding into call siteIan Romanick1-21/+12
In the next patch, we'll see that using gl_shader_program::UniformStorage is not correct for uniform blocks. That means we can't use ::UniformStorage to select between the sampler path and the block path. Instead we want to just use the type of the variable. That's never passed to set_uniform_binding, and it's easier to just remove the function (especially for later patches in the series) than to add another parameter. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "10.1" <mesa-stable@lists.freedesktop.org> Cc: github@socker.lepus.uberspace.de (cherry picked from commit 943b2d52bf5df6adde3c0abcb91d9a3899476ab0)
2014-04-16linker: Various trivial clean-ups in set_sampler_bindingIan Romanick1-18/+18
- Remove the spurious block left from the previous commit and re-indent. - Constify elements. - Make the spec reference in the code look like other spec references in the compiler. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "10.1" <mesa-stable@lists.freedesktop.org> Cc: github@socker.lepus.uberspace.de (cherry picked from commit 881c52f13f4a8ca1c80ca1766238d5100ddf283b)
2014-04-16linker: Split set_uniform_binding into separate functions for blocks and ↵Ian Romanick1-3/+39
samplers The two code paths are quite different, and there are some problems in the handling of uniform blocks. Future changes will cause these paths to diverge further. Ultimately, selecting between the two functions will happen at the set_uniform_binding call site, and set_uniform_binding will be deleted. NOTE: This patch just moves code around. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "10.1" <mesa-stable@lists.freedesktop.org> Cc: github@socker.lepus.uberspace.de (cherry picked from commit 6e2f63b69e37c365094ce9bf7e2f9cd118cea01a)
2014-04-14glsl: Fix lack of i2u in lower_ubo_reference.Kenneth Graunke1-3/+7
ir_binop_ubo_load takes unsigned integer operands. However, the array index used to compute these offsets may be a signed integer. (For example, see Piglit's spec/glsl-1.40/uniform_buffer/fs-bvec-array). For some reason, we were missing an ir_binop_i2u cast, and ir_validator was failing to catch that. Without this change, ir_builder's type inference code broke for me when writing a new optimization pass. Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit e14b93371cc8394bd69622f6b60cfdf8ba177360)
2014-02-28glsl: Don't vectorize horizontal expressions.Matt Turner1-0/+15
Cc: "10.1" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75224 (cherry picked from commit 4bd7f1d044eee17587d6523322303a61aeb8d660)
2014-02-28glsl: Add is_horizontal() method to ir_expression.Matt Turner1-0/+12
Cc: "10.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 5eff8576ba274858a0b242ead97b8b5fc2b4f8ff)
2014-02-26glsl: Delete LRP_TO_ARITH lowering pass flag.Kenneth Graunke2-35/+2
Tt's kind of a trap---calling do_common_optimization() after lower_instructions() may cause opt_algebraic() to reintroduce ir_triop_lrp expressions that were lowered, effectively defeating the point. Because of this, nobody uses it. v2: Delete more code (caught by Ian Romanick). Cc: "10.1" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Acked-by: Eric Anholt <eric@anholt.net> (cherry picked from commit ac0a8b9540b29eb6faa55e4c77ba8fa99478884a)
2014-02-20glsl: Only warn for macro names containing __Ian Romanick1-3/+10
From page 14 (page 20 of the PDF) of the GLSL 1.10 spec: "In addition, all identifiers containing two consecutive underscores (__) are reserved as possible future keywords." 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. Names simply containing __ are dangerous to use, but should be allowed. Per the Khronos bug mentioned below, a future version of the GLSL specification will clarify this. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Tested-by: Darius Spitznagel <d.spitznagel@goodbytez.de> Cc: Tapani Pälli <lemody@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870 Bugzilla: Khronos #11702 (cherry picked from commit 2c85fd5a964a78c9f7a93994fb79f1723c6f45b5)
2014-02-20glcpp: Only warn for macro names containing __Ian Romanick2-5/+21
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 <ian.d.romanick@intel.com> Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Tested-by: Darius Spitznagel <d.spitznagel@goodbytez.de> Cc: Tapani Pälli <lemody@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870 Bugzilla: Khronos #11702 (cherry picked from commit 0bd78926304e72ef3566e977d0cb5a959d86b809)
2014-02-18glsl: Fix condition to generate shader link errorAnuj Phogat1-4/+5
GL_ARB_ES2_compatibility doesn't say anything about shader linking when one of the shaders (vertex or fragment shader) is absent. So, the extension shouldn't change the behavior specified in GLSL specification. Tested the behavior on proprietary linux drivers of NVIDIA and AMD. Both of them allow linking a version 100 shader program in OpenGL context, when one of the shaders is absent. Makes following Khronos CTS tests to pass: successfulcompilevert_linkprogram.test successfulcompilefrag_linkprogram.test Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 03597cf802a7a89c4853794e6206ab8ab003898d)
2014-02-18glsl: Do not vectorize vector array dereferences.Matt Turner1-0/+14
Array dereferences must have scalar indices, so we cannot vectorize them. Cc: "10.1" <mesa-stable@lists.freedesktop.org> Reported-by: Andrew Guertin <lists@dolphinling.net> Tested-by: Andrew Guertin <lists@dolphinling.net> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 025d99ce3cea21c9ecea77b95655c0c838b2fa3c)
2014-02-18glsl: Add locking to builtin_builder singletonDaniel Kurtz1-1/+10
Consider a multithreaded program with two contexts A and B, and the following scenario: 1. Context A calls initialize(), which allocates mem_ctx and starts building built-ins. 2. Context B calls initialize(), which sees mem_ctx != NULL and assumes everything is already set up. It returns. 3. Context B calls find(), which fails to find the built-in since it hasn't been created yet. 4. Context A finally finishes initializing the built-ins. This will break at step 3. Adding a lock ensures that subsequent callers of initialize() will wait until initialization is actually complete. Similarly, if any thread calls release while another thread is still initializing, or calling find(), the mem_ctx/shader would get free'd while from under it, leading to corruption or use-after-free crashes. Fixes sporadic failures in Piglit's glx-multithread-shader-compile. Bugzilla: https://bugs.freedesktop.org/69200 Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "10.1 10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit b47d231526821f5cff99546a984103a7222bc66c)
2014-02-07glsl: Don't lose precision qualifiers when encountering "centroid".Kenneth Graunke1-1/+1
Mesa fails to retain the precision qualifier when parsing: #version 300 es centroid in mediump vec2 v; Consider how the parser's type_qualifier production is applied. First, the precision_qualifier rule creates a new ast_type_qualifier: <precision: mediump> Then the storage_qualifier rule creates a second one: <flags: in> and calls merge_qualifier() to fold in any previous qualifications, returning: <flags: in, precision: mediump> Finally, the auxiliary_storage_qualifier creates one for "centroid": <flags: centroid> it then does $$ = $1 and $$.flags |= $2.flags, resulting in: <flags: centroid, in> Since precision isn't stored in the flags bitfield, it is lost. We need to instead call merge_qualifier to combine all the fields. Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reported-by: Kevin Rogovin <kevin.rogovin@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 2062f40d81de4743758851b03dad506f9cb6f306)
2014-02-07glsl: Initialize ubo_binding_mask flags to zero.Matt Turner1-0/+1
Missed in commit e63bb298. Caused sporadic test failures, like incorrect-in-layout-qualifier-repeated-prim.geom. Cc: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> (cherry picked from commit e2ef93cf94ee553e5de70a7c26fd0724d967d0b2)
2014-02-07glsl: Fix continue statements in do-while loops.Paul Berry1-9/+14
From the GLSL 4.40 spec, section 6.4 (Jumps): The continue jump is used only in loops. It skips the remainder of the body of the inner most loop of which it is inside. For while and do-while loops, this jump is to the next evaluation of the loop condition-expression from which the loop continues as previously defined. Previously, we incorrectly treated a "continue" statement as jumping to the top of a do-while loop. This patch fixes the problem by replicating the loop condition when converting the "continue" statement to IR. (We already do a similar thing in "for" loops, to ensure that "continue" causes the loop expression to be executed). Fixes piglit tests: - glsl-fs-continue-inside-do-while.shader_test - glsl-vs-continue-inside-do-while.shader_test - glsl-fs-continue-in-switch-in-do-while.shader_test - glsl-vs-continue-in-switch-in-do-while.shader_test Cc: mesa-stable@lists.freedesktop.org Acked-by: Carl Worth <cworth@cworth.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 7f5740899fe8ee2d7fecebf1b9622e06dbc78f43)
2014-02-07glsl: Make condition_to_hir() callable from outside ast_iteration_statement.Paul Berry2-7/+6
In addition to making it public, we also need to change its first argument from an ir_loop * to an exec_list *, so that it can be used to insert the condition anywhere in the IR (rather than just in the body of the loop). This will be necessary in order to make continue statements work properly in do-while loops. Cc: mesa-stable@lists.freedesktop.org Acked-by: Carl Worth <cworth@cworth.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 56790856b303ad5ba86d7eb261ade91edaa3ee0b)
2014-01-31glsl: Expand non-expr & non-swizzle scalar rvalues in vectorizing.Matt Turner1-6/+8
2014-01-31glcpp: Reject #version after the version has been resolved.Matt Turner1-0/+6
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74166 Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Carl Worth <cworth@cworth.org>
2014-01-31glcpp: Rename the variable used to enable debugging.Carl Worth1-1/+1
The -p option we now use when calling bison means that this variable will be named glcpp_parser_debug not yydebug. This was not caught when the -p option was added because this variable isn't used in the code as committed. (I prefer the declaration to remain since it allows a developer to easily find this variable name to enable debugging.)
2014-01-31glcpp: Add "make check" test for comment-parsing bugCarl Worth2-0/+5
This is the innocent-looking but killer test case to verify the bug fixed in the preceding commit. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-01-31glcpp: Don't enter lexer's NEWLINE_CATCHUP start state for single-line commentsCarl Worth1-2/+0
In commit 6005e9cb28 a new start state of NEWLINE_CATCHUP was added to the lexer. This start state is used whenever the lexer is emitting a NEWLINE token to emit additional NEWLINE tokens for any newline characters that were skipped by an immediately preceding multi-line comment. However, that commit erroneously entered the NEWLINE_CATCHUP state for single-line comments. This is not desired since in the case of a single-line comment, the lexer is not emitting any NEWLINE token. The result is that the lexer will remain in the NEWLINE_CATCHUP state and proceed to fail to emit a NEWLINE token for the subsequent newline character, (since the case to match \n expects only the INITIAL start state). The fix is quite simple, remove the "BEGIN NEWLINE_CATCHUP" code from the single-line comment case, (preserving it only in exactly the cases where the lexer is actually emitting a NEWLINE token). Many thanks to Petri Latvala for reporting this bug and for providing the minimal test case to exercise it. The bug showed up only with a multi-line comment which was followed immediately by a single-line comment (without any intervening newline), such as: /* */ // Kablam! Since 6005e9cb28, and before this commit, that very innocent-looking combination of comments would yield a parse failure in the compiler. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72686 Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-01-29glsl: s/_NDEBUG/NDEBUG/Emil Velikov1-1/+1
The former symbol is never defined within mesa. Based on the code it seems that the original intent was to use NDEBUG. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-01-27glsl: Avoid combining statements from different basic blocks.Matt Turner1-0/+35
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74113 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-01-27glsl: Set proper swizzle when a channel is missing in vectorizing.Matt Turner1-4/+13
Previously, for example if the x channel was missing from a series of assignments we were attempting to vectorize, the wrong swizzle mask would be applied. a.y = b.y; a.z = b.z; a.w = b.w; would be incorrectly transformed into a.yzw = b.xyz; Fixes two transform feedback tests in the ES3 conformance suite. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73978 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73954 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-01-27glsl: Use bitfieldInsert in ldexp() lowering.Matt Turner1-4/+10
Shaves a few instructions off of lowered ldexp(). Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-01-27glsl: Add constant evaluation of ir_binop_bfm.Matt Turner1-0/+17
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-01-27glcpp: Resolve implicit GLSL version to 100 if the API is ES.Matt Turner4-5/+16
Fixes a regression since b2d1c579 where ES shaders without a #version declaration would fail to compile if their precision declaration was wrapped in the standard #ifdef GL_ES check. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74066 Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-01-27glcpp: Check version_resolved in the proper place.Matt Turner3-13/+13
The check was in the wrong place, such that if a shader incorrectly put a preprocessor token before the #version declaration, the version would be resolved twice, leading to a segmentation fault when attempting to redefine the __VERSION__ macro. #extension GL_ARB_sample_shading: require #version 130 void main() {} Also, rename glcpp_parser_resolve_version to glcpp_parser_resolve_implicit_version to avoid confusion. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Carl Worth <cworth@cworth.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-01-27glcpp: Make sure GL_AMD_shader_trinary_minmax is definedIan Romanick1-3/+2
The define was only available if gl_extensions::AMD_shader_trinary_minmax was set, but no driver set it. Since the extension is advertised by default, remove that field too. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Cc: Maxence Le Doré <maxence.ledore@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2014-01-24glsl: Simplify built-in generator functions for min3/max3/mid3.Kenneth Graunke1-77/+60
The type of all three parameters are identical, so we don't need to specify it three times. The predicate is always identical too, so we don't need to make it a parameter, either. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-01-24glsl: Fix chained assignments of vector channels.Kenneth Graunke1-1/+19
Simple shaders such as: void splat(vec2 v, float f) { v[0] = v[1] = f; } failed to compile with the following error: error: value of type vec2 cannot be assigned to variable of type float First, we would process v[1] = f, and transform: LHS: (expression float vector_extract (var_ref v) (constant int (1))) RHS: (var_ref f) into: LHS: (var_ref v) RHS: (expression vec2 vector_insert (var_ref v) (constant int (1)) (var_ref f)) Note that the LHS type is now vec2, not a float. This is surprising, but not the real problem. After emitting assignments, this ultimately becomes: (declare (temporary) vec2 assignment_tmp) (assign (xy) (var_ref assignment_tmp) (expression vec2 vector_insert (var_ref v) (constant int (1)) (var_ref f))) (assign (xy) (var_ref v) (var_ref assignment_tmp)) We would then return (var_ref assignment_tmp) as the rvalue, which has the wrong type---it should be float, but is instead a vec2. To fix this, we simply return (vector_extract (var_ref assignment_temp) <the appropriate channel>) to pull out the desired float value. Fixes Piglit's chained-assignment-with-vector-constant-index.vert and chained-assignment-with-vector-dynamic-index.vert tests. Cc: mesa-stable@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74026 Reported-by: Dan Ginsburg <dang@valvesoftware.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2014-01-24glsl: Rename "expr" to "lhs_expr" in vector_extract munging code.Kenneth Graunke1-6/+6
When processing assignments, we have both an LHS and RHS. At a glance, "lhs_expr" clearly refers to the LHS, while a generic name like "expr" is ambiguous. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2014-01-23glcpp: Define GL_EXT_shader_integer_mix in both GL and ES.Matt Turner1-3/+5
Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-01-23glcpp: Remove unused gl_api bits.Matt Turner2-2/+0
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-01-23glcpp: Set extension defines after resolving the GLSL version.Matt Turner3-143/+172
Instead of defining preprocessor macros in glcpp_parser_create based on the GL API, wait until the shader version has been resolved. Doing this allows us to correctly set (and not set) preprocessor macros for extensions allowed by the API but not the shader, as in the case of ARB_ES3_compatibility. The shader version has been resolved when the preprocessor encounters the first preprocessor token, since the GLSL spec says "The #version directive must occur in a shader before anything else, except for comments and white space." Specifically, if a #version token is found the version is known explicitly, and if any other preprocessor token is found then the GLSL version is implicitly 1.10. Cc: mesa-stable@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71630 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-01-23glsl: Disable ARB_texture_rectangle in shader version 100.Anuj Phogat1-0/+4
OpenGL with ARB_ES2_compatibility allows shaders that specify #version 100. This fixes the Khronos OpenGL test(Texture_Rectangle_Samplers_frag.test) failure. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-25 15:14:16 +0000