GS/GL: Drop requirement for GLAD_GL_ARB_draw_buffers_blend.

[lightningterror]

Description of Changes

GS/GL: Drop requirement for GLAD_GL_ARB_draw_buffers_blend.
Currently we don't use hw blend on individual render targets so we can revert to old behavior while keeping compatibility with older drivers.

Rationale behind Changes

Fixes crashes on older Mesa drivers on llvmpipe sw, might help other drivers/gpus that we don't know about.

Suggested Testing Steps

Try the latest release from:
https://fdossena.com/?p=mesa/index.frag
see if it crashes on windows on gl.

Did you use AI to help find, test, or implement this issue or feature?

No.

[TellowKrinkle]

I pulled up the mesa you linked in a decompiler and it definitely contains a glBlendFuncSeparatei, so you might want to look into why that isn't getting loaded properly.

[TheLastRar]

glBlendFuncSeparatei is listed as available in GL4.0 and newer.
GLAD doesn’t attempt to load it (or any GL4.0 function) if the reported GL version is too old.
The linked MESA build reports GL3.3.

A suffixed version of glBlendFuncSeparatei (glBlendFuncSeparateiARB) is loaded if GL_ARB_draw_buffers_blend is reported (as is the case with the linked MESA build).

[lightningterror]

At least it doesn't have vendor specific variants, anyway thanks for checking, cleaned/updated the code.

[lightningterror]

It seems that #13631 introduced back GLAD_GL_ARB_draw_buffers_blend support, @TJnotJT do we have any use case for it, otherwise we can switch back to the old ones, I also remember AMD pre Adrenalin era having issues with GLAD_GL_ARB_draw_buffers_blend not working properly while being supported.

[TJnotJT]

@lightningterror Yes, GLAD_GL_ARB_draw_buffers_blend is used for depth-as-rt feedback since we need to disable blending on the depth RT separately from the color RT. If there is a way to check for issues with GLAD_GL_ARB_draw_buffers_blend, depth feedback could be disabled in such cases.