2

I'm currently porting an open-source OpenGL game to OpenGL ES. The target device runs Linux and has a relatively weak CPU (ARM11 family, with FPU). It has an OpenGL ES accelerator but not an OpenGL one.

Initially I want to get the existing OpenGL-GLX-X11 implementation to run, using an accelerated OpenGL instance on another Linux machine - for example, an Athlon X2 with a Radeon X1650 Pro. This will help to verify that there are no serious CPU bottlenecks that need to be sorted out at a high level.

I have managed to set up SSH forwarding of the X11 connection. The glxinfo and glxgears programs run, but the latter has very poor performance (8fps) compared to a locally running glxgears (60fps with vsync). The glxinfo report stated that Direct Rendering is being used, which tells me that the local (to the ARM device) software renderer is being used.

What I want to happen is for OpenGL commands to be sent to the Athlon X2 machine and accelerated using the Radeon. I believe I need to turn on Indirect Rendering for this. However, setting LIBGL_ALWAYS_INDIRECT=1 does not change anything. For example:

arm$ LIBGL_ALWAYS_INDIRECT=1 glxinfo | fgrep rendering
direct rendering: Yes
arm$

The ARM device is running Gentoo Linux. What is the best way to force what I want to happen?

Charles
  • 50,943
  • 13
  • 104
  • 142
Chromatix
  • 1,143
  • 8
  • 12
  • So, I've tried rebuilding Mesa without the Gallium backend. This didn't help. Are there any more suggestions? NB: I can do the port without this, but it's annoying me that something that should work doesn't. – Chromatix Jul 05 '12 at 13:42

1 Answers1

1

The glxinfo and glxgears programs run, but the latter has very poor performance (8fps) compared to a locally running glxgears (60fps with vsync). The glxinfo report stated that Direct Rendering is being used, which tells me that the local (to the ARM device) software renderer is being used.

I'm a bit puzzled by this. If you see the OpenGL output on the remote display, then this would mean that instead of GLX commands pictures are transmitted. This however would mean, that the libGL.so on your host device is X11 aware for its output, but won't use GLX.

Could you please determine which package contributes the libGL.so on your ARM device. I suggest you install a separate libGL.so with only GLX command generation and LD_PRELOAD that.

Mesa3D can be configured to build GLX command stream generator library.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • Mesa provides libGL.so, as expected. It's not immediately clear to me how to tell Gentoo to produce this "reduced" version of the library, though. – Chromatix Jul 04 '12 at 20:21
  • @Chromatix: Following USE flags: "classic -gallium shared-glapi" you may also want to remove all videocard flags. – datenwolf Jul 04 '12 at 20:42
  • I'll try that. Might take a while - as I sad, ARM11 is a little weak. I also found a package called virtualgl while trying to track the provenance of GLX, might be worth trying that too. – Chromatix Jul 04 '12 at 20:54
  • Unfortunately virtualgl does the *opposite* of what I want. :( I'll just have to wait for mesa to rebuild. – Chromatix Jul 04 '12 at 21:15
  • 1
    @Chromatix: Mesa is not a terribly large build. You **are** cross compiling, are you? (Yes, I know, cross compiling is a drag, because the GNU toolchain is so messed up, but sometimes unavoidable) At least Gentoo offers it's crossdev package to ease the installation of cross toolchains. – datenwolf Jul 04 '12 at 21:48
  • If I really cared, I could plug the card into a faster ARM device and chroot-build stuff about four times as fast. However, rebuilding Mesa with only the Classic backend enabled didn't help - it is still behaving as before. – Chromatix Jul 05 '12 at 02:17