2006-05-24

 

Back to some shader programming

There is something magic in programming shaders. Like, when you edit one of our standard shaders and save, say, nine instructions in it - the feeling is really good. Maybe because, well, it's a standard shader - so that means everyone's graphics will actually render faster. Nice!

Maybe it's because shaders are such a short piece of code, without too complex dependencies... I'm sure anyone who knows graphics hardware will corect me here, but let's oversimplify and pretend that shaders actually execute in a simple way... So when you make a shader shorter, you pretty much know it's going to be faster. When you make it "look better", it almost certainly will look better. Try doing that in your regular big codebase - by optimizing something you may break something else; and in general you have no clue what to optimize unless you do your profiling homework. So, my take is that shaders are much simpler, so the joys of looking at assembly output actually make sense.

So, yeah, I'm back to some shader programming.

Comments
Hurray for the simple yet powerful toys ;)

Mav.
 
haha yeah i know this feeling exactly. it's always nice too after some time to go back through some shaders and realize an optimization. pixel shaders are great because you find a way to save a cycle or two then can multiply that by the number of pixels on the screen using that shader and feel very good about your even 1 cycle optimization. :D
 
uhmm... except that it's becoming not so true this days ;)
 
yeah. It's sad that programmers have so little insight about what happens in the hardware. We don't have to worry about threads, stalls, partial stalls, bypasses, load balancing, and all the schedulling problems that the compiler (assembler) solves for us.

On one side, being isolated from those problems is nice, because the two major IHVs have very different architectures, and not exposing that information allows them to change the architecture from one generation to the next.

However, I don't really like this situation. IHVs are monopolizing information that in the case of CPUs was public knowledge. On the days of the Pentium I used to know the uv pareability of every asm instruction and the number of cycles it took to execute. People could write compilers on their own! Today only IHVs can do that and if they don't support your favourite platform, (ie linux-ppc) you are screwed.

In any case, I'd recommend to use nvShaderPerf on nvidia hardware, sometimes you will get a surprise as shorter does not always mean faster.
 
ReJ/Ignacio: yeah, that's what my mean by "let's oversimplify a bit".
Still, the nice thing about shaders is that you can profile fairly easily, and (another oversimplification here) they are quite independent from the rest of your "stuff".
 
Post a Comment

<< Home