summaryrefslogtreecommitdiffstats
path: root/src/glsl
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Eliminate gl_shader_program::InternalSeparateShaderIan Romanick2014-05-021-2/+1
| | | | | | | | | This was a work-around to allow linking a program with only a fragment shader in a GLES context. Now that we have GL_EXT_separate_shader_objects in GLES contexts, we can just use that. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Enable GL_EXT_separate_shader_objects for OpenGL ESIan Romanick2014-05-024-4/+9
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Sort the list of extensionsIan Romanick2014-05-022-62/+85
| | | | | | | | ARB, OES, then everything else. If there's ever a KHR shading language extension, it should go between ARB and OES. Signed-off-by: Ian Romanick <[email protected]> Acked-by: Eric Anholt <[email protected]>
* mesa: Remove support for desktop OpenGL GL_EXT_separate_shader_objectsIan Romanick2014-05-021-6/+1
| | | | | | | | | | | | | | | | I don't know of any applications that actually use it. Now that Mesa supports GL_ARB_separate_shader_objects in all drivers, this extension is just cruft. The entrypoints for the extension remain in the XML. This is done so that a new libGL will continue to provide dispatch support for old drivers that try to expose this extension. Future patches will add OpenGL ES GL_EXT_separate_shader_objects, but that's a different thing. 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-022-4/+2
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* linker: Modify cross_validate_outputs_to_inputs to match using explicit ↵Ian Romanick2014-05-022-20/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | locations This will be used for GL_ARB_separate_shader_objects. That extension not only allows separable shaders to rendezvous by location, but it also allows traditionally linked shaders to rendezvous by location. The spec says: 36. How does the behavior of input/output interface matching differ between separable programs and non-separable programs? RESOLVED: The rules for matching individual variables or block members between stages are identical for separable and non-separable programs, with one exception -- matching variables of different type with the same location, as discussed in issue 34, applies only to separable programs. However, the ability to enforce matching requirements differs between program types. In non-separable programs, both sides of an interface are contained in the same linked program. In this case, if the linker detects a mismatch, it will generate a link error. v2: Make sure consumer_inputs_with_locations is initialized when consumer is NULL. Noticed by Chia-I. v3: Rebase on removal of ir_variable::user_location. v4: Replace a (stale) FINISHME with some good explanation comments from Eric. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* linker: Sort shader I/O variables into a canonical orderIan Romanick2014-05-021-4/+74
| | | | | | | v2: Rebase on removal of ir_variable::user_location. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* linker: Allow geometry shader without vertex shader for separable programsIan Romanick2014-05-021-1/+2
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* linker: Assign varying locations for separable programsIan Romanick2014-05-022-3/+30
| | | | Signed-off-by: Ian Romanick <[email protected]>
* linker: Allow consumer stage or producer stage to be NULLIan Romanick2014-05-021-25/+46
| | | | | | | | | When linking a separable program that contains only a fragment shader, the producer will be NULL. Similar cases will exist with geometry shaders and, eventually, tessellation shaders. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* linker: Refactor code that gets an input matching an outputIan Romanick2014-05-022-17/+114
| | | | Signed-off-by: Ian Romanick <[email protected]>
* glsl: Exit when the shader IR contains an interface block instanceIan Romanick2014-05-022-31/+63
| | | | | | | | | | | While writing the link_varyings::single_interface_input test, I discovered that populate_consumer_input_sets assumes that all shader interface blocks have been lowered to discrete variables. Since there is a pass that does this, it is a reasonable assumption. It was, however, non-obvious. Make the code fail when it encounters such a thing, and add a test to verify that behavior. Signed-off-by: Ian Romanick <[email protected]>
* glsl/tests: Add first simple tests of populate_consumer_input_setsIan Romanick2014-05-022-1/+248
| | | | | | | | | | | | | | | | | | | Four initial tests: * Create an IR list with a single input variable and verify that variable is the only thing in the hash tables. * Same as the previous test, but use a built-in variable (gl_ClipDistance) with an explicit location set. * Create an IR list with a single input variable from an interface block and verify that variable is the only thing in the hash tables. * Create an IR list with a single input variable and a single input variable from an interface block. Verify that each is the only thing in the proper hash tables. Signed-off-by: Ian Romanick <[email protected]>
* linker: Refactor code that builds hash tables of varyings during linkingIan Romanick2014-05-021-20/+33
| | | | | | | | | | I want to make some changes to this code, but first I want to make some unit tests for it... so that I can capture the pre- and post-invariants. Pulling the code out into its own function in a non-anonymous namespace enables that. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* linker: Make lower_packed_varyings work with explicit locationsIan Romanick2014-05-021-1/+6
| | | | | | | | Don't do anything with variables that have explicitly assigned locations. This is also how built-in varyings are handled. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Remove varying "base" parametersIan Romanick2014-05-023-35/+20
| | | | | | | | | | In February 2013 Paul unified the values used for shader stage outputs and shader stage inputs. See commits 8a076c5f0^..eed6baf76. Since that time, the location_base parameters are always VARYING_SLOT_VAR0. Instead of passing that around, just hard code it. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Constify parameter to a couple varying_matches methodsIan Romanick2014-05-021-4/+4
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Apply the link error conditions to GL_ARB_fragment_coord_conventionsAnuj Phogat2014-05-012-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 <[email protected]> Cc: <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Link error if fs defines conflicting qualifiers for gl_FragCoordAnuj Phogat2014-05-014-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Cc: <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Compile error if fs uses gl_FragCoord before first redeclarationAnuj Phogat2014-05-011-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 <[email protected]> Cc: <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Compile error if fs defines conflicting qualifiers for gl_FragCoordAnuj Phogat2014-05-012-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 <[email protected]> Cc: <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Allow overlapping locations for vertex input attributesAnuj Phogat2014-05-011-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 <[email protected]> Cc: "9.2 10.0 10.1" <[email protected]> Bugzilla: Khronos #9609 Reviewed-by: Ian Romanick <[email protected]>
* glsl: fix spelling of derivedChris Forbes2014-04-271-1/+1
| | | | Signed-off-by: Chris Forbes <[email protected]>
* glsl: Use properly typed arguments for bitfieldInsert.Matt Turner2014-04-251-2/+2
| | | | | | | | bitfieldInsert takes scalar integers for its last two arguments. Since bitfieldInsert is lowered on i965 to two instructions that have more flexible arguments, I didn't notice when I wrote this. Reviewed-by: Ilia Mirkin <[email protected]>
* glsl: Only allow `invariant` on shader in/out between stages.Chris Forbes2014-04-221-23/+8
| | | | | | | | | | | | | | | | | | | | | 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" <[email protected]> Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Fix typoChris Forbes2014-04-211-1/+1
| | | | Signed-off-by: Chris Forbes <[email protected]>
* glsl: Allow explicit binding on atomics againChris Forbes2014-04-181-1/+3
| | | | | | | | As of 943b2d52bf5, layout(binding) on an atomic would fail the assertion here. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Small optimization for constant conditionalsIago Toral Quiroga2014-04-161-8/+2
| | | | | | | | Once the relevant branch has been identified do not iterate over the instructions in the branch, do a linked list insertion instead to avoid the loop. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Fix incorrect indentation.Iago Toral Quiroga2014-04-161-793/+782
| | | | Acked-by: Kenneth Graunke <[email protected]>
* glsl: Fix copy-paste error in linker_warning()Anuj Phogat2014-04-161-1/+1
| | | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Properly handle blocks that define the same field name.Iago Toral Quiroga2014-04-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Currently we can have name space collisions between blocks that define the same fields. For example: in block { vec4 Color; } In[]; out block { vec4 Color; } Out; These two blocks will assign the same interface name (block.Color) to the Color field in flatten_named_interface_blocks_declarations.cpp, leading to havoc. This was breaking badly the gl-320-primitive-shading test from ogl-samples. The patch uses the block instance name to avoid collisions, producing names like block.In.Color and block.Out.Color to avoid the name clash. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76394 Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Use M_PI_* macros.Matt Turner2014-04-151-7/+13
| | | | | Notice our multiple values for M_PI_2, which rounded ...32 up to ...4 and ...5.
* glsl: Fix typo in interface block commentChris Forbes2014-04-131-1/+1
| | | | Signed-off-by: Chris Forbes <[email protected]>
* glsl: Ignore loop-too-large heuristic if there's bad variable indexing.Kenneth Graunke2014-04-111-3/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many shaders use a pattern such as: for (int i = 0; i < NUM_LIGHTS; i++) { ...access a uniform array, or shader input/output array... } where NUM_LIGHTS is a small constant (such as 2, 4, or 8). The expectation is that the compiler will unroll those loops, turning the array access into constant indexing, which is more efficient, and which may enable array splitting and other optimizations. In many cases, our heuristic fails - either there's another tiny nested loop inside, or the estimated number of instructions is just barely beyond the threshold. So, we fail to unroll the loop, leaving the variable indexing in place. Drivers which don't support the particular flavor of variable indexing will call lower_variable_index_to_cond_assign(), which generates piles and piles of immensely inefficient code. We'd like to avoid generating that. This patch detects unsupported forms of variable-indexing in loops, where the array index is a loop induction variable. In that case, it bypasses the loop-too-large heuristic and forces unrolling. Improves performance in various microbenchmarks: Gl32PSBump8 by 47%, Gl32ShMapVsm by 80%, and Gl32ShMapPcf by 27%. No changes in shader-db. v2: Check ir->array for being an array or matrix, rather than the ir_dereference_array itself. v3: Fix and expand statistics in commit message. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Rename loop_unroll_count::fail to "nested_loop."Kenneth Graunke2014-04-111-4/+5
| | | | | | | | | | | The "fail" flag is set if loop_unroll_count encounters a nested loop; calling the flag "nested_loop" is a bit clearer. The original reasoning was that count is inaccurate (too small) if there are nested loops, as we don't do any sort of analysis on the inner loop. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Pass gl_shader_compiler_optimizations to unroll_loops().Kenneth Graunke2014-04-113-9/+16
| | | | | | | Loop unrolling will need to know a few more options in the future. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Drop do_common_optimization's max_unroll_iterations parameter.Kenneth Graunke2014-04-114-10/+5
| | | | | | | | | | | | Now that we pass in gl_shader_compiler_options, it makes sense to just use options->MaxUnrollIterations, rather than passing a separate parameter. Half of the invocations already passed options->MaxUnrollIterations, while the other half passed in a hardcoded value of 32. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Try vectorizing when seeing a repeated assignment to a channel.Kenneth Graunke2014-04-111-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" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* glsl: Propagate explicit binding information from the AST all the way to the ↵Ian Romanick2014-04-114-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 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <[email protected]> Tested-by: [email protected] [v0] Cc: "10.1" <[email protected]> Cc: [email protected]
* linker: Set binding for all elements of UBO arrayIan Romanick2014-04-111-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 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <[email protected]> Cc: "10.1" <[email protected]> Cc: [email protected]
* linker: Set block bindings based on UniformBlocks rather than UniformStorageIan Romanick2014-04-111-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 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <[email protected]> Cc: "10.1" <[email protected]> Cc: [email protected]
* linker: Clean up "unused parameter" warningsIan Romanick2014-04-111-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 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <[email protected]> Cc: "10.1" <[email protected]> Cc: [email protected]
* linker: Fold set_uniform_binding into call siteIan Romanick2014-04-111-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 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <[email protected]> Cc: "10.1" <[email protected]> Cc: [email protected]
* linker: Various trivial clean-ups in set_sampler_bindingIan Romanick2014-04-111-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 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <[email protected]> Cc: "10.1" <[email protected]> Cc: [email protected]
* linker: Split set_uniform_binding into separate functions for blocks and ↵Ian Romanick2014-04-111-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 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323 Reviewed-by: Kenneth Graunke <[email protected]> Cc: "10.1" <[email protected]> Cc: [email protected]
* glsl: Move tree grafting's debug output to stderr.Eric Anholt2014-04-081-15/+15
| | | | | | The rest of our compiler dumps are there, now. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Skip making a temporary for assignments when we don't need one.Eric Anholt2014-04-082-61/+123
| | | | | | | | | | | | | | | | | | While we wish our optimization passes could identify all the cases where we can coalesce our variables, we miss out on a lot of opportunities. total instructions in shared programs: 1673849 -> 1673166 (-0.04%) instructions in affected programs: 299521 -> 298838 (-0.23%) GAINED: 7 LOST: 0 Note that many programs are "hurt". The notable ones are where we produce unrolling in cases we didn't before (presumably just because of the lower instruction count). But there are also some cases where pushing things right into the variables prevents copy propagation and tree grafting, since we don't split our variable usage webs apart. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Pass ctx->Const.NativeIntegers to do_algebraic.Kenneth Graunke2014-04-084-6/+8
| | | | | | | | | The next patch will introduce an optimization that only works when integers are not represented as floating point values. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* glsl: Pass ctx->Const.NativeIntegers to do_common_optimization().Kenneth Graunke2014-04-084-5/+10
| | | | | | | | | | | The next few patches will introduce an optimization that only works when integers are not represented as floating point values. v2: Re-word-wrap a line, as requested by Ian Romanick. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* glsl: Validate that base types match for a number of binops.Kenneth Graunke2014-04-081-0/+3
| | | | | | | | | The IR is not supposed to support implicit type conversions; we just failed to validate it. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-18 09:50:33 +0000