back  Return to list

homeprevnext Name
homeprevnext Name Strings
homeprevnext Contact
    Jeff Bolz, NVIDIA Corporation (jbolz 'at' 
homeprevnext Status
    Shipping (August 2009, Release 190) 
homeprevnext Version
    Last Modified Date:         August 10, 2009 
    NVIDIA Revision:            1 
homeprevnext Number
homeprevnext Dependencies
    This extension is written against the OpenGL 3.0 specification. 
homeprevnext Overview
    This extension relaxes the restrictions on rendering to a currently 
    bound texture and provides a mechanism to avoid read-after-write 
homeprevnext New Procedures and Functions
    void TextureBarrierNV(void); 
homeprevnext New Tokens
homeprevnext Additions to Chapter 2 of the OpenGL 3.0 Specification (OpenGL Operation)
homeprevnext Additions to Chapter 3 of the OpenGL 3.0 Specification (Rasterization)
homeprevnext Additions to Chapter 4 of the OpenGL 3.0 Specification (Per-Fragment Operations and the Frame Buffer)
    Modify Section 4.4.3, Rendering When an Image of a Bound Texture Object 
    is Also Attached to the Framebuffer, p. 288 
    (Replace the complicated set of conditions with the following) 
    Specifically, the values of rendered fragments are undefined if any  
    shader stage fetches texels and the same texels are written via fragment  
    shader outputs, even if the reads and writes are not in the same Draw  
    call, unless any of the following exceptions apply: 
    - The reads and writes are from/to disjoint sets of texels (after  
      accounting for texture filtering rules). 
    - There is only a single read and write of each texel, and the read is in  
      the fragment shader invocation that writes the same texel (e.g. using  
      "texelFetch2D(sampler, ivec2(gl_FragCoord.xy), 0);"). 
    - If a texel has been written, then in order to safely read the result 
      a texel fetch must be in a subsequent Draw separated by the command 
        void TextureBarrierNV(void); 
      TextureBarrierNV() will guarantee that writes have completed and caches 
      have been invalidated before subsequent Draws are executed. 
homeprevnext Additions to Chapter 5 of the OpenGL 3.0 Specification (Special Functions)
homeprevnext Additions to Chapter 6 of the OpenGL 3.0 Specification (State and State Requests)
homeprevnext Additions to the AGL/GLX/WGL Specifications
homeprevnext Errors
homeprevnext New State
homeprevnext New Implementation Dependent State
homeprevnext Issues
    (1) What algorithms can take advantage of TextureBarrierNV? 
      This can be used to accomplish a limited form of programmable blending 
      for applications where a single Draw call does not self-intersect, by 
      binding the same texture as both render target and texture and applying 
      blending operations in the fragment shader. Additionally, bounding-box  
      optimizations can be used to minimize the number of TextureBarrierNV 
      calls between Draws. For example: 
        foreach (object in scene) { 
          if (dirtybbox.intersects(object.bbox())) { 
          dirtybbox = bound(dirtybbox, object.bbox()); 
      Another application is to render-to-texture algorithms that ping-pong 
      between two textures, using the result of one rendering pass as the input 
      to the next. Existing mechanisms require expensive FBO Binds, DrawBuffer  
      changes, or FBO attachment changes to safely swap the render target and  
      texture. With texture barriers, layered geometry shader rendering, and  
      texture arrays, an application can very cheaply ping-pong between two  
      layers of a single texture. i.e. 
        X = 0; 
        // Bind the array texture to a texture unit 
        // Attach the array texture to an FBO using FramebufferTextureARB 
        while (!done) { 
          // Stuff X in a constant, vertex attrib, etc. 
          Draw -  
            Texturing from layer X; 
            Writing gl_Layer = 1 - X in the geometry shader; 
          X = 1 - X; 
      However, be warned that this requires geometry shaders and hence adds  
      the overhead that all geometry must pass through an additional program 
      stage, so an application using large amounts of geometry could become  
      geometry-limited or more shader-limited. 
homeprevnext Revision History
    Rev.    Date    Author    Changes 
    ----  --------  --------  ----------------------------------------- 
     1              jbolz     Initial revision. 
     1              jbolz     Initial revision. 
Valid XHTML 1.1! Valid CSS! Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.