Hi, On Sat, 2009-01-31 at 18:42 -0600, Dirk Reiners wrote: > Hi Gerrit, > > Gerrit Voss wrote: > > > > Hmm, shader composition wasn't on Allen's list IIRC. > > No, but you were talking about things in the works for 2, so I > generalized a little bit. ;) > > > It was more about all these memory and download things. I have > > a rough idea how to delay rendering, the bigger question is to figure > > out until when ? I was about to play with the pbo stuff and see if it > > has an impact on the texture downloads. > > I need to have that solved in a more general way anyway, as I will be > dealing with very large datasets (>100 GB) points. For that I'm thinking > about a general CacheManager class that handles a memory cache of a much > larger dataset. It will handle asynchronous loading and priorities, and > maybe hierarchical assets (e.g. LODs or multi-level textures), not quite > decided whether it's better to leave that with the higher-level code. > > I was thinking of having two coupled CMs, one for GfxMem and one for > main mem (and maybe another one for disk), that would limit the transfer > per frame to a give amount. For non-OOC ssytems you could use just one > for GfxMem. > > I was thinking about having managed versions of textures and LODs to > avoid having to integrate it seamlessly into the existing code (OOC and > even large model handling needs some special preprocessing anyway). ok. I did not plan to go that far ;-)
> > Unfortunately using driver memory directly seems not that easy as > > you need an active context. > > Yup. > > > The one thing high on my list is quite generic access to the glcontext > > during the traversal so that data prep/download can go on as early as > > possible. > > Well, that has the same problem, no? If you do the traversal in a > separate thread there is no context, and even if there was there might > be another thread busy pushing data into the pipe which might not like > being interrupted. ok, the generic contained exclusive, which I missed in the original. I was more thinking along the line of having a thread per context which has exclusive access and everything else has to go through it. So the render action will submit the stages for execution as it sees fit, similar the app would be allowed to submit things too. The only thing left is to synchronize app parts and the stage that depends on it, but that should not be to big a problem as there will be something in the tree that can setup this part for the stage properly. > > With this also goes early stage execution so we don't have to wait until > > the render traversal is finished. > > Hm, you're thinking of what Performer called Cull_o_Draw? Is that > critical enough to warrant the complication of not being able to build a > full tree? that not, what I was thinking about was executing stages that completed their traversal immediately. Determining if they are depending on something else is quite easy. I agree that interrupting the traversal itself should have a very very good reason ;-) > > That comes from the bbq terrain stuff, what kind of terrain are you > > doing ? > > I have a student working on a master's project (starting right now), and > we're trying to implement the Seamless Patches paper > (http://wscg.zcu.cz/WSCG2007/Papers_2007/full/C43-full.pdf), as it seems > like a good and simple method for multi-resolution terrain. That would > also need the CacheManager. Application is our Army foot soldier > simulation system. ok > > The other thing high on my list was the forget data after downloading. > > That requires some tweaking to work with the MT and Cluster syncs, but > > I have a reasonable good idea what is needed. > > I'm surprised that this is critical, given today's memory sizes. I think > a good gfxmem expulsion strategy is much more useful, and much less > complicated to get working right. Well Allen mentioned it and I trusted him that it is a serious issue for them so I started thinking what would be involved. > > As memory management is a quite wide topic what were you looking at ? > > See above. > > > The basics are there, currently I'm looking into the merge/override > > logic. The shaders now basically follow the OpenGL model so > > you can have program parts that compile separately and are finally > > linked together. You already can distribute them hierarchically in > > the graph but right now they are only merged together (by linking), > > hence the need for more logic ;-) It probably needs some low-level > > interface for direct use (e.g. activating/deactivating these shaders > > directly and not through the general draw mechanism) > > Not sure I get that last part. In general, have you thought about > conventions to make this work to replace OpenGL fixed func? I.e., how to > integrate different kinds of light sources with surface shader and > geometry manipulation like skinned character? What you describe above is > a necessary component, but the actual application is not going to be > trivial itself, so it might make sense to start thinking about it. Yes I already did, it is a reference as to how the infrastructure has to look like. But it is not in a condensed state right now it is more a set of floating ideas ;-) I see finalizing this is the last step, actually besides providing something I would like to keep it as open as possible so different ideas could be tried. > Or do you not want to talk about it until it's published? Publish, at least the infrastructure for now, yes, but it's hard to find a place, I was thinking a little bit about SEARIS but I'm not sure if this really fit's in. kind regards, gerrit ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
