From af38067c6a4fbea9e82b947313c11837739d824c Mon Sep 17 00:00:00 2001 From: Matthew Pohlmann Date: Sun, 7 Jan 2024 23:34:31 -0800 Subject: [PATCH] Fix timestamp calibration on MacOS. Turns out MoltenVK actually returns a timestamp in the mach_continuous_time() time domain instead of mach_absolute_time(), which I think is a bug --- lib/Remotery.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/Remotery.c b/lib/Remotery.c index 816f3dd..bd68ae0 100644 --- a/lib/Remotery.c +++ b/lib/Remotery.c @@ -10285,7 +10285,9 @@ static rmtError GetTimestampCalibration(VulkanBindImpl* bind, VkPhysicalDevice v timestamp_count = 2; timestamp_infos[1].sType = VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_EXT; timestamp_infos[1].timeDomain = VK_TIME_DOMAIN_QUERY_PERFORMANCE_COUNTER_EXT; -#elif defined(RMT_PLATFORM_MACOS) +#elif 0 // defined(RMT_PLATFORM_MACOS) + // TODO(valakor) The comment below would be correct if not for a bug in MoltenVK that returns the wrong timestamp + // value for VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT. For now we'll just sample the CPU timestamp manually. // On Apple platforms MoltenVK reports support for VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT even though under the hood // it uses mach_absolute_time(), which is actually CLOCK_UPTIME_RAW. This doesn't matter though as Remotery also uses // mach_absolute_time() for time measurements so the results are comparable. For more information see: @@ -10309,7 +10311,7 @@ static rmtError GetTimestampCalibration(VulkanBindImpl* bind, VkPhysicalDevice v } // Convert CPU ticks to microseconds, offset from the global timer start -#if defined(RMT_PLATFORM_WINDOWS) || defined(RMT_PLATFORM_MACOS) +#if defined(RMT_PLATFORM_WINDOWS) // || defined(RMT_PLATFORM_MACOS) cpu_timestamp_ticks = timestamps[1]; cpu_timestamp_us = usTimer_FromRawTicks(&g_Remotery->timer, cpu_timestamp_ticks); #else