Please help support this free site and future BRL projects!

Login or Signup

FBO + GLSL Shader Strangeness

BlitzMax Forums/BlitzMax OpenGL Programming/FBO + GLSL Shader Strangeness

tesuji(Posted 1+ years ago) #1

I'm hoping that some of those with more OpenGL experience than myself can help out here.

I've been playing around with FBOs and GLSL fragment shaders with a view to experiment with some cellular automata (starting with conway's life) and later fluid dynamic processing. Fragment shaders & FBOs show a lot of promise in this area as I can apply a per pixel algorithm off screen very fast and do it all on the GPU.

However, I've come up against an issue which is slowing progress. For some reason, my texel lookup doesn't appear reliable in that some errors are creeping in over the cause of the feedback cycle.

I've written a program which hopefully demonstrates this effect. In theory, the shader should smoothly scroll the line down without any corruption.


Bizarrely, the effect is amplified on certain GPUs. It is most noticeable on triangle boundaries but it's a lot more visible on my Intel HD3000 than it is on my Radeon 6750M

I've searched around the net for clues and my two areas of doubt are :
1) is it safe to simply overwrite the same texture with a shader or do I need to implement some sort of double buffering. Have been reading about a ping-pong technique for this sort of thing. If this is true, would be good to see a working example.
2) Perhaps I'm not specifying the uv texture coordinates correctly? I've seen a lot of different techniques for propagating this information to fragment shaders and I don't think I've a good enough grounding in OpenGL to know what's right (Max2D is my comfort zone :).

Any help would be much appreciated.

tesuji(Posted 1+ years ago) #2
Finally managed to solve it! I'll stick the solution here just in case anyone else comes across the same problem.

It was as I suspected (or at least appears to be), an issue with the lack of double buffering. Apparently you can't let shaders scribble over the same texture that's being written to without strange things happening.
Some interesting links :

Here's a reworked version with FBO double buffering added :

(Leak plugged) glsl.bmx

Last edited 1+ years ago

AdamRedwoods(Posted 1+ years ago) #3
Interesting, thanks for the examples.

GW(Posted 1+ years ago) #4
I've been playing around with this. pretty neat!

I'm guessing that if you want to run a shader on quad, the only way to do it is with FBO? other wise the shader is always drawn at global coordinates and the quad just acts as a small window.

Also, I'm not sure why, but this program leaks memory pretty badly.

tesuji(Posted 1+ years ago) #5
Not sure I understand exactly what you mean but you can use shaders without FBOs and not lose too much flexibility. My recent demo wasn't using FBOs.

FBOs do have some advantages though. The main one I'm using is the render to texture feature which allows me to process every pixel *and* record the processed result, ideal for cellular automata. Other benefits include being able to apply a shader to an area larger than the screen and also detach the texture updates from the rendering cycle. e.g. I can do 2 automata shader passes and only display 1.

eek. thanks for the spot on the leak. Initial investigation shows it's likely to be the glsl.bmx library. setUF2 etc.. don't appear to be release their resources. If I move them outside of the loop, it appears to stop leaking.
My money is on the name.ToCString() call. Will look into this further.

edit - Leakyness was indeed because of those pesky ToCString() calls. I've patched glsl.bmx with the requisite memfrees and included it in the post above. Could really do with rewriting/tidying up that module and re-releasing to the code archives. It's a bit long in the tooth. Here's a 5yr old post indicating how they got added.
Easy mistake to make when you're used to auto memory management.

Anyhow, back to work on my GLSL Life app. Still loads to do :

Last edited 1+ years ago

Last edited 1+ years ago

GW(Posted 1+ years ago) #6
Not sure I understand exactly what you mean but you can use shaders without FBOs and not lose too much flexibility

I meant that even if you set the frag shader to run with the dimensions of your dest image, the shader runs in screen space and your dest image just acts as a viewport into screenspace. As an example, make your image smaller than the window size and attach it to the mouse x/y and see what I mean.