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:
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)
*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 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
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
--- 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 =
: 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
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 list
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
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:
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
- 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,
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
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
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
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
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.
--- 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:
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 often
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
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
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
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
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
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;
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
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,
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:
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 - currently
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).
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
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
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
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
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
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
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
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
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.
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 process names
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
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
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
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
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
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
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
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
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:
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
56 matches
Mail list logo
