Dingoonity.org

GCW Zero => Development => Topic started by: the_gama on September 06, 2013, 05:00:24 am

Title: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on September 06, 2013, 05:00:24 am
Hi, I have been working on porting RetroArch to the gcw0.  Basically I simply wrote a Makefile using the sdl drivers and built several of the libretro cores using gcw0's toolchain.

Today, I started testing each core with one or two roms to see how they run.  The cores were tested with the smooth filter disabled, no scaling and no threaded video. Here are some results:

- fceumm: tested mega man 2, runs fullspeed as expected.
- Nestopia: tested mega man 2, runs fullspeed most of the time with minor hickups.
- gambatte: tested metroid 2, runs fullspeed.
- vbam: tested the hively player demo, runs slow. The gpsp core will run better but it hasn't been released.
- nxengine: runs slow (fullspeed with threaded video option)
- snes9x-next: tested megaman x and chrono trigger, runs slow, very slow actually.  Using threaded video helps a lot but it was still far from fullspeed.
- fba: Tested street fighter iii - new generation, runs slow. Marvel super heroes runs better, but still slow.
- mame078: tested snow bros, runs fullspeed ;).  I guess it will depend on the game here.
- mednafen_pce: tested salamander, runs fullspeed.
- mednafen_wswan: tested final fantasy i, runs very slow. Super robot wars runs fullspeed.
- mednafen_npc: tested king of fighters, runs fullspeed.
- picodrive: tested contra hard corps, runs fullspeed.
- gensplusx: tested contra hard corps, runs slow most of the time.

Ok, first sorry for not putting more accurate results (fps, exact options, etc) but I didn't have much time to test the roms. Retroarch logs an Average monitor Hz value at the exit, maybe I should post that value.  For instance, sfiii got a 20 Hz value and Mega Man 2 got 60 Hz.

Threaded video option helps a lot, for instance nxengine core runs fullspeed with that option enabled. But it doesn't help some cores that much, like fba and snes9x-next.  Actually, I was expecting better performance in snes9x-next but I guess it's a bit heavy for the zero, since it's based on snes9x 1.51 and uses the accurate apu. And I have to point that retroarch doesn't use frameskip and will never do.  The good thing about it is that, when a core runs fullspeed, it runs beautifully.

I did not changed anything from the sources, simply wrote the necessary makefiles to build retroarch and the cores, so there might be room for improvements.  Using the GL driver might help and we could really get some performance boost in all cores if the cpu could be overclocked.

Anyway, I'm not releasing anything, since I haven't properly contacted the retroarch project members, and because I don't really feel happy with the results. My main interest was having accurate and fast snes emulation on the console.
But if any serious dev would like to properly work on the port, please pm me.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: doglush on September 06, 2013, 10:39:36 am
I don't know what is RetroArch (a multi emulator like MESS ?).
Why porting such a thing with redudant existing emulator (SNES, NES, Genesis, FinalBurn) ?
Maybe it's more speed and accurate ?

Anyway, good luck. It's a pleasure seeing new applications on the Zero.
Thanks.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Malleus on September 06, 2013, 11:32:29 am
I think its great, hope it gets released!

Is it allowed to make libretrocores specific to platforms?
Just because the "standard" cores arent fast enough doesnt mean that it isnt great that you can implement the api and not have to worry about alot of things.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Shin-NiL on September 06, 2013, 12:34:59 pm
I had built the retroarch with PicoDrive and snes9x-next cores for the Dingoo A320 and GCW-Zero some weeks ago. As expected, the Dingoo ran very slow. The GCW version I could not test because I have not received my device yet...

Anyways, good to know somebody else is doing some tests  :)
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on September 06, 2013, 02:13:23 pm
Quote
Is it allowed to make libretrocores specific to platforms?
Just because the "standard" cores arent fast enough doesnt mean that it isnt great that you can implement the api and not have to worry about alot of things.

Of course, anyone is free to write a new core.  As long as you follow the GPL license in which libretro is based, in other words, you have to release the full sources of your changes.  For instance ToadKing wrote an unofficial pocketsnes based core for the Raspberry Pi.  The libretro devs don't really like all the 'ugly' snes9x forks based on old and hacked code though.

And what is most important for the libretro devs, do not make any kind of profit using libretro code.

Code: [Select]
I had built the retroarch with PicoDrive and snes9x-next cores for the Dingoo A320 and GCW-Zero some weeks ago. As expected, the Dingoo ran very slow. The GCW version I could not test because I have not received my device yet...

Anyways, good to know somebody else is doing some tests  :)

Good to know that ;).  Have you received your device yet?  Are you planning to make any optimizations for the gcw0? I tryied to use the mips optimized code in the picodrive core, but I got a relocation error when building the shared library.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: ruffnutts on September 06, 2013, 03:35:17 pm
So no chance of trying the psx core then? 8)

BTW would be nice to see a video or 2 of this in action ;D
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: doglush on September 07, 2013, 01:33:34 pm
I had built the retroarch with PicoDrive and snes9x-next cores for the Dingoo A320 and GCW-Zero some weeks ago. As expected, the Dingoo ran very slow. The GCW version I could not test because I have not received my device yet...

Anyways, good to know somebody else is doing some tests  :)

I got a question. Why porting Picodrive and SNES from retroarch when we still have these emulators ?
And you say, "the dingo ran very slow". Why using these cores, which are running SLOWER than originals one ???
If these core are slower on dingoo they will be slow on GCW Zero too...
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Shin-NiL on September 07, 2013, 02:21:17 pm
@the_gama: I'll receive my device today \o/
I was just doing some experiments with retroarch, now I have some other projects planned, so I probably will not have much time to try to do these optimizations.

@doglush: As I said for the_gama it were just experiments, there is no way to know how things will work if they are not tested before. Anyway, the beautiful part of retroarch is its modularity, we can get something out of it.  ;)
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Awakened on September 07, 2013, 08:12:55 pm
I got a question. Why porting Picodrive and SNES from retroarch when we still have these emulators ?
And you say, "the dingo ran very slow". Why using these cores, which are running SLOWER than originals one ???
If these core are slower on dingoo they will be slow on GCW Zero too...
For picodrive, it'd be one way to get the latest version of the core emulator instead of the older release found in the standalone version currently available. notaz has been improving 32x emulation recently. If it can be optimized enough that Genesis Plus GX, SNES9x Next and VBA Next can run fullspeed, you'd get more accurate emulation with less glitches, better sound, ect. Even if those cores are too slow after everything that can be done to speed them up on the Zero, I think it'd still be worth it for Picodrive, Nestopia, Gambatte, and Mednafen (PCE, Wswan and NPC) all in one app. Hopefully with a good enough interface with customizable buttons and aspect ratio per core  :D
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: hi-ban on September 07, 2013, 08:28:30 pm
For picodrive, it'd be one way to get the latest version of the core emulator instead of the older release found in the standalone version currently available.

Not really. Latest source code is already available: http://boards.dingoonity.org/gcw-zero-emulation/picodrive-updated/
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Awakened on September 07, 2013, 09:09:19 pm
Right, but is someone going to update the standalone GCW port?
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Shin-NiL on September 13, 2013, 03:12:43 pm
Hello the_gama.
Could you compare the general performance using Genesis Plus GX as a libretro core vs the standalone build (http://boards.dingoonity.org/gcw-development/genesis-plus-gx-experimental-build)?


Thank you.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on September 14, 2013, 01:59:11 am
Hello the_gama.
Could you compare the general performance using Genesis Plus GX as a libretro core vs the standalone build (http://boards.dingoonity.org/gcw-development/genesis-plus-gx-experimental-build)?


Thank you.

No problem, ok tested several roms from Sega Genesis, and the standalone build runs quite better than the retroarch core.

In the standalone build most games ran, what seemed to me, fullspeed or almost fullspeed.  The games tested were: Castlevania Bloodlines, Panorama Cotton (this one may not run fullspeed), Contra Hard Corps.  And I tested Virtua Racing which run very poorly in both.

What I can tell, is that retroarch has better sound, maybe because of the sinc resampler.  What is the audio output rate in genplusgx.dge?

And one more question, does the genplusgx.dge build is using any kind of frameskip? Maybe auto frameskip? We need to know that to ensure it is a fair comparison.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Awakened on September 14, 2013, 02:08:15 am
Will the new GLES support help performance?
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Shin-NiL on September 14, 2013, 01:21:48 pm
Thank you the_gama.
It's using 48000 as sound frequency and 2048 samples size with no frameskip that I can know. SVP is running really bad  :'(

About the OpenGL ES, I don't know if it will help the Genesis Plus GX core, maybe other cores that support it.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on September 16, 2013, 01:21:01 am
I'm trying to test the GL driver for retroarch, will post the results after I do some tests.  I tryied building mupen64plus but it failed when looking for fenv.h.  Can it be added to the toolchain?

mupen64plus uses fenv.h to set the rounding mode through fesetround function, I can skip it right now but I don't know how much will it affect emulation.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Squarepusher2 on September 16, 2013, 09:20:36 am
Thank you the_gama.
It's using 48000 as sound frequency and 2048 samples size with no frameskip that I can know. SVP is running really bad  :'(

About the OpenGL ES, I don't know if it will help the Genesis Plus GX core, maybe other cores that support it.

Genesis Plus GX requires at least a Wii-caliber CPU for SVP (Virtua Racing) to run at fullspeed (Genesis Plus GX has no recompilers - only interpreters).

The 1GHz MIPS CPU of the GCW Zero is unlikely to be as fast in real-world performance terms as the Wii CPU - not to mention that blitting is probably much slower. By comparison, the 1GHz Pandora (ARM Cortex A8) does not run Virtua Racing with Genesis Plus GX at fullspeed either (Picodrive does though), and the 1GHz MIPS CPU inside the GCW Zero is probably slower per-clock than that.

Normally I'd say it would be better to use Picodrive, but the problem is that it doesn't have any MIPS recompilers - so you would still fall back on interpreter in Picodrive. Even still, it should be at least somewhat faster than Genesis Plus GX at the same game even with the interpreter.

For Mupen64 Plus - yes, you will need at least OpenGL ES 2 support - it might take some time for those homespun GLES drivers for the GCW Zero to mature I guess - so I dunno how well you can expect it to run. There are also no MIPS->MIPS recompilers so there is also that - you would have to fall back to interpreter for now - pretty sure it will be way too slow on GCW Zero.

I am open to pull requests for a MIPS->MIPS recompiler in case you feel like writing one, and the same goes for any other patches you come up with.

Regarding the RetroArch port - SDL driver is the absolute worst driver you can go for. I would say either use the OpenGL driver (best case scenario, but requires that your GL drivers are decent - even commercial vendors can get it wrong most of the time) or write your own low-level graphics driver.

The sound driver (and configuration)  is crucial to get right - you need to get the audio latency option set exactly right to avoid sound crackling and not getting audio right will result in a bad experience since it blocks on audio - thus audio is the bottleneck in case the driver is bad or it is not configured right. I don't know what sound driver you are using right now - I assume ALSA?
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: pcercuei on September 16, 2013, 09:57:01 am
... and the 1GHz MIPS CPU inside the GCW Zero is probably slower per-clock than that.
It does surprisingly well; while ARM may lead to a better performance with hand-written ASM, MIPS is more compiler-friendly.

Normally I'd say it would be better to use Picodrive, but the problem is that it doesn't have any MIPS recompilers - so you would still fall back on interpreter in Picodrive. Even still, it should be at least somewhat faster than Genesis Plus GX at the same game even with the interpreter.
I never heard of a recompiler for Picodrive. I don't know what Genesis Plus GX uses, but FAME/C is proved to be extremely fast on MIPS.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Squarepusher2 on September 16, 2013, 11:13:07 am
... and the 1GHz MIPS CPU inside the GCW Zero is probably slower per-clock than that.
It does surprisingly well; while ARM may lead to a better performance with hand-written ASM, MIPS is more compiler-friendly.

Normally I'd say it would be better to use Picodrive, but the problem is that it doesn't have any MIPS recompilers - so you would still fall back on interpreter in Picodrive. Even still, it should be at least somewhat faster than Genesis Plus GX at the same game even with the interpreter.
I never heard of a recompiler for Picodrive. I don't know what Genesis Plus GX uses, but FAME/C is proved to be extremely fast on MIPS.

Picodrive has SVP and SH2 recompilers for ARM done by notaz. Without them, Virtua Racing and 32X would be going a lot slower on ARM.

Genesis Plus GX does not use FAME/C for the 68K interpreter core but Musashi. Picodrive does use FAME/C for the interpreter 68K core - for ARM an optimized version of Cyclone is used instead though.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: pcercuei on September 16, 2013, 11:24:17 am
Oh, sorry, I thought you meant recompilers for the M68k.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Shin-NiL on September 16, 2013, 02:54:52 pm
Thank you for clarifying these points Squarepusher2. Such kind of information is valuable ;)
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on September 16, 2013, 11:01:47 pm
Yes, very valuable indeed. Thanks squarepusher.

Quote
The sound driver (and configuration)  is crucial to get right - you need to get the audio latency option set exactly right to avoid sound crackling and not getting audio right will result in a bad experience since it blocks on audio - thus audio is the bottleneck in case the driver is bad or it is not configured right. I don't know what sound driver you are using right now - I assume ALSA?

I have tested both SDL and ALSA driver, ALSA works better with threaded video off, while SDL works better with threaded video.

I'm still searching the correct values for audio latency.  And currently I'm trying to test performance using the OpenGL (GLES 2.0) driver, compiled the gl driver files, but it seems an egl context code is needed.  Will try to write one based on the different egl contexts available, the emscripten or android ones seem appropiate.

Shin-Nil, have you tested your build?  It would be nice to compare your port.  As I said before, basically I only wrote a Makefile, and I haven't changed anything to the sources, except for a NULL pointer check in frontend.c when using the SDL gfx driver.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Shin-NiL on September 17, 2013, 01:07:28 am
I  haven't made any code changes also, just edited the makefile and tested some settings options. I'm using the SDL backend, apparently used only to test the emulator on Windows. Once I have more time I will try to test the sound latency.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on September 20, 2013, 03:11:33 pm
I'm trying to get retroarch's gl driver to work, but I'm getting very slow performance.  Any help from some dev?  What is the correct calls to setup an egl context in the zero?  Currently I'm using code from the EGLport from Pickle (with some minor modifications) to get input from sdl and video using opengles 2.0. 

It compiles fine and video output is working, but performance is very slow.  The opreport script shows that 38% of cpu time is spent in egl_gallium.so, so I believe I'm not using the correct configuration or the gl driver is using unimplemented/unoptimized features. 

Here is Retroarch log output:

Code: [Select]
RetroArch: Adjusting aspect ratio to 1.07
RetroArch: Video @ 240x224
EGL Getting EGL display
EGL Initializing
fbdev_display succesful
Kernel: Vivante GPL kernel driver 4.6.6.1381
Physical address of internal memory: 00000000
* Video memory:
  Internal physical: 0x00000000
  Internal size: 0x00000000
  External physical: 00000000
  External size: 0x00000000
  Contiguous physical: 0x8e2eff00
  Contiguous size: 0x00400000
Succesfully opened device
EGL_VENDOR: Mesa Project
EGL_VERSION: 1.4 (Gallium)
EGL_EXTENSIONS: EGL_MESA_screen_surface EGL_KHR_image_base EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_surfaceless_context
EGL Found 3 available configs
EGL Config 0
EGL Binding API
EGL Creating Context
EGL Creating window surface
native_fbdev: 2 buffers of 320x240
Framebuffer format: 6, flip_rb=0
Framebuffer format: 6, flip_rb=0
EGL Making Current
EGL Complete
RetroArch: Found GL context: opendingux
RetroArch: Detecting screen resolution 320x240.
RetroArch: gfx_ctx_set_swap_interval(1).
RetroArch: [GL]: Vendor: etnaviv, Renderer: Gallium 0.4 on Vivante GC860 rev 4621, Vivante GPL kernel driver 4.6.6.1381.
RetroArch: [GL]: Version: OpenGL ES 2.0 Mesa 9.3.0-devel.
RetroArch: Querying GL extension: BGRA8888 => exists
RetroArch: [GL]: BGRA8888 extension found for GLES.
RetroArch: GL: Using resolution 320x240
RetroArch: [GL]: Using GLSL shader backend.
RetroArch [WARN] :: [GL]: Stock GLSL shaders will be used.
RetroArch: Found GLSL vertex shader.
RetroArch: Found GLSL fragment shader.
RetroArch: Linking GLSL program.
RetroArch: Found GLSL vertex shader.
RetroArch: Found GLSL fragment shader.
RetroArch: Linking GLSL program.
RetroArch: Found GLSL vertex shader.
RetroArch: Found GLSL fragment shader.
RetroArch: Linking GLSL program.
RetroArch: GL: Using 4 textures.
RetroArch: GL: Loaded 1 program(s).
RetroArch: [Joypad]: Found pad: analog joystick on /dev/input/js0.
RetroArch: Found joypad driver: "linuxraw".
RetroArch: Using font rendering backend: bitmap.
RetroArch: ALSA: Using signed 16-bit format.
RetroArch: ALSA: Period size: 768 frames
RetroArch: ALSA: Buffer size: 3072 frames
RetroArch: ALSA: Can pause: yes.
RetroArch: Sinc resampler [C]
RetroArch: SINC params (12 phase bits, 8 taps).
RetroArch: [RGUI]: Opening history: retroarch/.retroarch-game-history.txt.

And this is opreport output:

Code: [Select]
Using /var/lib/oprofile/samples/ for samples directory.
warning: /no-vmlinux could not be found.
CPU: CPU with timer interrupt, speed 1188 MHz (estimated)
Profiling through timer interrupt
samples  %        app name                 symbol name
16277    52.3258  no-vmlinux               /no-vmlinux
12122    38.9687  egl_gallium.so           /usr/lib/egl/egl_gallium.so
495       1.5913  fceumm_libretro_gcw0.so  X6502_Run
460       1.4788  fceumm_libretro_gcw0.so  retro_run
399       1.2827  fceumm_libretro_gcw0.so  RefreshLine
216       0.6944  libuClibc-0.9.33.2.so    /lib/libuClibc-0.9.33.2.so
204       0.6558  fceumm_libretro_gcw0.so  FCEU_SoundCPUHook
196       0.6301  fceumm_libretro_gcw0.so  FCEUPPU_Loop
137       0.4404  fceumm_libretro_gcw0.so  CartBR
125       0.4018  retroarch-gcw0           resampler_sinc_process
52        0.1672  libpthread-0.9.33.2.so   pthread_mutex_lock
47        0.1511  fceumm_libretro_gcw0.so  RDoTriangleNoisePCMLQ
46        0.1479  fceumm_libretro_gcw0.so  RDoSQLQ
40        0.1286  libpthread-0.9.33.2.so   __pthread_mutex_unlock_usercnt
37        0.1189  ld-uClibc-0.9.33.2.so    /lib/ld-uClibc-0.9.33.2.so
35        0.1125  libpthread-0.9.33.2.so   __pthread_cleanup_push_defer
30        0.0964  retroarch-gcw0           audio_flush.part.57
21        0.0675  libpthread-0.9.33.2.so   __pthread_cleanup_pop_restore
20        0.0643  fceumm_libretro_gcw0.so  SexyFilter
16        0.0514  libm-0.9.33.2.so         /lib/libm-0.9.33.2.so
15        0.0482  busybox                  /bin/busybox
11        0.0354  libpthread-0.9.33.2.so   pthread_mutex_unlock
8         0.0257  libasound.so.2.0.0       /usr/lib/libasound.so.2.0.0
7         0.0225  retroarch-gcw0           gl_frame
6         0.0193  fceumm_libretro_gcw0.so  FCEUPPU_LineUpdate
6         0.0193  oprofiled                /usr/bin/oprofiled
5         0.0161  retroarch-gcw0           gl_glsl_set_params
4         0.0129  libEGL.so.1.0.0          /usr/lib/libEGL.so.1.0.0
4         0.0129  libGLESv2.so.2.0.0       /usr/lib/libGLESv2.so.2.0.0
4         0.0129  retroarch-gcw0           font_renderer_init
3         0.0096  fceumm_libretro_gcw0.so  FrameSoundUpdate
3         0.0096  fceumm_libretro_gcw0.so  X6502_DMR
3         0.0096  libSDL-1.2.so.0.11.4     /usr/lib/libSDL-1.2.so.0.11.4
3         0.0096  libpthread-0.9.33.2.so   pthread_getspecific
3         0.0096  retroarch-gcw0           gfx_ctx_update_window_title
3         0.0096  retroarch-gcw0           linuxraw_joypad_button
3         0.0096  retroarch-gcw0           rarch_main_iterate
3         0.0096  retroarch-gcw0           resampler_sinc_new
2         0.0064  fceumm_libretro_gcw0.so  X6502_DMW
2         0.0064  fceumm_libretro_gcw0.so  crc32
2         0.0064  fceumm_libretro_gcw0.so  md5_process
2         0.0064  libpthread-0.9.33.2.so   pthread_cond_signal
2         0.0064  retroarch-gcw0           audio_sample_batch
2         0.0064  retroarch-gcw0           do_state_checks
2         0.0064  retroarch-gcw0           gl_alive
2         0.0064  retroarch-gcw0           gl_glsl_set_coords.part.32
2         0.0064  retroarch-gcw0           input_joypad_pressed
2         0.0064  retroarch-gcw0           sdl_input_state
2         0.0064  retroarch-gcw0           video_frame
1         0.0032  fceumm_libretro_gcw0.so  ARAML
1         0.0032  fceumm_libretro_gcw0.so  B2004
1         0.0032  fceumm_libretro_gcw0.so  B2007
1         0.0032  fceumm_libretro_gcw0.so  B4014
1         0.0032  fceumm_libretro_gcw0.so  BRAML
1         0.0032  fceumm_libretro_gcw0.so  FCEUMOV_AddJoy
1         0.0032  fceumm_libretro_gcw0.so  FCEU_DrawSaveStates
1         0.0032  fceumm_libretro_gcw0.so  FlushEmulateSound
1         0.0032  fceumm_libretro_gcw0.so  setprg16r
1         0.0032  libpthread-0.9.33.2.so   __pthread_mutex_cond_lock
1         0.0032  libpthread-0.9.33.2.so   pthread_cond_wait
1         0.0032  retroarch-gcw0           alsa_write
1         0.0032  retroarch-gcw0           check_shader_dir
1         0.0032  retroarch-gcw0           gl_glsl_use
1         0.0032  retroarch-gcw0           gl_viewport_info
1         0.0032  retroarch-gcw0           msg_queue_pull
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: wumpus on September 23, 2013, 04:30:14 pm
CPU load shouldn't be that high. It looks like it  making a lot of calls to the GLES2 driver. What does the GL rendering code look like? (for example if it's doing a glDraw call per quad, that's the problem)
Can you maybe make an apitrace? Run with:
Code: [Select]
apitrace trace -a egl <executable>
Then send the .trace file.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on September 24, 2013, 03:50:35 am
Ok, this is the apitrace file.

http://www.gamefront.com/files/23720874/retroarch-gcw0.7z
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: zear on September 24, 2013, 02:37:47 pm
I'm getting "403 - Forbidden" on an attempt to download the file from your link.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: wumpus on September 24, 2013, 04:57:57 pm
He sent it to me by mail, I can send it through if you're interested.
It appears that the problem causing the high CPU (and underutilized GPU) load is texture conversion overhead. It's even spending a lot of time converting floats to/from ints. We don't know yet which program behaviour causes this.

Code: [Select]
3265     11.0099  egl_gallium.so           _mesa_apply_rgba_transfer_ops
3113     10.4974  egl_gallium.so           _mesa_make_temp_ubyte_image
3024     10.1973  egl_gallium.so           extract_float_rgba
2983     10.0590  egl_gallium.so           _mesa_unpack_color_span_ubyte
1103      3.7194  egl_gallium.so           pack_row_ubyte_XRGB8888
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on September 24, 2013, 07:09:11 pm
Here is another link, it should work now: http://www.speedyshare.com/fS4Xk/retroarch-gcw0.7z
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: wumpus on September 27, 2013, 08:11:40 am
I've committed this to remove the texture conversion overhead when using non-RGBx8888 formats:

https://github.com/laanwj/mesa/commit/0c71bcf1c5cc06e26bfed7a72507555fe7e7ad97
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on September 29, 2013, 01:18:49 am
I'm trying to test wumpus patch, I have successfully built the rootfs.squashfs file, renamed it to update_r.bin and copy it to /media/data on the device but after I reboot there is the following error: unable to mount /dev/loop.  The unit restarts and I have to press Y to fix it.  After that the update_r.bin file is deleted.

Any idea of what could be happening? Does the rootfs.squashfs file is corrupted?
It was built following the instructions from the wiki.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: pcercuei on September 29, 2013, 08:15:08 am
Maybe the transfer failed? Anyway, do *not* transfer a new update_r.bin while you run the backup roots, you will brick the device if it's another unbootable rootfs and you'd have to reflash. Instead, replace directly the regular rootfs.bin on the data partition.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on September 30, 2013, 12:48:54 am
Thanks pcercuei, I was about to copy update_r.bin again!.  Ok, rebuilt the rootfs image, copied it as rootfs.bin and it worked fine, maybe the transfer failed the first time as you suggested.

I have tested the app again using the gl driver, it works fine already.  It's not working fine without the smooth filter though, it seems that the vsync option is not working or a visual artifact caused by scaling is occurring.

Unfortunately the snes core is still running too slow, tested the Street Fighter II rom and it runs very slow.  I'm a bit surprised actually of how slow it runs, will do some profiling again to find the cause of this poor performance.

Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Awakened on September 30, 2013, 01:50:27 am
There was an update to VBA Next that added tiled rendering. It's sped up that core enough to make it fullspeed for most games on the Wii. Maybe it's enough for the Zero as well.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on September 30, 2013, 03:21:03 am
That's right, I have to try it out, but there is already a fullspeed gba emu though. 

Anyway I have to wait for a new firmware update that includes wumpus patch, to make a release.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on October 11, 2013, 03:51:03 am
Ok, finally got time to test the new firmware, which comes with the latest etnaviv driver.

I can confirm the gl driver and retroarch's gui (rgui) are working now.  There are still things to be done before working on a public release, like commiting the port changes to the libretro team.

But first, there is currently a bug which causes the app to freeze when resuming or resetting a game.  I have tracked the issue using gdb but I haven't been able to find the cause of it.

I don't have much free time now, so if any dev would like to help with the port, please contact me.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Shin-NiL on October 11, 2013, 03:33:34 pm
It's fantastic, the_gama! I've tried again, but I was not able to build a working gl driver.

And about performance? It's better than SDL driver? Which cores did you test this time?


Thanks.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on October 12, 2013, 01:10:22 am
I think it has the same performance as the SDL driver, but it adds several nice and usefull features: support for retroarch builtin gui, shaders, hardware scaling and filtering, and some additional cores like the model and scene viewers.

I have found the cause of the issue I described in my previous post, so now I will test which cores could be included in a release to work on it.

There are still things to be done though, like cleaning the sources, commit the changes to the libretro team, testing, etc. Shin, if you are interested and have some time, I can send you the sources so you can try the app.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: BlockABoots on November 09, 2013, 02:17:49 pm
I cant wait for RetroArch to be released on the GCW-Zero, will just be sooo nice to have just one continuity for a frontend to be used for all emulators. Is there any update on a possible release date the_gama, im guessing PS1 emulation will be out of the question? Im hoping the boost to the cpu clock that the latest FW contains will help performance
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: pcercuei on November 09, 2013, 04:52:18 pm
Im hoping the boost to the cpu clock that the latest FW contains will help performance
What the hell are you talking about? The CPU clock has not been changed since the debuts of OD on the Zero.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: BlockABoots on November 09, 2013, 05:19:37 pm
Sorry ment the GPU clock

"set GPU clock to 500 MHz (was 432 MHz)"
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: deBeauharnais on June 22, 2014, 09:42:39 pm
Any update about retroarch, guys?
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Malleus on June 23, 2014, 08:44:56 am
yes, would be interesting to know if tripplebuffering helps any for example   :)
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: forphucksakes on December 06, 2014, 04:43:27 pm
^bump
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: iesposta on January 10, 2015, 07:15:55 pm
Any update about retroarch, guys?

+1 for Retroarch OR update Stella 2600!
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Nebuleon on January 10, 2015, 08:45:02 pm
+1 for Retroarch OR update Stella 2600!
Stella 2600 is out of the scope of this thread. Please talk about that on the Stella thread.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Kivutar on December 04, 2015, 06:48:25 pm
I added a vivante_fbdev context driver in retroarch one year ago. It is based on the mali_fbdev by maister.

You need to configure with --enable-gles --disable-kms --enable-vivante_fbdev

It has been tested extensively on Vivante GC2000, and may work on Vivante GC800.

You should try it on gcw0 :)
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Radioboy86 on December 07, 2015, 02:55:12 am
Hey guys any chance i could get help on porting this to the a320 owners Opendingux?

Soruce code? Can you guys compile it? I am very dumb at this. i try and i try and... I fail :D

Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on February 08, 2016, 06:06:05 pm
Hi, I would like to make a new build of retroarch for the gcw0.

I wrote a gfx context driver based on the vivante_fbdev driver.  But I get the following error during build:

Code: [Select]
/opt/gcw0-toolchain/usr/lib/gcc/mipsel-gcw0-linux-uclibc/4.9.1/../../../../mipsel-gcw0-linux-uclibc/bin/ld: obj-unix/input/drivers/udev_input.o: undefined reference to symbol '[email protected]@LIBUDEV_183'
/opt/gcw0-toolchain/usr/lib/gcc/mipsel-gcw0-linux-uclibc/4.9.1/../../../../mipsel-gcw0-linux-uclibc/bin/ld: note: '[email protected]@LIBUDEV_183' is defined in DSO /opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot/lib/libudev.so.1 so try adding it to the linker command line
/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot/lib/libudev.so.1: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

I run configure with the following commands:

Code: [Select]
export PATH=$PATH:/opt/gcw0-toolchain/usr/bin:/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot/usr/bin
then

Code: [Select]
./configure --host=mipsel-gcw0-linux-uclibc --prefix=/tmp --enable-gles --disable-kms --enable-opendingux_fbdev --enable-alsa --with-gles_libs="-lGLESv2 -lEGL"

Anyone knows what causes the error?

By the way, does anyone have a more recent toolchain?  The official link is from 2014.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: David Knight on February 08, 2016, 06:20:14 pm
Code: [Select]
/opt/gcw0-toolchain/usr/lib/gcc/mipsel-gcw0-linux-uclibc/4.9.1/../../../../mipsel-gcw0-linux-uclibc/bin/ld: obj-unix/input/drivers/udev_input.o: undefined reference to symbol '[email protected]@LIBUDEV_183'
/opt/gcw0-toolchain/usr/lib/gcc/mipsel-gcw0-linux-uclibc/4.9.1/../../../../mipsel-gcw0-linux-uclibc/bin/ld: note: '[email protected]@LIBUDEV_183' is defined in DSO /opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot/lib/libudev.so.1 so try adding it to the linker command line
/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot/lib/libudev.so.1: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
As the error message states this is a linking error, have you tried adding "-ludev"?
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on February 08, 2016, 07:44:44 pm
Thanks David, RetroArch's autoconf file uses pkg-config to automatically add library dependencies.

Do you know how do I set pkg-config enviroment variables?
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Quickman on February 08, 2016, 11:48:30 pm
@the_gama  at the beginning of your post you stated, "My main interest was having accurate and fast snes emulation on the console."

 I'm curious, what your reasoning for porting RA would be at this point? Unless I'm completely mistaken (which is possible because I literally just got a GCW zero) I was made to believe the SNES emulation was running really well.

 Either way, thank you so much for your creativity and hard work! I'm always curious to see what people are building on and creating! Thank you
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on February 10, 2016, 06:37:55 pm
@the_gama  at the beginning of your post you stated, "My main interest was having accurate and fast snes emulation on the console."

Well, I wrote that back in 2013 :).  Only a few emulators were released by then, and I wanted to try retroarch and specially the snes cores on the zero. 

I only port stuff as a hobby, and I am a huge fan of retroarch.  Those are the only reasons to try it now :).


Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on February 10, 2016, 06:58:08 pm
Ok, I managed to built the latest revision of retroarch yesterday, and I am testing the different features available from the RGUI menu. 

I tested the network option to download assets and stuff, but unfortunately there is a connection error.
I looked through the code and found an small application to test the network connection used by retroarch.

These are the two main files,

Code: [Select]
#include <stdio.h>
#include <net/net_http.h>
#include <net/net_compat.h>

#ifdef _WIN32
#include <winsock2.h>
#endif

int main(void)
{
   char   *data;
   struct http_t *http1 = NULL, *http3 = NULL;
   struct http_connection_t *conn1 = NULL, *conn3 = NULL;
   size_t len, pos = 0, tot = 0;

   fprintf(stderr, "http_test: network_init()\n");
   if (!network_init())
      return -1;

   fprintf(stderr, "http_test: net_http_connection_new()\n");
   conn1 = net_http_connection_new("http://buildbot.libretro.com/nightly/win-x86/latest/mednafen_psx_libretro.dll.zip");
   if (!conn1)
      goto error;

   while (!net_http_connection_iterate(conn1)) {}
   if (!net_http_connection_done(conn1))
   {
      fprintf(stderr, "http_test: malformed url\n");
      goto error;
   }

   fprintf(stderr, "http_test: net_http_new()\n");
   http1 = net_http_new(conn1);
   if (!http1)
      goto error;

   fprintf(stderr, "http_test: net_http_update()\n");
   while (!net_http_update(http1, &pos, &tot))
      fprintf(stderr, "%.9lu / %.9lu        \r",pos,tot);

   conn3 = net_http_connection_new("http://www.wikipedia.org/");
   if (!conn3)
      goto error;

   while (!net_http_connection_iterate(conn3)) {}
   if (!net_http_connection_done(conn3))
   {
      fprintf(stderr, "http_test: malformed url\n");
      goto error;
   }

   http3 = net_http_new(conn3);
   if (!http3)
      goto error;
   
   while (!net_http_update(http3, NULL, NULL)) {}

   data  = (char*)net_http_data(http3, &len, false);

   fprintf(stderr, "%.*s\n", (int)256, data);

error:
   if ( http1 )
      net_http_delete( http1 );

   if ( conn1 )
      net_http_connection_free( conn1 );

   if ( http3 )
      net_http_delete( http3 );

   if ( conn3 )
      net_http_connection_free( conn3 );

   
   network_deinit();

   return 0;
}

Code: [Select]
/*  RetroArch - A frontend for libretro.
 *  Copyright (C) 2011-2015 - Daniel De Matteis
 *  Copyright (C) 2014-2015 - Alfred Agrell
 *
 *  RetroArch is free software: you can redistribute it and/or modify it under the terms
 *  of the GNU General Public License as published by the Free Software Found-
 *  ation, either version 3 of the License, or (at your option) any later version.
 *
 *  RetroArch is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
 *  without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
 *  PURPOSE.  See the GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License along with RetroArch.
 *  If not, see <http://www.gnu.org/licenses/>.
 */

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

#include <net/net_http.h>
#include <net/net_compat.h>
#include <compat/strl.h>

enum
{
   P_HEADER_TOP = 0,
   P_HEADER,
   P_BODY,
   P_BODY_CHUNKLEN,
   P_DONE,
   P_ERROR
};

enum
{
   T_FULL = 0,
   T_LEN,
   T_CHUNK
};

struct http_t
{
int fd;
int status;

char part;
char bodytype;
bool error;

size_t pos;
size_t len;
size_t buflen;
char * data;
};

struct http_connection_t
{
   char *domain;
   char *location;
   char *urlcopy;
   char *scan;
   int port;
};


static int net_http_new_socket(const char *domain, int port)
{
   int fd;
#ifndef _WIN32
#ifndef VITA
   struct timeval timeout;
#endif
#endif
   struct addrinfo hints, *addr = NULL;
   char portstr[16] = {0};
   
   /* Initialize the network. */
   if (!network_init())
      return -1;

   snprintf(portstr, sizeof(portstr), "%i", port);

   memset(&hints, 0, sizeof(hints));
   hints.ai_family   = AF_UNSPEC;
   hints.ai_socktype = SOCK_STREAM;
   hints.ai_flags    = 0;
   
   if (getaddrinfo_retro(domain, portstr, &hints, &addr) < 0)
      return -1;
   if (!addr)
      return -1;

   fd = socket(addr->ai_family, addr->ai_socktype, addr->ai_protocol);

#ifndef _WIN32
#ifndef VITA
   timeout.tv_sec=4;
   timeout.tv_usec=0;
   setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, (char*)&timeout, sizeof timeout);
#endif
#endif
   if (connect(fd, addr->ai_addr, addr->ai_addrlen) != 0)
   {
      freeaddrinfo_retro(addr);
      socket_close(fd);
      return -1;
   }

   freeaddrinfo_retro(addr);

   if (!socket_nonblock(fd))
   {
      socket_close(fd);
      return -1;
   }

   return fd;
}

static void net_http_send(int fd, bool * error,
      const char * data, size_t len)
{
   if (*error)
      return;

   while (len)
   {
      ssize_t thislen = send(fd, data, len, MSG_NOSIGNAL);

      if (thislen <= 0)
      {
         if (!isagain(thislen))
            continue;

         *error=true;
         return;
      }

      data += thislen;
      len  -= thislen;
   }
}

static void net_http_send_str(int fd, bool *error, const char *text)
{
   net_http_send(fd, error, text, strlen(text));
}

static ssize_t net_http_recv(int fd, bool *error,
      uint8_t *data, size_t maxlen)
{
   ssize_t bytes;

   if (*error)
      return -1;

   bytes = recv(fd, (char*)data, maxlen, 0);

   if (bytes > 0)
      return bytes;
   else if (bytes == 0)
      return -1;
   else if (isagain(bytes))
      return 0;

   *error=true;
   return -1;
}

struct http_connection_t *net_http_connection_new(const char *url)
{
   size_t length;
   char **domain = NULL;
   struct http_connection_t *conn = (struct http_connection_t*)calloc(1,
         sizeof(struct http_connection_t));

   if (!conn)
      return NULL;

   length             = strlen(url) + 1;
   conn->urlcopy      = (char*)malloc(length);

   if (!conn->urlcopy)
      goto error;

   strlcpy(conn->urlcopy, url, length);

   if (strncmp(url, "http://", strlen("http://")) != 0)
      goto error;

   conn->scan    = conn->urlcopy + strlen("http://");

   domain        = &conn->domain;

   *domain = conn->scan;

   return conn;

error:
   if (conn->urlcopy)
      free(conn->urlcopy);
   conn->urlcopy = NULL;
   free(conn);
   return NULL;
}

bool net_http_connection_iterate(struct http_connection_t *conn)
{
   if (!conn)
      return false;
   if (*conn->scan != '/' && *conn->scan != ':' && *conn->scan != '\0')
   {
      conn->scan++;
      return false;
   }
   return true;
}

bool net_http_connection_done(struct http_connection_t *conn)
{
   char **location = NULL;

   if (!conn)
      return false;

   location = &conn->location;

   if (*conn->scan == '\0')
      return false;

   *conn->scan   = '\0';
   conn->port   = 80;

   if (*conn->scan == ':')
   {

      if (!isdigit((int)conn->scan[1]))
         return false;

      conn->port = strtoul(conn->scan + 1, &conn->scan, 10);

      if (*conn->scan != '/')
         return false;
   }

   *location = conn->scan + 1;

   return true;
}

void net_http_connection_free(struct http_connection_t *conn)
{
   if (!conn)
      return;

   if (conn->urlcopy)
      free(conn->urlcopy);

   free(conn);
}

const char *net_http_connection_url(struct http_connection_t *conn)
{
   return conn->urlcopy;
}

struct http_t *net_http_new(struct http_connection_t *conn)
{
   bool error;
   int fd = -1;
   struct http_t *state      = NULL;

   if (!conn)
      goto error;

   fd = net_http_new_socket(conn->domain, conn->port);
   if (fd == -1)
      goto error;

   error=false;

   /* This is a bit lazy, but it works. */
   net_http_send_str(fd, &error, "GET /");
   net_http_send_str(fd, &error, conn->location);
   net_http_send_str(fd, &error, " HTTP/1.1\r\n");

   net_http_send_str(fd, &error, "Host: ");
   net_http_send_str(fd, &error, conn->domain);

   if (conn->port != 80)
   {
      char portstr[16] = {0};

      snprintf(portstr, sizeof(portstr), ":%i", conn->port);
      net_http_send_str(fd, &error, portstr);
   }

   net_http_send_str(fd, &error, "\r\n");
   net_http_send_str(fd, &error, "Connection: close\r\n");
   net_http_send_str(fd, &error, "\r\n");

   if (error)
      goto error;

   state          = (struct http_t*)malloc(sizeof(struct http_t));
   state->fd      = fd;
   state->status  = -1;
   state->data    = NULL;
   state->part    = P_HEADER_TOP;
   state->bodytype= T_FULL;
   state->error   = false;
   state->pos     = 0;
   state->len     = 0;
   state->buflen  = 512;
   state->data    = (char*)malloc(state->buflen);

   if (!state->data)
      goto error;

   return state;

error:
   if (fd != -1)
      socket_close(fd);
   return NULL;
}

int net_http_fd(struct http_t *state)
{
   if (!state)
      return 0;
   return state->fd;
}

bool net_http_update(struct http_t *state, size_t* progress, size_t* total)
{
   ssize_t newlen = 0;

   if (!state || state->error)
      goto fail;

   if (state->part < P_BODY)
   {
      newlen = net_http_recv(state->fd, &state->error,
            (uint8_t*)state->data + state->pos, state->buflen - state->pos);

      if (newlen < 0)
         goto fail;

      if (state->pos + newlen >= state->buflen - 64)
      {
         state->buflen *= 2;
         state->data = (char*)realloc(state->data, state->buflen);
      }
      state->pos += newlen;

      while (state->part < P_BODY)
      {
         char *dataend = state->data + state->pos;
         char *lineend = (char*)memchr(state->data, '\n', state->pos);

         if (!lineend)
            break;
         *lineend='\0';
         if (lineend != state->data && lineend[-1]=='\r')
            lineend[-1]='\0';

         if (state->part == P_HEADER_TOP)
         {
            if (strncmp(state->data, "HTTP/1.", strlen("HTTP/1."))!=0)
               goto fail;
            state->status = strtoul(state->data + strlen("HTTP/1.1 "), NULL, 10);
            state->part   = P_HEADER;
         }
         else
         {
            if (!strncmp(state->data, "Content-Length: ",
                     strlen("Content-Length: ")))
            {
               state->bodytype = T_LEN;
               state->len = strtol(state->data +
                     strlen("Content-Length: "), NULL, 10);
            }
            if (!strcmp(state->data, "Transfer-Encoding: chunked"))
               state->bodytype = T_CHUNK;

            /* TODO: save headers somewhere */
            if (state->data[0]=='\0')
            {
               state->part = P_BODY;
               if (state->bodytype == T_CHUNK)
                  state->part = P_BODY_CHUNKLEN;
            }
         }

         memmove(state->data, lineend + 1, dataend-(lineend+1));
         state->pos = (dataend-(lineend + 1));
      }
      if (state->part >= P_BODY)
      {
         newlen = state->pos;
         state->pos = 0;
      }
   }

   if (state->part >= P_BODY && state->part < P_DONE)
   {
      if (!newlen)
      {
         newlen = net_http_recv(state->fd, &state->error,
               (uint8_t*)state->data + state->pos,
               state->buflen - state->pos);

         if (newlen < 0)
         {
            if (state->bodytype == T_FULL)
            {
               state->part = P_DONE;
               state->data = (char*)realloc(state->data, state->len);
            }
            else
               goto fail;
            newlen=0;
         }

         if (state->pos + newlen >= state->buflen - 64)
         {
            state->buflen *= 2;
            state->data = (char*)realloc(state->data, state->buflen);
         }
      }

parse_again:
      if (state->bodytype == T_CHUNK)
      {
         if (state->part == P_BODY_CHUNKLEN)
         {
            state->pos += newlen;
            if (state->pos - state->len >= 2)
            {
               /*
                * len=start of chunk including \r\n
                * pos=end of data
                */

               char *fullend = state->data + state->pos;
               char *end     = (char*)memchr(state->data + state->len + 2,
                     '\n', state->pos - state->len - 2);

               if (end)
               {
                  size_t chunklen = strtoul(state->data+state->len, NULL, 16);
                  state->pos      = state->len;
                  end++;

                  memmove(state->data+state->len, end, fullend-end);

                  state->len      = chunklen;
                  newlen          = (fullend - end);

                  /*
                     len=num bytes
                     newlen=unparsed bytes after \n
                     pos=start of chunk including \r\n
                     */

                  state->part = P_BODY;
                  if (state->len == 0)
                  {
                     state->part = P_DONE;
                     state->len  = state->pos;
                     state->data = (char*)realloc(state->data, state->len);
                  }
                  goto parse_again;
               }
            }
         }
         else if (state->part == P_BODY)
         {
            if ((size_t)newlen >= state->len)
            {
               state->pos += state->len;
               newlen     -= state->len;
               state->len  = state->pos;
               state->part = P_BODY_CHUNKLEN;
               goto parse_again;
            }
            else
            {
               state->pos += newlen;
               state->len -= newlen;
            }
         }
      }
      else
      {
         state->pos += newlen;

         if (state->pos == state->len)
         {
            state->part = P_DONE;
            state->data = (char*)realloc(state->data, state->len);
         }
         if (state->pos > state->len)
            goto fail;
      }
   }

   if (progress)
      *progress = state->pos;

   if (total)
   {
      if (state->bodytype == T_LEN)
         *total=state->len;
      else
         *total=0;
   }

   return (state->part == P_DONE);

fail:
   if (state)
   {
      state->error  = true;
      state->part   = P_ERROR;
      state->status = -1;
   }

   return true;
}

int net_http_status(struct http_t *state)
{
   if (state)
      return state->status;
   return -1;
}

uint8_t* net_http_data(struct http_t *state, size_t* len, bool accept_error)
{
   if (!state)
      return NULL;

   if (!accept_error && net_http_error(state))
   {
      if (len)
         *len=0;
      return NULL;
   }

   if (len)
      *len=state->len;

   return (uint8_t*)state->data;
}

void net_http_delete(struct http_t *state)
{
   if (!state)
      return;

   if (state->fd != -1)
      socket_close(state->fd);
   free(state);
}

bool net_http_error(struct http_t *state)
{
   return (state->error || state->status<200 || state->status>299);
}

Failure occurs on line 103 of the second file: if (connect(fd, addr->ai_addr, addr->ai_addrlen) != 0)

Can anyone help me to find what could be causing this failure?
I can post all the files to build the sample test if you would like.
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: Quickman on February 10, 2016, 07:15:53 pm
@the_gama  at the beginning of your post you stated, "My main interest was having accurate and fast snes emulation on the console."

Well, I wrote that back in 2013 :).  Only a few emulators were released by then, and I wanted to try retroarch and specially the snes cores on the zero. 

I only port stuff as a hobby, and I am a huge fan of retroarch.  Those are the only reasons to try it now :).

@the_gama that's awesome. Passion projects are the best! Thanks for your hard work and I look forward to seeing all the updates! Also, thank you so much for your response. :D
I'll stay tuned :)
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: gameblabla on February 10, 2016, 09:55:04 pm
Failure occurs on line 103 of the second file: if (connect(fd, addr->ai_addr, addr->ai_addrlen) != 0)
Can anyone help me to find what could be causing this failure?
I can post all the files to build the sample test if you would like.
Could you please tell us how you compiled Retroarch ?
Because last time i tried, i got a non-working executable. (it was not even bringing up the RGUI)
Title: Re: [TEST RESULT] Test port of RetroArch running on gcw0
Post by: the_gama on February 11, 2016, 01:48:14 am
Could you please tell us how you compiled Retroarch ?
Because last time i tried, i got a non-working executable. (it was not even bringing up the RGUI)

Yes, of course.  All that is needed is a gfx_context_driver to use the gles video driver, autoconf and pkg-config takes care of everything else.  I will post all the steps to build it, I just need to prepare a patch with the changes.