Nothing in particular is wrong per se with how the shader is written, there are almost always optimizations to be found though. About those:

- Generally speaking ASM is faster than HLSL. Although I haven't looked at Doom 3's shaders I would bet that a good portion of them are written using ASM. You can also use ASM within HLSL to optimize costly portions of the shaders by enclosing the ASM portion with a {};

- When using a lot of shaders (and this would qualify as a lot since it is used on the majority of surfaces) it is important to eliminate anything that is not a Programmable Shader. When the GPU processes the scene it is very costly in terms of GPU cycles to purge the FFP commands and load up the Programmable Shader commands. Some tests in my own engine have shown as much as 10-15% difference in the frame rate. This is something that might need to be fixed from within the engine itself since I am not sure if the engine will still issue built in FFP commands even if you manage to eliminate objects which use them from the scene.

- Co-issue commands. I only did a quick glance through the shader itself, but I didn't notice any such optimizations. If you leave this up to the GPU you may or may not recieve the benefits of this technique. However if you manually apply the proper masks you will recieve the performance boost.

- Optimize the number of passes. I am pretty sure you should be able to get that down to a 2 pass shader - although I will admit that most my shader programming has not been with 3DGS so there may be a limit that I am missing out on that causes you to render in this method. Use the first pass for culling to prevent overdraw and the second to actually render the lighting effects.

- Doom uses several rendering systems. Each major chipset has its own highly optimized rendering system including shaders which are optimized for that chipset. You can include similiar features in 3DGS with a bit of work too. An example of this are optimizing texture fetches and ALU instructions for ATI cards. Each clock cycle the GPU for the last generation of ATI cards (9500,9700, 9800...) could process one of each. By tweaking the techniques used you can optimize the shader to make full use of the available processing power of the GPU. NVidia has their own tricks and traps as well which is why using a shader specific to each chipset is important when looking at making the most out of shaders.



Other issues can really only be addressed with proper analysis of the scene. You may find that using so many normal maps and what not is leading to a bottleneck in texture calls. If this is the case you can look into using alternative methods of storing that data. Some of the issues need to be addressed by Conitec within the engine itself - others are more a factor of the end user of your shader (Nadester using normal maps which were way too large) but the biggest difference between a game like Doom and a tech demo done with 3DGS is the time spent tweaking it.

Writing the switches needed to identify end user hardware and even testing shaders on that hardware is very time consuming - but without doing that 3DGS will look like it is holding a candle in the wind when compared to Doom 3 or Half Life 2.

Quote:

---

- Optimize the number of passes. I am pretty sure you should be able to get that down to a 2 pass shader - although I will admit that most my shader programming has not been with 3DGS so there may be a limit that I am missing out on that causes you to render in this method. Use the first pass for culling to prevent overdraw and the second to actually render the lighting effects.

---

im not sure how unless i eliminate some the lights(which i plan on doing as soon as i get the newest beta that fixes the Max_lights problem). It seems to me that you can only calculate a maximum of 3 lights with falloff in one pass..there just arent enough output registers. Unless im missing something here and you can pack in more lights somehow.

In any case.. i like the idea of using a first pass to cull, but how can this be done.. how do you tell the second pass whats been culled already?

However you make a good points with using assembly to speed some parts.. i will look into that. Also Co-issuing calls is something i have no clue about.. i will look into this too.

As i said before however.. my framerates are quite good in my own maps.. there is certainly a lot of optimization that you can do in compiling.

Usually it is done using something along the lines of the texdepth command in a Pixel shader. I have heard of some success using vertex shaders though and that should be a bit more efficient too. I'll poke around tonight and see what I can dig up on the depth test technique in terms of online documentation. I think I first learned of it in ShaderX though. Needs PS 1.4 to work - and it is pretty efficient too (solves the nasty z-buffer sorting error as well). The culled data when using texdepth (or more correctly data that is not culled) gets passed to the r5(have to double check?) registry and can be passed on to additional shaders and passes as needed.

The lights were my bad. I went back and took a look at the technique I am using and it is one ASM pass per light. According to my notes the ASM versus HLSL freed up about 15 FPS. Also using the initial pass to set the z-buffer made it so that I do not need to deal with a lot of extra pixels which will not be seen anyway (exact numbers will vary depending on scene complexity but it appears to have been almost a 25-35% improvement).

Like I said though I will look for the documentation on that culling technique tonight. I have too much junk covering my desk now to find it quickly and my bookmarks have become almost worthless (too many damned sites bookmarked). It will likely need some tweaking to work with 3DGS, but it is a pretty simple shader to set up (might even solve Orange Brat's depth problem for prerendered back grounds...at least it should be able to in theory).

thnx a lot for your help and knowledge.. i look forward to hearing more i will also do some research into this.

Just got done emptying half my desk o' junk and haven't found it yet. However when I was looking through the documentation of two of the engines we are evaluating for use at work I decided to poke at the shaders section...

Right now both are recomending using a seperate pass per light using a 2.0 with a 1.4 fall back shader for optimum results on DX9 hardware for per-pixel lighting. Seems as though that might be something to investigate for 3DGS as well.

Ugh - back to the stacks...
________________________________

Did some more looking today - I must have my notes at work right now. However there are a couple articles that quickly glaze over the issue on Gamasutra and GameDev.net. Also when looking online use the keywords "depth test."

As far as chip specific techniques I have been implementing an optimized path for ATI chips the past few days. It uses the HyperZ technology which is ATI only. The premise is similiar, but the ATI cards can process larger chunks at a time than other manufacturers and writing a pipeline for that specific chipset comes in quite handy.

For anyone who is doing a lot of shader programming consider working in fragments as opposed to complete shaders. NVidia and Microsoft both have handy fragment tools which will allow you to assemble predefined shader fragments into complete shaders which aids in the process of developing multiple paths (you will still need to implement switches in C-script...but that is pretty simple).