Idle skipping

[billyash]

This is question and idea for dev, i don't know it has been test or not by dev so please reply.
Question:
1.about frameskip in pcsx2 playground (im sorry i didn't mean to compare or anything) there option frame skip - in order to achive normal skip some frame are skipped, what kind of method is it ?is it same methode with frame to draw and frame to skip?if is it yes, how much frame to draw and skip?
Idea
2.Option give thick box idle skipping
It means same methode with auto skip but with limit half fps (ntsc =30, pal=25) if below those fps there won't be frame skipping.
What do you tink? In my opinion less skipping will be less bug. And give performance hit thank you

[refraction]

1. To skip frames the gs plugin ignors processing for skipped frames, thats it.

2. There is already an fps threshold option in there.

[billyash]

1. To skip frames the gs plugin ignors processing for skipped frames, thats it.

2. There is already an fps threshold option in there.

did you mean in gsdx plugin - hardware hack - skip draw?( is it mean if we give value 50 then there will auto skip if fps at half (ntsc=30,pal=25) there would be frame skip?

[refraction]

no, the frame skipping in pcsx2 tells the gs plugin (Gsdx) not to process the frames that are being skipped.

[billyash]

no, the frame skipping in pcsx2 tells the gs plugin (Gsdx) not to process the frames that are being skipped.

whole frame? Cos in gs plugin written n surface. I think with playground methode skip as much to achieve normal speed was good thing but with limit fps speed(limit frameskip for ntsc=33, pal 27.5) if below thos fps there won't be frameskip.
Is that idea was tested on pcsx2?

[refraction]

Apologies i thought it was still in there, but apparently the FPS threshold options have been removed, i suspect it might have been because it was problematic or offputting, it was somewhat jolting if it suddenly kicked in. But yes, the GS skips the whole frame, hence "frame skipping"

[nosisab Ken Keleh]

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.

[billyash]

Apologies i thought it was still in there, but apparently the FPS threshold options have been removed, i suspect it might have been because it was problematic or offputting, it was somewhat jolting if it suddenly kicked in. But yes, the GS skips the whole frame, hence "frame skipping"

i think put idle skiping was good idea to give performance hit especially if sudden slowdown occur, and most speedhack that give performance hit have bug.

[billyash]

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

may be that's why some games have 30fps is at full speed fps wich emulator always read as 60fps is full speed so emulator must work twice to achieve ful speed..

[refraction]

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