Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building at Raspberry Pi 2 B+ #7479

Closed
gamelaster opened this issue Feb 15, 2015 · 166 comments
Closed

Building at Raspberry Pi 2 B+ #7479

gamelaster opened this issue Feb 15, 2015 · 166 comments
Milestone

Comments

@gamelaster
Copy link

Heya,

Today i trying to build on my RPI a PPSSPP, but i still failure becouse libswresample has not found.

/home/pi/Desktop/ppsspp/Core/HLE/sceAtrac.cpp:95:38: fatal error: libswresample/swresample.h: Directory or file not exists

I searched alot about that and i found its becouse of ffmpeg, but i installed ffmpeg, but anyway, i probably need a ffmpeg-dev, but thats not for RPI...

Any ideas?

//EDIT: after some exploring i found that file in Hrydgards FFMPEG repository. That repository i got, and i found that file in my "solution". So i dont know why the sceAtrac cant found swresample.h ...

@hrydgard
Copy link
Owner

We use a patched ffmpeg so we should make a rasp-2B specific prebuild and put in ppsspp-ffmpeg. It should not be very hard to tweak the existing Linux build script that's in there...

I'm getting a rasp-2B myself but won't get to it for a little while.

@gamelaster
Copy link
Author

Awesome, anyway, i can participate with anything about RPI!
Anyway, i tried some stuffs to edit to be works, but when i changed a paths to full path (with ffmpeg), then that library got other errors with path. But others similiar libraries in FFMPEG including at sceAtrac.cpp has been included good 😆

@unknownbrackets
Copy link
Collaborator

Instead of changing paths, leave everything alone. The code should be okay to build.

The only paths you might change are in CMakeLists.txt, not in any cpp or h file. But first you need to run a script in the ffmpeg/ subdirectory to create the ffmpeg .a files. You'll create the script by modifying this:

https://github.com/hrydgard/ppsspp-ffmpeg/blob/master/linux_arm.sh
(it might just work as-is.)

Once that is built, ffmpeg libraries will exist inside ffmpeg/. This is where ppsspp expects them, and ppsspp should be able to build.

If you're changing any lines that have #include in them, you're changing the wrong thing.

-[Unknown]

@sergiobenrocha2
Copy link
Contributor

You must change -mfloat-abi=softfp to -mfloat-abi=hard in linux_arm.sh, and delete GENERAL stuff for cross-compile. And delete build_ARMv6 too.

@gamelaster
Copy link
Author

sergiobenrocha2: I know to delete ARMv6 build, already deleted. I tryied to delete general stuff for cross-compile, but anyway, i didnt found another way how to compile FFMPEG without cross-compile (if u look at original ffmpeg build process in Raspberry Pi, anyway u must install cross-tools). So, i will see if that helps... But in Raspberry Pi takes very long to install and patch toolchain and other stuffs, what made build (if i integrate the time to first build) more than hour. 20 minutes to download tools (its not failure of my internet), next 10 minutes to extract and patch etc. I actually work on that so i will write my result. Anyway, thanks for the idea to edit linux_arm.sh ! :P

//EDIT: OMG -_- installing crosstool is ... ah, 3 hours i trying to install.. 2 times RPI frozen... I think i will be must overclock that.

//EDIT 2: I think the best way has been to providing the compiled version of PPSSPP, i grab this todo, i will be doing the builds for RPI :) Becouse installing PPL for host in toolchain wants so much time & and power, so probably it will works only on overclocked devices (already testing on nooverclocked)

@sergiobenrocha2
Copy link
Contributor

Ahh, so you use cross-compiler instead of build in the rpi. Well, I use an odroid u3, it does not take many time to compile stuff, dunno about rpi B+.

I can compile here and send a PR, but I don't know the preferable gcc version and other stuff to make sure it will work in all distros, not only in ubuntu 14.04.

@gamelaster
Copy link
Author

Oh im dumb, why i making cross compiler on RPI :D ... Anyway, so when i want to do works a PPSSPP build on RaspBian, i must compile ARM version of modified FFMPEG on x86 Ubuntu and move it to PPSSPP project or how? I will going to try it, im little bit new in C/C++ so i must try it to do :P .

Anyway, i can try on my RPI anything, so we can try it. Just write me on IRC ppsspp (GAMiEE)

//EDIT 20:44 - So i installed cross-tool and others on my Ubuntu and suceffuly compiled FFMPEG for ARMv7 with edited script of build_arm.sh and Build instructions at FFMPEG wiki for Raspberry pi. So im going to copy that version and try to build that at RPI :P
//EDIT 21:40 - FFMPEG build failed, the linux/armv7 has not created, so IDK what builded O_O but prefix path has been setted good O_O actually disoriented -.-

@gamelaster
Copy link
Author

Today i successfull builded PPSSPPSDL on my RPI, but i got here a problem with launch:

libEGL warning: DRI2: failed to authenticate
SDL_CreateWindow failed: Could not initialize OpenGL / GLES library

I really dont get idea where is problem... Mesa libraries has been installed, but im little misunderstand becouse idk if i have installed SDL2 so if that has been not trouble.. Any ideas?

//EDIT: So i now building SDL2 on my RPI , so we will see... Question, i need again to rebuild a PPSSPP with SDL2?

@hrydgard
Copy link
Owner

I don't know, but please keep reporting your progress, it's useful :)

@Bigpet
Copy link
Collaborator

Bigpet commented Feb 17, 2015

ppsspp usually dynamically links to sdl2 so unless you linked it in statically or the headers changed you should not need to rebuild ppsspp

@gamelaster
Copy link
Author

SDL2 installed, works, i recompiled full PPSSPP, but still got error, but its some other:

libEGL warning: DRI2: failed to authenticate
SDL_CreateWindow failed: Couldn't find matching GLX visual

I think the main problem is the warning what makes SDL_CreateWindow fail. Now i didnt get idea, im stay still googling about this 2 errors and we will see :/

@hrydgard
Copy link
Owner

"failed to authenticate"? try running it as root? (shouldn't be needed, but hey...)

@gamelaster
Copy link
Author

Tryied, failed. I think is problem on side SDL, i checked SDL source files and i found he exception when is thrown, and its when trying to get access to Monitor/Display. I will continue to search..

//EDIT: When is available Qt (on linux is little bit buggy, but.. :P ), i can try build Qt version, but that take some more time than normal build (on Ubuntu takes build Qt long, so in RPI lol :D )

//EDIT2: Qt build attempting error with some files, its not files for ARM, so its can be global trouble (at all Qt builds), i will write what troubles, but first im someone writes me to try build Libretro-ppsspp so we will see! :)

//EDIT3: Same result as default PPSSPP, + libretro ppsspp has been working (as i seen), but idk why its not works, i still think is trouble in SDL side, but anyway, i try to fix that bug from source code, but if failure, i try to fix bug in Qt build :)

//EDIT4: Its really crazy... :D Someone got this trouble too, i looked at that but anyway still same error http://raspberrypi.stackexchange.com/questions/3285/sdl-couldnt-find-matching-glx-visual
Now trying to again rebuild that, we will see :P

@gamelaster
Copy link
Author

After some troubles i again reruned the build PPSSPP to Raspberry! Actually still got problems with building. Actually is all builds successfull but linking have trouble! I reinstalled Raspbian, but i didnt get this error on my build O_o i probably installed something what fix this, but i cant find now what has fixed that...
Linking CXX executable PPSSPPSDL
lib/libCore.a(Framebuffer.cpp.o): In function FramebufferManager::ClearDepthBuffer()': Framebuffer.cpp:(.text+0x1430): undefined reference toglClearDepth'
lib/libCore.a(Framebuffer.cpp.o): In function `FramebufferManager::ClearBuffer()':

Its looks like missing some OpenGL headers, but idk, i tried update RPI firmware what contains /opt/vc/ but not helped. I installed almost all MESA libraries, but again not helped. Fully disoriented and without idea... But probably, if i solve this trouble, its may to works good...

BTW, Qt build failed too, error:
Common -I../ffmpeg/linux/armv7/include -I../../ppsspp -I../native -I../native/ext/glew -I/usr/X11R6/include -I.moc/GPU -I. -o .obj/GPU/Rasterizer.o ../GPU/Software/Rasterizer.cpp
../GPU/Software/Rasterizer.cpp: In function ‘void Rasterizer::DrawLine(const VertexData&, const VertexData&)’:
../GPU/Software/Rasterizer.cpp:1503:1: error: unrecognizable insn:
(insn 2246 2245 2247 13 (set (reg:HI 2 r2)
(reg:SI 73 s10)) ../GPU/Software/Rasterizer.cpp:1488 -1
(nil))
../GPU/Software/Rasterizer.cpp:1503:1: internal compiler error: in extract_insn, at recog.c:2123

@unknownbrackets
Copy link
Collaborator

I think you're not getting USING_GLES2 defined for some reason, but using GLES2 libs. I think you want that defined.

The Qt thing, "unrecognizable insn"? That seems bad. What version of gcc?

-[Unknown]

@gamelaster
Copy link
Author

[Unknown](u have awesome name :D), i didnt changed CMakeList or anything, all is default. My gcc version is 4.7 (i can check more, but 100% i have 4.7, but i have installed 4.6 too, but i selected 4.7 by update-alternatives). Someone telled me to add -lGL and -lX11 to the linker, but idk how... :/ I now going to try build libretro ppsspp what works?!? :-)

@unknownbrackets
Copy link
Collaborator

Hmm, not sure, but try adding USING_GLES2 to CMakeCache.txt. It's a user option:

option(USING_GLES2 "Set to ON if target device uses OpenGL ES 2.0" ${USING_GLES2})

It's not on by default with RPI, not sure if it should be.

-[Unknown]

@steevp
Copy link

steevp commented Feb 20, 2015

I had better success building the libretro core

$ git clone https://github.com/libretro/libretro-ppsspp.git
$ cd libretro-ppsspp
$ git submodule init && git submodule update
$ export CC=gcc-4.8
$ export CXX=g++-4.8
$ export CFLAGS="-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -I/opt/vc/include"
$ export CXXFLAGS="$CFLAGS"
$ export LDFLAGS="-L/opt/vc/lib"
$ cd libretro
$ make platform=imx6 -j4

The compiler gives 'conflicting specifier' errors for these lines in gl3stub.h (had this problem with the standalone version, too). If I remove extern from those lines, the code compiles and links without errors

But now when I try to load the libretro core, it gives a bunch of 'undefined symbol' errors (probably related to the change I made above I guess?). I got rid of most of them by removing most of the code in the gl3stubInit function in gl3stub.c, leaving just:

GLboolean gl3stubInit() {
return GL_FALSE; // also tried GL_TRUE - I have no idea what I'm doing
}

The last remaining undefined symbol was glBlitFramebuffer, so (again not knowing what I'm doing) I removed every reference to it in GPU/GLES/Framebuffer.cpp and GPU/GLES/StencilBuffer.cpp

Now the libretro core loads and I can launch Tekken 6. It plays the intro movie and gets to the "Press start" screen, but then it crashes after I press start:

RetroArch [WARN] :: udev_input_init :: [udev]: Couldn't open any keyboard, mouse or touchpad. Are permissions set correctly for /dev/input/event*?
W: ../native/file/file_util.cpp:220: W: IsDirectory: stat failed on /home/pi/system/PPSSPP/lang/.ini
RetroArch [WARN] :: udev_input_init :: [udev]: Couldn't open any keyboard, mouse or touchpad. Are permissions set correctly for /dev/input/event*?
RetroArch: rarch_log_libretro: [libretro INFO] :: Context reset!
I: ../native/gfx/gl_lost_manager.cpp:50: I: gl_lost() restoring 0 items:
I: ../native/gfx/gl_lost_manager.cpp:55: I: gl_lost() completed restoring 0 items:
I: ../native/gfx_es2/gl_state.cpp:137: I: GPU Vendor : Broadcom ; renderer: VideoCore IV HW version str: OpenGL ES 2.0 ; GLSL version str: OpenGL ES GLSL ES 1.00
I: ../native/gfx_es2/gpu_features.cpp:20: I: Checking for GL driver bugs... vendor=7 model='VideoCore IV HW'
W: ../native/file/file_util.cpp:220: W: IsDirectory: stat failed on /home/pi/system/PPSSPP/flash0/font/jpn0.pgf
Failed to load ppge_atlas.zim.

Place it in the directory "assets" under your PPSSPP directory.
W: ../native/file/file_util.cpp:220: W: IsDirectory: stat failed on /home/pi/system/PPSSPP/shaders
I: ../native/file/zip_read.cpp:359: I: Not a VFS path: /home/pi/system/PPSSPP/PSP/shaders . Reading local directory.
W: ../native/file/file_util.cpp:220: W: IsDirectory: stat failed on /home/pi/system/PPSSPP/flash0/font/jpn0.pgf
I: ../native/gfx_es2/fbo.cpp:194: I: Creating 512 x 1 FBO using separate stencil
I: ../native/gfx_es2/fbo.cpp:194: I: Creating 512 x 272 FBO using separate stencil
glGetError 0x500
I: ../native/gfx_es2/fbo.cpp:194: I: Creating 480 x 272 FBO using separate stencil
glGetError 0x500
I: ../native/gfx_es2/fbo.cpp:194: I: Creating 480 x 272 FBO using separate stencil
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
glGetError 0x500
pure virtual method called
terminate called without an active exception
Aborted

@robertybob
Copy link

Great progress @steevp ! How smoothly does the video play?

@steevp
Copy link

steevp commented Feb 20, 2015

The video was very smooth, everything seemed to be running full speed up until the point that it crashed (though I never actually got into gameplay)

The only other game I tried was Vice City Stories, which crashed immediately with:

pure virtual method called
terminate called without an active exception 
Aborted

I'll try some more games just to see if something works, but I'm sure I probably broke something by removing all those lines

@hrydgard
Copy link
Owner

"pure virtual method called" is almost always from trying to call a method on a deleted object, of some sort. Can you get a callstack? (run in gdb or lldb, type bt after the crash)

@steevp
Copy link

steevp commented Feb 20, 2015

@hrydgard Anything useful here?

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7403c470 (LWP 2152)]
0x76bef8dc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) bt
#0  0x76bef8dc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x76bf365c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x71d15c0c in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#3  0x71d15c0c in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

@hrydgard
Copy link
Owner

No, unfortunately not. You might want to compile with -O0 and -g options for a better stacktrace..

@steevp
Copy link

steevp commented Feb 21, 2015

Hmm unfortunately the result was the same with -O0 -g

@mihailescu2m
Copy link

Got it working on RPI2.

You don't need to change much:

  • you need to get the EGL, GLES, GLESv2 and KHR headers from the mesa packages, preferably put them in the ppsspp source folder
  • change CMakeLists.txt and remove RPI references: ppssppsdl uses SDL2 which already has videocore backend, so we don't need any rpi-specific backend here
  • add the egl/gles include folder (where you copied the EGL, GLES, GLESv2 and KHR folders from mesa) and the egl/gles lib folder (the rpi one - /opt/vc/lib) - you can see in CMakeLists.txt how it was done previously for rpi

Run cmake, edit CMakeCache.txt and set FBDEV to ON, GLES2 to ON, maybe even MOBILE_DEVICE to ON, run cmake again, then run make.

A bit disappointed with the performance (GPU clocked at 500MHz), it runs fullspeed on the odroid...
https://www.youtube.com/watch?v=O8juShfoJtE

@steevp
Copy link

steevp commented Feb 22, 2015

There must have been something wrong with my Raspbian install. I switched to a different sdcard with Arch Linux ARM and the libretro core works now as well.

@mihailescu2m
Copy link

what's the performance of the libretro core?

@hrydgard
Copy link
Owner

The "libretro core" is PPSSPP so it's the same.

@mihailescu2m
Copy link

No, for example I don't have shared context in RetroArch so only buffered works, which is slower than unbuffered. But this was on Mali, not rpi2.

@klyoungblood
Copy link
Contributor

It didn't tell me much, but here it is:

Reading symbols from build/PPSSPPSDL...done.
(gdb) run
Starting program: /home/pi/ppsspp/build/PPSSPPSDL
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x761ce050 (LWP 6931)]
[New Thread 0x757ff050 (LWP 6932)]
[New Thread 0x74fff050 (LWP 6933)]
[New Thread 0x747ff050 (LWP 6934)]
41:46:573 Core/Config.cpp:948 I[LOAD]: Loading controller config: /home/pi/.config/ppsspp/PSP/SYSTEM/controls.ini
41:46:573 Core/Config.cpp:1304 E[LOAD]: Failed to read /home/pi/.config/ppsspp/PSP/SYSTEM/controls.ini. Setting controller config to default.
Pixels: 1680 x 1050
Virtual pixels: 1680 x 1050
I: gpu_features.cpp:123: GPU Vendor : Broadcom ; renderer: VideoCore IV HW version str: OpenGL ES 2.0 ; GLSL version str: OpenGL ES GLSL ES 1.00
glGetError 0x500
[New Thread 0x73fff050 (LWP 6935)]
pure virtual method called
E: PCMain.cpp:645: Failed to open audio: No such audio device
terminate called without an active exception

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x73fff050 (LWP 6935)]
0x769edf70 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0 0x769edf70 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x769ef324 in __GI_abort () at abort.c:89
#2 0x76bf5b5c in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#3 0x76bf39a0 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

@unknownbrackets
Copy link
Collaborator

Oh right, are you using -DRASPBIAN=ON to build as per above? Also, which version of gcc did you compile with? It sounds like this may require gcc 4.9 or higher.

-[Unknown]

@klyoungblood
Copy link
Contributor

I am on gcc 4.9.2

That got it building and booting. Sound seems to be missing however, so there's just that and the keyboard hang left.

@unknownbrackets
Copy link
Collaborator

Well, it says "Failed to open audio". That error is coming directly from SDL:
https://github.com/hrydgard/ppsspp/blob/master/ext/native/base/PCMain.cpp#L644

I'm not sure if this comment about SDL2 is still relevant or not - did you try building SDL2 with these settings?
#7479 (comment)

As for keyboard, hmm. It's definitely possible we might not be closing it properly. Can you remove this:
https://github.com/hrydgard/ppsspp/blob/master/ext/native/base/PCMain.cpp#L903

    // Faster exit, thanks to the OS. Remove this if you want to debug shutdown
    // The speed difference is only really noticable on Linux. On Windows you do notice it though
#ifndef MOBILE_DEVICE
    exit(0);
#endif

-[Unknown]

@klyoungblood
Copy link
Contributor

Rebuilt SDL2 with the specified settings, then rebuilt PPSSPP, still no audio.

Commented out those lines and the keyboard hang is fixed.

Lots of random crashes and glitches though.

@unknownbrackets
Copy link
Collaborator

Not sure about the audio. Does it say "Failed to open audio" still? Can you get anything else to play audio (ideally an SDL demo of some sort)?

@hrydgard hmm, do you think we should ifdef the early exit, or just remove it altogether? I'm a fan of speeeed even for shutdown, but it's probably better safe than sorry... I had removed it entirely in Qt to fix config saving, but config save is already earlier in SDL.

-[Unknown]

@klyoungblood
Copy link
Contributor

Same error, and a simple audio test program fails with the same error, so the fault lies with SDL2 in this case.

@klyoungblood
Copy link
Contributor

Or not, rebuilt SDL2 with the proper pre-reqs for audio, got a test program working.

PPSSPP fails with same error.

@unknownbrackets
Copy link
Collaborator

Can you link to / paste the test program? Just want to see what it's doing.

You recompiled PPSSPP too, right?

-[Unknown]

@klyoungblood
Copy link
Contributor

I indeed ran cmake again and recompiled PPSSPP.

http://pastebin.com/bm0WL6Nk - test program

@unknownbrackets
Copy link
Collaborator

unknownbrackets commented May 31, 2016

Hm. I would expect it to at least fail with a different error, like "Sound buffer format does not match requested format." or something.

You could try fiddling with the parameters here:

SDL_AudioSpec fmt, ret_fmt;
memset(&fmt, 0, sizeof(fmt));
fmt.freq = 44100;
fmt.format = AUDIO_S16;
fmt.channels = 2;
fmt.samples = 2048;
fmt.callback = &mixaudio;
fmt.userdata = (void *)0;
if (SDL_OpenAudio(&fmt, &ret_fmt) < 0) {

One idea is to just paste in the SDL_LoadWAV code, and comment out our fmt/SDL_OpenAudio. If you can get the device to open in PPSSPP (even playing just a wav), then we're getting somewhere.

If that works, then it's a matter of seeing what parameter we're passing differently in the struct than it allows, I guess? Maybe it's mono vs stereo?

Some ideas:

  1. Try channels = 1.
  2. Try 22050 or 11025 or even 48000 for freq?
  3. Try AUDIO_S16SYS for the format?
  4. Try 4096 for samples (apparently what LoadWAV uses)?
  5. Try replacing &ret_fmt with NULL like the sample?

I'm not sure any of these are likely to work, though... if nothing works, try adding SDL_INIT_VIDEO | SDL_INIT_JOYSTICK | to SDL_Init in the sample, or calling bcm_host_init(); before hand.

-[Unknown]

@klyoungblood
Copy link
Contributor

So I tried installing SDL 1.2, then rebuilding SDL2.

I'm all the way back to:

SDL_CreateWindow failed: Could not initialize OpenGL / GLES library

@klyoungblood
Copy link
Contributor

Ok, looks like I'd managed to hose my SDL2 libraries beyond repair.

One fresh OS install later, it's working with sound.

Of note: libsdl1.2-dev and libudev-dev must be installed before building SDL2 or SDL2 will have missing features.

I'm going to write up my build process in the forums to help others.

@danboid
Copy link

danboid commented Feb 1, 2017

Hi all

Last week I got a SABRE Lite board and tonight I want to try building PPSSPP on it so I've come here for tips to try and minimise my trial and error and failed attempts. I've read people have got it to build and run on both the RPi and Odroid boards so I'm sure its possible although I've not found any build instructions or makefiles etc for non-RPi ARMv7 boards w/ GLES2 etc.

I'll be building it under Ubuntu 16.04 with the closed Vivante libs/drivers first before I delve into Arch, mesa and etnaviv. Note that I already know my GPU drivers are working as the included GLES demos run fine.

So, my initial guess before I've even attempted a single build (I did try building PPSSPP under Linux/ARM a couple years ago on a BananaPi with no luck, hence why I'm asking in advance) would be to edit cmake/Toolchains/generic.armv7.cmake and append

set(USING_GLES2 ON)

Might I need to define

set(OPENGL_LIBRARIES GLESv2 ...

Too?

Then I'll run something like:

cmake -DCMAKE_TOOLCHAIN_FILE=cmake/Toolchains/generic.armv7.cmake .

In the source dir, maybe?

I'll be running it under X, probably with SDL unless there is a good reason to use Qt instead? I'm presuming the ARM JIT code gets enabled by default?

I'd like to hear build tips from anyone else who has got PPSSPP building with OGL or GLES support under ARM. If there are unforeseen troubles in getting this to work, it would be good to have a generic.armv7.GLES.cmake and/or generic.armv7.GL.cmake if there are enough commonalities between various, non-RPi ARM boards with GL(ES) support.

Alternatively, maybe a link or extra info could be added to http://build.ppsspp.org/ under the Linux section for the ever increasing number of non-RPi ARM Linux boards and users to recommend the best configuration flags for various cases.

Thanks

@Orphis
Copy link
Collaborator

Orphis commented Feb 1, 2017

No reason to use Qt. It doesn't bring anything.
Toolchains should be kind of generic and don't contain any feature enabling. I really need to fix that someday to detect OpenGL or OpenGLES properly automatically.

Also, you shouldn't run cmake in the source dir, create a build folder and run "cmake .." with all the options you need.

Feel free to tweak it however you need and report back!

@danboid
Copy link

danboid commented Feb 1, 2017

Hi Orphis!

Thanks for your quick reply!

It sounds like you think my initial guess at build settings might do the trick? I'm not sure what the Vivante drivers support but Etnaviv for my board supports GLES 2 and OGL 1.4 but mesa 17.1 will introduce OGL 2 support so I imagine the binary Vivante driver could well support OGL2.x. I've not checked as I only had time to get Ubuntu to boot last night - I've not even upgraded it or installed anything extra yet.

Presuming my driver does expose OGL 2.x, might I get better performance and/or better visuals than using GLES 2? It might even support OGL/GLES 3.x.

I presume the RPi makefiles only include a set(OPENGL_LIBRARIES) definition because the RPi and its GL libs are a bit 'special', right? Every other GPU doesn't need that?

@Orphis
Copy link
Collaborator

Orphis commented Feb 1, 2017

Yes, it's the bcm_host library that is special in this case.
I believe that Open GL 1 won't work and you'll need version 2 at least.

It seems that your board is quite limited overall, have you tried to put Raspbian on it for example? The software might be more current.

@danboid
Copy link

danboid commented Feb 1, 2017

I wouldn't say Ubuntu 16.04 is outdated just yet, but maybe it is for ppsspp git? Do you think any critical deps (SDL etc) would need to be ripped and replaced from 16.04 to build PPSSPP?

I've already given Arch a quick go on my board - that is more current than 16.04 but I may struggle to get the Vivante blob drivers running under Arch. I'm waiting for libdrm 2.4.75 to make its way into the Arch repos before I try building etnaviv (from mesa git) again as it's too much work having to replace libdrm and cairo etc instead of just replacing mesa. However, I do intend to transition to etnaviv eventually as I want open source drivers - under Arch it's likely a necessity.

The Sabre Lite is one of a handful of ARM dev boards with both SATA and (WIP) open source graphics drivers. I realise SATA won't speed up PPSSPP but having SATA makes a HUGE difference to overall system performance (boot and program load times, compilation etc) and is why the RPi's haven't interested me yet. If the RPi 4 gets USB3 though I may bite. :)

The SABRE Lite isn't the most powerful board but its more powerful than the RPi2.

@Orphis
Copy link
Collaborator

Orphis commented Feb 1, 2017

Sorry, I assumed it was much older since you mentioned that an update would bring OpenGL 2, which is already ancient technology.

@danboid
Copy link

danboid commented Feb 1, 2017

I was talking about the open source etnaviv driver - that only supports OGL 1.4 and OGLES 2 currently but it will soon support OGL 2.x and OGLES 3. The vivante blob driver I'll be trying first supports OGLES 3.0 already but I'm not sure it has any OGL support.

@imakowski
Copy link

probably I have problem related to this (https://retropie.org.uk/forum/topic/8837/lr-ppsspp-cannot-install-on-osmc)

Is there any progress for this topic?

@dankcushions
Copy link

@imakowski this is PPSSPP standalone, not libretro. go here: https://github.com/libretro/libretro-ppsspp

@imakowski
Copy link

@dankcushions standalone also doesn't work for me in retropie, but thanks for the informantion

@unknownbrackets
Copy link
Collaborator

Just for some current information: if you want to build on Raspbian (rather than cross compile), try the following:

  1. git clone ppsspp recursive (2.1GB, so make sure you have the space.) Make sure you have the submodules.

  2. Do not install libsdl2-dev, it's a trap (or so it seems.)

  3. sudo apt-get remove libgles2-mesa-dev libegl1-mesa-dev libgles2-mesa

  4. Switch to clang:

    sudo update-alternatives --config cc
    sudo update-alternatives --config c++
    
  5. Update to latest firmware:

    sudo rpi-update
    sudo shutdown -r now
    
  6. Make sure you've got more than the default GPU memory set aside for PPSSPP:

    sudo raspi-config
    # Advanced Options -> memory split -> 256, if you have a 1GB rpi.
    
  7. Compile SDL2 from source (possibly could avoid this by linking PPSSPP to brcmGLESv2 / brcmEGL?):

    curl https://www.libsdl.org/release/SDL2-2.0.9.tar.gz | tar xvz
    sudo apt-get install libudev-dev libasound2-dev libdbus-1-dev
    # Should already be installed, but make sure.
    sudo apt-get install libraspberrypi0 libraspberrypi-bin libraspberrypi-dev
    cd SDL2-2.0.9
    ./configure --disable-pulseaudio --disable-esd
    make -j4
    sudo make install
    cd ..
    
  8. Finally, build PPSSPP (if you already ran cmake before this, delete the directory first):

    cd ppsspp
    mkdir build && cd build
    # Hm, seems weird that I had to add these manually?
    export CFLAGS=-I/opt/vc/include
    export CXXFLAGS=-I/opt/vc/include
    export LDFLAGS=-L/opt/vc/lib
    cmake .. -DCMAKE_BUILD_TYPE=Release -DUSING_GLES2=ON -DUSE_WAYLAND_WSI=OFF -DUSING_FBDEV=ON
    make -j4
    
  9. Now exit any windowing environment you're in (i.e. Ctrl-Alt-F1, Ctrl-Alt-F7 to get back.)

  10. cd ppsspp/build && ./PPSSPPSDL --fullscreen

Some tips:

  • htop and cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq to see CPU usage and clock.
  • echo 5 | sudo tee /sys/devices/system/cpu/cpufreq/ondemand/up_threshold will improve performance but increase temp
  • It may be possible to link against brcmGLESv2 and brcmEGL to get hardware accel, would require changes in cmake toolchain presumably?
  • It's not necessary to patch out any Vulkan code or anything, just use -DUSE_WAYLAND_WSI=OFF.
  • There might be a way to make it work in windowed mode but I'm not sure how.
  • Audio and graphics generally work fine (there are some graphical glitches.)

-[Unknown]

@unknownbrackets
Copy link
Collaborator

unknownbrackets commented Mar 23, 2019

Actually, I'm dumb. I didn't notice there was a toolchain file. The mesa stuff above can be avoided by using -DCMAKE_TOOLCHAIN_FILE=cmake/Toolchains/raspberry.armv7.cmake. See #11923 - now you can just use ./b.sh --rpi.

That said, I still seem to have to use a self-built SDL2. So only step 8 above is really made simpler.

-[Unknown]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests