• Advertisement
Sign in to follow this  

Implement Graphics Pipeline On Compute Shader

This topic is 868 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello earth people,

 

Say, would it be a fools errand to implement the entire graphics pipeline that would include

  • Vertex Shading
  • Rasterization
  • Pixel Shading

On compute shader and expect it to have better performance.

 

I understand a lot of hardware based computations like post transform vertex cache, rasterization, etc ,etc speed up the rendering process.

 

But I was wondering that there a lot of computations that could still be avoided that are there in traditional graphics pipeline.

 

I have a few methods in mind that could render a triangles using only one compute shader stage. Meaning just by calling Dispatch once the compute shader will do all vertex transformation, rasterization and pixel shading. So I was about to start implementing it anyways, I thought maybe any of you would have done this before and if it was a fail it would save a lot of my time. rolleyes.gif I have a lot of doubts like could a compute shader based rasterization be comparable to performance of fixed pipeline rasterization.

 

This compute shader based technique opens me a lot of nice ways to implement shadow mapping and order independent transparency which might just be faster or way faster than the standard methods. 

 

Thankssmile.png 

Share this post


Link to post
Share on other sites
Advertisement

You can absolutely make an entire rendering pipeline in compute shaders. If you're just trying to do exactly the same things the typical 3D pipeline does though, you're probably never going to beat it or come within an order of magnitude as fast as it though. It's been optimized on a hardware level to transform, rasterize, and shade triangle lists into a frame buffer. It doesn't really make sense that you could beat this exact pipeline because if you could, why wouldn't nvidia or amd just make that the default pipeline instead? 

 

I recall someone teaching students about 3D graphics pipelines by making them implement everything it traditionally does using compute shaders but I'm having trouble finding the link. It's definitely a good learning exercise but if you want to draw a triangle soup, nothing's going to beat drawing a triangle list, at least right now. In another thread I demonstrated that even writing a value to a texture using a compute shader won't necessarily beat drawing a quad to the screen and using a pixel shader: http://www.gamedev.net/topic/673687-d3d12-use-compute-shader-to-write-to-swap-chain-backbuffer/

 

Compute shaders will beat the normal pipeline if you're doing some kind of atypical rendering technique that the normal pipeline isn't well suited for. 

Edited by Dingleberry

Share this post


Link to post
Share on other sites

Sometimes its worth doing something just to understand why it can't or shouldn't be done; and while I think its highly unlikely (very very unlikely), its not entirely impossible.

Share this post


Link to post
Share on other sites
Also consider a bunch of gpu functions aren't exposed in dx12, like nvidias dynamic kernel dispatching available in cuda. Internally the driver can go hog wild in ways we can't.

Share this post


Link to post
Share on other sites

I've tried it a few years ago with openCL on an 560Ti and got in about 10% of the rasterization performance (with shading, shadowmapping, forward+ rendering).

 

The nice part was that the whole scene was on the GPU, all object-instances were in a buffer that I've handled on GPU for rendering (e.g. frustum and occlusion checks). The problem I've got back then was resource handling (mainly textures).

Share this post


Link to post
Share on other sites

See Beating The GPU At Its Own Game.

 

The general comment is:

Laine and Kerras, and their predecessors, have been trying to replicate the full graphics pipeline in its entirety. I’ve always been kindof skeptical of this type of research, since the results are generally measured in multiples of how much slower it goes

However, as is the point of that post, there can be exceptions.

Share this post


Link to post
Share on other sites


See Beating The GPU At Its Own Game.

 

That's really cool. I originally thought the rasterizer was choking on the small triangles and overdraw, but if you zoom out the rasterizer starts beating the compute shader again. I haven't looked too much at the code but I'm not really sure why that is, it seems like that's the best scenario for the compute shader as I would think mapping a ton of triangles and depths to the same pixel location would be bad for the typical z buffered pipeline.

Share this post


Link to post
Share on other sites


I demonstrated that even writing a value to a texture using a compute shader won't necessarily beat drawing a quad to the screen and using a pixel shader: http://www.gamedev.net/topic/673687-d3d12-use-compute-shader-to-write-to-swap-chain-backbuffer/

I see, interesting.

 


Sometimes its worth doing something just to understand why it can't or shouldn't be done

Yep the same reason that inspires me.

 

 

Just what I was looking for, Thanks matebiggrin.png

 


See Beating The GPU At Its Own Game.

Also what I was looking forbiggrin.png

 


I've tried it a few years ago with openCL on an 560Ti and got in about 10% of the rasterization performance

Just 10%, hmmmsad.png. You migth have any idea why would you be getting 10x slower performance?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement