Verify builds on other machines

[kanerogers]

Description

In order for other people to use hotham, they're going to need to build it on their machine!

TODO

• Verify clean build on Windows
• Verify clean build on Linux
• Verify clean build on macOS

[kanerogers]

@pwcl Could you please try a build on Linux? It will almost certainly fail but it'll be fun to find out why.

[sinoth]

On Windows, trying to run cargo apk run --release in examples\beat-saber-clone results in:

error: extra arguments to `rustc` can only be passed to one target, consider filtering
the package by passing, e.g., `--lib` or `--bin NAME` to specify a single target
Error: Command `cargo rustc --target aarch64-linux-android --release -- -L F:\\Rust\\hotham\\target\\cargo-apk-temp-extra-link-libraries` had a non-zero exit code.

[kanerogers]

Thanks so much to @sinoth for finding these issues!

1. Need to make sure the user has Android SDK and Android NDK installed.
   1.1. Make sure they're using NDK22 as NDK23 has issues with android-ndk-glue: cargo-apk: Work around missing libgcc on NDK r23 with linker script rust-mobile/ndk#189
2. Much of Hotham is Windows specific at the moment. Need to eg. write bash versions of the run_on_device scripts
3. Need to install JDK

[pierre-l]

Could you please try a build on Linux? It will almost certainly fail but it'll be fun to find out why.

Hey, this project looks awesome, pretty much exactly what I was looking for :)

I gave it a try yesterday. I had to replace both *.so for it to compile, and chmod +x. Unfortunately the activity never starts on the headset, it keeps loading. I didn't use the --release arg though. I'll try that soon.

[sinoth]

Unfortunately the activity never starts on the headset, it keeps loading.

@pierre-l Did you get a black screen? If so, try emulating what the run_on_device.ps1 script in the project root is doing. Using something like adb shell pidof rust.beat_saber_example then adb logcat --pid=### where ### is the Process ID returned from the first command.

This will allow you to see if/how the app is crashing. In my case, it was an error with the most recent crate of OpenXR and the version of ndk-glue being requested. @kanerogers pushed a fix very recently for this. Try pulling the most recent commit to see if it helps.

If the activity fails to install to the device, then I'm not sure! Maybe add to this issue the console output of the cargo apk run --release command while in the examples/beat-saber-clone directory.

[pierre-l]

@sinoth I get a panic from ndk-glue. I still have to use the *.sos I downloaded myself to compile successfully but maybe I don't have the right version of these. Do you have any recommendation?

--------- beginning of main
01-08 14:37:54.150 12014 12014 I t_saber_exampl: Late-enabling -Xcheck:jni
01-08 14:37:54.185 12014 12014 E t_saber_exampl: Unknown bits set in runtime_flags: 0x8000
01-08 14:37:54.245 12014 12014 W System  : ClassLoader referenced unknown path: 
01-08 14:37:54.338 12014 12038 I RustStdoutStderr: [BEAT_SABER_EXAMPLE] MAIN!
01-08 14:37:54.345 12014 12038 I RustStdoutStderr: thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /home/pierre/.cargo/registry/src/github.com-1ecc6299db9ec823/ndk-glue-0.5.0/src/lib.rs:59:39
01-08 14:37:54.345 12014 12038 I RustStdoutStderr: stack backtrace:
01-08 14:37:54.345 12014 12038 I RustStdoutStderr: note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Bash script draft

[sinoth]

@pierre-l This is exactly the error I was getting before @kanerogers updated the ndk-glue version. The problem was something along the lines of one part of the code using version 0.4.0 and another using 0.5.0. Hopefully @kanerogers can come to the rescue here! You might try using version 0.4.0 if you can.

[pierre-l]

@sinoth I was using the Oculus mobile SDK v35. Rolling back to v34 allowed me to go further.
The panic now occurs upon texture loading:

01-08 15:15:59.199 12995 13020 I RustStdoutStderr: [HOTHAM_RENDERER] Creating renderer..
01-08 15:15:59.199 12995 13020 I RustStdoutStderr: [HOTHAM_INIT] Creating swapchain....done!
01-08 15:15:59.200 12995 13020 I RustStdoutStderr: [HOTHAM_INIT] Creating render pass....done!
01-08 15:15:59.432 12995 13020 I RustStdoutStderr: [HOTHAM_INIT] Creating pipeline..[HOTHAM_INIT] Creating frames.. ..done!
01-08 15:15:59.432 12995 13020 I RustStdoutStderr: [HOTHAM_RENDERER] Creating UBO..
01-08 15:15:59.432 12995 13020 I RustStdoutStderr: [HOTHAM_VULKAN] Allocated 288 bits of buffer memory: 0xb097c90000000027
01-08 15:15:59.432 12995 13020 I RustStdoutStderr: [HOTHAM_VULKAN] Allocated 40 bits of buffer memory: 0xb9181f0000000029
01-08 15:15:59.432 12995 13020 I RustStdoutStderr: thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: UnknownFileFormat', hotham/src/texture.rs:206:10

Investigating...

[kanerogers]

Holy smokes @pierre-l ! Thanks so much for checking out Hotham and big thanks to @sinoth for helping out! Sorry it took me a while to reply - I try to take at least Saturday off. 😄

@pierre-l can I ask what example you're trying to run that's giving you the texture error? Potentially it's one of the older ones that I haven't been keeping up to date.

If you try the beat saber example, that's usually the most up to date and stable. It won't show you the game at the moment, but it will give you a UI test, and importantly, it should build.

If you're still having issues, let me know and I can investigate further!

[kanerogers]

@sinoth I was using the Oculus mobile SDK v35. Rolling back to v34 allowed me to go further.

Interesting! I've been hand building libopenxr rather than using the Oculus SDK. I'll check this out!

[pierre-l]

I hadn't enabled LFS, sorry! I'm now able to get even further without having to change any *.so.

Another panic, but I feel close!

1-09 01:54:49.493  6097  6120 I RustStdoutStderr: [HOTHAM_VULKAN] Allocated 8260 bits of buffer memory: 0xad5092000000018d
01-09 01:54:49.493  6097  6120 I RustStdoutStderr: [HOTHAM_VULKAN] Allocating mesh descriptor sets..
01-09 01:54:49.493  6097  6120 I RustStdoutStderr: [HOTHAM_VULKAN] ..done! [0x296268000000018e]
01-09 01:54:49.494  6097  6120 I RustStdoutStderr: [HOTHAM_VULKAN] Allocated 8260 bits of buffer memory: 0x7a6b0c0000000190
01-09 01:54:49.494  6097  6120 I RustStdoutStderr: [HOTHAM_VULKAN] Allocating mesh descriptor sets..
01-09 01:54:49.494  6097  6120 I RustStdoutStderr: [HOTHAM_VULKAN] ..done! [0x42878f0000000191]
01-09 01:54:49.494  6097  6120 I RustStdoutStderr: [HOTHAM_VULKAN] Allocated 8260 bits of buffer memory: 0x4557cc0000000193
01-09 01:54:49.494  6097  6120 I RustStdoutStderr: [HOTHAM_VULKAN] Allocating mesh descriptor sets..
01-09 01:54:49.494  6097  6120 I RustStdoutStderr: thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: ERROR_OUT_OF_POOL_MEMORY', hotham/src/gltf_loader.rs:367:10

[kanerogers]

No need to apologise @pierre-l ! I provided no documentation whatsoever, the fact that you've made it this far is a miracle!

Just to confirm: which example are you running and on what device?

[pierre-l]

@kanerogers I'm running the beat saber example on the original Oculus Quest

[kanerogers]

Aha, that may be the issue. Potentially the number of descriptors is lower on the Quest 1: I haven't run any of the more recent demos on it in a while.

Descriptor pool sizes still needs to be set correctly: from memory I just set them to whatever value will make a given scene work. I had recently tested the Quest 2 on some very complex scenes, so potentially that's why the number is so high right now.

I'll take a look on my Quest 1 tonight, but in the meantime if you want to just get something working, take a look in VulkanContext constructor and see if you can find a descriptor pool that has a very high number (eg. > 100). Without looking at it I think the sampler pool was bumped recently. Tweak it around a bit and see what happens. 😄

Long term the solution should be to have a more programmatic pool size: either the max size the device will give us, or perhaps based on an analysis of the scene.

[pierre-l]

No luck with 10/100/1000 values :'(

[kanerogers]

Rats! I ran out of time yesterday @pierre-l but I'll make sure I get onto this today!

[kanerogers]

@pierre-l I've done a bit of digging and yep, we're definitely not handling this correctly..

I've created #118 to address this bug. Hopefully I can get something working for you soon!

[kanerogers]

@pierre-l PS. @sinoth suggested I create a Hotham Discord - please feel free to jump in if you want to get some realtime support on Hotham: https://discord.gg/qxnd5XjD

[kanerogers]

@pierre-l Great news! With #119 merged, you should now be able to get the example running on the Quest 1. 😄

Let me know how you go!

[pierre-l]

@kanerogers Victory! Cubes are displayed, I can control the sabers, this is awesome! Thanks for the fix! I'll see you on Discord :)

[kanerogers]

@kanerogers Victory! Cubes are displayed, I can control the sabers, this is awesome! Thanks for the fix! I'll see you on Discord :)

Yay! 😁

[jam1garner]

@kanerogers just as another bullet point to help you check off another box: building on linux (Ubuntu 20.04.3 LTS x86_64) without issue*.

*excluding the bug I've seen in other XR projects regarding needing to reinstall every run. but that's not really relevant to being able to build on linux

[kanerogers]

Nice!! Thanks so much!

Can you expand on the second point a bit though?

[jam1garner]

Nice!! Thanks so much!

Can you expand on the second point a bit though?

Needed to find some time to recreate but here's all the issues I hit. I do not think any of them have anything to do with linux but feel free to let me know if you want any of these broken out into their own issues.

---

Audio Issue

First up, audio doesn't seem to work. Digging through logs this seems to be the culprit:

01-27 10:54:51.588 14244 14267 I RustStdoutStderr: [HOTHAM_AUDIO_CONTEXT] An error occurred playing the audio stream: The requested device is no longer available. For example, it has been unplugged.
01-27 10:54:51.599 14244 14267 I RustStdoutStderr: [HOTHAM_AUDIO_CONTEXT] An error occurred playing the audio stream: The requested device is no longer available. For example, it has been unplugged.
01-27 10:54:51.884 14244 14267 I RustStdoutStderr: Error reading packet: IoError(Custom { kind: UnexpectedEof, error: "end of stream" })

For context this is on a Quest 2 (with earbuds connected, don't remember how android audio sources work off the top of my head so this may or may not be relevant).

---

Requires Reinstall/Reboot to Relaunch

Behavior observed: After first running the demo either a reinstall of the demo or a reboot of the quest is required to launch again. Additional launches result in an unrendered window (eg an empty "2d android app" window pops up, but the "contents" are just transparent/nonexistant). No Vulkan errors in the logs and they mostly seem to be exactly how they look when the demo works properly.

I have a suspicion this bit of the logs is indirectly relevant:

01-27 10:54:23.187 13791 14139 I RustStdoutStderr: thread '<unnamed>' panicked at 'Failed to bind: Os { code: 98, kind: AddrInUse, message: "Address already in use" }', hotham-debug-server/src/lib.rs:116:43
01-27 10:54:23.187 13791 14139 I RustStdoutStderr: stack backtrace:
01-27 10:54:23.188 13791 14139 I RustStdoutStderr: note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

If I had to guess, your android event handling isn't properly exiting the process, so when it tries to launch a second instance it tries to begin debugging but the address is already bound to by the activity. I looked through your code and am honestly having a bit of trouble finding any issue in how you're handling this.

My one guess is that this unconditional break here seems incorrect:

hotham/hotham/src/app.rs

Lines 110 to 124 in ea8c0b2

	loop {
	if let Some(event) = self.poll_android_events() {
	println!("[HOTHAM_ANDROID] Received event {:?}", event);
	match event {
	ndk_glue::Event::Resume => self.resumed = true,
	ndk_glue::Event::Destroy | ndk_glue::Event::WindowDestroyed => {
	self.should_quit.store(true, Ordering::Relaxed);
	return true;
	}
	ndk_glue::Event::Pause => self.resumed = false,
	_ => {}
	}
	}
	break;
	}

I think what you actually want here is:

            while let Some(event) = self.poll_android_events() {
                println!("[HOTHAM_ANDROID] Received event {:?}", event);
                match event {
                    ndk_glue::Event::Resume => self.resumed = true,
                    ndk_glue::Event::Destroy | ndk_glue::Event::WindowDestroyed => {
                        self.should_quit.store(true, Ordering::Relaxed);
                        return true;
                    }
                    ndk_glue::Event::Pause => self.resumed = false,
                    _ => {}
                }
            }

eg rather than break after the first iteration, stop looping once there are no more events to handle. I also can't say I have the highest confidence in the empty wildcard branch either.

If you'd like I can try testing/PRing the above if you think that's correct.

[kanerogers]

All systems green!