In real life, how much cool stuff does SM4 & SM5 bring?

Started by
7 comments, last by coderchris 13 years, 2 months ago
Other than things like increased shader operation count, what big changes do newer shader models provide in terms of new features?
Or put in other words, once you start working in SM4/5, what would you notice if you had to go back to SM3?

www.simulatedmedicine.com - medical simulation software

Looking to find experienced Ogre & shader developers/artists. PM me or contact through website with a contact email address if interested.

Advertisement

Other than things like increased shader operation count, what big changes do newer shader models provide in terms of new features?
Or put in other words, once you start working in SM4/5, what would you notice if you had to go back to SM3?


Some things that are awesome about SM4 and SM5 are Compute Shaders and unordered access. They basically allow you to use your GPU as a flexible parallel processor. https://channel9.msd...o-DirectCompute
The best thing from shader model 4 is that you have more registers so that you can make almost anything that you could think of doing on the CPU. :)
SM5 implies that you have D3D11, which means that you will have multithreaded rendering. That's a pretty big plus in my book...

SM5 implies that you have D3D11, which means that you will have multithreaded rendering. That's a pretty big plus in my book...


Could you explain to my ignorant self what that means please? I thought all post DX 9 versions had multithreaded rendering, as in for example pixel shaders processing each pixel in a seperate thread. I thought that was the whole GPU rendering as opposed to software rendering, as in that's what made it so fast relatively.
Here's a list, off the top of my head:

1. Integer support
2. MSAA texture access
3. Generic texture array access
4. Direct depth buffer access, both with MSAA and without
5. Built-in support for comparison sampling with or without bilinear (basically Nvidia's "hardware shadow maps" without the driver hacks)
6. Gather sampling (gathers 4 results from the red, green, blue, or alpha channels of a texture from a 2x2 block of texels). Can also do a gather with comparison.
7. Methods to query texture dimensions or MSAA count
8. Methods to query the MSAA sample pattern
9. Generic Buffer resource access (no need to always store data in textures if it needs to be accessed in the shader)
10. Full control over pixel shader input interpolation (perspective-correct, no perspective correction, no interpolation, centroid-snapped, snapped to an MSAA sample point)
11. Geometry shader stage, lets you perform per-primitive operations and amplify your data (simplest example is expanding a single point into a billboarded quad, for particles)
12. Tessellation stages are available in SM5.0
13. Compute shader stage is available in SM5.0
14. Can have the geometry shader select from 1 of 8 viewports to be used for rasterizing the primitive
15. Can have the geometry shader select from 1 of 8 render targets in a render target array
16. Can run pixel shaders for each MSAA sample, rather than for each pixel
17. Pixel shader can take triangle coverage as an input
18. Pixel shader can write triangle coverage as an output, allowing for custom alpha-to-coverage type effects
19. Textures are decoupled from sampler states. Rather than binding a texture to a slot and setting states for that slot, you bind textures and complete sampler states and then your shader decides which sampler to use when sampling a texture
20. Raw unfiltered reads from textures via Load, which take 2D integer indices rather than texture coordinates
21. Stream output lets your write out a fully processed vertex buffer so that you can reuse it (nice for skinned models that get used in multiple passes)
22. AppendStructuredBuffer/ConsumeStructuredBuffer lets pixel or compute shaders push data onto a buffer, which can then be pulled out in another stage. This is *really* useful for certain cases.
23. Constant buffers. If you've done any serious work at all then you know that dealing with constant registers is a nightmare. Constant buffers solve those problems.
24. All shader stages can index into constants and temporary registers. So no more bullshit when trying to write loops in pixel shaders.

So yeah, tons of cool stuff. I work with SM5 at home then go back to SM3 at work, and it sucks.

[quote name='Jason Z' timestamp='1298327188' post='4777254']
SM5 implies that you have D3D11, which means that you will have multithreaded rendering. That's a pretty big plus in my book...


Could you explain to my ignorant self what that means please? I thought all post DX 9 versions had multithreaded rendering, as in for example pixel shaders processing each pixel in a seperate thread. I thought that was the whole GPU rendering as opposed to software rendering, as in that's what made it so fast relatively.
[/quote]

He was talking about multithreaded command submission on the CPU, not about shader execution.
He was talking about multithreaded command submission on the CPU, not about shader execution.


Ah thank you. And nice list! :)

---


The best thing from shader model 4 is that you have more registers so that you can make almost anything that you could think of doing on the CPU. :)


Which brings us to a side question: what can't you make that can do on the CPU?

AFAIK that includes: recursion, pointers, classes, and unordered access on all arrays.
[color=#1C2837][size=2]Which brings us to a side question: what can't you make that can do on the CPU?

AFAIK that includes: recursion, pointers, classes, and unordered access on all arrays.[/quote]

Recursion: you can emulate that in a shader with a stack. See humus's recursion demo: http://www.humus.name/index.php?page=3D

Pointers: you could just use an int that is an index in an UAV. That int would be your "pointer".

Classes: Interfaces are supported in SM5. You could emulate classes though by making a struct that holds your data, and write functions that operate on that struct.

This topic is closed to new replies.

Advertisement