.png)
GLSL arrays
category: code [glöplog]
shiva said:
interesting. please elaborate.
Quote:
just use a texture for bob's sake. this whole high level shader language thing is so sickening.
interesting. please elaborate.
I'd guess that this functionality could be emulated to a certain degree with images, combined with 2d array textures..
well yes, actually i was more curious about the second sentence - shiva was usually quite pro-GL. I'm wondering if his approach was to actually avoid/minimize usage of glsl :)
I should check his Mole3d i guess..
I should check his Mole3d i guess..
Some time ago things were a bit different.
People were used to use texture based LUTs to avoid computations.
Nowadays you have quite some massive compute power and a bit more constant buffer/uniform memory (~64k).
Nevertheless, the stack thing from some posts above might affect the performance of your shader massively when used multiple times, since that piece of code will most likely produce some register pressure.
People were used to use texture based LUTs to avoid computations.
Nowadays you have quite some massive compute power and a bit more constant buffer/uniform memory (~64k).
Nevertheless, the stack thing from some posts above might affect the performance of your shader massively when used multiple times, since that piece of code will most likely produce some register pressure.
Erm, what about SSBOs? They are slower than UBs, agreed, but still let you modify significantly large regions of memory in real time ..
In global memory.
But yeah, if you know what you are doing you can do some really fancy stuff with SSBOs / images (Hi khronos guys... you did run out of names there right? "images", seriously? Even DirectX has a better name for that stuff.) or other global memory access primitives.
Shared memory can also be a very useful thing when implementing certain algorithms.
But yeah, if you know what you are doing you can do some really fancy stuff with SSBOs / images (Hi khronos guys... you did run out of names there right? "images", seriously? Even DirectX has a better name for that stuff.) or other global memory access primitives.
Shared memory can also be a very useful thing when implementing certain algorithms.
does SSBO works in WebGL ?
las: Touche ;-)
Manwe: nope. Last time I checked, WebGL more or less resembled ES2 feature set.
Manwe: nope. Last time I checked, WebGL more or less resembled ES2 feature set.
Manwe, you shouldn't move the whole stack, just the stack pointer. If you are implementing Forth Haiku or something similar, the needed stack size can also be known at compile time. I have an implementation for something similar here: http://06bacb42fe3bdfbd.paste.se/
linde, you're right, I'm working on the new Forth Haiku translator. I'll check your code, thank you.
Of course, I tried to change just the stack pointer first. The stack size was a constant. But this code wouldn't work in WebGL:
Because GLSL ES 2 don't like a variable as an array's index. Change "i++" to 0, 1 and 2 - everything will fine. Also, "i++" works in HLSL.
What's wrong with my code?
Of course, I tried to change just the stack pointer first. The stack size was a constant. But this code wouldn't work in WebGL:
Code:
void main()
{
float d[16]; int i=0; // stack
d[i++]=x;
d[i++]=y;
d[i++]=abs(sin(t));
gl_FragColor = vec4(d[0], d[1], d[2] 1.0);
}Because GLSL ES 2 don't like a variable as an array's index. Change "i++" to 0, 1 and 2 - everything will fine. Also, "i++" works in HLSL.
What's wrong with my code?
I can't say what's wrong (I'm a GLSL noob) but my approach was that since there is no branching, even the stack position after each word is knowable before running, I just used a set of separate variables for each possible stack index and cycle through them at [forth to GLSL] compile time. I.e. the compiler takes care of stack management altogether, and there is no need for the shader program worry about a stack.
You could as well use an array (where I used separate variables) with this approach and avoid copying data or touching the stack index at run time.
Thanks for suggestions, linde. I'll try to find a balance between the shader's size and speed, as well as a balance between the translator's size and speed. At this point I like to keep Forth's philosophy right in shader (stack emulation, user defined words as functions, etc.).