[Papercut] trouble opting-in to PerfHUD

[cyrfer]

Hi,
I've installed the latest PerfHUD version (6.something) and launched the example they provide by dragging it onto the PerfHUD launcher shortcut. It works like a charm and I can debug their app. This should verify that my system is setup right (XP, PerfHUD drivers, Instrumentation enabled, launched app correctly).

Now, when I drop my app onto the PerfHUD app launcher, I get a message (presumably from NVIDIA) that says:
This application is not confuged to use PerfHUD.
Consult the User's Guide for more information."

What am I doing wrong? My app is a little different in that I make my own system Window and have OGRE render to it, instead of having OGRE create the system Window. So could my window settings be different than what is assigned in my display_settings.cfg file (the .cfg provided when allocating Ogre::Root) ?

Also, is it possible to launch a PerfHUD-enabled app from Visual Studio (2008)? I'd like to debug the OGRE code to learn what I did wrong in my app, but I don't know how to launch PerfHUD apps from VC++.

Thanks!

[cyrfer]

Digging through OGRE a little more, I suspect it is not good enough to have a config file with the "Allow NVPerfHUD=Yes" setting. As far as I can tell, my program still needs to supply a NameValue parameter (useNVPerfHUD=true) when creating a RenderWindow without using Root::initialise to create the RenderWindow. I vote to change this behavior so that if a developer uses the config file, she/he can opt-in to PerfHUD whether or not OGRE creates the RenderWindow at initialization. Can I get a shout-out?

[cyrfer]

Since this never received any attention, I'd like to ask the moderator to move this to a more appropriate forum. Is this tiny feature request worthy of a papercut? Thanks.

[syedhs]

I think config file is not really the 'official' way of getting values to be fed into Ogre classes (which in this case, RenderWindow). There are lots of ways to customize the parameter NameValuePairList, and the default Ogre.cfg is meant for Ogre samples. Just my thought anyway, others may have different opinion

[cyrfer]

I see your point. The config file is not appropriate for everyone or for all uses. However for a feature like PerfHUD support, I would think you would want your entire application to work with it, not specific RenderWindows. If the developer loads a Config file with this option enabled, I think the intent is to profile the entire application.

On a side note, have you been able to make PerfHUD work with OGRE? What version of it and what OS are you using? Thanks!

[xavier]

Since this never received any attention, I'd like to ask the moderator to move this to a more appropriate forum. Is this tiny feature request worthy of a papercut? Thanks.

This would in fact be a prime example of a papercut -- functionality that is supposed to work as expected (indeed, it used to) but now may not (or might not in some cases). I'll move it over.

[syedhs]

On a side note, have you been able to make PerfHUD work with OGRE? What version of it and what OS are you using? Thanks!

Yes although it was quite some time ago. If I am not mistaken, I need to modify the OIS initialization so that the keyboard and mouse are not exclusive. And another, probably the only way to work is to drag-and-drop application icon onto the NVPerfHud icon. And make sure you are running full screen (not windowed).

[dark_sylinc]

On a side note, have you been able to make PerfHUD work with OGRE? What version of it and what OS are you using? Thanks!

I used NVPerfHUD quite often. I'm running Win 7 x64, Drivers 196.21 (driver versions make A LOT of difference) GeForce 8600 GTS 512 MB, 4GB RAM.

First make sure driver instrumentation is turned on (Start Menu->NVIDIA Corporation->NVIDIA PerfSDK->NVIDIA Driver Instrumentation Tray) If it's grayed, it's off.

Second, if you're using m_root->restoreConfig() (or m_root->showConfigDialog()) then m_root->initialise( true ); Make sure the option "Allow NVPerfHUD" says Yes.

If you're using m_root->initialise( false ), and creating the render window yourself, then you need to do this:

Code: Select all

Ogre::NameValuePairList params;
	params["useNVPerfHUD"] = "Yes";

	// Create the render window
	mRenderWindow = Ogre::Root::getSingleton ().createRenderWindow (
		Ogre::String ("MyOgreRenderWindow"),
		width, height, false, &params);

This happens because when you choose initialise( false ), ALL options are ignored, except which RenderSystem you've chosen. This is so because you're saying that way you want to manually control the windows, which is in itself a very advanced task. You have to deal with a lot of configurations and may break in a few systems if you don't do it well (for example, does your hand-made window support multi monitor setups? those ones are tricky to get right)

Furthermore parsing Ogre.cfg is actually pretty easy:

Code: Select all

bool allowNVPerfHud = false;
try
{
	ConfigFile cf;
	cf.load( "ogre.cfg" );
	allowNVPerfHud = StringConverter::parseBool( cf.getSetting( "Allow NVPerfHUD", "Direct3D9 Rendering Subsystem" /*You may want to leave this blank actually*/, "No" ) );
}
catch( Ogre::Exception &e )
{
	//Probably file not found
}

By the way NVPerfHUD works both in Fullscreen and window mode. I prefer windowed mode because in fullscreen I get more BSODs or screen hangs.
I've been using it from Eihort (1.4) until trunk (1.8 Byatis unstable)

I vote to change this behavior so that if a developer uses the config file, she/he can opt-in to PerfHUD whether or not OGRE creates the RenderWindow at initialization. Can I get a shout-out?

If the idea is to prevent hackers from debugging your application, then you lost the point the moment you've used an open source graphics engine. A slightly modified RenderSystem plugin will allow to always opt in for PerfHud.
If there are other reasons, then I don't see why not.

Cheers
Dark Sylinc

[cyrfer]

Thanks for all the tips! I am still not sure, but I think new drivers seem to remove functionality. I see you are using old drivers, so I may have to give that a try. My main development machine is XP, but I'm also working on a 7 machine. The last part of your response goes to the heart of this feature request...

I vote to change this behavior so that if a developer uses the config file, she/he can opt-in to PerfHUD whether or not OGRE creates the RenderWindow at initialization. Can I get a shout-out?

If the idea is to prevent hackers from debugging your application, then you lost the point the moment you've used an open source graphics engine. A slightly modified RenderSystem plugin will allow to always opt in for PerfHud.
If there are other reasons, then I don't see why not.

Cheers
Dark Sylinc

I never thought about hacking. My issue is that I load a config file at initialization with RenderSystem settings, like opting-in to PerfHUD, so why does manually creating a window ignore my PerfHUD choice? I do not think profile settings should be part of the window interface, but I guess some people might want the ability to override profile settings. Even with multi-monitor or multiple windows, I would like to be able to use PerfHUD, or not- depending on my config file choice. I guess it just seems redundant to load a config file twice, once for RenderSystem initialization, and again for when I create a window. I realize I could store the config, then use those values when I create a window, but that's beside the point. I want to be able to make a RenderSystem setting once, no matter if I create the windows manually or let OGRE do it at initialization.

[dark_sylinc]

Yes, drivers starting from version 250+ are messed up. It was a major overhaul and some stuff was unattended. Given NVIDIA's focus on NSIGHT & Co; I fear PerfSDK may become outdated and never fixed (BTW, I did my own ranting about nvidia here. I'm sticking to drivers that just works. If it's for performance, 196.75 driver was a call for attention to me. They claimed ridiculous "up to 50% increase due to better CPU utilization" in a few games, when it was more than obvious they didn't run a single decent game to test the driver changes (otherwise the driver literally burning the GPU would have become obvious...)
So, only use a newer driver if it's for a particular new feature, or an actually proven big performance increase.

As for the NVPerfHUD opt in/out, yeah, I'm seeing your point now. But IIRC the main problem arises in that a lot of configs are just handled "on the fly" and thus they get lost once you've ran out of the initialize() function. I'm not sure if changing that would be exactly "papercut" (given it's difficulty*) but is sure something desirable.

*At least with all the solutions I can come with. Sometimes, someone comes with a 3-line change and blows everyone's mind

[syedhs]

By the way NVPerfHUD works both in Fullscreen and window mode. I prefer windowed mode because in fullscreen I get more BSODs or screen hangs.

Well, I had tried NVPerfHud in windowed mode, the GPU RAM Usage was not reported (ie no graph was plotted). As soon as I changed to fullscreen mode, it worked without any other changes. If it works now regardless of the mode, then it is good.