Open ensc opened 1 year ago
Also facing similar issue on i.MX 8M Mini, chromium version 111.0.5563.110. On the command line I see these messages:
$ chromium --in-process-gpu --use-gl=egl
[4137:4137:0507/200048.114690:ERROR:wayland_event_watcher.cc(63)] Fatal Wayland communication error: Bad file descriptor.
Trace/breakpoint trap
$ chromium --in-process-gpu --use-gl=egl --ozone-platform=wayland
[4445:4445:0507/200703.494457:ERROR:wayland_event_watcher.cc(63)] Fatal Wayland communication error: Socket operation on non-socket.
Trace/breakpoint trap
$
I'm facing the same issue. chromium since version 110 uses it's own libwayland fork it uses to create struct wl_display
s and such, and passes those to EGL, which uses system wayland, which on kirkstone is 1.20.0.
The chromium libwayland fork and upstream libwayland 1.20.0 (even latest upstream 1.21) have incompatible changes, which is why system libwayland uses some bogus value as the display connection fd.
I modified the oe-core/meta/recipes-graphics/wayland/wayland_1.20.0.bb
to use the chromium fork and renamed to wayland_1.21.0.bb
and it works:
# We're using the chromium version, which has some additional patches.
PR:append = ".chromium0"
# For chromium 111.0.5563.147
# See: https://source.chromium.org/chromium/chromium/src/+/refs/tags/111.0.5563.147:DEPS;l=1821-1825
SRCREV = "c7473676b8abc682e820546287044cee3bca9147"
SRC_URI = "git://chromium.googlesource.com/external/anongit.freedesktop.org/git/wayland/wayland;protocol=git;branch=chromium_1_21_0
file://run-ptest \
file://0002-Do-not-hardcode-the-path-to-wayland-scanner.patch \
file://0001-build-Fix-strndup-detection-on-MinGW.patch \
"
S = "${WORKDIR}/git"
I'm a bit surprised how this works at all though, on desktop.
Any news on this? I'm trying with chromium 112 and I'm having the same issue described in the first on iMX8MM. libGLESv2.so and libEGL.so being used are those supplied by NXP.
Using --in-process-gpu chromium hangs without never opening the main window. ./chromium-bin --no-sandbox --use-gl=egl --ozone-platform=wayland --in-process-gpu
[2185:2200:0624/214712.093884:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2185:2200:0624/214712.094955:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2185:2185:0624/214712.115576:ERROR:chrome_browser_cloud_management_controller.cc(162)] Cloud management controller initialization aborted as CBCM is not enabled.
[2185:2200:0624/214712.151848:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2185:2200:0624/214712.151967:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[0624/214712.284307:WARNING:exception_snapshot_linux.cc(263)] fpsimd not found
[2185:2185:0624/214712.254778:ERROR:(-1)] Check failed: false.
[2185:2263:0624/214712.508191:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[2185:2263:0624/214712.509125:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[2185:2263:0624/214712.510199:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
If i remove --in-process-gpu it works but EGL is disabled. ./chromium-bin --no-sandbox --use-gl=egl --ozone-platform=wayland
[3858:3871:0624/215612.631693:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[3858:3871:0624/215612.632011:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[3858:3858:0624/215612.652597:ERROR:chrome_browser_cloud_management_controller.cc(162)] Cloud management controller initialization aborted as CBCM is not enabled.
EGL: Warning: No default display support on wayland
[3891:3891:0624/215612.660380:ERROR:gl_display.cc(819)] Initialization of all EGL display types failed.
[3891:3891:0624/215612.660977:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
EGL: Warning: No default display support on wayland
[3891:3891:0624/215612.662044:ERROR:gl_display.cc(819)] Initialization of all EGL display types failed.
[3891:3891:0624/215612.662427:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
[3891:3891:0624/215612.667713:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
[3858:3871:0624/215612.684527:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[3858:3871:0624/215612.684715:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[0624/215612.809277:WARNING:exception_snapshot_linux.cc(263)] fpsimd not found
[3858:3858:0624/215612.777658:ERROR:(-1)] Check failed: false.
EGL: Warning: No default display support on wayland
[3944:3944:0624/215612.998757:ERROR:gl_display.cc(819)] Initialization of all EGL display types failed.
[3944:3944:0624/215612.999090:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
EGL: Warning: No default display support on wayland
[3944:3944:0624/215612.999765:ERROR:gl_display.cc(819)] Initialization of all EGL display types failed.
[3944:3944:0624/215613.000078:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
[3944:3944:0624/215613.017032:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
[3858:3952:0624/215613.132189:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[3858:3952:0624/215613.133082:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[3858:3952:0624/215613.134267:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
EGL: Warning: No default display support on wayland
[3960:3960:0624/215613.154051:ERROR:gl_display.cc(819)] Initialization of all EGL display types failed.
[3960:3960:0624/215613.154441:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
EGL: Warning: No default display support on wayland
[3960:3960:0624/215613.155149:ERROR:gl_display.cc(819)] Initialization of all EGL display types failed.
[3960:3960:0624/215613.155434:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
[3960:3960:0624/215613.161107:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
EGL: Warning: No default display support on wayland
[3969:3969:0624/215613.189300:ERROR:gl_display.cc(819)] Initialization of all EGL display types failed.
[3969:3969:0624/215613.189675:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
EGL: Warning: No default display support on wayland
[3969:3969:0624/215613.190091:ERROR:gl_display.cc(819)] Initialization of all EGL display types failed.
[3969:3969:0624/215613.190244:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
[3969:3969:0624/215613.194481:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
Running Mali blobs on an Exynos 5 device here, in the same situation, encounteing the exact same issue with the '--in-process-gpu' flag. Without the flag, I can't get hardware accelerated compositing and all other GPU accelerated functions run at a reduced speed under Wayland.
Anyone tried examining the differences between 109 and 110+?
I'm using chromium-kirkstone-next layer by JeffyCN (of course, it pulls from meta-browser). I spoke with him not very long ago and he gave me some insights about this problem:
• Chromium is linked to its own built-in internal Wayland libraries (under third_party/wayland)
• The Mali blob is linked to the shared system Wayland libraries
According to him, the two Wayland APIs confuse each other when the definition of their internal structs are different with '--in-process-gpu'
That patch mentioned above seems promising though. I'll give it a try later and see if it helps.
I'm facing the same issue. chromium since version 110 uses it's own libwayland fork it uses to create
struct wl_display
s and such, and passes those to EGL, which uses system wayland, which on kirkstone is 1.20.0.The chromium libwayland fork and upstream libwayland 1.20.0 (even latest upstream 1.21) have incompatible changes, which is why system libwayland uses some bogus value as the display connection fd.
I modified the
oe-core/meta/recipes-graphics/wayland/wayland_1.20.0.bb
to use the chromium fork and renamed towayland_1.21.0.bb
and it works:# We're using the chromium version, which has some additional patches. PR:append = ".chromium0" # For chromium 111.0.5563.147 # See: https://source.chromium.org/chromium/chromium/src/+/refs/tags/111.0.5563.147:DEPS;l=1821-1825 SRCREV = "c7473676b8abc682e820546287044cee3bca9147" SRC_URI = "git://chromium.googlesource.com/external/anongit.freedesktop.org/git/wayland/wayland;protocol=git;branch=chromium_1_21_0 file://run-ptest \ file://0002-Do-not-hardcode-the-path-to-wayland-scanner.patch \ file://0001-build-Fix-strndup-detection-on-MinGW.patch \ " S = "${WORKDIR}/git"
I'm a bit surprised how this works at all though, on desktop.
@ardera
Is it still working for you? Using the Chromium Wayland fork yields this result now with '--in-process-gpu' specified:
[3255:3255:1010/040751.151609:ERROR:chrome_browser_cloud_management_controller.cc(162)] Cloud management controller initialization aborted as CBCM is not enabled.
[3255:3284:1010/040751.595094:ERROR:gles2_cmd_decoder.cc(2906)] [GroupMarkerNotSet(crbug.com/242999)!:5C56442A]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : BackFramebuffer::Create: <- error from previous GL command
[3255:3284:1010/040751.645846:ERROR:gles2_cmd_decoder.cc(2906)] [GroupMarkerNotSet(crbug.com/242999)!:5C28702A]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : BackFramebuffer::Create: <- error from previous GL command
[3255:3273:1010/040752.102771:ERROR:object_proxy.cc(590)] Failed to call method: org.freedesktop.DBus.StartServiceByName: object_path= /org/freedesktop/DBus: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
@TheNathan0 no idea, the project were we needed this is done now
Could it be a bug? It seems like it almost successfully launches, so that's progress. I suppose until I can figure out what could fix it, 109 will be the build of choice.
@TheNathan0 I'm not sure, but just from a quick look at the logs, this issue looks different. Maybe you can try with WAYLAND_DEBUG=1
(env var) and see if the wayland logs say something interesting.
In the original issue, there were some messages Bad file descriptor
or Not a socket
in that case.
I also have this exact problem! Using a Zynq Ultrascale+ and the Mali GPU is not usable with chromium 110+ :( Planned to use ElectronJS, but this is a major showstopper for us.
@FLeblanc-OTI @ensc
I’ve found a solution, but here’s a big BUT that should NOT be ignored. From my testing, you will suffer from MANY artifacts with any GL/related API stuff in Chromium. Everything using GL/WebGL/related API I’ve ran so far has been riddled with SEVERE and CONSTANT flashing and flickering as well as MANY render bugs in Chromium. Of course, I hold ZERO responsibility for what occurs. This may have been an issue before 110, if I remember correctly, but I'm not going to definitively confirm anything. I may of had this issue with 101? There appears to be MANY broken things. Does anyone know if this affects X11 contexts? I have not tried to definitively confirm anything on X11 neither do I plan to.
You will need to build this: https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.21.0/downloads/wayland-1.21.0.tar.xz
With these patches applied: 0001-Apply-WIP-CL-from-upstream-wayland.patch 0002-Set-the-default-max-buffer-size-to-unbounded.patch 0003-Log-the-object-and-methods-when-marshalling-or-sendi.patch 0004-wayland-Fix-buffer-resize-crash.patch 0005-Only-sort-types-if-they-have-size-0.patch
Then '--in-process-gpu --use-gl=egl' will work under a Wayland environment with GPU accelerated features working but be warned, with MANY bugs, render bugs, artifacts, flickering, issues, etc. I encountered some weird font rendering issues and '--enable-features=RawDraw' fixed it. Not sure if there were anything else that got fixed it and/or worsened, etc etc. All I know is that said flag fixed a font rendering issue that I had encountered.
Source: AUR Package: wayland-chromium
I've been using this solution on a device with a Mali T628 GPU and the Panfrost GPU driver. Also, semi-related note here, enabling V4L2 decoding options makes the Chromium build fail both not only on ARMV7H but also on ARM64. Could something have changed around Chromium 110 that also broke V4L2 video decoding?
@TheNathan0 Many thanks for the detailed instructions!
Warning noted :) Maybe the cause of these rendering errors are from the Panfrost GPU driver? I had the impression that opensource drivers such as lima were reverse engineered, but unsure about Panfrost. Looks like Panfrost does not support the Zynq Mali-400 GPU, I'd have to use the Lima driver... sticking to the Mali blob for now. What is the benefit of using Panfrost over the Mali driver blob?
Thankfully, my wayland version is already at version 1.21, so I'll try adding the patches (using AMD's Petalinux 2023.2).
Which chromium version are you using?
@FLeblanc-OTI, you're welcome! Panfrost is reverse engineered just like Lima. ARM did not initiate neither do they own/control the project. The support for my Mali GPU in Panfrost was done without ARM's help whatsoever. It's the oldest Mali GPU they list as supported. My device actually relies on kernel hacks to have two of its six cores disabled as otherwise the GPU becomes unusual with said open source unusable with tons of problems. I'll note, from my limited testing, it seems like desktop OpenGL and OpenGL ES apps are fine, at least, if it isn't Chromium. I should note, they aren't sophisticated apps though, so that could be why. Also, Panfrost is not a conformant driver for most of the GPUs. They officially claim to be fully conformant with OpenGL and OpenGL ES on like two GPUs.
I can't remember for sure if this issue occurred with Mali blobs or not whether it be on Wayland and/or X11. I prefer avoiding the blobs when possible due to many issues that present themselves when you try to use them. Your GPU seems to be better supported than mine.
Now, starting with some GPU model/series/etc some time ago, newer Mali GPU models that are supported in Panfrost see their support also by in part of ARM helping out the project (to my knowledge, it's like hardware documentation or something).
Lima aims to support the very small list of GPUs that they currently support. The Lima project to my knowledge never aimed to support Midgard and newer (and doesn't plan to in the future either). Panfrost aims to support Mali Midgard and newer. Lima aims to support Utgard GPUs (it looks like there's only two Utgard GPUs that they support if you look at their page on the MESA website). Both projects both rely on reverse engineered means for development but of course, Panfrost has a bit of help from ARM now these days with the newer hardware it appears (unlike the Lima driver). It was reported that ARM was/still is pretty hostile towards the Lima project as well.
I can't remember if the ANGLE backend fixed the weird issues that we currently see on the native EGL backend. I won't definitely confirm neither say anything on that. From my experience though, ANGLE results in a performance hit on these GPUs.
To answer your question about the Chromium version used regarding the solution I posted about, the solution was tested on the latest 119 from this GitHub repo.
@TheNathan0 With your patches and v119, it didn't work for the Mali-400 after all... (but glmark2-es2-wayland works)
xilinx-zcu104-20232:/home/petalinux# chromium --no-sandbox --enable-features=UseOzonePlatform --ozone-platform=wayland --in-process-gpu --enable-logging=stderr --v=0
[2590:2590:1208/181744.107472:WARNING:chrome_main_delegate.cc(660)] This is Chrome version 119.0.6045.159 (not a warning)
[2590:2590:1208/181744.221349:WARNING:policy_logger.cc(151)] :components/enterprise/browser/controller/chrome_browser_cloud_management_controller.cc(88) Could not create policy manager as CBCM is not enabled.
[2590:2590:1208/181744.323309:ERROR:policy_logger.cc(157)] :components/enterprise/browser/controller/chrome_browser_cloud_management_controller.cc(163) Cloud management controller initialization aborted as CBCM is not enabled.
[2590:2616:1208/181744.351824:ERROR:gl_display.cc(820)] Initialization of all EGL display types failed.
[2590:2616:1208/181744.351891:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
[2590:2616:1208/181744.355457:ERROR:gl_display.cc(820)] Initialization of all EGL display types failed.
[2590:2616:1208/181744.355523:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
[2590:2590:1208/181744.493772:WARNING:wayland_surface.cc(182)] Server doesn't support zcr_alpha_compositing_v1.
[2590:2590:1208/181744.493836:WARNING:wayland_surface.cc(197)] Server doesn't support overlay_prioritizer.
[2590:2590:1208/181744.493867:WARNING:wayland_surface.cc(211)] Server doesn't support surface_augmenter.
[2590:2590:1208/181744.493899:WARNING:wayland_surface.cc(226)] Server doesn't support wp_content_type_v1
[2590:2590:1208/181744.493929:WARNING:wayland_surface.cc(245)] Server doesn't support zcr_color_management_surface.
[2590:2590:1208/181744.664062:WARNING:bluez_dbus_manager.cc(247)] Floss manager not present, cannot set Floss enable/disable.
[1208/181744.798638:WARNING:exception_snapshot_linux.cc(263)] fpsimd not found
[2590:2616:1208/181744.773482:ERROR:check.cc(297)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
[2590:2616:1208/181744.815423:ERROR:gpu_channel_manager.cc(953)] Failed to create GLES3 context, fallback to GLES2.
[2590:2616:1208/181744.815473:ERROR:check.cc(297)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
[2590:2616:1208/181744.815533:ERROR:gpu_channel_manager.cc(964)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
[2590:2616:1208/181744.815574:ERROR:shared_image_stub.cc(620)] SharedImageStub: unable to create context
[2590:2616:1208/181744.815621:ERROR:gpu_channel.cc(766)] GpuChannel: Failed to create SharedImageStub
@FLeblanc-OTI You forgot "--use-gl=egl"
Your GPU doesn't support many modern instructions for ANGLE (which Chromium tries to use by default) according to those logs. To my knowledge, those who reported success with Chromium and this GPU used needed "--use-gl=egl" so that the backend was not ANGLE as it does several conversions that most likely need several instructions that your GPU doesn't have. From my understand and testing, either it's a placebo or using "--use-gl=egl" significantly improves performance.
@TheNathan0 The result is the same, it was on my test routine to try both with and without --use-gl=egl
. Thank you for your help though! :)
Oh, and about the unsupported instructions, you might have a point. Some of these warnings are also present when using v100, and the GPU acceleration works with this version (devtools shows GPU Raster ON). But there are more warnings for v119...
FYI this is the log for v100, with petalinux 2022.2:
petalinux:~# chromium --no-sandbox --enable-features=UseOzonePlatform --ozone-platform=wayland --in-process-gpu --enable-logging=stderr --v=0
[4574:4574:1212/162223.950701:WARNING:wayland_object.cc(94)] Binding to wl_output version 2 but version 3 is available.
[4574:4574:1212/162223.950973:WARNING:wayland_object.cc(94)] Binding to wl_seat version 5 but version 7 is available.
[4574:4599:1212/162224.009445:ERROR:gl_surface_egl.cc(608)] eglChooseConfig failed with error EGL_BAD_ATTRIBUTE
[4574:4599:1212/162224.015522:ERROR:gl_surface_egl.cc(608)] eglChooseConfig failed with error EGL_BAD_ATTRIBUTE
[4574:4599:1212/162224.016040:ERROR:gl_surface_egl.cc(608)] eglChooseConfig failed with error EGL_BAD_ATTRIBUTE
[4574:4589:1212/162224.120453:ERROR:login_database.cc(743)] Password store database is too new, kCurrentVersionNumber=32, GetCompatibleVersionNumber=33
[4574:4589:1212/162224.122064:ERROR:login_database_async_helper.cc(52)] Could not create/open login database.
[4574:4590:1212/162224.122032:ERROR:login_database.cc(743)] Password store database is too new, kCurrentVersionNumber=32, GetCompatibleVersionNumber=33
[4574:4590:1212/162224.122730:ERROR:login_database_async_helper.cc(52)] Could not create/open login database.
[4574:4574:1212/162224.187236:WARNING:wayland_surface.cc(118)] Server doesn't support zcr_alpha_compositing_v1.
[4574:4574:1212/162224.187321:WARNING:wayland_surface.cc(129)] Server doesn't support overlay_prioritizer.
[4574:4574:1212/162224.187354:WARNING:wayland_surface.cc(139)] Server doesn't support surface_augmenter.
[4574:4574:1212/162224.187409:WARNING:wayland_surface.cc(118)] Server doesn't support zcr_alpha_compositing_v1.
[4574:4574:1212/162224.187442:WARNING:wayland_surface.cc(129)] Server doesn't support overlay_prioritizer.
[4574:4574:1212/162224.187470:WARNING:wayland_surface.cc(139)] Server doesn't support surface_augmenter.
[4574:4574:1212/162224.189167:ERROR:cursor_loader.cc(116)] Failed to load a platform cursor of type kNull
[4574:4574:1212/162224.350971:WARNING:bluez_dbus_manager.cc(248)] Floss manager not present, cannot set Floss enable/disable.
@FLeblanc-OTI You're most certainly welcome! Have you tried "--single-process" perhaps? This could be either a Mesa or a Chromium bug.
What has been reported in this bug report might be related to what you're facing or if may be exactly about what you're facing:
Apparently X11 mode works but I think that's disabled by default when building "chromium-ozone-wayland"
Try getting some additional logs with the environment variable "EGL_LOG_LEVEL"
Here's a document by the Mesa 3D project surrounding that variable: [https://docs.mesa3d.org/egl.html](https://docs.mesa3d.org/egl.html)
It may be worth asking on the Chromium IRC and/or Lima IRC and seeing if someone has insights on this issue. I don't think blobs would help this situation either as the blobs for that GPU are pretty ancient. I'm not entirely sure if the Chromium from this repo will work without some adjusting as the blobs are so old. I think when building for those blobs you'd have to specify to not use the system's GBM. Triple buffering on the MP 400 series blobs is probably poorly implemented and/or broken with pretty extreme artifacting, flickering, etc. I don't think you'd get any modern or modern enough Wayland environment working with the blobs in ANY capacity without JeffyCN's libmali injector hook, assuming they'll work with current upstream or almost upstream Wayland and relevant components.
Have you tried building Chromium without option to use the system GBM and libdrm? That might make it work on Lima. I don't know for sure. I believe I've seen someone use old Mali blobs with or without? a libmali injector hook but had to use a different libdrm and GBM.
I got the LIMA gpu driver working with my Zynq Ultrascale+ platform! Here're my setup:
chromium --no-sandbox --enable-features=UseOzonePlatform --ozone-platform=wayland --in-process-gpu
@TheNathan0, I noticed that there are 6 patches in that Arch Linux page. I was wondering why you didn't include the 6th patch in your post above (0006-connection-avoid-calling-memcpy-on-NULL-0.patch). It's quite simple and should not cause problems...
Could it be a bug? It seems like it almost successfully launches, so that's progress. I suppose until I can figure out what could fix it, 109 will be the build of choice.
I was able to get chromium 119.0.6045.159 working with '--in-process-gpu' on Wayland on NXP IMX8MP (kirkstone) using chromium fork of wayland
chrome://gpu reports HW acceleration enabled for some items
about-gpu-2023-12-18T15-22-15-629Z.txt
Chromium logs show still some failures chromium-log.txt
I attached here the bb files and patches used. https://gist.github.com/marcostorto/7dbf5f14c3dfe748cce8578db5c6d2aa
I also added the following lines in local.conf
PREFERRED_VERSION_wayland-protocols:mx8-nxp-bsp = "1.31.imx"
PREFERRED_VERSION_wayland:mx8-nxp-bsp = "1.21.0"
I launch chromium with command switches
/usr/bin/chromium --use-gl=egl --ozone-platform=wayland --disable-features=Vulkan --in-process-gpu
I ported over the patches 0001-Fixed-chromium-flicker-with-g2d-renderer.patchand 0002-chromium-met-EGL-API-GetProcAddress-failures.patch from variscite layer https://github.com/varigit/meta-variscite-sdk-imx/tree/kirkstone/dynamic-layers/chromium-browser-layer/recipes-browser/chromium, but I'm not sure yet whether they are helpful or not
I would appreciate if somebody is able to reproduce this and suggest further steps
@FLeblanc-OTI That must've been a completed oversight with the way I listed the patches. My apologies.
I have no idea if that additional patch will improve your GPU acceleration situation however
Could it be a bug? It seems like it almost successfully launches, so that's progress. I suppose until I can figure out what could fix it, 109 will be the build of choice.
I was able to get chromium 119.0.6045.159 working with '--in-process-gpu' on Wayland on NXP IMX8MP (kirkstone) using chromium fork of wayland
chrome://gpu reports HW acceleration enabled for some items
about-gpu-2023-12-18T15-22-15-629Z.txt
Chromium logs show still some failures
I attached here the bb files and patches used.
https://gist.github.com/marcostorto/7dbf5f14c3dfe748cce8578db5c6d2aa
I also added the following lines in local.conf
PREFERRED_VERSION_wayland-protocols:mx8-nxp-bsp = "1.31.imx"
PREFERRED_VERSION_wayland:mx8-nxp-bsp = "1.21.0"
I launch chromium with command switches
/usr/bin/chromium --use-gl=egl --ozone-platform=wayland --disable-features=Vulkan --in-process-gpu
I ported over the patches 0001-Fixed-chromium-flicker-with-g2d-renderer.patchand 0002-chromium-met-EGL-API-GetProcAddress-failures.patch from variscite layer https://github.com/varigit/meta-variscite-sdk-imx/tree/kirkstone/dynamic-layers/chromium-browser-layer/recipes-browser/chromium, but I'm not sure yet whether they are helpful or not
I would appreciate if somebody is able to reproduce this and suggest further steps
I sure wonder if you do get it working would that very extreme flicker, render artifacts (and bugs) issue will also occur for you. On my hardware, using the plain Google Wayland fork alone did not resolve my issue. I had to patch Wayland 1.21 with those AUR patches but as a result, I got very extreme flickering and render artifacts (and bugs) issues with Chromium though it was fully GPU accelerated. I had to have it running with '--in-process-gpu' though.
I wonder if there was a way to (even if it causes issues/problems, it could be useful for debugging) force override blocklists and force enable options in Chromium as I noticed your situation does not permit the existing override flags to work. If it did override them and the options simply did not work, then we would see "Unavailable" beside the GPU accelerated features rather than them being listed as "Disabled" (which results from options being forced disabled).
@FLeblanc-OTI, if you are able to safely test it (you don't have to of course), did you ever get the errata I mentioned previously? Trying to determine if this is a Panfrost bug or not. From what I know and understand, it definitely is unless proven otjerwise.
@FLeblanc-OTI, if you are able to safely test it (you don't have to of course), did you ever get the errata I mentioned previously? Trying to determine if this is a Panfrost bug or not. From what I know and understand, it definitely is unless proven otjerwise.
@TheNathan0, I did not see any glitches with v119, but my tests were limited if you mean actual web browsing. More tests were done with our current app, based on ElectronJS (v24.x I think, = v112) and the rendering was great, no glitches at all. I'll try to update this thread if we encounter any problems. Our project is quite simple for now, with a simple UI, sliding menus, and the most heavy work is just 2D (I don't know which GLES draw calls are used, probably just a subset of what's available).
Someone might want to try to see if they can upstream those Wayland patches to a newer Wayland build. Maybe some extra patching might be needed as well. There might be a not so high chance that the AUR repo where I got the patches from will continue to be updated (though to my knowledge, it's still the only way to get native EGL + Wayland on Chromium).
The package that you could consider would go along with it is that Chromium Wayland + VAAPI patched package, but it's already pretty outdated and no one will be maintaining it as VAAPI + Chromium Wayland is now a thing upstream without any additional patching needed, making the AUR package useless now (and VAAPI + Wayland will most likely going to be enabled or already is enabled, at least on Arch Linux).
I have the same issue on iMX8M-Plus with chromium.
If I omit --in-process-gpu
, I can see the chromium window, but without HW accelerated GL
If I pass --in-process-gpu
, Chromium crashes.
Is there any test I can do to help fixing this behavior?
@TheNathan0 hi, When I used the 124 version of chromium (which I compiled myself), I started with these parameters and found that my GPU could not be used correctly. I don’t know if you have encountered the same problem. This is the relevant log, my startup The command is chromium-browser --enable-logging=stderr --vmodule="gpu=3" --no-sandbox --ignore-gpu-blacklist --ignore-gpu-blocklist --use-gl=egl --ozone -platform=wayland
Before that, I had been using choromium provided by ppa:saiarcot895/chromium-beta, started with the same parameters, my GPU was normal, and the version was 108 I don’t know if my friends can give me some help. Here is the relevant log.
about-gpu-2024-03-06T11-50-29-489Z.txt chromium-start-log.txt
Beginning with 2f5fe79935e1f5350f9e487625343a8f27b165d3 ("chromium: update to 110.0.5481.77") , chromium does not output anything on iMX8MM/MP anymore (pure wayland environment).
Removing
--in-process-gpu
shows the browser window again, but hardware accelerated GL is disabled."about://gpu" of last working version