Hi Art,
do you know what the fastest for a single channel transfer is? Or should
I make a shader that dumps single channel data into BGRA? Or can I cheat
and render to a luminance and transfer as BGRA? I'm getting +-1GB/s for
readpixels and luminance, so maybe I should stop trying to get it faster.
I'm curious what speeds other people are getting. NVidia claims that
with certain HW (NVidia M/B) one can get up to 3GB/s with "pinned" memory.
jp
Art Tevs wrote:
Hi J.P. , Robert,
as far as I remember PBO is indeed slower for formats not natively supported by the VRAM. On nVidia GPU's it seems that the PBO transfer of GL_BGRA is imho the fastest one. Yes, it is even faster than GL_RGBA.
I think that has something todo with alignment of the data in the memory. If I am wrong, then please correct me.
cheers,
art
J.P. Delport wrote:
Hi Robert,
Robert Osfield wrote:
Hi J.P,
I found that the GL driver support for properly accelerating the
reading from the GPU memory using PBO to be very sensitive for pixel
format, and if you fell off the past path it would indeed be slower.
It's a while since I implemented osgscreencapture so can't remember
all the details off hand, but have a look into forcing the use of the
RGBA frame buffer.
OK, I'll have a look at the format. I was actually triggered by one of
our own apps that reads GL_LUMINANCE textures back (at half the speed
with pbo than without) and then saw osgscreencapture exhibit the same
trend. For some reason I thought I remembered osgscreencapture being
faster with pbo (dual pbo is the default e.g.), but maybe my memory is
wrong.
rgds
jp
Robert.
On Mon, Dec 7, 2009 at 9:39 AM, J.P. Delport <> wrote:
Hi all,
running with latest svn OSG, the osgscreencapture example produces the best
speed for me (tested on a few machines) when run with the --no-pbo command
line parameter. All the pbo options (--single-pbo to --triple-pbo) are
slower. Is this expected? I've thought that the pbo versions would be
faster?
regards
jp
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=21012#21012
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
