wglShareLists and multiple render windows

Started by
12 comments, last by steven katic 15 years, 11 months ago
Quote:Original post by steven katic
Quote:
Yes, that is correct.
In general, like the previous person said it's better to just have 1 window with multiple views just like 3dS max does and many other CAD and content creation software.

now you are confusing me.

apparently, 3ds max used to be a slightly different beast again:


Sorry for using 3dS max as an example since you seemed to have read some in depth material about it and it is rather lengthy.

All I'm saying is that instead of having 2 windows, just make 1, use half of the window for 1 thing and the other half for something else.
Multithreading not required.

If that is not possible for you then I think the previous answers here cover all your questions.
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Advertisement
Quote:
It addresses the first issue: state management. You won't be needing to keep track of states for different rendering contexts since all states reside in a single context. It simplifies the design to some extent. Of course, you'd be needing some form of state management to cull redundant states.


come on now...you should be careful...it sounds like you are clutching at straws to justify its use to me - there is no need to justify any of your actions. I am here to discuss...not to convince..or to otherwise be convinced of anything.

Having said that I'lI continue to be blunt:
I fail to see any reason in that statement, let alone a compelling one to cease the use of wglShareLists() the way I do.

All I see there is a statement that applies equally to the shared contexts implementation I have. The major difference being that I have a context switch statement as the first statement in my viewport rendering function. In fact it is probably the only code wise difference to be had (I guess my implementation just happens to be organised in such a way by chance that allows me to say that i.e. point is it depends on you application implementation).OOps - should be real easy to just change it over to the one context multiple window method then!!! I put my foot in it now hey?

I can give you an example of how simple it works if you like?

In the meantime, if I were to try and convince you of anything..it would be to go with the 1 context with multiple windows - I actually want to know how it compares - but I'm to lazy to do the research! (But you have to be kind enough to share what you have learnt from it with us....*gulp*

V-man
Quote:
Sorry for using 3dS max as an example since you seemed to have read some in depth material about it and it is rather lengthy.


I found it in a galaxy far, far away,... long ago, and the haze is temporarily lifting from my memory, so I have to type quickly...before it returns!(this is now a memory... of a memory...of a memeory...of a mem.. unfortunately). It is probably ONE of the real reasons that prompted me to go with the multiple shared contexts concept. I had a soft spot for 3dsMax long ago and had to find out everything I could about how they implemented there multitude of windows. Being such a powerful premium product of choice was compelling enough a reason to attempt to emulate bits of it; Perhaps not much empirical rigor in that logic at all hey? Then the little boy grew up a little, hopefully.
Rather lengthy you say? Nah... Hey what do you think I read that stuff? It's reference material, scan it for info like I do, don't read it!

Quote:
All I'm saying is that instead of having 2 windows, just make 1, use half of the window for 1 thing and the other half for something else.
Multithreading not required.


yeah well....its not the contents(it may be dated info?) of that 3dsMax document that is important, it is its possible level of credibility that is important compared to your statement about 3dsMax.

[Edited by - steven katic on May 10, 2008 4:37:48 PM]
Quote:Original post by steven katic
Quote:
It addresses the first issue: state management. You won't be needing to keep track of states for different rendering contexts since all states reside in a single context. It simplifies the design to some extent. Of course, you'd be needing some form of state management to cull redundant states.


come on now...you should be careful...it sounds like you are clutching at straws to justify its use to me - there is no need to justify any of your actions. I am here to discuss...not to convince..or to otherwise be convinced of anything.


It's not like I'll win a free trip to moon if I manage to convince you?! I can't believe how you started getting so defensive all of a sudden after being so helpful all the way. I was just expressing my opinion for the sake of discussion and I don't see any reason to start getting hostile. If you're not convinced that managing one rendering context instead of several is both easier and more convinient, so be it. We have different opinions, big deal. Even if I was blindly insisting on a falacy, which I was *not*... well, it's my loss if I want to act blindly and there's no need for you to get defensive over it.

Thank you both of you guys for sharing your knowledge with me.
Something you may find interesting Ashkan:
I thought I would start a little investigating into the notorious expense of opengl render context switching vs 1 context + multiple device contexts.

I also said:
Quote:
OOps - should be real easy to just change it over to the one context multiple window method then!!! I put my foot in it now hey?


And it is true: All I did is the following:
private: System::Void ShareGLContexts(){   /**** (A)changed this ***********************/   // get the contexts to share resources   HGLRC c1 = m_OpenglViewports[0]->GetContext();   HGLRC c2 = m_OpenglViewports[1]->GetContext();   HGLRC c3 = m_OpenglViewports[2]->GetContext();   HGLRC c4 = m_OpenglViewports[3]->GetContext();   // whats with the going overboard with sharing both ways?: could be a problem.   if(!wglShareLists( c1,c2  ) || !wglShareLists( c3,c2  ) ||       !wglShareLists( c4,c2  ) || !wglShareLists( c2,c1  ) ||      !wglShareLists( c2,c3  ) || !wglShareLists( c2,c4  ) )   {      bGLContextShared = false;   }   /* (B)to this: *************************/   // 4 devices sharing one render context test   		    HGLRC c1 = m_OpenglViewports[0]->GetContext();			   m_OpenglViewports[1]->SetContext(c1);   m_OpenglViewports[2]->SetContext(c1);   m_OpenglViewports[3]->SetContext(c1);}


So far in testing nothing has changed: not even my fps metric of 260(or so I thought).
I tried out gDebugger for more reliable metrics and it records the following:
Option (A) 4 shared render contexts: 130 fps.[edited: 15th may 08 only 2 contexts where mesured!]
(Edit 15th may 08: Option(A) 4 shared contexts where all 4 where measured (65 fps per context)
Option (B) 1 render context shared among 4 DCs 260 fps.


Now that might be potentially compelling (so far). But something is not right (e.g. My fps counter?, or the way I use gDebugger is not right?). I need to continue testing, but with more rigor before making conclusions just yet. I must say gDebugger's metrics/testing options are very impressive (and very quick and easy to use).

Something of maybe more interest Ashkan, may be talk from here:
Quote:
...today with FBOs, there's no reason to use more than one context per GPU. You either just don't need it(no Pbuffers anymore) or got something else wrong (there' s no point in talking to the same gfx cards from two threads concurrently)....


FBO specs (and other docs) do mention FBO superiority to and substitution for context switching. Apparently different precision depths(you mention) can be achieved if you delve further into the use of FBOs. However, I have my doubts about FBO as suitable for multi windows (could it be a square peg for a round whole?): meaning "try it see" tests are required (there are 2 typical uses of FBOs, mutli windows is not one of them, as far as I can tell so far).

Hope this tentative speculation has been of interest.

[Edited by - steven katic on May 15, 2008 5:59:04 AM]

This topic is closed to new replies.

Advertisement