summaryrefslogtreecommitdiffstats
path: root/src/glsl
Commit message (Collapse)AuthorAgeFilesLines
* glsl/loops: replace loop controls with a normative bound.Paul Berry2013-12-0942-239/+88
| | | | | | | | | | | | | | This patch replaces the ir_loop fields "from", "to", "increment", "counter", and "cmp" with a single integer ("normative_bound") that serves the same purpose. I've used the name "normative_bound" to emphasize the fact that the back-end is required to emit code to prevent the loop from running more than normative_bound times. (By contrast, an "informative" bound would be a bound that is informational only). Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl/loops: consolidate bounded loop handling into a lowering pass.Paul Berry2013-12-093-0/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, all of the back-ends (ir_to_mesa, st_glsl_to_tgsi, and the i965 fs and vec4 visitors) had nearly identical logic for handling bounded loops. This replaces the duplicate logic with an equivalent lowering pass that is used by all the back-ends. Note: on i965, there is a slight increase in instruction count. For example, a loop like this: for (int i = 0; i < 100; i++) { total += i; } would previously compile down to this (vec4) native code: mov(8) g4<1>.xD 0D mov(8) g8<1>.xD 0D loop: cmp.ge.f0(8) null g8<4;4,1>.xD 100D (+f0) break(8) add(8) g5<1>.xD g5<4;4,1>.xD g4<4;4,1>.xD add(8) g8<1>.xD g8<4;4,1>.xD 1D add(8) g4<1>.xD g4<4;4,1>.xD 1D while(8) loop After this patch, the "(+f0) break(8)" turns into: (+f0) if(8) break(8) endif(8) because the back-end isn't smart enough to recognize that "if (condition) break;" can be done using a conditional break instruction. However, it should be relatively easy for a future peephole optimization to properly optimize this. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: In loop analysis, handle unconditional second assignment.Paul Berry2013-12-091-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, loop analysis would set this->conditional_or_nested_assignment based on the most recently visited assignment to the variable. As a result, if a vaiable was assigned to more than once in a loop, the flag might be set incorrectly. For example, in a loop like this: int x; for (int i = 0; i < 3; i++) { if (i == 0) x = 10; ... x = 20; ... } loop analysis would have incorrectly concluded that all assignments to x were unconditional. In practice this was a benign bug, because conditional_or_nested_assignment is only used to disqualify variables from being considered as loop induction variables or loop constant variables, and having multiple assignments also disqualifies a variable from being considered as either of those things. Still, we should get the analysis correct to avoid future confusion. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Fix handling of function calls inside nested loops.Paul Berry2013-12-091-7/+7
| | | | | | | | | | | | | | | | | | | | | Previously, when visiting an ir_call, loop analysis would only mark the innermost enclosing loop as containing a call. As a result, when encountering a loop like this: for (i = 0; i < 3; i++) { for (int j = 0; j < 3; j++) { foo(); } } it would incorrectly conclude that the outer loop ran three times. (This is not certain; if foo() modifies i, then the outer loop might run more or fewer times). Fixes piglit test "vs-call-in-nested-loop.shader_test". Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Fix loop analysis of nested loops.Paul Berry2013-12-092-17/+29
| | | | | | | | | | | | | | | | | | | | Previously, when visiting a variable dereference, loop analysis would only consider its effect on the innermost enclosing loop. As a result, when encountering a loop like this: for (int i = 0; i < 3; i++) { for (int j = 0; j < 3; j++) { ... i = 2; } } it would incorrectly conclude that the outer loop ran three times. Fixes piglit test "vs-inner-loop-modifies-outer-loop-var.shader_test". Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Extract functions from loop_analysis::visit(ir_dereference_variable *).Paul Berry2013-12-092-25/+71
| | | | | | | This function is about to get more complex. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Populate gl_fragment_program::IsSample bitfieldChris Forbes2013-12-071-1/+4
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* glsl: Put `sample`-qualified varyings in their own packing classesChris Forbes2013-12-071-1/+1
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* glsl: Add ir support for `sample` qualifier; adjust compiler and linkerChris Forbes2013-12-0713-4/+60
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* glsl: Add frontend support for `sample` auxiliary storage qualifierChris Forbes2013-12-075-4/+13
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* glsl: Don't emit empty declaration warning for a struct specifierIan Romanick2013-12-061-1/+1
| | | | | | | | | | | | | | | | | The intention is that things like int; will generate a warning. However, we were also accidentally emitting the same warning for things like struct Foo { int x; }; Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68838 Reviewed-by: Kenneth Graunke <[email protected]> Cc: Aras Pranckevicius <[email protected]> Cc: "9.2 10.0" <[email protected]>
* glsl: Use fabs() on floating point values.Matt Turner2013-12-041-2/+2
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Remove silly OR(..., 0x0) from ldexp() lowering.Matt Turner2013-12-041-3/+1
| | | | | | I translated copysign(0.0f, x) a little too literally. Reviewed-by: Eric Anholt <[email protected]>
* glsl: Simplify the built-in function linking code.Kenneth Graunke2013-12-015-32/+29
| | | | | | | | | | | | | | | | | | Previously, we stored an array of up to 16 additional shaders to link, as well as a count of how many each shader actually needed. Since the built-in functions rewrite, all the built-ins are stored in a single shader. So all we need is a boolean indicating whether a shader needs to link against built-ins or not. During linking, we can avoid creating the temporary array if none of the shaders being linked need built-ins. Otherwise, it's simply a copy of the array that has one additional element. This is much simpler. This patch saves approximately 128 bytes of memory per gl_shader object. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Create an accessor for the built-in function shader.Kenneth Graunke2013-12-012-2/+13
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Drop crazy looping from no_matching_function_error().Kenneth Graunke2013-12-011-16/+23
| | | | | | | | | | | | Since the built-in functions rewrite, num_builtins_to_link is always either 0 or 1, so we don't need tho crazy loop starting at -1 with a special case. All we need to do is print the prototypes from the current shader, and the single built-in function shader (if present). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Merge "candidates are: " message to the previous line.Kenneth Graunke2013-12-011-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, when we hit a "no matching function" error, it looked like: 0:0(0): error: no matching function for call to `cos()' 0:0(0): error: candidates are: float cos(float) 0:0(0): error: vec2 cos(vec2) 0:0(0): error: vec3 cos(vec3) 0:0(0): error: vec4 cos(vec4) Now it looks like: 0:0(0): error: no matching function for call to `cos()'; candidates are: 0:0(0): error: float cos(float) 0:0(0): error: vec2 cos(vec2) 0:0(0): error: vec3 cos(vec3) 0:0(0): error: vec4 cos(vec4) This is not really any worse and removes the need for the prefix variable. It will also help with the next commit's refactoring. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Drop unused call_ir parameter from generate_call().Kenneth Graunke2013-12-011-8/+6
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Remove useless iteration through function parameters.Kenneth Graunke2013-12-011-6/+0
| | | | | | | | | There's no need to loop through the "parameters" list and remove every element; move_nodes_to(&parameters) already throws away all elements of the destination list. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Remove unused field loop_variable_state::loop.Paul Berry2013-11-291-5/+0
| | | | | | This field was neither initialized nor used. It was just dead memory. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Improve documentation of ir_loop counter/control fields.Paul Berry2013-11-291-6/+28
| | | | | Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: In ir_validate, check that ir_loop::counter always refers to a new var.Paul Berry2013-11-291-0/+13
| | | | | | | | | | | | | The compiler back-ends (i965's fs_visitor and brw_visitor, ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this for some time. Thanks to the preceding patch, the compiler front-end no longer breaks this assumption. This patch adds code to validate the assumption so that if we have future bugs, we'll be able to catch them earlier. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Fix inconsistent assumptions about ir_loop::counter.Paul Berry2013-11-293-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The compiler back-ends (i965's fs_visitor and brw_visitor, ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when ir_loop::counter is non-null, it points to a fresh ir_variable that should be used as the loop counter (as opposed to an ir_variable that exists elsewhere in the instruction stream). However, previous to this patch: (1) loop_control_visitor did not create a new variable for ir_loop::counter; instead it re-used the existing ir_variable. This caused the loop counter to be double-incremented (once explicitly by the body of the loop, and once implicitly by ir_loop::increment). (2) ir_clone did not clone ir_loop::counter properly, resulting in the cloned ir_loop pointing to the source ir_loop's counter. (3) ir_hierarchical_visitor did not visit ir_loop::counter, resulting in the ir_variable being missed by reparenting. Additionally, most optimization passes (e.g. loop unrolling) assume that the variable mentioned by ir_loop::counter is not accessed in the body of the loop (an assumption which (1) violates). The combination of these factors caused a perfect storm in which the code worked properly nearly all of the time: for loops that got unrolled, (1) would introduce a double-increment, but loop unrolling would fail to notice it (since it assumes that ir_loop::counter is not accessed in the body of the loop), so it would unroll the loop the correct number of times. For loops that didn't get unrolled, (1) would introduce a double-increment, but then later when the IR was cloned for linking, (2) would prevent the loop counter from being cloned properly, so it would look to further analysis stages like an independent variable (and hence the double-increment would stop occurring). At the end of linking, (3) would prevent the loop counter from being reparented, so it would still belong to the shader object rather than the linked program object. Provided that the client program didn't delete the shader object, the memory would never get reclaimed, and so the shader would function properly. However, for loops that didn't get unrolled, if the client program did delete the shader object, and the memory belonging to the loop counter got re-used, this could cause a use-after-free bug, leading to a crash. This patch fixes loop_control_visitor, ir_clone, and ir_hierarchical_visitor to treat ir_loop::counter the same way the back-ends treat it: as a freshly allocated ir_variable that needs to be visited and cloned independently of other ir_variables. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72026 Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Teach ir_variable_refcount about ir_loop::counter variables.Paul Berry2013-11-292-0/+22
| | | | | | | | | | | | | | | | | If an ir_loop has a non-null "counter" field, the variable referred to by this field is implicitly read and written by the loop. We need to account for this in ir_variable_refcount, otherwise there is a danger we will try to dead-code-eliminate the loop counter variable. Note: at the moment the dead code elimination bug doesn't occur due to a bug in ir_hierarchical_visitor: it doesn't visit the "counter" field, so dead code elimination doesn't treat it as a candidate for elimination. But the patch to follow will fix that bug, so we need to fix ir_variable_refcount first in order to avoid breaking dead code elimination. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Link glcpp with math library.Vinson Lee2013-11-271-1/+3
| | | | | | | | | | | | | This patch fixes this build error with Oracle Solaris Studio. libtool: link: /opt/solarisstudio12.3/bin/cc -g -o glcpp/glcpp glcpp.o prog_hash_table.o ./.libs/libglcpp.a Undefined first referenced symbol in file sqrt prog_hash_table.o Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* glsl: Initialize _mesa_glsl_parse_state::atomic_counter_offsets before using it.Francisco Jerez2013-11-261-0/+2
| | | | | | Cc: Ian Romanick <[email protected]> Cc: "10.0" <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl/linker: Validate IR just before reparenting.Paul Berry2013-11-261-0/+5
| | | | | | | | | | | | | | | | | If reparent_ir() is called on invalid IR, then there's a danger that it will fail to reparent all of the necessary nodes. For example, if the IR contains an ir_dereference_variable which refers to an ir_variable that's not in the tree, that ir_variable won't get reparented, resulting in subtle use-after-free bugs once the non-reparented nodes are freed. (This is exactly what happened in the bug fixed by the previous commit). This patch makes this kind of bug far easier to track down, by transforming it from a use-after-free bug into an explicit IR validation error. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Fix lowering of direct assignment in lower_clip_distance.Paul Berry2013-11-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 065da16 (glsl: Convert lower_clip_distance_visitor to be an ir_rvalue_visitor), we failed to notice that since lower_clip_distance_visitor overrides visit_leave(ir_assignment *), ir_rvalue_visitor::visit_leave(ir_assignment *) wasn't getting called. As a result, clip distance dereferences appearing directly on the right hand side of an assignment (not in a subexpression) weren't getting properly lowered. This caused an ir_dereference_variable node to be left in the IR that referred to the old gl_ClipDistance variable. However, since the lowering pass replaces gl_ClipDistance with gl_ClipDistanceMESA, this turned into a dangling pointer when the IR got reparented. Prior to the introduction of geometry shaders, this bug was unlikely to arise, because (a) reading from gl_ClipDistance[i] in the fragment shader was rare, and (b) when it happened, it was likely that it would either appear in a subexpression, or be hoisted into a subexpression by tree grafting. However, in a geometry shader, we're likely to see a statement like this, which would trigger the bug: gl_ClipDistance[i] = gl_in[j].gl_ClipDistance[i]; This patch causes lower_clip_distance_visitor::visit_leave(ir_assignment *) to call the base class visitor, so that the right hand side of the assignment is properly lowered. Fixes piglit test: - spec/glsl-1.50/execution/geometry/clip-distance-itemized-copy Cc: Ian Romanick <[email protected]> Cc: "9.2" <[email protected]> Cc: "10.0" <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Improve error message when attemping assignment to unsized arrayTimothy Arceri2013-11-231-2/+8
| | | | | | | | V2: Return after error to avoid cascading error messages and removed redundant "to" from error message Signed-off-by: Timothy Arceri <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Remove the ralloc canary on release builds.Eric Anholt2013-11-221-0/+6
| | | | | | | | | The canary is basically just to give a better debugging message when you ralloc_free() something that wasn't rallocated. Reduces maximum memory usage of apitrace replay of the dota2 demo by 60MB on my 64-bit system (so half that on a real 32-bit dota2 environment). Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Fix interstage uniform interface block link error detection.Paul Berry2013-11-213-32/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we checked for interstage uniform interface block link errors in validate_interstage_interface_blocks(), which is only called on pairs of adjacent shader stages. Therefore, we failed to detect uniform interface block mismatches between non-adjacent shader stages. Before the introduction of geometry shaders, this wasn't a problem, because the only supported shader stages were vertex and fragment shaders, therefore they were always adjacent. However, now that we allow a program to contain vertex, geometry, and fragment shaders, that is no longer the case. Fixes piglit test "skip-stage-uniform-block-array-size-mismatch". Cc: "10.0" <[email protected]> v2: Rename validate_interstage_interface_blocks() to validate_interstage_inout_blocks() to reflect the fact that it no longer validates uniform blocks. Reviewed-by: Jordan Justen <[email protected]> v3: Make validate_interstage_inout_blocks() skip uniform blocks. Reviewed-by: Ian Romanick <[email protected]>
* glsl: Fix cross-version linking between VS and GS.Paul Berry2013-11-211-4/+23
| | | | | | | | | | | | | | | | | | | Previously, when attempting to link a vertex shader and a geometry shader that use different GLSL versions, we would sometimes generate a link error due to the implicit declaration of gl_PerVertex being different between the two GLSL versions. This patch fixes that problem by only requiring interface block definitions to match when they are explicitly declared. Fixes piglit test "shaders/version-mixing vs-gs". Cc: "10.0" <[email protected]> v2: In the interface_block_definition constructor, move the assignment to explicitly_declared after the existing if block. Reviewed-by: Ian Romanick <[email protected]>
* glsl: Prohibit illegal mixing of redeclarations inside/outside gl_PerVertex.Paul Berry2013-11-215-1/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From section 7.1 (Built-In Language Variables) of the GLSL 4.10 spec: Also, if a built-in interface block is redeclared, no member of the built-in declaration can be redeclared outside the block redeclaration. We have been regarding this text as a clarification to the behaviour established for gl_PerVertex by GLSL 1.50, so we apply it regardless of GLSL version. This patch enforces the rule by adding an enum to ir_variable to track how the variable was declared: implicitly, normally, or in an interface block. Fixes piglit tests: - gs-redeclares-pervertex-out-after-global-redeclaration.geom - vs-redeclares-pervertex-out-after-global-redeclaration.vert - gs-redeclares-pervertex-out-after-other-global-redeclaration.geom - vs-redeclares-pervertex-out-after-other-global-redeclaration.vert - gs-redeclares-pervertex-out-before-global-redeclaration - vs-redeclares-pervertex-out-before-global-redeclaration Cc: "10.0" <[email protected]> v2: Don't set "how_declared" redundantly in builtin_variables.cpp. Properly clone "how_declared". Reviewed-by: Ian Romanick <[email protected]>
* glsl: Use more portable bash invocation construct.Vinson Lee2013-11-2026-26/+26
| | | | | | | | | Fixes 'make check' on distros where bash is not at /bin/bash. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Tested-by: Ian Romanick <[email protected]>
* glsl: cleanup, remove duplicate assignmentTapani Pälli2013-11-171-1/+0
| | | | | Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Apply the transformation "1/rsq(x) == sqrt(x)" in opt_algebraic.Eric Anholt2013-11-151-3/+4
| | | | | | | | | | | | | The comment was stale, because the lowering in question wasn't happening in lower_instructions.cpp. Presumably if the lowering ever moves there, we can plumb the lowering mask through to opt_algebraic. total instructions in shared programs: 1618696 -> 1616810 (-0.12%) instructions in affected programs: 243018 -> 241132 (-0.78%) GAINED: 0 LOST: 0 Reviewed-by: Jordan Justen <[email protected]>
* glsl: Apply the transformation "(a ^^ a) -> false" in opt_algebraic.Eric Anholt2013-11-151-1/+3
| | | | Reviewed-by: Jordan Justen <[email protected]>
* glsl: Apply the transformation "(a && a) -> a" in opt_algebraic.Eric Anholt2013-11-151-1/+3
| | | | Reviewed-by: Jordan Justen <[email protected]>
* glsl: Apply the transformation "(a || a) -> a" in opt_algebraic.Eric Anholt2013-11-151-1/+3
| | | | | | | | | | | total instructions in shared programs: 1732385 -> 1732373 (-0.00%) instructions in affected programs: 416 -> 404 (-2.88%) GAINED: 0 LOST: 0 (That's 4 already-short fragment shaders in dota2) Reviewed-by: Jordan Justen <[email protected]>
* glsl: Move the CSE equality functions to the ir class.Eric Anholt2013-11-154-179/+222
| | | | | | | | I want to reuse them in opt_algebraic. v2: Merge in Chris Forbes's break fix. Reviewed-by: Jordan Justen <[email protected]>
* glsl: Rework interface block linking.Paul Berry2013-11-151-20/+251
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, when doing intrastage and interstage interface block linking, we only checked the interface type; this prevented us from catching some link errors. We now check the following additional constraints: - For intrastage linking, the presence/absence of interface names must match. - For shader ins/outs, the interface names themselves must match when doing intrastage linking (note: it's not clear from the spec whether this is necessary, but Mesa's implementation currently relies on it). - Array vs. nonarray must be consistent, taking into account the special rules for vertex-geometry linkage. - Array sizes must be consistent (exception: during intrastage linking, an unsized array matches a sized array). Note: validate_interstage_interface_blocks currently handles both uniforms and in/out variables. As a result, if all three shader types are present (VS, GS, and FS), and a uniform interface block is mentioned in the VS and FS but not the GS, it won't be validated. I plan to address this in later patches. Fixes the following piglit tests in spec/glsl-1.50/linker: - interface-blocks-vs-fs-array-size-mismatch - interface-vs-array-to-fs-unnamed - interface-vs-unnamed-to-fs-array - intrastage-interface-unnamed-array v2: Simplify logic in intrastage_match() for handling array sizes. Make extra_array_level const. Use an unnamed temporary interface_block_definition in validate_interstage_interface_blocks()'s first call to definitions->store(). Cc: "10.0" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* glsl: fix missing breaks in equals(ir_texture,..)Chris Forbes2013-11-101-0/+2
| | | | | | Signed-off-by: Chris Forbes <[email protected]> Cc: "10.0" <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Linker support for ARB_shader_atomic_counters.Francisco Jerez2013-11-074-1/+306
| | | | | | | | | | | | | | | v2: Add comments on the purpose of the auxiliary data structures. Check for atomic counter overlaps. Use the contains_atomic() convenience method. Add static assert with the number of expected shader stages. v3: Don't resize atomic arrays. v4: Add comment on the reason why we don't resize atomic counter arrays. Use 'strcmp(...) == 0' instead of '!strcmp(...)'. v5 (idr): Don't use STL in the linker. Signed-off-by: Francisco Jerez <[email protected]> Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Implement parser support for atomic counters.Francisco Jerez2013-11-076-6/+103
| | | | | | | | | | | | | | | | v2: Mark atomic counters as read-only variables. Move offset overlap code to the linker. Use the contains_atomic() convenience method. v3: Use pointer to integer instead of non-const reference. Add comment so we remember to add a spec quotation from the next GLSL release once the issue of atomic counter aggregation within structures is clarified. v4 (idr): Don't use std::map because it's overkill. Add an assertion that ctx->Const.MaxAtomicBufferBindings <= MAX_COMBINED_ATOMIC_BUFFERS. Signed-off-by: Francisco Jerez <[email protected]> Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Enable dFdx, dFdy, and fwidth by default in GLSL ES 3.00.Kenneth Graunke2013-11-071-1/+2
| | | | | | | | | | | | | | | Previously, we only exposed them in desktop GL or with: #extension GL_OES_standard_derivatives : enable GLSL ES 3.00 includes these without an extension, so we need to expose them by default. Note that the above #extension line results in an error or desktop GL, so we don't need to worry about this. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* glsl: Don't generate misleading debug names when packing gs inputs.Paul Berry2013-11-041-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | Previously, when packing geometry shader input varyings like this: in float foo[3]; in float bar[3]; lower_packed_varyings would declare a packed varying like this: (declare (shader_in flat) (array ivec4 3) packed:foo[0],bar[0]) That's confusing, since the packed varying acutally stores all three values of foo and all three values of bar. This patch causes it to generate the more sensible declaration: (declare (shader_in flat) (array ivec4 3) packed:foo,bar) Note that there should be no functional change for users of geometry shaders, since the packed name is only used for generating debug output. But this should reduce confusion when using INTEL_DEBUG=gs. Reviewed-by: Eric Anholt <[email protected]>
* glsl: Add new builtins required by GL_ARB_sample_shadingAnuj Phogat2013-11-011-0/+18
| | | | | | | | | | | | | | | | New builtins added by GL_ARB_sample_shading: in vec2 gl_SamplePosition in int gl_SampleID in int gl_NumSamples out int gl_SampleMask[] V2: - Use SWIZZLE_XXXX for STATE_NUM_SAMPLES. - Use "result.samplemask" in arb_output_attrib_string. - Add comment to explain the size of gl_SampleMask[] array. - Make gl_SampleID and gl_SamplePosition system values. Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Add infrastructure for GL_ARB_sample_shadingAnuj Phogat2013-11-014-0/+7
| | | | | | | | | | | This patch implements the common support code required for the GL_ARB_sample_shading extension. V2: Move GL_ARB_sample_shading to ARB extension list. Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Ken Graunke <[email protected]>
* glsl: Add a CSE pass.Eric Anholt2013-11-015-0/+608
| | | | | | | | | | | | | | | | | | | | | | | | This only operates on constant/uniform values for now, because otherwise I'd have to deal with killing my available CSE entries when assignments happen, and getting even this working in the tree ir was painful enough. As is, it has the following effect in shader-db: total instructions in shared programs: 1524077 -> 1521964 (-0.14%) instructions in affected programs: 50629 -> 48516 (-4.17%) GAINED: 0 LOST: 0 And, for tropics, that accounts for most of the effect, the FPS improvement is 11.67% +/- 0.72% (n=3). v2: Use read_only field of the variable, manually check the lod_info union members, use get_num_operands(), rename cse_operands_visitor to is_cse_candidate_visitor, move all is-a-candidate logic to that function, and call it before checking for CSE on a given rvalue, more comments, use private keyword. Reviewed-by: Paul Berry <[email protected]>
* glsl: fix MSVC int->bool conversion warningBrian Paul2013-10-311-1/+1
|