Hi Robert, > I'm just reviewing your changes and I generally support > these changes, > PixeBufferObject as it stands is far too restrictive and > needs > generalising. My inclination would be to make a single > PixeBufferObject class that is general purpose, rather than > have two, > but as a first step towards this I don't have a problem > with a > temporary class that offers extra functionality missing for > the > original. > This was also my thoughts: to rewrite PixelBufferObject for more general implementation. However, this could make it backward incompatible, hence I wrote this new class. As I said before, this is one of the points to be included into major version step todo list.
> One area that I found that needs further clarification is > that role of > PixelDataBufferObject::Mode, while I see how you are using > it, the > multi-context/threading safety of it does concern me, if > you are > changing the mode during the life of the application, and > doing so > from multiple threads running on multiple contexts that the > mode > management would become invalid for the current context > when another > changes the mode on it. My best guess for how to resolve > this would > be to buffer the mode per context. > The mode variable do just specify in which current mode (read/write/normal) the buffer object is. True, one need to buffer the value for each context, you are right. Art. > Robert. > > On Fri, Nov 28, 2008 at 1:28 PM, Art Tevs > <[EMAIL PROTECTED]> wrote: > > Hi Robert, > > > > here is a submission of an additional class of > PixelBufferObejct, which implements more general way of > handling with PBOs. Current osg implementation of PBO does > use an attached osg::Image to copy data from. This is > somehow only one way of using it and doesn't provide > full functionality of PBOs. > > > > -------------------------------------------- > > Descripton: > > > > The patch does provide a new class > PixelDataBufferObject which is capable of allocating memory > on the GPU side (PBO memory) of arbitrary size. The memory > can then further be used to be enabled into read mode > (GL_PIXEL_UNPACK_BUFFER_ARB) or in write mode > (GL_PIXEL_PACK_BUFFER_ARB). Enabling the buffer into write > mode will force the driver to write data from bounded > textures into that buffer (i.e. glGetTexImage). Using buffer > in read mode give you the possibility to read data from the > buffer into a texture with e.g. glTexSubImage or other > instuctions. Hence no data is copied over the CPU (host > memory), all the operations are done in the GPU memory. > > > > > > -------------------------------------------- > > Compatibility: > > > > The new class require the unbindBuffer method from the > base class BufferObject to be virtual, which shouldn't > break any functionality of already existing classes. Except > of this the new class is fully orthogonal to existing one, > hence can be safely added into already existing osg system. > > > > -------------------------------------------- > > Testing: > > > > The new class was tested in the current svn version of > osgPPU. I am using the new class to copy data from textures > into the PBO and hence provide them to CUDA kernels. Also > reading the results back from CUDA is implemented using the > provided patch. The given patch gives a possibility of easy > interoperability between CUDA and osg (osgPPU ;) ) > > > > > > -------------------------------------------- > > I think in general it is a better way to derive the > PixelBufferObject class from PixelDataBufferObject, since > the second one is a generalization of the first one. However > this could break the current functionality, hence I > haven't implemented it in such a way. However I would > push that on a stack of wished osg 3.x features, since this > will reflect the OpenGL PBO functionality through the > classes better. > > > > > > Best regards, > > Art > > > > > > > > > > _______________________________________________ > > osg-submissions mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
