Fastest function execution
Author
I'm using Angelscript to power the fixed function shaders in my system. Obviously, these script functions will be executed at a very critical point of the program, so they need be as fast as possible.
What's the best way to prepare and execute 50 different functions? Should I create one context, store 50 function ID's, and simply go through them each and say
singleContext->Prepare(functionIDs[index]);
singleContext->Execute();
Or, should I create 50 different contexts and call the prepare function in preprocessing? This seems to be a bulky way of doing it.. but, even if it takes more resources, if it's faster it may be worth it.
FYI, all the functions are compiled into the same module with different names.
I'd never use a scripting language in any part of my rendering pipeline. Are you looking for ways to eat up your fps?
Calling Prepare() between each function obviously creates an overhead, but the relative overhead depends on the size of the scripts. If the scripts only has a couple of statements then the relative overhead is quite large, but if the scripts have perhaps 10 or more statements the overhead should be quite small.
Having one context for each of the functions will no doubt be the fastest way, though as you say, it may be a bit cumbersome, and will use a lot more memory. In this case you should take care to adjust the stack size to not be larger than necessary.
In either case you need to take a look at the stack size. Ideally it should have the initial size large enough to run the entire script without having to allocate extra space at runtime. Currently there is no way of dynamically determining the ideal size but I'm planning on introducing this feature.
However I doubt that a scripting library is very suitable for shaders, at least not without JIT compilation. You might want to take a look at something like SoftWire instead.
Having one context for each of the functions will no doubt be the fastest way, though as you say, it may be a bit cumbersome, and will use a lot more memory. In this case you should take care to adjust the stack size to not be larger than necessary.
In either case you need to take a look at the stack size. Ideally it should have the initial size large enough to run the entire script without having to allocate extra space at runtime. Currently there is no way of dynamically determining the ideal size but I'm planning on introducing this feature.
However I doubt that a scripting library is very suitable for shaders, at least not without JIT compilation. You might want to take a look at something like SoftWire instead.
There are stuff that should be scripted and stuff that should be hard-coded. It's up to you how 'flexible' you want your engine to be.
Couldn't you use function pointers and do something like this?
myFunctions[j].Execute();
Couldn't you use function pointers and do something like this?
myFunctions[j].Execute();
Author
I am only researching different solutions for the application. There is a good chance that most of what I do now won't make it in the real application. I wanted to see what kind of pros and cons this would bring into the system. I don't see why it would be so much slower- it's just like writing a text file configuring a shader and then parsing the text file. It compiles it. But, that's what I am to find out. It would be great to use something like this to make my non-hardware shaders flexible. But if I find that it is too slow, then so be it. But I need to do it myself to see.
Edit- seems that people replied while I was writing. :p thanks for the answers. I'll check it out. As for function pointers, well, in a sense that's what I would do with DLL's. My problem is pulling the shaders outside the system. I'm trying to avoid DLL's, but, if I find those are so much faster, I might have to do it that way. Crap- I though XML files with embedded shader script would be so cool :p
Edit- seems that people replied while I was writing. :p thanks for the answers. I'll check it out. As for function pointers, well, in a sense that's what I would do with DLL's. My problem is pulling the shaders outside the system. I'm trying to avoid DLL's, but, if I find those are so much faster, I might have to do it that way. Crap- I though XML files with embedded shader script would be so cool :p
Quote:Original post by okonomiyaki
Crap- I though XML files with embedded shader script would be so cool :p
Yeah, me too. I don't know what API you're using, probably not Direct3D, buf if you are, check out .FX files. Maybe you can make a parser for those....... Hmm.. [grin] [wink]
Quote:Original post by okonomiyaki... it's just like writing a text file configuring a shader and then parsing the text file.
Parsing a text file you do once, usually into a format directly usable in your C++ code. Executing a script every frame is going to be many times slower. Even the fastest scripting language is still significantly slower than the raw c++ code. If you're talking about just defining the shaders in script, so that they are loaded in and used once, thats different, but your post implied to me that you would be calling the scripts each frame.
Author
I am using OpenGL, but I use DirectX as well in other applications. I have looked at the FX files, and it looks good, but I don't have the time to write a whole parser myself :p I'm not quite sure what I'm gonna do yet, I'll have to do some refactoring if I go with DLL's, or write my own parser if I go with text files. Either way, it's gonna take some time I guess.
drEvil- you are correct, they would be called every frame. I thought that compiling and preparing in a preprocess step would take away most of the overhead, but I didn't understand scripts well enough. I still want to test it though. thanks.
drEvil- you are correct, they would be called every frame. I thought that compiling and preparing in a preprocess step would take away most of the overhead, but I didn't understand scripts well enough. I still want to test it though. thanks.
You could have the scripts set up some internal structures that your rendering engine can use to render the fixed function pipeline. This would allow you to use a scripting engine to define the rendering, and still have the speed of direct C++ code when rendering. Example:
The scripts would serve much the same function as DirectX's effect files, and would also be easy to implement with OpenGL.
You could also allow scripts to animate the shaders, by having the application call an animation script with a shader structure once every frame.
// shader scriptvoid Init(shader &sh){ sh.renderTexture = true; sh.texture1 = gfx.GetTexture("Steel"); if( gfx.canDoCubeMapping ) sh.renderCubeMapping = true; else sh.renderEnvironmentMapping = true;}// C++ app codeCShader *sh = new CShader();Call Script Shader Init(*sh);// Renderingif( sh->renderTexture ) enable textureif( sh->renderCubeMapping ) enable cube mappingif( sh->renderEnvironmentMapping ) enable environment mappingThe scripts would serve much the same function as DirectX's effect files, and would also be easy to implement with OpenGL.
You could also allow scripts to animate the shaders, by having the application call an animation script with a shader structure once every frame.
Author
Yeah, I thought about that, but it's still not as easy as just letting the scripts do it themselves :p though I think that may be the easiest way. It also kind of makes scripting useless- I might as well just embed the properties straight into XML. I dunno. I'm actually not going to use the fixed function pipeline a whole lot in my program, so I don't have to give it total flexibility. Obviously I can't just totally forego support for it though. thanks for the suggestion.
But see, how is this different than calling a script to set fixed function states every frame? Wouldn't calling any script every frame produce the same bottleneck?
Quote:Original post by WitchLord
You could also allow scripts to animate the shaders, by having the application call an animation script with a shader structure once every frame.
But see, how is this different than calling a script to set fixed function states every frame? Wouldn't calling any script every frame produce the same bottleneck?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement