[BUG] ARBClearTexture functions now falling back to GL44 functions

[Kai]

Hi,

just recently, I checked again whether my LWJGL raytracing demos are all working, and it seems that two of them don't work anymore with your recent changes. I think it has to do with the deduplication of the native methods.
My card and driver support the ARBClearTexture extension. But, the problem is that the glClearTexImage function is delegated to the GL44.glClearTexImage, which I think is wrong behaviour. The GL44 function might not be supported (if requesting a GL32 context for example), BUT the ARB extension function may still be supported.

The result is that with requesting a GL43 context, as the PhotonMappingBindlessDemo did, that ARBClearTexture.glClearTexImage() function call does not work anymore (it fails with "java.lang.IllegalStateException: This functionality is not available.") , whereas it did all time before the LWJGL update.

In general I think we cannot assume the GL context to support the GL core version for every ARB extension function, since a card/driver may not support the full GL core version, but may support many ARB extensions that possibly got promoted to core in any such GL core version.

[Kai]

On second thought, it seems that actually Khronos screwed this up, since the functions in that extension have no ARB suffix, and then the LWJGL generator might think that this could be a core function?

Hmm... but then again, there are also other extensions, such as ARBShaderImageLoadStore that contain functions without ARB suffix, but still don't delegate to their core functions, such as GL42 in that case. Weird...

[spasi]

This was indeed a bug introduced by the deduplication changes. Fixed in the latest nightly build. Thanks!

[Kai]

Now, the build seems to have some errors when compiling the tests. I tried with a normal "ant" on a clean checkout:

compile-tests:
    [Tests] Compiling 29 source files to D:\downloads\lwjgl3-clean\bin\Tests
    [Tests] D:\downloads\lwjgl3-clean\modules\core\src\test\java\org\lwjgl\system\MemoryUtilTest.java:23: error: cannot find symbol
    [Tests]             memSet(nGetAddress(buffer), 0x7F, buffer.capacity());
    [Tests]                    ^
    [Tests]   symbol:   method nGetAddress(ByteBuffer)
    [Tests]   location: class MemoryUtilTest
    [Tests] D:\downloads\lwjgl3-clean\modules\core\src\test\java\org\lwjgl\system\MemoryUtilTest.java:47: error: cannot find symbol
    [Tests]             long address = nGetAddress(buffer);
    [Tests]                            ^
    [Tests]   symbol:   method nGetAddress(ByteBuffer)
    [Tests]   location: class MemoryUtilTest
    [Tests] D:\downloads\lwjgl3-clean\modules\core\src\test\java\org\lwjgl\system\MemoryUtilTest.java:50: error: cannot find symbol
    [Tests]             ByteBuffer view = nNewBuffer(address + 8, 16);
    [Tests]                               ^
    [Tests]   symbol:   method nNewBuffer(long,int)
    [Tests]   location: class MemoryUtilTest
    [Tests] 3 errors

[spasi]

Ignore it, I'm in the middle of some unrelated changes that got pushed with the above fix. Will be fixed soon.

[Kai]

Okay, thanks for fixing! The original issue is resolved. (had to fix the build-script however to make the test compile at the very last, so that the natives got built)

[spasi]

I have now set everything up so that I build the JOML, joml-camera, joml-lwjgl3-demos and lwjgl3-demos repositories together with LWJGL 3. I will be testing any significant changes against your demos, they cover a lot of the API and should catch any unintended changes.

Btw, none of the raytracing demos (other than Demo20) work with the latest AMD drivers ("Implicit version number 110 not supported by GL3 forward compatible context"). Hadn't I fixed this in lwjgl3 before moving the demos to lwjgl3-demos?

[Kai]

Btw, none of the raytracing demos (other than Demo20) work with the latest AMD drivers ("Implicit version number 110 not supported by GL3 forward compatible context"). Hadn't I fixed this in lwjgl3 before moving the demos to lwjgl3-demos?

You did. And your changes are still there:
- compile-time conditionals #if defined(GL_core_profile) in the shader, and
- shader source assembling with prepended "version" String in the Java sources.
Additionally, I had other troubles recently with very old Intel cards/drivers that defined GL_core_profile but had only GL 2.1 support and won't accept "in/out" therefore. But I removed to support those in the shaders again. There simply does not seem to be a way to support old and new Intel, new AMD and new NV at the same time.

EDIT: Ahh, it could be that I refactored common parts of all "random" shader fragments into its own "randomCommon.glsl". This has no explicit GLSL version declared. Is this the shader object that gives you compile errors?

[spasi]

Yes, that's the one. Added a version statement and everything works great.