Great article, thanks for sharing! Some comments/questions below:
I have not found it necessary to add target_cpu = ["arm"] to .gclient, I'm not sure if this has any particular benefits.
Another good way of sharing files between the (build) and (pi) machines is to use sshfs. In this way, you do not need to transfer the files every time you build. You simply mount the build location when you start your Pi and the files are kept in sync.
Is there any reason you run ozone_demo with --disable-explicit-dma-fences? I have not come across this flag and have successfully run it without. Is there any particular benefit or was it just to test something?
Another useful thing to note is that the --kiosk flag works in Ozone-GBM. This removes most of the Chromium OS and browser UIs and leaves you with a clean webpage.
I have posted a crbug for the flickering/stuttering issue: crbug.com/1104165
Another bug I've found is that any keystrokes made in Chromium will also be entered into the terminal behind the scenes (see bbc/chromium #2).
--disable-explicit-dma-fences is needed to avoid DCHECK() you are also facing in bbc/chromium #5. I suspect this function CreateForGpuFence() is almost meaningless for platforms other than Android...
I'll add bbc/chromium #2 as a known problem in the article. Probably we need implement correct VT console mode handling for Ozone-GBM. A possible workaround would be to switch to an unused VT by running chvt 8 in the remote shell.
I appreciate other suggestions and comments from you, and it's great that you've already filed an issue in crbug! It would be nice if I could provide concise reproducible steps and testcases to attract more attention from upstream developers.
Thanks for your reply, some interesting stuff here.
So target_cpu = ["arm"] simply pre-installs the sysroot, makes sense.
I will have to give --disable-explicit-dma-fences a go with issue #5, thanks.
I'll let you know if I find a definitive solution to issue #2, I think your suggestion sounds like a good idea.
I am discussing the crbug with one of the minigbm developers, who suggests it may be a VC4 KMS bug. I am going to try building/running the drm-tests in hopes of determining the cause, to pass on to Chromium/RPi devs. I haven't got any 100% reproducible test cases yet, but I have posted a video with some examples: youtu.be/HAYFYRwHQE8
I've tried it out with their prebuilt image. The performance looks better than chrome I built, but the flickering issue seems to still remain, especially with the omnibox. And it won't start the desktop on RPi4 with 8GB.
I rebuilt both vc4.ko and v3d.ko using this patch from that repo, and ozone sprang to life. I should note I'm also building for 64-bit userspace via the new Ubuntu image, which provides a healthy uplift in performance. (And ostensibly fixes the 8GB limitation?)
Great article, thanks for sharing! Some comments/questions below:
I have not found it necessary to add
target_cpu = ["arm"]to.gclient, I'm not sure if this has any particular benefits.Another good way of sharing files between the
(build)and(pi)machines is to usesshfs. In this way, you do not need to transfer the files every time you build. You simply mount the build location when you start your Pi and the files are kept in sync.Is there any reason you run
ozone_demowith--disable-explicit-dma-fences? I have not come across this flag and have successfully run it without. Is there any particular benefit or was it just to test something?Another useful thing to note is that the
--kioskflag works in Ozone-GBM. This removes most of the Chromium OS and browser UIs and leaves you with a clean webpage.I have posted a crbug for the flickering/stuttering issue: crbug.com/1104165
Another bug I've found is that any keystrokes made in Chromium will also be entered into the terminal behind the scenes (see bbc/chromium #2).
Hi @ewanroycroft , thanks again for the valuable comment.
target_cpu = ["arm"]is mentioned in Linux Chromium Arm Recipes.--disable-explicit-dma-fencesis needed to avoid DCHECK() you are also facing in bbc/chromium #5. I suspect this functionCreateForGpuFence()is almost meaningless for platforms other than Android...I'll add bbc/chromium #2 as a known problem in the article. Probably we need implement correct VT console mode handling for Ozone-GBM. A possible workaround would be to switch to an unused VT by running
chvt 8in the remote shell.I appreciate other suggestions and comments from you, and it's great that you've already filed an issue in crbug! It would be nice if I could provide concise reproducible steps and testcases to attract more attention from upstream developers.
Thanks for your reply, some interesting stuff here.
So
target_cpu = ["arm"]simply pre-installs the sysroot, makes sense.I will have to give
--disable-explicit-dma-fencesa go with issue #5, thanks.I'll let you know if I find a definitive solution to issue #2, I think your suggestion sounds like a good idea.
I am discussing the crbug with one of the minigbm developers, who suggests it may be a VC4 KMS bug. I am going to try building/running the
drm-testsin hopes of determining the cause, to pass on to Chromium/RPi devs. I haven't got any 100% reproducible test cases yet, but I have posted a video with some examples: youtu.be/HAYFYRwHQE8You might want to see FydeOS people's repository:
Build your Chromium OS for Raspberry Pi 3B/3B+/4B
They have patches against kernel/mesa/minigbm fixing the flickering issue.
I've tried it out with their prebuilt image. The performance looks better than chrome I built, but the flickering issue seems to still remain, especially with the omnibox. And it won't start the desktop on RPi4 with 8GB.
I rebuilt both vc4.ko and v3d.ko using this patch from that repo, and ozone sprang to life. I should note I'm also building for 64-bit userspace via the new Ubuntu image, which provides a healthy uplift in performance. (And ostensibly fixes the 8GB limitation?)
@yaegashi
Have you ever tried running
chromewith--disable-explicit-dma-fences? Or justozone_demo?I have just run Chrome with that flag set and it no longer suffers from the stuttering bug :)