<p>If you really want to obtain every fragment (shading sample) within the camera frustum, regardless of occlusion, one way to do it would be to disable depth testing, and then use a large <a href="https://www.opengl.org/wiki/Shader_Storage_Buffer_Object" rel="nofollow">SSBO</a> together with an <a href="https://www.opengl.org/wiki/Atomic_Counter" rel="nofollow">atomic counter</a> to append data into the buffer from the fragment shader.  Each fragment could then store a record of its screen position, depth, color, and any other desired information into the buffer to be read out later.  The buffer has to be large enough to store every fragment rendered, as it will throw away any extra data once it's full.</p>

<p>Using one huge SSBO for the whole screen likely isn't ideal, as there will be huge contention on its counter with every fragment trying to increment it.  A better way might be to slice up the screen in tiles with an SSBO+counter per tile.  There is a limit of 16 bound SSBOs on all current GPUs, and on AMD GPUs, there is a further limit of 8 atomic counters (source: Sascha Willem's <a href="http://delphigl.de/glcapsviewer/gl_listreports" rel="nofollow">OpenGL Hardware Database</a>).  Those limits will determine how many tiles you can create. This will reduce contention and also ensure that even if you run out of memory in one tile, you'll still have valid data in the others.</p>

CC BY-SA 3.0
2015-08-25T06:53:55.193Z
2015-08-25T06:53:55.193Z
Nathan Reed
<p>Im developing a deep texture processing engine. Right now I have a software renderer to generate the raster samples. Now, for bigger renders it would be nice to do this on hardware.</p>

<p>Is there a standard mechanism on how to capture the data of each shader evaluation in OpenGL? I could do some sort of depth peeling but it seems to me as a bit too brute forcelike approach. I don't mind the time cost just as long as it does not take ages to implement the infrastructure needed.</p>

CC BY-SA 3.0
2015-08-25T06:08:38.767Z
You could render every pass to a texture and read back the buffers to obtain the output.
Nero
CC BY-SA 3.0
2015-08-28T06:10:02.113Z
As an improvement to depth peeling, you might look into [Multi-Layer Depth Peeling Via Fragment Sort](http://research-srv.microsoft.com/pubs/70307/tr-2006-81.pdf) which allows you to extract multiple layers in each pass, reducing the total number of passes needed.
Nathan Reed
<opengl><rendering>
Is there a way for me to record every shading sample for a deep texture
joojaa
# Is there a way for me to record every shading sample for a deep texture

(Asked by: username_0 on 2015-08-25)

Im developing a deep texture processing engine. Right now I have a software renderer to generate the raster samples. Now, for bigger renders it would be nice to do this on hardware.

Is there a standard mechanism on how to capture the data of each shader evaluation in OpenGL? I could do some sort of depth peeling but it seems to me as a bit too brute forcelike approach. I don't mind the time cost just as long as it does not take ages to implement the infrastructure needed.

**Tags:** opengl, rendering

> **Comments:**
> **username_1**: You could render every pass to a texture and read back the buffers to obtain the output.  
> **username_2**: As an improvement to depth peeling, you might look into [Multi-Layer Depth Peeling Via Fragment Sort](http://research-srv.microsoft.com/pubs/70307/tr-2006-81.pdf) which allows you to extract multiple layers in each pass, reducing the total number of passes needed.  

---

## 1 answers

### Answer by username_2 on 2015-08-25. Score: 4 | Accepted answer

If you really want to obtain every fragment (shading sample) within the camera frustum, regardless of occlusion, one way to do it would be to disable depth testing, and then use a large [SSBO](https://www.opengl.org/wiki/Shader_Storage_Buffer_Object) together with an [atomic counter](https://www.opengl.org/wiki/Atomic_Counter) to append data into the buffer from the fragment shader. Each fragment could then store a record of its screen position, depth, color, and any other desired information into the buffer to be read out later. The buffer has to be large enough to store every fragment rendered, as it will throw away any extra data once it's full.

Using one huge SSBO for the whole screen likely isn't ideal, as there will be huge contention on its counter with every fragment trying to increment it. A better way might be to slice up the screen in tiles with an SSBO+counter per tile. There is a limit of 16 bound SSBOs on all current GPUs, and on AMD GPUs, there is a further limit of 8 atomic counters (source: Sascha Willem's [OpenGL Hardware Database](http://delphigl.de/glcapsviewer/gl_listreports)). Those limits will determine how many tiles you can create. This will reduce contention and also ensure that even if you run out of memory in one tile, you'll still have valid data in the others.


---

