Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 2 12 LastLast
Results 1 to 10 of 13

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

  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
    3,213
    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 Guru
    Join Date
    May 2009
    Posts
    4,948
    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.

  8. #8
    Member Regular Contributor Nowhere-01's Avatar
    Join Date
    Feb 2011
    Location
    Novosibirsk
    Posts
    251
    can you specify problem? blitting works for you on AMD hardware? if it doesn't, what code exactly you use to blit? my method doesn't work? and let's stay in this topic.

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

    Unhappy

    Quote Originally Posted by Alfonse Reinheart View Post
    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.

    Thanks a lot, dear Alfonse Reinheart. Since I'm only an opengl application developer and not a member of ARB, I can't fathom deep enough to the cause of such important abridgment. But as being only an application developer, I just care about the method how the mapping of stencil buffer can be done substitutely.
    I think any modification on an industry standard should deliberate the compatibility. If a function is cut, any previous implemention depending on it should be considered over of an alternative on the new version.

    As a veteran in this field, Alfone Reinheart, can you give me some advice, if there is a way anyway, on how my task can be fulfilled without the usage of stencil mapping of ARB_imaging. And the most important of all, without the lose of efficiency of course!

  10. #10
    Intern Contributor
    Join Date
    Dec 2012
    Posts
    74
    Quote Originally Posted by Nowhere-01 View Post
    can you specify problem? blitting works for you on AMD hardware? if it doesn't, what code exactly you use to blit? my method doesn't work? and let's stay in this topic.
    Well. The last problem has already been solved. If you wish to know the origin of my question, I think the best way is to get an ATI card and write some stencil blitting code, then you will know the difference between them.

    As for this thread, you can see here Alfone Reinheart had found the cause of it.
    Can you please also help me to think over if there is an alternative way to write my code without loss of efficiency?


    Best regards,

    nuclear bomb

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
  •