Electron segfaults when enabling hardware acceleration on iMX8MP

scott · June 18, 2024, 11:20am

Hello!

I’m working on achieving hardware accelerated graphics for our Electron front-end on the Verdin iMX8MP, for smoother animations and transitions for the GUI. So far I’ve structured the project after the VS Code Torizon Electron Template, and our Electron application simply creates a BrowserWindow accessing https://browserbench.org to be able to ascertain whether the applied changes have created better performance, as the UI itself is still in development. Unfortunately, the BrowserWindow crashes, whether actually running tests or not, with the --use-gl=egl option applied. It does however crash after some time has passed, leaving me enough time to start a benchmark test, and the difference is quite noticeable - until the crash of course.

First of, the output of tdx-info:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           5.15.148-6.6.1+git.23a8e831749d #1-TorizonCore SMP PREEMPT Thu Feb 29 20:25:21 UTC 2024
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/911edfe9ee0d80deff5013f22805689ff18f1977e087a7824078275dbf5cdc51/0
Distro name:              NAME="TorizonCore"
Distro version:           VERSION_ID=6.6.1-build.14
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15128291
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8MP WB on Verdin Development Board
Toradex version:          0064 V1.1A
Serial number:            15128291
Processor arch:           aarch64
------------------------------------------------------------

Secondly, the logs provided by the Electron container:

[207:0618/104304.868905:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[207:0618/104304.870406:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[207:0618/104304.871896:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[207:0618/104304.872943:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
Warning: vkCreateInstance: Found no drivers!
Warning: vkCreateInstance failed with VK_ERROR_INCOMPATIBLE_DRIVER
    at CheckVkSuccessImpl (../../third_party/dawn/src/dawn/native/vulkan/VulkanError.cpp:101)
    at CreateVkInstance (../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:493)
    at Initialize (../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:379)
    at Create (../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:301)
    at operator() (../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:556)

Segmentation fault (core dumped)

The Dockerfile build instructions are the same, as the ones provided in the VS Code Torizon Electron Template. As such, the application is also launched with the same commandline options (--no-sandbox --ozone-platform=wayland --use-gl=egl --in-process-gpu). Any help would be much appreciated, as front-end processes really aren’t my field of expertise, thanks!

Best regards,
Sophus

ToradexAI · June 18, 2024, 11:20am

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

Hello Sophus,

The issue you’re encountering with Electron segfaulting when enabling hardware acceleration on the Verdin iMX8MP appears to be related to the Electron’s handling of OpenGL ES contexts and its interaction with the underlying graphics stack on the iMX8MP platform. The Vulkan errors and the segmentation fault suggest a problem with the GPU acceleration path that Electron attempts to use.

Given the context and the error logs you’ve provided, here are a few steps and considerations that might help resolve or diagnose the issue further:

Verify GPU Drivers and OpenGL ES Support: Ensure that the GPU drivers on your Verdin iMX8MP are correctly installed and that OpenGL ES support is functional. You can test this by running other OpenGL ES applications or benchmarks outside of Electron to confirm that the GPU acceleration works as expected.
Electron and Wayland Compatibility: Electron’s compatibility with Wayland and the specific GPU acceleration mechanism (--use-gl=egl) might have limitations or require specific versions of Electron, Mesa, and Wayland protocols. Verify that you’re using compatible versions of these components. Sometimes, updating or downgrading Electron or the graphics stack can resolve such issues.
Docker Container Graphics Access: Running Electron inside a Docker container introduces additional layers of complexity, especially regarding access to the GPU. Ensure that the Docker container is correctly configured to access the host GPU. This typically involves mounting the correct device files (/dev/dri, for example) into the container and ensuring the container runtime is configured to allow GPU access.
Electron Launch Options: The launch options you’re using are generally correct for Wayland and GPU acceleration. However, experimenting with additional Electron flags related to GPU and rendering might provide more stability or reveal more about the underlying issue. Flags such as --disable-gpu-sandbox, --enable-features=UseOzonePlatform, and --disable-gpu-compositing can sometimes alter the behavior in beneficial ways.
Debugging and Logs: Further debugging might reveal more information. Running Electron with additional verbosity or debug flags can provide more insights into what happens internally before the crash. Environment variables like ELECTRON_ENABLE_LOGGING=true and ELECTRON_ENABLE_STACK_DUMPING=true can be useful.
Fallback to Software Rendering: As a temporary workaround, you might consider disabling GPU acceleration (--disable-gpu) to see if the Electron application runs without crashing. This isn’t a solution but can serve as a diagnostic tool or a temporary

Please, also check if these links can help you solve your problem:

2D/3D Graphics Acceleration (GPU) | Toradex Developer Center.

scott · June 18, 2024, 12:32pm

The issue has been resolved. The Electron version used was version 28.2.0, and the issue was resolved by downgrading to version 24.3.1 - the version used in the VS Code Torizon Templates as well. +1 to the ToradexAI for suggesting some paths I hadn’t yet tried to solve this issue.

rudhi.tx · June 18, 2024, 1:42pm

Hello @scott,

Thanks for contributing to the Toradex Community!
We are glad to hear that the AI could help you resolve this issue! Feel free to open new posts in case new topics arise!