OpenGL 4.1 and new extensions

[spasi]

Support for OpenGL 4.1 and equivalent extensions has been added to LWJGL. Extension list:

ARB_debug_output (callback is supported just like AMD_debug_output, check the org.lwjgl.opengl.ARBDebugOutputCallback class)
ARB_ES_compatibility
ARB_get_program_binary
ARB_robustness
ARB_separate_shader_objects
ARB_shader_precision
ARB_shader_stencil_export
ARB_vertex_attrib_64bit
ARB_viewport_array

From the latest extensions, only ARB_cl_event is missing. I'll add that one when we add support for OpenCL.

[Matthias]

Great work. You are really fast

* Matthias waits for next driver update to test some of the new features.

[Matzon]

Great work. You are really fast

* Matthias waits for next driver update to test some of the new features.

++
excellent work!

should we add some stuff in util to store and load shaders - or is it simple to use?
same question with the debug stuff?

[spasi]

Might be useful, but I think most people will roll their own solutions anyway. We have the shader tests that can be a useful starting place for new LWJGL users. Loading shaders specifically is dead simple with the recent CharSequence support.

The debug callback classes needed to be in org.lwjgl.opengl because they require package private functionality that interacts with native code. They're also simple to use and default implementations are provided (they dump everything to System.err).

[Matzon]

wrt, sharders - I was thinking of the binary compiled shaders

[spasi]

Binary shaders are also very simple to use, but with one catch; the loading of a binary shader program may fail at any time because of a hardware/software change (e.g. new driver version that comes with a better compiler). When that happens the application must fall-back to normal shader program creation, which means we can't have a robust solution in util.

[princec]

I confess I can't quite see the utility in binary shaders. A tiny performance gain but increased instability? Not in the modern world, thanks.

Cas

[spasi]

Binary shaders are all about start-up speed. It's not only the resources wasted by the driver compiler or the time it takes to compile/link/optimize shader programs (which can be very significant for complex rendering with hundreds of shaders). You also gain performance on the application side, because you don't have to "construct" the shader code again. Modern engines have to combine dozens of little shader scripts, dynamically insert the proper uniforms/flags/directives/etc, there's a lot of pre-processing required. If you can cache all that, the computation and IO gains are important. Besides, you can layer binary shaders on top of all that, I don't think it creates any instability.

Btw, they've even added new API (glReleaseShaderCompiler) that informs the driver to release resources allocated by the shader compiler.

[Bonbon]

How the ARB_ES_compatibility extensions works ?

I'm looking to make a port of LWJL to the Pandora device (ARM Linux with only OpenGL ES on it). I don't think so but that this extension works with the OpenGL ES driver or only with the OpenGL 4.1 driver ?

[spasi]

ARB_ES2_compatibility is only exposed on desktop OpenGL implementations. Practically, it only helps to have some kind of source-level compatibility between desktop GL and GL-ES (in C code mostly). With a Java binding like LWJGL it's basically useless, you need proper ES2 support. Even if you do all the EGL context management yourself and pass it down to LWJGL with GLContext.useContext, LWJGL still needs to "know" about eglGetProcAddress to do anything useful.