i use FBO with large textures (2048x2048, GL_RGBA16F_ARB). when i attach only one, everything is fine, when i attach two such big textures, then i get GL_FRAMEBUFFER_UNSUPPORTED_EXT. when i use two 2048x1024 textures, it is ok.
now the funny thing is, when i use arb_texture_rectangle instead of texture_2d (texture internal format GL_FLOAT_R16_NV), then i can attach two 2048x2048 textures without any problems.
Maybe you have run into some memory limit. 2048x2048 RGBA16F texture consumes aproximatelly 33MB of memory while texture with FLOAT_R16_NV format consums quarter (or half on GF FX) of that memory.
You can try to increase AGP aperture size if it is 64MB and see if that helps.
Originally posted by Komat: Maybe you have run into some memory limit. 2048x2048 RGBA16F texture consumes aproximatelly 33MB of memory while texture with FLOAT_R16_NV format consums quarter (or half on GF FX) of that memory.
You can try to increase AGP aperture size if it is 64MB and see if that helps.
When you run out of memory, everything runs very very slow but it still runs. The error must be somewhere else.
When you run out of memory, everything runs very very slow but it still runs.
Not necessary. Each OpenGL command may theoretically generate OUT_OF_MEMORY error if memory was exhousted as a side effect of the execution of a command and result of that command is undefined in that situation (GLspec 2 chapter 2.5).
The FBO extensions allows to return FRAMEBUFFER_UNSUPPORTED_EXT if there is problem with implementation-dependent limitation instead of having to implement fallback into sw rendering in that case, which is imho better behaviour than the “must run even if at horrible fps” one.
Because of this is reasonable to expect that if driver can not fit the texture wherever it needs to for hardware to support rendering into it or simply because another path was not implemented in the driver, it is implementation-dependent limitation and FRAMEBUFFER_UNSUPPORTED_EXT will be returned.
it is out of memory problem. but opengl doesn’t throw this error after creating textures and not even after attaching them to FBO…
in previous post i also mentioned, that my app hangs, when resizing window. now i use only one 2048x2048 and two 1024x1024 GL_RGBA16F_ARB textures and the app runs, but as said before it some times hangs. with gDEBugger i found out, that it hangs on glClear command saying OUT_OF_MEMORY, but only some times. why can be this? i only create textures once, attach them to FBO and then render to them, do ping-ponging… why it could suddenly get out of memory without allocating annything?
ps: when we will have FBO extension for single channel FP textures, that can be used as render targets? as i need to port my app to ATi cards, i can’t use arb_texture_rectnagle and NV_float_buffer, which is runnig perfectly on nVidia cards.
it is out of memory problem. but opengl doesn’t throw this error after creating textures and not even after attaching them to FBO…
I assume that driver is trying to be nice to the application. Many applications do not check ordinary error channel while it is likely that they will check for FBO completeness status. Additionaly behaviour of operation is undefined if OUT_OF_MEMORY is generated while behaviour on completeness check failure is defined so this is more clean and imho more appropriate way to report this problem.
that it hangs on glClear command saying OUT_OF_MEMORY, but only some times. why can be this? i only create textures once, attach them to FBO and then render to them, do ping-ponging… why it could suddenly get out of memory without allocating annything?
Your OS may have additional memory allocated for its own purposes and ammount of this memory may change if you manipulate with the window. Additionaly driver may allocate additional memory for example to store copy of input data (e.g. content of vertex arrays if VBO are not used) or to prevent stall (e.g. if VBO you are uploading into is still used by hw)
Because your textures are really big the driver may have problems organizing memory to fit all necessary stuf into it especially if rendering into texture is likely to lock that entire texture at its memory address until hw is done with it.