Idle skipping

[billyash]

The emulator doesn't work twice as much. Most games are interlaced, games work at 30fps, each frame only contains half the picture in an interlaced scenario, so 2 interlaced frames = 1 frame. So although it's reading 60fps, it is actually only doing 30 full frames.

Wiki article on how interlacing works: http://en.wikipedia.org/wiki/Interlaced_video

hmm... ( ' ',)
Very interesting...
What do you think with idle skiping?
I know dev give up on frame skiping,
I think with limit 33fps no more skiping was good ide...( ^^,)d

[refraction]

Theres no suck thing as an idle frame

[billyash]

Theres no suck thing as an idle frame

have dev test it? And what the result?
With suck thing there will smooth speed, coz if below 33 fps (ntrc), 27.5fps(pal) the movement isn't smooth :d

[billyash]

In PC there is nothing or at least not much in between the CPU and the GPU, so the application/game writes specific logic for the CPU to chew and the bulk of graphics (read vector calculation) directly to the GPU. Where this is an exception in newer games, like Skyrim which was ported from consoles where the CPU is "stronger" than the GPU, the general performance is hit hard.

That's not the case of PS2 which has the CPU (EE), the two vector units (VU), an interface to GS and finally GS itself. Much of the work made by the VUs falls on the CPU "shoulders" and the CPU simply don't have enough vector unities to deal with the load that normally goes to the GPU. Nowadays EE and VUs are shoved inside the same chip (what may lead some to think they are one and only CPU with extended vector processing capacity) but this does not change that x86 CPUs just lack enough float point unities to deal with the load coming from the PS2 game's code. multithreading the VU (MTVU) is an attempt to reduce the problem but can't really solve it. The GPU is the piece having a lot of vector unities to deal with this tipe of calculation, any reasonably video card would chew it relatively easy, as already stated, that's how it's done in PC.

PCSX2 already has many optimizations, out of order execution and branch prediction, state of art micro recompilers which do wonders in foreseeing the possible blocks of code coming from the game and everybody is happy... till a game's developer finds out ways to code the game in a way that just kill the prediction, causing lots of misses and massively harming the general performance.

Someday the methods and approaches may be reviewed and rewritten to get "real", actual performance boost, just they aren't things to be done in a day's job. Changes in any those things ask for deep rewrite in many modules to be properly implemented if ever will. Insisting in proposing methods which changes the structure of PS2 (notice it's not a typo, I meant PS2 indeed) is not the way to go. The intention is getting the emulators more accurate and compatible at each revision and version... not going by the road of killing all that was already accomplished in compatibility and accuracy.

Points to ponder.

so is it like CPU=EE core, GPU=VU?
Wich mean
CPU=EE core (carries out the instructions only)
GPU=VU(manipulate and alter memory to accelerate the building of images in a frame buffer intended for output to a display/GS) ( ' ',)?

[billyash]

Is frame skip as much as possible that is 'skip when on turbo only'? But when i activate it. It behaviour like constant skipping?

[nosisab Ken Keleh]

so is it like CPU=EE core, GPU=VU?
Wich mean
CPU=EE core (carries out the instructions only)
GPU=VU(manipulate and alter memory to accelerate the building of images in a frame buffer intended for output to a display/GS) ( ' ',)?

Not that simple but basically yes. Of course float point calculations are not restricted to graphics and then aren't vectors exclusivity of graphics also.

Besides, image and general processing should not be seen as independent, is not enough to get the best image if that breaks the bounds with general events.

Many times we (and I in particular) have tried to point to you the potential dangers the proposed methods bring. Besides, even when they work they call for so many "measures" to try and compensate elsewhere that the greater possible benefit is lost. To make things worse, there is no warranty it will work with many games and more compensation work is needed if one can be found for otherwise working games which should never need it.

EE and VU speedhacks are already a greater concession to general stability, changing PS2 base refresh rate is too much aggressive and sync breaking. One thing would be if PCSX2 was meant to emulate a single game, in this case one could go wild and do the weirdest attempts (This happened more than once at "special plugins" or even special PCSX2 emulators which infested the web sometime ago, mostly coming from somewhere in Asia).

But... the infamous but, PCSX2 is meant to emulate PS2 and then to emulate most games from it. It was never to emulate one definite game.
This mean that to be a "valid", general and made official performance hack the candidate should not break things so badly and this one you propose is old known already and was for a reason it was "removed" from the GUI.

Edit to complement: You are thinking the image processing as only the frame buffer, but to get there a lot of vectors calculation must be done (at least most pos MS-DOS graphical applications use vectors instead plain bitmap). The control of what is to be displayed is always from the game, At PC the general flux, the logic, the events and the image must pass by the CPU also. Then a series of information about position, geometry, lighting and many other fancies are passed to the GPU which will get those information and do the bulk of actual vector calculation to finally send the result to the output to be presented as image. AT PS2 greatest part of that job falls on the VU, GS is still needed of course, the rasterisation must yet be done and the actual presentation of image on the screen is a GS job and this can't be changed.

That's what comes to GS, that's the main reason native resolution is not the most demanding part of emulating PS2 toward the video card... then one can go crazy and abuse post processing "freely" at even reasonably mainstream cards without actually and seriously compromising the core emulation that much.

Finally, is not said that reducing the native PS2 threshold could not help increasing FPS, of course having to emulate less things will make the emulator's "life" easier... the problem is just the cost.

[billyash]

Thank you.
After your explainationg, i try to googling and find site :
http://lukasz.dk/playstation-2-programmi...to-ps2dev/
There a lot explanation there,tool and source code to make games ps2. My question is
Are you using those snurce code or tool?( im sorry i didn't anything im just ask )
now i understand ps2 was far complicated than gamecube .
And one more thing why im making thread to gain speed boost e.g framerate,frameskip? Becos it could really help for newbie. Cost mostly complain about sudden slow fps and they aren't familiar with ee cycle rate ,mtvu or else.( i didn't mean to underestimate or else but i mean to help trying to gain speed , i know im newbie too )

[nosisab Ken Keleh]

Despite knowing something about programming (and did more codding I ever wanted and mainly helped actual programmers pinpointing errors and suggesting corrections and structural precautions, my job function was that of system analysis) I have retired from this at same time I retired from actual job as well so, no, I keep distance from programming tools nowadays the best I can.

It's just than decades of experience dealing with programmers and even other analysts as de facto "end users" taught me a thing or two about foreseeing potential issues and to make diagnosis based on symptoms.

Is good to know you are willing to learn, many people believe they know everything already and act as so, they just close themselves to actual growth, sad but true. And indeed some the information we shared surely helped to advance knowledge a bit more, for yes, I learned one thing or two from our talks also.

[billyash]

Despite knowing something about programming (and did more codding I ever wanted and mainly helped actual programmers pinpointing errors and suggesting corrections and structural precautions, my job function was that of system analysis) I have retired from this at same time I retired from actual job as well so, no, I keep distance from programming tools nowadays the best I can.

It's just than decades of experience dealing with programmers and even other analysts as de facto "end users" taught me a thing or two about foreseeing potential issues and to make diagnosis based on symptoms.

Is good to know you are willing to learn, many people believe they know everything already and act as so, they just close themselves to actual growth, sad but true. And indeed some the information we shared surely helped to advance knowledge a bit more, for yes, I learned one thing or two from our talks also.

ok, enjoy your retirement

[billyash]

I read from other forum about idle skipping like this :
Idle Skipping???

"I think here's the little problem in this algoritm.
For example game Fullspeed limit is Game is 30 fps
you run it without IdleSkip you've got: 30fps 721Mhz(721-real 0-Skipped)
yuo run it with IdleSkip and now the fun starts, game limit no longer just 30 fps it can be any number
And i see some dependance in this bug
Idle skip limits game at 18fps for example but you still got 721Mhz (45-real 676 Skipped)
Idle Skip limits game at 25 fps you still got721Mhz(157-real 564-skipped)
And here the right skipping 30fps 721Mhz(432-real 289-Skipped)
Dependance is simple More-Skip+Less-Real=Worse number of fullspee game limit
Less-Skip+More-Real=Better number of fullspee game limit
I think the algoritm skips to rough and to much, need to be fixed"

And i don't get the point, can anyone explain with easier word? (i don't know is valid or not discus from other forum,
If isn't please delete, cos i rally want to know) thank you