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: OpenXR integration #1387

Closed
wants to merge 8 commits into from
Closed

WIP: OpenXR integration #1387

wants to merge 8 commits into from

Conversation

blaind
Copy link

@blaind blaind commented May 14, 2021

Connections

One take at resolving OpenXR support (#602). See https://github.com/blaind/xrbevy

The code in this pull request is not even close to merge-able, but I thought its good idea to open it for further discussion.

See also gfx-rs/gfx#3761 and gfx-rs/wgpu-rs#910

Description
For architecture of the pull request, see https://github.com/blaind/xrbevy/blob/main/docs/architecture.md (evolving document)

Testing
(TODO)

@blaind blaind marked this pull request as draft May 14, 2021 16:36
"openxr",
"hal/use-openxr",
"wgt/use-openxr",
"gfx-backend-vulkan/use-openxr",
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Current PR supports only Vulkan-based OpenXR (are others possible?)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think they are, at least dx and gl are supported by OpenXR.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from what I've seen from the docs its GL and VK


[dependencies]
bitflags = "1.0"
serde = { version = "1.0", features = ["serde_derive"], optional = true }
openxr = { version = "0.14", features = ["loaded"], default-features = false, optional = true }
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eventually, is it okay to have openxr as an optional dependency?

}

/// FIXME FIXME FIXME is this okay?
pub struct OpenXRHandles {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These OpenXR concepts are required at engine-space (bevy) in order to communicate with openxr. This is one take at transferring them between

@@ -17,6 +17,10 @@
use serde::{Deserialize, Serialize};
use std::{num::NonZeroU32, ops::Range};

#[cfg(feature = "use-openxr")]
/// OpenXR
pub mod openxr;
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming clash with openxr crate, other names?

self.device_create_texture_raw_image::<B>(device_id, desc, None, id_in)
}

pub fn device_create_texture_raw_image<B: GfxBackend>(
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic here is modeled from https://github.com/Ralith/openxrs/blob/5283daa09ddbe7170069ff3ea9e42e8a8a9ff4bc/openxr/examples/vulkan.rs#L537 - basically a raw image is required for the swapchain

@blaind
Copy link
Author

blaind commented Jul 23, 2021

I'll close this - there's a better encapsulation approach with raw handles that's being continued at #1609

@blaind blaind closed this Jul 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants