Please help testing upcoming openMSX release!

Page 14/61
7 | 8 | 9 | 10 | 11 | 12 | 13 | | 15 | 16 | 17 | 18 | 19

By Manuel

Ascended (18066)

Manuel's picture

06-05-2020, 23:24

That's strange, because the default in 0.15.0 was SDL1 and that one did not have vsync, as far as I know. And when we moved to SDL2 we first also didn't have it, but due to 706793b we accidentally moved to vsync, but that gave other issues. So we moved back to the original default (no vsync). But vsync is apparently now needed for macOS??

By Grauw

Ascended (10001)

Grauw's picture

06-05-2020, 23:30

Manuel wrote:

That's strange, because the default in 0.15.0 was SDL1 and that one did not have vsync, as far as I know.

I don’t know about the implementation details of SDL1 vs SDL2 on MacOS, however 0.15.0 has no stutter, SDL2 had it on its introduction (so something changed), then it disappeared after apparently the vsync was accidentally enabled and it behaved like 0.15.0 did. So the logical conclusion seems to me that at least on MacOS SDL1 had vsync.

To be frank I don’t understand how the “immediate” mode can work for anyone. It’s like timing demo effects on the MSX with cycle exact CPU code and expecting the VDP to stay synchronized, when there is no guarantee that they are clocked by the same crystal.

By Manuel

Ascended (18066)

Manuel's picture

06-05-2020, 23:50

Well, the thing is, there are drawbacks to vsync:
1. full throttle doesn't work anymore without setting the max_frameskip to like 100. (But that seems to be remedied using adaptive vsync.)
2. it works badly on a 50Hz game (at least for me)
3. it takes a lot (LOT!) of CPU usage extra on my nvidia Linux box (looks like nvidia decided to time it with busy waiting).

What do other people have to say about it? How does this work out on your systems?

By Grauw

Ascended (10001)

Grauw's picture

07-05-2020, 00:05

On MacOS:

1. If I set maxframeskip to 0 then CMD-T does nothing on sync and sync_adaptive settings.
2. 50 Hz games judder in all modes (logically), however it looks more regular with sync.
3. CPU usage is the same.

p.s. I had noticed that throttling had become less effective, so I had set maxframeskip to 100 already a while back.

These drawbacks are nice and all but if you look at the video then you can see the alternative is simply a “not shippable” regression Smile.

By Manuel

Ascended (18066)

Manuel's picture

07-05-2020, 00:06

Yeah, me too, that's probably why I thought it mattered... it doesn't, indeed. So not sure what the advantage of adaptive really is in practice.

By Grauw

Ascended (10001)

Grauw's picture

07-05-2020, 00:33

In openMSX 0.15.0 on macOS when I set maxframeskip to 0 CMD-T also does nothing.

So this confirms that in SDL1 there was vsync.

By Grauw

Ascended (10001)

Grauw's picture

07-05-2020, 00:37

Grauw wrote:

In openMSX 0.15.0 on macOS when I set maxframeskip to 0 CMD-T also does nothing.

So this confirms that in SDL1 there was vsync.

This is also the case on Windows. I just tried on my work PC.

And in fullscreen mode openMSX 0.15.0 is smooth, while the latest openMSX 0.16.0 dev build is screen tearing like crazy. If I enable sync it too behaves like the previous release.

By mth

Champion (496)

mth's picture

07-05-2020, 00:57

With SDL1, it could be that vsync on or off was never explicitly selected, so we'd end up with the default which could differ per OS or even per graphics driver.

Looking at Grauw's video, in the stuttering parts, the screen updates only every other frame, instead of every frame. This goes for both the MSX part of the screen and the stats overlay, so it is the entire application output that ends up in limbo.

Immediate page flipping causes tearing, but apart from that tearing, it should be fluent. However, that assumes that what the application outputs gets displayed immediately by the OS as well and it seems at least macOS has extra buffering. What I don't understand though is why it would drop every other frame over an extended period of time; I had expected one frame to be dropped or repeated every now and then if openMSX doesn't output exactly at the monitor's refresh rate.

The best solution is adaptive vsync with hardware support (like G-Sync and FreeSync), but I don't know if this technology will become the standard for everyone or remain a niche feature for gaming monitors. I'm also not sure that the SDL2 "adaptive" setting is actually using hardware adaptive vsync; the documentation wasn't clear about that.

Full throttle not working with vsync is a problem with how throttle is implemented currently. In my opinion we should have a fast-forward setting that temporarily overrides the speed setting to run the MSX at something like 10x or 20x normal speed. It should not be unlimited, because fast-forwarding too quickly isn't user friendly either, since you'd overshoot whatever you were waiting for.

The maxframeskip setting was originally designed for the user to configure what openMSX should do when it cannot render quickly enough on slow host machines; this was relevant in the Pentium 2 days. A low maxframeskip setting means openMSX will slow down MSX time when it cannot render fast enough, while a high maxframeskip setting means it will try to keep the MSX running in real time by dropping frames. The effect it has on full throttle was accidental.

If we know we're running at for example 15x normal speed, we can simply render only 1 in 15 frames. That both saves effort not rendering an excessive amount of frames and it means we don't run into issues when delivering frames to a blocking graphics API.

For mismatches between MSX refresh rate (50/60 Hz) and host refresh rate (often 60 Hz, but could be anything in theory) we could either rely on the host to compensate for that (if possible and done well) or build compensation into openMSX. I think blueMSX had some kind of frame blending feature to map 50 Hz MSX video to 60 fps hosts. A simpler alternative would be to just send every 5th MSX frame to the host twice.

The busy waiting that Manuel encountered is a problem, in the sense that we need to work around it. But it's a problem of a particular graphics system, not a problem of vsync in general.

Anyway, fixing this properly is going to take some time, so for the short term I think we should keep the vsync setting and figure out what the best default value would be, perhaps separate per OS.

By Grauw

Ascended (10001)

Grauw's picture

07-05-2020, 01:02

It’s actually irregular, you can spot it in the player shadow sprite which toggles on and off every frame, but indeed also sometimes period where it’s pretty consistently missing every other frame.

Notice that the “bad periods” become shorter (on my Mac, haven’t tried on Windows) when I disable my OSD profiler. So there seems to be some kind of jitter related to the openMSX running / sleep time involved.

I think CLK is vsynced but paints the screen up to the pixel where the VDP is. I think openMSX always blits when the MSX reaches the VDP sync output signal? I don’t know which is better. Adaptive sync (as-in graphics card & display technology) is ideal, indeed, though I don’t know if that works if it’s not full-screen and either way a lot of people don’t have it.

Page 14/61
7 | 8 | 9 | 10 | 11 | 12 | 13 | | 15 | 16 | 17 | 18 | 19