Disable Intel Fastclear in GL Backend

[zicklag]

This works around a Mesa bug on Intel cards:

• https://gitlab.freedesktop.org/mesa/mesa/-/issues/2565
• Fastclear Bug With Intel Mesa Adapters on the GL Backend #1627 (comment)

Connections
Related to pixelated edges in GL backend brought up in #1627.

Description
This just adds the INTEL_DEBUG=nofc environment variable setting when creating an Instance using the GL backend in wgpu_hal. This is just a workaround until the mesa bug is fixed.

I wanted to wait until adapters were enumerated to determine that the user wanted to use an Intel Mesa adapter, but the environment variable has to be set before the x11 display was opened so that wasn't an option.

This may not be the strategy we want to take with this one, but it seems relatively harmless. Because the environment variable prefixed with INTEL anyway, it might not effect devices other than the ones we want to, which would be good.

Testing
I tested this on Ubuntu 20.04 with Mesa Intel(R) UHD Graphics (CML GT2) on using the GL backend.

[kvark]

This looks useful, thank you!
My main concern is - if it's temporary, when is it going to go away?
Do we have any means of detecting the driver version for Intel on EGL?

[cwfitzgerald]

My main concern is - if it's temporary, when is it going to go away?

When we find a way to trick the driver into a slow clear, or otherwise work around the bug. Otherwise the when the bug is fixed.

I'll have to check up on how to find driver versions, but it's likely there exists such an api. The big issue with this workaround is it needs to happen before LibGL is loaded at all. If we find a better workaround we can selectively apply it.

[kvark]

eh, ok. Hope we can revert this soon :)
bors r+

[bors]

Build succeeded:

• Android aarch64
• Format
• IOS aarch64
• Linux Nightly x86_64
• Linux x86_64
• MacOS x86_64
• WebAssembly
• Windows x86_64

[cwfitzgerald]

You and me both :)

[zicklag]

Actually, the other way I found to work around the bug was to set gl.color_mask(true, true, true, false);. That could be selectively applied based on driver detection done whenever we wanted.

Disadvantage there is that we are limiting functionality instead of making it slower. 🤔 Maybe that's better for some people, but not for others. I'm not sure.

[cwfitzgerald]

@zicklag so what that is likely doing is hitting a case where fast clears don't work so it's falling back to slow clears. I wonder if we can find another way to do that without affecting functionality.

[zicklag]

Not that this helps ( same alpha problem ), but I was also able to do it by forcing the pixel format of the framebuffer to RGB8 ( no alpha ). I wonder if there are other pixel formats that would still have an alpha channel, but would still work around the bug.

As far as I know we only run into this with the draw framebuffer, and I can't remember if the user actually depends on it being a specific pixel format or not, I'd have to look at it again.