Rendering to multiple DC
Hi,
I am writing a windows application that has multiple windows rendering an OpenGL scene simultanously, were each represents a camera.
The problem that I have is that the frame-rate drops dramatically for every additional window:
Single window - 85 fps
2 Windows - 42 fps
4 Windows - 20 fps
I think most of the extra time is spent in wglSwapBuffers into each windows'' DC. Is there a common way to handle this situation ?
Maybe single/multiple RC''s.
A friend of mine suggested that I would use viewports instead of windows, but I don''t like the idea since it means we render to a single window and I lose all the advantages of having independent separate views.
Any suggestions ?
Thanks,
------------------------------
Amos Laber
Lead 3D Developer
------------------------------
------------------------------ Amos Laber Lead 3D Developer------------------------------
I think that the speed drop is normal and that your assumption about wglSwapBuffers is false. As I understands it do you render the scene multiple times so this is doubling the work. Do some profiling.
quote:
Original post by Obelix
I think that the speed drop is normal and that your assumption about wglSwapBuffers is false. As I understands it do you render the scene multiple times so this is doubling the work. Do some profiling.
I did, and rendering time is NOT the bottleneck here. This performance drop happens also when rendering an empty scene with nothing in it.
It looks like there is no sharing of back buffers, perhaps an OpenGL pipeline problem ... In DirectX 8.0 it works very well.
------------------------------
Amos Laber
Lead 3D Developer
------------------------------
------------------------------ Amos Laber Lead 3D Developer------------------------------
You may want to look into creating a virtual-window system, with just one full-screen GL context. That way you can just use glViewport for the different windows, and only call SwapBuffers once per frame.
You should note that when you double the workload (scenes), the fps drop by half.
It''s normal, since the scenes are essencially the same.
It''s normal, since the scenes are essencially the same.
Yes, but I think he is rendering to different contexts in one loop reducing the state changes in the card.
If you are talking about wglSwapBuffer and the pipeline do I guess that you are thinking about the synchronization? This is up to the driver but it seems reasonable to assume that the second call to swapbuffer should benefit from the sync. done in the first.
Sharing back buffers seems to be difficult and I do not think that the DX8 driver does it. Do you send the vertices to the card the same way in OpenGL and DX8?
Check that you are sending data in big enough chunks.
You can try to play around adding/removing glFlush/glFinish but this can be difficult since you are forced to make assumptions about the driver. In the advanced forum at www.opengl.org do sometimes programmers from nvidia answers question. They also had a long thread about glFlush/glFinish some time ago that can be interesting.
I would follow the advice from your friend and use viewports. Adding some code so that the user can resize them seems to be easier than the above.
If you are talking about wglSwapBuffer and the pipeline do I guess that you are thinking about the synchronization? This is up to the driver but it seems reasonable to assume that the second call to swapbuffer should benefit from the sync. done in the first.
Sharing back buffers seems to be difficult and I do not think that the DX8 driver does it. Do you send the vertices to the card the same way in OpenGL and DX8?
Check that you are sending data in big enough chunks.
You can try to play around adding/removing glFlush/glFinish but this can be difficult since you are forced to make assumptions about the driver. In the advanced forum at www.opengl.org do sometimes programmers from nvidia answers question. They also had a long thread about glFlush/glFinish some time ago that can be interesting.
I would follow the advice from your friend and use viewports. Adding some code so that the user can resize them seems to be easier than the above.
Well, I think I got it.
Obelix is right about swapbuffer and the sync with screen refresh. It is possible to turn off the sync using the WGL_EXT_swap_control extension.
The results are impressive - I got the framerate back to around 70 fps with 4 windows.
Thank you all !
Obelix is right about swapbuffer and the sync with screen refresh. It is possible to turn off the sync using the WGL_EXT_swap_control extension.
The results are impressive - I got the framerate back to around 70 fps with 4 windows.
Thank you all !
------------------------------ Amos Laber Lead 3D Developer------------------------------
I was thinking about the pipeline and how the drivers would handle rendering to multiple windows. Well, if you let a monkey hack on a computer long enough will he come up with something...:D
Seems obvious now that the vsync stuff could take time if each window should wait for it.
Anyway, I just read some stuff from nvidia:
Context switching is expensive, keep it to a minimum
Try faking multiple windows by setting the viewport and scissor rectangle to restrict drawing to that sub- window
If multiple windows are necessary, try re- using a single context by binding it to separate windows
Seems obvious now that the vsync stuff could take time if each window should wait for it.
Anyway, I just read some stuff from nvidia:
Context switching is expensive, keep it to a minimum
Try faking multiple windows by setting the viewport and scissor rectangle to restrict drawing to that sub- window
If multiple windows are necessary, try re- using a single context by binding it to separate windows
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement