Thanks for the question,

     while there is a DSP unit on the glasses (that's available for programming, also one on phone), the glasses just pass info to the phone. The entire rendering pipeline resides on the phone, and the rendered scene is then blitted to the glasses display. It is possible to grab the 6DOF parameters in the program, but there's nothing on the glasses that's doing "rendering". The current use-case that we're working with is a tethered/wireless headset connected to a phone/android-device that's doing most of the work. Different architectures using Qualcomm XR chips (like the Quest 2) are self contained but essentially there's a CPU/GPU unit and the HMD display. 

We are fully behind using OpenXR to use a uniform standard so that it's easy for hmd manufacturers to utilize Qualcomm (and any other conforming SOC) to easily create apps using engines that conform to OpenXR interfaces. Generic portability. OpenXR does have an overlay subsystem that could do what you describe, but you'd have to code that in the rendering engine, and that's always going to be on the CPU/GPU.

You might review the non-Snapdragon Spaces software for the Lenovo glasses - they utilize the glasses as an external 2D display - whereas Spaces is intended for XR applications.

- Snapdragon Spaces Support

Hi Ron Appreciate you response. Perhaps it may help if I distill my query further to clarify what I am trying to achieve. 3D rendering will not be necessary on the glasses. However, what will be required is 2D Screen Position Adjustment just like what all monitors have(i.e. horizontal and vertical). Here come the questions: Is Screen Position Adjustment for glasses available through api? Can this adjustment be fast enough to react to head movement? Ability to shift screen completely off visible FOV will be essential. Is Qualcomm in full control of Display Controller firmware to add this ability if it is not currently present? Using up battery for 3D perspective calculations with Outlook and Excel is completely unnecessary. Everything should be doable with the current Display Controller. A little 2D reactivity to head movements is what i am hoping to organise. A small Win/Mac app should be able to instruct the Display Controller if api is available. Ideally, this app should run on internal DSP. Hoping Qualcomm could assist. Thanks

So you can see I'm working backwards through the forum posts :-)

While I wait for a response from Lenovo - what you'd need to do this is 6DOF information ( the head tracking information) to get where the user is moving their head position and direction. So while you might be able to use DCC/CI to move the display, you'd near certainly need OpenXR functionality to get the 6DOF info (at least, in a hardware agnostic manner) - since the render pipeline is already hooked up to the 6DOF - anything you render (3D or 2D) can be placed and would respond as expected when the user moves their head. If you look up head-locked display you'll find more information on that. It's usually used for HUDs but you do have frame-by-frame control over the position.  Additionally the render pipeline is designed to not-tear when the user moves their head (each eye is independant and their prediction algorithms are involved & throw in time-warp, space-warp, etc), something that would not occur if you're directly manipulating the display parameters outside of the rendering sync.

- Ron

-  DDC/CI code running on the internal DSP - this will be ideal and  completely transparent. 

.....So yes and on most Qualcomm chips there's a programmable DPS chip, but each one might have one of different capabilities - plus it might already be in use (like for hand tracking)

Wondering if 6DoF data is available to the DSP?

.....You would need to access that information through the OpenXR interface and then pass it along.

- DDC/CI code running on PC/Mac.

.... Spaces runs on Android

Is OpenXR supported by Spaces on PC at this stage?

.... No, although running with a PC and using the glasses as the XR display is something we're looking at, but it's not POR

Is OpenXR the only way to access 6DoF data?

.... currently yes

-  Use GPU brand specific api for screen position adjustment. i.e.  generally screen position can be set manually from GPU settings and  there should be a way to do it with an api.

...Spaces is designed to be hardware agnostic, but in general we'll support Spaces Ready hardware. Currently that's just the Motorola Edge+ plus Lenovo A3. Theoretically an OpenXR compatible hardware might work, but Spaces is designed to add layers on top of the basic OpenXR functionality. But there's more than one flavor of OpenXR that could work (they can all co-exist)

Which of these three options are more realistic?

...So, while you might be able to feed DCC/CI code to the display, it would be tricky to sync them as each eye in an OpenXR frame has it's own timing and interactions with things like space/time warp, etc. The left eye gets rendered with a particular 6DOF location and then the right eye with a (potentially) different 6DOF value. Making small changes would work, large ones would cause issues.

....You'd still need to use OpenXR to fetch the 6DOF position. I don't know if there's a way to get the "predicted" position for the right eye. Since you're already in the middle of the OpenXR rendering path, it'd be easy to adjust the position of a rendered object and let the render pipeline worry about the left/right 6DOF differences as it's built in. There are OpenXR 2D layers that are designed for headlocked/displaylocked purposes.

OpenXR has a few versions that run on a PC (Steam, Monado, etc.) basically these get installed on your machine and at run time you select the one you want.

Since we're pretty heavily invested in OpenXR support, I can't see us providing a non-OpenXR interface - we had our own SDK for a while and it's been deprecated in favor of our OpenXR implementation.

Accessing/programming our DSP's is done through our Hexagon SDK.  Other than knowing it exists and it's used in machine learning tasks (like hand tracking, CV app, etc.) I  don't have any experience in utilizing it in an app. If you're not running our OpenXR services then I think there is likely some programming space.

Tearing/misalignment will occur when there's a change in the render target *or* 6DOF values as it's being blitted to the screen. Unless these commands are queued up and executed in alignment with vsync *and* the warp in effect you can get so tearing or eye-mismatch. Note that 6DOF values for each are are (possible) different. The left eye is the "current" 6DOF and the right eye gets a "predicted" 6DOF.

I'm looking at DDC/CI but as this is a Lenovo product if I get some positive response I'll be pointing you there as this is beyond the reach of "Snapdragon Spaces". That said - I like creative solutions :-)

- Ron