Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 6 of 6

Thread: glDrawArrays and memory fragmentation

  1. #1
    Junior Member Newbie
    Join Date
    Nov 2017
    Posts
    3

    glDrawArrays and memory fragmentation

    Hello to all,

    I have a problem with the glDrawArrays function and I can not find an explanation.

    Environment: Windows 10 and a Win32 application (VB6 + Ocx written in VC++ 2015)
    In the OnDraw of the ocx the glDrawBuffer is used every 100 ms to display data from device (a 2D curve).

    The curve is displayed regularly.
    In the loop the simplified code is

    glVertexPointer (2, GL_DOUBLE, 0, m_dataCh1);
    glColor3ub (GetRValue (m_foreColorY1), GetGValue (m_foreColorY1), GetBValue (m_foreColorY1));
    glDrawArrays (GL_LINE_STRIP, m_currArrayStart, m_currArraySize);

    Problem: during the display (which can last 30 minutes), they are continuously allocated
    pieces of 1 or 2 M memory (Private Data). At the end, the memory is so fragmented that
    the application becomes unusable. I noticed that the allocations source is the glDrawArrays.

    What am I doing wrong?

    (I attach a program image to work and allocated and fragmented memory)

    Thanks !
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	ogl.jpg 
Views:	14 
Size:	19.4 KB 
ID:	2561  

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,728
    What you're doing wrong is continually allocating and freeing memory.

    glDrawArrays, contrary to what you might expect, does not actually draw immediately: instead it will copy off your parameters, queue up the draw call in your drivers command buffer, then return and allow your program to continue running. At some arbitrary later point in time your driver will pick up all queued-up work and run it' that's when drawing actually happens. So you'll typically have at least two blocks of memory in flight: one for the current draw call you're building, one for a previous draw call you've submitted but that has not yet been run.

    The solution is to not constantly allocate and free memory. Instead, allocate a fixed amount one-time-only during program startup and reuse that each time. If you know that you'll never use more than 4mb then go ahead and allocate the whole 4mb - it doesn't matter if you actually only need 1mb 75% of the time, that's a false optimization, as you've discovered.

    Right now you're using client-side arrays via system memory allocations, which is an old-school OpenGL 1.1 approach. From OpenGL 1.5 onwards the ability to store data in GPU memory via buffer objects exists, but it may not be a performance gain depending on your use case, and I'm not certain if it's even available in VB6.

  3. #3
    Junior Member Newbie
    Join Date
    Nov 2017
    Posts
    3
    Thanks for the answer, but maybe I did not explain it clearly.

    Quote Originally Posted by mhagain View Post
    What you're doing wrong is continually allocating and freeing memory.
    The application allocates once the array with the data to display.

    At the DrawArray function, every 100 ms, I pass the initial element and the items number to be displayed. The array allocated by the application does not grow during the display.
    It's the DrawArrays that always allocates pieces of memory and I can not do anything.

    The application uses OpenGl 1.1 because it is the version supported by Windows (do not ask why).

    I could use other versions of OpenGl through GLEW but before I change everything i would like to understand if there is an explanation of the behavior of DrawArrays.

    If I wanted to use VBO mode, what would the minimum sequence of function call for data visualizations without using the DrawArrays?


    Thanks again

  4. #4
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,728
    Quote Originally Posted by oglengine View Post
    The application uses OpenGl 1.1 because it is the version supported by Windows (do not ask why).
    No, no, no, no, no, no, no.

    OpenGL does not work this way and the version of OpenGL available does not depend on the OS.

    The crap software implementation provided by default on Windows is limited to OpenGL 1.1; but nobody uses that. OpenGL, and the OpenGL version you can use, is determined by your GPU and your device driver.

  5. #5
    Junior Member Newbie
    Join Date
    Nov 2017
    Posts
    3
    Quote Originally Posted by mhagain View Post
    No, no, no, no, no, no, no.
    Keep calm, please ... :-) It was exactly what I meant, so we agree. It is the library for Visual C++ that does not support the call to some functions and so it is necessary to use them dynamically ...

    As for the code skeleton I was asking you, for the buffer allocation section, drawing and deallocation of buffer, can you tell me something?

    Thank you

  6. #6
    Member Regular Contributor
    Join Date
    May 2016
    Posts
    443
    take a look at any recent "first-triangle" demo code (that uses openGL 3.3 or a newer version)
    https://www.khronos.org/opengl/wiki/Buffer_Object

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •