Java OpenGL pipline and the new VC4 drivers

[knute]

I've been attempting to get Java to run with the OpenGL pipeline in the latest Jessie revision but I have been unsuccessful.

pi@raspberrypi ~/bin $ java -Dsun.java2d.opengl=True -cp cookbook.jar com.knutejohnson.cookbook.DrawFast
OpenGL pipeline enabled for default config on screen 0
unknown NIR ALU inst: vec1 ssa_371 = fddx ssa_316
Aborted

It did work just fine when using the test distro from http://sukzessiv.net/~gohai/vc4-buildbot/build/ but that link now points back to https://www.raspberrypi.org/blog/anothe ... n-release/ which describes the changes to the current Jessie release.

I have all the packages loaded and have set dtoverlay=vc4-kms-v3d in /boot/config.txt.

Anybody got any suggestions?

Thanks,

knute...

[xranby]

The developers of the VC4 driver is aware that Raspbian currently ships with a broken OpenGL setup:
it is _not_ ok to ship a system with two incompatible versions of OpenGL ES side by side because this breaks all applications that tried to load OpenGL ES dynamically such as JOGL and GStreamer.

Only statically linked OpenGL ES applications work with such an odd dual driver setup such as GLXGears and the /opt/vc/src examples.

However we are not the same people who package and maintain Raspbian thus we need to persuade the right people to do the right thing and make sure that only one OpenGL driver implementation is exposed to the applications at one given time.

The easiest workaround you can do is by moving the /opt/vc filer into /opt/vc.disabled
sudo mv /opt/vc /opt/vc.disabled
by doing this you only expose one set of OpenGL drivers to your applications, this enable applications that dynamically link to OpenGL ES to figure out what to do.

A quote from "Eric Anholt" the author of the new VC4 OpenGL driver:
"If they're leaving both libGLESv2s in the link path, we're in trouble. Back when I was working with them in October, we'd talked a boot script moving the libraries such that only one could be found. If they did that, then in some glorious future you could autodetect by asking your EGL if it does X11 using EGL_EXT_platform_x11.txt (if it ever gets implemented). Until then you could hack it up by grepping the EGL vendor for "mesa" I guess."

You may want to read these two bug-reports that deal with the same issue:
https://jogamp.org/bugzilla/show_bug.cgi?id=1290 - Raspberry Pi Raspbian now ship with two incompatible implementations of OpenGL ES
https://github.com/anholt/mesa/issues/2 ... -184451181 - Raspbian integration (two libGLES side-by-side)

[knute]

Thanks very much for your response Xerxes.

I renamed the /opt/vc directory as you suggested and still get the same error when running my Java program.

Any other ideas?

Thanks,

knute...

[xranby]

I re-read your error report:

unknown NIR ALU inst: vec1 ssa_371 = fddx ssa_316

and have now came to a different conclusion...

This bug have been reported to the pi userland bugtracker with an easy reproducer.
https://github.com/raspberrypi/userland/issues/289

Based on some research I think this is why it fails:
I hope the following information is correct:

NIR is a New Intermediate Representation used in the Mesa3D Gallium driver architecture.
The NIR representation is commonly used by many free software drivers in between high level Fixed function OpenGL shaders and the GPU machine code instructions.
GLSL -> NIR -> MachineCode instructions for your GPU
The error you see is missing functionality, Mesa3D do not know yet how to convert the NIR fddx operator into machine code for the vc4 GPU.

The NIR fddx opcode is used to implement accurate derivatives, the following document have some nice images that allows you to understand why derivatives is used in OpenGL:
https://www.opengl.org/pipeline/article/vol003_6/

It appears that the java -Dsun.java2d.opengl=True
swing implementation implicit tries to make use of accurate derivatives
Fixed function OpenGL applications implicit uses accurate derivatives if they enable mipmapped or anisotropic texture fetches.
Unfortunately there is no way to easily disable mipmapped textures using the -Dsun.java2d.opengl=True pipeline.

Here is Eric Anholt's bug/workitem to add DDX/DDY support to the new driver, this is required in order to support accurate derivatives.
https://github.com/anholt/mesa/issues/12
It is possible that this was still not implemented in the vc4 test-builds that "worked" for you. The test builds may not have raised a warning however I would have expected it to render incorrect.

Implementing DDX/DDY into the new driver is my best advice how to fix this issue.

[xranby]

DDX/DDY can be supported by adding the missing implementation for nir_op_fddx and nir_op_fddy into
https://github.com/anholt/mesa/blob/mas ... L819-L1087

Code: Select all

static void
ntq_emit_alu(struct vc4_compile *c, nir_alu_instr *instr)
{
...
switch (instr->op) {
...
case nir_op_fddx:
...
break;
case nir_op_fddy:
...
break;

I need to read up/research a bit more and will then try make a fix for this issue.
https://github.com/anholt/mesa/issues/12

[knute]

Thanks very much for looking into this for me. It worked really well on the test OS and I was looking forward to it being incorporated into the mainstream.

[MostHated]

Was anything ever figured out on this? I can not seem to get it to work properly, I always get the errors when loading a java application in x11 of "glamor0 gl error FBO incomplete". The app then runs at 1 frame every 10-15 seconds. When I turn the driver off, it gets around 12 fps but 85% cpu usage.