FS-UAE port for GLES/OpenPandora

[lallafa]

I continued the work of linuxboch's fs-uae-gles to have OpenGL ES support for our favorite Amiga emulator.

For OpenPandora Users pre-compiled PNDs can be found on my github download page.

The GLES patches are applied to current devel 2.1.x and stable 2.0 branches from Frode's git tree and located on my github site.

Currently only Pandora builds are supported, but the GLES parts should work for other platforms as well. In fact I'll play with the Raspi next

@Frode: As the patches apply cleanly on the current mainline and will happily co-exist with the current source (i.e. without breaking it ) you might consider including them in your tree, too... You can either pull from my git repo directly or I can prepare you patches if you like.

[FrodeSolheim]

Hi, I have pulled the changes into a local branch and I'm checking out the changes

I'll consider merging it into the main source tree, though I would make a few minor changes and use #ifdefs to better separate the GLES and EGL stuff, for example replace HAVE_GLES with USE_GLES and USE_EGLPORT. And the only use USE_GLES to indicate that the OpenGL ES subset of OpenGL should be used. This way, the OpenGL ES code can be compiled/tested on regular desktop computers as well.

In the future, I may restructure the code so the OpenGL and OpenGL ES stuff can be better separated. The code does get a lot messier (at least longer) with lots of #ifdef HAVE_GLES..

By the way, I see GL_RGB5 stuff is #ifdef-ed out (obviously, since this does not exist in OpenGL ES), but perhaps you should try to enable/use 16-bit video format on Pandora, it may be faster? (I don't know whether the Pandora uses or can use 16-bit texture formats internally with GL_RGB). At least, copying buffer data around will be faster

Try setting the following combination:

g_fs_emu_video_format = FS_EMU_VIDEO_FORMAT_R5G6B5;
g_fs_emu_video_bpp = 2;
g_fs_emu_texture_format = GL_RGB;

How's the speed when emulating A500? I assume you must run with accuracy = 0 (or -1) and perhaps video_sync = off...

[lallafa]

Hi,

feel free to adjust the patch before inclusion!
It would be great if it will be included in the mainline source
Thanks for your effort!

Yes, some restructuring of the render code in the future will clean up the large sets of #ifdefs currently required. Maybe some quad render functions for typical cases (color, texture coord) will help here.

Thanks for the the hint with RGB + 2 bpp! It really works fine and gives some extra boost... I have adjusted the code to allow "rgb565" on GLES, too and use RGB instead of RGB5.

Performance is still poor on my 800 MHz Pandora

I am testing FS-UAE 2.0 on an A500 with vsync off, accuracy 0 and benchmark mode (CTRL+F9 or CTRL+F10 in live mode) in Turrican title screen.

default video mode: average fps sys: 13.3 emu: 13.7
rgb565 video mode: average fps sys: 17.6 emu: 17.5

accuracy -1 does not affect those values

Are there any performance traces I could enable to analyse the performance bottlenecks further?

(Sidenode: 2.1.x seems to have lost audio completely... audio debug in CTRL+F10 mode also shows 0.0 and a flat line all the time... hmm... any idea?)

[FrodeSolheim]

Well, I did voice my concern for the performance over at the openpandora forum: :-/
http://boards.openpandora.org/index....40#entry143666

I assume the main problem is that this UAE codebase is not optimized for low-powered devices and ARM architecture, like the UAE2ALL variants are. There can also be inefficiencies in the libfsemu layer, but I don't know of any possible fix which would triple performance...

Regarding audio, there hasn't been any changes to the audio system since 2.0... -perhaps the Pandora patches have accidentally disabled some part of the audio initialization?

[lallafa]

Yes, it really looks like that the raw CPU power on the platform is not sufficient for the newcpu m68k emulation and the Amiga core in FS-UAE. While graphics rendering is supported by the GPU these tasks have to be done on the CPU. Thats probably the reason why uae4all replaced newcpu with the FAME m68k emulator.

Nevertheless, the GLES port is in place now and allows us to analyse potential improvements on these platforms.

In my repository I added support for the Raspberry Pi and restructed the GLES build process to be less intrusive for the main build files. OpenGLES is a sub-type of the Linux/Posix build now and all platform specific stuff is moved to platform-specific Makefiles in sub-directories that call the main build (see raspi and pandora dirs).

I also played around a bit with the Launcher on the Pandora. It works as expected but the current layout is not really suitable for the 800x480 display. Do you see an easy fix for that (e.g. by optionally changing font size or reduced spacing between the elements) or is a complete redesign of the GUI required in this case?

Originally Posted by lallafa

Yes, it really looks like that the raw CPU power on the platform is not sufficient for the newcpu m68k emulation and the Amiga core in FS-UAE. While graphics rendering is supported by the GPU these tasks have to be done on the CPU. Thats probably the reason why uae4all replaced newcpu with the FAME m68k emulator.

Nevertheless, the GLES port is in place now and allows us to analyse potential improvements on these platforms.

In my repository I added support for the Raspberry Pi and restructed the GLES build process to be less intrusive for the main build files. OpenGLES is a sub-type of the Linux/Posix build now and all platform specific stuff is moved to platform-specific Makefiles in sub-directories that call the main build (see raspi and pandora dirs).

I also played around a bit with the Launcher on the Pandora. It works as expected but the current layout is not really suitable for the 800x480 display. Do you see an easy fix for that (e.g. by optionally changing font size or reduced spacing between the elements) or is a complete redesign of the GUI required in this case?

Any updates? I would like to run FS-UAE on my raspberry pi :-)

Ive been trying to get this to run on the Raspberry Pi.

It compiles fine with the raspi makefile, and i had to move vchost_config.h from /opt/vc/include/interface/vmcs_host/linux/ to the parent directory.

However whenever i try to run this in X the FS-uae window pops up briefly then disappears at EGL Create window surface. My log is below, can anyone help?

FS-UAE VERSION 9.8.7
Copyright 1995-2002 Bernd Schmidt, 1999-2012 Toni Wilen,
2003-2007 Richard Drummond, 2006-2011 Mustafa 'GnoStiC' Tufan,
2011-2013 Frode Solheim, and contributors.

This is free software; see the file COPYING for copying conditions. There
is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the README for more copyright info, and the source code for
a full list of contributors

logging to /home/pi/.local/share/fs-uae/fs-uae.log
libamiga (based on emulation core from WinUAE 2.5.1) initialized
logging to /home/pi/FS-UAE/Logs/FS-UAE.log.txt
xrandr: Failed to get size of gamma for output default
xrandr: Failed to get size of gamma for output default
EGL Opening EGL display
EGL Initializing
libEGL warning: GLX/DRI2 is not supported
libEGL warning: DRI2: failed to authenticate
libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)
EGL Implementation Version: Major 1 Minor 4
EGL_VENDOR: Mesa Project
EGL_VERSION: 1.4 (Gallium)
EGL_EXTENSIONS: EGL_KHR_image_base EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_surfaceless_gles1 EGL_KHR_surfaceless_gles2 EGL_KHR_surfaceless_opengl 
EGL Found 8 available configs
EGL config #0: r=8 g=8 b=8 a=8 d=16  l=0
EGL config #1: r=8 g=8 b=8 a=8 d=24  l=0
EGL config #2: r=8 g=8 b=8 a=8 d=24  l=0
EGL config #3: r=8 g=8 b=8 a=8 d=32  l=0
EGL config #4: r=5 g=6 b=5 a=0 d=16  l=0
EGL config #5: r=5 g=6 b=5 a=0 d=24  l=0
EGL config #6: r=5 g=6 b=5 a=0 d=24  l=0
EGL config #7: r=5 g=6 b=5 a=0 d=32  l=0
EGL Using Config 0
EGL Binding API
EGL Creating Context
EGL Creating window surface
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  14 (X_GetGeometry)
  Resource id in failed request:  0x37d3304
  Serial number of failed request:  7
  Current serial number in output stream:  7
AL lib: ReleaseALC: 1 device not closed

[lallafa]

Originally Posted by critic

It compiles fine with the raspi makefile, and i had to move vchost_config.h from /opt/vc/include/interface/vmcs_host/linux/ to the parent directory.

Thanks, for pointing out... I added the missing include.
Seems to be added in one of the latest pi updates...

Originally Posted by critic

However whenever i try to run this in X the FS-uae window pops up briefly then disappears at EGL Create window surface. My log is below, can anyone help?

FS-UAE VERSION 9.8.7
EGL_VENDOR: Mesa Project
EGL_VERSION: 1.4 (Gallium)

That looks wrong... The reported EGL is the SW emulation implemented by Mesa and not the Raspi HW...

If I run the binary I get:

EGL Opening EGL display
EGL Initializing
EGL Implementation Version: Major 1 Minor 4
EGL_VENDOR: Broadcom
EGL_VERSION: 1.4

Make sure to have no mesa includes/libs around when compiling...
Check your linked libs:

> ldd fs-uae | grep GL
	libEGL.so => /opt/vc/lib/libEGL.so (0xb6c9c000)
	libGLESv2.so => /opt/vc/lib/libGLESv2.so (0xb6c7f000)

Fixed, thanks! I had the libgles-mesa-dev packages installed.

After recompiling i had problems initially with the display, the amiga window was all white and only displaying text overlays, eg the F12 menu text displayed fine. After increasing memory to the GPU and adding some options to Default.conf i finally watched my little PI boot an amiga disk!

My current config is :

amiga_model = A600
kickstart_file = kick.rom
video_format = rgb565
texture_format = rgb
video_sync = off
accuracy = -1
fullscreen = 0
floppy_drive_0 = /home/pi/magic.adf

Im running on the latest raspbian image with pi clocked at 900mhz . Performance is very slow as expected, and fs-uae is only taking up around 1/3 of my screen. (hdmi/tv res is 1280x768@60hz)

Keyboard input if booted from the commandline is very unresponsive (opening/closing F12 menu)- strangely this is not a problem if launching Fs-uae inside Xwindow manager.

Today i shall try again with a clean raspbian image, remove any unneeded services, lower screen resolution, set 50hz, etc to see if i can squeeze any more performance from this.

Since this requires SDL libraries to compile i also wonder if Vanfanels SDL-dispmanx build will help http://www.raspberrypi.org/phpBB3/viewtopic.php?t=25146

Thanks for your efforts bringing this software to GLES platforms

[lubomyr]

Originally Posted by FrodeSolheim

I assume the main problem is that this UAE codebase is not optimized for low-powered devices and ARM architecture, like the UAE2ALL variants are. There can also be inefficiencies in the libfsemu layer, but I don't know of any possible fix which would triple performance...

I think uae4all2 very fast works, because use FameC cpu core which very fast works with ARM devices.