Allow GLava to work without GL_NV_texture_barrier extension

[quantum5]

Without this extension, GLava tries to call into a null pointer and segfaults.

Fix: don't call glTextureBarrierNV if the extension doesn't exist.

This is potentially unsafe, but appears to work fine in practice.

[jarcode-foss]

Are you on a driver that doesn't support this extension? Removing this call is sure to give rise to strange bugs that would be otherwise difficult to narrow down.

If your driver does not support this function (all major vendors should, despite the NV portion of the function name), then it would be preferred to replace it with a workaround that guarantees a shader texture write/read barrier on your hardware. The best way to do this is to use GL 4.x glMemoryBarrier, but the portion of GLava in question is trying to maintain 3.x compatibility for older hardware.

[quantum5]

Yes, I was running GLava on mesa. Not the best combination, but it also shouldn't just outright crash with a segmentation fault.

I will give glMemoryBarrier a try, but we still have to gracefully handle the case when it is not supported. Perhaps a warning on startup and try to chug along despite the neither function existing?

[jarcode-foss]

@quantum5 Attempting to use glMemoryBarrier instead, and if that doesn't exist, force-disabling #request setaccelfft would be the best solution to avoid any output actually breaking.

Removing the glTextureBarrierNV on amdgpu completely breaks output so there is more than just a theoretical reason for needing this call.

Yes, I was running GLava on mesa.

I am assuming on older Intel integrated graphics, because most mesa drivers support glTextureBarrierNV.

Also, I would hold off on trying to fix the patch since there is a huge slew of changes pending on my local branch that contains the remainder of the GPU-accelerated FFT stuff.