Hi,
till now using VAR gave me quite nice speed ups. But the combination pbuffer/render_texture and VAR is awful slow. Drop from 130fps to 3 fps. Its rendered correct but too slow. (yes, i have VAR enabled in the pbuffer context 
In the VAR specification is said that a opengl context switch does a var flush, but can 2 var flushes be so expensive ?
With pbuffer only or VAR only everything works fine.
Why is the combination so slow ?
I’ve never tried with VAR, but some tips in general:
If you’re not using the latest drivers (and you’re rendering to a 2D texture), update your drivers, or don’t use WGL_ARB_render_texture and simply copy the pbuffer content to the texture.
If you’re rendering to a cube map, then pray for the next NVIDIA driver to finally fix the performance problems with render-to-cube-map, or again copy from the pbuffer to the texture yourself.
thanks for the advice, but i use the latest drivers and render to 2D texture.
And concerning the copy: well, i would prefer render_texture.
But i could try it, to see if render_texure or the pbuffer is the problem with VAR…
Has anyone tried pbuffer/render_texture with VAR ?
I have, and it works fine. The first thing that came to my mind was to enable VAR in both contexts, but you said you’ve done that already… So I’m not too sure why it is so slow…
Probably a dumb question but you’re not being kicked back to software are you?
What type of card are you using?
i use a Geforce TI4200.
how can i test if i’m kicked back to software ?
btw: i set WGL_ACCELERATION_ARB to WGL_FULL_ACCELERATION_ARB so i think it should be hardware accelerated.
i have also done some benchmarks and with simple objects the slowdown is not so extreme as for complex objects:
12 faces VA: 100 fps VAR: 90fps
800 faces VA: 100 fps VAR: 30fps
7200 faces VA: 55 fps VAR: 5fps
i’ve also found out that the
glDrawElements(GL_TRIANGLES…) command is the reason for the slowdown, it takes about 0.1 - 0.2 seconds for rendering to the pbuffer.
well, still have to try to use copy instead render_texture, but as VirtualVoid said it should work also with render_texture…
[This message has been edited by valoh (edited 01-22-2003).]
Originally posted by valoh:
how can i test if i’m kicked back to software ?
glGetString(GL_RENDERER)
and/or
glGetString(GL_VENDOR)
If one or the other (probably RENDERER?) contains ForceSW then you’ll be in Software (and there’s the good ol ‘Vendor = Micro$oft’ which I doubt you’ll find because your using VAR etc).
i set WGL_ACCELERATION_ARB to WGL_FULL_ACCELERATION_ARB so i think it should be hardware accelerated
I don’t know of any GL implementation where setting this option actually matters. Vendors enable hardware wherever they can, aggressively, to get good performance.
You said you enabled GL_VERTEX_ARRAY_RANGE_NV in both contexts, but did you also call glVertexArrayRangeNV() to establish the range in both contexts?
What does a Get of GL_VERTEX_ARRAY_RANGE_VALID_NV return?
Originally posted by jwatte:
[b]
You said you enabled GL_VERTEX_ARRAY_RANGE_NV in both contexts, but did you also call glVertexArrayRangeNV() to establish the range in both contexts?
What does a Get of GL_VERTEX_ARRAY_RANGE_VALID_NV return?[/b]
thanks ! that was the mistake, i didn’t call glVertexArrayRangeNV() for the pbuffer context.
now everything works fine.
BTW, if the pixel formats you want are the same for the pbuffer and the window, you might consider using a single render context and share it between them.
yes, i tried that (see the “state managment for pbuffer/render_texture” thread) but sharing contexts and ARB_render_texure doesn’t seem to work. The guess was because of different pixel formats by ARB_render_texure and the main window.
mhh, could you use render_texure pixel format for the window ? 
Has anybody a working solution with pbuffer/ARB_render_texture and sharing rendering contexts ?
i’ve read that the pbuffer and render_texture extensions were not that nice, but now i know why. their use is really error-prone, i had a lot of trouble with them 