Comments on: Implementing fixed function T&L in vertex shaders http://aras-p.info/blog/2009/06/09/implementing-fixed-function-tl-in-vertex-shaders/ Random thoughts of a triangle pusher Fri, 10 Feb 2012 03:15:49 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Aras Pranckevičius http://aras-p.info/blog/2009/06/09/implementing-fixed-function-tl-in-vertex-shaders/comment-page-1/#comment-19434 Aras Pranckevičius Fri, 12 Jun 2009 03:33:39 +0000 http://aras-p.info/blog/?p=364#comment-19434 @ryg: that's beyond awesome. Thanks for sharing! @ryg: that’s beyond awesome. Thanks for sharing!

]]> By: Fabian "ryg" Giesen http://aras-p.info/blog/2009/06/09/implementing-fixed-function-tl-in-vertex-shaders/comment-page-1/#comment-19431 Fabian "ryg" Giesen Thu, 11 Jun 2009 21:46:40 +0000 http://aras-p.info/blog/?p=364#comment-19431 Woops, just noticed: view the files with tab width 2 or they're screwed up (sorry, should've cleaned this up before uploading). Woops, just noticed: view the files with tab width 2 or they’re screwed up (sorry, should’ve cleaned this up before uploading).

]]> By: Fabian "ryg" Giesen http://aras-p.info/blog/2009/06/09/implementing-fixed-function-tl-in-vertex-shaders/comment-page-1/#comment-19430 Fabian "ryg" Giesen Thu, 11 Jun 2009 21:45:29 +0000 http://aras-p.info/blog/?p=364#comment-19430 Just for the sake of showing how a bytecode-based solution looks, I've put the shader generator code that was used for debris (and also the never-materialized kkrieger final, and a couple of other things) online here: http://www.farbrausch.de/~fg/code/shadergen/. It's basically a custom shader assembler that supports (macro assembler level) flow control. Everything is stored as shader bytecode, with some new opcodes for the flow control instructions. This was mainly for size reasons; the only thing that is needed on the app side is shadercodegen.cpp, which is comperatively tiny (boiled down to about 880 bytes of code in the final executable), somewhat at the expense of readability. That's the part that also resolves flow control and register allocation, and even though it has some limitations you need to work around at the source level, I'm still quite fond of it. :) I've also thrown in the sources for the "ubershader" used in kkrieger (long before that term was coined) and the tons-of-permutations multipass lighting stuff used in debris to show some examples. I certainly don't miss writing these, but still, merely having variable names with automatic register allocation made them an order of magnitude more useful than "plain" ASM shaders; the flow-control with automatic bitfields on everything (that's what the [16..19] after a variable name means, it's bits 16 through 19) is admittedly weird, but that allowed me to pass the material parameters to the shader compiler directly in the bitpacked format in which it was stored. Not very clean, but it got rid of a whole translation layer, which was lots of code. (This kind of fakery is precisely why I'm sick of size-optimizing!) Just for the sake of showing how a bytecode-based solution looks, I’ve put the shader generator code that was used for debris (and also the never-materialized kkrieger final, and a couple of other things) online here: http://www.farbrausch.de/~fg/code/shadergen/. It’s basically a custom shader assembler that supports (macro assembler level) flow control. Everything is stored as shader bytecode, with some new opcodes for the flow control instructions. This was mainly for size reasons; the only thing that is needed on the app side is shadercodegen.cpp, which is comperatively tiny (boiled down to about 880 bytes of code in the final executable), somewhat at the expense of readability. That’s the part that also resolves flow control and register allocation, and even though it has some limitations you need to work around at the source level, I’m still quite fond of it. :)

I’ve also thrown in the sources for the “ubershader” used in kkrieger (long before that term was coined) and the tons-of-permutations multipass lighting stuff used in debris to show some examples. I certainly don’t miss writing these, but still, merely having variable names with automatic register allocation made them an order of magnitude more useful than “plain” ASM shaders; the flow-control with automatic bitfields on everything (that’s what the [16..19] after a variable name means, it’s bits 16 through 19) is admittedly weird, but that allowed me to pass the material parameters to the shader compiler directly in the bitpacked format in which it was stored. Not very clean, but it got rid of a whole translation layer, which was lots of code. (This kind of fakery is precisely why I’m sick of size-optimizing!)

]]> By: steve http://aras-p.info/blog/2009/06/09/implementing-fixed-function-tl-in-vertex-shaders/comment-page-1/#comment-19414 steve Tue, 09 Jun 2009 09:54:45 +0000 http://aras-p.info/blog/?p=364#comment-19414 Nice work! I think I would have done it as a Cg/HLSL fragment generator (and maybe cached compiled assembler in GL and bytecode in D3D), but that's because I've totally gone off working with assembler these days (it's the age). Your way is clearly more hardcore :) Nice work! I think I would have done it as a Cg/HLSL fragment generator (and maybe cached compiled assembler in GL and bytecode in D3D), but that’s because I’ve totally gone off working with assembler these days (it’s the age). Your way is clearly more hardcore :)

]]>