<p>Yes you can, this is how deferred rendering for example would work. For that you would render to a texture in one pass, in openGL this would be via an FBO, then feed that texture as the input to the next pass/shader.</p>

CC BY-SA 3.0
2016-08-02T06:28:33.867Z
Isn't it a bit restrictive? I mean, IMO, the texture is not the best-suited data storage for passing data in general (but I am new to computer graphics and maybe I have to get used to it).
BPiek
CC BY-SA 3.0
2016-08-02T06:30:21.073Z
A texture is just a normal buffer, although in the fragment shader we use fancy sampler2D to read it with filtering/etc. You can use a compute shader to read it more in its raw form and skip the texture sampler stage.
PaulHK
CC BY-SA 3.0
2016-08-05T17:38:24.513Z
There's a few options. Render-to-texture is probably the most straightforward but also kind of wasteful unless you need the results of your calculations in screen-space (like in deferred rendering), since you're rasterizing geometry before you can do any calculation. There's transform feedback, where you pull the output of a vertex or geometry shader before it hits the rasterizer and write it back to a buffer instead, might be good for the use case you mentioned but I haven't tried it myself. Otherwise compute shaders are the way to go, they're not that scary once you get used to them ;-)
russ
CC BY-SA 3.0
2016-08-02T06:17:52.277Z
2016-08-02T06:17:52.277Z
PaulHK
<p>While the other answers are giving possible techniques to achieve what you're looking for, rendering your stuff into a texture is not always the best way if you need it as VBOs (i.e. vertex attributes) in the next render step (requiring either a read into a PBO and some index/coordinate/sizing magic or a vertex texture fetch).</p>

<p>An approach that would more accurately represent your 2nd point and be better when you need a transformation <em>from</em> a buffer <em>into</em> a buffer would be what's called <a href="https://www.khronos.org/opengl/wiki/Transform_Feedback" rel="nofollow noreferrer"><strong>Transform Feedback</strong></a> (or Stream Output in the DirectX world). However, this requires OpenGL 3/DirectX 10 hardware (however, not necessarily the GL4/DX11 needed for compute shaders). It's also a little less of a synchronization mess than compute shaders with arbitrary shader storage buffers when your use case is really just to transform a bunch of vertices/primitives into a nother bunch of vertices/primitives.</p>

<p>It basically lets you <strong>hook into the render pipeline after the vertex (or rather primitive) processing step and before the rasterization</strong> and write out whatever per-vertex values you computed <strong>directly into a buffer object</strong> (that you can then use as vertex attributes in the next step). It therefore doesn't draw anything into the framebuffer either. You just specify a bunch of <code>varying/out</code> variables and how to format them into the buffer and bind a buffer to the corresponding binding point. You can also use a query to gather information of how many primtives were written (since a geometry shader could change that dynamically) or, in later versions, just render the results directly without any need for synchronization. For more details, see the above Wiki article.</p>

<p>Together with the geometry shader (which TF hardware should have, too) and its abilities for changing the primtive type or removing/adding vertices, this makes a useful tool for transforming your geometry however you deem fit in preparation of further rendering stages. Of course, it <strong>has to be evaluated if that really buys you anything</strong> in the particular use-case, especially if you're really just doing a simple vertex transformation.</p>

CC BY-SA 3.0
2017-09-30T17:06:32.490Z
2017-10-01T21:57:57.203Z
2017-10-01T21:57:57.203Z
Christian Rau
<h1>Question</h1>

<p>Is there a way to compute something in a first shader program (eg. screen-space coordinates from word-space ones) and access those results in an another shader program? </p>

<h1>Possible solutions</h1>

<ol>
<li>Give up multiple-shader-programs architecture and create one combined shader program</li>
<li>Save somehow results to a buffer objects (I couldn't find out if this is possible except computation shaders)</li>
<li>Render to texture and read the texture </li>
</ol>

<p>Is there a nicer solution?</p>

<opengl><shader><vertex-buffer-object>
Sharing calculation result between shader programs in OpenGL
BPiek
# Sharing calculation result between shader programs in OpenGL

(Asked by: username_0 on 2016-08-02)

# Question

Is there a way to compute something in a first shader program (eg. screen-space coordinates from word-space ones) and access those results in an another shader program?

# Possible solutions

1. Give up multiple-shader-programs architecture and create one combined shader program
2. Save somehow results to a buffer objects (I couldn't find out if this is possible except computation shaders)
3. Render to texture and read the texture

Is there a nicer solution?

**Tags:** opengl, shader, vertex-buffer-object


---

## 2 answers

### Answer by username_1 on 2016-08-02. Score: 2 | Accepted answer

Yes you can, this is how deferred rendering for example would work. For that you would render to a texture in one pass, in openGL this would be via an FBO, then feed that texture as the input to the next pass/shader.

> **Comments:**
> **username_0**: Isn't it a bit restrictive? I mean, IMO, the texture is not the best-suited data storage for passing data in general (but I am new to computer graphics and maybe I have to get used to it).  
> **username_1**: A texture is just a normal buffer, although in the fragment shader we use fancy sampler2D to read it with filtering/etc. You can use a compute shader to read it more in its raw form and skip the texture sampler stage.  
> **username_2**: There's a few options. Render-to-texture is probably the most straightforward but also kind of wasteful unless you need the results of your calculations in screen-space (like in deferred rendering), since you're rasterizing geometry before you can do any calculation. There's transform feedback, where you pull the output of a vertex or geometry shader before it hits the rasterizer and write it back to a buffer instead, might be good for the use case you mentioned but I haven't tried it myself. Otherwise compute shaders are the way to go, they're not that scary once you get used to them ;-)  

---

### Answer by username_3 on 2017-09-30. Score: 1

While the other answers are giving possible techniques to achieve what you're looking for, rendering your stuff into a texture is not always the best way if you need it as VBOs (i.e. vertex attributes) in the next render step (requiring either a read into a PBO and some index/coordinate/sizing magic or a vertex texture fetch).

An approach that would more accurately represent your 2nd point and be better when you need a transformation *from* a buffer *into* a buffer would be what's called [**Transform Feedback**](https://www.khronos.org/opengl/wiki/Transform_Feedback) (or Stream Output in the DirectX world). However, this requires OpenGL 3/DirectX 10 hardware (however, not necessarily the GL4/DX11 needed for compute shaders). It's also a little less of a synchronization mess than compute shaders with arbitrary shader storage buffers when your use case is really just to transform a bunch of vertices/primitives into a nother bunch of vertices/primitives.

It basically lets you **hook into the render pipeline after the vertex (or rather primitive) processing step and before the rasterization** and write out whatever per-vertex values you computed **directly into a buffer object** (that you can then use as vertex attributes in the next step). It therefore doesn't draw anything into the framebuffer either. You just specify a bunch of `varying/out` variables and how to format them into the buffer and bind a buffer to the corresponding binding point. You can also use a query to gather information of how many primtives were written (since a geometry shader could change that dynamically) or, in later versions, just render the results directly without any need for synchronization. For more details, see the above Wiki article.

Together with the geometry shader (which TF hardware should have, too) and its abilities for changing the primtive type or removing/adding vertices, this makes a useful tool for transforming your geometry however you deem fit in preparation of further rendering stages. Of course, it **has to be evaluated if that really buys you anything** in the particular use-case, especially if you're really just doing a simple vertex transformation.


---

