Shader pipeline differences OGL DX

Started by
11 comments, last by remigius 13 years, 6 months ago
Quote:Original post by remigius
Can you disclose what the main sinks were for this lost CPU time?
IIRC it was mostly setting uniform data, like matrices, model colours, etc... Without effects we put this data into specific registers, so they don't have to be re-uploaded with each shader switch.
Advertisement
Thanks for all the responses! Things are becoming a bit clearer for me.

Effects don't appeal to me since the break any kind of GAL pipeline which branches off into more API-specific code later down the line. But for prototyping they look neat. Also, based on the all the replies I won't reconsider it.

Yes, I wish to use the ID3D10Device::CreateVertexShader and the ID3D10Device::CreatePixelShader. Even though I've been using OpenGL for a long time the DX10 approach makes a lot of sense to me. Coming from OpenGL though I felt a bit uneasy about when linkage occurs (on assignment per shader I presume). My issue is more of how to not break my OpenGL code when designing for both systems (forcing me to make a more loose abstraction which will give me some overhead).

Further I'm guessing that the cost is also based on the HW generation, with DX9/10 cards having cheap linkage?

I was worried the driver would do expensive stuff on the CPU side when linking using glLinkProgram but if it's a relic then all is well. There is still an issue of relinking and again relocating all my attributes and constants (something I suppose DX10 need not worry about because of the IA stage?). But I haven't fully decided yet on how I wish for my pipeline to look.

@ Krohm: Thanks a lot for the link, this would solve a lot of issues for me if implemented on my target platforms (OSX is still a bit slow here). I was actually designing to "meta-link" keeping track of different combinations. Let's just say the solution turned out to be less elegant...
Quote:Original post by Hodgman
IIRC it was mostly setting uniform data, like matrices, model colours, etc... Without effects we put this data into specific registers, so they don't have to be re-uploaded with each shader switch.


Thanks for the response, I just realized keeping data around across shader switches isn't something I've considered doing before [smile]

I have to ask however, isn't this what EffectPool sharing should fix, or is the performance of the EffectPool part of the problem?
Rim van Wersch [ MDXInfo ] [ XNAInfo ] [ YouTube ] - Do yourself a favor and bookmark this excellent free online D3D/shader book!

This topic is closed to new replies.

Advertisement