<p>While <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/bb509647%28v=vs.85%29.aspx">this MSDN page</a> does claim that SV_RenderTargetArrayIndex can be written in a pixel shader, I believe this is incorrect. Viewport array index and RT array index values are both intended to be output by the geometry shader stage. They can then be read by the pixel shader (and have a constant value per-primitive, based on the GS output). However, it is not possible to set these values from the pixel shader.</p>

<p>The stereo instancing approach detailed in those slides is interesting precisely because it avoids using slow geometry shaders. However, if you're not using GS, you can't use multiple viewports or render target arrays. That's why the stereo instancing approach uses one large viewport and bakes each eye's viewport transform into its projection matrix, and requires clip planes.</p>

<p>Clip planes should work, so if you're having problems with them, you could post another question detailing the specific issues (preferably with screenshots) and we can try to figure that out.</p>

<p>(For completeness, note that if you're using OpenGL, the <a href="https://www.opengl.org/registry/specs/AMD/vertex_shader_viewport_index.txt">GL_AMD_vertex_shader_viewport_index</a> extension is available on <a href="http://delphigl.de/glcapsviewer/listreports2.php?listreportsbyextension=GL_AMD_vertex_shader_viewport_index">recent GPUs from all three IHVs</a> and allows setting the viewport index from the vertex shader.)</p>

CC BY-SA 3.0
2016-01-27T11:40:47.010Z
Thanks for the reply Nathan, I did expect that MSDN page was incorrect from my initial experiments. I might give the clip planes solution another try when I get some time, i'll post another question when I have more information on what's going wrong. Thanks again for your help.
Garry Wallis
CC BY-SA 3.0
2016-01-30T00:40:49.583Z
Finally figured out why the VR prototype I did wasn't working. Turns out my prototype was a bit too simple, I was just doing the squish and move code to all vertex shaders and also doing all draws with an instance count of 2. This meant that when the last BLIT ran to copy the render target to the back buffer happened it also squish, moved and rendered twice causing the 4 views :) figured it out pretty quick once I'd captured in RenderDoc.
Garry Wallis
CC BY-SA 3.0
2016-01-30T00:41:03.577Z
BTW: Thanks again for the information on the SV_RenderTargetArrayIndex in the pixel shader now I've thought about it it makes sense that the RT output would need to be consistent across all pixels.
Garry Wallis
CC BY-SA 3.0
2016-01-27T07:15:21.190Z
2016-01-27T07:15:21.190Z
Nathan Reed
<p>I have been reading this paper by Timothy Wilson <a href="https://docs.google.com/presentation/d/19x9XDjUvkW_9gsfsMQzt3hZbRNziVsoCEHOn4AercAc/edit#slide=id.p" rel="noreferrer">Fast Stereo Rendering for VR</a>
and it would suit our game engine (DirectX 11) to use this method of stereo rendering. I have managed to get the game rendering Instanced and the screen squished into left and right areas like he mentions but am unable to get the SV_ClipDistance working correctly, when I use his methods or the method the jMonkeyEngine uses I get 4 views of the world! </p>

<p>My question is does anyone know if you can write SV_RenderTargetArrayIndex in a pixel shader according to MSDN it says it can be read and written by the pixel shader but in all my experimentation I am unable to get the shader to compile, it complains about too many outputs. If I could get this to work the instancing would work by just setting the SV_RenderTargetArrayIndex to SV_InstanceId. Any help would be much appreciated.</p>

<directx11><virtual-reality>
VR stereo rendering with Instancing
Garry Wallis
# VR stereo rendering with Instancing

(Asked by: username_0 on 2016-01-27)

I have been reading this paper by Timothy Wilson [Fast Stereo Rendering for VR](https://docs.google.com/presentation/d/19x9XDjUvkW_9gsfsMQzt3hZbRNziVsoCEHOn4AercAc/edit#slide=id.p)
and it would suit our game engine (DirectX 11) to use this method of stereo rendering. I have managed to get the game rendering Instanced and the screen squished into left and right areas like he mentions but am unable to get the SV\_ClipDistance working correctly, when I use his methods or the method the jMonkeyEngine uses I get 4 views of the world!

My question is does anyone know if you can write SV\_RenderTargetArrayIndex in a pixel shader according to MSDN it says it can be read and written by the pixel shader but in all my experimentation I am unable to get the shader to compile, it complains about too many outputs. If I could get this to work the instancing would work by just setting the SV\_RenderTargetArrayIndex to SV\_InstanceId. Any help would be much appreciated.

**Tags:** directx11, virtual-reality


---

## 1 answers

### Answer by username_1 on 2016-01-27. Score: 5 | Accepted answer

While [this MSDN page](https://msdn.microsoft.com/en-us/library/windows/desktop/bb509647%28v=vs.85%29.aspx) does claim that SV\_RenderTargetArrayIndex can be written in a pixel shader, I believe this is incorrect. Viewport array index and RT array index values are both intended to be output by the geometry shader stage. They can then be read by the pixel shader (and have a constant value per-primitive, based on the GS output). However, it is not possible to set these values from the pixel shader.

The stereo instancing approach detailed in those slides is interesting precisely because it avoids using slow geometry shaders. However, if you're not using GS, you can't use multiple viewports or render target arrays. That's why the stereo instancing approach uses one large viewport and bakes each eye's viewport transform into its projection matrix, and requires clip planes.

Clip planes should work, so if you're having problems with them, you could post another question detailing the specific issues (preferably with screenshots) and we can try to figure that out.

(For completeness, note that if you're using OpenGL, the [GL\_AMD\_vertex\_shader\_viewport\_index](https://www.opengl.org/registry/specs/AMD/vertex_shader_viewport_index.txt) extension is available on [recent GPUs from all three IHVs](http://delphigl.de/glcapsviewer/listreports2.php?listreportsbyextension=GL_AMD_vertex_shader_viewport_index) and allows setting the viewport index from the vertex shader.)

> **Comments:**
> **username_0**: Thanks for the reply username_1, I did expect that MSDN page was incorrect from my initial experiments. I might give the clip planes solution another try when I get some time, i'll post another question when I have more information on what's going wrong. Thanks again for your help.  
> **username_0**: Finally figured out why the VR prototype I did wasn't working. Turns out my prototype was a bit too simple, I was just doing the squish and move code to all vertex shaders and also doing all draws with an instance count of 2. This meant that when the last BLIT ran to copy the render target to the back buffer happened it also squish, moved and rendered twice causing the 4 views :) figured it out pretty quick once I'd captured in RenderDoc.  
> **username_0**: BTW: Thanks again for the information on the SV_RenderTargetArrayIndex in the pixel shader now I've thought about it it makes sense that the RT output would need to be consistent across all pixels.  

---

