30 replies to this topic

[J3SteR]

Ok let me start by saying that i Love vp and i think its a fantastic programs. You guys put a lot of hard work, time, and effort into this i understand. Im in no way trying to bash your guys efforts. Im just not understanding the performance of the app though, I still get stuttering on a few table during multiball, which i think its nuts. Theirs nothing to demanding going on here most of the time. I feel vp is not making good use at all of today's hardware. I have upgraded a few times already on my cab and get the same results. I was debating on getting a gtx 460 for my play field and putting my 450 gts to my second and third monitor but whats the point i thought if its not taking advantage of my hardware its going to run the same. I have a Phenom II X2 unlocked to a quad core @ 3.6 ghz. A gts 450 1gb and a 8400 gs 512, also 4gb of ddr3 1600 mhz.So i decided to see for my self if it was being held back by any of my hardware. So here is a picture that was taken during MultiBall on The high res version of Monster Bash. As you see there is nothing being maxed at full load, yet i see ball stutter going on. My video cards are barely being used and sometimes even dropping to 2d clocks cause of lack of use. And please do not tell me i need to set processor affinity either, i have done that and get the same results, besides there is no point in doing so if none of the cores hit full load.


Something is not right at all. Why am i seeing stutter or drop in performance at times on some tables if my hardware is never being put to full load or stressed to the max? there is no bottle necking. its so confusing.

Edited by J3SteR, 26 February 2011 - 11:43 PM.

[Rawd]

Good question. I also think there is something strange going on..

My Q6600 2.4ghz with my old 8800GT runs just the same as my i7920 2.8ghz/ 285gtx.

It is only a couple of tables during multiball where my cabinet stutters as well.

Edited by Rawd, 26 February 2011 - 11:46 PM.

[toxie]

unfortunately this is nothing too surprising for me..

the architecture of VP is far from optimal (nowadays!) and this shows especially when looking at the performance.. you have to consider that VP evolved over many many years, and thus the whole way how it works is basically very very bad for efficiency on nowadays complex table designs..
it was made for much simpler tables, far less 'hacks' (=the stuff that table authors nowadays (ab)use) and much older hardware.. thus performance falls apart on the tables we love to play today.. in your example you seem to be blocked by the CPU, which sounds strange, i know, but the main problem is that VP can only use one thread for rendering, thus it will never exceed 25% on your taskmanager (which also won't be reached as CPU and GPU will block each other a lot (synching/copying buffers))!
oh, and to make things even worse, it also uses a very old API (DX7) for rendering, i.e. something that will only be 'emulated' by todays GPU drivers..

but be sure that we are aware of that (though its nothing that can be simply fixed in a day or two)..

Edited by toxie, 26 February 2011 - 11:52 PM.

[J3SteR]

Good question. I also think there is something strange going on..

My Q6600 2.4ghz with my old 8800GT ran just the same as my i7920 2.8ghz/ 285gtx.

It is only a couple of tables during multiball where my cabinet stutters as well.

Thats exactly my point rawd, it does not matter how much or how powerful of hardware you throw at it cause its not making good use of them. Its like the program is limiting itself not the hardware.

unfortunately this is nothing too surprising for me..

the architecture of VP is far from optimal (nowadays!) and this shows especially when looking at the performance.. you have to consider that VP evolved over many many years, and thus the whole way how it works is basically very very bad for efficiency on nowadays complex table designs..
it was made for much simpler tables, far less 'hacks' (=the stuff that table authors nowadays (ab)use) and much older hardware.. thus performance falls apart on the tables we love to play today.. in your example you seem to be blocked by the CPU, which sounds strange, i know, but the main problem is that VP can only use one thread for rendering, thus it will never exceed 25% on your taskmanager (which also won't be reached as CPU and GPU will block each other a lot (synching/copying buffers))!

but be sure that we are aware of that (though its nothing that can be simply fixed in a day or two)..

No dont look at my percentage of total use, just look at the one core it never hits full load, Ive also overclocked my processor to 3.9 had the graph drop a bit lower on that 4th core and still had the exact same stuttering going on, not buying the cpu bottle neck.

Edited by J3SteR, 26 February 2011 - 11:48 PM.

[toxie]

what matters is the overall load, not what a single core does.. this can and will be switched by the OS anyways..

apart from that see my answer what really should cause this (GPU vs CPU blocking (due to old 2D gfx code and DX7), driver emu, etcetc)

hopefully the new project by cupid can fix this in the future.. until then, i wouldn't put too much hope in a simple fix of the existing program..

Edited by toxie, 27 February 2011 - 12:07 AM.

[J3SteR]

ok toxie thanks for explaining, i figured it had something to do with still being in dx7.

[toxie]

no problem.. i was basically shocked the first time i understood how VP does render its table elements.. same for cupid..

if i would have more time on my hands i would love to redo some things, but fortunately cupid already started something new!

[cupid]

no problem.. i was basically shocked the first time i understood how VP does render its table elements.. same for cupid..

if i would have more time on my hands i would love to redo some things, but fortunately cupid already started something new!

Jester, is it possible that you measure a non vpinmame table with the same method. That would be interesting.

[J3SteR]

no problem.. i was basically shocked the first time i understood how VP does render its table elements.. same for cupid..

if i would have more time on my hands i would love to redo some things, but fortunately cupid already started something new!

Jester, is it possible that you measure a non vpinmame table with the same method. That would be interesting.

I only have vpinmame tables installed. Maybe i will try to get one on and try it out.

[sleepy]

Yeah, what cupid said to do. Try measuring a straight New Table in VP.

What we used to do back when it was the opposite problem; that CPUs and video cards were being stretched to their limits when running VPinMame tables, was to set a YieldTime value in the table script, i.e.:

Const YieldTime = 1

This parameter forces Visual Pinball to time share the Visual Pinball processing cycle with VPinMame, but it also puts a hit on faster systems by limiting their duty cycles.
I want to make sure the YieldTime parameter is not being used in current VP9 tables, and if it is in use in the table script, that users know to adjust it or comment it out by adding a hyphen ' in front of the YieldTime line if and when it is in the script.

Or does that make a difference?

You can test a VP only table as a designed download with bells and whistles or whatever it comes with, but you can also just open VP and click File > New.
This opens a playable start table.

Edited by sleepy, 27 February 2011 - 01:29 AM.

[J3SteR]

Ok guess i do have non vpinmame tables wasn't thinking... Just used rawd's Triple Strike table. Oddly enough my cpu was taxed more with this table and i never get stuttering of any sort on this table. My main video card switched to 2d clock speeds.

[J3SteR]

Ok so i went to file and then new and ran the plain table. To my surprise my cpu usage jumped way up and my gpu load jumped to the 20 to 30 percent range in 2d clock speeds though.



One other thing i need to bring up is odd too. If I dont have the Hyperpin hglass.exe running when i launch a table my performance drops. thats why when i run my tables in hyperpin they run betterthan they do if i just run them outside of hyperpin. It makes no sense, what is hglass doing to make vp run smooth. It did this for me on other setups too. With XP or windows 7 which im currently running now.

[Rawd]

... Just used rawd's Triple Strike table. Oddly enough my cpu was taxed more with this table......

Probably my disgusting scripting....

[druadic]

I've noticed this myself. When I first started with VP I had an 800Mhz AMD Thunderbird processor. I had no issues whatsoever with VP all the way to version 6. I only had 1 gig of ram as well.

Now, I have a laptop that is an Intel mobile Celeron at 1.4 Ghz and VP SHOULD be playing with no hiccups. It's the software for sure but what could it be?

I hope the guys who work on the VP proggie take a very detailed look into this. I've gotten tons of stutter from VP after version 6.

Who knows what's going on. I'm glad someone posted about this topic because I was going to myself after a while longer. This stuttering is annoying to say the least.

Thanks for the topic starter. Hope this can be fixed soon.

TRYING to look at all the good that has come out of VP. It's still a good thing, just a few errors here and there.

Maybe they'll add a "decal" emreel that can actually be used for the glass and allow the ball to roll under it without having to use those walls for decals to work right on the glass. This would be a MASSIVE time saver.

Will
aka druadic

Edited by druadic, 27 February 2011 - 02:14 AM.

[sleepy]

This is nothing but speculation.

Since VP/VPinMame runs on a single core, is it possible that the diagnostic program is misreporting CPU usage by assuming multi-core operation?
How do the diagnostic programs report CPU usage on a multi-core CPU? By the actual core(s) in use or by the total number of available cores in use or not? I note that the screens do not seem to indicate the program in use or by program in use.

Because DX7 is a CPU function of D3D and is being emulated by the single CPU core in use, would the load pull down the CPU headroom by as much as half of what it should be?

EDIT: Does the video card actually do the Hardware Acceleration of the DDraw emulation or is it passed back to the CPU in DX10.1 or 11?

If the Resource Meter on the Task Manager is available, what does the percentage bar indicate when running VPinMame? Is it reporting differently from the NVidia diag?

Would setting YieldTime in the script help in the event the DDraw emulation is pulling down the CPU? Does Hyperpin use a YieldTime setting?

Edited by sleepy, 27 February 2011 - 05:37 AM.

[sleepy]

What OS and version of DirectX are you using?

Is Hyperpin enabled for multi-core use? That would take the VPinMame DMD workload off of the single core.

[J3SteR]

What OS and version of DirectX are you using?

Is Hyperpin enabled for multi-core use? That would take the VPinMame DMD workload off of the single core.

All these test are run outside of hyperpin.. only things running are vp and hglass. Running windows 7 64bit. But makes no difference I've had the same outcome when I used XP 32. If I don't have hglass.exe running all my tables stutter. All of them. I've downloaded the latest directx from Microsoft and I have disabled services not needed.

Edited by J3SteR, 27 February 2011 - 06:30 AM.

[BigBoss]

And please do not tell me i need to set processor affinity either, i have done that and get the same results, besides there is no point in doing so if none of the cores hit full load.

Ok this is plain wrong. Processor affinity can still benefit you whether you have full load or not. There is some performance hit in removing the cache from one cpu for one process and loading another process into it. You can experience performance degradation whether you are at full load or not. Further, on tables where you have UVP running, it is absolutely critical to affinity the two tasks to different cpu cores. I suggest picking cores like 2 and 3 leaving most system tasks at 0 and 1.

One other thing i need to bring up is odd too. If I dont have the Hyperpin hglass.exe running when i launch a table my performance drops. thats why when i run my tables in hyperpin they run betterthan they do if i just run them outside of hyperpin. It makes no sense, what is hglass doing to make vp run smooth. It did this for me on other setups too. With XP or windows 7 which im currently running now.

I also experience this. I also experience vpinmame sound slowdown (as if it is a record player that's spinning too slowly). It's no big deal though since I do have hyperpin running so these issues go away.

Now that aside, do you have HD Render checked? Does everything run fine with hyperpin running? What is your goal here by your question?

[settingsons]

Just to throw more 'strange happenings' into the pot. While running rosve's EM backglass table 'Strange World' I had all O/S processes on a single core, VP on it's own core, and rosve backglass exe on it's own core and I get stutter. If I set the VP exe and rosve's backglass exe to the SAME CORE and I get NO stuttering. Now we know these two programs talk to each other so it is almost as if there is a communications bottleneck OR maintenance overhead when they run on their own cores.

I just tested out some of my VPinmame tables with UVP by assigning UVPserver and VP to the SAME core, and guess what - I get the same FPS as them having separate cores.

Edited by settingsons, 27 February 2011 - 10:31 AM.

[rosve]

Just to throw more 'strange happenings' into the pot. While running rosve's EM backglass table 'Strange World' I had all O/S processes on a single core, VP on it's own core, and rosve backglass exe on it's own core and I get stutter. If I set the VP exe and rosve's backglass exe to the SAME CORE and I get NO stuttering. Now we know these two programs talk to each other so it is almost as if there is a communications bottleneck OR maintenance overhead when they run on their own cores.

I just tested out some of my VPinmame tables with UVP by assigning UVPserver and VP to the SAME core, and guess what - I get the same FPS as them having separate cores.

I want to clearify one thing. VP an my backglass program doesn't actually talk to each other (ocx)
The communication is done by setting and reading screen pixel values. The backglass and VP has absolutely no connections in the software.

/rosve