JOGL and VIA CLE266 (UniChrome) compatibility problem (glActiveTextureARB entry

OpenGL Development JOGL Development
#1

Hello,

We are testing our app for compatibility with VIA CLE266 based PCs (those with UniChrome-based graphics). Drivers for these boards report that they support OpenGL 1.2 and ARB_multitexture extension, and they have no glActiveTexture entry point but only glActiveTextureARB. This means that apps that in practice may run on these boards will fail due to extension GL_ARB_multitexture is ignored in default JOGL build (in gl-common.cfg, as extension subsumed in OpenGL 1.3 (from OpenGL 1.3 spec, Appendix F)).

Sure we will make our own build of JOGL, but you see, this is a victim of OpenGL API Inclusion Criteria :), and, because of getExtension() is not supported (at least now), some apps that under other circumstances MAY run on such systems will fail (for example, all Xith3D-based applications [for now]).

I think it makes sense to keep compatibility for such cases, at least while cards/boards that only support 1.2 and few 1.3 extensions are in use.

It is 100% clear, that “If the functionality of the OpenGL extension was subsumed into core OpenGL by version 1.3, then the extension was dropped from the Java bindings.” (as of OpenGL API Inclusion Criteria).

The bottom line: I think that while JSR-231 is free to drop extensions included in 1.3, JOGL should support them…

[OK, maybe I am also wrong in this case, anyway we will continue with custom build of JOGL for now]

Yuri

#2

Sorry, but I think your best approach is to continue using a custom build of JOGL and to report this problem to VIA and get them to update their drivers. They are the only manufacturer I’ve heard of that’s shipping an OpenGL implementation that supports 1.2 but not 1.3.

#3

As far as I can see, some (if not most) extensions promoted to OpenGL core spec from ARB have exactly the same syntax but only different function (entrypoint) names (like glActiveTexture in 1.3 vs. glActiveTextureARB in ARM_multitexture). This seems to be true, say, for GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_ARB_texture_compression and some others (needs to be checked deeper).

My question is: what do you think about implementing function name aliasing for such cases (actually, few selected functions) similar way as you do, fo example in WindowsGLContext.isFunctionAvailable(…) by using mapToRealGLFunctionName and functionNameMap for mapping glAllocateMemoryNV to wglAllocateMemoryNV?

This mechanism can be trivially placed in WindowsGLDrawableFactory.dynamicLookupFunction and will have no performance impact because of it will only be activated if exactly matching function not found, and will work only on context-setup time. On the other hand, JSR-231 public API will remain unchanged (only implementation internals will be affected), and we will have a bit better compatibility with some vendors.

[This is actually included in my custom JOGL build, and I am just wondering if it makes sense to integrate it with the publically available code]

Yuri

#4

Please file an RFE about this with the JOGL Issue Tracker. We’ll consider adding it to the next beta.