Change graphics card used in dual-gpu ChromeOS Flex device

[Allen Ballway]

Hi all,

I'm investigating b/298460913, which concerns a ChromeOS Flex device with an integrated Intel GPU and a discrete Nvidia GPU. With the switch to the passthrough command decoder the device started defaulting to Card0 (which is almost always the Nvidia card) rather than preferring the Intel card. This GPU is not well supported and has caused graphics and video playback glitches, with colors flashing on part or all of the screen.

1) Where is the divergence for selecting the GPU used for the passthrough command decoder vs. the validating decoder? Would it be reasonable to change that logic to match what was previously used?

2) If that logic can't be changed I will need to force Chrome to select the integrated GPU on this device. I know there's the `force_low_power_gpu` workaround, though that doesn't work on ChromeOS for now. Are there any other places where it would be reasonable to force the GPU usage?

Thanks!

Allen Ballway

He/Him

bal...@google.com

[Yuly Novikov]

I think you should be able to set ANGLE_PREFERRED_DEVICE env var to "intel" to force ANGLE to use the Intel GPU.

A permanent solution I think is to add your OS/GPU/Driver to https://source.chromium.org/chromium/chromium/src/+/main:gpu/config/gpu_driver_bug_list.json.

[Geoff Lang]

I think ANGLE_PREFERRED_DEVICE is only used by the ANGLE Metalbackend right now.

We need to look at how Chrome with the validating command decoder initialized GL/EGL to select the Intel device and make sure the same thing is done with ANGLE. In the end, for this device ANGLE is just EGL on top of EGL so we need to forward the same parameters.

Geoff

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/CAKK1iFC_oop%2BmqaBKf-M4CsBcgTTJkHXW4%3DsEjmM-spm7a7W9Q%40mail.gmail.com.

[Yuly Novikov]

On Wed, Dec 6, 2023 at 9:08 PM Geoff Lang <geof...@google.com> wrote:

I think ANGLE_PREFERRED_DEVICE is only used by the ANGLE Metalbackend right now.

I think also Vulkan?
https://source.chromium.org/chromium/chromium/src/+/main:third_party/angle/src/common/vulkan/vulkan_icd.cpp;l=96

Not sure what is the status of Vulkan backend on ChromeOS though.

You can try with --use-angle=vulkan Chrome arg. 

[Geoff Lang]

Ah, yup. Didn't see that string was duplicated in a few places.

I'd imagine the behaviour would be very different between GL and Vulkan and likely hide (and add?) bugs.

[Geoff Lang]

On ChromeOS, I think that Chrome goes through this path to select a device: GLOzoneEGLGbm::GetNativeDisplay. I'm not sure what kind of devices are selected on ANGLE, I suspect that we don't expose the platform device extensions and go down the default display path.

In ANGLE, we end up initializing the display in FunctionsEGL::initialize. There is some logic to check for various extensions and change how we initialize the display. It's possible to do the same device enumeration logic as GLOzoneEGLGbm.

On Thu, Dec 7, 2023 at 5:00 PM Allen Ballway <bal...@google.com> wrote:

A permanent solution I think is to add your OS/GPU/Driver to https://source.chromium.org/chromium/chromium/src/+/main:gpu/config/gpu_driver_bug_list.json.

I tried using force_low_power_gpu but it doesn't work for ChromeOS, are there other workaround options? Or would hooking up that workaround on ChromeOS be the solution here?

You can try with --use-angle=vulkan Chrome arg. 

 

This particular device is old enough that the GPU doesn't have Vulkan support, but because of how the reven board covers all ChromeOS Flex devices we wouldn't be able to switch to Vulkan until all of our devices support it, which won't be for several years.

We need to look at how Chrome with the validating command decoder initialized GL/EGL to select the Intel device and make sure the same thing is done with ANGLE. In the end, for this device ANGLE is just EGL on top of EGL so we need to forward the same parameters.

Where does this logic happen? 

Thanks,

Allen Ballway

He/Him

bal...@google.com

[Allen Ballway]

A permanent solution I think is to add your OS/GPU/Driver to https://source.chromium.org/chromium/chromium/src/+/main:gpu/config/gpu_driver_bug_list.json.

I tried using force_low_power_gpu but it doesn't work for ChromeOS, are there other workaround options? Or would hooking up that workaround on ChromeOS be the solution here?

You can try with --use-angle=vulkan Chrome arg. 

 

This particular device is old enough that the GPU doesn't have Vulkan support, but because of how the reven board covers all ChromeOS Flex devices we wouldn't be able to switch to Vulkan until all of our devices support it, which won't be for several years.

We need to look at how Chrome with the validating command decoder initialized GL/EGL to select the Intel device and make sure the same thing is done with ANGLE. In the end, for this device ANGLE is just EGL on top of EGL so we need to forward the same parameters.

Where does this logic happen? 

Thanks,

Allen Ballway

He/Him

bal...@google.com

On Thu, Dec 7, 2023 at 11:54 AM Geoff Lang <geof...@google.com> wrote:

[Geoff Lang]

You can try hard-coding platformType to EGL_PLATFORM_SURFACELESS_MESA in ANGLE to confirm that it fixes things. To wire it up from Chrome, it's passed to ANGLE as the EGL_PLATFORM_ANGLE_NATIVE_PLATFORM_TYPE_ANGLE parameter for display creation. There is an example where it's used here: https://source.chromium.org/chromium/chromium/src/+/main:ui/gl/gl_display.cc;l=376-381;drc=2fefec3ffe696781714d9fca4f3a3647127956cf

Geoff

On Thu, Jan 11, 2024 at 2:47 PM Allen Ballway <bal...@google.com> wrote:

From what I can tell, in Chrome we have the b_EGL_MESA_platform_surfaceless extension so we call eglGetPlatformDisplay. In ANGLE the platformType in FunctionsEGL::initialize isn't surfaceless so we just call eglGetDisplay rather than eglGetPlatformDisplay with EGL_PLATFORM_SURFACELESS_MESA. I'm having a hard time finding where the platformType is set. To change the display selection to be surfaceless would I need to change how ANGLE is started in Chrome or would I need to make these changes inside ANGLE?

Thanks,

Allen Ballway

He/Him

bal...@google.com

[Allen Ballway]

From what I can tell, in Chrome we have the b_EGL_MESA_platform_surfaceless extension so we call eglGetPlatformDisplay. In ANGLE the platformType in FunctionsEGL::initialize isn't surfaceless so we just call eglGetDisplay rather than eglGetPlatformDisplay with EGL_PLATFORM_SURFACELESS_MESA. I'm having a hard time finding where the platformType is set. To change the display selection to be surfaceless would I need to change how ANGLE is started in Chrome or would I need to make these changes inside ANGLE?

Thanks,

Allen Ballway

He/Him

bal...@google.com

[Allen Ballway]

Unfortunately that doesn't seem to work. Hardcoding it in ANGLE and calling eglGetPlatformDipslay instead doesn't make a difference, and adding the extra_display_attrib crashes the process. The display type is ANGLE_OPENGL, I'm not sure if that makes a difference.

I also noticed that gpu_info_collector_linux.cc is called and says that the Nvidia GPU is active before I see any logs coming from ANGLE and the result and timestamp don't match the call I see logging from SystemInfo_linux.cpp. I'm not sure how that's happening but it makes me wonder if there's some other ANGLE source that's doing initialization separate from my local change, which is still being called because I see the logs later.

Allen Ballway

He/Him

bal...@google.com