LWJGL Forum

I upgraded my HD 3650 to 10.1 drivers: (these are totally official ones, not any beta or anything)
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: ATI Radeon HD 3600 Series
GL_VERSION: 3.2.9252 Compatibility Profile Context

and now with lwjgl 2.2.1 i get a lot of exception with basic GL11 and GL12 functions being not supported.
for example:

java.lang.IllegalStateException: Function is not supported
   at org.lwjgl.BufferChecks.checkFunctionAddress(BufferChecks.java:64)
   at org.lwjgl.opengl.GL11.glLightModeli(GL11.java:1892)   <-- basic stuff
   at Game.initGL(Game.java:136)
or
java.lang.IllegalStateException: Function is not supported
   at org.lwjgl.BufferChecks.checkFunctionAddress(BufferChecks.java:64)
   at org.lwjgl.opengl.GL11.glLightModel(GL11.java:1900)    <-- what am i supposed to use instead of this one
   at Game.initGL(Game.java:151)
or
java.lang.IllegalStateException: Function is not supported
   at org.lwjgl.BufferChecks.checkFunctionAddress(BufferChecks.java:64)
   at org.lwjgl.opengl.GL11.glMatrixMode(GL11.java:1961) 
   at Game.initGL(Game.java:163)

is this an april fools joke because on amd forum it seems there are lots of issues with programs that use opengl and these drivers are installed by everyone who do updates.

I can confirm this, latest AMD drivers are seriously broken. I can't create anything but a 3.2 core context (even though it says it's a Compatibility context), all deprecated functions are missing.

If I use no ContextAttribs or ContextAttribs with any version < 3.2, I get a 3.2 core context.
If I use ContextAttribs with 3.2 and Compatibility profile, I get a 3.2 core context.
If I use ContextAttribs with 3.2 and Core profile or no profile at all, I get an OpenGL error on context initialization.

A joke indeed.

Hmmm... try running this: http://www.tommytwisters.com/games/tommybench/files/tommybench.jnlp (http://www.tommytwisters.com/games/tommybench/files/tommybench.jnlp)

Let me know if it works or not. I'll try scrounging up an ATI machine to experiment on.

Ok, I've verified this with lwjgl 2.2.2. However, I ran one of my older games (not sure which version of lwjgl it's using - at least version 2), and it ran fine with the new ATI drivers.

I went back through each version of LWJGL to version 2.1.0.

2.1.0 works just fine with the new ATI drivers. I'm not sure why there's this sudden incompatibility between the 2.2 series and the 10.1 ATI drivers, but there you go. I hope this helps in some way to figure out what the problem is (as it appears to be an LWJGL issue).

Let me know if there's anything else I can do to help.

driver problem - probably related to ogl 3+

benchmark worked fine. don't know what's wrong , minecraft, runescape work also fine, maybe new lwjgl changed something.

I found out what the problem with LWJGL is, this ATI driver doesn't expose ARB_compatibility and I kinda assumed that it should exist in a 3.2 compatibility context. Working on a fix, will let you know when it's up.

sounds like a critical bug, worthy of a LWJGL 2.2.3 release :)

Matzon, should I also remove support for non-direct buffers? We haven't had any different opinions so far (http://lwjgl.org/forum/index.php/topic,3172.0.html (http://lwjgl.org/forum/index.php/topic,3172.0.html)), but I don't feel like making this decision alone. Not sure how many LWJGL users visit this forum, it's a non-trivial change and might break existing code.

Committed. The ATI fix works fine, a bunch of AMD extensions have been added, indirect buffer support has been removed. Grab a fresh build (https://www.newdawnsoftware.com/hudson/view/LWJGL/) when it's up and let me know how it goes.

now with GL11.glLightModel(GL11.GL_LIGHT_MODEL_AMBIENT, FloatBuffer.wrap(new float[] { 0.1f, 0.1f, 0.1f, 1.0f }));   
      
i get java.lang.IllegalArgumentException: FloatBuffer is not direct
   at org.lwjgl.BufferChecks.checkDirect(BufferChecks.java:122)
   at org.lwjgl.BufferChecks.checkBuffer(BufferChecks.java:177)
   at org.lwjgl.opengl.GL11.glLightModel(GL11.java:1838)

i guess now have to construct the float buffers differently

Yes, he mentioned that he removed support for non-direct buffers. But trust me, it's for the best. Just revamp your code to use direct buffers instead (and reuse them when possible, like in the case of setting your lightmodel).

Nice to see nondirect buffers gone. Never seen any use for them when dealing with heap data so I won't miss them ^^

Just verified that the ATI driver problem is fixed in the nightly build. Thanks Spasi!!!

New build out ASAP? I'd pull the old one too, as it doesn't work properly...

Cas :)

I'd say yes, we need a new build.

There's no point pulling the last one btw. The problem exists in every build since LWJGL 2.1.0, but it only triggered with the latest ATI driver.

edit: since 2.1.0, not 2.2.0

I got the nightly 2.3 build, and it's still happening:

(http://img402.imageshack.us/img402/1877/problemg.png)

I cannot test the indev Minecraft version. The 3 public versions use an old 2.1.0 build that doesn't have this problem. Could you please add the following piece of code in Minecraft to help me out?

System.out.println("GL RENDERER: " + GL11.glGetString(GL11.GL_RENDERER));
System.out.println("GL VENDOR: " + GL11.glGetString(GL11.GL_VENDOR));
System.out.println("GL VERSION: " + GL11.glGetString(GL11.GL_VERSION));

ContextCapabilities caps = GLContext.getCapabilities();

System.out.println("OpenGL 3.0: " + caps.OpenGL30);
System.out.println("OpenGL 3.1: " + caps.OpenGL31);
System.out.println("OpenGL 3.2: " + caps.OpenGL32);
System.out.println("ARB_compatibility: " + caps.GL_ARB_compatibility);

if ( caps.OpenGL32 ) {
IntBuffer buffer = ByteBuffer.allocateDirect(16 * 4).order(ByteOrder.nativeOrder()).asIntBuffer();

GL11.glGetInteger(GL32.GL_CONTEXT_PROFILE_MASK, buffer);
int profileMask = buffer.get(0);

System.out.println("PROFILE MASK: " + Integer.toBinaryString(profileMask));

System.out.println("CORE PROFILE: " + ((profileMask & GL32.GL_CONTEXT_CORE_PROFILE_BIT) != 0));
System.out.println("COMPATIBILITY PROFILE: " + ((profileMask & GL32.GL_CONTEXT_COMPATIBILITY_PROFILE_BIT) != 0));
}

Feel free to replace println with whatever you use for logging and make sure you run the code immediately after creating the GL context (or at least before calling anything else in GL, especially anything deprecated).

I may have found the root of the problem anyway, but I'd appreciate it if you could help me verify it. Anyone else on ATI with 10.1 feel free to run this code as well.

thanks for working quickly on this - will release 2.3 shortly after confirmed fix.

Preferably, test with the next available build (https://www.newdawnsoftware.com/hudson/view/LWJGL/) (build # > 384).

Your account is now paid so you can test it. Thank you. =)

I updated to the latest LWJGL since the next build isn't available yet. This is what I get:

QuoteLWJGL version: 2.3
GL RENDERER: GeForce GTX 260/PCI/SSE2
GL VENDOR: NVIDIA Corporation
GL VERSION: 3.2.0
OpenGL 3.0: true
OpenGL 3.1: true
OpenGL 3.2: false
ARB_compatibility: true

I thought this issue was Ati specific ?

Yes. it works for me. I just posted that for reference.

I tried the indev version and it works on my ATI, no exceptions or anything. But your report shows that there's a problem on NV as well. Could you please run Minecraft with -Dorg.lwjgl.util.Debug=true and let me know if any functions are reported as missing on context creation?

It works? In 10.1? Well, that's good! :D

I create the context with just Display.create(). I'm not passing any parameters.

I get no warnings about missing functions here, all extra output I get from passing that flag is:

Initial mode: 1680 x 1050 x 32 @60Hz
OpenGL32 was reported as available but an entry point is missing
getPathFromClassLoader: searching for: OpenAL32
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
getPathFromClassLoader: searching for: lwjgl
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
getPathFromClassLoader: searching for: lwjgl
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
Found 32 OpenAL paths
T
Failed to load C:\Program Files (x86)\Java\jre6\bin\OpenAL64.dll: C
T
Failed to load .\OpenAL64.dll: C
T
Failed to load C:\Windows\Sun\Java\bin\OpenAL64.dll: C
T
Failed to load C:\Windows\system32\OpenAL64.dll: C
T
Failed to load C:\Windows\OpenAL64.dll: C
T
Failed to load C:/Program Files (x86)/Java/jre6/bin/client\OpenAL64.dll: C
T
Failed to load C:/Program Files (x86)/Java/jre6/bin\OpenAL64.dll: C
T
Failed to load C:\Program Files (x86)\JavaFX\javafx-sdk1.2\bin\OpenAL64.dll: C
T
Failed to load C:\Program Files (x86)\JavaFX\javafx-sdk1.2\emulator\bin\OpenAL64.dll: C
T
Failed to load C:\Windows\system32\OpenAL64.dll: C
T
Failed to load C:\Windows\OpenAL64.dll: C
T
Failed to load C:\Windows\System32\Wbem\OpenAL64.dll: C
T
Failed to load C:\Windows\System32\WindowsPowerShell\v1.0\\OpenAL64.dll: C
T
Failed to load C:\Program Files (x86)\Java\jdk1.6.0_17\bin\OpenAL64.dll: C
T
Failed to load E:\mc_dev\Minecraft.Client\OpenAL64.dll: C
T
Failed to load OpenAL64.dll: C
T
Failed to load C:\Program Files (x86)\Java\jre6\bin\OpenAL32.dll: C
T
F

QuoteOpenGL32 was reported as available but an entry point is missing

This is the important line. You should be getting a message that says which function is missing, not sure why it doesn't print.

Oh, there's another line when I quit the game:

Could not locate symbol glGetInteger64i_v

OK, try the next build (hmm, why hasn't the previous one shown up yet?).

What I did is to allow certain functions to be made optional when loading an extension. LWJGL has always been checking for the availability of all the functions in an extension (or core GL version). When one of them was missing, it would make it so that the whole extension was not available. For now, I've marked the following functions as optional:

glDrawElementsBaseVertex (GL32)
glDrawRangeElementsBaseVertex (GL32)
glDrawElementsInstancedBaseVertex (GL32)

The above 3 are missing from the current ATI driver.

glGetInteger64i_v (GL32)

This one is missing from the current NV driver.

This means that, for example, you'll be able to use all GL32 functions on an NV implementation, but calling glGetInteger64i_v will throw an exception. Hopefully the latest commit fixes both AMD and NV issues.

Quote from: spasi on February 07, 2010, 18:58:10
OK, try the next build (hmm, why hasn't the previous one shown up yet?).

Because, almost without fail, the windows machines (either 32 or 64 bit) fall out of the farm whenever I go away. Just got back, win64 machines back in farm, building has resumed :)

Endolf

Markus, could you please update Minecraft to the latest build so we can test and get an official release out asap?

Done!

I get this now:

LWJGL version: 2.3
GL RENDERER: GeForce GTX 260/PCI/SSE2
GL VENDOR: NVIDIA Corporation
GL VERSION: 3.2.0
OpenGL 3.0: true
OpenGL 3.1: true
OpenGL 3.2: true
ARB_compatibility: true
PROFILE MASK: 0
CORE PROFILE: false
COMPATIBILITY PROFILE: false


Works fine on nvidia now right? No exceptions or anything?

Flawlessly.

Works on ATI 10.1 too, so I guess we can consider this fixed.

Thanks for your efforts, much appreciated :)

Now it's not working on some other driver version for ATi. I don't know which driver version that is, though, sorry:
It's a "XFX ATI RADEON HD5870 1GB GDDR5"

Reading certificates from 2388 http://minecraft.net/indev/client/lwjgl_util_applet.jar?v=14 | C:\Users\ez\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\7\7df4b9c7-17664ff0.idx
Laddade bild: http://minecraft.net/indev/client/logo_small.png
Laddade bild: jar:http://minecraft.net/indev/client/lwjgl_util_applet.jar?v=14!/appletprogress.gif
Reading certificates from 2152 http://minecraft.net/indev/client/lzma.jar?v=14 | C:\Users\ez\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\0\3b677940-19b1b04b.idx
43
org.lwjgl.opengl.OpenGLException: Invalid operation (1282)
at org.lwjgl.opengl.Util.checkGLError(Util.java:54)
at org.lwjgl.opengl.Display.makeCurrentAndSetSwapInterval(Display.java:884)
at org.lwjgl.opengl.Display.create(Display.java:847)
at org.lwjgl.opengl.Display.create(Display.java:771)
at org.lwjgl.opengl.Display.create(Display.java:752)
at net.minecraft.client.d.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

This is a context creation error and since you are not using ContextAttribs it shouldn't be any different from old LWJGL versions. Can that user run the non-indev versions of Minecraft? The same error should happen there, I'll investigate further if not.

She could play the indev version up until yesterday, she's played the old versions a lot. This error was still there after a reboot.

For reference: http://www.minecraftforum.net/viewtopic.php?f=35&t=7065

pardon my ignorance, but why do we have to update code when ATI updates its drivers?

Fixed on next build. I had to revert to an old driver version to test this and of course ATI behaved exactly like NV before 10.1 (ARB_compatibility exposed), with the difference that it generates an INVALID_OPERATION error if you try to retrieve GL_CONTEXT_PROFILE_MASK (which is what I had to do to fix the original 10.1 problem). ::)

The build is up if you want to update Minecraft.

just curious how exactly did you fix this ati problem? do you now have ati driver version specific hacks or general code that works the same everywhere?

Quote from: javalwjgl on February 09, 2010, 22:07:46general code that works the same everywhere?

This. I added another condition to the code that forces forward compatible mode (fc mode = no deprecated functions are loaded). That condition is basically checking a GL3.2 core mask (GL_CONTEXT_PROFILE_MASK) to see if the compatibility profile has been loaded. If either ARB_compatibility or the compatibility profile are available, forward compatible mode isn't forced (the application can still enable it if desirable).

So, the code is general, but parts of it only apply to specific implementations. The driver behavior I've seen so far for the default context creation:

- NVIDIA: ARB_compatibility exposed, GL_CONTEXT_PROFILE_MASK returns 0.
- ATI pre 10.1: ARB_compatibility exposed, retrieving GL_CONTEXT_PROFILE_MASK produces an INVALID_OPERATION error.
- ATI 10.1: ARB_compatibility *not* exposed, GL_CONTEXT_PROFILE_MASK returns GL_CONTEXT_COMPATIBILITY_PROFILE_BIT.

but what I am thinking is - why were we hit with the issue?
what about the other 438294209384092390 applications out there?

IMO, drivers shouldn't change behavior all of a sudden.

Wow, you guys are fast. I got an error report about it during the night, and you have already fixed it. Thanks for your hard work. Will this warrant a new release? Any ETA on that?

I am planning on releasing 2.3 as soon as this fix is confirmed working.
I was also hoping to get a new OpenAL-Soft build into this - but I am having problems getting it compiled for all platforms - so this may come in a later version.

If that improves openal support on mac and linux, I'd kill for it to be in. :D
I recently abandoned java sound (because it's HORRIBLE these days, no pan and gain controls!?) in favor of OpenAL only, but some people (mainly mac it seems) can't get that to run.

Are you having OpenAL trouble on Mac? I had been under the impression it worked flawlessly (no support requests at any rate).

Cas :)

Quote from: Matzon on February 10, 2010, 07:09:11but what I am thinking is - why were we hit with the issue?
what about the other 438294209384092390 applications out there?

IMO, drivers shouldn't change behavior all of a sudden.

An application that never cared about OpenGL 3.1+ would never encounter this issue. All the drivers so far, from both major vendors, continue exposing the deprecated functionality, it never went away. An OpenGL app written 10 years ago would use the same context creation routine we use in LWJGL (without ContextAttribs) and would be able to retrieve the function pointers to the deprecated functions with no issues.

The problem with LWJGL has 2 parts:

a) We try to support all the new stuff, from day one. We were ready for GL 3.1 (that drops the deprecated functionality) when GL 3.0 was released. We even introduced the pseudo-forward-compatible mode, for people to test how GL would feel like without the deprecated functions.
b) For LWJGL to consider an extension supported, all functions in that extension should be exposed. (that's the main problem)

So, imagine that LWJGL encounters a GL31 compliant implementation that does not expose ARB_compatibility, or even a GL30 implementation with support for the forward compatible bit (this hasn't happened yet, but at the time GL30 was released it sounded like a real possibility and we had to support it). Without any changes to how we load extensions, LWJGL would suddenly fail to even start. 1 missing function from GL11 would be enough to make the whole thing unavailable, causing LWJGL to throw an early exception.

At that time there were 2 ways to enable the forward compatible path:

1) The application specifically asked for a forward compatible context (ContextAttribs.withForwardCompatible). This was even available to pre3.0 implementations (the pseudo-fc mode).
2) OpenGL 3.1 was supported and ARB_compatibility was not exposed. This was forced by LWJGL, since it had to follow the spec.

Then came OpenGL 3.2 that introduced another way to avoid forward compatible mode, the Compatibility profile. Then came ATI 10.1 that dropped ARB_compatibility. Then we had to fix LWJGL. :)

Does LWJGL really have to be clever?

The less clever it is, the lower are the odds of it tripping itself over. I don't want to release a game using 2.4 or whatever, then have it break five years down the line.

LWJGL doesn't do anything special tbh, I just followed the initial design (extension supported = all functions exposed) and the OpenGL spec. The only way to avoid all the above would be to have users load the extensions/functions manually, or have them manage the deprecation model manually. They'd still have to solve the same problems though, so why not centralize the solutions? The only unnecessary feature was the pseudo-fc mode, but even that you get for free, it's an implementation by-product.

You also need to realize that OpenGL is indeed drastically changing. We have a new context creation routine for the first time in 15 years, it's only normal that problems would occur. I don't think we'll have any problems down the line, this instability period should be very short. The real problem is... what happens if in 5 years ATI/NV decide to drop support for the compatibility profile? There's nothing LWJGL can do for you in that case, it's the application's responsibility to be ready for the post GL 3.0 era. At least LWJGL will be functioning properly when it happens. ;)

On a related note, I just found another bug in LWJGL. There's some state tracking performed internally and we used GL13.GL_MAX_TEXTURE_UNITS at some point. It so happens that GL_MAX_TEXTURE_UNITS is deprecated and was causing an INVALID ENUM error during context initialization if a forward compatible context was used. I changed it so that GL20.GL_MAX_TEXTURE_IMAGE_UNITS is used when available and we're also now catching+logging any OpenGL errors during context init, instead of throwing an (unrecoverable) exception. What I previously thought was an error caused by no support for the core profile, ended up being a stupid LWJGL bug.

The good news is that ATI actually supports the core profile. ContextAttribs.withForwardCompatible and ContextAttribs.withDebug also work.

from my POV, if LWJGL doesn't do this work - it would be up to the individual developer. So I see this as a Good Thing (TM). But sometimes it just gets a bit bumpy :)

Quote from: Notch on February 10, 2010, 08:41:14
If that improves openal support on mac and linux, I'd kill for it to be in. :D
I recently abandoned java sound (because it's HORRIBLE these days, no pan and gain controls!?) in favor of OpenAL only, but some people (mainly mac it seems) can't get that to run.

we're not supporting openal-soft for mac, since no one has done a CoreAudio backend for openal-soft: http://repo.or.cz/w/openal-soft.git/tree/HEAD:/Alc

Out of curiosity, what's the proper way to create a display context now? I've just been using Display.create(PixelFormat) and Display.create(). Has this changed?

Quotewe're not supporting openal-soft for mac, since no one has done a CoreAudio backend for openal-soft

Does this mean no more sound support on Mac? It seemed to work fine before (as far as I could tell).

Quote from: elias4444 on February 10, 2010, 16:10:39

Quotewe're not supporting openal-soft for mac, since no one has done a CoreAudio backend for openal-soft

Does this mean no more sound support on Mac? It seemed to work fine before (as far as I could tell).

No it means that we dont supply openal-soft - we use the platform provided openal on macs.

Quote from: elias4444 on February 10, 2010, 16:10:39Out of curiosity, what's the proper way to create a display context now? I've just been using Display.create(PixelFormat) and Display.create(). Has this changed?

No, it hasn't changed. Using Windows as an example, calling Display.create without passing any ContextAttribs will use wglCreateContext(hdc) under the hood. On a GL implementation that supports GL30 or newer, wglCreateContext(hdc) is equivalent to wglCreateContextAttribsARB(hdc, 0, NULL). What happens at this point depends on the implementation (see wgl_create_context (http://www.opengl.org/registry/specs/ARB/wgl_create_context.txt) for details), but you can be sure that:

QuoteThe legacy context creation routines can only return OpenGL 3.1 contexts if the GL_ARB_compatibility extension is supported, and can only return OpenGL 3.2 or greater contexts implementing the compatibility profile. This ensures compatibility for existing applications. However, 3.0-aware applications are encouraged to use wglCreateContextAttribsARB instead of the legacy routines.

ContextAttribs is simply LWJGL's wrapper of the WGL/GLX ARB_create_context extensions. Passing a ContextAttribs instance to Display.create gives you control of what happens in CreateContextAttribsARB, which is mostly useful for creating a Core profile/forward compatible context.

Have you got an ETA on the next release with this fix?

Dare I distribute the nightly build instead?

You can use nightly. I plan on releasing 2.3 this weekend. I was waiting for notch's confirmation tho ... - but I think its all good.

And I just tested it with the new ATI drivers that were released today (10.2)... the fixes still hold!


...phew!

What about 9.x drivers - everything working as expected on that front?

Cas :)

Yes, I had downgraded my drivers and tested when I was working on this.

Thanks. I'll wait for the release then. Please let me know if it turns out it wont happen this weekend, so I can decide on whether to use nightly instead.

Sorry to dig this up again, but I have that problem with LWJGL 2.8.3 on Mac OS 10.7.3 with a RADEON HD6950M.
Here's the stack trace:

>17:00:02 [SCHWERWIEGEND] Exception in thread "Render Thread"
>17:00:02 [SCHWERWIEGEND] java.lang.IllegalStateException: Function is not supported
>17:00:02 [SCHWERWIEGEND]    at org.lwjgl.BufferChecks.checkFunctionAddress(BufferChecks.java:58)
>17:00:02 [SCHWERWIEGEND]    at org.lwjgl.opengl.GL11.glGenLists(GL11.java:1392)
>17:00:02 [SCHWERWIEGEND]    at org.spout.engine.renderer.GL11BatchVertexRenderer.<init>(GL11BatchVertexRenderer.java:13)
>17:00:02 [SCHWERWIEGEND]    at org.spout.engine.renderer.BatchVertexRenderer.constructNewBatch(BatchVertexRenderer.java:21)
>17:00:02 [SCHWERWIEGEND]    at org.spout.engine.batcher.PrimitiveBatch.<init>(PrimitiveBatch.java:18)
>17:00:02 [SCHWERWIEGEND]    at org.spout.engine.SpoutClient.initRenderer(SpoutClient.java:124)
>17:00:02 [SCHWERWIEGEND]    at org.spout.engine.scheduler.SpoutScheduler$RenderThread.run(SpoutScheduler.java:170)

Seems that the drivers are even more broken on the Mac than they are on windows :/