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

Thread: Any way to do depth testing per fragment?

  1. #1
    Intern Contributor
    Join Date
    Nov 2010
    Posts
    61

    Any way to do depth testing per fragment?

    Hello,

    I'm drawing a bunch of fuzzy lines in 3D space, and they can cross and re-cross each other so that it isn't possible to sort them by depth. If one line is drawn closer to the camera, then another line passes behind it, that second line is not drawn properly as it passes underneath the first line. The second line fails the depth test where the fuzzy edges of the first line are.

    Is there any way to check the depth values from within the fragment shader? It seems like this should be possible but maybe not, due to the parallel nature of fragment shaders. If I could compare the two depths of the fragments, then I could blend them appropriately. It wouldn't work once you had a lot of overlapping translucent values, but it would probably be good enough.

    Thanks
    Bob

    Click image for larger version. 

Name:	Screen Shot 2017-10-24 at 9.21.08 AM.jpg 
Views:	12 
Size:	7.4 KB 
ID:	2528

  2. #2
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,478
    Quote Originally Posted by bsabiston View Post
    Is there any way to check the depth values from within the fragment shader?
    Not easily. Or efficiently. You can't read from a texture which is bound as a framebuffer attachment. For read-modify-write, you can use image atomic operations, but there's a performance cost due to the atomicity requirement. But at best, that's going to let you handle two layers correctly (i.e. you can handle one fragment rendered either in front of or behind a previous fragment, but then you have to decide which of the two depths to store, and the choice will affect the handling of a third fragment which lies between the first two).

    Common approaches to order-independent transparency are "depth peeling" (which involves multiple render passes, each processing the Nth-nearest (or farthest) fragment), or maintaining a linked list of fragments for each pixel.

  3. #3
    Intern Contributor
    Join Date
    Nov 2010
    Posts
    61
    Thanks -- that's what I was afraid of. Do you know of any good references to the linked-list approach? How is that different from read-modify-write? All the GPU threads would be accessing the same list, wouldn't they?

  4. #4
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,928
    Quote Originally Posted by bsabiston View Post
    Thanks -- that's what I was afraid of. Do you know of any good references to the linked-list approach? How is that different from read-modify-write? All the GPU threads would be accessing the same list, wouldn't they?
    Each pixel has its own linked list (though they are all "allocated" from the same buffer). This is managed through the use of atomics. When a shader invocation "allocates" a new node from the buffer, it does so by bumping an atomic counter. The index it gets becomes the "pointer" for that linked list node (since the buffer is just an array of nodes). It then does an atomic-swap of this "pointer" into the pixel the invocation corresponds to. It takes the "pointer" value it got from the swap and stores it in the linked list node's "next" field.

    So each invocation will have a unique linked list node, and data races as to who puts their node into the pixel first don't matter, since the swap is atomic. And since each invocation has its own unique linked list node, they can poke at that data without caring about what other invocations are doing.

  5. #5
    Intern Contributor
    Join Date
    Nov 2010
    Posts
    61
    Thanks -- sounds like I have some things to learn before I can tackle this approach, but I like the idea of it.

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
  •