Currently the GPU plugin do not runs on macOS, even after adding JOGL natives for macOS the plugin still do not works because the minimum required GL version is 4.3+ because we use compute shaders. Even after this would be solved, it do not works because of JOGL (the screen just freezes/GL context fails to create). Solutions are - move compute shaders to OpenCL and switch to different library (tested with LWJGL2, works well, but same issue as with Linux, input needs to be proxied, do not tested with LWJGL3 but with their JAWT it might work) or move everything to Vulkan (with LWJGL3 again) and MetalVK (what runs vulkan on top of metal, works out of the box with LWJGL3).There is an open bounty for implementing this feature. I'll just dump some information here, as quite a lot of this is over my head at the moment and if I don't write it down I'll probably forget it.We can use to render using Vulkan (Metal on macOS).
![]()
Since version 3 its implementation uses GLFW - which we cant use because it does not work with AWT. This implementation works fine using both OpenGL and Vulkan on Windows and using OpenGL on Windows and Linux.We would need to write an implementation for macOS here. We should use JAWTVERSION17 since anything lower would not be able to get a valid drawing surface, not without passing JAWTMACOSXUSECALAYER and implementing both variants in the native bridge. I'm willing to look into this more, though I don't necessarily have a timeline for it. Before I get going though, I do see two initial sets of obstacles where I would appreciate some guidance.
I haven't worked with maven previously, and I'm not sure how to add the JOGL natives for mac to the project. My understanding though is that with the fixes for Linux already implemented, no work should be required on this front other than adding the JOGL natives. In order to convert the openGL compute shaders to openCL, I'll have to first understand in depth what the current rendering pipeline is actually doing, namely in Drawin GPUClient.java as well as the specific tasks of the compute shaders. My understanding is that Adam wrote the GPU plugin himself, would he be the best person to reach out to? At the moment I've done some initial exploring and have accomplished three things:. Commented out what I believe is all compute shader related code. Added mac natives.
![]()
Set glcaps to use FrameBuffer Objects on Mac as there is a crash otherwiseMy goal through these stages was to have a blank runnable slate that I could use as a starting point for moving the compute shaders to openCL. However, I have run into two potential issues.
Toggling the gpu plugin on results in the game window (including the RS UI) freezing. Calls to draw are made and it sounds as if I can still click buttons, so I do not believe the game is frozen. While this behavior is different than the behavior I expected, which was for the UI to remain responsive while the play area was a mess, I wanted to ask if this is how forcefully yanking all of the compute shader code would be expected to affect things. Alternatively, I could see it being the case that the game is rendering a mess offscreen. Toggling the GPU plugin off results in the following error, which causes a JVM crash. I'm not sure if this error is Mac specific, if it is the result of enabling use of a FrameBuffer Object, or if it is the result of my commenting code out.
Operating system requirements: For Java 7 and later versions, you will need an Intel-based Mac running Mac OS X version 10.7.3 (Lion) and above. Installing Java on a Mac is performed on a system wide basis, for all users, and administrator privileges are required. Java can not be installed on a per-user basis. For Mac users, you’ll see a.dmg folder. Open the folder to see the files inside. Drag the application file from the.dmg folder you’re currently in to the Applications folder. This will start the installation process.
It seems to be thrown somewhere inside of NewtFactoryAWT.destroyNativeWindow(jawtWindow); from inside of shutDown, though I'm not sure exactly where. I've found some people reporting similar sounding issues, but I've not seen any resolutions.# A fatal error has been detected by the Java Runtime Environment:## SIGSEGV (0xb) at pc=0xe10f4e, pid=44188, tid=775## JRE version: Java(TM) SE Runtime Environment (10.0.1+10) (build 10.0.1+10)# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0.1+10, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)# Problematic frame:# C libosxapp.dylib+0x2f4e -NSApplicationAWT sendEvent:+0x179My branch is available here. That's not all that is needed, but that is the basic idea. I've run into a problem though. In addition to the setting the surface scale, gl calls like glViewport and glTexImage2D that are dependent on a height and width also need to be scaled. The problem is that this causes a crash when scaling glTexImage2D because client.getBufferProvider doesn't provide a big enough buffer, it doesn't consider scaling.
Pretty sure that's necessary for supporting display scaling. The buffer provider comes from obfuscated code:(, but before investigating further I'm wondering if linux or windows users end up having a blury display when using the current GPU plugin on HiDPI displays while using Java 9 or greater. Java 9 added HiDPI support for windows and linux.
It was already supported for Mac in earlier versions. So I'm guessing they have the same problem. Previous to java 9, AWT/Swing wouldn't scale on windows and linux and so you would see the actual pixel counts. Sorry for my disappearance, got busy and then distracted with other things.
Here is the mess I had, didn't do any cleanup before commiting:. I also didn't check if the scaling issues were fixed with.So next step, aside from taking the above and making it sane, is converting the compute shaders to openCL kernels and using openCL to write to the openGL buffers. I'd start with just getting the CL/GL inter-op working with something simple before jumping right into the kernels. Shows how buffers can be shared using jocl.If anyone decides to play around with this, feel free to reach out. If not here than on discord, if you @ me in the development room, I should respond now. I did the ghauth thing so I can chat there again.
![]() Comments are closed.
|
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |