Hi Gerrit, On 23.11.2011 12:54, Gerrit Voß wrote: > > Hi, > > On Wed, 2011-11-23 at 12:32 +0100, "Christoph Fünfzig" wrote: >> Hi Carsten, >> >> On 22.11.2011 18:44, Carsten Neumann wrote: >>> Hello Christoph, >>> >>> On 11/21/2011 11:27 AM, "Christoph Fünfzig" wrote: >>>>> I want to do >>>>> singleton->passiveWin[id]->render (singleton->action[id]); >>>>> in several threads on the same aspect. >>> hmm, may I ask why? That sounds like it would cause quite bad thrashing >>> on the driver/GPU side... >>> >> >> I have never looked into driver code ;) But it would cover the >> traversal/culling time of the scenegraph. >> It is mentioned here >> http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html >> so would like to try it out among the other possibilities :) > > on a stage level we already support what is described under 2. where > complete stages can have their OpenGL commands executed while the > main traversal continues to run in parallel. > >>>>> In method RenderPartition::dropFunctor(DrawFunctor&, State*, Int32, bool) >>>>> which belongs to RenderAction, there is >>>>> " >>>>> DrawableStatsAttachment *st = DrawableStatsAttachment::get(actCore); >>>>> >>>>> if(st == NULL) >>>>> { >>>>> DrawableStatsAttachment::addTo(actCore); >>>>> >>>>> st = DrawableStatsAttachment::get(actCore); >>>>> } >>>>> >>>>> " >>>>> which looks not deadlock-free to me (as it adds an attachment to the >>>>> node), >>> correct, that is going to cause problems if run concurrently. >>> >> >> Sorry, I meant race condition, as one thread meets the test "st==NULL" >> first and proceeds to adding the attachment. >> A second might already see "st!=NULL" which is not yet correctly linked to >> the node. >> >>>>> Is there the possibility to move this out of the render traversal >>>>> into a preparation phase "add DrawableStatsAttachment"? >>> part of the problem is that scene traversal is somewhat expensive for >>> OpenSG and if new geometry is added it would need to get an attachment, >>> so it's not enough to just run this preparation pass once. >> >> Providing these attachments could be made the responsibility of the >> application code. >> Then there could be custom traversals to attach them outside the render >> loops. > > The problem is that this element came in to support the occlusion > culling traversal so it is needed deep inside the rendering traversal > and not just something utilized by the application. > >> But using several aspects might be an alternative ;) > > At the moment, yes. > >>>>> Or can StatsCollector be switched off completely? >>> By default the render action does not have a StatCollector; I changed >>> the code to only add the attachment and collect statistics if there is a >>> collector present (otherwise it's a waste of time anyway). >>> Incidentally this also fixes a bug where we were counting triangles twice. >>> >>>>> How are resources handled during traversal on different windows? >>> Sorry for being slow, but I don't quite get what you are asking for, can >>> you rephrase the question or give an example of what handling for which >>> resources you are interested in? >> >> If you have 2 windows/contexts and 2 render actions, the display lists are >> created and stored for each one, for example? > > yes, all OpenGL objects are bound and maintained by the window, so for n > windows you will have n times the OpenGL resources allocated. Currently > we do not support sharing of contexts out of the box. The render action > will carry some traversal dependent OpenSG elements. > >> Currently, I am not seeing anything. Perhaps I may send the debug log >> offline? > > As there can be quite some reasons for not seeing anything that would > be helpful. A good starting point would be to use a OpenGL debugger and > see if the OpenGL command stream looks as expected. >
Ok this one is resolved :) I found that the viewports were all (0, 0, 0, 0), as the code was missing a win->resize(width, height) call for the passive window. >> I will try to use several aspects. >> How is the max number of aspects set with OpenSG 2.0 ? > > that part is gone. Aspects copies are allocated on the fly (sync) and > not while creating the initial container copy, so there is no need to > specify the maximum number of aspect in the beginning anymore. > I am currently exploring this .. > The complex scenemanager contains a reference implementation for > parallel drawers on multiple aspects (DrawManager/Drawer) so it might > be a convenient reference. I'll have to check if I have the multiple > windows CSM Example committed. > Could you perhaps sketch what parallel drawing functions are available? Thanks again, Christoph -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
