Re: [chromium-dev] Wrong GL_VENDOR & GL_RENDERER after build and GPU acceleration issues after build.

[Ken Russell]

chromium-dev -> bcc

+graphics-dev 

Hi Denis,

Chromium's changed over to using ANGLE and the "passthrough" command decoder for the graphics and WebGL remoting protocol on macOS. This is under a 50/50 experiment in Google Chrome Canary. If it's not working correctly for some webpages then please file bugs on crbug.com; if you can't cc: me then please email me the bug IDs.

You can launch Chromium from the command line with the argument --use-cmd-decoder=validating (the default is passthrough now) to restore the old behavior.

-Ken

On Wed, Dec 23, 2020 at 6:59 PM Denis Popov <akad...@gmail.com> wrote:

Hello. I'm building Chromium on macOS (Catalina 10.15.7) according to the instructions (https://chromium.googlesource.com/chromium/src/+/master/docs/mac_build_instructions.md).

The project compiles successfully. But the resulting binary has problems with GPU. Some web pages render strange black rectangles.

When viewing information about the GPU (chrome://gpu), the output is:

Driver vendor ANGLE

Driver version 2.1.14248

GL_RENDERER ANGLE (ATI Technologies Inc., AMD Radeon Pro 570 OpenGL Engine, OpenGL 4.1 core)

GL_VERSION OpenGL ES 2.0.0 (ANGLE 2.1.14248 git hash: f46e6201b40b).

If I run Google Chrome or Chromium binaries (downloaded from: https://download-chromium.appspot.com/) everything works fine, and also the GPU page displays:

Driver vendor ATI

Driver version 3.10.19

GL_RENDERER AMD Radeon Pro 570 OpenGL Engine

GL_VERSION 4.1 ATI-3.10.19.

Chromium versions is absolutely identical.

I can't figure out why my build chooses a different driver (Angle) for hardware acceleration.

If someone faced a similar problem, please tell me how to fix it?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/03077d4d-7e62-433c-8686-ef274bc8b0ddn%40chromium.org.

[Денис Попов]

Indeed with the --use-cmd-decoder=validating argument, the native driver is selected (ATI in my case).

But it doesn't solve the problem with rendering artifacts (black rectangles still remain on the pages). I was wrong that the cause is ANGLE. Apparently the problem is somewhere else. 

I will try to test this for different versions of Chromium soon (I was building version 89.0.4325.0). I will also try to create a test html page with this bug and describe it on crbug.com.

Thank you for reply!

четверг, 24 декабря 2020 г. в 09:28:03 UTC+3, Kenneth Russell:

[Yuly Novikov]

Try --use-gl=desktop

[Денис Попов]

Yes, I tried --use-gl=desktop argument. This disables hardware acceleration completely. 

chrome://gpu output:

Graphics Feature Status

Canvas: Software only, hardware acceleration unavailable

Compositing: Software only. Hardware acceleration disabled

Metal: Disabled

Multiple Raster Threads: Enabled

Out-of-process Rasterization: Unavailable

OpenGL: Unavailable

Hardware Protected Video Decode: Unavailable

Rasterization: Unavailable

Skia Renderer: Disabled

Video Decode: Unavailable

WebGL: Unavailable

WebGL2: Unavailable

This fixes the rendering problem (black rectangles), but the page rendering itself becomes slow (CPU). 

пятница, 25 декабря 2020 г. в 00:14:07 UTC+3, ynov...@chromium.org:

[Andres Calderon Jaramillo]

When using hardware acceleration, is the Skia Renderer enabled (in chrome://gpu)?

[Денис Попов]

Skia Renderer: Disabled (with or without arg --use-cmd-decoder=validating)

Graphics Feature Status

Canvas: Hardware accelerated

Compositing: Hardware accelerated

Metal: Disabled

Multiple Raster Threads: Enabled

Out-of-process Rasterization: Hardware accelerated

OpenGL: Enabled

Hardware Protected Video Decode: Unavailable

Rasterization: Hardware accelerated

Skia Renderer: Disabled

Video Decode: Hardware accelerated

WebGL: Hardware accelerated

WebGL2: Hardware accelerated

пятница, 25 декабря 2020 г. в 01:17:15 UTC+3, andr...@chromium.org:

[Andres Calderon Jaramillo]

Hmm, does it make any difference on the artifacts if it's enabled by starting Chrome with --enable-features=UseSkiaRenderer (check chrome://gpu after adding this flag to make sure it is in fact used)?

[Денис Попов]

Yes, there is a difference in rendering when using Skia. No black rectangles, but other artifacts appear when scrolling the page. 

Unfortunately, I haven't had time yet to prepare a small clean page to reproduce the error. 

But I did happen to find a page where you can see this error. I've attached three short videos where you can see these rendering artifacts on this web page https://www.artlebedev.ru/r-pharm/.

The first video is a reference rendering of the downloaded release 89.0.4325.0 from https://github.com/macchrome/chromium/releases/tag/v89.0.4325.0-r827558-macOS

For my build 89.0.4325.0 version, I used these arguments 

https://github.com/macchrome/chromium/blob/v89.0.4325.0-r827558-macOS/args.nosync.gn.txt

The second video is a rendering of my build running with --use-cmd-decoder=validating (without the same result)

The third video is a rendering of my build running with --enable-features=UseSkiaRenderer

пятница, 25 декабря 2020 г. в 01:33:19 UTC+3, andr...@chromium.org:

[Andres Calderon Jaramillo]

Interesting. The artifacts happen only on top of the animations which are actually <video> elements. Additionally, these elements have a "poster" attribute set (not sure what difference this makes). For the SkiaRenderer case, it's almost as if the poster image stays behind the video somehow.

Just to rule out another problem: can you check if disabling video decode acceleration makes a difference (chrome://flags/#disable-accelerated-video-decode)? I know that there were some recent changes to the video stack for Chromium/Mac.

[Денис Попов]

Yes, it seems to be with SkiaRenderer on that page videobox scrolling faster than it should be (with the Chromium reference build or Google Chrome this does not happen). The image in <video poster="..."> attribute scrolls at normal speed and seems to become visible from behind the video. 

I toggle flag (chrome://flags/#disable-accelerated-video-decode) and it has no effect on rendering in my case.

Either black rectangles on top of video with default renderer, or weird scrolling effects with SkiaRenderer.

One thing I can't understand: build which I download from https://chromium.woolyss.com/#mac (download link https://github.com/macchrome/chromium/releases/download/v89.0.4325.0-r827558-macOS/Chromium.89.0.4325.0.sync.app.zip) having the same version of Chromium doesn't have these problems with rendering. Although I am compiling the project with the same args.gn. I even thought there might be a problem with my environment and installed a clean macOS Catalina in a virtual machine and compile Chromium inside the virtual machine. But the result is the same...

Anyway, I'll try to check it by building different branches/versions of Chromium and also try to prepare a page to reproduce these bugs.

пятница, 25 декабря 2020 г. в 03:09:47 UTC+3, andr...@chromium.org:

[Andres Calderon Jaramillo]

I find it strange that your build has a "Variations:" section in chrome://about whereas woolyss' build doesn't. This is a list of experiments in effect. I wouldn't have expected a local Chromium build to fetch experiments. Can you email me this "Variations:" list to andr...@chromium.org to see if I find a suspicious experiment?

Also, can you try starting your build with --user-data-dir=<some folder> where <some folder> is a new folder you create so that it's separate from the path used by woolyss' Chromium?

[Andres Calderon Jaramillo]

Thanks for emailing me the variations! The only suspicious experiments I saw were:

1) The passthrough command decoder (but you already tried disabling this).

2) Some "compositing optimizations". I'm not familiar with these, but you can try disabling them with --disable-features=CompositingOptimizations

3) "UsePreferredIntervalForVideo"; I'm also not familiar with this and it seems like a stretch, but you can also try disabling this with --disable-features=UsePreferredIntervalForVideo

Let me know if disabling any of these works. You can also disable multiple features simultaneously by using a comma-separated list, e.g., --disable-features=CompositingOptimizations,UsePreferredIntervalForVideo

[Денис Попов]

I tried these arguments, but unfortunately they had no effect on the rendering. Neither individually, nor all together. 

But I'm more and more convinced that my problem is related to the versions of Xcode, macOS SDK & command line tools. 

I have successfully built Chromium versions 84, 86, 88 with Xcode 11.4.1 (+ command line tools 11.4.1) & macOS SDK 10.15 and all those builds don't have this rendering problem!

I'm currently building the revision that originally compared (v89.0.4325.0-r827558-macOS 8f60186caac1450314698d57b9cb859ecd748fd6-refs/heads/master@{#827558}).

I'm moving steadily and want to find out a clear boundary of versions of Xcode on which this problem occurs.  As soon as I'm sure, I will definitely post here and also create issue on crbug.com if necessary.

Thanks for your advice and help!

понедельник, 28 декабря 2020 г. в 01:54:03 UTC+3, andr...@chromium.org:

[Andres Calderon Jaramillo]

Sounds good! Thanks for trying those flags.

Let us know if the development environment is the culprit. I don't have a Mac but I'm curious if anyone has had a similar problem.

CCing ccameron@ who works on Chrome for Mac.