GPU: OpenXR integration #11601

Beyley · 2024-12-07T05:12:10Z

Description

Implements functions to create/manage an OpenXR instance/system/session/swapchain, without exposing raw GPU handles to the end user. This branch still needs a lot of work, but the foundation is layed at the least, and I'm opening this PR to hopefully make it easier to get some help with some of the problems I'm currently encountering (namely the validation error and the resource management oopsies I'm likely committing).

Example usage.

Existing Issue(s)

#10925

TODO

Beyley · 2024-12-17T07:43:35Z

Ported the branch to windows, and its now tested working with latest SteamVR on Windows 10

so now it is tested working with the dominant OpenXR runtimes on Windows (SteamVR) and Linux (Monado)

also tested working on the Windows Oculus runtime

still a long way to go before being ready to merge though

Beyley · 2024-12-23T00:48:03Z

Aside from the validation errors on exit, this branch is in a fully usable state (I've been building a game with it for the past couple weeks, and that's mostly what has driven this work).

While it's definitely not ready to be merged, I think it's in a state where it's ready to get preliminary review and pointers to where to take the public API surface, since right now its a bit cobbled together.

I also need help with the Vulkan validation error on app exit

VUID-vkDestroyImageView-imageView-01026(ERROR / SPEC): msgNum: 1672225264 - Validation Error: [ VUID-vkDestroyImageView-imageView-01026 ] | MessageID = 0x63ac21f0 | vkDestroyImageView():  can't be called on VkImageView 0x9f9b41000000003c[] that is currently in use by VkFramebuffer 0x45d6d1000000004c[].
The Vulkan spec states: All submitted commands that refer to imageView must have completed execution (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkDestroyImageView-imageView-01026)

Just run this fork of SDL_gpu_examples on the openxr branch, using the latest version of this PR, then close the app as normal.

You are required to have an OpenXR runtime setup, so either build Monado with the simulated driver, use an actual device with SteamVR, or some other simulator like the Meta XR Simulator

thatcosmonaut

First of all, it's clear that some serious effort has gone into this already, so thank you for that.

For build system and dynamic loader stuff, I think we should defer to the build system expert @madebr who I'm sure will have comments.

Some general notes on my end:

I think SDL_openxr.h can just be folded into SDL_gpu.h, it depends on gpu.h anyway and all of the API surface relies on GPU API handles.

The Vulkan device setup functions are basically fully duplicated. I think it would be possible to just stick the XR setup inside the rest of the setup functions. I might even go as far as saying that there shouldn't be a separate CreateXRDevice and we could just include XR setup details as device properties.

I think the same probably goes for swapchain creation, but I'll have to look at it more closely.

What's the OpenXR story for D3D12/Metal? In general I've been reluctant to merge features that are only implemented on one backend because I don't want to give the impression that features might be missing or different on specific backends. If you're not able to develop for these platforms that's fine but we should try to find someone who can. Unfortunately I don't have a VR device so I can't be much help there personally.

thatcosmonaut · 2024-12-23T19:43:45Z

I also need help with the Vulkan validation error on app exit

VUID-vkDestroyImageView-imageView-01026(ERROR / SPEC): msgNum: 1672225264 - Validation Error: [ VUID-vkDestroyImageView-imageView-01026 ] | MessageID = 0x63ac21f0 | vkDestroyImageView():  can't be called on VkImageView 0x9f9b41000000003c[] that is currently in use by VkFramebuffer 0x45d6d1000000004c[].
The Vulkan spec states: All submitted commands that refer to imageView must have completed execution (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkDestroyImageView-imageView-01026)

This sounds like the device isn't asked to wait for idle before destroying the swapchain. You need to make sure the device is idle before teardown.

Beyley · 2024-12-23T20:42:33Z

I think SDL_openxr.h can just be folded into SDL_gpu.h, it depends on gpu.h anyway and all of the API surface relies on GPU API handles.

I was thinking the same aswell, but when doing so, I needed to define a bunch of extra types to not depend on the upstream OpenXR headers, which is why I originally created the SDL_openxr.h header. I later also was thinking of exposing the internal openxr-loader handle (or at least the getprocaddress function), the same way SDL_vulkan.h does, to aid integration, and those wouldnt fit inside SDL_gpu.h. Perhaps the GPU specific functions should go inside SDL_gpu.h, and the OpenXR types and the getprocaddress function should go inside SDL_openxr.h.

The Vulkan device setup functions are basically fully duplicated. I think it would be possible to just stick the XR setup inside the rest of the setup functions. I might even go as far as saying that there shouldn't be a separate CreateXRDevice and we could just include XR setup details as device properties.

This can be done, perhaps bool SDL.gpu.device.create.openxr, XrInstance* SDL.gpu.device.create.xr.out_instance, XrSystemId* SDL.gpu.device.create.xr.out_system_id. This would allow the two functions to be folded into eachother, and when creating an OpenXR GPU instance, you set create.openxr, and then the two out ptr properties.

I think the same probably goes for swapchain creation, but I'll have to look at it more closely.

Normal GPU swapchain creation is quite different from OpenXR swapchains. OpenXR swapchains are really just an array of VkImage handles gotten from the OpenXR runtime. The functions are unique code except for the end step, which is mostly derivative from the texture creation code, so parts can probably be merged with that.

What's the OpenXR story for D3D12/Metal? In general I've been reluctant to merge features that are only implemented on one backend because I don't want to give the impression that features might be missing or different on specific backends. If you're not able to develop for these platforms that's fine but we should try to find someone who can. Unfortunately I don't have a VR device so I can't be much help there personally.

With regards to D3D12, I don't own a Windows device capable of running an OpenXR runtime. The only device I own is the Volterra ARM64 dev kit, which is missing vital Vulkan extensions to run Monado (the Monado compositor is written in Vulkan, and uses interop extensions for implementing other APIs), and SteamVR does not have an ARM64 Windows port. Someone could very easily contribute D3D12 support though, and I'd be happy to help anyone who wants to try (perhaps the Vulkan side should be cleaned up first though, so there's a good reference of "where to start").

With regards to Metal, I dont believe this should be too strongly of a concern. SteamVR for MacOS was abandoned before OpenXR became a thing, and the WIP MacOS port of Monado does not support the KHR_metal_enable OpenXR extension. ~~Off the top of my head, I don't know any runtime which supports it.~~

~~The Khronos extension support report doesn't list a single runtime with the Metal extension, so I don't think we could implement/test this, even if we wanted to.~~

Turns out the Meta XR Simulator does support it! Seems in the past month this has become feasable. For reference, here's the qtquick3d and godot usages of the extension. I still don't own a capable enough Mac for this, but someone is free to implement it on their own mac using the Meta XR Simulator, and I'd be happy to guide them through it.

Beyley · 2024-12-23T22:32:08Z

This sounds like the device isn't asked to wait for idle before destroying the swapchain. You need to make sure the device is idle before teardown.

Yeah this seems to be the case, I attempted to test this earlier by just sleeping the main thread by 5 seconds and it still happened, but then I realized SDL_WaitForGPUIdle exists, and calling that fixes the validation error. Would it make sense to call VULKAN_Wait internally inside VULKAN_DestroyXRSwapchain? Or should this be deferred to callers

thatcosmonaut · 2024-12-23T23:10:33Z

Yeah go ahead and put a Wait in the destroy call. You can see we do something similar for UnclaimWindow and DestroyDevice.

Beyley · 2024-12-24T00:56:10Z

The Vulkan device setup functions are basically fully duplicated. I think it would be possible to just stick the XR setup inside the rest of the setup functions. I might even go as far as saying that there shouldn't be a separate CreateXRDevice and we could just include XR setup details as device properties.

I've made these changes, now, creating an OpenXR capable GPU device looks like this

CMakeLists.txt

include/build_config/SDL_build_config.h.cmake

CMakeLists.txt

madebr · 2024-12-24T01:44:06Z

CMakeLists.txt

+  if(SDL_GPU_OPENXR)
+    # TODO: actually do this header detection correctly
+    set(HAVE_OPENXR_H TRUE)
+    # TODO: im not sure what the optimal way to do this is...


I think hardcoding these filenames is fine.
Are the Windows dll and apple dylib unversioned?

Suggested change

# TODO: im not sure what the optimal way to do this is...

Not sure about macOS, but they are not versioned on Windows as built from source/distributed officially.

The OpenXR Loader spec specifies it to be unversioned on Windows, although it does not specify the macOS name (macOS is still fairly so-and-so when it comes to OpenXR).

We tend to follow Linux convention on Mac.

(How are the Windows DLLs unversioned? They have version resources, and the loader since like 1.0.9 can be used forward and backward compatible across patch versions, possibly even minor versions if you don't rely on core symbols being exported)

We tend to follow Linux convention on Mac.

If they're versioned in the same way on macOS as they are on Linux, I'll change the macOS path to libopenxr_loader.dylib.1

How are the Windows DLLs unversioned? They have version resources, and the loader since like 1.0.9 can be used forward and backward compatible across patch versions, possibly even minor versions if you don't rely on core symbols being exported

Unversioned in that the filenames themselves don't have a version number is what I meant.

CMakeLists.txt

Beyley · 2024-12-24T05:28:25Z

I think SDL_openxr.h can just be folded into SDL_gpu.h, it depends on gpu.h anyway and all of the API surface relies on GPU API handles.

I'm struggling with the build system trying to get this working. SDL_gpu.h needs to work even when the OpenXR header isn't imported/available, but SDL_gpu.h cannot define the OpenXR types (which I define myself inside here) due to it being pulled in by SDL_internal.h, and that being a precompiled header incldued before all internal code. Since SDL_internal.h is implicitly and pre-imported by all the internal code (such as SDL_gpu_vulkan.c) relying on openxr.h, I get duplicate definition errors when the internal code tries to import openxr.h.

I'm not entirely sure how to proceed here, I'm not great with C preprocessor spaghetti.

Options I can see are, but there's probably a proper one.
a) Keep the function definitions which rely directly on OpenXR types inside SDL_openxr.h
b) Undefine the conflicting types inside SDL_internal.h (this feels jank/prone to breakage)
c) Don't use the OpenXR types in the function definitions if they aren't available, and instead use generic types like const void * instead of const XrCreateInfo *, or Uint32 instead of XrResult

madebr · 2024-12-24T09:05:49Z

CMakeLists.txt

-      #   # endif()
-      # endif()
-    # endif()
+      set(SDL_GPU_OPENXR_DYNAMIC "\"libopenxr_loader.so.1\"")


Looks like only Linux has a versioned library. This is probably an oversight.

Reminder for me to create a PR to the oxr repo.

sezero · 2024-12-24T10:50:23Z

Minor thing: I got this bogus warning from gcc:

src/gpu/vulkan/SDL_gpu_vulkan.c: In function 'VULKAN_PrepareDriver':
src/gpu/vulkan/SDL_gpu_vulkan.c:11975: warning: 'instancePfns' may be used uninitialized in this function

Something like the following cures it for me.

--- a/src/gpu/vulkan/SDL_gpu_vulkan.c
+++ b/src/gpu/vulkan/SDL_gpu_vulkan.c
@@ -11972,7 +11972,7 @@ static bool VULKAN_PrepareDriver(SDL_VideoDevice *_this, SDL_PropertiesID props)
 
 #ifdef HAVE_GPU_OPENXR
     XrResult xrResult;
-    XrInstancePfns *instancePfns;
+    XrInstancePfns *instancePfns = NULL;
     XrInstance xrInstance = XR_NULL_HANDLE;
     XrSystemId xrSystemId = XR_NULL_HANDLE;
     bool xr = SDL_GetBooleanProperty(props, SDL_PROP_GPU_DEVICE_CREATE_XR_ENABLE, false);
@@ -12062,7 +12062,7 @@ static bool VULKAN_PrepareDriver(SDL_VideoDevice *_this, SDL_PropertiesID props)
         renderer->vkDestroyInstance(renderer->instance, NULL);
     }
 #ifdef HAVE_GPU_OPENXR
-    if (xr) {
+    if (instancePfns) {
         instancePfns->xrDestroyInstance(xrInstance);
         SDL_free(instancePfns);
         SDL_OPENXR_UnloadLoaderSymbols();

Beyley · 2025-01-10T01:56:58Z

Got a working Windows VM with a dedicated GPU passed through, so I'm going to start working on D3D12 support. Regarding Metal, I still don't have the hardware for working on that, so someone else will have to work on that.

Beyley · 2025-01-10T10:39:06Z

Made a bunch of progress on the D3D12 backend, it's now rendering to the screen successfully (at least the BasicVr sample is, I havent tested my game on it), however there's a bunch of validation errors relating to resource states.

Need to take a deeper look tomorrow into how rendering to images is internally handled in SDL_gpu's D3D12 backend.

D3D12 ERROR: ID3D12CommandQueue::ExecuteCommandLists: Using ID3D12DebugCommandList1::AssertResourceState on Command List (0x000001BFB756D000:'Unnamed ID3D12GraphicsCommandList Object'): Resource state (0x4: D3D12_RESOURCE_STATE_RENDER_TARGET) of resource (0x000001BFB6E51010:'Unnamed ID3D12Resource Object') (subresource: 0) is invalid for use as a INITIAL|PRESENT.  Expected State Bits (all): 0x0: D3D12_RESOURCE_STATE_[COMMON|PRESENT], Actual State: 0x4: D3D12_RESOURCE_STATE_RENDER_TARGET, Missing State: 0x0: D3D12_RESOURCE_STATE_[COMMON|PRESENT]. [ EXECUTION ERROR #538: INVALID_SUBRESOURCE_STATE]
D3D12 ERROR: ID3D12CommandQueue::ExecuteCommandLists: Using ResourceBarrier on Command List (0x000001BFB756D000:'Unnamed ID3D12GraphicsCommandList Object'): Before state (0x0: D3D12_RESOURCE_STATE_[COMMON|PRESENT]) of resource (0x000001BFB6E51010:'Unnamed ID3D12Resource Object') (subresource: 0) specified by transition barrier does not match with the state (0x4: D3D12_RESOURCE_STATE_RENDER_TARGET) specified in the previous call to ResourceBarrier [ RESOURCE_MANIPULATION ERROR #527: RESOURCE_BARRIER_BEFORE_AFTER_MISMATCH]
D3D12 WARNING: ID3D12CommandList::ClearRenderTargetView: The application did not pass any clear value to resource creation. The clear operation is typically slower as a result; but will still clear to the desired value. [ EXECUTION WARNING #820: CLEARRENDERTARGETVIEW_MISMATCHINGCLEARVALUE]

rpavlik · 2025-01-10T15:36:43Z

Feel free to ping me or come to the OpenXR forum if you have questions on the OpenXR side. https://community.khronos.org/c/openxr/25

Currently only supports the SDL_gpu vulkan driver.

Also refactor code to actually find the correct backend with OpenXR

Beyley · 2025-01-22T11:41:49Z

Congrats on everyone on the SDL 3.0 release! Just rebased my work on latest main to bring it up to date. Still haven't resolved the issues with the D3D12 driver yet, but the VK one still works great after the rebase.

Something I noticed on Windows when working on the D3D12 driver is that OpenXR's loader when compiled in debug mode produces a DLL named openxr_loaderd.dll, which is different than the release name of openxr_loader.dll. How should I handle this in SDL's OpenXR DLL loading code? Should I try release -> debug (may not pick the one the developer wants if the actual loader is installed system wide), or should i try debug -> release (which may adversely pick up a local debug build of the loader when the user wants a release version stored system wide).

madebr · 2025-01-22T17:59:24Z

Something I noticed on Windows when working on the D3D12 driver is that OpenXR's loader when compiled in debug mode produces a DLL named openxr_loaderd.dll, which is different than the release name of openxr_loader.dll. How should I handle this in SDL's OpenXR DLL loading code? Should I try release -> debug (may not pick the one the developer wants if the actual loader is installed system wide), or should i try debug -> release (which may adversely pick up a local debug build of the loader when the user wants a release version stored system wide).

This is done here in OpenXR-SDK. SDL2's CMake script also does this, which was undone immediately after the SDL3 fork creation.
I'd ask Khronos, but the sensible way is to always use openxr_loader.dll (without suffix) and require openxr-loader to be configured with -DOPENXR_DEBUG_POSTFIX=.

Beyley · 2025-01-23T08:32:10Z

the sensible way is to always use openxr_loader.dll (without suffix) and require openxr-loader to be configured with -DOPENXR_DEBUG_POSTFIX=.

Makes sense, although, when using the OpenXR SDK through vcpkg+cmake, it does not seem possible to tell it to give you the non-debug binaries always. When building your app for debug, ittl always provide you with openxr_loaderd.dll. I'd imagine this would be a common enough issue to cause confusion. Likely should document somewhere (maybe provide a hint to change the loaded lib path aswell?) that we require the non-suffix version, although not sure where exactly that would be best to do.

madebr · 2025-01-23T18:00:13Z

the sensible way is to always use openxr_loader.dll (without suffix) and require openxr-loader to be configured with -DOPENXR_DEBUG_POSTFIX=.

Makes sense, although, when using the OpenXR SDK through vcpkg+cmake, it does not seem possible to tell it to give you the non-debug binaries always. When building your app for debug, ittl always provide you with openxr_loaderd.dll. I'd imagine this would be a common enough issue to cause confusion. Likely should document somewhere (maybe provide a hint to change the loaded lib path aswell?) that we require the non-suffix version, although not sure where exactly that would be best to do.

I asked the openxr developers here

madebr · 2025-01-23T20:05:33Z

Looks like the OpenXR devs are not confident on this topic. They'd require extra testing to make sure mixing MSVC CRT's works.
They suggested attempting to load both names. Perhaps we should turn the library name into a hint, use openxr_loader.dll by default? Perhaps the hint can accept a comma separated list of dlls?

Beyley · 2025-01-23T20:19:57Z

Perhaps we should turn the library name into a hint, use openxr_loader.dll by default? Perhaps the hint can accept a comma separated list of dlls?

This seems reasonable to me, I'll do that. I likely should document this somewhere aswell, but not sure where would be best.

This allows third party apps to re-use the same OpenXR loader instance that SDL opens

madebr · 2025-01-24T00:02:45Z

Perhaps also add libopenxr-dev (for Ubuntu) and openxr-devel (for Fedora) to README-linux.md?
And add libopenxr-dev to .github/workflows/create-test-plan.py. (The first list is for Ubuntu 20.04+, the second list is 22.04+.

Beyley · 2025-01-24T00:19:03Z

Perhaps also add libopenxr-dev (for Ubuntu) and openxr-devel (for Fedora) to README-linux.md? And add libopenxr-dev to .github/workflows/create-test-plan.py. (The first list is for Ubuntu 20.04+, the second list is 22.04+.

I don't believe we need to, as I vendored the OpenXR headers same as was done for Vulkan. So we don't actually need the OpenXR dev packages on the host when compiling to get an OpenXR-enabled SDL.

madebr · 2025-01-24T00:25:41Z

I don't believe we need to, as I vendored the OpenXR headers same as was done for Vulkan. So we don't actually need the OpenXR dev packages on the host when compiling to get an OpenXR-enabled SDL.

Right, the page does not have a run-time depencies section.

src/gpu/xr/SDL_openxrdyn.c

but different this time

CMakeLists.txt

madebr · 2025-01-24T01:51:16Z

include/build_config/SDL_build_config.h.cmake

@@ -435,6 +435,7 @@
 #cmakedefine SDL_GPU_D3D12 1
 #cmakedefine SDL_GPU_VULKAN 1
 #cmakedefine SDL_GPU_METAL 1
+#cmakedefine HAVE_GPU_OPENXR 1


You also need to add this to SDL_build_config_android.h and SDL_build_config_windows.h.

Does SDL_build_config_macos.h/ios.h also need it? Or doesn't this work on top of MoltenVK?

I'm not sure about SDL_build_config_xbox.h and wingdk.h. You're adding a d3d12 backend here, so it can work. But loading shared libraries will not work (on xbox) (but I'm not a specialist, so don't quote me)

I've added it for the Windows and Android build configs.

Does SDL_build_config_macos.h/ios.h also need it?

For now, it's not necessary per-se.

Theoretically the openxrdyn bits should work fine as-is on MacOS/iOS (assuming you can dynamically load on iOS, I've never written for that platform), and once someone writes OpenXR support into the Metal backend (MoltenVK does not work due to missing extensions last I heard), it should just kick into action.

I'm not sure about SDL_build_config_xbox.h and wingdk.h. You're adding a d3d12 backend here, so it can work.

afaik, there's no OpenXR loader or headset for the Xbox, so it probably shouldnt have it. It'd just be dead weight on that platform.

I've heard secondhand for the PS5 there is an OpenXR compatibility layer allowing you to develop using it for the PSVR2 on PS5, but I dont have the developer credentials to actually see what that looks like, or much of anything about it. So if someone comes around wanting SDL_gpu OpenXR support on PS5, I'm not sure how well the current code would be suited to support that. Ideally someone with PS5 developer credentials comes around and gives pointers for what would need to be changed before merging to make that path more accessible in the future.

Beyley force-pushed the openxr branch from 9a34662 to 1e2c772 Compare December 7, 2024 05:24

Beyley force-pushed the openxr branch from c051384 to 5623fc0 Compare December 17, 2024 01:23

Beyley force-pushed the openxr branch 2 times, most recently from 9366a29 to 0b64757 Compare December 22, 2024 21:08

Beyley marked this pull request as ready for review December 23, 2024 00:48

thatcosmonaut reviewed Dec 23, 2024

View reviewed changes

madebr reviewed Dec 24, 2024

View reviewed changes

Beyley force-pushed the openxr branch from b865ddd to 4ffbd81 Compare December 24, 2024 19:18

Beyley force-pushed the openxr branch from 2acad37 to 6dbcd49 Compare January 4, 2025 21:51

Beyley added 8 commits January 22, 2025 03:19

gpu + openxr: Implement initial OpenXR support

88bcf7a

Currently only supports the SDL_gpu vulkan driver.

openxr: Fix docs syntax

1976aa7

gpu: Clean up XR func return values

18a90c3

gpu + openxr: Add SDL_XRGPUSupportsProperties

dfd94d1

Also refactor code to actually find the correct backend with OpenXR

openxr: Put structure base header for typedefs

421c030

gpu: Attempt to fix d3d12 and metal GPU backends

9dce8f5

gpu: Fix d3d12 compilation, and probably metal compilation

288e725

gpu: Wait for idle in VULKAN_DestroyXRSwapchain

c47cd72

Beyley force-pushed the openxr branch from ade4830 to e9aed47 Compare January 22, 2025 11:33

madebr mentioned this pull request Jan 23, 2025

openxr_loader dll name on Windows KhronosGroup/OpenXR-SDK-Source#528

Open

Beyley added 4 commits January 23, 2025 12:56

openxr: Add hint to specify the set of OpenXR loader sonames to try

1458f85

openxr: Expose Load/Unload library + xrInstanceProcAddress

4965b65

This allows third party apps to re-use the same OpenXR loader instance that SDL opens

d3d12: Fix error logs

93f233b

openxr: Provide stub functions when OpenXR is disabled

69d0563

d3d12: Use picked feature level in device creation

e9f4dee

cmake: Disable GPU on unsupported platforms

4356d61

Beyley added 4 commits January 23, 2025 16:39

dynapi: fix OpenXR dynapi

5f266fd

android: Add OpenXR files to android build

d4fad39

cmake + openxr: Pick library name in C file, not cmake

91ea910

VisualC: Add OpenXR code

760eead

madebr reviewed Jan 24, 2025

View reviewed changes

src/gpu/xr/SDL_openxrdyn.c Outdated Show resolved Hide resolved

Beyley added 3 commits January 23, 2025 17:37

android + VisualC: Add openxr include path

e59bb28

openxr: Look for the OpenXR loader without a version suffix aswell

73753f3

VisualC: Add khronos to include path

85d0e23

but different this time

madebr reviewed Jan 24, 2025

View reviewed changes

Beyley added 4 commits January 23, 2025 17:55

VisualC: minor spelling mistake

d479bc8

cmake: Fix order of sources

f467d07

build_config: Add OpenXR for android and windows build config

b9ef00a

gpu/d3d12: Remove unreachable code in GetAdapterByLuid

7e57f6b

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GPU: OpenXR integration #11601

GPU: OpenXR integration #11601

Beyley commented Dec 7, 2024 •

edited

Loading

Beyley commented Dec 17, 2024 •

edited

Loading

Beyley commented Dec 23, 2024 •

edited

Loading

thatcosmonaut left a comment

thatcosmonaut commented Dec 23, 2024

Beyley commented Dec 23, 2024 •

edited

Loading

Beyley commented Dec 23, 2024 •

edited

Loading

thatcosmonaut commented Dec 23, 2024

Beyley commented Dec 24, 2024

madebr Dec 24, 2024

Beyley Dec 24, 2024 •

edited

Loading

rpavlik Jan 7, 2025 •

edited

Loading

Beyley Jan 11, 2025

Beyley commented Dec 24, 2024

madebr Dec 24, 2024 •

edited

Loading

sezero commented Dec 24, 2024

Beyley commented Jan 10, 2025

Beyley commented Jan 10, 2025 •

edited

Loading

rpavlik commented Jan 10, 2025

Beyley commented Jan 22, 2025 •

edited

Loading

madebr commented Jan 22, 2025 •

edited

Loading

Beyley commented Jan 23, 2025 •

edited

Loading

madebr commented Jan 23, 2025

madebr commented Jan 23, 2025

Beyley commented Jan 23, 2025

madebr commented Jan 24, 2025

Beyley commented Jan 24, 2025

madebr commented Jan 24, 2025

madebr Jan 24, 2025 •

edited

Loading

Beyley Jan 24, 2025 •

edited

Loading

GPU: OpenXR integration #11601

Are you sure you want to change the base?

GPU: OpenXR integration #11601

Conversation

Beyley commented Dec 7, 2024 • edited Loading

Description

Existing Issue(s)

TODO

Beyley commented Dec 17, 2024 • edited Loading

Beyley commented Dec 23, 2024 • edited Loading

thatcosmonaut left a comment

Choose a reason for hiding this comment

thatcosmonaut commented Dec 23, 2024

Beyley commented Dec 23, 2024 • edited Loading

Beyley commented Dec 23, 2024 • edited Loading

thatcosmonaut commented Dec 23, 2024

Beyley commented Dec 24, 2024

madebr Dec 24, 2024

Choose a reason for hiding this comment

Beyley Dec 24, 2024 • edited Loading

Choose a reason for hiding this comment

rpavlik Jan 7, 2025 • edited Loading

Choose a reason for hiding this comment

Beyley Jan 11, 2025

Choose a reason for hiding this comment

Beyley commented Dec 24, 2024

madebr Dec 24, 2024 • edited Loading

Choose a reason for hiding this comment

sezero commented Dec 24, 2024

Beyley commented Jan 10, 2025

Beyley commented Jan 10, 2025 • edited Loading

rpavlik commented Jan 10, 2025

Beyley commented Jan 22, 2025 • edited Loading

madebr commented Jan 22, 2025 • edited Loading

Beyley commented Jan 23, 2025 • edited Loading

madebr commented Jan 23, 2025

madebr commented Jan 23, 2025

Beyley commented Jan 23, 2025

madebr commented Jan 24, 2025

Beyley commented Jan 24, 2025

madebr commented Jan 24, 2025

madebr Jan 24, 2025 • edited Loading

Choose a reason for hiding this comment

Beyley Jan 24, 2025 • edited Loading

Choose a reason for hiding this comment

Beyley commented Dec 7, 2024 •

edited

Loading

Beyley commented Dec 17, 2024 •

edited

Loading

Beyley commented Dec 23, 2024 •

edited

Loading

Beyley commented Dec 23, 2024 •

edited

Loading

Beyley commented Dec 23, 2024 •

edited

Loading

Beyley Dec 24, 2024 •

edited

Loading

rpavlik Jan 7, 2025 •

edited

Loading

madebr Dec 24, 2024 •

edited

Loading

Beyley commented Jan 10, 2025 •

edited

Loading

Beyley commented Jan 22, 2025 •

edited

Loading

madebr commented Jan 22, 2025 •

edited

Loading

Beyley commented Jan 23, 2025 •

edited

Loading

madebr Jan 24, 2025 •

edited

Loading

Beyley Jan 24, 2025 •

edited

Loading