Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualcr88192

Posted 02 April 2013 - 02:38 AM

One universal truth however is that if you update a texture while it is still being used by the GPU the GPU will perform a synchronous flush in order to allow you to update the texture safely on the CPU side.

 

I would hope that in this case drivers are at least reasonably intelligent and copy off the data to temp storage for updating at a later time when the resource is no longer in use (similar to the D3D10+ case for UpdateSubresource where there is contention, although unfortunately OpenGL doesn't seem to specify a behaviour here).

 

when messing around with multithreaded OpenGL and texture uploading (with the rendering and texture-uploading being done in different threads), I observed some interesting behaviors here:

the glTexImage2d() or glCompressedTexImage2d() calls were completing immediately;

within the main render thread, it would often be up to several seconds later until the texture image actually appeared (otherwise, it would be the prior contents and/or garbage).

 

typically, having the uploader threads call glFinish() would cause them to stall temporarily, but results in the next frame in all of the textures being correct.

 

judging by this, I suspect the driver is lazily updating the textures in this case.

 

 

I am less certain what happens in the single-threaded case, but have made another general observation:

if you do something, and try to immediately make use of the results, there will be a stall.

 

this seems to happen with both VBOs and also things like occlusion queries, like there is a delay between when the upload call is made, and when it can be bound or used.

typically, in my case this means "batching" things and doing them in a partly interleaved order (say, all the draw requests for occlusion queries before fetching any of the results, or uploading all the updated VBOs before the rest of the drawing pass begins, ...).

 

granted, I am not sure how much of this is driver/hardware specific. in this case, I am using a GeForce GTX 460...


#2cr88192

Posted 02 April 2013 - 02:37 AM

One universal truth however is that if you update a texture while it is still being used by the GPU the GPU will perform a synchronous flush in order to allow you to update the texture safely on the CPU side.

 

I would hope that in this case drivers are at least reasonably intelligent and copy off the data to temp storage for updating at a later time when the resource is no longer in use (similar to the D3D10+ case for UpdateSubresource where there is contention, although unfortunately OpenGL doesn't seem to specify a behaviour here).

 

when messing around with multithreaded OpenGL and texture uploading (with the rendering and texture-uploading being done in different threads), I observed some interesting behaviors here:

the glTexImage2d() or glCompressedTexImage2d() calls were completing immediately;

within the main render thread, it would often be up to several seconds later until the texture image actually appeared (otherwise, it would be the prior contents and/or garbage).

 

typically, having the uploader threads call glFinish() would cause them to stall temporarily, but results in the next frame in all of the textures being correct.

 

judging by this, I suspect the driver is lazily updating the textures in this case.

 

 

I am less certain what happens in the single-threaded case, but have made another general observation:

if you do something, and try to immediately make use of the results, there will be a stall.

 

this seems to happen with both VBOs and also things like occlusion queries, like there is a delay between when the upload call is made, and when it can be bound or used.

typically, in my case this means "batching" things and doing them in a partly interleaved order (say, all the draw requests for occlusion queries before fetching the results, or uploading all the VBOs before the rest of the drawing pass, ...).

 

granted, I am not sure how much of this is driver/hardware specific. in this case, I am using a GeForce GTX 460...


#1cr88192

Posted 02 April 2013 - 02:37 AM

One universal truth however is that if you update a texture while it is still being used by the GPU the GPU will perform a synchronous flush in order to allow you to update the texture safely on the CPU side.

 

I would hope that in this case drivers are at least reasonably intelligent and copy off the data to temp storage for updating at a later time when the resource is no longer in use (similar to the D3D10+ case for UpdateSubresource where there is contention, although unfortunately OpenGL doesn't seem to specify a behaviour here).

 

when messing around with multithreaded OpenGL and texture uploading (with the rendering and texture-uploading being done in different threads), I observed some interesting behaviors here:

the glTexImage2d() or glCompressedTexImage2d() calls were completing immediately;

within the main render thread, it would often be up to several seconds later until the texture image actually appeared (otherwise, it would be the prior contents and/or garbage).

 

typically, having the uploader threads call glFinish() would cause them to stall temporarily, but results in the next frame in all of the textures being correct.

 

judging by this, I suspect the driver is lazily updating the textures in this case.

 

 

I am less certain what happens in the single-threaded case, but have made another general observation:

if you do something, and try to immediately make use of the results, there will be a stall.

 

this "seems" to happen with both VBOs and also things like occlusion queries, like there is a delay between when the upload call is made, and when it can be bound or used.

typically, in my case this means "batching" things and doing them in a partly interleaved order (say, all the draw requests for occlusion queries before fetching the results, or uploading all the VBOs before the rest of the drawing pass, ...).

 

granted, I am not sure how much of this is driver/hardware specific. in this case, I am using a GeForce GTX 460...


PARTNERS