Rendering to texture

NitroGL · May 26, 2001, 7:11pm

Is there a way to do this fast?

Right now I’m using glCopyTexImage2D, but this is really slow with any texture size above 64*64.

Could a P-Buffer be used in such a way to do this?

Thanks.

(BTW, I’m on a Win32 platform, if that helps any)

paddy · May 26, 2001, 9:48pm

Yeah, brother, pbuffers is was you need.
they have been made wgl extensions in the latest ati drivers, i believe also in the nvidia ones, so you must check for them using the WGL_EXT_extensions_string stuff.

NitroGL · May 26, 2001, 9:56pm

Originally posted by paddy:
Yeah, brother, pbuffers is was you need.
they have been made wgl extensions in the latest ati drivers, i believe also in the nvidia ones, so you must check for them using the WGL_EXT_extensions_string stuff.

Ok, but how? And how fast would this be?

ET3D · May 27, 2001, 6:35am

On the Radeon, only copying from pbuffer is currently optimised. On NVIDIA hardware, Matt suggested copying from the frame buffer, but pbuffer should also work.

And it’s usually recommended to use SubImage and not Image functions if you’re updating a texture.

mcraighead · May 27, 2001, 6:53am

Don’t use pbuffers unless you have to. I still strongly suggest using CopyTexSubImage from the back buffer.

Matt

NitroGL · May 27, 2001, 7:42am

Originally posted by mcraighead:
[b]Don’t use pbuffers unless you have to. I still strongly suggest using CopyTexSubImage from the back buffer.

Matt[/b]

Yeah, but that’s deathly slow (I really need something that would be near or as fast as D3D Render to Texture feature).

Zeno · May 27, 2001, 9:51am

Nitro -

This seems strange to me. A backbuffer copy of a 64x64 image using gltexsubimage2d is so fast on all the cards I have used, I hardly even notice that I’m doing it.

What card and drivers are you using? What’s the pixel format of your back buffer and your target texture?

– Zeno

NitroGL · May 27, 2001, 10:18am

Originally posted by Zeno:
[b]Nitro -

This seems strange to me. A backbuffer copy of a 64x64 image using gltexsubimage2d is so fast on all the cards I have used, I hardly even notice that I’m doing it.

What card and drivers are you using? What’s the pixel format of your back buffer and your target texture?

– Zeno[/b]

Yeah, a 6464 texture works fine (about 100+ FPS), but I would like to use a 128128 texture (so it looks better).

Currently the Pixel Format is the same (they both get rendered on the same context), 32bit color, 24bit depth, no stencil.

Radeon using 7.54.7107, with OpenGL ICD from the 7.54.7109 drivers.

Humus · May 27, 2001, 12:18pm

Originally posted by mcraighead:
[b]Don’t use pbuffers unless you have to. I still strongly suggest using CopyTexSubImage from the back buffer.

Matt[/b]

Is the actual copying faster from the backbuffer than the from a pBuffer? I mean, in case the memory usage is no issue (very few textures etc.) are there any significant advantages of using the backbuffer instead?

paddy · May 27, 2001, 12:53pm

I’m bored to see only one color of the chipmaker palette
Can any ATI guy out there give us his solution ? Jason ?

jra101 · May 27, 2001, 6:25pm

I get extremely smooth framerates using pbuffers and capturing 512x512 textures on a GeForce3 with the latest drivers.

NitroGL · May 27, 2001, 6:32pm

Originally posted by jra101:
I get extremely smooth framerates using pbuffers and capturing 512x512 textures on a GeForce3 with the latest drivers.

What drivers?

I know someone with a GF3, and the 12.40 drivers, and they don’t export the pbuffer extension…

imported_jwatte · May 27, 2001, 6:56pm

I believe Matt wants us to use the back buffer because switching between contexts might be very expensive on nVidia hardware (pbuffers are one context, the back buffer another).

However, there are cases where the back buffer needs to be used for the scene and imagery needs to be accumulated into a texture, and then pbuffers is the right solution.

jra101 · May 27, 2001, 6:57pm

I’m using 12.40 and they definitely do export the WGL_ARB_pixel_buffer and WGL_ARB_pixel_format extensions.

Jason A.
DelphiGL (http://delphigl.cfxweb.net)

cass · May 27, 2001, 7:04pm

The copy between the back buffer or a pbuffer should be roughly equivalent. The context switch costs something.

We’re looking into being able to use the same RC on a pbuffer and a window if their PFD’s are similar, but if you can use the back buffer, then it’s a good idea.

12.40 does export the pbuffer extension and all rel 1x.xx drivers have a fast glCopyTex{Sub}Image2D().

Thanks -
Cass

NitroGL · May 27, 2001, 7:04pm

Originally posted by jra101:
[b]I’m using 12.40 and they definitely do export the WGL_ARB_pixel_buffer and WGL_ARB_pixel_format extensions.

Jason A.
DelphiGL (http://delphigl.cfxweb.net)[/b]

Here’s a dump of the extensions, there aren’t any of those extensions listed.

Vendor:
NVIDIA Corporation

Renderer:
GeForce3/AGP/3DNOW!

Extensions:
GL_ARB_imaging
GL_ARB_multisample
GL_ARB_multitexture
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_dot3
GL_ARB_transpose_matrix
GL_S3_s3tc
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_compiled_vertex_array
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_packed_pixels
GL_EXT_paletted_texture
GL_EXT_point_parameters
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_shared_texture_palette
GL_EXT_stencil_wrap
GL_EXT_texture_compression_s3tc
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_EXT_texture_cube_map
GL_EXT_texture_lod
GL_EXT_texture_lod_bias
GL_EXT_texture_object
GL_EXT_vertex_array
GL_EXT_vertex_weighting
GL_IBM_texture_mirrored_repeat
GL_KTX_buffer_region
GL_NV_blend_square
GL_NV_evaluators
GL_NV_fence
GL_NV_fog_distance
GL_NV_light_max_exponent
GL_NV_packed_depth_stencil
GL_NV_register_combiners
GL_NV_register_combiners2
GL_NV_texgen_reflection
GL_NV_texture_env_combine4
GL_NV_texture_rectangle
GL_NV_texture_shader
GL_NV_vertex_array_range
GL_NV_vertex_array_range2
GL_NV_vertex_program
GL_SGIS_generate_mipmap
GL_SGIS_multitexture
GL_SGIS_texture_lod
GL_SGIX_depth_texture
GL_SGIX_shadow
GL_WIN_swap_hint
WGL_EXT_swap_control

jra101 · May 27, 2001, 7:10pm

Thats because the WGL extensions are aren’t returned by using glGetString(GL_EXTENSIONS).

You have to load the wglGetExtensionsStringARB function (load using wglGetProcAddress, if pointer is not null then extension is supported) and use it to list the WGL_ARB_… extensions.

Jason A.
DelphiGL (http://delphigl.cfxweb.net)

NitroGL · May 27, 2001, 7:13pm

Originally posted by jra101:
[b]Thats because the WGL extensions are aren’t returned by using glGetString(GL_EXTENSIONS).

You have to load the wglGetExtensionsStringARB function (load using wglGetProcAddress, if pointer is not null then extension is supported) and use it to list the WGL_ARB_… extensions.

Jason A.
DelphiGL (http://delphigl.cfxweb.net)[/b]

Aren’t those WGL extension to be exposed through glGetString still?

jra101 · May 27, 2001, 7:16pm

You would think so but for some reason they made a separate function to retrieve the WGL extensions.

Jason A.
DelphiGL (http://delphigl.cfxweb.net)

Humus · May 28, 2001, 8:41am

This is something I’ve wondered ever since I came across it … wtf … what’s the reason behind packing all new WGL extensions in a new extension string? I feel it does nothing but adding work for the developer.