I have managed to get LWJGL 2.8.4 to build and run on the Raspberry Pi. In this github repository (https://github.com/spsn/lwjgl (https://github.com/spsn/lwjgl)) you will find 2 archives with jars and libraries that you may use to build and run your applications on the Raspberry Pi; one for soft float (armel) and one for hard float (armhf). The repository also contains helpful information for getting the Raspberry Pi set up to build LWJGL and the set of files that needed changing to use dispmanx on the Raspberry Pi to create the rendering surface.
For a demo of JWJGL for Raspberry Pi in action, have a look here: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=78&t=22341 (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=78&t=22341)
nice work, thats not a lot of changes to get it to work on the raspberry pi?
nice job on the Blocky too!
(Thanks for dropping by too!)
Cas :)
Now with an official JDK that supports hard floats coming out, I'd say we should think about merging the LWJGL PI modifications into the main repo (looks like very few changes).
Even if we don't provide official PI builds, would be nice to have an option to compile for the PI straight from the main source.
I think official builds would be nice, is it too much work to maintain? Also will a Oculus Rift lib make it into lwjgl?
https://developer.oculusvr.com/forums/viewtopic.php?f=20&t=255 (https://developer.oculusvr.com/forums/viewtopic.php?f=20&t=255)
Sorry to wake this old lady up, but I did some wondering: Are the direct rendering routines present on mobile GPUs but just hidden by the OpenGL ES implementation? Or are the glBegin glEnd etc actually not there at all on the GPU? Because linear algebra is linear algebra, somewhere the logic to draw a triangle exists!
Basically porting my OpenGL 1.0 game to Android is a horrible mess, OpenAL is gone and OpenGL requires buffers... why? No backwards compatibility is really bad, specially when you remove the lower level methods!?
I also draw each triangle to morph the models in real time, to do that with OpenGL 2.0> I have to recruit some designer and build a huuuuge toolchain... programmer art FTW!
Can we interface with Mesa3D on the raspberry pi for example to reach direct rendering?
The old functionality does not exist on mobile hardware. This is because these functions are horribly slow and memory inefficient. It would be too costly to implement these functions in mobile hardware with its limited space and resources. Furthermore since the performance would be abyssmal on the lower tier hardware it wouldnt be used anyway.
Ok, but that's not true, direct rendering with draw lists is really fast.
On modern hardware the GPU will convert your display list code in to a VBO so what you think is a display list is actually a VBO. The GPU knows the best ways to create VBO's so it may seem fast but you can't get away from the fact that VBO's are being used regardless.
Also the fixed pipe line api has been deprecated for a long while now which is why GLES did not support it from the get go, no backwards compatibility was the best thing they could have done.
Also Openal is not gone on android, it was never there
QuoteI also draw each triangle to morph the models in real time, to do that with OpenGL 2.0> I have to recruit some designer and build a huuuuge toolchain... programmer art FTW!
Rubbish! I used to do fixed pipe line and converted over to modern opengl. My morph classes didn't change a single bit, I just changed the classes that used the new morph data. When you full understand opengl 2.0+ you will see how much easier you can do things. The shift mentally is quite a large leap but once you are there you will understand why its better. Stick with it :)
So again necro, but now it seems we have a driver for desktop OpenGL on RaspberryPi, doesen't that open up for all sorts of fun? See this post in particular about LWJGL: https://www.raspberrypi.org/forums/viewtopic.php?p=804047#p804047
How about a desktop OpenGL LWJGL build for the Rpi now?
Quote from: abcdef on March 03, 2015, 06:36:08
no backwards compatibility was the best thing they could have done.
I couldn't agree more, but how do you draw a triangle with less than 3 lines in OpenGL ES?
My game looks like this btw: http://aeonalpha.com if your curious to why the resistance.
Quote from: abcdef on March 03, 2015, 06:36:08
Rubbish! I used to do fixed pipe line and converted over to modern opengl. My morph classes didn't change a single bit, I just changed the classes that used the new morph data. When you full understand opengl 2.0+ you will see how much easier you can do things. The shift mentally is quite a large leap but once you are there you will understand why its better. Stick with it :)
I trust you are right, but I'm an old dog, can't learn to sit properly.
Quote from: rupy on August 17, 2015, 23:35:00So again necro, but now it seems we have a driver for desktop OpenGL on RaspberryPi, doesen't that open up for all sorts of fun? See this post in particular about LWJGL: https://www.raspberrypi.org/forums/viewtopic.php?p=804047#p804047
How about a desktop OpenGL LWJGL build for the Rpi now?
ARM support is not a priority right now. If you would like to help, getting Travis CI to cross-compile for armhf would be a big step forward. This includes LWJGL itself and all its dependencies. Instructions:
- Fork one of the LWJGL CI (https://github.com/LWJGL-CI) repositories. (easiest-to-hardest to get working: jemalloc/libffi -> openal-soft -> glfw -> lwjgl3)
- Create a linux-armhf branch
- Edit .travis.yml to remove the security tokens and the awscli stuff.
- Edit .travis.yml to propertly enable armhf cross-compilation (this is what I need help with)
- Go to https://travis-ci.org (https://travis-ci.org): create an account -> Github sync -> enable the forked repository
If you could get one working, I can probably handle the rest and do any necessary changes to LWJGL itself to support the new architecture.
I'm afraid all of those are way above my head. I code LWJGL because it's Java! ;)
But I understand that you have your work cut out for you, if you somehow get this up and running and my game runs at some kind of framerate on RPi 2 I will build a RPi VR head mount (wearality lenses, RPi 3?! compute module and Rift/Vive screens!) and open source my game engine! :)
I doubt the performance will be good enough, but they are getting there with the driver:
https://www.reddit.com/r/raspberry_pi/comments/3wyemd/opensource_gpu_driver_vc4_status_update/
There, now the OpenGL driver is in raspbian:
https://www.raspberrypi.org/blog/#another-new-raspbian-release
https://www.youtube.com/watch?v=lg2SikcRDZs
Maybe LWJGL should consider a port?
You could wait until the driver is tested and becomes the default I guess?
RPi 3 coming monday, apparently 64-bit possibly ARM8 which would do a lot for performance.
Still no go for LWJGL on RPi?
Still no go. No one has offered help with cross-compiling all the LWJGL stuff yet. I'll get to it myself eventually, but Vulkan, hwloc and doing the 3.0.0 release have priority.
No problem, I'll get a RPi 3 in the mail soon and I'll hopefully manage to install and benchmark the latest VC4 stuff from Anholt too see if it's even worth your time. Seems Anholt's super busy trying to make the driver compliant enough for the foundation to consider using it as default, which is what we need really! http://anholt.livejournal.com
On the hardware side, I'm quite disappointed with the RPi 3 which still is 40 nm (power hungry and hot, the 50% performance increase comes at a 100% power increase), still has a bus that is too slow and too little memory for 64-bit. The GPU speed has been bumped to 400MHz, but apparently you can bump the RPi 2 GPU to that too without issues.
I'm looking at other boards even if that means porting to OpenGL ES which I don't like...
What about Vulcan, to me it seems verbose and super abstract, maybe it's a big leap going from OpenGL 1.0 to Vulcan directly? Can you draw a simple triangle with Vulcan programmatically or is it the same buffers and stuff as ES?
Also, off topic, I'm hoping to be able to get the screen of my HTC Vive with GLFW in LWJGL 3.0, do you think that would work even if it's "undetected" by the desktop and in direct buffer mode?
Quote from: rupy on March 04, 2016, 00:41:19What about Vulcan, to me it seems verbose and super abstract, maybe it's a big leap going from OpenGL 1.0 to Vulcan directly? Can you draw a simple triangle with Vulcan programmatically or is it the same buffers and stuff as ES?
It's much, much worse: simple triangle demo (https://github.com/LWJGL/lwjgl3-demos/blob/master/src/org/lwjgl/demo/vulkan/TriangleDemo.java).
Quote from: rupy on March 04, 2016, 00:41:19Also, off topic, I'm hoping to be able to get the screen of my HTC Vive with GLFW in LWJGL 3.0, do you think that would work even if it's "undetected" by the desktop and in direct buffer mode?
No idea, but it'll probably work for non-stereoscopic stuff. We'll eventually need to support OpenVR (https://github.com/ValveSoftware/openvr).
Quote from: spasi on March 04, 2016, 10:34:54
Quote from: rupy on March 04, 2016, 00:41:19What about Vulcan, to me it seems verbose and super abstract, maybe it's a big leap going from OpenGL 1.0 to Vulcan directly? Can you draw a simple triangle with Vulcan programmatically or is it the same buffers and stuff as ES?
It's much, much worse: simple triangle demo (https://github.com/LWJGL/lwjgl3-demos/blob/master/src/org/lwjgl/demo/vulkan/TriangleDemo.java).
:o
I dont believe it. That shitz is 1400 lines of code... This cant be serious.
Hehe. :) Now @Spasi scared everyone to stay as far away from Vulkan as possible. :D
Yeah, Vulkan is not meant for "I want to draw a single red triangle on the screen" usecases.
It is more for: "I have a thousand animated models which I render using deferred shading with complex material shaders, and use a custom multisample resolve shader and use lots of other post-processing effects compositing things together with explicitly statable dependencies between each other. Now how can I render that in the most efficient way?"
Quote from: Cornix on March 04, 2016, 10:45:36:o
I dont believe it. That shitz is 1400 lines of code... This cant be serious.
Obviously, that's not all setup for a single draw call. Most of it is stuff you'd only be doing once, in any Vulkan program. But if you don't have that code up front, in a library or something, it can be a real pain.
I think Vulkan is the definition of over-engineered... I'll stick to OpenGL 1.0 for now. ;)
Quote from: spasi on March 04, 2016, 10:34:54
No idea, but it'll probably work for non-stereoscopic stuff. We'll eventually need to support OpenVR (https://github.com/ValveSoftware/openvr).
How do you mean non-stereoscopic stuff, I do all the stereo rendering myself, it's the screen I worried about.
@spasi
Do these help out on the arm config?
https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html
https://github.com/bakerface/travis-armhf
Quote from: abcdef on March 06, 2016, 18:38:17Do these help out on the arm config?
https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html
https://github.com/bakerface/travis-armhf
We don't need to emulate running on ARM, we just need to cross-compile LWJGL and its dependencies to ARM.
This is similar to compiling for x86 on the Travis machines which are x64. This was such a pita that we recently dropped support for Linux x86. It was a maintenance nightmare and Travis updates kept breaking the build scripts (the Travis instances do not come with any x86 libraries pre-installed, you have to setup everything from scratch). I don't know how hard this will be for ARM... It might be even easy, I don't know, I'm just not that experienced with Linux and don't have the energy for it (the Travis feedback loop is looooong).
The libraries that must be cross-compiled:
- GLFW
- jemalloc
- libffi
- openal-soft
If someone could provide an example of building (at least one of) the above, I would be very grateful.
I see!
Does this help at all? For jemalloc you should be able to build with
./configure --host=arm-wrs-linux-gnueabi --with-sysroot=$DISTRO/arm-wr6
If I have time on the weekend I will see if I can set up a new travis branch to play around with
@spasi
I found some time this evening to have a quick look at this
I used this config
sudo: true
env:
language: c
compiler: /usr/bin/arm-linux-gnueabihf-gcc
before_install:
- export PATH=$PATH:$HOME/.local/bin
- sudo apt-get install libc6-armel-cross libc6-dev-armel-cross
- sudo apt-get install binutils-arm-linux-gnueabi
- sudo apt-get install libncurses5-dev
- sudo apt-get install gcc-arm-linux-gnueabihf
script:
- ./autogen.sh --with-jemalloc-prefix=je_ --with-malloc-conf=purge:decay --host=arm-linux-gnueabihf
- make
- cd lib
- ls -alrt
- file libjemalloc.so.2
And this was the result of the file command
The command "make" exited with 0.
$ cd lib
The command "cd lib" exited with 0.
$ ls -alrt
total 820
drwxrwxr-x 11 travis travis 4096 Mar 7 19:58 ..
-rwxrwxr-x 1 travis travis 227283 Mar 7 19:58 libjemalloc.so.2
lrwxrwxrwx 1 travis travis 16 Mar 7 19:58 libjemalloc.so -> libjemalloc.so.2
-rw-rw-r-- 1 travis travis 289702 Mar 7 19:58 libjemalloc.a
-rw-rw-r-- 1 travis travis 309850 Mar 7 19:58 libjemalloc_pic.a
drwxrwxr-x 2 travis travis 4096 Mar 7 19:58 .
The command "ls -alrt" exited with 0.
0.02s$ file libjemalloc.so.2
libjemalloc.so.2: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xf3ee59149449d927a396c62610516334441b8fed, not stripped
The command "file libjemalloc.so.2" exited with 0.
Done. Your build exited with 0.
You should be able to adapt this to load the resulting file in to aws
Awesome, thanks!
Still interested in this :) Especially LWJGL without having to boot the Pi into a desktop (eg. raw framebuffer mode).
Cas :)
Talking about that, I'm mustering the courage to port to LWJGL 3.0 to see if GLFW can detect the Oculus DK2 as a monitor. Do you guys know if it should be able to?
Quote from: rupy on March 16, 2016, 21:34:58
Talking about that, I'm mustering the courage to port to LWJGL 3.0 to see if GLFW can detect the Oculus DK2 as a monitor. Do you guys know if it should be able to?
Yes ---> http://www.glfw.org/docs/latest/rift.html
Yep saw that too but Stellas JRift 0.8 does not expose this Ovr method what I can find:
ovrHmd_AttachToWindow
There's no ovrHmd_AttachToWindow in recent versions of the Oculus SDK.
Ok, so how would one go about getting the DK2 monitor?!
getMonitors() only returns the primary monitor.
PointerBuffer buffer = glfwGetMonitors();
System.out.println(buffer.get() + " " + glfwGetPrimaryMonitor());
returns something like: 3450336 3450336 and is length 1 no matter which state the DK2 is in; off, on with orange light or on with blue lights on both headset and camera.
Afaik, you need to use something like Virtual Desktop (http://www.vrdesktop.net/).
Ok, apparently the Vive still has extended! Problem solved!
Edit: it works but the fresnel lenses are flareing, Valve won't release antiflare shader either: I'm off VR until I get WebVR working in the Vive.
Edit2: Got WebVR working my the Vive, it's so cool: https://webvr.info/samples/
And apparently someone ported LWJGL to the Pi: https://www.raspberrypi.org/forums/viewtopic.php?p=911808
they ported LWJGL 2x, hopefully spasi will get some time to add the arm format to the official builds now that 3.0.0 is out.
I use 2.0 (like minecraft) so I don't care about 3.0... I wish somebody told me this could be done so simply:
http://rogerallen.github.io/jetson/2014/07/31/minecraft-on-jetson-tk1/
Oh well, better late than never.