DX9 Handle question
Author
All my effects files include a header which contains basic stuff like world matrix, inverse world matrix, etc, etc. Since its a header, all these get included in my handle table for each effect.
Even if the parameters not used in the file, GetParameter() still gives me a handle since its included in my header. Will SetValue() type calls using these handles still upload to the card? And if so, do you guys think its worth trying to manage these and not send them to the card, or if it doesn't matter too much (which would be cleaner code-wise for me).
Side question, would it be cheaper to just calculate my inverse matrices in a shader, as opposed to sending them to the card, provided these were already available? Or does this just depend.
Thanks,
Benny
[Edited by - bennyW on March 16, 2006 9:38:18 PM]
Quote:Original post by bennyW
Even if the parameters not used in the file, GetParameter() still gives me a handle since its included in my header. Will SetValue() type calls using these handles still upload to the card?
If the parameter isn't actually used by any HLSL code, it should be optimized out. IIRC, you can still get a handle to it and call SetValue() with it, but the runtime or drivers should stop early.
In general, you don't wanna have all of those constants if you aren't go to use them (ie just don't make a general purpose header that includes absolutely everything). For one, you have a lot more overhead in your application just for managing them. Second, you may be trying to update them, which even if they don't get set to the card, there is still a performance penalty (simply from function overhead).
Quote:Side question, would it be cheaper to just calculate my inverse matrices in a shader, as opposed to sending them to the card, provided these were already available? Or does this just depend.
No, you do not want to do this. This is because that calculation has to be done for every vertex, which gets to be quite expensive. If you notice that you are performing the exact same calculation (ie it doesn't use any vertex-dependent data), you should move it out of the vertex shader and into a constant register.
Cool, thanks for the reply.
Yeah, that second question wasn't well thought out. My bad on that one.
Anyways, right now my code has several different render functions, which set a technique, the proper params, the necessary textures. As I write more and more shaders, the number of these functions increase which is starting to bloat a little.
An alternative would be to have one render function, with an if/switch to set these individual params based on a shader class/struct that I manage myself.
The third would be each effect has a handle table, and I set them all. If they're not going to the card, this one doesn't seem too too bad, but I don't yet fully understand the scope of a complete and robust graphics engine.
I'm hoping to nail my design here early and avoid future headaches, so any advice or suggestions would greatly be appreciated.
BennyW
Yeah, that second question wasn't well thought out. My bad on that one.
Anyways, right now my code has several different render functions, which set a technique, the proper params, the necessary textures. As I write more and more shaders, the number of these functions increase which is starting to bloat a little.
An alternative would be to have one render function, with an if/switch to set these individual params based on a shader class/struct that I manage myself.
The third would be each effect has a handle table, and I set them all. If they're not going to the card, this one doesn't seem too too bad, but I don't yet fully understand the scope of a complete and robust graphics engine.
I'm hoping to nail my design here early and avoid future headaches, so any advice or suggestions would greatly be appreciated.
BennyW
Have you considered using some kind of function pointer mechanism? The implementation is a bit heavy, but I have found that it is well worth it. Based on the semantic, you can bind a semantic to a specific function pointer. For example, you might have the INVERSEVIEW semantic bound to a function like:
Then, each frame, just enumerate through all of your constants, call the linked function pointers, and call SetValue() with that data. There are a lot of things you can do that I haven't mentioned, but this would be a nice start.
void* Camera::GetInverseView( int* size ){ *size = sizeof(Matrix); return &inverseViewMatrix}Then, each frame, just enumerate through all of your constants, call the linked function pointers, and call SetValue() with that data. There are a lot of things you can do that I haven't mentioned, but this would be a nice start.
That's a neat trick Dustin [smile]
I might be getting a bit muddled up with FX10 (side note: Shader reflection in D3D10 is awesome), but if you use the FX9 reflection information for individual techniques/passes you should be able to find out which parameters are actually being used for a given effect - rather than just those that exist in the FX file in general.
hth
Jack
I might be getting a bit muddled up with FX10 (side note: Shader reflection in D3D10 is awesome), but if you use the FX9 reflection information for individual techniques/passes you should be able to find out which parameters are actually being used for a given effect - rather than just those that exist in the FX file in general.
hth
Jack
Quote:Original post by jollyjeffers
That's a neat trick Dustin [smile]
It gets tons better when you employ function pointer hacks that allow you to basically call a function of any signature, but can be stored by the same function pointer. For example:
Matrix* GetMyMatrix(){ ...}Vector4* GetMyVector(){ ...}can be used in the exact same way. This is really nice, because then your interfaces don't get poluted with annoying functions like void* GetMatrix(int* size), while you have a mirroring overload that you would use normally.
Author
Ah, so LPD3DXEFFECT has a function IsParameterUsed(), where you pass it the handle and a technique (was this what you're talking about jolly?).
I can use this to check the handles I retrieve from the file against each technique within and then iterate through my list of handles using something like the function-pointer trick mentioned above to set the parameters. Then I can avoid having different rendering code as most (if not all) of my techniques could be rendered this way.
BennyW
I can use this to check the handles I retrieve from the file against each technique within and then iterate through my list of handles using something like the function-pointer trick mentioned above to set the parameters. Then I can avoid having different rendering code as most (if not all) of my techniques could be rendered this way.
BennyW
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
