--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?)
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 :)