very slowes, for most interesting games, only pc can run good things? for ever?

Libretro Lakka
#1

reviewing and testing i can see the libretro and lakka runs in genereal slow and have poor performance… too many tune to get decent

i understand that the project are huge (libretro) and commit in one product (lakka) to use directly its a hard task… but important:

Considering: my older box http://debianeepc2gsurf.blogspot.com/2016/03/debian-eeepc-2g-surf-usando-disco.html lees powefull rather and moder devices listed in the lakka documentatin (very less powerfull) can run pleny of the breath of fire in the snes9x emulator

A) the eepc 2g surf no hav disk drive, only 512 ram and cpu/gpu are very slow, and runs event the mupen64plus B) Pi, Hummingboard, Cubox-i, are good choises for but runs very slowly then

why lakka cannot run games in those moder devices such raspberry pi 1 or 2, that have much more ram and cpu/gpu rather than a 2g surf eepc?

lest taking about performance! maybe the problem its some of:

  1. using too high compilation depends/versions
  2. too modern kernel have too many depends
  3. too modern of all

in the eepc 2g i used a hacked debian squeeze with prepackages specialed tuned to that version of linux…


#2

It is difficult for me to understand what exactly you are asking. I have an eeepc 4g surf and I can run emulators up to Super Nintendo (snes9x-next). For newer games console emulation is too slow. Also, mame 0.78 works fine, picodrive, prboom, fceum, tyrquake. I use debian jessie, no x11 just kms/egl.

#3

I have an eeepc 4g surf and I can run emulators up to Super Nintendo (snes9x-next).

i have a lees powerfully (2gsuf) and i run visualvboyadvance at pley of performance and mupen64plus in debian lenny, umm maybe i need to post a video, seems not many people have that! but i not have resources how to record that inside the 2gsurf itselft, and i not have a modern phone to record video but i deb that, i’ll try to find how!

For newer games console emulation is too slow. Also, mame 0.78 works fine, picodrive, prboom, fceum, tyrquake. I use debian jessie, no x11 just kms/egl.

not jessie, jessie its too slower! i running complete desktop, play videos up to 720p at 30 fps, in background cracked wifi with aircrack-ng with ssh while my boy play Crono trigger (yeah the best rpg ever!)

put a backgroun desktop downgrade performance of mupen64plus and virtualjaguar, event with nitrogen

the only thing, the device goes too hot, very very hot! if 720p videos are played! of course mvp are not good choice, the powered very faster mplayer 1.1.0 are the one!

i triying now to run playstation one with a modified pcsxr 1.9.92 with gtk << 2.22 and glib << 2.24 but opengl its a pain! and software render are not enough

if I had more skills programming, i will achieve programs run with few hardware requeriments, today programer seem are very lazy due always will have “power” and “ram”, machines are “modern”

i’m not sking i’m pointing what are happened! modern versions of gcc or kernel have more computed cpu requeriments! by example!

#4

Both asus eeepc 4g and 2g have the same processor so they basically have the same amount of power, just 4g has a larger SSD drive. You can start with minimal debian iso and build on top of that. The entire debian system with x11, which I rarely use, is less than 700MB. I remove packages I don’t need like manpages, man-db, groff-base, discover, debconf-i18n, vim-tiny, vim-common, bluez, dictionaries-common, locales, util-linux-locales, ispell… Also, I install lxde-core with --no-install-recommends. You can also overclock you processor so it runs on 900MHz instead of 630MHz.

#5

Did you make a test with the lastest nightly available ? If XMB menu is too slow try to use RGUI menu via menu Driver > Menu Driver > rgui it may help.

#6

thanks for suggestion but its clarelly that u not read the complete thread, please read the thread complety firts! i added that now i tested and used in a pc too some libretro cores to some emualtes, noted that experimental tyr-quake are more slower rather thant original code under a less powerfully machine

i have a borrowed raspberry pi, i think “uff 1.0 GHz with 512 RAM, oh” but event are more powerfully rather the eepc 2gsurf does not run the mupen64plus in fact, with a “uff powered OpenGL ES 2.0” capable gpu, does not run well the pcsxr or mupen64plus!, the 2gsurf does it at leas with mupen64plus with debian lenny (some gliches and not run all games)!

i think the compiler used (gcc 4.9 +) are too high, i hear the optimization routines at compile time are not same like gcc 3.4 that generated more powered optimized darkplaces engine! seem since gcc 4.1, optimization routines are more stric and the memory consuption are huge and insane for some “hacks”, in this orde same for the rest of components, too high versions of all!

#7

[QUOTE=kalehrl;36976]Both asus eeepc 4g and 2g have the same processor so they basically have the same amount of power, just 4g has a larger SSD drive. The entire debian system with x11, which I rarely use, is less than 700MB. [/QUOTE] same procesor, but less space and network cards are different i have the firts model, not the commercial, my eepc 2g surf its russian, see the blog 700MB too high, debian lenny with my hacked venenux packages install all openbox in 500Mb

[QUOTE=kalehrl;36976] I remove packages I don’t need like manpages, man-db, groff-base, discover, debconf-i18n, vim-tiny, vim-common, bluez, dictionaries-common, locales, util-linux-locales, ispell… Also, I install lxde-core with --no-install-recommends. You can also overclock you processor so it runs on 900MHz instead of 630MHz.[/QUOTE] i not overclock the procesor, WOW then in a very low end machine i run mupen64plus, and libretro does not in a rasberry pi 700MHz?!!! WTH?!

hey, this its not a competition of what installation are correct i reposted the posted before: i think the compiler used (gcc 4.9 +) are too high, i hear the optimization routines at compile time are not same like gcc 3.4 that generated more powered optimized darkplaces engine! seem since gcc 4.1, optimization routines are more stric and the memory consuption are huge and insane for some “hacks”, in this orde same for the rest of components, too high versions of all! the VisualBoyAdvance emulator suffers from that change, as example, i have more but i dont remenber what of my huge repository packages also suffers that problem too… i always used gcc 3.4 for compilation whn possible due generate more optimized code

#8

I asked you to make some test to check if you have some issue with your graphic card with Lakka because we are using DRM/KMS no Xorg.

#9

i tested! lasted night build (last week, using git lasted), compiled and ten installed in the rasberry pi, when i tested i revised have opengl (in log no error found) when i use the kms gl way

there 3 ways of test, with native rasperry system, with the lakka image and with a kms egl mode diredctly lauchs

NOTES IMPORTANT:

  • in all always used hard optimization flags: “CFLAGS = -mfpu=vfp -mfloat-abi=hard -march=armv6zk -mtune=arm1176jzf-s”
  • in compiled ways, used a git clone and compile only specific parts (i use only playsation core, desmume and mupen64plus core)
  • in lakka way i used lasted images http://sources.lakka.tv/nightly/RPi.arm/
  • no debug symbols, for most optimized (debug symbols generates more slower and big product compilation)

and of course we are using kms/drm, opengl need it! but i noted nw that for example desmume still not use gl, and git mode are not fully complete

but mupen64plus are in good shape but in any combination still play more more more slower rather thatn my poor eeepc 2gsurf

tomorrow at my job i’ll test with the with the pc… but i quickly test in the eepc and of course no work!

#10

[QUOTE=mckaygerhard;36995] i have a borrowed raspberry pi, i think “uff 1.0 GHz with 512 RAM, oh” but event are more powerfully rather the eepc 2gsurf does not run the mupen64plus in fact, with a “uff powered OpenGL ES 2.0” capable gpu, does not run well the pcsxr or mupen64plus!, [/QUOTE] which raspberry pi? the zero is the only one with 1GHz, but it’s an ARM cpu that is not comparable to other types of CPU like in your eepc 2gsurf. eg: “While operating at 700 MHz by default, the first generation Raspberry Pi provided a real-world performance roughly equivalent to 0.041 GFLOPS.[SUP][19][/SUP][SUP][20][/SUP] On the CPU level the performance is similar to a 300 MHz Pentium IIof 1997–99.” the zero won’t be much better.

raspberry pi 2 and 3 run these systems much better, but there are lots of factors - the resolution, how you’ve configured the system, etc.

#11

[QUOTE=dankcushions;37339]

raspberry pi 2 and 3 run these systems much better, but there are lots of factors - the resolution, how you’ve configured the system, etc.[/QUOTE]

thanks for clarify, i really have a Raspberry Pi 2 Model B at 900Mz so of course, firts raspberri py 2 does not say expressily “2”, but take in onsideration: have an quad-core ARM Cortex A7 CPU; a QUAD-CORE!!! fourt cores!, my eepc only have one! and at 700MHZ vs 900MHz fourt cores on the Py2

the issue its not the raspberry hardware , its the tools and path of the development of the libretro, the libretro mupen64plus core runs more slower rather thant original mupen64plus in same hardware (x86 and/or x86-64)

i made some tricks, by example noted that of course snesx9x 1.42 runs more faster rather thant lasted version, and libretro snes9x its based in lasted version…

[ol] [li]when developers included more features also includes more lines of code that must be computed… that its the firts problems[/li][li]the second problem its the dependencies (either runtime or compile), gcc requirement its too high and gcc 3.4 have better “trick” for optimizations[/li][li]the works most important: libretro need much of opengl and 3d capabilities for task that dont need! [/li][/ol]

i remenber the raiden emulator of guindows… that rus without 3d capabilities!!! and was the best emulator of playstation one, but today playsation emulators need too high requeriments

also i remenber that VisualBoyAdvance dont compile with high optimizations on recent GCC, due recent gcc dont pass trick of optimizations due very huge comsuption of memory, that not happen in gcc 3.4

FOR REST BEFORE MAKE RESPONSE; PLEASE READ BEFORE this its not about “most powerfull hardware” its about “why i need too high requeriments that are ilogic?”!

#12

well, if you want something to run on minimum hardware then you will probably find you you will have find specific older, standalone versions to get best performance. what do you expect libretro to do here? we can’t stop progress just to support people on the lowest hardware. i think they already do a pretty good compromise by offering a variety of cores, and some older versions (like mame2000, 2003, etc) for older hardware.

as for the pi2, it runs libretro pcsx rearmed at full speed at standard resolution, and mupen64plus standalone doesn’t run particularly well on it anyway.

#13

[QUOTE=dankcushions;37372]well, if you want something to run on minimum hardware then you will probably find you you will have find specific older… i think they already do a pretty good compromise by offering a variety of cores, and some older versions (like mame2000, 2003, etc) for older hardware. [/QUOTE] well most people know that can be more compromise… explain how in previous messages

[QUOTE=dankcushions;37372] as for the pi2, it runs libretro pcsx rearmed at full speed at standard resolution, and mupen64plus standalone doesn’t run particularly well on it anyway.[/QUOTE] at least u reconiced that does not run mupen64plus at full speed! and i explaint too why in prevous mesages

explain how to solve, but its more easy to say “u cannot stop progress”

seems progress=microsoft : more and more resourses!

#14

So, the solution you propose is that we compile everything with a 12-yr old version of gcc? If that’s a thing you would like to do, we’re happy to help you do it but we’re not going to craft our releases around it.

As for the GL requirements, we have other display drivers such as SDL2 and xv that aren’t accelerated. You’re welcome to try those to see if they perform any better on your hardware but they can’t run the mupen64plus core (among others) or use shaders.

#15

The reason for the performance difference is not in the quality of the optimization but in the type. The 3.x gcc series used machine/CPU specific optimizations for the best hardware level performance. Starting with the 4.x series, the GCC project switched to generic more cross platform optimizations. The performance difference is huge between the same code compiled using the different compilers. However, GCC 3.x isn’t an option for the PI platform as I don’t think it would have had the right CPU optimizations to start with and it is quite old now. It would be worth checking out the effectiveness of optimizations with current releases of GCC and CLANG/LLVM though. If any of the other commercial compilers support CPU level optimizations, it might be worth checking them out for an optimized product release. The whole GCC 3.x thing has been around a long while. If you look back thru the articles on the change you will even see where Linux Torvalds ripped the GCC team for creating a sub par compiler in 4.x on. Worth noting that he heaped a tons of complaints about the 4.9 release specifically. I know from my use or attempted use of it that it had issues. I happily jumped from 4.7 to 5.x with my projects. Was very happy using CLANG as well.

[QUOTE=mckaygerhard;36995]

i have a borrowed raspberry pi, i think “uff 1.0 GHz with 512 RAM, oh” but event are more powerfully rather the eepc 2gsurf does not run the mupen64plus in fact, with a “uff powered OpenGL ES 2.0” capable gpu, does not run well the pcsxr or mupen64plus!, the 2gsurf does it at leas with mupen64plus with debian lenny (some gliches and not run all games)!

i think the compiler used (gcc 4.9 +) are too high, i hear the optimization routines at compile time are not same like gcc 3.4 that generated more powered optimized darkplaces engine! seem since gcc 4.1, optimization routines are more stric and the memory consuption are huge and insane for some “hacks”, in this orde same for the rest of components, too high versions of all![/QUOTE]