Daedalus R10 - Primeras informaciones

a ver si alguien lo traduze (yo esque de ingles poco ).gracias por la informacion

esperando traducion podria ponerla en google pero seria triste

grcias por la info, estamos deseando pillar la r11
por fin soy el primero en reponder un post, lo dixo thanks

P.d. ya se me han adelantado jej estais al pie del cañon

Muyyyyyyyyyyyyyyyyyyyyyyyy interesanteeeeeeeeeeeee!!!

Para cuando esta programada la salida del r10?

traduccion please

salu2

llendo a lo que le interesa a casi todo el mundo, pues viene a decir que consigue en algunos juegos un aumento de la velocidad entre un 10 y un 15%.
Espero con ansias la salida del emu para hacer pruebas.

Bueno aquí pongo una traducción, no esta totalmente bien pero es que no entiendo a pa perfeccion el ingles i la he hecho con el traductor, tengo k marchar por lo k no e podido repasarla.
La questión es que se entiende, aquí ta;

Yo no quise dejarlo bastante tan largo desde último fin de semana actualización, pero yo he estado trabajando difícilmente en varios optmisations para R10. Extrañamente bastante éstos son principalmente nuevos problemas que yo he encontrado - la mayoría de ellos no existe en la lista de tareas que yo propuse hace un par de semanas. ¡Yo pienso que muestra cuánto alcance hay para el optimising Daedalus!

Primeramente, yo manejé conseguir Daedalus que compilan con finalmente GCC ' -O3 ' poniendo. Esta bandera enciende todo el optimisations que GCC proporciona. Cuando yo he intentado habilitar esta bandera en el pasado que yo he tenido numerosas caídas extrañas y los behaviour impares, para que se han compilado todos los descargos de Daedalus para fechar con -O1.

Yo puse al día mi instalación local del PSPSDK en último lugar pase el fin de semana y decidió probar el -O3 que pone de nuevo. Yo fui agradado para encontrar ese Daedalus corrió sin chocar, pero había todavía algún behaviour impar que yo rastreé en el futuro abajo a mi uso de la función de InvSqrt famosa. Usted puede leer más a un pedazo sobre mis resultados en los foros del pspdev.

Habilitando -O3 tiende a aumentar el tamaño del código ligeramente (el EBOOT. PBP ha aumentado de alrededor de 850KB a 900KB), pero el speedup realmente es el noticable - mi estimación es ese carreras de Daedalus alrededor de 5% más rápido con -O3 encima de -O1.

Como resultado del hilo yo empecé en los foros del pspdev, hlide y Raphael para que los dos propusieron algunas grandes sugerencias cómo yo pudiera perfeccionar mi uso del VFPU.

Cuando yo escribí originalmente que los VFPU codifican para TnL y sujetando había todavía muchas funciones del undocumented/unsupported. Unos meses abajo la línea y el hlide y co han descubierto un par de instrucciones que son perfecto para mis necesidades - a saber el vuc2i y vc2i. Estas dos funciones toman un valor del 32-pedazo que comprende de 4 (los trabajos por horas de 8-pedazo de un)signed y los desempaqueta en un vector de 4 32-pedazo arregló los números del punto. Resulta que que estas instrucciones son perfectas para convertir los colour condensados del N64 y valores del normal en un formato que yo puedo usar en el código de VFPU.

El varios VFPU pellizca yo he hecho le ha dado otro 5% a Daedalus o para que el speedup.

El juego final de cambios yo he estado trabajando en esta semana ha sido hacer con cómo yo me ocupo de ciertos modos de la mezcla. Algunos de los N64 mezcla modos son demasiado complejos para el PSP precisamente repartir con, para que yo tengo una mesa grande de ' los override' mezclan modos que me permiten hacer como bueno una aproximación del modo de N64 como posible. Resultó que buscando estos modos de la mezcla era muy caro, para que yo he vuelto a escribir cómo esto se maneja para hacerlo más eficaz. El resultado del extremo es otro speedup pequeño.

En conjunto estos tres cambios dan un combinó 10-15% speedup en los varios juegos que yo he probado, aunque hay roms que quedan fuera de este rango (alguna muestra un speedup aun mayores mientras otros son más sencillos por los cambios).

Hay todavía muchos más de la manera de optimisations que yo quiero entrar para Daedalus R10 (principalmente el material yo mencioné antes) tan esperanzadamente estos números incluso mejorarán más allá encima de la próxima pareja de semanas.

me ganaron con la traducción


bueno, aqui dejo mi xaputraducción. también está a la rapida, y hay partes que no he entendido muy bien.

espero que sirva para entender un poco mas.

xaputraducción escribió:Daedalus R10, progreso de la Optimización

No quiero decir que haya dejado mucho tiempo entre la última actualización del fin de semana, pero he estado trabajando duramente en algunas optimizaciones para el R10. Bastantes de estas mejoras son precisamente sobre lo que he encontrado en la nueva versión - muchas de ellas no existen en la lista de tareas que me traje hace un par de semanas atrás. Pienso que esto muestra el alcance que puede haber en la optimización del Daedalus!

Antes que todo, finalmente he logrado compilar Daedalus con el parámetro de 'GCC' '-O3'. Este flag (termino informático) habilita todas las optimizaciones que GCC pueda proveer. cuando intenté establecer este flag en el pasado, obtuve numerosos cuelgues extraños y un comportamiento aleatorio, por lo que todas las actualizaciones de Daedalus hasta la fecha, han sido compiladas con el parámetro '-O1'.

He actualizado mi instalación local del PSPSDK la ultima semana, y me decidí a intentar establecer el '-O3' otra vez. Por fin me sentí satisfecho de ejecutar el Daedalus sin cuelgues, aunque todavía existen algunos comportamientos extraños que eventualmente revisaré hasta llegar al uso de la famosa función InvSqrt (Esta parte no supe traducirla correctamente). Puedes leer un poco mas sobre lo que he encontrado en los forums de pspdev.

Habilitando '-O3', tenderá a aumentar el tamaño del código lévemente (el EBOOT.PBP ha cresido desde los 850KB a los 900KB), aunque la velocidad es apreciable. Mi estimación es que Daedalus corre cerca del 5% mas rapido con '-O3' que con '-O1'.

Como resultado de esta "vuelta de tuerca" que empecé en los foros de pspdev, hlide y Raphael se han acercado con algunas grandes sugerencias sobre como poder optimizar mi uso del VFPU

Cuando originalmente escribí el código del VFPU para el "TnL And Clipping" (npi de como traducir), todavía existían muchas funciones no soportadas o indocumentadas. Un par de meses fuera de la scene, y hlide & compañía descubrieron un par de instrucciones que eran perfectas para mis necesidades - llamadas vuc2i y vc2i. Estas dos funciones toman un valor de 32-bits de compresión de 4 (un)signed caracteres de 8-bits y desempaquetandolos en un vector de 4 32-bits de punto fijo. Esto cambia ya que estas instrucciones son perfectas para convertir los paquetes de color de la N64, y los valores normales dentro de un formato que puedo utilizar con el codigo de la VFPU (todo este tocho lo he traducido sin saber muy bien que es lo que quiere decir.)

Con varios ajustes a la VFPU puedo hacer que Daedalus gane otros 5% mas o menos, de velocidad.

El conjunto final de cambios en los que estoy trabajando en esta semana han sido, cómo opder maipular algunos modos "blend". Algunos de los modos "blend" de la N64 son muy complejos para que la PSP los pueda manejar precisamente, por lo que tengo una gran tabla para "sobreescribir" los modos "blends" lo que me permitirá aproximarme lo mas posible al modo de la N64. Resulta que mirar este tipo de modos "blend" es muy dificultoso, por lo que he reescrito como se maneja esto, para hacerlo mas eficiente. El resultado final es otro pequeño incremento de velocidad.

Con estos tres cambios combinados, el incremento de velocidad es de un 10-15% en varios juegos que he probado, aunque todavía existen roms que estan fuera de este rango (algunos muestran un gran incremento de velocidad, mientras que otros se ven afectados en en mayor o menor grado por los cambios)

Aún queda mucho mas que hacer en el camino de las optimizaciones que espero incorporar en Daedalus R10 (además de lo que he mencionado anteriormente), asi que con un poco de suerte estas mejoras estarán en un par de semanas.

Zalu2!

Disculpa Rheinhardt, leíste algo de lo que posteaste?

esto lo puse yo hace tiempo, pero sin traduccion...

MMm, muy interesante, según lo que leí, el creador, cuando intentaba compilar el programa con "GCC - 03", tenía muchos problemas con el emu, pero el fin de semana actualizó su entorno de programaación y porfín pudo compilar el programa sin tantos problemas, solo algunos y que los intentará solucionar, lo verdaderamente interesante es esto:

Los juegos tendrán entre un 10 y un 15 por ciento de optimización, algunos puede ser mayor, y en algunos menor.

Vaya, tremendo avanze en esto de la scene de la PSP, pronto podremos jugar un Mario 64 o un Zelda en nuestra querida PSP, por razones como esta, la PSP es la reina de la scene!

Yo con el mod de frameskip que sacaron hace unos días me echo mis carreritas al Mario Kart y es bastante jugable, vamos que no me aburro

El Super Mario 64 tb funciona muy bien.

A ver si con estas mejoras se incrementa algo más la velocidad y dentro de unas cuantas versiones más, tenemos el emulador de 64 definitivo!

con esto y el frame-skip que quería implementar y comentó que se le olvidó.. si le quitamos el sonido para ahorrar cpu... parece que varios juegos va a ser bastante jugables...

2 entradas más en su blog

Frameskip

A couple of people have been commenting about the mysterious frameskip version of Daedalus R9 which appeared a short while ago. I'm not going to link to it because I can't verify where it came from. That said, I've not checked my email for a week so maybe the author has emailed me about it

Anyway, it just so happens that I implemented frameskip in R10 on Sunday, so expect this to be a supported feature in the next official release. I had been planning to add this to R9, but I forgot It's no big deal - it's about 20 lines of code.

It does give a slight speedup, but not always as much as you'd expect. For instance, skipping every other frame won't double the framerate, as not all the time is spent rendering. Paradoxically, it tends to have more of an effect on roms that are already running fairly fast. Hopefully for some roms it will make the different between them being barely playable and playable though.

There are a few other things people have been asking about which I will implement for R10 too:

• A configurable deadzone for the stick
• A configurable framerate limiter

A look inside Daedalus

(This is quite technical post, probably only of interest to other C++/PSP developers.)

Since I fixed the issue stopping the Expansion Pak support from working, I've been testing daedalus with the feature enabled to see if the added pressure on available RAM causes any new issues. Most roms that I've been tested have been running perfectly, but I've been experiencing occasional crashes through running out of memory. I believe this is due to a small leak somewhere, so in an effort to track it down I've been improving the tools I use to track memory usage.

In the improved tracker I override the global new and delete operators, which lets me perform some logging on every allocation/deallocation made during the course of executing the emulator (this isn't quite true, as I don't currently log calls to malloc etc, but it's good enough for my purposes). At the start of each overriden implementation, I keep track of the calling function's return address with the following snippet of code:


u32 ra;
asm volatile
(
"sw $ra, %0\n"
: "+m"(ra) : : "memory"
);


I log this return address along with the allocation size and the returned pointer for every call to new and new[]. For calls to delete and delete[], I just log the address of the memory being freed and the caller's address. This data is all logged to disk across the USB connection using PSPLink.

The logfiles look a little like this:


Allocating 36 bytes - 09c40620 - RA is 08953a94
Allocating[] 8192 bytes - 09c40a00 - RA is 0895e8bc
Allocating 12 bytes - 09c3fce0 - RA is 08964898
Allocating 12 bytes - 09c40970 - RA is 089648b0
Allocating 12 bytes - 09c409d0 - RA is 089648c8
Allocating 12 bytes - 09c408e0 - RA is 089648e0
Allocating 20 bytes - 091ceb20 - RA is 089645e8
Freeing 09c3fce0 - RA is 08962374
Freeing 09c40970 - RA is 089621fc


In order to analyse the results I've written a PC tool which scans through the logfile one line at a time 'replaying' the allocations and deallocations in the same order that they occured on the PSP. The analyser keeps track of the current state of allocations at any point in time, matching up any calls to delete with the corresponding call to new. This means that at any given time the tool has a complete list of all outstanding allocations.

I can discover any memory leaks by shutting down the emulator and continuing to record the logfile while it frees up all allocated resources. By replaying the logfile the analyser can identify any leaks, as these are (mostly) the only remaining allocations at the end of the logfile. I can then run the corresponding return addresses through psp-addr2line to discover where the leaked memory is being allocated from.

The other cool feature of the tool is that it builds up a graphical representation of the state of memory allocations at any point in time. This is really useful for figuring out where all the available RAM is going.

Here's a picture showing where most of the PSP's memory is being used while emulating Mario 64 (I've added the labels on by hand, the tool doesn't do that

http://bp3.blogger.com/_DFQdY4jxLWo/RgB0qL5losI/AAAAAAAAAEU/ivj5tN0gciA/s1600-h/daedalus_memory.png
(Es demasiado grande la foto)

Each pixel corresponds to 16 bytes of RAM. The smallest blocks are 64x64x16 bytes = 64KB. 1MB chunks are formed from 4x4 64KB blocks. The black space corresponds to both unallocated memory, and also memory allocated outside of the tracker (e.g. calls to malloc, memory used by PSPLink, the CRT, static data areas etc.) You can see that the "Emulated RAM" accounts for just over 8MB - this is because I enabled the Expansion Pak while testing. Dynarec currently uses about 6MB - Ideally I'd like to reduce this down to around 4MB soon.

You'll notice that almost all the memory Daedalus uses is for these big fixed-size allocations. What little dynamic allocation it does at runtime is limited to:

• Keeping track of hot-trace hit counts in the Dynamo implementation
• Textures and texture caching

As it turns out, the out-of-memory issues I've been having have been due to the texture cache going crazy and chewing up around 3MB of memory (typically it just uses 200-300KB or so). I've not figured out the root cause yet, but the tool has helped point me in the right direction.

All in all I think this is a pretty nifty utility as it stands, but I've been thinking about a few features that would make it even better:

• Log the time and current frame alongside each allocation/deallocation. The analyser can then use this information to see how much 'churn' there is over time. Minimising this should help improve performance and reduce fragmentation.
• Every memory allocation has a small housekeeping overhead (for alignment, keeping track of the allocation size etc). The tool could generate a histogram of allocation sizes to demonstrate how much memory is being wasted through tiny allocations, and give some indication of where pooling or freelists might help.

These are probably features for some point down the line however

That pretty much sums up the tool. If this code (either for the tracker or the logfile analyser) would be useful to anyone, let me know and I'll add it to Subversion alongside the rest of the Daedalus code with R10.

bueno, estoy algo ocupado ahora... cuando tenga un poco de tiempo lo traduzco... (uf!)