Re: [Mesa-dev] [PATCH 0/8] Hash table and hash set reworking
With regards to cheaper hash-functions: It seems this is a case of much pain for no gain. Not sure if you looked at it, but xxHash is an extremely fast 32 bit hash function, about 2x faster than murmur https://code.google.com/p/xxhash/ -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/7] glsl: Add initial functions to implement an on-disk cache
On Thu, Feb 5, 2015 at 1:31 AM, Kenneth Graunke kenn...@whitecape.org wrote: On Wednesday, February 04, 2015 01:52:57 PM Carl Worth wrote: From: Kristian Høgsberg k...@bitplanet.net This code provides for an on-disk cache of objects. Objects are stored and retrieved (in ~/.cache/mesa) via names that are arbitrary 20-byte sequences, (intended to be SHA-1 hashes of something identifying for the content). The cache is limited to a maximum number of entries (1024 in this patch), and uses random replacement. These attributes are managed via Hi Carl, The cache will need to be much larger than 1024 entries - perhaps by an order of magnitude. For example, Shadowrun Returns uses 1299 shaders, Left 4 Dead 2 uses 1849 shaders, and Natural Selection 2 uses 2719 shaders. A single application could overflow the cache :) Seconded. Many Unity games end up loading between several hundred to several thousand shaders. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Precision qualifiers in the IR
*I see precision qualifiers being parsed and stored in the AST, but I don't see where this information is passed to the IR: ir_variable or glsl_type don't have this info, in fact, apply_type_qualifier_to_variable() in ast_to_hir.cpp seems to ignore the ast precision qualifier data completely.* Correct, precision is blissfully ignored in Mesa IR. *So I am guessing that we should add precision information to the glsl_type, but I wonder if there is a reason why this hasn't been done yet* I did add precision support for glsl-optimizer ( https://github.com/aras-p/glsl-optimizer) which is a fork of Mesa. I forgot why I did not make precision be part of the type to be honest, but I think there was some reason. Maybe because a ton of places in Mesa do things like get me a float type, and changing all these places to deal with 4x more types (unspecified, low, medium, high) did not sound attactive. So what I did is ir make ir_rvalues and ir_variables have precision (and a few other oddball things, like return type of ir_function_signature). And then in places that construct rvalues or variables, the precision is determined. In some cases that comes directly from AST, in other cases (e.g. results of optimization passes) it comes from higher precision of things being operated upon (e.g. result of a+b is higher precision of the arguments), etc. And then I tweaked some optimization passes to stop applying optimizations across different precision. For example, tree grafting should not paste subtrees into other places, if precision is different there. Not sure if my approach (precision as not part of type, but rvalues+variables) is a good one, but seems to work so far in glsl-optimizer. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Submitting more shaders to shader-db?
On Sun, Jan 4, 2015 at 10:20 AM, Kenneth Graunke kenn...@whitecape.org wrote: On Sunday 04 January 2015 09:36:40 Aras Pranckevicius wrote: Is it possible to submit more shaders into whatever shader-db is typically used by Mesa developers to test compiler optimizations on? I could package up some built-in shaders from Unity 4 / Unity 5 (which end up being used in a many, many Unity games), in the format expected by shader-db, and under whatever license is needed. Would that be useful, and if so, what are the steps to get there? Absolutely! We'd love to expand it. You can just run a program that compiles the shaders with MESA_GLSL=dump and email me the output. (MESA_GLSL=dump ./yourapp log_to_be_emailed) Since I don't even have a Linux box nearby, it would be way easier for me to change Unity source code to dump the shaders into the right format directly, and do it from a Mac (Linux Unity game builds use exactly the same shaders anyway). If you'd like them included in the public repository, I'll also need a license header saying that the shaders are freely redistributable. MIT or BSD would be fine with me; are they ok for public shader-db? -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Submitting more shaders to shader-db?
Hi, I noticed some GLSL related discussions talk My shader-db is dominated by TF2, DOTA2, Portal, Brutal Legend and Dungeon Defenders. Maybe non-Source-engine games show some benefit from this series? Now, shader-db that I can find is this: http://cgit.freedesktop.org/mesa/shader-db/tree/shaders - and it seems to have very few shaders. Is it possible to submit more shaders into whatever shader-db is typically used by Mesa developers to test compiler optimizations on? I could package up some built-in shaders from Unity 4 / Unity 5 (which end up being used in a many, many Unity games), in the format expected by shader-db, and under whatever license is needed. Would that be useful, and if so, what are the steps to get there? -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix memory leak in glsl_lexer.ll
--- a/src/glsl/glsl_lexer.ll
+++ b/src/glsl/glsl_lexer.ll
@@ -232,7 +232,8 @@ HASH^{SPC}#{SPC}
PP[ \t\r]* { }
PP: return COLON;
PP[_a-zA-Z][_a-zA-Z0-9]* {
- yylval-identifier = strdup(yytext);
+ void *ctx = yyextra;
+ yylval-identifier =
ralloc_strdup(ctx, yytext);
return IDENTIFIER;
}
PP[1-9][0-9]*{
There's another use of strdup() in this file. I assume it needs the
same treatment.
Seems like there's a memory leak at least in extension indentifiers:
http://lists.freedesktop.org/archives/mesa-dev/2013-August/044010.html
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Fixed vectorize pass vs. texture lookups
Attached patch fixes GLSL vectorization optimization going wrong on some
texture lookups, see https://bugs.freedesktop.org/show_bug.cgi?id=82574
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
From 9c592e2d0216e1b17f303be3ae1505b209abd5b3 Mon Sep 17 00:00:00 2001
From: Aras Pranckevicius a...@unity3d.com
Date: Wed, 13 Aug 2014 20:40:05 +0300
Subject: [PATCH] glsl: Fixed vectorize pass vs. texture lookups
https://bugs.freedesktop.org/show_bug.cgi?id=82574
---
src/glsl/opt_vectorize.cpp | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/glsl/opt_vectorize.cpp b/src/glsl/opt_vectorize.cpp
index 826de5f..aa24043 100644
--- a/src/glsl/opt_vectorize.cpp
+++ b/src/glsl/opt_vectorize.cpp
@@ -86,6 +86,7 @@ public:
virtual ir_visitor_status visit_enter(ir_expression *);
virtual ir_visitor_status visit_enter(ir_if *);
virtual ir_visitor_status visit_enter(ir_loop *);
+ virtual ir_visitor_status visit_enter(ir_texture *);
virtual ir_visitor_status visit_leave(ir_assignment *);
@@ -354,6 +355,18 @@ ir_vectorize_visitor::visit_enter(ir_loop *ir)
}
/**
+ * Upon entering an ir_texture, remove the current assignment from
+ * further consideration. Vectorizing multiple texture lookups into one
+ * is wrong.
+ */
+ir_visitor_status
+ir_vectorize_visitor::visit_enter(ir_texture *)
+{
+ this-current_assignment = NULL;
+ return visit_continue_with_parent;
+}
+
+/**
* Upon leaving an ir_assignment, save a pointer to it in ::assignment[] if
* the swizzle mask(s) found were appropriate. Also save a pointer in
* ::last_assignment so that we can compare future assignments with it.
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl: ideas how to improve dead code elimination?
Hi, When Mesa's GLSL compiler is faced with a code like this: // vec4 packednormal exists vec3 normal; normal.xy = packednormal.wy * 2.0 - 1.0; normal.z = sqrt(1.0 - dot(normal.xy, normal.xy)); // now do not use the normal at all anywhere Then the dead code elimination pass will not be able to eliminate the normal variable, nor anything that lead to it (possibly sampling textures into packed normal, etc.). This is because variable refcounting visitor sees normal as having four references, but only two assignments, and can not consider it dead. Even if these two references are from assignment to normal.z where both LHS RHS reference the same variable. Any ideas on how to improve this? If the original code was doing something like this, then dead code elimination is able to properly eliminate this whole thing: // vec4 packednormal exists vec3 normal; vec2 nxy = packednormal.wy * 2.0 - 1.0; float nz = sqrt(1.0 - dot(nxy, nxy)); normal.xy = nxy; normal.z = nz; // now do not use the normal at all anywhere -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glsl: should uniform initializers be allowed in GLSL ES 3.00?
While the GLSL ES 3.00 (.4) spec says (The GLSL ES 3.1 spec contains this wording too) All uniform variables are read-only. They are initialized to 0 at link time and may be updated through the API. So I think we're correct in disallowing it. Ok, fair enough. /me shakes fist at the list of removed from 3.30 GLSL spec section not mentioning it. Chalk it up to another trivial divergence of ES in unexpected way. Ian, does it seem like we can make a really trivial extension that gives you back the wording in the Desktop GLSL spec? Are there other interactions we need to think about? There's already wording explicitly disallowing initializing samplers in a shader. Probably not worth it then. Everyone will have to support no initializers case for the foreseeable future if that's what all current implementations do. Thanks for the info! -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl: should uniform initializers be allowed in GLSL ES 3.00?
Hi, Mesa's ast_to_hir.cpp does a check like: state-check_version(120, 0, initializer_loc, cannot initialize uniforms); i.e. it does not allow uniform initializers on GLSL ES 3.00. Upon my reading of the spec, I can't find any place where that would be disallowed. ES 3.00 seems to be based on GLSL 3.3, with a bunch of stuff removed and added. Uniform initializers aren't listed in the removed section (spec 3.00.4, section 1.1.4). So maybe the check should be changed to allow 300 in the ES min version? -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glsl: Improve debug output and variable names for opt_dead_code_local.
-static bool debug = false; +static bool debug = true; Accidental debug flag? -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl: vectorize pass probably needs to change types of scalar constants as well?
The new vectorization pass (added in 4bd6e0d7c69) properly changes types of
scalar dereferences. Doesn't it need to change types of scalar constants as
well?
Consider this shader:
uniform sampler2D maintex;
uniform float factor;
varying vec2 uv;
void main() {
vec4 c = texture2D(maintex, uv);
vec4 r;
r.x = max(0.123, c.x);
r.y = max(0.123, c.y);
r.z = min(c.z, factor);
r.w = min(c.w, factor);
gl_FragColor = r;
}
Scalar dereference gets properly vectorized into:
r.zw = min (c.zw, vec2(factor));
However scalar constant is vectorized into:
r.xy = max (0.123, c.xy); // type mismatch
It seems that handling ir_constant same way as ir_dereference inside
opt_vectorize.cpp rewrite_swizzle() should fix the issue.
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl: memory leak in parsing extension statements?
Hi,
Looking at the code, is there a potential memory leak in GLSL parser wrt
extension statements?
glsl_lexer.ll has:
PP[_a-zA-Z][_a-zA-Z0-9]* {
yylval-identifier = strdup(yytext);
return IDENTIFIER;
}
i.e. calls strdup on the token (there's one other place that calls strdup;
whereas most regular identifiers use ralloc_strdup for easier memory
management.
glsl_parser.yy has this:
extension_statement:
EXTENSION any_identifier COLON any_identifier EOL
{
if (!_mesa_glsl_process_extension($2, @2, $4, @4, state)) {
YYERROR;
}
}
;
which looks like it processes the extension identifiers, but never
frees the memory.
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] GLSL: fix too eager constant variable optimization
- The patch doesn't compile cleanly on master. In particular, it looks like it was made using a version of the code prior to commit 42a29d8 (glsl: Eliminate ambiguity between function ins/outs and shader ins/outs). Whoops, indeed. I made in my own modified Mesa fork (GLSL Optimizer, https://github.com/aras-p/glsl-optimizer) that's not up to date with latest master. - It seems kludgy to add a visitor for ir_function_signature that loops through all the parameters, since the default hierarchial visitor for ir_function_signature already does that. Why not just modify the ir_variable visitor so that it increments entry-assignment_count when it visits a variable whose mode is ir_var_function_in or ir_var_function_inout? (Note that the ability to distinguish between function in variables and shader in variables was added in commit 42a29d8, the commit I mentined above). Good point, that should be a better approach. Although I agree that opt_constant_variable has problems and could be improved, it seems like I must be missing some crucial piece of information here, since I can't reproduce the bug and I can't understand why your patch would have any effect. I've made a shader_runner test to try to demonstrate the problem (attached), and it works fine on mesa master as well as the 9.1, 9.0, 8.0, and 7.11 branches. Can you help me understand what I'm missing? Yeah perhaps it can't ever manifest in Mesa's context. In my fork, I'm using Mesa's GLSL compiler optimization passes to do a GLSL-to-GLSL compiler (sounds weird? it kind of is, but works around many mobile platform drivers being really, really weak at GLSL optimization). I do optimization passes very similarly to Mesa, but slightly different at places. But since it's not clear whether my improvements bring any benefit in the context of Mesa, then maybe my patch should just be ignored. And sorry for the wasted time then. Finally, in the future would you mind posting patches to the mailing list as inline text rather than attachments? (git send-email is a convenient way to do this.) Will do. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] GLSL: fix too eager constant variable optimization
opt_constant_variable was marking a variable as constant as long as there was
exactly one constant assignment to it, but did not take into account that
this
assignment might be in a dynamic branch or a loop.
Was happening on a fragment shader like this:
uniform float mode;
float func (float c) {
if (mode == 2.0)
return c; // was returning 0.1 after optimization!
if (mode == 3.0)
discard;
if (mode == 10.0)
c = 0.1;
return c;
}
void main() {
vec4 c = gl_FragCoord;
c.x = func(c.x);
gl_FragColor = c;
}
Now, looking further this optimization pass should also not mark variables as
const if there was a dereference of them before that first assignment. I had
code to do this (a hashtable that would track dereferences before assignment
is done). But couldn't come up with a test case that would break the whole
set
of optimizations that Mesa does (lower jumps, or inlining, ... were getting
in
the way and hide the bug).
I'm not sure I agree with this. The real problem with the example code you
showed
above is that there's an implicit write to the variable c at the top of the
function,
so c is not in fact constant--it's written twice. What we should really do
is modify
the optimization pass so that it's aware of the implicit write that happens
in in
and inout function args.
Attached version two of the patch which does what you suggest - any
ir_var_in, ir_var_const_in or ir_var_inout function args are being
marked as assigned to. Fixes the issue just as well as my initial
patch on several shaders that were problematic before.
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
glsl-constant-variable-fix-v2.diff
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] GLSL: fix too eager constant variable optimization
Now, looking further this optimization pass should also not mark variables as const if there was a dereference of them before that first assignment. I had code to do this (a hashtable that would track dereferences before assignment is done). But couldn't come up with a test case that would break the whole set of optimizations that Mesa does (lower jumps, or inlining, ... were getting in the way and hide the bug). I'm not sure I agree with this. The real problem with the example code you showed above is that there's an implicit write to the variable c at the top of the function, so c is not in fact constant--it's written twice. What we should really do is modify the optimization pass so that it's aware of the implicit write that happens in in and inout function args. If we resolve the implicit write issue, there should be no harm in marking variables as const if there's a dereference of them before the first assignment, because a dereference of a variable before the first assignment is undefined. Right. I'm not sure what's the correct way of making constant variable pass robust, all I know is that in it's current form it is clearly wrong. If function arguments do get marked as one write, that effectively means they will be excluded from actual optimization until the function is inlined? Maybe that's okay, no sure. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] GLSL: fix too eager constant variable optimization
Hi,
opt_constant_variable was marking a variable as constant as long as there
was exactly one constant assignment to it, but did not take into account
that this assignment might be in a dynamic branch or a loop.
Was happening on a fragment shader like this:
uniform float mode;
float func (float c) {
if (mode == 2.0)
return c; // was returning 0.1 after optimization!
if (mode == 3.0)
discard;
if (mode == 10.0)
c = 0.1;
return c;
}
void main() {
vec4 c = gl_FragCoord;
c.x = func(c.x);
gl_FragColor = c;
}
Now, looking further this optimization pass should also not mark variables
as const if there was a dereference of them before that first assignment. I
had code to do this (a hashtable that would track dereferences before
assignment is done). But couldn't come up with a test case that would break
the whole set of optimizations that Mesa does (lower jumps, or inlining,
... were getting in the way and hide the bug).
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
glsl-constant-variable-fix.diff
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] GLSL: fix lower_jumps to report progress properly
Hi, A fix for lower_jumps progress reporting, very much like similar in c1e591eed: http://cgit.freedesktop.org/mesa/mesa/commit/src/glsl/lower_variable_index_to_cond_assign.cpp?id=c1e591eed -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info glsl-lower-jumps-fix.diff Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/9] glsl: Convert mix() to use a new ir_triop_lrp opcode.
Why did glsl implement this really as x * (1 - a) + y * a? The usual way for lerp would be (y - x) * a + x, i.e. two ops for most gpus (sub+mad, or sub+mul+add). But I'm wondering if that sacrifices precision Yes. http://fgiesen.wordpress.com/2012/08/15/linear-interpolation-past-present-and-future/ -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix handling of array dereferences of vectors in opt_dead_code_local
--- a/src/glsl/opt_dead_code_local.cpp +++ b/src/glsl/opt_dead_code_local.cpp @@ -38,10 +38,73 @@ #include ir_optimization.h #include glsl_types.h -static bool debug = false; +static bool debug = true; Accidental debug flag? -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl: IR clone of ir_loop doesn't remap variable reference
Hi, Something that hit me in GLSL Optimizer (which is based on Mesa's GLSL). Cloning ir_loop just sets counter to the old counter. So in situations like: 1) loop controls are set, 2) and after that inlining happens, cloning the instructions including original variable It ends up in a situation where function body has one ir_variable object, but a loop counter there points to another ir_variable (before it was cloned). Not sure how/if that's relevant to Mesa though -- it might. I've fixed it in my tree with this: https://github.com/aras-p/glsl-optimizer/commit/c2919f69#diff-0 -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/10] glsl: Implement varying packing.
Not sure if relevant for Mesa, but e.g. on PowerVR SGX it's really bad to pack two vec2 texture coordinates into a single vec4. That's because var.xy texture read can be prefetched, whereas var.zw texture read is not prefetched (essentially treated as a dependent texture read), and often causes stalls in the shader execution. Interesting--I had not thought of that possibility. On i965 all texture reads have to be done explicitly by the fragment shader (there is no prefetching IIRC), so this penalty doesn't apply. Does anyone know if a penalty like this exists in any of Mesa's other back-ends? From what I know, it's only PowerVR SGX that is really *seriously *affected by this. On some other GPUs swizzled texture instructions cost an extra MOV and possibly count against dependent read limit - both not ideal, but not a big deal. On SGX, however, the swizzled texture loads cause texture prefetch to not happen at all, which usually stalls the shader for quite some time (SGX prefetches regular texture loads, but doesn't have good latency hiding for dependent or swizzled texture loads). Anyway, if Mesa does not have (or is not planning to) have a backend for SGX, then probably not a big deal. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/10] glsl: Implement varying packing.
For the initial implementation I've chosen a strategy that operates exclusively at the GLSL IR level, so that it doesn't require the cooperation of the driver back-ends. Wouldn't this negatively affect performance of some GPUs? Not sure if relevant for Mesa, but e.g. on PowerVR SGX it's really bad to pack two vec2 texture coordinates into a single vec4. That's because var.xy texture read can be prefetched, whereas var.zw texture read is not prefetched (essentially treated as a dependent texture read), and often causes stalls in the shader execution. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glsl hierarchical visitor: Do not overwrite base_ir for parameter lists.
This patch fixes a bug in ir_hirearchical_visitor: when traversing an exec_list representing the formal or actual parameters of a function, it modified base_ir to point to each parameter in turn, rather than leaving it as a pointer to the enclosing statement. This was a problem, since base_ir is used by visitor classes to locate the statement containing the node being visited (usually so that additional statements can be inserted before or after it). Without this fix, visitors might attempt to insert statements into parameter lists. This sure sounds like a bug, but I'm really surprised that this hasn't cause catastrophic failures before. Do you have a shader in mind that fails due to this issue? This very behavior was causing crashes in do_vec_index_to_cond_assign with an older version of Mesa (before commit 2f4fe151681a6f6afe) that I wrote about in glsl: do_vec_index_to_cond_assign not called; has problems if called thread on August 17th. After that commit do_vec_index_to_cond_assign was moved into drivers themselves, where the IR is probably low level enough that it does not cause problems. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glsl: do_vec_index_to_cond_assign not called; has problems if called
Looks like do_vec_index_to_cond_assing was lost in this commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=2f4fe151681a6f6afe1d452eece6cf4144f44e49 Converting variable indexing of vectors to conditional assignments is a lowering pass, not an optimization. We don't do it by default because some hardware may not need it. Ah ok. Now I see that it's called much later, either in the driver or in glsl_to_tgsi. Before commit 2f4fe151681 it used to be called inside the high level IR optimization loop. I ran this on the i965 driver with current Mesa master, and it ran just fine. Can you provide a backtrace from the abort in IR validate? Right, it probably does not happen anymore now that do_vec_index_to_cond_assing is called much later in the process. Move along, nothing to see here! -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl: strange looking code in ast_function.cpp
Lines 290..294 in ast_function.cpp: deref = new(ctx) ir_dereference_variable(var); ir_assignment *assign = new(ctx) ir_assignment(deref, call, NULL); instructions-push_tail(assign); deref = new(ctx) ir_dereference_variable(var); The second creation of ir_dereference_variable almost looks like some copy-paste accident. If there is a reason for it, I guess a code comment would help to figure out why. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl: do_vec_index_to_cond_assign not called; has problems if called
Looks like do_vec_index_to_cond_assing was lost in this commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=2f4fe151681a6f6afe1d452eece6cf4144f44e49
Not sure if that was intentional or not. However if I try to manually
call it like it used to be called before (just after
do_vec_index_to_swizzle), it has problems with some shaders. Same
problem I reported a while ago here:
http://lists.freedesktop.org/archives/mesa-dev/2010-August/002337.html
- but now it aborts in IR validation stage instead of crashing.
Fragment shader it has problems on:
vec2 nonInlinedFunction (vec2 a) {
if (a.x 0.0)
return -a;
return a*2.0;
}
void main() {
vec2 c = vec2(0.0);
for (int j = 0; j 2; ++j) {
c += nonInlinedFunction (vec2(vec2(0.0)[j])); // - weird, but legit
}
gl_FragColor = vec4(c,0.0,0.0);
}
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: fix matrix type check in ir_algebraic (miscompilation/asserts)
Hi,
Attached patch fixes what looks like a typo in ir_algebraic GLSL optimizations.
Vertex shader that triggers the bug:
void main() {
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
mat3 m = mat3 (0.1, 0.8, 0.1, 0.3, 0.3, 0.5, 0.9, 0.0, 0.1);
vec3 n = m * gl_Normal;
gl_FrontColor = vec4(n*0.5+0.5, 1.0);
}
(in debug build, triggers assert; miscompiled shader in release build)
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
glsl-fix-matrix-type-check-in-ir_algebraic.patch
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Any plans to add type precision to GLSL IR (glsl_type etc.)?
Hi, For GLSL optimizer (http://github.com/aras-p/glsl-optimizer) that is built on top of Mesa's GLSL2, I need to add native OpenGL ES 2.0 precision support. Looks like right now Mesa's GLSL can parse precision qualifiers just fine (when OpenGL ES 2.0 option is used), but it does not do anything with them beyond the AST. Are there any plans to add precision qualifiers to glsl_type and relevant parts of GLSL IR? (some desktop GPUs internally can operate on different precisions, and supporting that could be a performance improvement in the future) If there are no plans to support precision qualifiers beyond AST anytime soon -- are there some caveats I need to know before I try to implement it myself? Or some suggestions on how to approach the problem? Regards, -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Any plans to add type precision to GLSL IR (glsl_type etc.)?
That said, I don't think it would be difficult to add precision tracking to the IR. My first thought is that a field should be added to ir_variable to track the declared precision of the variable. A similar field should then be added to ir_rvalue to track the precision of the expression. Yeah, at first I thought about adding that to glsl_type, but that way lies madness. So I started adding it to ir_variable, ir_rvalue et al., and so far it seems to be promising (and not hard either). Thanks for confirming that I'm not on some crazy path! -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] scons: add TARGET_ARCH option
Hi, When building with SCons+MSVC, it defaults to host architecture. So on 64 bit windows 64 bit Mesa is built. Attached patch adds SCons' TARGET_ARCH option; passing TARGET_ARCH=x86 allows building 32 bit Mesa on 64 bit host. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info 0001-scons-add-TARGET_ARCH-option-for-MSVC.patch Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: fix crash in loop analysis when some loop controls can't be found
Attached patch fixes crash in GLSL loop analysis when some of the loop's
controls (e.g. from) can not be determined.
This happens on a shader like this (there's another loop between counter
initialization loop):
void main() {
float a = 0.0;
int k = 0;
for (int i = 0; i 3; ++i)
a += 1.0;
for ( ; k 3; ++k)
a += 3.0;
gl_FragColor = vec4(a);
}
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
0001-fix-crash-in-loop-analysis-when-some-of-loop-control.patch
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): mesa/st: ask GLSL to not emit noise since we have a dummy implementation
Yes, in fact, nothing seems to use the NOISE opcodes at all. Also, I can't find evidence of any hardware ever having implemented it. AMD IL has Perlin noise opcodes, but it looks like they are lowered to normal instructions since the ISA docs don't say anything about it. FWIW, HLSL in theory has noise() function, but it does not work in any real shaders (it only works in software shader kind used to fill in procedural textures aka tx_* shaders). -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [mesa 7.9-dev] Possibly incorrect OpenGL version being returned to applications?
Also, glewinfo[1] shows that there are a lot of OpenGL 2.0 and OpenGL 3.0 specific functions available - shouldn't it be OpenGL 3.0 instead of OpenGL 1.5? It can only return 3.0 if _all_ required 3.0 functionality is implemented. Similar thing exists in Apple land for example - currently all Apple drivers are OpenGL 2.1, even if they are only missing piece (GLSL 1.30) to be 3.0 compliant. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl / imports.h: fix MSVC build
Could be; I'm not actually building full Mesa (just the GLSL compiler). At least for snprintf, in MSVC it's _snprintf; no idea about others right now. Hmm, they are used by the new GLSL compiler (src/glsl/). Indeed, they are used by preprocessor (which I was not building before). Attached patch adds isspace(), strtoll() for MSVC, and fixes class vs struct mixage (MSVC really does not like class keyword when compiling C code). -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info glsl-more-preprocessor-build-fixes-for-msvc.patch Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl / imports.h: fix MSVC build
Hi, Attached patch fixes MSVC (2008) build. MSVC was still missing truncf, exp2f, log2f (all used in GLSL2). MSVC does not have trunc(), so defining truncf() to trunc() does not quite work. The _XOPEN_SOURCE usage looked pretty weird as well; it made whole that block not be included if the define is not there at all. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info glsl-fix-msvc-build.patch Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl / imports.h: fix MSVC build
Not that familiar with MSVC, but when I built Mesa on Windows the other day, other than the defines introduced by this patch, these functions were also missing: snprintf, strtoll, and isblank. Is it me or the patch that misses something? Could be; I'm not actually building full Mesa (just the GLSL compiler). At least for snprintf, in MSVC it's _snprintf; no idea about others right now. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glsl2: problem (crash) with ir_vec_index_to_cond_assign
Caveat emptor: so far I can't repro this on Linux via piglit ...
That is, I can only repro the crash in MSVC build of my GLSL2 fork.
FYI, I do get a segfault when running that shader via glsl_compiler on
Linux, so it looks like it's not something that's windows specific.
That is, glsl_compiler --dump-ast --dump-hir input.frag crashes (in
optimization phase; i.e. prints AST non optimized IR fine) on
input.frag like this:
vec2 nonInlinedFunction (vec2 a) {
if (a.x 0.0)
return -a;
return a*2.0;
}
void main() {
vec2 c = vec2(0.0);
for (int j = 0; j 2; ++j) {
c += nonInlinedFunction (vec2(vec2(0.0)[j])); // - weird, but legit
}
gl_FragColor = vec4(c,0.0,0.0);
}
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl2: problem (crash) with ir_vec_index_to_cond_assign
Hi,
I'm investigating a crash on some weird GLSL inputs. E.g. a fragment shader
like this:
vec2 nonInlinedFunction (vec2 a) {
if (a.x 0.0)
return -a;
return a*2.0;
}
void main() {
vec2 c = vec2(0.0);
for (int j = 0; j 2; ++j) {
c += nonInlinedFunction (vec2(vec2(0.0)[j])); // - weird, but legit
}
gl_FragColor = vec4(c,0.0,0.0);
}
It seems that ir_vec_index_to_cond_assign can take a single instruction and
turn that into a series of instructions. Which somehow messes up the number of
arguments that seem to be coming in for ir_call later.
Caveat emptor: so far I can't repro this on Linux via piglit, but then I'm a
Linux n00b (installed VM just today, and with all the mesa/piglit/etc. things
I'm not even sure my piglit tests are using the right mesa build... it does
not help that instructions on how to build mesa seem to be outdated or
contradicting. But I digress). That is, I can only repro the crash in MSVC
build of my GLSL2 fork.
What happens is:
* After some tree grafting pass, the weird part becomes
(call nonInlinedFunction (
(swiz xx
(array_ref (constant vec2 (0.0 0.0)) (var_ref j))
)
))
So far so good.
* Later on, ir_vec_index_to_cond_assign turns it into this:
(call nonInlinedFunction (
(declare (temp) int vec_index_tmp_i)
(assign (1) (x)
(var_ref vec_index_tmp_i)
(var_ref j)
)
(declare (temp) float vec_index_tmp_v)
(assign (expression bool == (var_ref vec_index_tmp_i) (0)) (x)
(var_ref vec_index_tmp_v)
(swiz x (constant vec2 (0.0 0.0)))
)
(assign (expression bool == (var_ref vec_index_tmp_i) (1)) (x)
(var_ref vec_index_tmp_v)
(swiz y (constant vec2 (0.0 0.0)))
)
(swiz xx (var_ref vec_index_tmp_v))
))
So at this point, it looks like a call has 6 actual arguments.
* Later on, ir_copy_propagation_visitor::visit_enter (ir_call) goes
over actual parameters and function signature parameters, and one
iterator reaches the end while another does not. Boom!
--
Aras Pranckevicius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl2: compile error on MSVC (string constant exceeds 65535 bytes)
Hi, Since commits 2f9ecc818d67 and a433cd286c60 (Add builtins profile for GLSL 1.30), GLSL2 does not compile on MSVC 2008: builtin_function.cpp(15821) : fatal error C1091: compiler limit: string exceeds 65535 bytes in length It does seem quite stupid to have 64k limit for strings in a 21st century compiler, but that's what MSVC has. Would it be possible to somehow split that string up? Or have it be generated in a more compact form? -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merge of glsl2 branch to master
Thanks for all your diligence with Windows portability. There are still some issues with MSVC but it's pretty minor stuff (e.g log2f exp2f). FYI, implementations of truncf, log2f, exp2f for MSVC in my GLSL2 fork: http://github.com/aras-p/glsl-optimizer/blob/glsl2/src/glsl/msvc/msvccompat.h (I just dumped them into a new msvccompat.h file, but for official Mesa some better place should be used I guess) -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
Like I said before, full port of talloc seems to be not needed for compiling on Visual C++; just drop in talloc.h talloc.c into the project and that's it. Same for Mac with Xcode. Be careful about LGPLv3 rules, If you are distributing anything linked with an LGPL library without accompanying source you need to dynamically link it I know. I'm just providing a MSVC/Xcode compatible talloc source file. How Mesa or some fork of Mesa includes it in the build or packages it up - I'll just leave that up to them. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
I had to rename some tokens in order to avoid collisions with windows.h defines. Aras didn't mention this problem before. I mentioned this to Eric in private conversation, but on this list I only talked about talloc specific changes. Yeah, in the glsl2 parser some tokens clash with windows headers (BOOL, INPUT etc.), and windows.h is indirectly included by Mesa's own gl.h. I've been doing renames of them in my own fork. Maybe bulk of glsl2 does not need to include that much of Mesa itself (e.g. right now you need to have things like src/mapi/mapi/u_thread.h and src/mesa/math/m_matrix.h - because they are included indirectly by something that glsl2 includes). -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? I think we learned our lesson with GLEW. Trying to keep a copy of an external dependency in our tree only leads to sadness. I have no intention to repeat that mistake. I suspect there may also be some issue with including a piece of software with such a different license in our tree. I'm not a lawyer, so I may be unnecessarily paranoid here. *shrug* Another option I was considering (mostly for my own needs; I need to use GLSL2 fork in a closed source product) is a from-scratch implementation of talloc that keeps the same interface. Similar to what Mono folks have did with glib (they wrote their own eglib that matched the license and was much smaller in the result). In my case, talloc's LGPL is quite a hassle because I have to build talloc dlls/dylibs, which complicates deployment packaging, etc. I had not time to do that yet and probably won't have in the next month or two though :( talloc is not very large, looks like just taking one .h and .c file is enough. And then there are quite a few functions that GLSL2 does not ever use. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
No, it's missing most of the API that talloc provides. Also, http://github.com/aras-p/glsl-optimizer/ ported it to windows. Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? First things first: I needed to make it compile work quickly, so I just dropped talloc.h and talloc.c into my project ( http://github.com/aras-p/glsl-optimizer/tree/glsl2/src/glsl/msvc/talloc/) and made some fixes. So I wouldn't call it a full port, but apparently it was enough without taking everything that is in official talloc tarball. However, I'm not really sure if that is legal license wise (talloc is LGPLv3). That said, the only fixes I had to do are Visual C++ specific (I'm using VS2008): - compile talloc.c as C++ (otherwise 'inline' etc. are errors on MSVC). This required wrapping talloc.h and talloc.c in extern C blocks: http://github.com/aras-p/glsl-optimizer/commit/ceee99ebe0c606de6ed093c2aec20f8ecae5b673 - vsnprintf can't be used to determine output buffer size; under MSVC _vcsprintf has to be used instead. http://github.com/aras-p/glsl-optimizer/commit/56bb0c7e7cedefcd2d149011a0b644551e080b9a - Replaced usage of MIN to TALLOC_MIN, and defined TALLOC_MIN: http://github.com/aras-p/glsl-optimizer/commit/db96499fbf874582b81dabedebc835c950520211(there's accidental line of unrelated change in that commit) Compiling on Mac with Xcode 3.2 (using gcc 4.0) required MIN-TALLOC_MIN change and compiling as C++ with extern C blocks as well. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl2: do not create __retval names (two underscores is a reserved name)
Attached patch changes __retval variable to _ret_val. According to GLSL spec, all identifiers containing two consecutive underscores are reserved as possible future keywords. Windows Radeon 5xxx drivers actually complain about this case. You definitely need something to process names to produce unique, safe names for usage in your GLSL-to-GLSL compiler. The names used internally in the compiler are not unique or safe to use as identifiers in GLSL. Yeah, I realized that patch is not directly related to Mesa just after sending it. Oh well. Otherwise, I do explicitly unique-ify the names in my GLSL-to-GLSL compiler fork (e.g. append unique postfixes to local variables after inlining, etc.). I haven't ran into other issues yet, except this double underscore thing in __retval. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glsl2: optimizing unused struct assignments
Pushed a change that cleans up the shader you pasted. Mostly. There's still some junk in it that we could do better at. Results below. Very nice, thanks! By the way, it would be useful to get some examples of your shaders as shader_runner tests in piglit. That makes them easy to analyze for optimization opportunities, and they serve as regression tests to make sure we don't break your shaders. Would you be up for making some of those? I don't quite know what piglit or shader_runner is... I guess it's stuff here: http://cgit.freedesktop.org/piglit/tree/tests/shaders ? I do have about 500 random shaders from Unity here: http://github.com/aras-p/glsl-optimizer/tree/glsl2/src/glsl/optimizer-tests/ (the *-in.txt files), but to prepare them for piglit I'd have to think up some instructions to draw something and inspect the pixel values, right? -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl2: fix inlining with samplers (iterator next() were missing)
Hi, Attached patch fixes GLSL2 inlining where samplers are involved. Broke with 199c441239762eec. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ir_function_inlining-looks-like-iterator-next-were-m.patch Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl2: do copy propagation to non-out call params
Hi, Attached patch improves GLSL2 copy propagation to non-out ir_call parameters. Seems to improve optimizations in my tests. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info do-propagation-into-non-out-call-params.patch Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl2: performance regression with import_prototypes
We were talking about this this morning, and I ended up doing a more complete fix -- most places we clone we want to be cloning into a particular place, so just pass a mem_ctx in to -clone(). Looks like it's fixed the performance problem here. Yeah, that fixed it as well. Thanks! -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glsl2: optimizing unused struct assignments
I believe the plan is to eventually break structures and arrays that are
not variably indexed into individual variables. Your structure above
would be broken into s_used and s_unused. The existing dead code paths
would take care of s_unused. We'll need to do this break-up anyway to
do proper register assignment.
Ok, nice. If someone else is going to do that I don't have to worry
about it. Any idea on when that work is planned to be done?
For the GLSL optimizer I'm working on this currently seems to be the
largest possible optimization left. On a certain mobile platform that
starts with 'i' a fragment shader like this:
struct v2f { vec4 pos; vec2 uv0; vec2 uv1; };
uniform vec4 _Color;
uniform sampler2D _Detail;
uniform sampler2D _MainTex;
varying vec4 xlv_TEXCOORD0;
varying vec4 xlv_TEXCOORD1;
void main ()
{
v2f xlt_i;
xlt_i.uv0 = xlv_TEXCOORD0.xy;
xlt_i.uv1 = xlv_TEXCOORD1.xy;
v2f i;
i = xlt_i;
vec4 c;
vec4 tmpvar_10;
tmpvar_10 = texture2D (_MainTex, i.uv0);
c = (_Color * tmpvar_10);
vec4 tmpvar_12;
tmpvar_12 = texture2D (_Detail, i.uv1);
vec4 tmpvar_13;
tmpvar_13 = ((c * tmpvar_12) * 2.00);
c = tmpvar_13;
gl_FragData[0] = tmpvar_13.xyzw;
}
Is running about 2.5X slower than the one I hand-optimize by removing
structure member moves:
// ...
void main ()
{
vec4 c;
vec4 tmpvar_10;
tmpvar_10 = texture2D (_MainTex, xlv_TEXCOORD0.xy);
c = (_Color * tmpvar_10);
vec4 tmpvar_12;
tmpvar_12 = texture2D (_Detail, xlv_TEXCOORD1.xy);
vec4 tmpvar_13;
tmpvar_13 = ((c * tmpvar_12) * 2.00);
c = tmpvar_13;
gl_FragData[0] = tmpvar_13.xyzw;
}
We'll have similar issue with code like:
uniform vec4 angles;
void main() {
vec4 v;
v.x = sin(angles.x);
v.y = cos(angles.y);
v.z = tan(angles.z);
v.w = 1/tan(angles.w);
gl_Position = v.xyxy;
}
In this case v.zw is never used, and the (expensive) assignments should
be killed.
What's the plan for attacking this? Splitting up structures into
individual variables won't help with this case.
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl2: assignment write masks vs. swizzles
Hi, Since commit 5a7758efbe14dee026245a4f4f4fb3ccf7b2c23b (Add ir_assignment::write_mask and associated methods) I'm somewhat confused about types and swizzles. Expression like this: gl_Position.zw = gl_Vertex.xy*2.0; now produces IR that has vec4 node types: (declare (temporary ) vec2 tmpvar_1) (assign (constant bool (1)) (xy) (var_ref tmpvar_1) (expression vec2 * (swiz xy (var_ref gl_Vertex))(constant float (2.0)) ) ) (assign (constant bool (1)) (zw) (var_ref gl_Position) (swiz xxxy (var_ref tmpvar_1) )) in the last two lines line, var_ref gl_Position has vec4 type, also the xxxy swizzle has vec4 type. Is that expected behavior, or something ir_assignment::set_lhs and friends don't handle correctly? If the behavior is expected, how a xxxy swizzle should be interpreted? First two components ignored because a write mask is .zw up above? Also, why vec4 node types come into play when everything in the source was vec2? -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glsl2: assignment write masks vs. swizzles
So when you say those types are vec2s above, I saw, before and after, a masked operation on the two vec4s involved when it came to actual code generated. Ok. So I assume current behavior is correct. The trouble I have now is unrelated to Mesa itself; I'm trying to use GLSL2 for a GLSL optimizer (http://github.com/aras-p/glsl-optimizer/commits/glsl2). So when the original GLSL was: gl_Position.zw = gl_Vertex.xy*2.0; and the current HIR has vec4 types and xxxy masks, my current GLSL naive printing code produces something like: gl_Position.zw = vec2((gl_Vertex.xy * 2.00).xxxy); which is obviously wrong. I'll try to adapt my printing code for the change somehow. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl2: performance regression with import_prototypes
Hi, Attached patch - or alternatively, this github commit: http://github.com/aras-p/glsl-optimizer/commit/cb5b9ad7b439eddaedc54147f41727a661d11b21 - fixes GLSL2 performance problems after many shaders are processed. When constructing builtin functions, they are put into global memory pool (once), and their prototypes cloned into current shader. However, the cloned prototype variables were still using the global memory pool, which then makes talloc_parent's O(N) complexity really visible after a while. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info 0001-import_prototypes-do-not-put-all-cloned-params-into-.patch Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl2: fix unset type of ir_discard clone
Hi, Attached patch - or alternatively, this github commit: http://github.com/aras-p/glsl-optimizer/commit/06212e35b4aa06d3cd5af27e2faa5999598f987a - fixes unset GLSL2 ir_type after cloning ir_discard node. This fixes IR validation after inlining a discard. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info 0001-set-ir_discard-type-when-cloning-it.patch Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl2: optimizing unused struct assignments
Hi,
Currently GLSL2 optimizer can't remove assignments to struct members that
are never used. After inlining, the struct is often not passed to any other
functions as a whole; and some assignments to the members might be useless.
For example, in this fragment shader assignment to s.unused could be
optimized away. I guess then whole structure (of which only s.used is left)
could be replaced with just a float temporary:
struct foo {
float used;
float unused;
};
void main() {
float f = 1.0;
foo s;
s.used = f;
s.unused = f;
gl_FragColor = vec4(s.used);
}
Right now GLSL2 optimizer optimizes the above into this (GLSL output):
struct foo {
float used;
float unused;
};
void main ()
{
foo s;
s .used = 1.00;
s .unused = 1.00;
gl_FragColor = s .used .;
}
From the code, it seems that ir_variable_refcount only tracks references to
whole variables (in this case, whole struct), and not to individual
members. Any quick ideas / pitfalls how that can be extended, before I try
to figure it out myself?
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
