Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your feedback on a survey! Each completed response supports our community and gives you a chance to win a $25 Amazon gift card!


#ActualDark Helmet

Posted 25 February 2013 - 08:20 PM

Check out:

* GLSL : common mistakes#Sampling and Rendering to the Same Texture

NV_texture_barrier might be useful to you on NVidia specifically, but I don't know of a cross-vendor way to support this.

OpenCL IMO is a non-starter except for limited use cases, as IIRC flipping back and forth requires a full pipeline flush/sync (that is, in the absense of cl_khr_gl_event / ARB_cl_event). An OpenGL Compute Shader is much more interesting in terms of avoiding that overhead, but I'm not an expert on those yet.

#2Dark Helmet

Posted 25 February 2013 - 08:20 PM

Check out:

* GLSL : common mistakes#Sampling and Rendering to the Same Texture

NV_texture_barrier might be useful to you on NVidia specifically, but I don't know of a cross-vendor way to support this.

OpenCL IMO is a non-starter except for limited use cases, as IIRC flipping back and forth requires a full pipeline flush/sync (that is, in the absense of cl_khr_gl_event / ARB_cl_event). An OpenGL Compute Shader is much more interesting in terms of avoiding that overhead, but I'm no guru on that yet.

#1Dark Helmet

Posted 25 February 2013 - 08:18 PM

Check out:

* GLSL : common mistakes#Sampling and Rendering to the Same Texture

NV_texture_barrier might be useful to you on NVidia specifically, but I don't know of a cross-vendor way to support this.

OpenCL IMO is a non-starter except for limited use cases, as flipping back and forth requires a full pipeline flush/sync (IIRC) in the absense of cl_khr_gl_event / ARB_cl_event. An OpenGL Compute Shader is much more interesting in terms of avoiding that.

PARTNERS