[Bug]: 'Unable to compute luma percent: ERROR_OUT_OF_DEVICE_MEMORY'

[mrhappy200]

Steps for reproducing the issue

1. setup wluma with webcam as sensor
2. do the workaround for Support DRM modifiers (e.g. frames with multiple objects) #8
3. run wluma

What is the buggy behavior?

It panics instantly

What is the expected behavior?

It works and doesn't crash (or at least has a more approachable error)

Logs

RUST_LOG=debug wluma$ RUST_BACKTRACE=debug wluma
[2022-11-23T09:36:00Z INFO  wluma] Continue adjusting brightness and wluma will learn your preference over time.
thread 'predictor-eDP-1' panicked at 'Unable to compute luma percent: ERROR_OUT_OF_DEVICE_MEMORY', src/frame/capturer/wlroots.rs:128:26
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Version

I am using version 4.1.2-1 from the Arch User Repositories

Environment

lsb_release -a; uname -a; pgrep -l sway; pacman -Q | egrep "(wlroots|vulkan|sway|clang|rust)"; dpkg -l | egrep "(wlroots|vulkan|sway|clang|rust)"
bash: lsb_release: command not found
Linux HappyPc 6.0.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 16 Nov 2022 17:01:17 +0000 x86_64 GNU/Linux
2053 sway
2076 swaybg
egrep: warning: egrep is obsolescent; using grep -E
clang 14.0.6-4
rust 1:1.65.0-1
sway 1:1.7-10
swaybg 1.1.1-1
swayidle 1.7.1-3
swaylock 1.6-2
vulkan-headers 1:1.3.235-1
vulkan-icd-loader 1.3.235-1
wlroots 0.15.1-6
bash: dpkg: command not found
egrep: warning: egrep is obsolescent; using grep -E

[maximbaz]

Interesting bug, thanks for sharing!

Do you by any chance have multiple GPUs?

If I were to bet, the issue comes from the fact that I haven't had a chance to experiment with devices that have an external GPU, so there are several places in the vulkan.rs code that just take the first available device, the first available queue, etc., instead of being smart about it and querying some properties and picking the most fitting objects to work with.

wluma/src/frame/vulkan.rs

Lines 57 to 84 in d13f50a

	.get(0)
	.ok_or("Unable to find a physical device")?;
	let queue_family_index = 0;
	let queue_info = &[vk::DeviceQueueCreateInfo::builder()
	.queue_family_index(queue_family_index)
	.queue_priorities(&[1.0])
	.build()];
	let device_extensions = &[
	vk::KhrExternalMemoryFn::name().as_ptr(),
	vk::KhrExternalMemoryFdFn::name().as_ptr(),
	vk::ExtExternalMemoryDmaBufFn::name().as_ptr(),
	];
	let features = vk::PhysicalDeviceFeatures::builder();
	let device_create_info = vk::DeviceCreateInfo::builder()
	.queue_create_infos(queue_info)
	.enabled_extension_names(device_extensions)
	.enabled_features(&features);
	let device = unsafe { instance.create_device(physical_device, &device_create_info, None)? };
	let queue = unsafe { device.get_device_queue(queue_family_index, 0) };
	let pool_create_info = vk::CommandPoolCreateInfo::builder()
	.flags(vk::CommandPoolCreateFlags::RESET_COMMAND_BUFFER)
	.queue_family_index(queue_family_index);

Do you have an interest to try to experiment with code and to make it work on your hardware? If so I can try to give some pointers to examples of what to try 😊

[mrhappy200]

Thank you for your response, yes I do have 2 gpu's an intel integrated graphics gpu and one nvidia external gpu, I can't seem to make the nvidia one work though (some kind of driver problem) so it doesn't matter if wluma just ignores that one. Long story short I have some very basic rust knowledge and would like to have a try. :)

[maximbaz]

Awesome! As a very first step, I suggest to focus on finding a hacked hardcoded version of the code that works on your hardware. See those hardcoded 0s as indexes in the code snippet above in a few places, for physical decide, queue, etc? What if you just randomly try 1s, would anything change? There are also functions you could call to query all (e.g. all physical devices), then you can print some details to console, like how many of what you have, which index corresponds to Intel and Nvidia, etc.

Another thing that might help is just to add some prints everywhere, so you can get a rough idea of what is going on in Vulkan code, and what pieces are involved just before the crash.

In other words, let's explore first, and once it gets clearer on what precisely is the problem and what should have been the right value or parameter, then we can focus on writing a pretty and generic code that works for everyone and can be merged.

How does this sound? 😊 Feel free to post here some findings and analysis as you go, whether you find something interesting or get stuck, me and perhaps some folks who watch the repo will try to give you some pointers.

[mrhappy200]

Sounds great thanks for the help :) Is the code snippet above the only place with hard-coded devices or are there more places I should check?