I've been working a lot with #glsl for a while now, writing complex code. Overall, I feel like the single improvement that would make the most difference for the language would be support for pass-by-reference instead of copy in/copy out syntax, as suggested here https://github.com/KhronosGroup/GLSL/issues/84
This would make it possible to do a lot of things that are either not possible or ridiculously inefficient to compile, including object oriented programming.
Also one thing that should be easier to do (I imagine) if pass by reference exists, is to accept arbitrary length arrays as parameters.
Right now you can declare a local array and iterate on it with a for loop on its .length(), but you can't move that for loop to a common function that accepts various array sizes as input. The only way to avoid repeating the code is using macros, which sucks.
Again for a language that inlines everything this seems like a strange omission.
And it also has a no aliasing restriction; you can't have two names for the same variable memory and have a RW, WR, or WW hazard in the same function. https://www.w3.org/TR/WGSL/#alias-analysis
And with all that our compiler does call site specialization until it boils those pointer params away. It's convenient for the programmer but can bloat code size (hopefully no more than hand rolling it yourself)
Made another #GLSL filter for the smartphone. It is a bit frustrating to take photos with this manipulation because Safari crashes after every shot on my smartphone. OK, it's too much for the device when you push it to the limit.
I know SPIR-V is not meant for human readability and all that, but damn. Is there not any way that the variables were named anything closer to useful than %13525? I understand that it's not a one-to-one match with my glsl variables, but like... This feels like it's actively trying to obfuscate the code 🥲
Maybe there's some glslang option I don't know about that tries to make them a bit clearer?
Ha, in the light of the whole discussion around how people treated the original maintainer of #xz, I'm having a little moment of self-awareness as I complain about the features in the open source software I'm using for free, while the amazing people who actually work on it like @gfxstrand and @crzwdjk patiently explain to me why it's not that simple... 😅
@julienbarnoin You're welcome! And we do it gladly, or at least I do. As long as I can keep getting a paycheck to go along with it, I see no reason to stop.
But also, it's okay to gripe a little about things that suck. I know they suck, too. It usually only gets frustrating when people expect me to get out my magic wand and pointy hat and retroactively fix a feature that shipped 25 years ago. 😅
Learn how to change the look of the halftone pattern shader with different blend modes. View the Shadertoy demo to see it in action, and change the options.
Somehow I was under the impression that the const keyword for function parameters in #GLSL was mostly there for the benefit of programmers, so we'd get an error if we try to modify something we're not supposed to, but that the compiler would figure out if it does get modified or not on its own.
I was wrong. I have a case where just adding the const keyword to one parameter makes a shader twice as fast - from 750µs to 300µs.
Totally unexpected for me, am I the only one?
@oblomov@julienbarnoin Yes, I think? I'm having trouble parsing the original question. But it's less because of aliasing and more because GLSL doesn't have pointers/references at all. If you write
void foo(inout a, inout b) {
a = 3;
b = b + 5;
}
and then you called
x = 7;
foo(x, x);
With C or C++ reference semantics, that would turn into
@gfxstrand@julienbarnoin oh nice example, very clear (and in some sense this is an aliasing issue, although not via pointers in the traditional C sense). And it is entirely due to what can happen in a single work-item (I'm more used to work with things like OpenCL and CUDA, where, work-items can step on each other's toes). Thank you very much.
In the mathematical sense, this is is not a kaleidoscope but a conformal mapping. What they have in common with a kaleidoscope are the distortions that lead to symmetries.
(p^c-1)/(p^c+1)
This mapping (distortions of the image plane) is calculated with complex numbers. Where p are the pixel coordinates and c is a constant.
@twilliability This is roughly how one could implement this mapping in #GLSL as a fragment shader. The constants in this example are chosen somewhat arbitrarily.
The camera image comes from a USB web cam and the effect can be calculated in real time. This is a screen shot of my test / development environment.