5

I'm writing an OpenGL program that draws into an Auxiliary Buffer, then the content of the Auxiliary Buffer is accumulated to the Accumulation Buffer before being GL_RETURN-ed to the Back buffer (essentially to be composited to the screen). In short, I'm doing sort of a motion blur. However the strange thing is, when I recompile and rerun my program, I was seeing the content of the Auxiliary/Accumulation Buffer from the previous program runs. This does not make sense. Am I misunderstanding something, shouldn't OpenGL's state be completely reset when the program restarts?

I'm writing an SDL/OpenGL program in Gentoo Linux nVidia Drivers 195.36.31 on GeForce Go 6150.

Lie Ryan
  • 62,238
  • 13
  • 100
  • 144

2 Answers2

10

No - there's no reason for your GPU to ever clear its memory. It's your responsibility to clear out (or initialize) your textures before using them.

EboMike
  • 76,846
  • 14
  • 164
  • 167
  • Thanks, at least now I know that it's not an unexpected behavior, though it is just creepy... – Lie Ryan Nov 06 '10 at 08:38
  • 1
    I agree. Want to add: under some conditions video drivers are requested to zero-init the allocated memory, because of "security" considerations (evil program may want to know what others were drawing). This is ridiculous (I'd say that should be the responsibility of that program that wants to conceal its intermediate output), but this is how things are. – valdo Nov 06 '10 at 10:17
  • 1
    I did a lot of Direct3D through the DirectX9 era. When I started, framebuffers, surfaces etc would invariably be uninitialized and code could easily expose the contents of a previous run. At some point, either Microsoft or the driver providers must have decided to "fix" this and you'd get blanked buffers instead. I believe it was done in the name of security. I'd say the security concerns are valid; we wouldn't tolerate a system which handed user processes RAM containing other user's uncleared debris and the framebuffer RAM shouldn't be regarded differently. – timday Nov 13 '10 at 13:45
  • Note that it's also very cheap. GPU memory is fast, and you don't exactly allocate a new framebuffer thousands of times per second. – jalf Nov 13 '10 at 15:03
5

Actually, the OpenGL state is initialized to well-defined values.

However, the GL state consists of settings like all binary switches (glEnable), blending, depth test mode... etc, etc. Each of those has its default settings, which are described in OpenGL specs and you can be sure that they will be enforced upon context creation.

The point is, the framebuffer (or texture data or vertex buffers or anything) is NOT a part of what is called "GL state". GL state "exists" in your driver. What is stored in the GPU memory is totally different thing and it is uninitialized until you ask the driver (via GL calls) to initialize it. So it's completely possible to have the remains of previous run in texture memory or even in the frame buffer itself if you don't clear or initialize it at startup.

Kos
  • 70,399
  • 25
  • 169
  • 233