Comments on: Fixed function lighting in vertex shader – how? http://aras-p.info/blog/2009/01/22/fixed-function-lighting-in-vertex-shader-how/ Random thoughts of a triangle pusher Thu, 04 Mar 2010 23:01:48 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Pat Wilson http://aras-p.info/blog/2009/01/22/fixed-function-lighting-in-vertex-shader-how/comment-page-1/#comment-19417 Pat Wilson Tue, 09 Jun 2009 17:06:16 +0000 http://aras-p.info/blog/?p=261#comment-19417 Instead of implementing an ubershader, I implemented 3 very simple and small shaders which cover most simple cases: VertexColor, Texture, VertexColorModTexture, VertexColorAddTexture. This covers debug rendering, UI elements, simple particle systems, and such. Everything else must use a proper Material to render, in which case the Material system will take care of generating a shader, or using fixed-function to render the object. I don't favor the ubershader-FF approach because, in my opinion, it continues to re-enforce the entire fixed-function concept. Providing developers with a way to interact with a device in a deprecated way (like fixed function) is convenient, but it's the reason OpenGL's API is the way it is now. Instead of implementing an ubershader, I implemented 3 very simple and small shaders which cover most simple cases: VertexColor, Texture, VertexColorModTexture, VertexColorAddTexture. This covers debug rendering, UI elements, simple particle systems, and such. Everything else must use a proper Material to render, in which case the Material system will take care of generating a shader, or using fixed-function to render the object.

I don’t favor the ubershader-FF approach because, in my opinion, it continues to re-enforce the entire fixed-function concept. Providing developers with a way to interact with a device in a deprecated way (like fixed function) is convenient, but it’s the reason OpenGL’s API is the way it is now.

]]> By: Sean Barrett http://aras-p.info/blog/2009/01/22/fixed-function-lighting-in-vertex-shader-how/comment-page-1/#comment-16846 Sean Barrett Wed, 04 Mar 2009 19:41:05 +0000 http://aras-p.info/blog/?p=261#comment-16846 Aha, makes sense, thanks. Aha, makes sense, thanks.

]]> By: Aras Pranckevičius http://aras-p.info/blog/2009/01/22/fixed-function-lighting-in-vertex-shader-how/comment-page-1/#comment-16845 Aras Pranckevičius Wed, 04 Mar 2009 19:19:56 +0000 http://aras-p.info/blog/?p=261#comment-16845 @Sean: HLSL compiler is in D3DX (not in core D3D runtime). Nowadays it's in a DLL, so that's 3MB or so (we can't rely on the right DLL being present on user's machine, hence we'd need to include D3DX redist in our own installer). Back in the old days (SDKs from 2004), D3DX was a static library, so if you weren't using HLSL, the linker would strip it out. @Sean: HLSL compiler is in D3DX (not in core D3D runtime). Nowadays it’s in a DLL, so that’s 3MB or so (we can’t rely on the right DLL being present on user’s machine, hence we’d need to include D3DX redist in our own installer). Back in the old days (SDKs from 2004), D3DX was a static library, so if you weren’t using HLSL, the linker would strip it out.

]]> By: Sean Barrett http://aras-p.info/blog/2009/01/22/fixed-function-lighting-in-vertex-shader-how/comment-page-1/#comment-16842 Sean Barrett Wed, 04 Mar 2009 18:36:37 +0000 http://aras-p.info/blog/?p=261#comment-16842 Using HLSL instead of assembly requires an extra megabyte? How so? Does that stuff live in a library that if you can link in separately? Or it gets trimmed out automatically if you don't call it? I'd have assumed that was all DLLs at least. Using HLSL instead of assembly requires an extra megabyte? How so? Does that stuff live in a library that if you can link in separately? Or it gets trimmed out automatically if you don’t call it? I’d have assumed that was all DLLs at least.

]]> By: Aras Pranckevičius http://aras-p.info/blog/2009/01/22/fixed-function-lighting-in-vertex-shader-how/comment-page-1/#comment-16274 Aras Pranckevičius Fri, 23 Jan 2009 04:27:17 +0000 http://aras-p.info/blog/?p=261#comment-16274 @Michael: thanks, but using GLSL does not really help under DX9 (why DX9? Because D3D is <em>way</em> more stable than OpenGL on Windows). Also, ftransform() does not work as expected in some OpenGL implementations. E.g. on Apple platforms, ftransform() on some ATI cards does not work like it should - it produces different result than fixed function pipe. @Simon: I know. But I still have quite a large chunk of XP installs to support that won't go away soon. @Jack: thanks for the info. I guess I'll just work on this further and see what happens. @Michael: thanks, but using GLSL does not really help under DX9 (why DX9? Because D3D is way more stable than OpenGL on Windows). Also, ftransform() does not work as expected in some OpenGL implementations. E.g. on Apple platforms, ftransform() on some ATI cards does not work like it should – it produces different result than fixed function pipe.

@Simon: I know. But I still have quite a large chunk of XP installs to support that won’t go away soon.

@Jack: thanks for the info. I guess I’ll just work on this further and see what happens.

]]> By: Jack Palevich http://aras-p.info/blog/2009/01/22/fixed-function-lighting-in-vertex-shader-how/comment-page-1/#comment-16273 Jack Palevich Fri, 23 Jan 2009 03:17:17 +0000 http://aras-p.info/blog/?p=261#comment-16273 Oh, and as for"why" it happens, the answer is that floating point math operations are not associative or commutative, but the HLSL compiler (and sometimes the graphics drivers) pretend that they are. So it's not really a fixed function vs HLSL issue, its a "two shaders that do the same operations in a different order give slightly different results" issue. You can sometimes run into it with two similar HLSL shaders that end up being optimized differently. Skipping HLSL and using assembly fragments can help, but an aggressive driver can still decide to reorder the instructions in your shaders, leading to differences in results. Oh, and as for”why” it happens, the answer is that floating point math operations are not associative or commutative, but the HLSL compiler (and sometimes the graphics drivers) pretend that they are.

So it’s not really a fixed function vs HLSL issue, its a “two shaders that do the same operations in a different order give slightly different results” issue. You can sometimes run into it with two similar HLSL shaders that end up being optimized differently.

Skipping HLSL and using assembly fragments can help, but an aggressive driver can still decide to reorder the instructions in your shaders, leading to differences in results.

]]> By: Jack Palevich http://aras-p.info/blog/2009/01/22/fixed-function-lighting-in-vertex-shader-how/comment-page-1/#comment-16272 Jack Palevich Fri, 23 Jan 2009 03:06:01 +0000 http://aras-p.info/blog/?p=261#comment-16272 I've done something like this for Xbox 360, and it worked out pretty well. I think most Windows graphics drivers try pretty hard to optimize the shaders that are handed to them, so you probably don't need to do much optimization on your own. In fact you optimizations might even be counterproductive, because they might prevent the driver from doing some of its own optimizations. The Xbox 360, of course, does no run-time shader optimization. At least it didn't back when I was programming it. One problem you may run into is that for DX9 99% of games use HLSL rather than hand-written assembly, which means that the graphics drivers are only being tested and optimized for the kind of assembly that HLSL puts out. If you start feeding in your own assembly, you may find that you get sub-optimal results or even expose bugs in the drivers. (For example, there are some opcodes which HLSL never generates. If you start using those opcodes you may find the driver doesn't handle them correctly.) I highly recommend writing your shader generator to produce HLSL as well as assembly, so that you can compare the relative performance (and bugs). Also, you might find that the HLSL generation time isn't too slow. You will probably learn a lot about the fixed function pipeline. I know I did. :-) I’ve done something like this for Xbox 360, and it worked out pretty well. I think most Windows graphics drivers try pretty hard to optimize the shaders that are handed to them, so you probably don’t need to do much optimization on your own. In fact you optimizations might even be counterproductive, because they might prevent the driver from doing some of its own optimizations.

The Xbox 360, of course, does no run-time shader optimization. At least it didn’t back when I was programming it.

One problem you may run into is that for DX9 99% of games use HLSL rather than hand-written assembly, which means that the graphics drivers are only being tested and optimized for the kind of assembly that HLSL puts out. If you start feeding in your own assembly, you may find that you get sub-optimal results or even expose bugs in the drivers. (For example, there are some opcodes which HLSL never generates. If you start using those opcodes you may find the driver doesn’t handle them correctly.)

I highly recommend writing your shader generator to produce HLSL as well as assembly, so that you can compare the relative performance (and bugs). Also, you might find that the HLSL generation time isn’t too slow.

You will probably learn a lot about the fixed function pipeline. I know I did. :-)

]]> By: Simon Kozlov http://aras-p.info/blog/2009/01/22/fixed-function-lighting-in-vertex-shader-how/comment-page-1/#comment-16271 Simon Kozlov Fri, 23 Jan 2009 02:51:05 +0000 http://aras-p.info/blog/?p=261#comment-16271 I''m not sure if it helps, but FYI - Vista doesn't use fixed function pipeline at all (for WDDM drivers, which is everywhere), it's all implemented via vertex/pixel shaders so you shouldn't see the difference. I”m not sure if it helps, but FYI – Vista doesn’t use fixed function pipeline at all (for WDDM drivers, which is everywhere), it’s all implemented via vertex/pixel shaders so you shouldn’t see the difference.

]]> By: Michael Daum http://aras-p.info/blog/2009/01/22/fixed-function-lighting-in-vertex-shader-how/comment-page-1/#comment-16270 Michael Daum Fri, 23 Jan 2009 01:32:47 +0000 http://aras-p.info/blog/?p=261#comment-16270 Not sure if you're interested, but the ftransform() function in GLSL solves exactly this problem, providing the correct transform which will allow one to mix GLSL passes with GL fixed pipeline passes. Plus, you'll have portable code as a bonus after you switch from D3D!! Not sure if you’re interested, but the ftransform() function in GLSL solves exactly this problem, providing the correct transform which will allow one to mix GLSL passes with GL fixed pipeline passes. Plus, you’ll have portable code as a bonus after you switch from D3D!!

]]>