If you dont pass it the actual GetClientRect window size the problem I was seeing with Dedicated GPUs was that the compositing and final output to the window was actually still happening on the iGPU instead of on the dGPU.
The DX11 adapter selection should be enough to select the dGPU and you dont need to add any of the NV or AMD apis to force the selection of the GPU.
Thanks bud, I have uncovered a raft of small issues that didnt seem to bother the ATI Driver but were showing up. The worst being a data alignment issue on the Matrix instance buffer. This wasn't an issue in one SetVertexBuffer call because I was setting the alignment correctly, BUT if I used the other call, the creation of the binding was incorrectly offset. This was causing an issue.
I've attached the code for Sharpdx for everyone's reference in future.
On another note, I was not setting the backbuffer resolution to the correct resolution and leaving it to be set by the window handle, this also caused an exception in relation to setting the stencil buffer in SetRenderTargets. This also was fixed. Thanks for your help!
Added note: still have to wait on my colleague to test the changes But I feel these issues were at the core of it. Also, Sharpdx AppendAligned doesn't seem to work and was causing an issue!
YEah NVIdia can be a bit finicky when you dont set the backbuffers to the exact client rect size, I saw extreme slowdowns in those cases (a 970M ran at the same speeds of a 4600HD).
Do you create a buffer for each quad or are you using a buffer to hold multiple quads? (the text you wrote to me indicates that you create a buffer for each quad so just want to clear that up)
You should discard the content of the old buffer when you are filling it again with new data, you could create a quad data that contains all of the transformed vertex data and then just copy that into the vertex buffer for rendering. You would need a new VB if you change font or scaling size offcourse, and even that is fixable with instanced rendering.
What Oberon_Command mentions seems to be the issue once I used the GetClientRect and used does values all started working again and it actually selects the NV chip as the one to render on, thanks for that
It also makes it so you can just use DXGI to select your render device, no need to deal with the extern variables like further up in the thread .
Maybe the driver is injecting the FF emulation shaders that it puts in for any D3D9 call, that would bind a VS at least that could just be a pass through shader seeing no MVP is set either. Which then would mean that as long as you keep the vertex coordinates in screen view you will see the triangle on screen. This would off course only work with a driver that still has support for D3D9.
This is all speculation of course.
Have you tried doing a VS graphics/Renderdoc/Intel Graphics analyser/NSight capture to see what the GPU is actually doing?
You can use Renderdoc, INtel GPA, AMD codeXL or NVidia Nsight for GPU profiling. They all give you GPU timings, some will give you more info than others depending on the hardware you run it on. Renderdoc doesnt do DX9 though although I never checked this.
That should work (except there is no such thing as raw_name in std::type_info, it's just name).
A few notes:
As it stands, your approach will generally "work fine" but the program is ill-formed because you don't include <typeinfo> prior to evaluating a typeid expression (your compiler should warn about that?).
You are caching the hash in a static variable. Keep it that way. The temptation exists to instead make the hash function constexpr. Don't do that because it will not work on the stricter compilers as the name is not a constant expression (it sure is, how could it possibly not be... but the standard and the compiler think differently) and will be vastly inferior on the more forgiving compilers (which will compile fine, but evaluate at runtime).
std::type_info has a member function hash_code which just looks like what you want, only better, faster, and standard. Yeah right. Don't fall for that. The hash provided by the standard not only isn't portable (that would be quite hard to do, admittedly), but it does not even guarantee that the value stays the same between different runs of the same executable. Which, frankly, is total shit.
The standard also provides std::type_index, which suggests by its name and its description that it could be very useful (index? as in unique number? great!), but it is really just a wrapper around std::type_info which adds operators <= and >= in terms of std::type_info.before(). Other than for using it as key in unordered standard containers, it's pretty useless.
Instead of using std::type_info.name(), you could use the well-known hack with a helper class that contains a static function which evaluates some flavour of __func__ or __PRETTY_FUNCTION__ or whatever you want to use, optionally adding an offset into the string constant to strip off the ugly mangling. These string constants are not constexpr either (although I think they should be, unless the name of a type can change during a program's execution which would be a big WTF, they are pretty darn constant expressions), but it is less bloat than using std::type_info (especially with GCC which has a very poor implementation), and you save yourself from including another header. I seem to remember someone even posted a complete, usable implementation of the __func__ hack on this site not long ago.
From the most pedantic point of view, using the __func__ hack even makes your program a little more robust. The typeid operator does not guarantee that the same type_info object is returned for different invocations in the same program with the same type. This sounds like something you could take for granted, and this is probably what happens anyway, but in the strictest sense, that's not the case. The standard merely says that some type_info (or derived) object with static storage duration is returned (and leaving unspecified whether destructors are called), and that the objects from different typeid expressions with the same type compare equal. That doesn't mean that they are equal, or that that name() returns the same value (or even the same pointer).
I wouldnt use type info for this, you can do this through the preprocessor with something like:
//create a hash based of a type name
inline uint64_t HashTypeName(const char* str)
//djb2 algorithm from here:
uint64_t hash = 5381;
while((c = *str++) != 0)
hash = ((hash << 5) + hash) + c; /* hash * 33 + c */
inline TypeHash HashType()\
//a way of generating a hash that is cross platform\
static TypeHash hash = HashTypeName(#type);\
This needs less template magic than your solution and is generally easier to use because typeid names contain namespaces and such which can make it hard to figure out what a hash belongs too when you are debugging the code. In my case you can just run the HashTypeName("MyType") function in the watch window to find the hash of your type when on a breakpoint.
Alot of game engines have stuff like Runtime type info turned off in compile settings which will make typeid not work for dynamic types.
If you use a constexpr hash function all of the preprocessor stuff and dynamic lookup of typeid at runtime will be change to static compile time implementations.