Encontrado acceso 3D en Linux para PS3

Archivado
Noticia sacada de Maxconsole.

"copio y pego"
A method has been found to reach Linux 3D Graphics on the PS3. A number of hackers have clubbed together to release a draft kernel module for this along with a relevant Xorg driver.

Hi,

I've finally been able to setup and use a second independent context. I was able to perform the 'upper VRAM workaround' from this second context, even though the first context (setup by ps3fb) has restricted upper VRAM access through DMA (by means of the lv1_gpu_memory_allocate(ps3fb_videomemory.size,... ) call).

The contexts are truely independent including:
- object bindings: since lv1_gpu_context_attribute:fb_setup fails with LV1_BUSY, we have to bind objects by hand in the newly created context. For this we can use the exact same commands FB_SETUP puts in the FIFO (http://www.everfall.com/paste/id.php?ew29498z816w) when creating the first context.
- iomapping: the lv1_gpu_context_iomap call has to be done again to allow the GPU to access XDR. The location of the mapping in GPU space (GPU_IOIF) can be the same or different from the value used by ps3fb (0x0d000000)
- FIFO control and location: the FIFO control registers initially read as zero. They can be written to with the address of the second context FIFO. In my test I used the 64kB just before the ps3fb FIFO (i.e. 128kb from the end of the XDR ps3fb_videomemory region). So I put 0x0e1e0000 in the registers (0x10000 less than the value I read in ps3fb context), yet we still have to figure out how this value is obtained from the address of the ps3fb_videomemory, so that we can locate the FIFO anywhere we want.

This means interesting things:
- We don't need the FIFO workaround anymore! But the 'upper VRAM' one is still needed and can be executed from second context.
- We should finally be able to provide one (or several) independent kernel module for all our GPU work (3D,Xorg,VRAM mtd). I'll look into this tomorrow and try to provide this module.
- We should be able to have both 3D and accelerated Xorg working at the same time.
haber si laguien lo traduci plss ,
no tiene mucho meollo para traducir... (traductor al canto):

Hola,

Finalmente he sido capaz de configurar y usar un segundo contexto independiente. Tuve la posibilidad de realizar el 'superior VRAM solución "de este segundo contexto, aunque el primer contexto (la configuración por ps3fb) ha restringido el acceso a través de VRAM superior DMA (por medio de la lv1_gpu_memory_allocate (ps3fb_videomemory.size ,...) llamada) .

Los contextos son verdaderamente independiente incluyendo:
- Objeto de enlace: desde lv1_gpu_context_attribute: fb_setup falla en la LV1_BUSY, hemos de obligar a los objetos a mano en el contexto de nueva creación. Para ello puede utilizar exactamente los mismos comandos FB_SETUP pone en el FIFO (http://www.everfall.com/paste/id.php?ew29498z816w) al crear el primer contexto.
- Iomapping: la lv1_gpu_context_iomap convocatoria se tiene que hacer de nuevo para permitir el acceso a la GPU XDR. La ubicación de la cartografía en el espacio GPU (GPU_IOIF) puede ser el mismo o diferente del valor utilizado por ps3fb (0x0d000000)
FIFO - el control y la localización: el control de los registros FIFO inicialmente leído como cero. Se puede escribir con la dirección de la segunda contexto FIFO. En mi prueba he utilizado el 64kB justo antes de la ps3fb FIFO (es decir, 128kb de la final de la XDR ps3fb_videomemory región). Así que poner 0x0e1e0000 en los registros (0x10000 inferior al valor leí en ps3fb contexto), pero todavía tenemos que pensar en cómo este valor es obtenido de la dirección de la ps3fb_videomemory, a fin de que podamos localizar la FIFO en cualquier lugar que queremos.

Esto significa cosas interesantes:
- No necesitamos la solución más FIFO! Pero el 'superior VRAM' uno aún es necesaria y puede ser ejecutado desde el segundo contexto.
- Debemos finalmente estar en condiciones de proporcionar una (o varias) independiente de módulos del núcleo GPU para todos nuestros trabajos (3D, Xorg, VRAM mtd). Voy a examinar esta mañana y tratar de proporcionar este módulo.
- Deberíamos ser capaces de tener 3D y Xorg acelerado de trabajo al mismo tiempo.
Ojalá estuviesen prohibidos los trans on-line... para eso mejor no poner nada.

Creo que básicamente dice que un grupo de hackers han conseguido modificar el kernel de Linux de tal forma que pueda acceder al RSX. O algo así...

¿Esto es lo mismo que lo de "A route for full access to RSX?"?
eso quiere decir que ya se pueden emular los juegos??
Que esta en pruebas aun .... diria yo , a ver si lo consigue que va de pena el linux [decaio] yo que compre la ps3 por eso mismo [sati]
Acceso al 3D o a la RSX? porque no se hasta que punto sera lo mismo, esto podria permitir ver bien los videos HD en linux con framerate decente?
Xray escribió:Acceso al 3D o a la RSX? porque no se hasta que punto sera lo mismo, esto podria permitir ver bien los videos HD en linux con framerate decente?


creo que no, eso es para poder abrir aplicaciones que piden 3D, asi alomejor se podra emular desde linux juegos de psx o ps2 (aunque lo dudo)

yo lo que espero es que peten el hipervisor
Esto es mas viejo que la tos, y ya se ha publicado en este foro.

Si, hay 2 desarrolladores que han encontrado acceso a la rsx y estan desarrollando drivers para 2D y 3D, pero aun les queda mucho seguramente meses para que tengamos algo util
basicamente es acceso a la VRAM del RSX, o sea, que han podido acceder a los 256MB de RAM del RSX y usarlos como framebuffer.

pero de usar la aceleracion 2D o 3D (blitting, manejo de vertices y texturas) nada de nada aun...

a seguir esperando, aunque es un buen avance...
en los foros de ps2dev llevan algun tiempo tratando el tema este del FIFO,,,y parece que la noticia viene de ahi


http://forums.ps2dev.org/viewtopic.php?t=8364&postdays=0&postorder=asc&start=210

de trabajos como este se va a beneficiar mucho la scene,,,,porque si lo consiguen tendriamos todo el potencial de linux con aceleracion 3d......
desde mi ignoracia me parece que los juegos no estan echos para correr en linux
ternerito escribió:desde mi ignoracia me parece que los juegos no estan echos para correr en linux


No hablamos de juegos comerciales, pero sí de homebrewn. Podrían ejecutarse todos los emuladores para Linux, reproductores, etc, más los juegos que corren en Linux (Quake 3 por ejemplo) con un rendimiento increíble.
seria mucho mas facil hacer un engine grafico/driver de X que usando un par de SPU implementara 'tile based rendering' con el objetivo que el tile a tratar no salga fuera de los 256KB del SPU (por ejemplo, tratar tiles de 256x128x32bits=128KB + otros tantos 128KB de codigo) e ir renderizando por tiles. con la potencia de los SPU, incluso se podria hacer 'sub-pixel rendering' sin perdida apreciable de velocidad
Pues si que seria interesante usar las SPU's para acelerar OpenGL y cosas asi

Pero de todos modos podría ser más interesante lo de usar la Vram es que los 256 MB son un poco justitos ...
Harl escribió:Pues si que seria interesante usar las SPU's para acelerar OpenGL y cosas asi

Pero de todos modos podría ser más interesante lo de usar la Vram es que los 256 MB son un poco justitos ...


Bueno, a lo primero, si te refieres a calculo vectorial, modelado en tiempo real, etc, los SPE son sencillos de utilizar, pero si te refieres a apoyar en tareas de renderizado, me temo que el acceso al buffer de video (que no VRAM, pues está virtualizado), es mas lento que el caballo del malo.

y lo segundo tal vez, este relacionado con lo primero... me explico:

La VRAM de PS3, segun los datos de que disponemos, es rapida de acceder en escritura, pero lentisima en lectura... por lo que no nos ayudaria a que el sistema fuera mas fluido, si no todo lo contrario.

Ahora bien, lo que no se yo es si en esa virtualizacion de la VRAM que tenemos bajo Linux, se hace una lectura antes de proceder a una escritura o que coño será, pero cuando escribimos en el frame buffer, o incluso en back buffer (yo mismo modifiqué SDL para implementar los modos de video y servicios propios de PS3), la velocidad es excesivamente lenta, pero curiosamente, no se resiente si añado una multiplicacion para posicionar el scan, en vez de una suma fija, en cada pixel, o mas curioso lo de los SPE, que LEEN un scan mediante DMA y luego lo ESCRIBEN mediante DMA y parece que la cosa tira mas o menos igual (y si usas varios, la velocidad aumenta, pues yo he usado hasta cuatro SPE renderizando cada uno parte de un scan, para dibujar triangulos)

Asi que tal vez, el problema no sea culpa de la interferencia del hypervisor y sea un problema de que la GPU, LEE esa VRAM para generar las lineas en nuestro monitor, de forma prioritaria, claro (y eso penaliza a nuestros accesos)

El tema es, que sea como sea, aproximadamente perdemos el 40% del proceso del PPE en una tarea tan simple como rellenar el frame buffer con un color. Como para usar esa memoria para "acelerar" programa :-p
pero se podrian poner juegos, aunque no esten hechos para linux, siempre i cuando el programa sea compatible con powerpc.
Segun lei por ai, (http://taringa.net/posts/downloads/976320/Juegos-de-Windows-para-Linux-(un-programa).html) ai para ser exactos, dice que el programa cenega, implementa la api de directx a linux i correr juegos de windows.

ciertamente, seria posible con la ps3, si se pudiese conseguir acceso completo al sistema 3d?
Si no voy mal cenega no esta para powerpc por lo tanto no se puede hacer nada.
no se puede instalar cedega, wine, virtual box... porque son virutualizadores, de una forma o de otra, NO SON EMULADORES, por lo que la arquitectura del procesador es diferente, no es que no halla paquetes para la arquitectura, ya que si fuera por esto, con wine por ejemplo podria valer ya que tenemos el codigo fuente y se podria compilar, pero como no es un emulador no sirve, lo unico que funciona son cosas tipo qemu, QUE NO SON TIPO VIRTUAL BOX, VMWARE..., ya que la diferencia de velocidad entre estos es porque qemu por ejemplo es un emulador y vmware es un virtualizador
18 respuestas
Archivado
Volver a Scene