Vsync?

[gfx-rs]

Vsync?

[rennis250]

How did you measure it? I'm trying to finding the two best points to insert time measurements. For example, I've tried the following in the window example:

if let Some(drawable) = layer.next_drawable() {
   let s = time::precise_time_ns();
    ....
   let e = time::precise_time_ns();
   println!("{:?}", e - s);
}

Then I get the following values:

1879944
898908
349323
249012
428890
584386
927518
1285250
826689
974424
397832
766317
408452
1542721
440585

which are too small and too variable to be vsynced. They should all be around 16666666 at 60Hz.

EDIT: Sorry, should have put the initial time measurement before the polling of events. When I do that, then I get a few values that are in the expected range, but the variability is much worse than what one finds with OpenGL. With Metal, I get a mean and std of ~8314262+/-7460716, which is far off, whereas with OpenGL, I get ~16571695+/-109656, which is getting close to perfect synchronization.

[JohnColanduoni]

@rennis250 High Sierra has added an explicit displaySyncEnabled property. I've not played with it so I'm not sure if it's on by default but it may be worth a shot. allowNextDrawableTimeout might be related but there's no hint as to what they mean by that.

If you need high precision your best bet is probably to do an end-run around CAMetalLayer entirely. macOS (and newer iOS) have an API-independent handle to a GPU-resident texture called IOSurface that can be bound to a Metal texture. It's stable but almost entirely undocumented, however Chrome uses it and I've written a rough presentation system that uses it with Metal here. Note that you'd still need to use CVDisplayLink to time the swapping of buffers (i.e. the present function in the code I linked).

[kvark]

@JohnColanduoni and @fkaa are our main Metal experts, but they may not be fully responsive at this time.

From what I see in the docs, the method variant with afterMinimumDuration parameter is only available on iOS 10.3 and tvOS 10.2. Are you trying to test it on a mac instead?

[rennis250]

Oh, I should have taken a closer look. Well, that's disappointing... Thanks, though!

Hmm... I'll do a bit more searching, but I suppose that I will have to accept that there may be no decent Vsync for Metal on macOS for the time being.

[kvark]

I'd look into SDL/glfw source code to see what they do.

…

On Sep 25, 2017, at 14:36, Robert J. Ennis ***@***.***> wrote: Oh, I should have taken a closer look. Well, that's disappointing... Hmm... I'll do a bit more searching, but I suppose that I will have to accept that there may be no decent Vsync for Metal on macOS for the time being. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[fkaa]

As far as i can recall VSync is on by default on macOS, at least when I was working with it.

[rennis250]

I took a look. Both GLFW’s and SDL’s vsync functionality is tied to OpenGL. I’m going to do a bit more searching.

[JohnColanduoni]

Internally CAMetalLayer uses CVDisplayLink when VSync is enabled (which like @fkaa said appears to be by default). That at least used to be how Apple recommended OpenGL applications drive their render loops (see here) but that documentation is pretty outdated. It's possible you could get better results by registering a callback yourself and calling present:atTime:, but I've never tried it.

[rennis250]

Thanks for that information. Doing a search for "CAMetalLayer CVDisplayLink" brought me to the following post, which seems to say that you need to explicitly ask for a CVDisplayLinkRef when working with Metal:

https://stackoverflow.com/questions/37794646/the-right-way-to-make-a-continuously-redrawn-metal-nsview

I'm going to try implementing this and see how it works.

Best,
Rob

[rennis250]

Wow, I just re-ran the example to see something and now it works. I didn't do anything with CVDisplayLink yet. I'm not sure what was going wrong before, although I wasn't getting too much sleep in the past days, so most likely an inability to remember where and how I was placing the time::precise_time_ns() statements...

Now, I get ~16674287+/-408055 ns for the Metal example.

Sorry about that! Thanks again for the help. This is pretty exciting, since I've wanted to try Metal for a while. :) 👍

Best,
Rob

[rennis250]

Although, just as a warning, vsync precision has become more than 2x worse in High Sierra and is above the threshold for the line of work that I do, so that's unfortunate. Vsync precision was great in tests on Sierra, provided that one disabled a few of the fancy window animations and such things.

[rennis250]

Interesting. Thanks a lot for this. When I again have some free time, I'll try it out. 👍