[GH-ISSUE #619] Emulator hangs for ROMs compiled with the preview branch of libdragon #93

New issue

Closed

opened 2026-03-03 13:45:38 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 13:45:38 +03:00

Owner

Originally created by @Krasjet on GitHub (Nov 21, 2025).
Original GitHub issue: https://github.com/gopher64/gopher64/issues/619

I've already bisected that this commit in libdragon introduces the issue: github.com/DragonMinded/libdragon@901b83887e.

Any ROM compiled using libdragon after that commit hangs the emulator, and it has to be force killed. But ares works fine with the ROM. The log is

[INFO]: Targeting VK_KHR_present_wait latency to 1 frames.
[INFO]: Layer count: 1
[INFO]: Found layer: VK_LAYER_MESA_device_select.
[INFO]: Enabling instance extension: VK_KHR_surface.
[INFO]: Enabling instance extension: VK_KHR_xlib_surface.
[INFO]: Enabling instance extension: VK_EXT_debug_utils.
[INFO]: Enabling instance extension: VK_KHR_get_surface_capabilities2.
[INFO]: Enabling instance extension: VK_EXT_swapchain_colorspace.
[INFO]: Enabling instance extension: VK_EXT_surface_maintenance1.
[INFO]: Found Vulkan GPU: Intel(R) UHD Graphics 620 (KBL GT2)
[INFO]:     API: 1.4.318
[INFO]:     Driver: 25.2.7
[INFO]: Using Vulkan GPU: Intel(R) UHD Graphics 620 (KBL GT2)
[INFO]: Enabling device extension: VK_KHR_swapchain.
[INFO]: Enabling device extension: VK_KHR_external_semaphore_fd.
[INFO]: Enabling device extension: VK_KHR_external_memory_fd.
[INFO]: Enabling device extension: VK_EXT_external_memory_dma_buf.
[INFO]: Enabling device extension: VK_EXT_image_drm_format_modifier.
[INFO]: Enabling device extension: VK_KHR_calibrated_timestamps.
[INFO]: Enabling device extension: VK_EXT_conservative_rasterization.
[INFO]: Enabling device extension: VK_KHR_compute_shader_derivatives.
[INFO]: Enabling device extension: VK_EXT_memory_budget.
[INFO]: Enabling device extension: VK_EXT_external_memory_host.
[INFO]: Enabling device extension: VK_EXT_descriptor_buffer.
[INFO]: Enabling device extension: VK_KHR_present_id2.
[INFO]: Enabling device extension: VK_KHR_present_wait2.
[INFO]: Enabling device extension: VK_EXT_swapchain_maintenance1.
[INFO]: Enabling device extension: VK_EXT_hdr_metadata.
[INFO]: Using present mode: 0.
[INFO]: Current transform is enum 0x1.
[INFO]: Supported transform 0x1: IDENTITY_BIT_KHR.
[INFO]: Swapchain current extent: 919 x 996
[INFO]: Targeting 3 swapchain images.
[INFO]: Created swapchain 919 x 996 (fmt: 44, transform: 1).
[INFO]: Got 3 swapchain images.
[INFO]: Enabling 8 and 16-bit integer arithmetic support for more efficient shaders!

I'm using v1.1.10 on Linux (x86_64).

Originally created by @Krasjet on GitHub (Nov 21, 2025). Original GitHub issue: https://github.com/gopher64/gopher64/issues/619 I've already bisected that this commit in libdragon introduces the issue: https://github.com/DragonMinded/libdragon/commit/901b83887ec4d8a166937a23ca5c62256f0b30c. Any ROM compiled using libdragon after that commit hangs the emulator, and it has to be force killed. But ares works fine with the ROM. The log is ``` [INFO]: Targeting VK_KHR_present_wait latency to 1 frames. [INFO]: Layer count: 1 [INFO]: Found layer: VK_LAYER_MESA_device_select. [INFO]: Enabling instance extension: VK_KHR_surface. [INFO]: Enabling instance extension: VK_KHR_xlib_surface. [INFO]: Enabling instance extension: VK_EXT_debug_utils. [INFO]: Enabling instance extension: VK_KHR_get_surface_capabilities2. [INFO]: Enabling instance extension: VK_EXT_swapchain_colorspace. [INFO]: Enabling instance extension: VK_EXT_surface_maintenance1. [INFO]: Found Vulkan GPU: Intel(R) UHD Graphics 620 (KBL GT2) [INFO]: API: 1.4.318 [INFO]: Driver: 25.2.7 [INFO]: Using Vulkan GPU: Intel(R) UHD Graphics 620 (KBL GT2) [INFO]: Enabling device extension: VK_KHR_swapchain. [INFO]: Enabling device extension: VK_KHR_external_semaphore_fd. [INFO]: Enabling device extension: VK_KHR_external_memory_fd. [INFO]: Enabling device extension: VK_EXT_external_memory_dma_buf. [INFO]: Enabling device extension: VK_EXT_image_drm_format_modifier. [INFO]: Enabling device extension: VK_KHR_calibrated_timestamps. [INFO]: Enabling device extension: VK_EXT_conservative_rasterization. [INFO]: Enabling device extension: VK_KHR_compute_shader_derivatives. [INFO]: Enabling device extension: VK_EXT_memory_budget. [INFO]: Enabling device extension: VK_EXT_external_memory_host. [INFO]: Enabling device extension: VK_EXT_descriptor_buffer. [INFO]: Enabling device extension: VK_KHR_present_id2. [INFO]: Enabling device extension: VK_KHR_present_wait2. [INFO]: Enabling device extension: VK_EXT_swapchain_maintenance1. [INFO]: Enabling device extension: VK_EXT_hdr_metadata. [INFO]: Using present mode: 0. [INFO]: Current transform is enum 0x1. [INFO]: Supported transform 0x1: IDENTITY_BIT_KHR. [INFO]: Swapchain current extent: 919 x 996 [INFO]: Targeting 3 swapchain images. [INFO]: Created swapchain 919 x 996 (fmt: 44, transform: 1). [INFO]: Got 3 swapchain images. [INFO]: Enabling 8 and 16-bit integer arithmetic support for more efficient shaders! ``` I'm using v1.1.10 on Linux (x86_64).

kerem closed this issue

2026-03-03 13:45:39 +03:00

kerem commented

2026-03-03 13:45:39 +03:00

Author

Owner

@ariahirose64 commented on GitHub (Nov 22, 2025):

i can confirm this is a real bug

@ariahirose64 commented on GitHub (Nov 22, 2025): i can confirm this is a real bug

kerem commented

2026-03-03 13:45:39 +03:00

Author

Owner

@loganmc10 commented on GitHub (Nov 22, 2025):

Thanks, I appreciate you bisecting the commit, which saves a lot of time.

For the time being, I'm just going to add a little hack to convert the addresses back to 32-bit addresses. This is kind of annoying to be honest, since as far as I can tell, it is "complexity for the sake of complexity", since no PI devices actually use the 64-bit address space, but maybe they have future plans I am not aware of.

@loganmc10 commented on GitHub (Nov 22, 2025): Thanks, I appreciate you bisecting the commit, which saves a lot of time. For the time being, I'm just going to add a little hack to convert the addresses back to 32-bit addresses. This is kind of annoying to be honest, since as far as I can tell, it is "complexity for the sake of complexity", since no PI devices actually use the 64-bit address space, but maybe they have future plans I am not aware of.

kerem referenced this issue

2026-03-03 13:46:25 +03:00

[PR #93] [MERGED] Update eframe requirement from 0.29 to 0.30 #201