(MSAD) Metodo Sony para el Adoctrinamiento de Dependientes

the_gooseman escribió:
ya hay tiendas exclusivas para vender playstations...

Playstation center

Pues a esos son a los que se debería meter por vena la actitud "lavacerebros" y dejar al resto del mundo en paz con sus propias decisiónes.

P.D: No lo sabía que las había, pero gracias por decirlo para evitarlas.... Que no quiero acabar lobotomizado

shadow land escribió:
Que tal si lo dejas en 6 SPUs? Los juegos SOLO PUEDEN USAR 6 SPU's de la misma forma que el SO se reserva una SPU igual q las 96MB de las 256 que posee "de sistema".

Amen que Xenos no es como la ppu de CELL ni remotamente, bueno, si, que ambas se basan en g5, solo que el de cell es un g5 "a pelo" y el de xenos esta totalmente modificado

Los cores de la Xbox 360 son versiones modificadas segun peticiones de microsoft del PPU del Cell.

Esta es una foto borrosa pero se puede ver las similitudes:


Los G5 son bastante distintos que los PPU que usa el Cell a partir de su segunda revision (la primera revision del Cell no se uso fuera de los laboratorios):


Yo solo pretendo explicar los numeros no justificarlos. El Cell de la PS3 tiene 7 SPU aunque los juegos solo usen 6 para fines propios (el septimo se utiliza durante los juegos aunque sirva para lo que le apetezca a Sony en vez de lo que le apetezca al creador del juego).

La diferencia en rendimiento real entre las dos CPUs no te la va a dar el numero de veces que se puede hacer una operacion concreta y menos en este caso.

PD: Un core de la Xbox 360 es el doble de grande que un SPU si cuentas la cache, la diferencia real en tamaño es solo de un 50% mas grande el Cell que la CPU de la XBox 360 por lo que a priori podrias decir que es un 50% más potente si cuentas las operaciones a nivel de transistor en vez de flops (si cuentas el asunto del SPU desactivado + reservado te quedas con practicamente lo mismo).

A lo que voy, es a que no se pueden comparar directamente el IPC de CELL con el de Xenos. Y tampoco se puede calcular la potencia total de cpu de ps3 (pensando en juegos) con la de xenos, por que en ps3 solo hay disponibles 6 spus, y en xenos estan los 3 cores completos (no se por donde leí que lo "reservado" que no era tal realmente, rondaba el 2% del tiempo de cpu para un solo hilo).

Cell no es un 66% más potente que xenos ni de coña vamos. Si no por Beyond3d y otros laos ya lo hubiesen dejado sentado muchas veces, y lo unico que dejan sentado es que es más potente, no mucho más potente.

Bueno como ya he puesto en el PD de mi anterior post si lo que cuentas es tamaño de CPU usada mientras juegas (esto es posible comparlo por que estan fabricadas ambas a 90nm) Xenon y Cell de PS3 son iguales. Esta forma de calcular la "potencia" normalmente es mas realista que los flops cuando haces comparaciones globales.

titorino escribió:
Pues claro que las recuerdo la demo del tekken me compre el tekken tag de salida viendo el video de la demo y que quieres que te diga , cutre el juego la verdad.

el tekken tag por supuesto, ¿pero el 4 y el 5...? por ign tienen los vídeos de esas demos, y la verdad, hay alguna que da bastante pena y todo, pero vamos, que no es el tema del hilo tampoco.

shadowland te refieres a Xenos(GPU) o Xenon(CPU)?

radeonxt escribió:shadowland te refieres a Xenos(GPU) o Xenon(CPU)?

xenon, que siempre me lio

Ghostito escribió:
el tekken tag por supuesto, ¿pero el 4 y el 5...? por ign tienen los vídeos de esas demos, y la verdad, hay alguna que da bastante pena y todo, pero vamos, que no es el tema del hilo tampoco.

El tema del hilo es que SONY infla los datos y altera la verdad vendiendonos una ''supermáquina'' por un pastón y luego es mas o menos la mitad de lo que nos vende ,puse ese juego como ejemplo

Me parece increible, en serio xDD.

Sony está llegando a unos extremos que nunca hubiera imaginado. A lo mejor es que dudan demasiado de su producto..

roig escribió:Me parece increible, en serio xDD.

Sony está llegando a unos extremos que nunca hubiera imaginado. A lo mejor es que dudan demasiado de su producto..

llegando? dudas que no lo hayan hecho desde la psx?

Que buenoXD Sumale ese estilo de cosas a las pajas mentales que ya de por si se forman algunos dependientes cuando no tienen ni puta idea y no saben que responder... et voila, cocktail explosivo.

pues "aguita" con lo que ha dicho nvidia:

"congratulations to NVIDIA for making the PS3 obsolete before it ever shipped"-PC FTW

http://www.anandtech.com/video/showdoc.aspx?i=2870&p=29

Back when Sony announced the specifications of the PlayStation 3, everyone asked if it meant the end of PC gaming. After all Cell looked very strong and NVIDIA's RSX GPU had tremendous power. We asked NVIDIA how long it would take until we saw a GPU faster than the RSX. Their answer: by the time the PS3 ships. So congratulations to NVIDIA for making the PS3 obsolete before it ever shipped, as G80 is truly a beast.

esperabais otra cosa? PS3 no es el caso de xbox, nVidia ha sido un parche en el fracaso de la gpu basada en cell, NV2A fue la "apuesta" xD

Esperate a que lance ATi su tarjeta DirectX 10, no se cual será la más potente de las dos, pero quien se compre una, tiene gráfica para 3 o 4 años sin menearse.

por cierto, 88Gigas/seg q tiene la jodida G80 de ancho de banda a memoria

Cuando dices de las dos te refieres a la de xbox 360.

no, me refiero a la nueva gráfica DirectX 10 de pc de ATi (debería llamarla AMD...).

en consola esta claro que es mejor gráfica la de 360 que la de ps3.

shadow land escribió:en consola esta claro que es mejor gráfica la de 360 que la de ps3.

Lastima que comparta la memoria con la CPU.

corpa escribió:
Lastima que comparta la memoria con la CPU.

lastima? es una de las ventajas, no estar limitado a una cantidad X, si no redistribuirla como te convenga.

eso pienso yo, pero en este hilo estan diciendo lo contrario...

the_gooseman escribió:eso pienso yo, pero en este hilo estan diciendo lo contrario...

En ese hilo no se dice lo contrario.
En ese hilo se dice que porque la memoria unificada funcione muy bien eso no implica ninguna de estas dos cosas:
A)Que la UMA sea el segundo advenimiento de jesús.
B)Que la "memoria independiente" ahora de repente sea una mierda pinchada en un palo.

segun tengo entendio, entre memoria unificada y memoria independiente (para consolas, entiendo yo), es mas conveniente la unificada que la memoria independiente, porque puedes distribuirla cuando quieras y no tienes que usar cosas como el turbocahe que usara el RSX (que al final vienen siendo parches).

no he entendido que la memoria independiente no funcione, porque se lleva usando desde siempre, pero tambien he leido un post de otro forero (no eras tu) que decia que en los accesos a memoria se "molestaban" xenos y xenon por lo tener memoria unificada y que la eDram era un parche para evitarlo....

el único problema de la unificada, efectivamente, es la posibilidad de que se "peguen" ambos chips por ella, pero teniendo en cuenta, que solo un maximo de 10GB/s de los 20 y pico que hay disponibles, son para la CPU, no es tal problema.

La ventaja (y mucha) es la de poder administrar la memoria como te salga de allí sin limitación, y sabiendo en todo momento como va a trabajar esta.

Que necesitas un juego con una carga brutal gráfica, pero muy poca de niveles (malla 3D, IA y demás), pues das 300 y 200 megas, o 400 y 100 megas, que necesitas pocos gráficos pero mucho dato, pues a la inversa.

En ps3 eso se ve penalizado, además, con el trabajo extra para los programadores de tener que controlar en todo momento si tienen repleta la memoria gráfica, para hacer el "swap" entre ella y la ram de sistema, y devolver de nuevo los datos cuando se necesiten en la gráfica. Esto se puede convertir en una auténtica pesadilla, y de ahí, que por ejemplo, en DirectX 10, no exista diferenciación entre memorias, solo un "bloque" de memoria que será el propio sistema quien controlará, y no el programador.

ok, lo he entendido perfectamente. gracias por la explicacion

trankis,ke ahora sale corpa y lo rebate...

El acceso unificado se consigue a costa de hacer más lento el acceso de la CPU a la memoria (este es un mayor problema que el ancho de banda compartido en la Xbox 360), te ahorras tener dos controladores de memoria pero tampoco es que sea la panacea.

Se supone que el poner el framebuffer aparte en la eDram hace mucho más facil a los desarrolladores planificar el uso del ancho de banda de la memoria.

the_gooseman escribió:segun tengo entendio, entre memoria unificada y memoria independiente (para consolas, entiendo yo), es mas conveniente la unificada que la memoria independiente, porque puedes distribuirla cuando quieras y no tienes que usar cosas como el turbocahe que usara el RSX (que al final vienen siendo parches).

No es Turbocaché lo que usa RSX, que manía. Y mira que lo dije veces en dicho hilo.

Y el RSX PUEDE ACCEDER DIRECTAMENTE A MEMORIA DE SISTEMA, no tiene que hacer swap ni pijadas ni replicar datos.

La memoria unificada tiene sus cosas buenas y malas, como todo. Que las buenas superan a las malas y encima éstas se pueden paliar? Pues de puta madre y tira millas, pero repito, eso no lo convierte en el descubrimiento del siglo y el motivo de la rotación del mundo, que era lo que decía cierto forero en el hilo.

no he entendido que la memoria independiente no funcione, porque se lleva usando desde siempre, pero tambien he leido un post de otro forero (no eras tu) que decia que en los accesos a memoria se "molestaban" xenos y xenon por lo tener memoria unificada y que la eDram era un parche para evitarlo....

Y efectivamente si pueden tener "peleas" por el acceso a memoria, y la eDRAM era más bien un paliativo. Al añadirle la lógica que interactua con la eDRAM pues se conviertió en una fantástica idea. Pero ya lo ha explicado deathkiller, y se habló en el otro hilo.

zheo escribió:Y el RSX PUEDE ACCEDER DIRECTAMENTE A MEMORIA DE SISTEMA, no tiene que hacer swap ni pijadas ni replicar datos.

La memoria unificada tiene sus cosas buenas y malas, como todo. Que las buenas superan a las malas y encima éstas se pueden paliar? Pues de puta madre y tira millas, pero repito, eso no lo convierte en el descubrimiento del siglo y el motivo de la rotación del mundo, que era lo que decía cierto forero en el hilo.


Y efectivamente si pueden tener "peleas" por el acceso a memoria, y la eDRAM era más bien un paliativo. Al añadirle la lógica que interactua con la eDRAM pues se conviertió en una fantástica idea. Pero ya lo ha explicado deathkiller, y se habló en el otro hilo.

a) El programador ha de controlar esos accesos, ya que se sale del pool principal del subsistema gráfico. Tiene que controlarlos, adminsitrarlos, y solventarlos. En un sistema unificado no tienes ese problema, y por tanto, te evitas UNOS DOLORES DE CABEZA KILOMETRICOS. Al fin y al cabo, es un Swap de memoria. Tenga que hacerse o no, si un dato no esta, hay que leeerlo, y hay que controlar donde esta.

b) de acuerdo.

c) la función real de la eDram no es "liberar" el ancho de banda, es facilitar funciones como el FSAA y bla bla bla. Supongo que lo empezaremos a ver en proximos juegos ya que parece que han mejorado enormemente las herramientas para el uso de tiling y dicha edram.

shadow land escribió:
a) El programador ha de controlar esos accesos, ya que se sale del pool principal del subsistema gráfico. Tiene que controlarlos, adminsitrarlos, y solventarlos. En un sistema unificado no tienes ese problema, y por tanto, te evitas UNOS DOLORES DE CABEZA KILOMETRICOS. Al fin y al cabo, es un Swap de memoria. Tenga que hacerse o no, si un dato no esta, hay que leeerlo, y hay que controlar donde esta.

¿Kilométricos? Oye yo no se tú, pero con los puntero no tengo tanto quebradero de cabeza, y repito que se supone que desde la GPU puedes acceder al espacio de memoria principal. Vamos a suponer que esa petición la gestiona el hardware y que el programador no tiene que calcular la direción de memoria que está buscando en principal. Digo yo.

c) la función real de la eDram no es "liberar" el ancho de banda, es facilitar funciones como el FSAA y bla bla bla. Supongo que lo empezaremos a ver en proximos juegos ya que parece que han mejorado enormemente las herramientas para el uso de tiling y dicha edram.

Y además palía el problema de la memoria unificada. Así que ¿fue primero el huevo o la gallina?

a lo primero, por desgracía el FlexI/O solo es un bus/northbridge como otro cualquier, son dos pools diferentes, y auqnue este simplifiacdo, no es tan simple como mandar un puntero, por que en un momento dado, quizas tengas que jugar con datos entre los dos pools, y moverlos entre ellos.

b) La función de la edram es cache basicamente y framebuffer, es una solución para no tener que usar memorias de 256bits por causa de tareas pesaddas en el ancho de banda, pero de poco proceso logico real.

shadow land escribió:a lo primero, por desgracía el FlexI/O solo es un bus/northbridge como otro cualquier, son dos pools diferentes, y auqnue este simplifiacdo, no es tan simple como mandar un puntero, por que en un momento dado, quizas tengas que jugar con datos entre los dos pools, y moverlos entre ellos.

Me refiería a hacer una petición de memoria desde la GPU y que el FlexI/O lo gestione, leyendo directamente de principal (a menos velocidad, claro)
Mover datos entre ellos es otro tema aparte.

b) La función de la edram es cache basicamente y framebuffer, es una solución para no tener que usar memorias de 256bits por causa de tareas pesaddas en el ancho de banda, pero de poco proceso logico real.

Pues eso era lo que decía, usar la eDRAM de "caché" también evita "pegas" con el acceso a memoria. Y al meterle la lógica a todo el tingaldo=

a) Para eso tienes que saber de ante mano la posición exacta de dicho dato

b) Sip, pero primero tienes que haber leido el dato jejeje. Si, es la utilidad, pero relativa... a ver si empiezan a usarla de verdad, que tengo ganas de ver hasta donde llegarán usando la edram correctamente

shadow land escribió:a) Para eso tienes que saber de ante mano la posición exacta de dicho dato

Bueno eso pasa con todas las texturas, la informacion de donde tienen que leerse las texturas esta en con los vertices. Como la latencia puede causar problemas con los shader se podrian poner las texturas que usen shader que lo toleren bien (usando pocos registros por ejemplo). Realmente no creo que a efectos de codigo se note el use de diferentes Pools, las librerias deberian abstraerte de cualquier diferencia mientras programas (sigues sabiendo donde esta un textura por que tu la pones en un determinado sitio).

Sobre la eDram una ventaja que no se suele mecionar es que si usas AntiAliasing no te aumenta el tamaño del framebuffer ya que se resuelve antes de tocar la ram principal cosa que no pasa en PS3/PC.

estabamos hablado del RSX trabajando en la X D R.

shadow land escribió:estabamos hablado del RSX trabajando en la X D R.

Por eso, me refiero a que usar el X DR no cambia como procesa las cosas el RSX.

PD: Un ejemplo de uso es las nubes del Warhawk, el Cell las crea en la X DR con su framebuffer/z-buffer y el RSX las sobreescribe en el framebuffer principal.

Pero la posición exacta de dicho dato lo necesitas saber para referenciar cualquier dato . Lo que pasa que eso se abstrae
Juer que tener diferentes pools de memoria no es nada del otro mundo, los mismos SPUs tienen un espacio local, pero pueden referenciar memoria principal directamente, incluso mapear memoria principal en local...

zheo escribió:Pero la posición exacta de dicho dato lo necesitas saber para referenciar cualquier dato . Lo que pasa que eso se abstrae
Juer que tener diferentes pools de memoria no es nada del otro mundo, los mismos SPUs tienen un espacio local, pero pueden referenciar memoria principal directamente, incluso mapear memoria principal en local...

lo segundo lo se, pero tb se que implica una latencia un tanto... bruta.

El RSX claro que puede acceder, igual que una gráfica de pc puede acceder a la memoria de sistema o HD mediante el AGP... pero hay que controlarlo. Pero claro, yo hipotetizo en el grado de que haya más datos gráficos de los que caben en la memoria de RSX, y la de sistema ande justa teniendo que swapear o mover datos. Si estan fijos, nos tocamos la nariz ocn un puto puntero como si un niño hiciese la O con un canuto

shadow land escribió:
lo segundo lo se, pero tb se que implica una latencia un tanto... bruta.

El RSX claro que puede acceder, igual que una gráfica de pc puede acceder a la memoria de sistema o HD mediante el AGP... pero hay que controlarlo. Pero claro, yo hipotetizo en el grado de que haya más datos gráficos de los que caben en la memoria de RSX, y la de sistema ande justa teniendo que swapear o mover datos. Si estan fijos, nos tocamos la nariz ocn un puto puntero como si un niño hiciese la O con un canuto

Estarán fijos, esto no es un ordenador. Y si no lo están supongamos que el sistema se encarga de recuperarlos. Como tú dices es lo mismo que en PC, y en éste todo eso se abstrae.

eso no quita que sea un puto coñazo, y más todavía en un sistema cerrado sin metodos de paginación en las APIs (o eso me parecio leer por B3d)