[RFE] LWJGL 3.0

Started by spasi, November 08, 2012, 13:23:54

Previous topic - Next topic

Umami

Quote from: shivshank on December 22, 2014, 21:05:17
var vaos:ListBuffer[Int] = new ListBuffer[Int]()
I don't know Scala, but can those List Buffers be freed prematurely? Maybe your freeing fake pointers? Also make sure your using the BufferUtils whenever you pass data to the GPU, it looks like you are though.

Also, if I recall correctly, (it has been a while), this is a part of the VAO state, so just call it during VAO creation.
GL20.glDisableVertexAttribArray(0)
Although I don't think that will fix your problem...

Just noticed: has LWJGL been tested on OpenJDK at all? Is libffi tested on it?

Thanks, you may be right. I'll try out Java ArrayLists here. Will test it tomorrow.

Well, I used libgdx in the past and lwjgl 2.someish back a few years ago. I always use the openjdk, never the oracle implementation. Shouldn't change much here.

Umami

Well, no, it doesn't matter if I use an ArrayList or not. Rewrote the class in java, still the same segfault.

spasi

Umami,

Could you please test a simpler version of your program? E.g. simply instantiate a callback and then release it immediately. Other things you can try:

- Clone the LWJGL repo and run the tests (after cloning run ant compile-templates and then ant tests).
- Run your program with a different JDK (e.g. OpenJDK 7 or the Oracle JDK).

shivshank

Hmm, Umami, I looked again: in Loader.destroy(26), you wrote GL30.glDeleteFramebuffers(i). A VAO is not a frame buffer, I believe you're supposed to use glDeleteVertexArrays, https://www.opengl.org/sdk/docs/man/html/glDeleteVertexArrays.xhtml.

The error you posted says it's with libffi, so I don't know if this makes sense. Would a GPU mis-access cause a seg fault? Could it bubble up?

Umami

Hey everyone, I hope you had a merry Christmas! :)

Quote from: shivshank on December 24, 2014, 01:56:47
Hmm, Umami, I looked again: in Loader.destroy(26), you wrote GL30.glDeleteFramebuffers(i). A VAO is not a frame buffer, I believe you're supposed to use glDeleteVertexArrays, https://www.opengl.org/sdk/docs/man/html/glDeleteVertexArrays.xhtml.

The error you posted says it's with libffi, so I don't know if this makes sense. Would a GPU mis-access cause a seg fault? Could it bubble up?

The error happens as soon as I try to create a new VAO:

    val vaoID:Int = GL30.glGenVertexArrays()


Crashes my program.

I'm not sure why, though. My drivers should support OpenGL 3 just fine.

Quote
OpenGL version string: 3.0 Mesa 10.3.5

I'm playing a lot of games with the open source drivers and some of them use OpenGL 3 features (at least to my knowledge) and everything works like a charm.

@spasi:

Tried to build the repo-code but it's assuming I use Java 1.6, which I don't and hence the compilation fails :(

I will try the OpenJDK 7, but not the OracleJDK tho.

spasi

Quote from: Umami on December 25, 2014, 16:09:20Tried to build the repo-code but it's assuming I use Java 1.6, which I don't and hence the compilation fails :(

You should be able to build with any JDK version >= 6. What error did you get exactly?

Umami

Ah, well, my bad. I just had a reeeeeally quick look at the build.xml

Anyway
/home/umami/lwjgl-test/lwjgl3/build.xml:101: The following error occurred while executing this line:
/home/umamil/lwjgl-test/lwjgl3/build.xml:106: /home/umami/lwjgl-test/lwjgl3/${env.JAVA_HOME}/jre/lib does not exist.

SHC

I think I've found a bug. This occurred to me on the startup.

2014-12-26 11:58:10.967 java[1955:36431] An uncaught exception was raised
2014-12-26 11:58:10.967 java[1955:36431] *** Collection <__NSSetM: 0x7f9b6506d400> was mutated while being enumerated.
2014-12-26 11:58:10.968 java[1955:36431] (
	0   CoreFoundation                      0x00007fff8f31a64c __exceptionPreprocess + 172
	1   libobjc.A.dylib                     0x00007fff8c1b86de objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff8f319ee5 __NSFastEnumerationMutationHandler + 309
	3   AppKit                              0x00007fff8d01b59b -[NSView trackingAreas] + 278
	4   AppKit                              0x00007fff8d109a1a -[NSView(NSInternal) _enableOrDisableTrackingAreas] + 108
	5   AppKit                              0x00007fff8d114027 -[NSView _windowChangedKeyState] + 665
	6   AppKit                              0x00007fff8d113ced -[NSFrameView _windowChangedKeyState] + 97
	7   AppKit                              0x00007fff8d6bc631 -[NSThemeFrame _windowChangedKeyState] + 47
	8   AppKit                              0x00007fff8d113887 -[NSWindow _setFrameNeedsDisplay:] + 156
	9   AppKit                              0x00007fff8d10a346 -[NSWindow _makeKeyRegardlessOfVisibility] + 98
	10  AppKit                              0x00007fff8d10a2ae -[NSWindow makeKeyAndOrderFront:] + 27
	11  ???                                 0x0000000106e134d4 0x0 + 4410389716
)
2014-12-26 11:58:10.969 java[1955:36431] *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSSetM: 0x7f9b6506d400> was mutated while being enumerated.'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff8f31a64c __exceptionPreprocess + 172
	1   libobjc.A.dylib                     0x00007fff8c1b86de objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff8f319ee5 __NSFastEnumerationMutationHandler + 309
	3   AppKit                              0x00007fff8d01b59b -[NSView trackingAreas] + 278
	4   AppKit                              0x00007fff8d109a1a -[NSView(NSInternal) _enableOrDisableTrackingAreas] + 108
	5   AppKit                              0x00007fff8d114027 -[NSView _windowChangedKeyState] + 665
	6   AppKit                              0x00007fff8d113ced -[NSFrameView _windowChangedKeyState] + 97
	7   AppKit                              0x00007fff8d6bc631 -[NSThemeFrame _windowChangedKeyState] + 47
	8   AppKit                              0x00007fff8d113887 -[NSWindow _setFrameNeedsDisplay:] + 156
	9   AppKit                              0x00007fff8d10a346 -[NSWindow _makeKeyRegardlessOfVisibility] + 98
	10  AppKit                              0x00007fff8d10a2ae -[NSWindow makeKeyAndOrderFront:] + 27
	11  ???                                 0x0000000106e134d4 0x0 + 4410389716
)
libc++abi.dylib: terminating with uncaught exception of type NSException

The previous run is fine, and also the next run, this just occurred once to me, and I also cannot reproduce it again.

SHC

I'm on OS X and LWJGL3 is asking me to start on the first thread after upgrading to LWJGL Nightly #35. This problem is not present in #34.

java.lang.IllegalStateException: Please run the JVM with -XstartOnFirstThread.
	at org.lwjgl.system.macosx.EventLoop.checkFirstThread(EventLoop.java:20)
	at org.lwjgl.glfw.GLFW.glfwInit(GLFW.java:426)
	at com.shc.silenceengine.core.Display.create(Display.java:215)
	at com.shc.silenceengine.core.Game.start(Game.java:157)
	at com.shc.silenceengine.tests.SoundTest.main(SoundTest.java:41)

I know that I can add -XstartOnFirstThread to the VM options, and that indeed works, but for my engine, I'll be happy to find a way that doesn't require me to do that. Is there any way I can use Disruptor myself?

spasi

I could walk you through the details (send a PM if you're interested), but I really think you'd be wasting your time. OS X and, by extension, GLFW, are not designed to work that way.

kappa

-XstartOnFirstThread as a VM option is pretty much the only way to go on OS X, even SWT requires that to function. The problem is the way the JVM is implemented on OS X and that it reserves the first thread by default for AWT, Swing and JavaFX, so until that changes or GLFW gets support for running from other threads there isn't really a clean way to workaround this.

Umami

I still had no luck tinkering with OpenGL 3 and lwjgl 3. One more thing I will try: Setting the opengl context explicitely to version 3.

Have to find out how to do that in lwjgl 3 tho.

If that's not working I'll leave it for now and switch to C++ for my initial prototype. Not exactly what I'd want, because I wanted to use Scala, but, well ...

spasi

Quote from: Umami on December 31, 2014, 07:30:15I still had no luck tinkering with OpenGL 3 and lwjgl 3. One more thing I will try: Setting the opengl context explicitely to version 3.

Have to find out how to do that in lwjgl 3 tho.

See the glfwWindowHint documentation. Specifically, the CONTEXT_VERSION_MAJOR, CONTEXT_VERSION_MINOR and maybe OPENGL_PROFILE hints.

Umami

So, not sure if that was really it, but I had to move

model = loader.loadToVAO(vertices)


into my update method after I create a GLContext.

Still I can't get my simple quad to render with my shaders, but at least it doesn't crash on startup anymore, which is a tiny success after all. :)

After I dumped my newbie code here, I was always searching at the wrong components, blaming other parts of my system to be faulty. Although it's still not very nice that it crashes instead of throwing an exception stating that the opengl context is missing, which it does in other cases.

spasi

Quote from: Umami on January 01, 2015, 12:01:11So, not sure if that was really it, but I had to move

model = loader.loadToVAO(vertices)


into my update method after I create a GLContext.

The reason is simple; you cannot use LWJGL's OpenGL bindings before GLContext.createFromCurrent(). Even if there is a context current in the current thread (after glfwMakeContextCurrent), you must let LWJGL know so that function pointers can be initialized, etc. It is not done automatically for you, because a) it's an expensive operation and b) you may want to reuse GLContext instances in some situations.

Quote from: Umami on January 01, 2015, 12:01:11After I dumped my newbie code here, I was always searching at the wrong components, blaming other parts of my system to be faulty. Although it's still not very nice that it crashes instead of throwing an exception stating that the opengl context is missing, which it does in other cases.

I had another look at your code and decided to download Scala and try it out. Another bug I found was the order of calls in your render loop. You're effectively rendering your model, then calling glClear, then glfwSwapBuffers, which means you're always going to get an empty framebuffer.

The model still isn't rendered after fixing that. I'm not getting any OpenGL errors, but you're not setting glViewport or the PROJECT/MODELVIEW matrices, so your model is probably not visible using the default settings.

I also didn't get any crashes, but I tested on Windows + Oracle JDK. It would be great if you could write a simpler test (preferably in Java) that reproduces the crash.