Windows Media Player boosts the render performance ?

[Jiang]

If you have low FPS, try start Windows Media Player background, and it is possible the FPS will be improved quite a lot.

I did my test just now:

Hardware : Intel Quad 9450, Nvidia 9600GT, 4G RAM.

test1:
No WMP started. FPS:64

test2:
WMP started. FPS: 255

Of course I rebooted the PC after test1, and the exe are the same.

Can anyone explain this ? Seems some resource/optimization are managed by WMP, how can we do it by ourselves?

[MasterGod]

W00t! funny..

[pelonzudo]

I had seen that before with World of Warcraft. It's about memory management in windows... I look for the full info later, but you could search in google about it and will found some answers.

See you.

[vitek]

What OS are you using?

[Jiang]

What OS are you using?

WindowsXp Prof. SP3 .

Newest version of WMP(Sorry I cant recall the exact version number, my home PC is not accessible now)

I had seen that before with World of Warcraft. It's about memory management in windows... I look for the full info later, but you could search in google about it and will found some answers.

See you.

Yes, I got the related thread in WoW forum. I am not sure this is true or not, but according to that thread, Adam Rock reported that:

From the USA forums (I don't play WoW but I'm VERY interested in this sort of thing):

" I talked about this to a friend of mine who's a Microsoft engineer. His response:

(...)
this is because media player is the only app known today that uses the MMCSS stuff
it elevates the priority of threads in a process registered with MMSCS to the realtime level which cannot be done by an app itself
only the MMCSS (a system component) can do that magic
it's a bug because obviously that leaked to WoW
it will starve the crap out of anything running in the background

[msdn2.microsoft.com]

***

Translation: Your computer usually reserves a certain % of the CPU for background applications. Having WMP opened changes this behavior and allocates all available CPU to WoW. Little to no CPU time will be given to background applications and services, therefore increasing WoW performance."

Check it @ http://kotaku.com/336552/windows-media- ... oad-faster

There are other explanations, but I think this one is reasonable, since my CPU usage changed from 1% to 14% and the numerical part of my application is also faster.

So it seems that this issue is not a render/graphics issue. If we give the application higher priority, say Real time, maybe we can get the same things.






[/quote]

[Wollnashorn]

I think it is because of the quad core processor.

64 * 4 = 256

[MasterGod]

Finally a good bug

[d3jake]

Well the orgin of the word bug in relation to computers dates back to a moth found in one of the relays of an old computer, but since this is beneficial, what could we call it?

[twilight17]

1337 H4X!

[dlangdev]

Well the orgin of the word bug in relation to computers dates back to a moth found in one of the relays of an old computer, but since this is beneficial, what could we call it?

it's not a bug.

it's a feature.

[twilight17]

Well the orgin of the word bug in relation to computers dates back to a moth found in one of the relays of an old computer, but since this is beneficial, what could we call it?

it's not a bug.

it's a feature.

He was talking about what MasterGod wrote...

[rogerborg]

What OS are you using?

WindowsXp Prof. SP3 .

Uh huh.

Windows Server 2003 and Windows XP/2000: MMCSS is not available.

The effect may be real, but I suggest we search for a different cause.

There are other explanations, but I think this one is reasonable, since my CPU usage changed from 1% to 14% and the numerical part of my application is also faster.

That's either obscenely GPU bound (upgrade your Rendition Vérité), or there is another user process eating your clock cycles.Normally you'd expect an Irrlicht app with a busy main loop to use close to 100% of one core. I'd suggest that your core issue is that 1% usage. Where's the bottleneck?

So it seems that this issue is not a render/graphics issue. If we give the application higher priority, say Real time, maybe we can get the same things.

REALTIME_PRIORITY_CLASS
0x00000100

Process that has the highest possible priority. The threads of the process preempt the threads of all other processes, including operating system processes performing important tasks. For example, a real-time process that executes for more than a very brief interval can cause disk caches not to flush or cause the mouse to be unresponsive.

I... wouldn't. You have to keep lowering it if you want to get inputs, for one thing. You could increase to HIGH_PRIORITY_CLASS, but that's should only have an effect if there are other user processes eating clock cycles.

It's a puzzler, but we should approach it sceptically, and not take assertions as to the cause from DudeITotallyKnowADudeAtMicrosoft34531 at face value when the evidence seems to contradict them.

[Jiang]

There are other explanations, but I think this one is reasonable, since my CPU usage changed from 1% to 14% and the numerical part of my application is also faster.

That's either obscenely GPU bound (upgrade your Rendition Vérité), or there is another user process eating your clock cycles.Normally you'd expect an Irrlicht app with a busy main loop to use close to 100% of one core. I'd suggest that your core issue is that 1% usage. Where's the bottleneck?

Well, I implemented my render loop in a separated thread to decouple the render and state management. There is no sleep/delay in my render task. I test the same program with different PCs, none of them reports 100% CPU usage.

Actually I am confused with this, but it is not so easy to change my program to a single-threaded one, I am not sure this is caused by threading or not. But it is true that without the threading the FPS will drop since I do heavy numerical computation in other threads, also multi-core CPU is another issue to be considered.

I will try to locate the possible bottleneck, any suggestions?

So it seems that this issue is not a render/graphics issue. If we give the application higher priority, say Real time, maybe we can get the same things.

REALTIME_PRIORITY_CLASS
0x00000100

Process that has the highest possible priority. The threads of the process preempt the threads of all other processes, including operating system processes performing important tasks. For example, a real-time process that executes for more than a very brief interval can cause disk caches not to flush or cause the mouse to be unresponsive.

I... wouldn't. You have to keep lowering it if you want to get inputs, for one thing. You could increase to HIGH_PRIORITY_CLASS, but that's should only have an effect if there are other user processes eating clock cycles.

It's a puzzler, but we should approach it sceptically, and not take assertions as to the cause from DudeITotallyKnowADudeAtMicrosoft34531 at face value when the evidence seems to contradict them.

True, it is not a good suggestion. Actually it was not my intention to do so in a real-world program. Well, I just want to say if the render priority control of process/thread is available, that would be one way to improve the render performance. Sorry for the possible confusion.

Lets go back to the WMP issue, the performance boost can be archived if and only if :

1. Your have free CPU & graphics resource by default.
2. Your WMP has the so-called MMCSS enabled.
3. You program is lucky enough can use the MMCSS leak.

1 is necessary because in my other 2 PCs with old video card, no FPS boost observed since the higher priority render can not write more data to a slow graphics device.

Jiang