-
-
Notifications
You must be signed in to change notification settings - Fork 567
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
Advanced OpenGL apps may cause graphical glitches and/or GPU hangs #158
Comments
This comment has been minimized.
This comment has been minimized.
ANGLE is for WebGL. Nothing to do with Chrome itself glitching out. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Talking about that workaround... I just realised something: |
This comment was marked as spam.
This comment was marked as spam.
(The VTable hack has to do with HWAlignManager used inside it for calculations) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@VisualEhrmanntraut Do you have any predictions if we can have any solution for chrome-based browsers natively in the future? |
New prediction available: No prediction available. |
This comment was marked as off-topic.
This comment was marked as off-topic.
DOSBOX's OpenGL freezes the system immediately, looking into what triggers it since it's a fast and reliable crash. Config field is |
Chrome seems to die due to a command sent by libGLES2. Relevant log attached. (This is an Electron app, therefore uses Chromium) |
Also I found that in |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The situation has been improved with the latest commits. For instance, Firefox now works, and things like Chrome don't instantly kill the system anymore for some that it did. Verified by my internal quality control group. Here's a few screenshots: Note that there's also some other misc changes in the build they're using, but I think those aren't related. |
This comment was marked as off-topic.
This comment was marked as off-topic.
You ran something, it corrupted the VRAM, and now stuff looks like this. |
So the latest artifact that I'm fetching from GitHub has those recent changes in it? I still have glitches on chromium based apps with it, but I'm not really sure if that version already includes those changes |
Never said anything about glitches being fixed. |
I thought this meant apps shouldn't glitch out the entire screen; the OS isn't crashing, but the entire screen gets broken once I launch Chrome-based apps |
That would mean the issue is fixed, so the issue would not be open anymore. The things I listed is what seemed to be fixed in the testing. There were also reports of other issues be fixed after the changes were added, like black screens and other instabilities. |
Also I was having problem with nextflix/crunchroll/amazon on safari based browsers where the media even started (gives black screen or a page error), but now in firefox works perfectly and not problems so far. I think this may be related to DRM compatibility, apparently, with the last updates the OpenGL is using better the DRM infrastructure Thanks for the update! I'm using Sonoma 14.3.1 (23D60) on a R7 5700G with iGPU 2GB VRAM dedicated |
Safari uses hardware DRM, which isn't implemented here. Firefox uses software DRM. |
This comment was marked as off-topic.
This comment was marked as off-topic.
nope |
Hello! Just to add to this topic in case anyone comes from google with the same issue: TL; DR: I had 512 VRAM for the iGPU (5700G) and after setting it to at least 3GB I could at least log in without issues to close the apps. I had Chrome opened with roughly 5 or 6 tabs and vscode with just the init screen. After powering off the system with the "open all apps as they were before" checked if I restarted the system it would do the following:
Hope this helps someone (and yeah, I know the docs already mentioned that it was better to have 1GB+ for VRAM but I just couldn't find it in the BIOS until I searched for a freaking video as it was kind of obfuscated within the BIOS) |
Just create a pendrive with WhateverGreen (make sure NootedRed is either disabled or removed completely) and disable "Use graphics acceleration when available" in Settings > System of chrome. I know this will offload all the work from GPU to CPU but you'll be able to browse at least. After that you can just simply boot from your Mac's EFI. Nonetheless, we need a solution for this as if I talk about my R3 2200G with only iGPU in place, it snatches a lot of performance that could possibly have been spent elsewhere usefully. |
ugh, how many times will I have to say that WhateverGreen is useless if you don't have a native macOS GPU... |
the UN should make "modern macOS must be run with 3D accel working" an international law. |
at least use Firefox... so much better than Google's crap and also works pretty much flawlessly with the latest NootedRed |
yep you beat me to it lol. edited at the same time you posted. and I agree wholeheartedly. |
GPU hangs in open a gitlab repository in firefox... |
Advanced OpenGL software, like Chrome, may have artefacts or freeze the system.
To Reproduce
Expected behavior
The software working perfectly fine.
Screenshots
System Information:
N/A; Happens on all ASIC types and macOS versions.
Additional context
Metal software all work fine. It is likely a bug in the OpenGL library.
The text was updated successfully, but these errors were encountered: