Hi Ralf,
Thanks for your quick reply!
> Have you investigated the memory consumption when this happens,
> thinking you could be starting to hit page file?
Yepp, the system has 24GB main memory. With the current config the
system is stable at about 6.8GB memory consumption, leaving swap
untouched. Good question though. Just did a double check to be sure:-)
Gfx RAM, on the other side, is almost constantly exhausted. According to
"watch nvidia-smi -q" there is only a few MB of gfx mem available
throughout execution (varies between 5-100MB free). However, this is
also true for our own systems which are not able to reproduce the issue.
Best regards,
John
Ralf Stokholm wrote:
Hi John
Have you investigated the memory consumption when this happens, thinking
you could be starting to hit page file?
Brgs
Ralf
On 16 June 2011 15:06, John Vidar Larring <[email protected]
<mailto:[email protected]>> wrote:
Hi Sergey,
Thanks for the async reading tip! It gives us a general speed-up,
but it does not fix the issue at hand. But thanks anyway for great
community support!
We used osg::Timer to time the execution of the following calls in
the code you suggested below: glReadPixels, glMapBuffer, memcpy and
the total time of the whole code segment per frame and we got the
following results (all numbers are in milliseconds):
*** PXREAD MAPBUF MEMCPY TOTAL ***
0.038 0.004 7.274 7.316
0.038 0.004 7.262 7.304
0.039 0.004 7.275 7.318
0.037 0.004 7.276 7.317
[...snip... about 20-30 minutes later ...]
0.04 0.004 7.277 7.321
0.037 0.005 7.293 7.335
0.039 0.004 7.279 7.322
0.038 0.004 7.274 7.316
0.037 81.524 7.285 88.846 <--- ???
0.039 802.79 7.253 810.082 <--- ???
0.039 800.092 7.247 807.378
0.037 802.858 7.269 810.164
0.036 800.102 7.279 807.417
0.036 803.398 7.25 810.684
0.038 799.461 7.255 806.754
0.037 802.716 7.247 810
0.038 799.323 7.25 806.611
0.037 799.439 7.265 806.741
0.039 803.154 7.248 810.441
[...snip... stays like this until program is terminated]
No Errors, performance just suddenly drops from excellent to a
virtual halt. This is a total mystery to me, and I haven't seen
anyone else on the web posting similar problems... sigh!
So we are trying to come up with theories as to what can potentially
hurt glReadPixels performance (either sync or async) so badly.
Drivers and HW are among the usual suspects, but the client have the
same issue on multiple machines while we are having trouble
reproducing, on a range of similar HW with the same SW, drivers and
config.
Are there any odd comination of GL calls than can
interrupt/interfere with glReadPixels?
Again any suggestion or ideas are greatly appreciated?
Best regards,
John
Sergey Kurdakov wrote:
Hi John,
I cannot say, what the problem is,
but the possible solution is to use pbo with glReadPixels so
that you read previous frame - and all reading is async - not
slowing app at all
here is a code for you
//somewhere after rendering
glReadBuffer(GL_FRONT);
// get next buffer's index
unsigned int iNextBuffer = (_iCurrentBuffer + 1) % N_MAX_BUFFERS;
// kick of readback of current front-buffer
// into the next buffer
glBindBuffer(GL_PIXEL_PACK_BUFFER,
_aPixelBuffer[iNextBuffer]);//bind pbo1
glReadPixels(0, 0, m_width, m_height, GL_BGRA,
GL_UNSIGNED_BYTE, BUFFER_OFFSET(0));//readback
// map the current buffer
containing the
// image read back the previous
time around
glBindBuffer(GL_PIXEL_PACK_BUFFER_EXT,
_aPixelBuffer[_iCurrentBuffer]);//bind pbo2
_pPixels = static_cast<unsigned char
*>(glMapBuffer(GL_PIXEL_PACK_BUFFER, GL_READ_ONLY));
if(_pPixels)
{
//something like:
memcpy(image,_pPixels,m_width*m_height*4);
// unmap the buffer
if (!glUnmapBuffer(GL_PIXEL_PACK_BUFFER))
{
std::cerr << "Couldn't unmap pixel buffer. Exiting\n";
assert(false);
}
}
// unbind readback buffer to not interfere with
// any other (traditional) readbacks.
glBindBuffer(GL_PIXEL_PACK_BUFFER, 0);
// make next-buffer the current buffer
_iCurrentBuffer = iNextBuffer;
glReadBuffer(GL_BACK);
make sure you have inited buffers
glGenBuffers(N_MAX_BUFFERS, _aPixelBuffer);
for (unsigned int iBuffer = 0; iBuffer < N_MAX_BUFFERS; ++iBuffer)
{
glBindBuffer(GL_PIXEL_PACK_BUFFER, _aPixelBuffer[iBuffer]);
glBufferData(GL_PIXEL_PACK_BUFFER, m_width*m_height*4,
NULL, GL_STATIC_READ);
errorcode = glGetError();
} glBindBuffer(GL_PIXEL_PACK_BUFFER, 0);
and that you delete them after use
glBindBufferARB(GL_PIXEL_PACK_BUFFER_EXT, 0);
glDeleteBuffersARB(N_MAX_BUFFERS, _aPixelBuffer);
Regards
Sergey
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Ralf Stokholm
Director R&D
Email: [email protected] <mailto:[email protected]>
Phone: +45 28 30 83 52
Web: www.arenalogic.com <http://www.arenalogic.com>
This transmission and any accompanying documents are intended only for
confidential use of the designated recipient(s) identified above. This
message contains proprietary information belonging to Arenalogic Aps.
If you have received this message by error, please notify the sender.
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
