SolarLiner
It's necessary, TARS.
So, since I can't really work on D3D9 anymore because of my new engineering school I'm attending, I spent some time thinking about my Lens Flare shader and the performance loss. There was something I knew all along but had forgotten to retrieve when I was making the shader.
Since I want it to be modular (as in, customizeable so that everybody can set its own to their liking), I did group code into functions that I thought would be simple enough to work with.
Now that I think of it, it's almost cringey; how would anyone that never touched shader code (or any code for that matter, since I'm setting a low knowledge level to try to include as much users as possible) modify the right part of the shader, without making mistakes, even if well documented? That seems a bit too much to ask.
So I had thought about a configuration file: that would bring the best of two worlds. But getting a configuration file to work, that the D3D9 Client would load and send arguments to the shader would be too complicated, and the amount of branching needed...
Wait.
That's what I knew all along but somehow forgot: GPUs are good at raw calculations, but very bad at branching. And my shader hit all the red zones with the modular setup. Any remotely confident shader code guy must be wanting to hit me in the head so bad right now. :hide:
So, here's what I'm thinking:
- Use a configuration file that will be read by an utility that will generate a flattened LensFlare.hlsl shader file based on that lens flare configuration. I'm even thinking of doing a GUI tool with a neat realtime preview, if possible.
- The flattened Lens Flare code should run wayyyy faster than the current one.
I'm writing a command line utility that should be run every time the config file is changed, and I am still thinking about the syntax of the config file itself. If I can find a HLSL flattener tool somewhere, I should be able to flatten the code and measure the speed improvement.
That is, if I find time for myself...
Since I want it to be modular (as in, customizeable so that everybody can set its own to their liking), I did group code into functions that I thought would be simple enough to work with.
Now that I think of it, it's almost cringey; how would anyone that never touched shader code (or any code for that matter, since I'm setting a low knowledge level to try to include as much users as possible) modify the right part of the shader, without making mistakes, even if well documented? That seems a bit too much to ask.
So I had thought about a configuration file: that would bring the best of two worlds. But getting a configuration file to work, that the D3D9 Client would load and send arguments to the shader would be too complicated, and the amount of branching needed...
Wait.
That's what I knew all along but somehow forgot: GPUs are good at raw calculations, but very bad at branching. And my shader hit all the red zones with the modular setup. Any remotely confident shader code guy must be wanting to hit me in the head so bad right now. :hide:
So, here's what I'm thinking:
- Use a configuration file that will be read by an utility that will generate a flattened LensFlare.hlsl shader file based on that lens flare configuration. I'm even thinking of doing a GUI tool with a neat realtime preview, if possible.
- The flattened Lens Flare code should run wayyyy faster than the current one.
I'm writing a command line utility that should be run every time the config file is changed, and I am still thinking about the syntax of the config file itself. If I can find a HLSL flattener tool somewhere, I should be able to flatten the code and measure the speed improvement.
That is, if I find time for myself...
Thanks!
