>
> 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
ho
On Thu, Feb 5, 2015 at 1:31 AM, Kenneth Graunke
wrote:
> On Wednesday, February 04, 2015 01:52:57 PM Carl Worth wrote:
> > From: Kristian Høgsberg
> >
> > This code provides for an on-disk cache of objects. Objects are stored
> > and retrieved (in ~/.cache/mesa) via names that are arbitrary 20-b
>
>
>
>
>
> *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
On Sun, Jan 4, 2015 at 10:20 AM, Kenneth Graunke
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
>
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/shader
>
> > --- a/src/glsl/glsl_lexer.ll
> > +++ b/src/glsl/glsl_lexer.ll
> > @@ -232,7 +232,8 @@ HASH^{SPC}#{SPC}
> > [ \t\r]* { }
> > : return COLON;
> > [_a-zA-Z][_a-zA-Z0-9]* {
> > - yylval->identifier
: Aras Pranckevicius
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
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
>
> 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
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
>
> -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
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);
Hi,
Looking at the code, is there a potential memory leak in GLSL parser wrt
extension statements?
glsl_lexer.ll has:
[_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;
> - 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:/
>> 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;
>>
> 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 wou
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
Descri
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
> 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-a
> --- 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
h
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
> 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 oft
> 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 re
> > 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,
>
> > 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
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_swizz
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 li
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_F
> 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
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 wi
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.in
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
>
> 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
>
> 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 - currentl
Hi,
Attached patch fixes GLSL2 crash on a shader like below.
whole_variable_referenced() can return NULL if the array in question
is not a top-level variable.
struct str {
float params[3];
};
void main() {
str s;
for (int i = 0; i < 3; ++i)
s.params[i] = 1.0;
gl_FragColor = vec4(0.0);
> The strtoll() #define should be put in the imports.h file.
> Perhaps you can update your patch for today's git code.
Updated patch attached.
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
glsl-mesa-fixes-for-MSVC.patch
Description: Binary data
___
>
> > 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).
>
> 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
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
> 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_comp
(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. B
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 centu
> 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 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 he
> > 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
>
> > 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 m
>
> > 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
>
> > 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
Hi,
Attached patch fixes missing return statement in one codepath of
ir_structure_splitting
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
glsl-fix-missing-return-in-ir_structure_splitting.patch
Description: Binary data
___
m
Hi,
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.
--
Aras Pranckevičius
work: http://unity3d.com
home
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
_
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
_
> 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 anal
> 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 optim
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 t
> 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
> 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!
--
A
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://unity
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),
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
60 matches
Mail list logo
