salamanca escribió:
La putada de tu argumento es que reconoces que al final de cuentas las latencias de las memorias son diferentes y por eso se jode la posibilidad de usarla como un bloque unico y total y por eso se ve limitada la opcion de video a solo 256 dificultando tareas de video superiores a 256
¿Sabes lo que significa transferencias de memoria principal a vídeo?
Me parece que no, y se puede hacer perfectamente, de hecho se hace desde hace mucho tiempo, y BIEN hecho apenas hay merma de rendimiento.
Lo que no se puede creer perfectamente es que la lógica de juego, el sonido y la geometría de una escena de nueva generación ocupen 32 megas y que el resto es para texturas, pero si tú te quieres convencer allá tú.
Tambien reconoces que por muy rapida que sea una memoria de nada sirve en cuestiones graficas la velocidad sino el ancho de banda porque al caso una tarea de 128 o 256 bits (todas, pues ya no quedan casi tareas graficas de 64 bits) en una memoria de 64 bits por muy rapida que sea debera ser partida en 2 partes de trabajo o 4 partes de trabajo dando lugar a hacer lo que una memoria mas lenta pero de mas ancho de banda hace en una sola instruccion.
El caso, querido amigo, es que la velocidad de la memoria influye directamente en el ancho de banda, algo que no pareces conocer.
Incluso te diré que a veces un ancho de palabra MUY grande puede llegar a ser contraproducente, ya que si tienes x cantidad de información a transferir, y no ocupa exactamente el ancho Y de palabra, desperdicias datos que no se envían, así como procesamiento al hacer una máscara con los bits necesarios del envío. No todo el monte es orégano, aunque está claro que al tener un ancho de banda de menores palabras hay que hacer más transferencias de memoria. Sin embargo, como te pongo, al ser la memoria MUCHO MÁS RÁPIDA, el ancho de banda máximo teórico pasa a ser mayor. Ya ves tú que cosas.
No estoy diciendo que sea lo mejor, pero no es tan malo -ni muchísimo menos- como tú lo quieres hacer pintar, eso seguro.
A eso le sumo que hay tareas que al dividirse pierden rendimiento (Framebuffer, Alpha Blending, MSAA, HDR, etc) y lo veo muy poco util eso de tener mas velocidad.
No se muy bien a qué te refieres, sobre todo porque estás mezclando términos como memoria de video, partes del renderizado del pipeline, y técnicas de renderizado, respectivamente. Si pudieras ser un poco más concreto te lo agradecería.
Por ejemplo, si te dieran a elegir un CPU Intel Celeron de 2.0 Ghz o un AMD AthlonXp de 1700 Ghz:
Cual es mas rapido en numeros?
Cual rinde mas en la realidad por su forma de trabajo?
Supongo que ese ejemplo tan sencillo lo darás para la gente que no entiende de arquitectura de computadores, porque te aseguro que yo tengo las cosas muy claras, así que por mucho que cortes, pegues y resumas información de mil webs (algunas de dudosa procedencia) no vas a convencerme de que la 360 es tecnología extraterrestre, y la PS3 un spectrum a pedales.
Un saludo.
PD: Supongo que los puntos que comentas son los únicos en los que has encontrado algo para refrutar, así que los comentarios de los 16Kb de escritura, el HDR+AA, DirectX10 + SM4, y demás pijadas no confirmadas los podremos tomar directamente como falsos, ¿no?
Edito, ah, no, veo que has completado, pues sigamos:
salamanca escribió:Para que el CPU calcule parte de las tareas graficas. Si tenemos en cuenta que Sony se la pasa presumiendo de que Cell hara mucho en colaboracion con el RSX tiene sentido al menos en la logica de Sony que parte de las tareas graficas se calculen por CPU
Pues entonces si todo se resuelve por shaders entonces el sentido del CELL colaborando con RSX en graficos se convierte en un bulo de Sony porque no tiene aplicaciòn practica en la realidad. Al caso todo es shaders por tu respuesta. Entonces para que Sony se la pasa repitiendo de la importancia de CELL en la colaboracion con RSX a los efectos graficos?
No digo que no tengas razon, la tienes, pero entonces la teoria de Sony dandole importancia a CELL para tareas graficas pierde total sentido salvo para tareas no muy pesadas
Lo único que puede hacer la CPU para ayudar a la gráfica de forma que no haga un cuello de botella son transformaciones geométricas y físicas en animación, cosa que OOOOPSS, ya se puede hacer con el Cell, y de manera más eficiente que el Xenon, porque de hecho la única manera de hacerlo es con CPU. De hecho, si has leído algo de directx10 sabrás que meterán una unidad de geometría en el pipeline, de forma que la gráfica pueda crear y destruir vértices, algo que ahora mismo ningunta gráfica (ni la de 360) puede hacer. Se ha de hacer con CPU. A eso súmale cálculos físicos y verás que el Cell puede ayudar bastante más de lo que la gente dice.
El Xenon tienen ciertas características de DirextX10, si, pero tiene MUCHAS más que la eliminan del juego empezando por el SM4 y, como ya he comentado, la unidad de geometría.