Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

One of the Brave Process is consuming almost 170%-200% of CPU #18877

Closed
Im-Fran opened this issue Oct 19, 2021 · 6 comments
Closed

One of the Brave Process is consuming almost 170%-200% of CPU #18877

Im-Fran opened this issue Oct 19, 2021 · 6 comments

Comments

@Im-Fran
Copy link

Im-Fran commented Oct 19, 2021

Description

Context: I personally like to record my zoom meetings through google meet to get them directly saved on my drive so this is why I record with google meet my zoom meetings (please don't judge xD)
Actual Issue: When sharing a tab to google meet and you're on a zoom meeting the CPU usage of one of the brave processes can actually show it's using almost 170%-200% of the CPU.

Steps to Reproduce

  1. Make sure to have Hardware Acceleration Disabled
  2. Join a zoom meeting
  3. In a new tab join a google meet meeting and share the zoom meeting tab
  4. record the google meet meeting.

Actual result:

One of the brave processes is using almost 170%-200% of my CPU
image
image

Expected result:

I expect for it to use around 60%-80% because I'm recording a zoom meeting through google meet while sharing my tab

Reproduces how often:

All the times when following the steps to reproduce

Brave version (brave://version info)

Brave 1.31.87 Chromium: 95.0.4638.54 (Official Build) (x86_64)
Revision d31a821ec901f68d0d34ccdbaea45b4c86ce543e-refs/branch-heads/4638@{#871}
OS macOS Version 11.6 (Build 20G165)

Version/Channel Information:

  • Can you reproduce this issue with the current release?
    Yes
  • Can you reproduce this issue with the beta channel?
    Not Tested
  • Can you reproduce this issue with the nightly channel?
    Not Tested

Other Additional Information:

  • Does the issue resolve itself when disabling Brave Shields?
    Brave Shields are disabled because when enabled meet seems to be slowing down.
  • Does the issue resolve itself when disabling Brave Rewards?
    No
  • Is the issue reproducible on the latest version of Chrome?
    Not Tested

Miscellaneous Information:

I also had some issues with Google Meet this morning, as said by various threads on other sites is better to disable Hardware Acceleration while using google meet to increase performance and this weirdly seems to be true

@Im-Fran
Copy link
Author

Im-Fran commented Oct 19, 2021

I also want to share what I found in brave://gpu:

Graphics Feature Status

  • Canvas: Software only, hardware acceleration unavailable
  • Canvas out-of-process rasterization: Disabled
  • Compositing: Software only. Hardware acceleration disabled
  • Metal: Disabled
  • Multiple Raster Threads: Enabled
  • Out-of-process Rasterization: Disabled
  • OpenGL: Disabled
  • Rasterization: Software only. Hardware acceleration disabled
  • Skia Renderer: Enabled
  • Video Decode: Software only. Hardware acceleration disabled
  • WebGL: Software only, hardware acceleration unavailable
  • WebGL2: Software only, hardware acceleration unavailable

Problems Detected

  • Gpu compositing has been disabled, either via blocklist, about:flags or the command line. The browser will fall back to software compositing and hardware acceleration will be unavailable.
    Disabled Features: gpu_compositing

DAWN Info


    <Integrated GPU> Metal backend - Intel(R) Iris(TM) Plus Graphics 640
    [Default Toggle Names]
  • always_resolve_into_zero_level_and_layer: https://crbug.com/dawn/56: When the resolve target is a texture view that is created on the non-zero level or layer of a texture, we first resolve into a temporarily 2D texture with only one mipmap level and one array layer, and copy the result of MSAA resolve into the true resolve target. This workaround is enabled by default on the Metal drivers that have bugs when setting non-zero resolveLevel or resolveSlice.
  • lazy_clear_resource_on_first_use: https://crbug.com/dawn/145: Clears resource to zero on first usage. This initializes the resource so that no dirty bits from recycled memory is present in the new resource.
  • metal_use_shared_mode_for_counter_sample_buffer: https://crbug.com/dawn/434: The query set on Metal need to create MTLCounterSampleBuffer which storage mode must be either MTLStorageModeShared or MTLStorageModePrivate. But the private mode does not work properly on Intel platforms. The workaround is use shared mode instead.
  • metal_enable_vertex_pulling: https://crbug.com/dawn/480: Uses vertex pulling to protect out-of-bounds reads on Metal
  • disallow_unsafe_apis: http://crbug.com/1138528: Produces validation errors on API entry points or parameter combinations that aren't considered secure yet.
  • use_tint_generator: https://crbug.com/dawn/571: Use Tint instead of SPRIV-cross to generate shaders.
  • disable_r8_rg8_mipmaps: https://crbug.com/dawn/1071: Disables mipmaps for r8unorm and rg8unorm textures, which are known on some drivers to not clear correctly.
  • [WebGPU Forced Toggles - enabled]
  • disallow_spirv: https://crbug.com/1214923: Disallow usage of SPIR-V completely so that only WGSL is used for shader modules.This is useful to prevent a Chromium renderer process from successfully sendingSPIR-V code to be compiled in the GPU process.
  • [Supported Extensions]
  • texture_compression_bc
  • pipeline_statistics_query
  • depth_clamping
  • dawn-internal-usages

Version Information

Data exported 2021-10-19T20:51:16.797Z
Chrome version Chrome/95.0.4638.54
Operating system Mac OS X 11.6.0
Software rendering list URL https://chromium.googlesource.com/chromium/src/+/d31a821ec901f68d0d34ccdbaea45b4c86ce543e/gpu/config/software_rendering_list.json
Driver bug list URL https://chromium.googlesource.com/chromium/src/+/d31a821ec901f68d0d34ccdbaea45b4c86ce543e/gpu/config/gpu_driver_bug_list.json
ANGLE commit id 115fe74c8cee
2D graphics backend Skia/95 565e21c650d81ce861d0d54b0dd4fc247ad58ae6
Command Line CENSORED - idk if this is important but I'll share it if needed

Log Messages

  • [18595:259:1019/173433.296260:ERROR:gles2_cmd_decoder.cc(3613)] : ContextResult::kFatalFailure: fail_if_major_perf_caveat + swiftshader

@User198263321
Copy link

Are you having this issue? #17987

@Im-Fran
Copy link
Author

Im-Fran commented Oct 24, 2021

Nope, it doesn't crash, the main problem that concerns me is that Brave doesn't have like a "limit" for some processes because how is possible to get almost 200% of cpu usage? xD

And another issue that I know is google's fault but it maybe can be optimized on brave's side is that when you're using google meet the gpu/cpu usage increases unless you disable hardware acceleration.

@User198263321
Copy link

User198263321 commented Oct 24, 2021

Nope, it doesn't crash, the main problem that concerns me is that Brave doesn't have like a "limit" for some processes because how is possible to get almost 200% of cpu usage? xD

And another issue that I know is google's fault but it maybe can be optimized on brave's side is that when you're using google meet the gpu/cpu usage increases unless you disable hardware acceleration.

I have seen processes go over 200% in chromium browser's task manager for years. I have no idea how that works. I just use the operating system task manager.

@Im-Fran
Copy link
Author

Im-Fran commented Oct 31, 2021

Yeah, as I said my idea is adding like a limit for processes because I can barely use my mac when I record my zoom meetings through google meet.

@Im-Fran
Copy link
Author

Im-Fran commented Nov 10, 2021

I'm just gonna close it cuz I don't really think this can be fixed for now, and also I switched to safari 😛

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants