PDA

View Full Version : synchronization issue: reusing float target as texture



gregory38
07-28-2015, 09:52 AM
Hello,

In order to emulate the behavior of an old console, I need to emulate a mask/modulo operation after the blending. In short Cd = (Cd + Cs * As) % 256. So far my solution does the addition in a float texture and finally does a post-processing to apply the modulo. Unfortunately, if I don't call glFinish, I won't have the correct data in the 2nd pass. I kind of expect the driver to do the synchronization. I try to replace the glFinish with a gl_MemoryBarrier(GL_ALL_BARRIER_BITS) without any success. glFinish isn't a nice solution because it has a bad impact on the performance. Test were done on Nvidia Linux driver 352.21, I don't know the behavior of others drivers. So is the glFinish mandatory? or did I miss somethings?

The command in short (full detail in the attached screenshot)
1/ Create a float texture
2/ Copy RGBA8 texture into the float texture
3/ Bind the float texture as target of the FB
4/ Do the normal rendering in the float texture

5/ Call glFinish <= Otherwise my float target is corrupted (or maybe unfinished)!

6/ Bind the RGBA8 texture as target of the FB
7/ Bind the float texture as input
8/ Do the %256 postprocessing draw.


1976

Thanks for your attention.

Dark Photon
07-28-2015, 05:55 PM
7/ Bind the float texture as input
Are you doing an unconditional bind here or a lazy bind.
(Lazy bind would optimize away the glBindTexture if it saw that it was already bound.)

gregory38
07-29-2015, 04:48 AM
I'm not sure to understand what you mean. Generally speaking my code binds texture only if texture isn't already bound. However, in the current situation, glBindTextureUnit is always called because it is a newly created texture. In my first draw call, "pseudo texture" 0 (or no texture) is bound to the target.

The 2 draw calls image in a readable size
http://i.imgur.com/yxfGSnh.png

gregory38
07-29-2015, 10:52 AM
I found my issue sorry for the noise.

Due to bad ordering of my function, my internal counter of vertex offset wasn't updated properly. So the 2nd draw call overwrite the vertice of the 1st draw call...