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 10 of 13

Thread: glDrawPixels slow down when set GL_MAP_STENCIL to true on nvidia

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Intern Contributor
    Join Date
    Dec 2012
    Posts
    74

    Thumbs up glDrawPixels slow down when set GL_MAP_STENCIL to true on nvidia

    Have written the following code:

    Code :
            glPixelTransferi(GL_MAP_STENCIL,TRUE);
     
            long timeBeforeDrawPixels=timeGetTime();
     
            glDrawPixels(FINAL_WIDTH,FINAL_HEIGHT,GL_STENCIL_INDEX,GL_UNSIGNED_BYTE,pboImageReadBackRed);
            //FINAL_WIDTH and FINAL_HEIGHT are set to 1024 and 768 respectively
     
            long timeAfterDrawPixels=timeGetTime();
     
            printf("We found this artificial noise lasted for %ld miliseconds.\n", timeAfterDrawPixels-timeBeforeDrawPixels);
            //I got above 400 ms here on GeForce GTX 650 Ti.
     
            glPixelTransferi(GL_MAP_STENCIL,FALSE);

    Can anyone give any hint on this issue? Is it a driver error or architecture error? Thanks in advance!

  2. #2
    Intern Contributor
    Join Date
    Dec 2012
    Posts
    74
    Why no one answers? Is there anything not declared clearly?
    And brave Nowhere-01, why not show your omnipresent heroism this time?
    Last edited by newbiecow; 02-06-2013 at 07:35 PM.

  3. #3
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,225
    Quote Originally Posted by newbiecow View Post
    Why no one answers? Is there anything not declared clearly?
    It's been less than 12 hours, and it's possibly few if any have ever done this.

    I personally have never even thought to look and see if this is supported. CPU<->GPU = slow. Keep it all on the GPU when possible.

    I could guess at this, but not sure it would help you much. Is pboImageReadBackRed a CPU pointer or an offset into a bound PBO? If the latter when was it last uploaded (or generated)?

  4. #4
    Intern Contributor
    Join Date
    Dec 2012
    Posts
    74

    Unhappy

    Quote Originally Posted by Dark Photon View Post
    It's been less than 12 hours, and it's possibly few if any have ever done this.

    I personally have never even thought to look and see if this is supported. CPU<->GPU = slow. Keep it all on the GPU when possible.

    I could guess at this, but not sure it would help you much. Is pboImageReadBackRed a CPU pointer or an offset into a bound PBO? If the latter when was it last uploaded (or generated)?

    Thanks a lot, Dark Photon!

    At first, I also think it may due to the bandwidth between CPU<->GPU. But after I modified the code to
    Code :
     
     
            //glPixelTransferi(GL_MAP_STENCIL,TRUE);  //<------------------------- Do not map stencil
     
            long timeBeforeDrawPixels=timeGetTime();
     
            glDrawPixels(FINAL_WIDTH,FINAL_HEIGHT,GL_STENCIL_INDEX,GL_UNSIGNED_BYTE,pboImageReadBackRed);
            //FINAL_WIDTH and FINAL_HEIGHT are set to 1024 and 768 respectively
     
            long timeAfterDrawPixels=timeGetTime();
     
            printf("Now, we found this artificial noise is cancelled out, so drawing takes only %ld miliseconds.\n", timeAfterDrawPixels-timeBeforeDrawPixels);
            //now we've got only about 30 ms here on GeForce GTX 650 Ti.
     
            //glPixelTransferi(GL_MAP_STENCIL,FALSE);  //<------------------------- Do not map stencil
    No delay was found at all!

    So, this is an obvious fault, most probably in hardware's opengl driver, perhaps even intended.
    And most probably others have encountered this fault, should know how to fix it or know where to download a fixed version of the Nvidia's driver.

    I know Nowhere-01 is a sly guy, he seems to know everything and is always ready to give instructions, I even think he is an employee of Nvidia, but why this time he hides his head like a goddamn turtle!
    Last edited by newbiecow; 02-07-2013 at 04:17 AM.

  5. #5
    Member Regular Contributor Nowhere-01's Avatar
    Join Date
    Feb 2011
    Location
    Novosibirsk
    Posts
    251
    i guess, you are still trying to blit stencil. it's done like that:

    • you initialize source and destination FBO's. both should have stencil attachment, defined like that: glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH24_STENCIL8, Width, Height);
      glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_STENCIL_ATTACHMENT, GL_RENDERBUFFER, renderBuffer);
    • you render to source buffer and fill stencil with whatever you want
    • you bind destination buffer as a draw_buffer - glBindFramebuffer(GL_DRAW_FRAMEBUFFER, bufferObject), and source buffer as read_buffer - glBindFramebuffer(GL_READ_FRAMEBUFFER, bufferObject).
    • you blit from source to destination glBlitFramebuffer(0, 0, srcWidth, srcHeight, 0, 0, dstWidth, dstHeight, GL_STENCIL_BUFFER_BIT, GL_NEAREST);
    • GL_NEAREST is important, depth\stencil buffer is not directly compatible with filtering.
    • you use stencil as usual in destination frame buffer;


    i've ignored your topic because of that: https://www.opengl.org/discussion_boards/showthread.php/180986-Some-stencil-fbo-code-runs-on-ati-but-not-on-nvidia
    you've got the solution to one of your problems, but instead of commenting it you've posted some unrelated message quoting yourself. and that's not the first time you've completely ignored an answer.
    and in this topic you've posted more text discussing me, than anything related to your problem. was that necessary?
    no, i'm not related to nvidia or any other corporation. and i'm very far in my knowledge level from someone you can assume is an experienced professional.

    i think your method is slow, because you were using legacy functionality, which is not hardware-accelerated in any way.

  6. #6
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,940
    And most probably others have encountered this fault, should know how to fix it or know where to download a fixed version of the Nvidia's driver.
    Or perhaps there is no "fixed version" because it's not broken. Just because it's slow doesn't mean it's broken. It's slow because MAP_STENCIL is some terrible ARB_imaging feature that's not hardware accelerated. And it's not going to become hardware accelerated in the near future.

    Don't use this map-stencil stuff. If you need to process the image data, process it yourself; don't rely on the driver to do it for you. And especially don't rely on anything in the imaging subset.

  7. #7
    Intern Contributor
    Join Date
    Dec 2012
    Posts
    74

    Quote Originally Posted by Nowhere-01 View Post
    i guess, you are still trying to blit stencil. it's done like that:

    • you initialize source and destination FBO's. both should have stencil attachment, defined like that: glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH24_STENCIL8, Width, Height);
      glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_STENCIL_ATTACHMENT, GL_RENDERBUFFER, renderBuffer);
    • you render to source buffer and fill stencil with whatever you want
    • you bind destination buffer as a draw_buffer - glBindFramebuffer(GL_DRAW_FRAMEBUFFER, bufferObject), and source buffer as read_buffer - glBindFramebuffer(GL_READ_FRAMEBUFFER, bufferObject).
    • you blit from source to destination glBlitFramebuffer(0, 0, srcWidth, srcHeight, 0, 0, dstWidth, dstHeight, GL_STENCIL_BUFFER_BIT, GL_NEAREST);
    • GL_NEAREST is important, depth\stencil buffer is not directly compatible with filtering.
    • you use stencil as usual in destination frame buffer;


    i've ignored your topic because of that: https://www.opengl.org/discussion_boards/showthread.php/180986-Some-stencil-fbo-code-runs-on-ati-but-not-on-nvidia
    you've got the solution to one of your problems, but instead of commenting it you've posted some unrelated message quoting yourself. and that's not the first time you've completely ignored an answer.
    and in this topic you've posted more text discussing me, than anything related to your problem. was that necessary?
    no, i'm not related to nvidia or any other corporation. and i'm very far in my knowledge level from someone you can assume is an experienced professional.

    i think your method is slow, because you were using legacy functionality, which is not hardware-accelerated in any way.
    Well, Nowhere-01. Anyway you have shown up again!
    But, this time, I think you should reread this thread carefully. The last problem on this thread http://www.opengl.org/discussion_boa...46#post1248046 has been solved.

    This question is no more harder than the last one of http://www.opengl.org/discussion_boa...46#post1248046.

    And since you are an nvidia familiar, you can easily make out what is wrong here.
    So, this time, why not use your agile mind and execute your omnipresent heroism to show me your epertise knowledge between opengl and nvidia?


    Best regard,

    newbiecow
    Last edited by newbiecow; 02-07-2013 at 06:07 AM.

Tags for this Thread

Posting Permissions

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