Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Vulkan sampling support #256

Merged
merged 28 commits into from
Jan 18, 2024
Merged
Changes from 1 commit
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
5d76b16
WIP: First-pass implementation of Vulkan profiling. Currently assumes…
Valakor Jan 6, 2024
dff750b
Update comment describing compilation requirements for Vulkan profiling
Valakor Jan 6, 2024
11314f7
Fix calling rmt_GetLastErrorMessage from C++
Valakor Jan 7, 2024
45f4887
Fix rmt_ScopedD3D12Sample and rmt_ScopedVulkanSample. Extra parens co…
Valakor Jan 7, 2024
e608550
Fix Remotery_Destructor when D3D12 or Vulkan sampling are enabled. Ne…
Valakor Jan 7, 2024
067ba82
WIP: Fix getting Vulkan function pointers
Valakor Jan 7, 2024
433a90c
Update readme.md
Valakor Jan 7, 2024
bf90e0d
Fix visualization of uint64 and sint64 properties
Valakor Jan 7, 2024
fce6e3b
WIP: Vulkan spec states that you can't call vkGetQueryPoolResults wit…
Valakor Jan 7, 2024
533f7cf
WIP: First-pass Vulkan profiling implementation complete
Valakor Jan 7, 2024
083be58
Default RMT_USE_VULKAN back to 0
Valakor Jan 8, 2024
3db954d
Merge branch 'Celtoys:main' into main
Valakor Jan 8, 2024
bebb5a2
Update a handful of comments
Valakor Jan 8, 2024
5502716
Add missing ZeroMemory macro on non-Windows platforms
Valakor Jan 8, 2024
90c8e2e
Support thread naming on MacOS
Valakor Jan 8, 2024
d41b2bf
Vulkan on MacOS (via MoltenVK) only allows query pools of up to size …
Valakor Jan 8, 2024
6e3cbbf
Add missing comment about query pool size limits on MacOS
Valakor Jan 8, 2024
af38067
Fix timestamp calibration on MacOS. Turns out MoltenVK actually retur…
Valakor Jan 8, 2024
6f957e8
Update some comments in GetTimestampCalibration to reflect correct in…
Valakor Jan 8, 2024
8ceedd3
Remove ZeroMemory macro hack, just use memset
Valakor Jan 10, 2024
f38c000
Clarify that the function pointer passed to rmt_BindVulkan is the vkG…
Valakor Jan 10, 2024
0c96a6f
Rename VulkanGetInstanceProcAddr to rmtVulkanGetInstanceProcAddr
Valakor Jan 10, 2024
53897b4
Update readme.md
Valakor Jan 10, 2024
b0bf7c5
Ensure we delete VulkanBindImpl::mqToVulkanUpdate
Valakor Jan 10, 2024
70a13a9
Cleaner shutdown by automatically consuming all pending GPU samples. …
Valakor Jan 10, 2024
e7141d6
Clarify Vulkan compilation and extension/version requirements in Remo…
Valakor Jan 14, 2024
2e56a7b
Have the user specify Vulkan functions pointers instead of loading th…
Valakor Jan 17, 2024
2f28ede
Fix a handful of issues:
Valakor Jan 17, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 14 additions & 6 deletions lib/Remotery.c
Original file line number Diff line number Diff line change
Expand Up @@ -10280,18 +10280,26 @@ static rmtError GetTimestampCalibration(VulkanBindImpl* bind, VkPhysicalDevice v
timestamp_infos[0].sType = VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_EXT;
timestamp_infos[0].timeDomain = VK_TIME_DOMAIN_DEVICE_EXT;

// TODO(valakor): Reconsider whether we bother asking Vulkan to give us a CPU timestamp at all. It'd be much
// simpler to just query the device timestamp (supported by all platforms) and manually query our timer instead
// of all this platform-specific code. All we need is something "close enough".

// Potentially also query a cpu timestamp if supported
#if defined(RMT_PLATFORM_WINDOWS)
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 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:
// https://github.com/KhronosGroup/MoltenVK/blob/main/MoltenVK/MoltenVK/GPUObjects/MVKDevice.mm
// TODO(valakor): We have to fall back to manually querying CPU time due to the following issue:
// On Apple platforms MoltenVK reports support for VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT, which matches the time
// domain of mach_continuous_time(). To support mach_absolute_time() Vulkan would have to extend the available
// time domains to include something like "VK_TIME_DOMAIN_CLOCK_UPTIME_RAW_EXT". See the comments here:
// https://github.com/KhronosGroup/MoltenVK/blob/main/MoltenVK/MoltenVK/GPUObjects/MVKDevice.mm
//
// Alternatively, Remotery could switch to using mach_continuous_time(). The difference between the two is that
// mach_continuous_time() (CLOCK_MONOTONIC_RAW) includes system sleep time, whereas mach_absolute_time()
// (CLOCK_UPTIME_RAW) does not. I'm not 100% convinced that's what we would want, but I think it is technically
// more secure.
dwilliamson marked this conversation as resolved.
Show resolved Hide resolved
timestamp_count = 2;
timestamp_infos[1].sType = VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_EXT;
timestamp_infos[1].timeDomain = VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT;
Expand Down
Loading