Sign in to follow this  
Dragon_Strike

writing to texture in shader?

Recommended Posts

nope - you have to use FBOs (imho)...

...and since r/w access (bind tex as src AND SIMULTANEOUSLY attach tex to fbo as dst) isn't supported on some gpus (my 9800 PRO drops to some 0.000x fps software emulation), you have to use some custom double buffering:

GLuint src, dst; // <-- your textures

void mod(GLuint prog) {
// bind src
// attach dst to some fbo
// bind fbo
// bind prog
// blit textured quad w/ projection = ortho
// swap src w/ dst
}

Share this post


Link to post
Share on other sites
zimerman's got the right idea, but I've found that as long as you don't clear the colour buffer when using FBOs like that, you wont have to worry about things grinding to a halt. At least that's the way it is with my GeForce 2 (thanks to NVemulate helping with the FBO extensions).

Share this post


Link to post
Share on other sites
If you sample a texture and if you are trying to render to it, you will get undefined results. It doesn't matter if you use FBO or p-buffer.
If you have a source that says this is ok, I would like to see it. In principle, the GPU is a parallel processing device and you will get race conditions if you try to read and write to the same texture. DON'T do it.

Share this post


Link to post
Share on other sites
Quote:
Original post by V-man
If you sample a texture and if you are trying to render to it, you will get undefined results. It doesn't matter if you use FBO or p-buffer.
If you have a source that says this is ok, I would like to see it. In principle, the GPU is a parallel processing device and you will get race conditions if you try to read and write to the same texture. DON'T do it.


the reason i want to know this si taht as far as ive understood the geometry clipmaps gpu impelemtation uses wiring to textures in order to update the elevation map...?

Share this post


Link to post
Share on other sites
The FBO spec explicitly states that rendering to a texture and sampling from it at the same time will cause undefined results.

The fact that Renderer A seems to fall to SW, and renderer B seems to work OK, is irrevelant. Both behaviors are correct, and both implementations can change to entirely new, unpredictable behavior later (such as, with a driver update).

You MUST double buffer the texture.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this