OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

[Persistent buffer implementation in osg]

Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
mp3butcher (Julien Valentin)

Joined: 17 Feb 2010
Posts: 511
Location: France

PostPosted: Wed Feb 07, 2018 6:31 pm    Post subject:
[Persistent buffer implementation in osg]
Reply with quote

I began to integrate GL immutable storages in osg (glMapBufferRange)
but I blocked on the design problem of Persistent Buffer.

First I haven't find a way to use vector interface for both dma and ::new memory allocation policy without violating the standard (interact directly with vector allocator state of a boost::vector)

Second, DMA changes have to be commited using a valid context from the update thread (glFlushMappedBuffer)! I know it sound weird but It's how it is....No?

here's the branch

here's Robert review
As for the actual functionality attempted here. Well pushing context specific data into BufferData which is designed to be graphics context agnostic is broken, the whole point of this design is to allow the subclasses of BufferData to just concentrate on application data and not have to worry about what context are created by the application - it's all about decoupling the scene graph from the viewer. It's one of the OSG great assets. And here you won't to throw away a clean design for a niche feature only usable on a GL4 and has absolutely no value for all other GL/GLES versions.

With niche feature think how to implement things in a custom way where the changes are kept local, not sprayed across the core OSG.

All insights are welcome

Thank you!

Back to top
View user's profile Send private message Visit poster's website
OSG Project Lead

Joined: 18 Mar 2009
Posts: 12205

PostPosted: Sat Feb 10, 2018 5:52 pm    Post subject:
[Persistent buffer implementation in osg]
Reply with quote

Hi Julien,

My guess is that if you can just implement what you want for a single
threading, single graphics context application then the thing to do is
just create your graphics context make it current in the main thread
and then just run your frame loop. You can put all GL calls anywhere
you want - in the update, event, cull or draw traversals.

If you want want a general purpose solution for all OSG users then
it's far tougher proposition. Having memory that is associated with a
graphics context means that you'll need to multi-buffer to handle an
application that has multiple graphics contexts - this is the reason
why the OSG has a BufferObject aggregates a vector of GLBufferObjects,
with one GLBufferObject per graphics context. The OSG works hard to
hide all this complexity so that scene graph users mostly don't have
to go through serious pain if there boss turns around and ask them to
have two windows rather that than the one that they originally design
it for. The OSG makes this pretty trivial, but for many graphics
applications it's a nightmare.

However, if you want to blur the distinction between GL memory and
application memory you will have to multi-buffer at the scene graph
level, you won;'t be able to hide it as an implementation detail like
is done by the OSG for normal OpenGL state. If you wanted your
application osg::Vec3Array to use GL memory then you'd need buffer the
osg::Vec3Array for each context, so which in turns means that
osg::Geometry that manages them would need to multi-buffered as well.
If you then need map/unmap the data you'll also need to do this from
threads that have the graphics context associated with that particular
buffer, which then pushes the need to update your scene graph during
the draw traversal. Which is now starting to get pretty messy.

I suspect the only way you could resolve this would then be push the
update, event, cull and draw threads into the graphics threads, which
pushes you toward needing a new threading model for osgViewer that
supports this type of usage. If there are non GL parts of the scene
graph that are shared between graphics contexts then these might be
able to be run from the main loop, but it could get a bit sticky.

So... a general purpose solution is unlikely to be easy to implement
or easy to use. It's not a low level integration issue, it's both a
high level and low level issue.

Or... just keep things simple, if you want this particular usage case
then just implement it client side, simplify your application usage so
that everything is done single threaded for a single graphics context.


Post generated by Mail2Forum
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts Camera with FBO and dynamic color buf... filnet Submission 0 Tue Mar 06, 2018 12:59 pm View latest post
No new posts Read frame buffer back into main memory arennuit General 12 Wed Feb 28, 2018 6:05 pm View latest post
No new posts Texture Buffer Object Initialization ... EonStrife General 0 Tue Feb 27, 2018 7:53 am View latest post
No new posts osgText - alignment differences using... gwaldron General 4 Thu Feb 01, 2018 5:51 pm View latest post
No new posts How to use frame buffer object in exi... saedrna1 General 2 Sat Feb 18, 2017 3:54 am View latest post

Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP