geekcomputing
[H]ard|Gawd
- Joined
- Aug 30, 2004
- Messages
- 1,100
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.
pixel shaders article .... ps3.0
- Thread starter geekcomputing
- Start date
.DamienThorn
[H]ard|Gawd
- Joined
- Nov 28, 2004
- Messages
- 1,937
That's a wicked link. Thx for finding and posting it!
Uhmm, that's actually fairly crappy summary of shaders, and the features that the various shader models allow. Plus, it contains some significant bits of misinformation (the one that flies out at me is the instruction count summary on the final page). I'll write up a summary of points they missed or were wrong about later.
Indeed, there are a few small errors, such as that only 3.0 shaders allow floating point precision.
But I guess the idea is clear, and unless you actually want to program shaders yourself, the minor details don't really matter. All the info is in the DirectX SDK anyway.
But I guess the idea is clear, and unless you actually want to program shaders yourself, the minor details don't really matter. All the info is in the DirectX SDK anyway.
The only notable jumps in shader versions are from 1.x to 2.x. 1.x shaders were in general VERY limited, with few registers (I think it was 8x4 floats?), few instruction slots and not many functions (yay, we can, um, add, multiply, move...). SM2.0 was literally a revolution by comparison. Suddenly, devs could handle a lot more data, and do more with the data, and shaders actually became USEFUL. SM2.x and SM3.0 however, offered little more potential. Yes, registers, instructions and instruction counts rose a lot more, but there are few algorithms that, image quality wise, 2.0 could not do. Also, vertex texture lookups are not that great, imo, and loops do not work as well as many people would like them to. The image quality that branching brings could even be simulated on SM2.0 hardware, as evidenced by the fact that the HLSL compiler can do if statements just fine when compiling to an SM2.0 target. Basically, the jump to SM2.x and SM3.0 aren't all that bit-tech cracks it up to be, and they seem to hail it as something that is blowing the minds of graphics programmers, while in the real world there is actually a small debate over how useful SM3.0's features really are.
What higher colour precision? 24-bits is STILL enough for any graphics algorithm out there. The HDR support is an entirely seperate feature that came with SM2.0 cards (9x00 and FX). The 3.0 path is able to use HDR because so many more instructions are required for all of the post process effects (bloom, glare, exposure) that people associate HDR with. Also, it is primarily because of those effects that performance suffers, not just because floating point render targets are suddenly being used.
No, fewer passes are required on SM3.0 hardware because SM1.1 is so damn limited.
I'd be SHOCKED if the soft shadows come in because of the dynamic branching. I haven't seen SC:CT myself, but I can bet that it's just because they need the increased instruction count that SM3.0 provides. It's also likely that SM2.x could run those shaders A-OK as well.
That's only half right. The so-called shader unification of "SM4.0" is just because finally vertex and pixel shaders will have the EXACT same capabilities. Hence, it almost follows directly that a shader core could be used for vertex or pixel usage.
Huh? What happened to Avalon?
*BZZZZT* WRONG! http://msdn.microsoft.com/library/e...aders/pixelshaders/pixelshaderdifferences.asp The top of the page there lists the instruction counts for each shader model (vertex instruction counts are basically right, though). Dynamic branching? Yeah, woo, like I said earlier, so what? Backface register? All that contains right now is a freakin' sign, and I can't even think of ANY practical use for it (two lighting calcs in one pass couldn't be further from the truth). Maybe occlusion queries on the PS? Colour depth? Wrong again, SM2.0 AND SM3.0 cards support 16-bit (per channel) floating point targets, not just 8-bit or 32-bit like bit-tech thinks. Nested looping? Yay, now I can do some loops where the different variable I access is a vertex input register! It's so useless, just do it the Crytek way and just make some different shaders that behave like loops!
*hits preview* Damn, that turned out to be pretty long. Oh well, at least you know that bit-tech editors just glance over information they don't really know and make it seem like they know it.
Edit: Whoops, missed one point. 32-bit per channel FP targets DO exist, I forget what cards support them. I know I'm using a single-channel 32-bit FP target at home for my shadowing demo on my X800Pro, so Xx00 and 6x00 cards probably support them, assuming 9x00 and FX don't.
Cypher19 said:
Actually, the post-processing is done in a separate pass after the initial image is rendered. With more instructions it's easier to do larger filters in a single pass, but it's not strictly required (multipassing with a single fullscreen quad is not all that expensive, usually not the bottleneck).
The main difference is that (in practice) SM3.0 cards have floating point alphablending, which makes it really easy and efficient to handle translucent surfaces in a HDR-image.
It's not impossible without it, but it is just harder to do, and less efficient.
Two-sided lighting ofcourse. You apply the sign to the normalvector, so backfaces can be lit properly aswell. Normally you'd have to double the backface geometry and send it twice, with the proper normal for each side, or alternatively render the geometry twice, first with a frontface shader and backface culling, then with a backface shader and frontface culling. Not a good idea in geometry-limited situations.
9x00 supports 32-bit per channel though generic Direct3D formats. FX lacks proper texture address wrapping logic for FP targets, so it only supports some proprietary formats, but by using those you can still render to 16 and 32-bit per channel surfaces.
Cypher19 said:
Think of objects with holes in them, or translucent objects, where the surface can be viewed from both sides.
Heck, even something as simple as a wall or a tablecloth could be viewed from both sides.
Just any non-convex, non two-manifold object you can think of, really.