This solves a problem where OpenXR timestamps could become invalid
(negative) in certain circumstances:
The timestamps that the OpenXR state tracker returned were offset such
that they appeared to start at OpenXR application startup time.
However monado-service is a long running service using system timestamps.
Because of this, if monado-service started work using a system timestamp
acquired before an OpenXR application started, then this system timestamp
could not be converted into an OpenXR without becoming invalid.
With this change, the OpenXR timestamps for OpenXR applications are offset
such that they appear to start at monado-service startup time instead.
As a side effect, all OpenXR applications connected to the same
monado-service instance will receive timestamps from the same domain.
1. Add feature info pose extension
2. Make pose extensions toggleable on runtime
3. Add timestats helper for external system to keep track of info for pose extensions
Currently, there is a single command pool in the vk bundle, shared by
everyone. Since command pools (and command buffers allocated from those
pools) can only be used on one thread at a time, this requires locking.
However, the main point of having these annoying command pool things in
the first place is that you can use one for each thread/lifetime/area in
the app and avoid the overhead of the locks (both computational and
cognitive).
In this change I have given the rendering bits of the compositor its own
command pool. Instead of allocating and freeing a command buffer every
frame, a single command buffer is allocated from the pool during
initialization, and the pool is reset at the beginning of each frame.
Normally, multiple pools would need to be used, but this is not
necessary in monado because frames are serialized. The `TRANSIENT` and
`ONE_TIME_SUBMIT` flags have been added, which can allow for some driver
optimizations. The render code no longer takes out the command pool
mutex. The shared command pool is still there for a few remaining
places where vulkan work needs to be done outside the compositor.
I used the command buffer vulkan helpers when possible, but I would
maybe propose the idea of removing them, since they aren't really
wrapping much at this point. The `C` macro helps a lot and it's a bit
easier to see the Vulkan details in front of you instead of needing to
switch back and forth between the helper.
Later, I think it would be cool to apply and document some constraints
like "the queue is only accessed in functions XYZ, the render_resources
command pool must only be accessed in layer_commit from 1 thread" etc.
Previously this was using math_quat_len which was always 1 for
these unit quaternions. This commit assumes math_quat_ln works properly which is
not exactly true at the moment and the returned angle will be twice as large.
Previously, math_pose_invert would apply a multiplication in the wrong
order. This lead to the position of the 'original' pose being rotated.
This patch fixes that, and adds a unit test to check this case.
An isometry is a rigid body transform. In this context I'm using the term to
refer to 4x4 homogeneous matrices in SE(3). I.e., matrices comprised of a
3x3 rotation, a 3x1 translation, and a [0,0,0,1] last row.
This matrix represent both rigid body transforms.
Isometry3f is a 4x4 matrix transform that performs only rotation and translation
(an SE(3) matrix). Its inverse can be computed trivially by Eigen compared to a
regular 4x4 transform.
Need COM initialized to do some things (like d3d11) on Windows,
don't know if the app already initialized it, don't have a big preference
for "how" we initialize it.
Percetto is using designated struct initializers, but those are not
supported in standard C++ before C++20, resulting in some compilation
warnings.
The previous fix for that was using a diagnostic valid for clang but not
for g++ resulting in another warning when building with g++:
-----------------------------------------------------------------------
In file included from ../monado/src/xrt/auxiliary/math/m_relation_history.cpp:19:
../monado/src/xrt/auxiliary/util/u_trace_marker.h:21:32: warning: unknown option after ‘#pragma GCC diagnostic’ kind [-Wpragmas]
21 | #pragma GCC diagnostic ignored "-Wc99-designator"
| ^~~~~~~~~~~~~~~~~~
-----------------------------------------------------------------------
For GCC the diagnostics to disable is actually "-Wpedantic", as shown
below:
-----------------------------------------------------------------------
In file included from ../monado/src/xrt/auxiliary/util/u_trace_marker.h:25,
from ../monado/src/xrt/auxiliary/math/m_relation_history.cpp:19:
../external/percetto/src/percetto.h: In function ‘void percetto_event_with_args(percetto_category*, uint32_t, const char*, int32_t, const percetto_track*, int64_t, uint64_t)’:
../external/percetto/src/percetto.h:424:5: warning: C++ designated initializers only available with ‘-std=c++2a’ or ‘-std=gnu++2a’ [-Wpedantic]
424 | .track = track,
| ^
-----------------------------------------------------------------------
And for clang "-Wc++20-designator" should be slightly more accurate:
-----------------------------------------------------------------------
In file included from ../monado/src/xrt/auxiliary/util/u_trace_marker.h:29:
../external/percetto/src/percetto.h:424:5: warning: designated initializers are a C++20 extension [-Wc++20-designator]
.track = track,
^
-----------------------------------------------------------------------
Fix all the warnings by ignoring the right diagnostics depending on the
compiler, taking care of differentiating clang++ from g++ as they both
define __GNUC__.
Should a application load and unload the OpenXR runtime driver multiple times
the Perfetto code becomes unstable and eventually crashes. This unfortunately
happens with the CTS, to avoid having to recompile Monado and a env variable
to control if tracing should be used.
Fixes CTS on nvidia.
Example code given by the driver devs in the nvidia forums was
VkBool32 dedicatedAllocation = (memDedicatedReq.requiresDedicatedAllocation != VK_FALSE) ||
(memDedicatedReq.prefersDedicatedAllocation != VK_FALSE);
However on GTX 1080, nvidia 470.103 with
./conformance_cli "Timed Pipelined Frame Submission" -G Vulkan2
we are to create a VkImage with
DEBUG [create_image] create_image: Use dedicated allocation: 0 (preferred: 0, required: 0)
doing so causes the VkFence wait in vk_submit_cmd_buffer to fail randomly with
either VK_TIMEOUT or VK_ERROR_DEVICE_LOST.
On AMD radv we are told to use dedicated allocation:
DEBUG [create_image] create_image: Use dedicated allocation: 1 (preferred: 1, required: 1)
Only the camera tracking config writes and uses the version field.
Unfortunately the tracking override config is written into the same json
object while not making use of the version field.
* Adds support for querying the device's currently set display refresh rate to
be used for android driver on creation. Allowing for devices which support
selecting other refresh rate modes beyond 60hz.
* Changes hardcoded sensor polling rate to now match refresh queried from the
device.
If the last returned display time shifts backwards slightly with respect to the
last sampled display time from the compositor, the next predicted display time
will not move forward by one frame. Adding half the display period to the
comparison makes the pacing robust to this case.
- Add CMakeUserPresets.json to .gitignore
- Fix DASSERTs warning for release builds
- Do not use one euro filter with invalid poses
- Other NFC style changes
Add some missing returns pointed out by -Wreturn-type:
-----------------------------------------------------------------------
[75/1571] Building C object src/xrt/auxiliary/CMakeFiles/aux_util.dir/util/u_config_json.c.o
.../src/xrt/auxiliary/util/u_config_json.c: In function ‘u_gui_state_scene_to_string’:
.../src/xrt/auxiliary/util/u_config_json.c:524:1: warning: control reaches end of non-void function [-Wreturn-type]
524 | }
| ^
-----------------------------------------------------------------------
Some variables are only used in asserts, so they may be unused
depending on the build type:
-----------------------------------------------------------------------
[68/315] Building C object src/xrt/auxiliary/CMakeFiles/aux_util.dir/util/u_sink_combiner.c.o
.../src/xrt/auxiliary/util/u_sink_combiner.c:188:11: warning: unused variable 'diff_ns' [-Wunused-variable]
int64_t diff_ns = frames[0]->timestamp - frames[1]->timestamp;
^
1 warning generated.
[205/315] Building C object src/xrt/compositor/CMakeFiles/comp_main.dir/main/comp_renderer.c.o
.../src/xrt/compositor/main/comp_renderer.c:872:17: warning: unused variable 'layer_count' [-Wunused-variable]
const uint32_t layer_count = c->base.slot.layer_count;
^
1 warning generated.
-----------------------------------------------------------------------
Mark them as XRT_MAYBE_UNUSED to fix the build warnings.
Add some missing returns pointed out by -Wreturn-type:
-----------------------------------------------------------------------
[32/315] Building C object src/xrt/auxiliary/CMakeFiles/aux_gstreamer.dir/gstreamer/gst_sink.c.o
.../src/xrt/auxiliary/gstreamer/gst_sink.c:53:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
}
^
1 warning generated.
[84/315] Building C object src/xrt/auxiliary/CMakeFiles/aux_vk.dir/vk/vk_compositor_flags.c.o
.../src/xrt/auxiliary/vk/vk_compositor_flags.c:117:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
}
^
.../src/xrt/auxiliary/vk/vk_compositor_flags.c:146:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
}
^
2 warnings generated.
-----------------------------------------------------------------------
For the function returning VkImageAspectFlags return a literal 0 because
the enum values VK_IMAGE_ASPECT_NONE or VK_IMAGE_ASPECT_NONE_KHR may not
always be defined.
