Go to bottom

GLSL arrays

category: code [glöplog]
shiva said:
just use a texture for bob's sake. this whole high level shader language thing is so sickening.

interesting. please elaborate.
added on the 2014-07-31 16:10:02 by spike spike
I'd guess that this functionality could be emulated to a certain degree with images, combined with 2d array textures..
added on the 2014-07-31 18:56:29 by kbi kbi
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..
added on the 2014-08-01 08:32:39 by spike spike
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.
added on the 2014-08-01 18:32:33 by las las
Erm, what about SSBOs? They are slower than UBs, agreed, but still let you modify significantly large regions of memory in real time ..
added on the 2014-08-02 11:38:23 by kbi kbi
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.
added on the 2014-08-02 12:38:19 by las las
does SSBO works in WebGL ?
added on the 2014-08-03 23:07:07 by Manwe Manwe
las: Touche ;-)

Manwe: nope. Last time I checked, WebGL more or less resembled ES2 feature set.
added on the 2014-08-03 23:30:37 by kbi kbi
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/
added on the 2014-08-04 21:56:37 by linde linde
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:
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?
added on the 2014-08-05 08:00:13 by Manwe Manwe
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.
added on the 2014-08-05 14:09:52 by linde linde
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.
added on the 2014-08-05 14:12:59 by linde linde
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.).
added on the 2014-08-05 15:07:43 by Manwe Manwe


Go to top