Frame limiter + vsync issue
#21
There is no sense in this thread anymore, is the known syndrome of overstuffed machine and lack of something behind (or in front, don't know) it.

First, one GTX 680 is already a monster of card, that's conceded, two are yet better but helps nothing in this case.

Second, emulation is not only some few CPU cycles more... it involves "translating" the original code and trying to be true to the original hardware. This not only actually calls for a lot of more CPU cycles but may appear problems in the "translation" also. That's something called compatibility + emulator's accuracy and is not directly related to CPU power.

Third, options in PCSX2 config are there so you can have ways to better your experience gaming, if any config option is harming that experience, disable it, simple as this.

Don't ask why, if rolling back to 4x resolves a problem, it works, it's better and it is sufficient (the upscale is a plus, it is not even part of the "emulation"). If Vsync is causing problems, disable it. Well, some things are just too hard to understand or would it be too hard to explain?
Imagination is where we are truly real
Reply

Sponsored links

#22
Lets also try it this way seeing you to dense to believe what you are told, and your own eyes tell you.

1. The Desktop Compositions/Aero in Vista/WIn7/Win8 isnt even true Vsync, As it does not sync framerate your your refresh rate and allows your framerate to go well beyond what your refresh rate is, It just buffers the screen in a way so windowed stuff dont tear And for most part actual does that. USING MUCH LESS RAW POWER.

2. True Vsync use MUCH MORE RAW POWER then what the above does. Which you have proven your PC can't handle true VSYNC with 6x by actually turning off the VSYNC in pcsx2.

(03-24-2013, 05:42 AM)Link68759 Wrote: Am I not allowed to ask a question to confirm what is causing the issue so I can learn more about it and maybe submit a bug report?

Moreover if you had read more carefully I said several times... the problem goes away when I disable vsync, even while at 6x, so you really need to just get off that train of thought sir. I don't think it should run fine. It does run fine, provided I change the vsync setting or GS plugin. This thread is about a possible bug in the SSE4 GS plugin, and the fact that it shouldn't ever happen in the first place- there's a difference between bad settings overloading the processor, and a bug which is causing the limiter to misbehave.

3. You would told to stop using pcsx2 vsync (as you would only need this if you have Desktop composition turned of or pcsx2 actually use TRUE FULLSCREEN which it does not or stop using 6x scaling, for the above reason. IF your turn of Desktop composition you will find it tearing, and if you put vsync on you most likely find out your pc still cant handle true vsync with 6x scale

4. We are not the ones to dense to want to listen to what there being told, or what there OWN test as proven.

I might wrong on something, but i am not so dense as to not listen ike you seem to be. You where told to stop using vsync in pcsx2 or stop using 6x scale for reason. if your refuse to listen then the problem becomes the user. there is no bug in sse4 or vsync or in the software this is just how they work. You came here for help but since the get go you refused to listen to what you were told. which is why probably why no one else is trying to help cause there no point in helping when said person dont want to listen.
Reply
#23
First of all, you are saying "listen to us and turn off vsync" like it was your idea.

I said turning off vsync solves the problem. IN MY FIRST POST.

Also, the problem does not occur with vsync on using AVX.

You keep telling me my hardware can't handle it but I just don't understand how disabling the frame limiter and having my framerate boost past 200FPS is somehow indicative of my computer being unable to handle it. Every time I say this you ignore it. I will record you a video, unless you just refuse to comprehend what I am saying.
Reply
#24
(03-24-2013, 07:33 PM)Link68759 Wrote: First of all, you are saying "listen to us and turn off vsync" like it was your idea.

I said turning off vsync solves the problem. IN MY FIRST POST.

Also, the problem does not occur with vsync on using AVX.

You keep telling me my hardware can't handle it but I just don't understand how disabling the frame limiter and having my framerate boost past 200FPS is somehow indicative of my computer being unable to handle it. Every time I say this you ignore it. I will record you a video, unless you just refuse to comprehend what I am saying.

You can't be serious, all that was said is Vsync is giving problems and so should be disabled, that's all. Everything else come just from your lack of understanding about the universe, life and everything else. Sorry to say this but your machine is good indeed, it performs better than the user.

Goodby, so long, farewell, I quit this thread once at all.
Imagination is where we are truly real
Reply
#25
Also, the problem does not occur with vsync on, using AVX. All the while 6x is still on.*** Which is why I'm still here.

Someone please explain the technical details of AVX vs SSE4 like I asked earlier. All I can find is that AVX is software only... but it allows me to select DX11 Hardware? I'm not exactly sure what is going on here. I know of SSE instruction sets, I just don't know what the significance is in terms of how PCSX2 goes about using these. I will try to reproduce the issue on my laptop, but if I can't I'm thinking that SLI might be introducing some bugs as someone here suggested (even though PCSX2 is only using one GPU according to the GPU usage stats).

I think the issue with communication here is that you all are assuming I am an average pinhead who doesn't know much about computers or the demand that emulation puts on a computer, and me getting angry isn't helping my case. I'm not going to waste my time trying to convince you otherwise, but give me the benefit of the doubt, okay? What goes through your heads when I say "it's limited at 40fps but when I disable the limiter it goes up to 200fps in a controlled instance in the game"? I mean... that's pretty conclusively not a hardware restriction.

I did not know that vsync is on for all windows by DWM or "aero". I looked into it and my findings (and personal experience*) actually disagree with this statement: it seems that DWM is responsible for handling requests for vsync, not that it automatically vsyncs everything on screen. I could be wrong, but that would mean that PCSX2 is not vsynced by default and turning on the vsync option will not cause it to be doubly vsynced...

*I've seen a lot of windowed programs have terrible tearing issues that I can fix from the nvidia control panel. And if vsync were always on, I don't think the developers of MPC-HC would have Vsync as an option turned on by default. If vsync were always on, then having an option for vsync in programs like mpc-hc would not only be redundant, but misleading since turning it off would have no effect. It makes a lot more sense that DWM handles requests for vsync. A lot of the results I found were developers complaining that calls for vsync don't work when aero is disabled.
Reply
#26
(03-24-2013, 07:33 PM)Link68759 Wrote: First of all, you are saying "listen to us and turn off vsync" like it was your idea.

I said turning off vsync solves the problem. IN MY FIRST POST.

Also, the problem does not occur with vsync on using AVX.

You keep telling me my hardware can't handle it but I just don't understand how disabling the frame limiter and having my framerate boost past 200FPS is somehow indicative of my computer being unable to handle it. Every time I say this you ignore it. I will record you a video, unless you just refuse to comprehend what I am saying.

you no less then what you think By all mean show video of that so you can prove my point to other that your pc cant cope with 6x scale on SSE4 plugin and sync, which you should not be using seeing the AVX pluing is for AVX chips which is what YOU HAVE.

What you get i with limiter off is IRRELEVANT
Reply
#27
Since the tone became civil once again, maybe there still hope for something coming out of this thread. Let's treat some concepts then.

AVX is a set of instructions the CPU is able to understand and performs, you can see it as an extension to SSE4.x the same way each SSE version is an extension from previous ones. These are instructions for vector calculation primarily and they change nothing for previous programs which don't use the instructions. By principle it has nothing to do with Vsync.

Vsync on the other hand is a feature to grant the image buffer is sent for drawn at the exact moment the refresh rate swept starts, to prevent the drawing starts when the swept is advanced in its course. That means the next frame to be drawn is kept stalled till the next Vsync signal is active.

Double and triple buffering are techniques to grant the next frame is being rendered and loaded in the background while the actual frame is drawn, then the system shifts the buffers and the already filled one is sent directly to the video driver output. Then, besides a concept to keep the image from tearing, Vsync is actually a signal to control the refresh start and then may be used to decide when the actual frame is drawn also. If more than a controlling signal is present or being generated, things may become confuse.

For full screen that control should be left exclusively for the video driver since Vsync is important mainly for the monitor to know "when" to start the screen swept. For windowed environment, where more than one window could be drawing images at different paces, the OS tries keeping the control of when the image on each window must start.

On the other side, Vsync grants no frame will start being drawn until it (as the controlling signal) is active, so it effectively clamps the FPS at the refresh rate value. Special techniques may change this but is outside the scope of this forum, then let's keep at the basics.

Vsync on the emulator's plugin is provided as a workaround if for any reason you are experimenting image tearing. I'd rather not relying it to be so precise and reliable as that one from the video driver or even the way the OS try to keep the many windows from tearing. It is not something you MUST have activated forcibly, it can't do anything to make better an image which is already not tearing. Ask yourself why do you insist enabling it if is not having issues to start with?

Then comes the framelimiter, this is another "necessary evil", contrary of Vsync that one is a necessity, the better the machine the most it is necessary. Now come an extra complication. That 60 FPS the emulator is expected to run should be seen as an emulation of PS2 refresh rate (it's called NTSC or PAL for a reason), it is not an actual FPS as could be understood from a native PC game perspective. It's paramount it is kept at the nominal 60 FPS for NTSC or 50 FPS for PAL because it is the main source for PS2 timings. So, there is no actual sense in thinking how good is to have it above those values, actually is a bad thing that must be corrected... hence the necessary evil from framelimiter.

So all those 200 FPS you saw your machine is able to output need to pass by that clamping, whatever the method used to accomplish it from the framelimiter, and from this the FPS comes back to 60 but may exist complications in how it is being drawn, there are micro fluctuations which can compromise the Vsync. You could tell this to be an inaccuracy from the emulator, maybe you are right, but is an issue easily resolved by just not enabling Vsync at the emulator GS window config. The simplest way of looking at this is that after the framelimiting, any delay, for the smallest it is is enough to "lose" the Vsync signal and then the frame is forced to wait the next one... no surprise you see a drop on FPS.

Resuming, AVX is a set of instructions on your CPU which do nothing unless the program uses them. It should not by itself affect Vsync, and since is reported it is used in the newer plugins only for the software mode part, is probably something else causing the "issue" reported in this thread.

What leads to: It is an issue only because you insist using the emulator's Vsync when it is causing troubles not existent otherwise.

PS: Windows automatic update came around, I don't know how it changed from download but let me chose when install to download and install without warning Sad

Well, to end the post. From all the above one could imagine the extra mess if the game is PAL (and so expected to run at 50FPS) and the monitor's refresh rate (and then Vsync) is 60HZ or even more.
Imagination is where we are truly real
Reply
#28
Quote: So, there is no actual sense in thinking how good is to have it above those values, actually is a bad thing that must be corrected... hence the necessary evil from framelimiter.

Yes, I knew this, as the game speeds up quite a lot (or on older machines, run slowly). It's hard to not notice the fact that timing revolves around the game's "framerate". I only brought it up as a measuring stick of the performance my computers are capable of. My past computers could not even hold 45FPS at native resolution. My line of thought was, if I'm this much past 60FPS, then my computer is easily handling my current settings and the limiter going down to 40 is some strange aberration.

Now I'm not sure I understood everything you said...
1)Is vsync turning off when I disable the limiter, thus allowing the framerate to exceed (not be clamped at) 60FPS? Because that would make a little more sense, and would partially explain my issue. Or is the displayed framerate completely irrelevant- a measurement of NTSC timing only, and the actual output is still being clamped at 60FPS?
2)If the latter, then why does rivatuner display server still see the FPS as 200 or so when I un-limit it? Shouldn't it be seeing it as 60FPS?

Quote:Ask yourself why do you insist enabling it if is not having issues to start with?

Well first and foremost, I have two machines and the problem plagues one, not the other. This thread is entirely about me trying to understand the issue, not trying to fix it, since we already know the answer. I like to know what's going on.
As for why I had it on at all: My shaky understanding of Vsync is that it is somewhat similar to the Nyquist–Shannon sampling theorem, except the rate needs to be 1:1 with the data rather than 2:1. With vsync on, things are ordered and neat. In my experiences I almost always want it on because I frequently see a lot of tearing otherwise, so I usually just tick it on without thinking in my new machines because I haven't yet run into a case where it was too much to handle.

Assuming we're talking about a standard PC game and not an emulator- is enabling vsync where it's not needed a bad thing? It seems to me regulating the framerate to the monitor's refresh rate would always be a good thing to do, even if you don't see tearing.
Reply
#29
Vsync is a signal primarily, it is sent so the monitor can synchronize the sweep. This concept is still valid although modern LCD monitors don't have a "sweep" in the old sense of tube monitors but a matrix. Is easier to understand what is meant if you think the left upper pixel is the start point, then the next pixel in the first line is activated and so by the whole line, then is moved to the second line and repeated, again for the third line... in the end all lines are filled and the frame is complete, the Vsync is sent so the image starts once again from the first line.

As you can see, that signal can be used so the new frame don't start untill the current one is completed. IF the game (in the case) can push a higher FPS than the refresh rate and Vsync is off, that FPS is actual, that number of frames are actually drawn. If Vsync becomes active, the FPS is clamped because the next frame can't start being drawn untill the Vsync signal becomes active. That means Vsync clamps the FPS at 60 on a 60HZ vertical refresh rate monitor. I'm not sure if PCSX2 measures the actual FPS that is being drawn of the number of frames it is able to send, if is the first case if you see 200FPS that means the Vsync is off at the driver and windows is using only the dual buffering trick.

If the FPS is smaller than the refresh rate the image buffer will not be sent to the card's drawing buffer till it is complete, that means the first frame (from the previous image) will be repeated till the new frame comes from the program (lets call the game from now on). So, if the Vsync (option) is off, the new frame will start the drawing when the sweep is already in course, what can be cause of tearing but the actual FPS from the game is kept.

If Vsync (option, not the signal) is on, then the new frame from the game is stalled till the refresh rate completes the cycle and the Vsync signal is activated. This grants the image from the frame and the sweep start at same time, the image is perfect but the FPS drops.

When the frame limiter is active, it clamps the FPS at 60, what is wonderful, it is exactly equal the refresh rate so should not exist problem... but that's in the ideal world, the framelimiter may introduce micro flutuation on that FPS and since the Vsync is a pulse of short duration, the next frame may miss it if even slightly delayed and then the whole frame must wait till the whole refresh is done before it can be sent... result? drop in the FPS... I hope things start to become a bit clearer.

This scenery is further aggravated in a PAL game running on a system with a monitor with 60HZ refresh rate (sometimes even greater than this). Conclusion, the Vsync may work depending on the game and the micro flutuation it causes on the emulator, "when" the refresh rate and the intended FPS is the same...

Would be not a problem for a PAL game running on the emulator in a 50HZ monitor, I don't know how common such PC monitors are at Europe, if they are common at all. The console is designed to run on TV, not in PC monitors.

Just from these possible problems mentioned above, is sensible to suppose Vsync should be avoided unless absolutely necessary. It may mean problem even for PC games every time the FPS fall bellow the refresh rate, why would be better in a much more complex scenario like in emulating alien hardware?

Maybe the other, slower machine, not able to get such high extreme "FPS" at the emulator's output may cause less problems for the frame limiter, so even this could be a reasoning to understand the reported issue. Emulation is too complex scenario to us to be much picky, then let's avoid features that are harming the experience of gaming and be happy.
Imagination is where we are truly real
Reply




Users browsing this thread: 1 Guest(s)