Chromium is not accelerated ( webgl not activated )

Technical Support
, ,
1

Hello all,
I want to evaluate the colibri-imx8x capabilities with chromium , for an application which use webgl ( check GPU support ) and video playback ( check VPU support ) and after some tests, it seems that the chromium version inside the official torizon core 5.1.0 image is not GPU-VPU accelerated.

I have just installed with toradex easy installer the version : TorizonCore 5.1.0 with evaluation containers for V1.0C HW ( 5.1.0+build.1.container ( 2021-01-06 )

I tried to launch chromium with 2 ways :

  • First, I created a container with the portainer portal based on the app template “chromium” and launch my webapp
  • Second, I tried to launch manually chromium by following this link : Web Browser / Kiosk Mode with TorizonCore | Toradex Developer Center and launch like this :
    docker run -d --rm -v /tmp:/tmp -v /dev/dri:/dev/dri -v /var/run/dbus:/var/run/dbus --device-cgroup-rule='c 226:* rmw' --shm-size="256m" --security-opt="seccomp=unconfined" --name kiosk\ torizon/kiosk-mode-browser:$CT_TAG_KIOSK_MODE_BROWSER --virtual-keyboard https://mywebapp

But in both case, the GPU and VPU acceleration seems not activated.

For GPU , I tried on colibri-imx8X the following URLs :

For VPU, I tried to read a video :

My question is : How to activate GPU and VPU hw acceleration on torizon core 5.1.0 ? Is it available or do I have to recompile chromium with acceleration ? If so, I prefer work on tdx-reference-multimedia-image ,torizon core was just for me to evaluate web capabilities of colibri-imx8x

Thanks a lot for your help.

2

Greetings @f.mazur,

I answered this a bit on your original thread before I saw this one so let me copy/paste my response here:

Actually I can comment on the chromium acceleration issue here.

First of all, we are aware of this limitation. We’ve had some difficulty in trying to get hardware acceleration with chromium on all of our hardware platforms. This has been more difficult on the newer hardware such as the i.MX8X. I don’t have anything to share but we are still working on this.

As a follow-up is it a hard-requirement for you to be using specifically chromium, or will any web-browser suffice as long as it’s hardware accelerated?

Best Regards,
Jeremias

3

Hello @jeremias.tx ,

Thank you for your answer.

Ok, so I wonder that it is useless for me to try to generate chromium from my own ( by using GitHub - OSSystems/meta-browser: OpenEmbedded/Yocto BSP layer for Web Browsers ) , I should have the same result.

It is not mandatory for me to have chromium as a GPU-accelerated browser. This could be another, such as firefox or a qt application instanciating qtwebengine , or anything else. For qtwebengine, I had some difficulties to generate qtwebengine-example , and qtwebengine has its engine based on a specific version of chromium, I guess that it should be not accelerated too.

(apart : )
Currently I am generating meta-browser from https:/github.com/OSSystems/meta-browser ( master branch because dunfell branch does not exist ), and just a remark : for the moment , this is not possible to generate on debian 9 64 bits, because “gn” dependancy of chromium - which is built with ninja / clang++ - doen’t compile. I discover that ninja+ “clang++” uses headers that are included in host , on debian 9 libc++ is not fully compatible with c++17 , and the include fails because the file /usr/include/c++/6/string_view does not exist ( I confirm this by creating an empty file “string_view” inside this directory, and the error message was different ). On debian 10 , the host c++ version is 8 , and the file /usr/include/c++/8/string_view exists, and now recipy gn-native compiles.

I don’t know why the build generation engine uses host headers and not built-in headers, I thought it would generate errors inside yocto build as “host contamination”, but it is not the case.

If the build succeed, I will test if chromium is already accelerated or not ( I hope :stuck_out_tongue: ) , if not, the meta-browser has also a recipy to build firefox, I will try this next.

For the browser, what is my goal : I have 3 proprieraty webapps to evaluate :

  • 2 of them are using only webgl , so just GPU acceleration is needed. Chormium / Firefox/ Qtwebengine based, all of this is acceptable.
  • the third one is a VOD application, so we have to be able to read h264 ( or VP9 ) content , fullhd max ( the 4k version will be evaluated with apalix IMX8M , because we are not able to display on a 4K output with colibri imx8x) . We don’t know at this time if we will use a browser to play videos, or an application which use gstreamer as a standalone player, or third possibilité, a qt application with gstreamer bindings.
4

Hi, I use chromium-ozone-wayland from meta-browser master branch on iMX8QXP and hardware acceleration is enabled (checked from chrome://gpu) so it should definitely be possible. I don’t use torizon though, maybe they have some startup flag missing.

5

Hi,

Thank you for the answer.

I am currently building chromium from meta-browser ( the one on O.S. Systems Software LTDA. · GitHub , branch master , the only available for dunfell ). The build is not finished, I wait for the result ^^

Do you have used the same version ? Without modification of the meta ? just add to local.conf IMAGE_INSTALL_append = " chromium-ozone-wayland" ?

6

Hi, yes just like that, no modifications.

I just had to disable g2d from weston.ini (use-g2d) as it was on by default. Then launch chromium with flag --in-process-gpu and maybe some additional flags, depending what you need, like --enable-accelerated-video-decode

7

thank you for the information.

At last, the build has finished successfully, and I am now able to deploy chromium on the target.

Unfortunately, the gpu seems not be used ( and neither the vpu ). If I go to chrome://gpu I see the webgl 1&2 hw accelerated, but if I run any webgl sample, it works bad ( poor fps ) , probably it is not using the hw acceleration

8

Let me know if you make any progress with the chromium method that Stuo is using. I’d be interested to know the process needed.

As for alternatives, perhaps you can try WPE/Cog: GitHub - Igalia/cog: WPE launcher and webapp container
It should be provided in yocto via “meta-webkit”. I’ve done some testing on this and the results seem better out of the box than chromium.

On i.MX8 I was able to get cog working with what seemed like GPU acceleration. As a side note I had to build cog since the latest release requires a fix to work properly on i.MX8. Namely this commit: platform: add a common EGL proc address loader with dlsym fallback · Igalia/cog@f5c32a0 · GitHub

Also I’ve yet to get VPU working properly with Cog though from what I hear it can work depending on what version of the gstreamer libraries from NXP are used. As in the newer libraries don’t have proper support yet but apparently the older libraries have been known to work.

Again none of this is official yet, just some testing I’ve done on the side, but just wanted to give you some alternatives.

Best Regards,
Jeremias

9

Here is the result of chrome://gpu on my target :

Graphics Feature Status
Canvas: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Disabled
OpenGL: Enabled
Hardware Protected Video Decode: Unavailable
Rasterization: Software only. Hardware acceleration disabled
Skia Renderer: Enabled
Video Decode: Software only. Hardware acceleration disabled
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
Driver Bug Workarounds
clear_uniforms_before_first_program_use
exit_on_context_lost
scalarize_vec_and_mat_constructor_args
disabled_extension_GL_KHR_blend_equation_advanced
disabled_extension_GL_KHR_blend_equation_advanced_coherent
Problems Detected
Protected video decoding with swap chain is for certain Intel and AMD GPUs on Windows: 1093625
Disabled Features: protected_video_decode
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Some drivers can't recover after OUT_OF_MEM and context lost: 893177
Applied Workarounds: exit_on_context_lost
Accelerated video decode has been disabled, either via blocklist, about:flags or the command line.
Disabled Features: video_decode
Version Information
Data exported	2020-02-07T15:55:09.508Z
Chrome version	Chrome/87.0.4280.141
Operating system	Linux 5.4.77-5.1.0-devel+git.a2f08dfd79ae
Software rendering list URL	https://chromium.googlesource.com/chromium/src/+/9f05d1d9ee7483a73e9fe91ddcb8274ebcec9d7f/gpu/config/software_rendering_list.json
Driver bug list URL	https://chromium.googlesource.com/chromium/src/+/9f05d1d9ee7483a73e9fe91ddcb8274ebcec9d7f/gpu/config/gpu_driver_bug_list.json
ANGLE commit id	unknown hash
2D graphics backend	Skia/87 73c703c2bdbde9a7602bc017f08376bfb4c79f33
Command Line	/usr/bin/chromium --use-gl=egl --ozone-platform=wayland --no-sandbox --in-process-gpu --flag-switches-begin --flag-switches-end --gpu-preferences=OAAAAAAAAAAoAAAQAAAAAAAAAAAAAAAAAABgAAAAAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAABQAAACgAAAAAAAAAMAAAAAAAAAA4AAAAAAAAAEAAAAAAAAAASAAAAAAAAAAQAAAAAAAAAAAAAAADAAAAEAAAAAAAAAAAAAAADAAAABAAAAAAAAAAAgAAAA0AAAAQAAAAAAAAAAcAAAAMAAAAEAAAAAAAAAAHAAAADQAAAA== --use-gl=egl
Driver Information
Initialization time	0
In-process GPU	true
Passthrough Command Decoder	false
Sandboxed	false
GPU0	VENDOR= 0x0000 [Vivante Corporation], DEVICE=0x0000 [Vivante GC7000L] *ACTIVE*
Optimus	false
AMD switchable	false
Driver vendor	
Driver version	6.4.0.p2.234062
GPU CUDA compute capability major version	0
Pixel shader version	3.10
Vertex shader version	3.10
Max. MSAA samples	4
Machine model name	
Machine model version	
GL_VENDOR	Vivante Corporation
GL_RENDERER	Vivante GC7000L
GL_VERSION	OpenGL ES 3.1 V6.4.0.p2.234062
GL_EXTENSIONS	GL_OES_vertex_type_10_10_10_2 GL_OES_vertex_half_float GL_OES_element_index_uint GL_OES_mapbuffer GL_OES_vertex_array_object GL_OES_compressed_ETC1_RGB8_texture GL_OES_compressed_paletted_texture GL_OES_texture_npot GL_OES_rgb8_rgba8 GL_OES_depth_texture GL_OES_depth_texture_cube_map GL_OES_depth24 GL_OES_depth32 GL_OES_packed_depth_stencil GL_OES_fbo_render_mipmap GL_OES_get_program_binary GL_OES_fragment_precision_high GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_EGL_sync GL_OES_texture_stencil8 GL_OES_shader_image_atomic GL_OES_texture_storage_multisample_2d_array GL_OES_required_internalformat GL_OES_surfaceless_context GL_OES_copy_image GL_OES_draw_buffers_indexed GL_OES_texture_border_clamp GL_OES_texture_buffer GL_OES_texture_cube_map_array GL_OES_draw_elements_base_vertex GL_OES_texture_half_float GL_OES_texture_float GL_KHR_blend_equation_advanced GL_KHR_debug GL_KHR_robustness GL_KHR_robust_buffer_access_behavior GL_EXT_texture_type_2_10_10_10_REV GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888 GL_EXT_texture_compression_s3tc GL_EXT_read_format_bgra GL_EXT_multi_draw_arrays GL_EXT_frag_depth GL_EXT_discard_framebuffer GL_EXT_blend_minmax GL_EXT_multisampled_render_to_texture GL_EXT_color_buffer_half_float GL_EXT_color_buffer_float GL_EXT_robustness GL_EXT_texture_sRGB_decode GL_EXT_draw_buffers_indexed GL_EXT_texture_border_clamp GL_EXT_texture_buffer GL_EXT_copy_image GL_EXT_texture_cube_map_array GL_EXT_multi_draw_indirect GL_EXT_draw_elements_base_vertex GL_EXT_texture_rg GL_EXT_protected_textures GL_EXT_sRGB
Disabled Extensions	GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent
Disabled WebGL Extensions	
Window system binding vendor	Vivante Corporation
Window system binding version	1.5
Window system binding extensions	EGL_KHR_fence_sync EGL_KHR_reusable_sync EGL_KHR_wait_sync EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_lock_surface EGL_KHR_create_context EGL_KHR_no_config_context EGL_KHR_surfaceless_context EGL_KHR_get_all_proc_addresses EGL_EXT_create_context_robustness EGL_EXT_protected_surface EGL_EXT_protected_content EGL_EXT_buffer_age EGL_ANDROID_native_fence_sync EGL_WL_bind_wayland_display EGL_WL_create_wayland_buffer_from_image EGL_KHR_partial_update EGL_EXT_swap_buffers_with_damage EGL_KHR_swap_buffers_with_damage
Direct rendering version	unknown
Reset notification strategy	0x8252
GPU process crash count	0
gfx::BufferFormats supported for allocation and texturing	R_8: not supported, R_16: not supported, RG_88: not supported, BGR_565: not supported, RGBA_4444: not supported, RGBX_8888: not supported, RGBA_8888: not supported, BGRX_8888: not supported, BGRA_1010102: not supported, RGBA_1010102: not supported, BGRA_8888: not supported, RGBA_F16: not supported, YVU_420: not supported, YUV_420_BIPLANAR: not supported, P010: not supported
Compositor Information
Tile Update Mode	One-copy
Partial Raster	Enabled
GpuMemoryBuffers Status
R_8	CAMERA_AND_CPU_READ_WRITE
R_16	Software only
RG_88	Software only
BGR_565	GPU_READ
RGBA_4444	Software only
RGBX_8888	GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE
RGBA_8888	GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE
BGRX_8888	GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE
BGRA_1010102	Software only
RGBA_1010102	Software only
BGRA_8888	GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE
RGBA_F16	Software only
YVU_420	GPU_READ, SCANOUT_VEA_READ_CAMERA_AND_CPU_READ_WRITE
YUV_420_BIPLANAR	SCANOUT_CAMERA_READ_WRITE, SCANOUT_VEA_READ_CAMERA_AND_CPU_READ_WRITE
P010	Software only
Display(s) Information
Info	Display[19] bounds=[0,0 480x800], workarea=[0,0 480x800], scale=1, rotation=0, panel_rotation=0 external.
Color space (all)	{primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL}
Buffer format (all)	RGBA_8888
SDR white level in nits	100
Bits per color component	8
Bits per pixel	24
Video Acceleration Information
Vulkan Information
Device Performance Information

if I don’t put use_g2d to 0 in weston.ini, the windows is not created.
If I don’ put --in-process-gpu , the windows is not created with the following error message :
root@colibri-imx8x:~# chromium --no-sandbox
EGL: Warning: No default display support on wayland
[697:697:0207/155443.895216:ERROR:gl_surface_egl.cc(1297)] EGL display query failed with error EGL_SUCCESS
[697:697:0207/155443.904188:ERROR:gl_surface_egl.cc(1322)] eglInitialize Default failed with error EGL_BAD_DISPLAY
[697:697:0207/155443.907989:ERROR:gl_ozone_egl.cc(20)] GLSurfaceEGL::InitializeOneOff failed.

I’m stuck at this point. I guess I have to patch chromium to enable correctly GPU acceleration, but it is out of my skills.

10

Hello @jeremias.tx ,

Thank you for your alternative, I will try this :slight_smile:

Maybe I have to ask NXP to know exactly what would be officialy supported ?

For hw video acceleration, only gstreamer with the required sink ?
for webgl acceleration, no official support ?

Edit : my other answer has been removed. Was it too long ? ( I have done a copy paste of the result of chrome:/gpu )

11

Hello @jeremias.tx ,

I was able to generate webkit ( meta-webkit branch dunfell , so version 2.30.4 )

and I have build cog from git ( branch master ) with SDK generated for my yocto build.
It seems to be cog 0.7.1+git-9f1d504-dirty version

I have deployed cog on my platform and I have some weird results.

First, I have to put use-g2d=0 in weston.ini ( or I have some artifacts with the cursor )
Second, I need to create a link libWPEbackend-default.so → libWPEBackend-fd0-1.0.so
Next, I need to launch with the option -P fdo ( I don’t know the difference between fdo and rdk , i found this link : Supported Hardware IMX8M supported and choose FDO. I use IMX8X and not IMX8M , this is make a difference ? )
When I launch my app, it is in fullscreen , and I don’t see all the app ( my display is 800x480, maybe it is the cause, I cannot choose the wxh )

And the performances are not so good, some webgl bench link seems working well, some other not. When I launch my webgl app, I have this message :

Cog-Core-Message: 13:09:46.784: <http://172.17.67.67/fp3d-webapp> Load started.
Cog-Core-Message: 13:09:46.791: <http://172.17.67.67/fp3d-webapp/> Redirected.
Cog-Core-Message: 13:09:46.799: <http://172.17.67.67/fp3d-webapp/> Loading...
Cog-Core-Message: 13:09:53.803: <http://172.17.67.67/fp3d-webapp/> Loaded successfully.
error marshalling arguments for create_buffer: dup failed: Too many open files
Error marshalling request: Too many open files

If I check /proc/pid/fd , I have thousand files opened to dmaBuffer like this :

lrwx------ 1 root root 64 Jan 27 12:41 990 -> /dmabuf:
lrwx------ 1 root root 64 Jan 27 12:41 991 -> /dmabuf:
lrwx------ 1 root root 64 Jan 27 12:41 992 -> /dmabuf:
lrwx------ 1 root root 64 Jan 27 12:41 993 -> /dmabuf:

My webgl app did not launch and after, cog crashes sometimes.

12

Huh well I don’t have much to add to this, except that these are interesting results.

I will say my tests with Cog were with version 0.8 of it (including the commit I mentioned). But yes unfortunately we too at Toradex are still working on proper browser support, as well as relying a bit on the various browser maintainers.

For the time being I think cog is closest to have proper hw support for the i.MX8 but we’ll have to see as developments progress.

Best Regards,
Jeremias

13

Hello,

Is there any update on this ? Is there a work around for Chromium to support hardware acceleration on imx8x ?

Thank you.

14

Hi @djjoyro,

For the time being hardware acceleration with Chromium for the i.MX8* SoCs has been put on pause. Currently we offer the Cog browser as an alternative browser that does leverage the GPU see here for more details: Web Browser / Kiosk Mode with TorizonCore | Toradex Developer Center

We may or may not follow-up with hardware support on Chromium but for the time being it’s on hold.

Is there a reason you require Chromium? Or is Cog a suitable alternative for you?

Best Regards,
Jeremias

15

Thank you for your fast response, We will try cog, I think it will be ok if it supports hardware acceleration.

Regards,
Ionica.

16

That’s good to hear, if you encounter any issues with using Cog please open a new technical support post in the future.

Best Regards,
Jeremias