LWJGL working on Raspberry Pi in full screen mode

[spasi]

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.

[rupy]

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?

[spasi]

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?

It's much, much worse: simple triangle demo.

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?

No idea, but it'll probably work for non-stereoscopic stuff. We'll eventually need to support OpenVR.

[Cornix]

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?

It's much, much worse: simple triangle demo.

I dont believe it. That shitz is 1400 lines of code... This cant be serious.

[Kai]

Hehe. Now @Spasi scared everyone to stay as far away from Vulkan as possible.

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?"

[spasi]

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.

[rupy]

I think Vulkan is the definition of over-engineered... I'll stick to OpenGL 1.0 for now.

No idea, but it'll probably work for non-stereoscopic stuff. We'll eventually need to support OpenVR.

How do you mean non-stereoscopic stuff, I do all the stereo rendering myself, it's the screen I worried about.

[abcdef]

@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

[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

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.

[abcdef]

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

[abcdef]

@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

[spasi]

Awesome, thanks!

[princec]

Still interested in this Especially LWJGL without having to boot the Pi into a desktop (eg. raw framebuffer mode).

Cas

[rupy]

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?

[Kai]

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