feat(gles): Add GlDebugFns option to disable OpenGL debug functions

[Xavientois]

Summary

Adds a new debug_fns field to GlBackendOptions and GlDebugFns enum that allows disabling OpenGL debug functions (glPushDebugGroup, glPopDebugGroup, glObjectLabel, etc.).

Problem

On some Mali GPUs on Samsung Galaxy devices, we observed the following crash:

SIGSEGV: Segmentation violation (invalid memory reference)

0 libGLES_mali.so +0x1348004 cutils_cstr_strncpy
1 libGLES_mali.so +0x61077b  gles_state_push_debug_group
2 libGLES_mali.so +0x5e274f  glPushDebugGroup
3 mylib.so +0x5f6583  wgpu_hal::gles::queue::submit

Since we do not use the debug functions in our project, we want to be able to disable them outright.

Solution

• Add GlDebugFns enum with Auto (default) and Disabled variants
• Add debug_fns: GlDebugFns field to GlBackendOptions
• Add environment variable support via WGPU_GL_DEBUG_FNS=auto|disabled
• Update the DEBUG_FNS capability-setting code to respect this option

Usage

Via API:

let instance = wgpu::Instance::new(&wgpu::InstanceDescriptor {
    backends: wgpu::Backends::GL,
    backend_options: wgpu::BackendOptions {
        gl: wgpu::GlBackendOptions {
            debug_fns: wgpu::GlDebugFns::Disabled,  // Disable for Mali GPU workaround
            ..Default::default()
        },
        ..Default::default()
    },
    ..Default::default()
});

Via environment variable:

WGPU_GL_DEBUG_FNS=disabled ./your_app

Test

• Hard-coding the disabled value here has worked as a fix for us for the past year at Pinterest

---

This PR description was written by AI.

[inner-daemons]

@Xavientois THanks for this PR, and thanks for being upfront about the AI usage for writing this description!

I don't think we have our policy in words yet, but we basically require that for any PR or issue that you file, you must be able to defend and understand everything that is written. The general policy is that 2 people must understand well every PR: the author and the reviewer.

Also, we don't really want to read through whatever an LLM wrote, especially given how common hallucinations are, or how it might drag out the word count.

The PR itself looks relatively simple but I'd just like to warn you that there's basically no chance in my mind that it gets merged as-is.

Maintainers will discuss this on Wednesday and get back to you. Nothing I've said here is a final decision. Thanks again for being clear about this being AI written.

[Xavientois]

@inner-daemons Thanks for the quick response! I appreciate you being candid about not wanting to the LLM-generated piece.

If the primary blocker is the LLM-generated content, I'd be happy to rewrite it myself. I do fully understand the change, as this is a fix that we have been using in our internal WGPU fork for over a year now, so my goal is just to include it in the upstream.

Do you think it would be worthwhile for me to rewrite it myself?

[inner-daemons]

@Xavientois The point of contention here is mainly the description being AI generated. Code can be judged purely on its quality and is trustworthy and self explanatory. If a reviewer approves of code it doesn't particularly matter what wrote it, except that the human responsible for filing the PR understands it. But having an AI generate a PR description comes off as little bit lazy and disrespectful in all honesty, and it means there will be too many words, many of which are not necessarily true.

I'd also want you to file an issue before submitting a PR like this. The issue template gives a lot of helpful information to maintainers. There might be better ways to solve these problems, and we want to know on what device the issue is occuring, what the logs are, and what alternatives you've considered. Plus, just having the bug be documented is nice.