GLSL Minifier Open Sourced

[Roy Williams]

Hey guys,

Some of you may have seen this at WebGL Camp, but I just open sourced
our GLSL Minifier/Compiler. This helps you minimize your payloads and
obfuscate your code. You can play with it here:

http://glslunit.appspot.com/compiler.html

It works for all of the ShaderToy examples, and usually results in a
50%-60% reduction in code size. The shader toy examples aren't
actually great examples for compression because they tend to be
sparsely commented and use short variable/function names already, but
we still see a 30% reduction in code size. Give it a try and let me
know if you're running into any issues.

Thanks,
Roy

[David Sheets]

Hi Roy,

I was playing with your processor and ran into some issues.

Here is a reduced shader I would like to compile:
int h() { return 0; }
int g() { return 255; }
#define g h
void main(){ g(); }

And here is the generated code:
int a(){return 255;}
#define g h
void main(){a();}

Is full preprocessor support planned?

Cheers,

David Sheets

[Benoit Jacob]

A GLSL minifier can definitely be very useful in the context of WebGL.

I am more doubtful about the obfuscation part: most practical shaders
are very short and self-contained programs, so I don't see anything
that can prevent disassembly from being entirely successful and easy.
This isn't specific to WebGL, affects equally OpenGL and Direct3D.

Cheers,
Benoit

2012/1/4 Roy Williams <rowi...@google.com>:

[Patrick Cozzi]

Roy,

I'm really excited to see this. Are there any plans to support GLSL
libraries, that is, shaders with just structs and functions? In this
case, structs and their fields cannot be renamed nor can functions be
renamed or removed, but comments/whitespace and the function
implementations can be minified. This is useful for those of us that
procedurally create shaders on the client from multiple GLSL
libraries.

Also, do you have any stats on if minification improves compile time
since I assume the GLSL optimizer has less work to do?

Regards,
Patrick

On Jan 4, 6:00 pm, Benoit Jacob <jacob.benoi...@gmail.com> wrote:
> A GLSL minifier can definitely be very useful in the context of WebGL.
>
> I am more doubtful about the obfuscation part: most practical shaders
> are very short and self-contained programs, so I don't see anything
> that can prevent disassembly from being entirely successful and easy.
> This isn't specific to WebGL, affects equally OpenGL and Direct3D.
>
> Cheers,
> Benoit
>

> 2012/1/4 Roy Williams <rowil...@google.com>:

[Roy Williams]

Hey David,

Right now it doesn't do any sort of preprocessesing. That was sort of
intended because it's fairly common to add in defines at runtime.
That said...this kind of problem is unfortunately a victim of this. I
was actually looking to see if I could port cpp to LLVM and then use
emscripten to run the preprocessor.

Thanks for trying it out!
Roy

[Roy Williams]

Totally, and true obfuscation would bloat your code. Maybe
obfuscation was too strong of a word in the initial email. This is
going for the Closure or Uglify style of obfuscation which stops the
casual copy paster. Obfuscation is really just a side benefit to the
minification.

On Jan 4, 3:00 pm, Benoit Jacob <jacob.benoi...@gmail.com> wrote:
> A GLSL minifier can definitely be very useful in the context of WebGL.
>
> I am more doubtful about the obfuscation part: most practical shaders
> are very short and self-contained programs, so I don't see anything
> that can prevent disassembly from being entirely successful and easy.
> This isn't specific to WebGL, affects equally OpenGL and Direct3D.
>
> Cheers,
> Benoit
>

> 2012/1/4 Roy Williams <rowil...@google.com>:

[Roy Williams]

Thanks Patrick! I started looking at libraries today actually.
ThreeJS _sort of_ has the idea of libraries with code snippets and I
was looking into what it would take to minify their shaders. You've
got the right idea, we can just disable the phases that aren't library
compatible. I'm really interested in helping to minify ThreeJS since
it's almost 335kb (100kb compressed) now which is massive for the most
popular WebGL library (It's taking nearly 500ms just to download the
ThreeJS library for me on a great connection at Google).

I haven't actually looked to see if it speeds up compilation yet. The
only true optimization we're doing now is dead function removal,
everything else is just minification. When we start getting fancier
with inlining I expect to see a nice performance boost.

I recently discovered the compiler chokes on structs. I'll get that
patched today or this weekend.

[Roy Williams]

Hi All,

I just wanted to update this thread since I recently addressed a bunch of issues brought up here.

David, we now have full preprocessor support.  Your example above now outputs:

int a(){return 0;}void main(){a();}

Which I'm pretty sure is what you expected.  The compiler now has the concept of "Modes".  A Mode is a preprocessor definition that we're letting the compiler know could possibly be declared at runtime.  A good example of this would be Vertex Texture Fetch.  Perhaps you've got a shader with two paths controlled by ifdefs, one that assumes VTF is there, one that works without it.  We would then define something like "VTF" as a mode and we could use

#ifdef VTF

...

#endif

in our shader code and the compiler would know not to optimize away preprocessor branches with "VTF" in them since we're allowing that to be defined at runtime.

There isn't great documentation on Modes yet, working on that now.

Patrick,  We've recently added library support.  See https://code.google.com/p/glsl-unit/source/browse/#git%2Fexample%2Fcompiler and http://code.google.com/p/glsl-unit/wiki/CompilerPreprocessor.  Right now, our library checked in is closely tied with Closure, but it's all controlled by a template.  You could create a new template to fit in with whatever library/build system you're using, so you could write a requires.js template if you wanted to.

--
As a New Year's resolution, I'll be trying out empty inbox for the next month.  I will only be checking email in the morning, after lunch, and before I leave.  If you need me sooner than that, IM or call.