Experimental LWJGL rendering (for Apple users?)

Forum for alternative clients, mods & discussions on the same.

Experimental LWJGL rendering (for Apple users?)

Postby loftar » Sun Jul 10, 2022 4:35 pm

In case anyone is interested, I've pushed an experimental rendering branch that adds support for using LWJGL instead of JOGL to call OpenGL. For those unaware, LWJGL is an alternative OpenGL library for Java, which is generally more active and well-maintained than JOGL is these days, which is the main reason why I'm considering switching to it, or at least supporting it as an alternative rendering backend. Among other things, LWJGL supposedly has native support for Apple Silicon Macs (though I can't test this personally, since I don't have an AS Mac), so this may be interesting for Apple users. It is my understanding that the client can already run on AS Macs using Rosetta 2, but at the very least, then, using native LWJGL should increase performance on that platform. It is also my understanding that there are some bugs between later versions of MacOS and JOGL, that using LWJGL instead may fix.

The main reason I haven't merged this to the master branch yet is that the extra indirection layer added to support using either JOGL or LWJGL seems to decrease GL-thread performance on JOGL by about 5%, and I'm still trying to figure out if there isn't some semi-reasonable rewrite that can avoid this penalty. LWJGL is also more "direct" than JOGL is, and increases the general chances of crashing and memory leaks, which is why I wouldn't want to use it by default without some more robust testing first. But the alternative branch is there for anyone who wants to test it. Note than when switching back from the lwjgl branch to the master branch, you will probably have to clean the build tree because of a couple of naming conflicts.
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am

Re: Experimental LWJGL rendering (for Apple users?)

Postby Asor » Mon Aug 22, 2022 11:18 pm

When compiling on a M1 macbook, I got the error
Code: Select all
Exception in thread "Haven main thread" java.lang.UnsatisfiedLinkError: Can't load library: /var/folders/hy/h7v0nq855yqb248wy4njqg8h0000gn/T/lwjgl<user>/3.3.1-SNAPSHOT/liblwjgl3awt.dylib
   at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2398)
   at java.base/java.lang.Runtime.load0(Runtime.java:785)
   at java.base/java.lang.System.load(System.java:1979)
   at org.lwjgl.system.Library.loadSystem(Library.java:179)
   at org.lwjgl.system.Library.loadSystemFromLibraryPath(Library.java:169)
   at org.lwjgl.system.Library.loadSystem(Library.java:124)
   at org.lwjgl.system.Library.loadSystem(Library.java:63)
   at org.lwjgl.opengl.awt.PlatformMacOSXGLCanvas.<clinit>(PlatformMacOSXGLCanvas.java:86)
   at org.lwjgl.opengl.awt.AWTGLCanvas.createPlatformCanvas(AWTGLCanvas.java:26)
   at org.lwjgl.opengl.awt.AWTGLCanvas.<init>(AWTGLCanvas.java:17)
   at haven.LWJGLPanel.<init>(LWJGLPanel.java:57)
   at haven.MainFrame.<init>(MainFrame.java:180)
   at haven.MainFrame.main2(MainFrame.java:407)
   at haven.MainFrame.lambda$main$0(MainFrame.java:443)
   at java.base/java.lang.Thread.run(Thread.java:833)
Asor
 
Posts: 12
Joined: Fri Apr 13, 2012 12:20 am

Re: Experimental LWJGL rendering (for Apple users?)

Postby loftar » Sat Aug 27, 2022 1:35 am

Asor wrote:Exception in thread "Haven main thread" java.lang.UnsatisfiedLinkError: Can't load library: /var/folders/hy/h7v0nq855yqb248wy4njqg8h0000gn/T/lwjgl<user>/3.3.1-SNAPSHOT/liblwjgl3awt.dylib

I'm not really sure what's happening here. My understanding was the lwjgl-awt dropped their dependency on using a native library for MacOS altogether in v3.3.0 or so, so I can't immediately tell why it would be looking for one.

EDIT: Right, it seems I had actually missed updating lwjgl-awt, quite simply. I've done so now, so if you would try again, that'd be swell. Note that you may need to run "ant clean" to properly redownload the library files.
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am

Re: Experimental LWJGL rendering (for Apple users?)

Postby biiont » Sat Dec 31, 2022 8:42 pm

Good choice. Minecraft is using LWJQL too, means it will be well supported in nearest future.
I would like to help with LWJGL on Mac M1.

Could you advise, which version of JDK do you use (OpenJDK/Oracle, 19/17/11/8)?
biiont
 
Posts: 3
Joined: Wed Jul 29, 2015 6:38 am

Re: Experimental LWJGL rendering (for Apple users?)

Postby loftar » Sat May 13, 2023 1:54 pm

I thought I'd update this thread by saying that I've now merged the LWJGL code into the normal client branches, but to be clear, that doesn't mean that the client uses LWJGL by default. It is switchable (at configuration time, not (yet) at runtime) between using JOGL or LWJGL, and JOGL is still the default. However, it means that anyone using the LWJGL code (which I've lead myself to believe that some have been doing) can now use the normal client code again. For anyone wishing to test the LWJGL code (again, perhaps primarily Apple users?), I've also put up a separate launcher that does that, which can be found here:

https://www.havenandhearth.com/java/hafen-lwjgl-launcher.jar

If it is at any point unclear, you can always use the :renderer console command to check what rendering backend is currently in use. It will output some information to the System Log "chat" channel. I should probably also make it clear that JOGL is still the default for a reason. While merged, I still consider the LWJGL code a bit more experimental still, and I know there are a couple of potential crashes and memory leaks that I've still to investigate.

Also, for anyone curious about the 5% performance penalty I mentioned in the OP, I've since done more rigorous performance comparisons, and it turns out to be closer to 1-2%. I'll admit I'm bothered by any penalty at all to something that is fundamentally just doing the same thing, but that kind of penalty felt easier to swallow, and I'm not sure how to improve it. I've looked at the machine code generated by Java for the OpenGL calls, and I while I don't understand everything that the JVM is doing, I can see that some small overhead may be difficult to avoid for the sake of correctness. For anyone interested, I've calculated the overhead to be 15-20 clock cycles per OpenGL call, which does seem a bit excessive for what should just be one extra interface call, but that's apparently where it's at, which, if nothing else, is kind of an interesting data point.

If anyone has any good idea on how to completely eliminate the overhead, I'm all ears, but the only way I've been able to think of (at least in Java) is to effectively duplicate the whole OpenGL backend for both JOGL and LWJGL, just replacing the actual OpenGL calls, and that seems a bit excessive to me.
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am


Return to The Wizards' Tower

Who is online

Users browsing this forum: EnderWiggin, Google [Bot] and 6 guests