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 8 of 8

Thread: Make NV_texture_barrier core functionality.

  1. #1
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Make NV_texture_barrier core functionality.

    Both AMD and NVIDIA provide access to this extension across all of their 3.x and 4.x hardware. It's high-time this was core behavior.

    And no, glMemoryBarrier doesn't cut it. Besides the fact that it's not available in 3.x land, it doesn't do what glTextureBarrierNV does. Texture barrier is all about framebuffer object writes; glMemoryBarrier only is concerned with writes via atomic counters, image load/store, or shader storage buffers.

  2. #2
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Agreed. +1
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  3. #3
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    153
    In 4.3 you can use ARB_shader_image_load_store, ARB_framebuffer_no_attachments and glMemoryBarrier to accomplish what glTextureBarrierNV does. I don't see a point to add yet another feature to already huge, complex and very hard to implement API (NVIDIA and AMD aren't the only vendors).

  4. #4
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    No, you can't. ARB_shader_image_load_store only syncs image/UAV operations and atomic counter operations with any of the other accesses, but not framebuffer updates with texture accesses.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  5. #5
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,290
    I don't see issues in adding this to core. In the worst case it's a glFlush() + added flushing of texture caches.
    But for most things, I think it will be slower than image_load_store. (could you prove otherwise?)

  6. #6
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    I don't have any GL 4.x hardware, so I can't run performance tests. However, recall that the principle use of this feature is to allow a form of shader-based blending. Being able to perform a read/modify-in-shader/write loop to the same texel.

    Now, both image load/store and texture_barrier require calling a barrier function between different read/modify-in-shader/write passes. And each pass must not overlap with itself. Fair enough.

    However, texture_barrier has two major advantages. First, while the read/modify-in-shader/write loop is all about being able to do in-shader computations, that doesn't mean that you can't use hardware blending at all. You can combine your shader with a specific blend mode, so that you effectively get an additional operation for "free". It's not really "free", but it's not in the fragment shader; it's in the ROP. So the operation is pipelined and thus more efficiently uses the hardware. If the in-shader blending operation is fairly short, maybe only an extra math operation or two that `glBlendFunc` couldn't handle, odds are good that it'll be a non-trivial performance win.

    The other advantage is more substantial: hardware multisampling. If you write a fragment shader output, the hardware will use the coverage mask and write the fragment data to each coverage area using hardware ROPs. If you write the value with Image Load/Store, you must issue an imageStore call for each sample individually. Odds are good that the latter is going to be more expensive, since the hardware is optimized for multisampling, but it must assume that each individual imageStore operation is passing different data.

    I can't imagine how Image Load/Store would ever be faster than framebuffer writes, since it's the same algorithm either way. If that were true, then writing outputs via Image Load/Store would be cheaper than writing them to the current framebuffer. And that seems rather unlikely.

    The only place where the image load/store version might be a performance win would be if you're also using it to do order-independent transparency via pixel lists. And in that case, the performance gain/loss would depend on the nature of the scene. A scene with little transparency overlap would be relatively expensive in the image load/store case, while a scene with lots of overlap is cheap.

  7. #7
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,290
    The multisampling one seems invalid: to do any proper custom blending, you will have to do per-sample processing: fetch each individual texel sample, calculate, write one sample. Exactly the same flow as if you used image_load_store. Still, the gains from using ROP blending, that you mentioned, fortunately remain.

  8. #8
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    The multisampling one seems invalid: to do any proper custom blending, you will have to do per-sample processing: fetch each individual texel sample, calculate, write one sample. Exactly the same flow as if you used image_load_store.
    It depends on what you're doing and how accurate you want to be. If you read texels that correspond to the sample mask being written, then aggregate them together (effectively performing multisample resolve), you can still write one sample out with the proper sample mask, thus still benefiting from the hardware ROP writing.

    It's not as sample-accurate as doing per-sample shading, true. But then again, regular multisample without sample shading loses some accuracy too, compared to true super-sampling. So it is an accuracy-for-performance tradeoff. One that Image Load/Store doesn't let you make.

    That being said, it would be good if Image Load/Store had some functionality for doing writes to a texel with a sample mask, such that all of the given texels will get the same value. Though that might not be possible, depending on how the hardware actually implements multisample writes.

Posting Permissions

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