Articulo sobre la GPU de x360

the_master escribió:Eso es lo que dice MS

the_master escribió:Eso es lo que dice MS

el CELL se pasrá la mitad del tiempo parado con el 95% de los juegos

lherre escribió:

Al menos así no se necesitará mucho sistema de refrigeración

deathkiller escribió:Lo que dicen las trasparencias es que mentiste varias veces en tus comentarios sobre el cell shadow land.

Conviertes tus opiniones en hechos irrefutables sin importarte las especificaciones oficiales.

Seguro que si los juegos de multiplataforma se ven mejor en la PS3 diras que Sony pago a las thirds para que fuera asi.

oslando escribió:ozú ke tia maj fea por cierto, es una demo sobre la 9700, no creo ke ahi se muestre nada de shaders unificados.

GXY escribió:
esa demo es de las X800 actuales, nada de shaders unificados.

y sera to lo fea que tu quieras, pero ya te gustaria que la srta. dark del PD0 de X360 tuviera ese nivel de detalle ingame

deathkiller escribió:Realmente en situaciones controladas (por ejemplo fisicas, efectos graficos y cosas similares) el rendimiento alcanzable en el Cell es mayor que el que puedes alcanzar en un core generico como los de la Xbox 360 y estoy seguro que se alcanzara pues IBM ha creado un monton de herramientas para ello.

La situación de las CPU es exactamente la contraria que las GPUs, Microsoft lo unico que ha hecho es cojer la arquitectura power y meterle unos cuantos recortes y añadidos mientras que Sony con una gran colaboración de IBM ha creado desde casi 0 durante 4 años una nueva arquitectura siempre teniendo en cuenta que se pueda aprovechar casi al 100% en un videojuego, esta opinion la comparten los desarrolladores (Major Nelson de Microsoft solo desarrolla el Live no videojuegos).

Phellan_Wolf escribió:La demostración que se hizo del Raytracing en tiempo real, fue con 2 procesadores Cell a 4Ghz y con sus 8 SPE'S, asi que olvidaos de ver Raytracing en tiempo real en PS3, que según se comenta es posible que reduzcan a 6 SPE'S. También por lo visto el Cell que incluye la PS3 no reconoce más de 256 MB de X D R, por lo que el único posible aumento que podría tener en cuanto a memoria sería respecto a la memoria de vídeo. Pero eso de que no reconozca más es una cagada, probablemente de la bios que monte.

The first demo we saw was a ray-traced landscape demo, which was also shown at Sony's PlayStation 3 press conference yesterday. Height field data acquired by LIDAR (light RADAR basically) was combined with a color overlay taken via satellite imagery to create a realistic 3D rendering of the Mount St. Helens volcanic area.

deathkiller escribió:
http://gear.ign.com/articles/615/615521p1.html

A esto me referia yo no a esa tonteria de video de spiderman y gran turismo que vamos menudo al que se le ocurrio esa idea.

deathkiller escribió: La memoria inteligente de la Xbox 360 no hace HDR ni ningun efecto de ese tipo, solo se dedica a postprocesar que yo sepa siempre se comenta AA y Z-buffer pero nada de efectos de iluminación y tal.

deathkiller escribió: Lo de la ropa ya se que no es una gran innovación pero ya me diras cuantos de juegos de PC lo hacen. Estoy poniendo un ejemplo de la Xbox 360 no conviertas todo en una bara de medir solo quiero hablar de las cosas nuevas que nos depara esta nueva generación, por ejemplo de que sirve que el Cell pueda "mover mas ropa" si solo quieres tener a un personaje con ropa.

deathkiller escribió: ¿Tengo que molestarme cada vez que comento algo que se pueda hacer en detallar la eficiencia con la que lo haria la Xbox 360 y la PS3 cuando no tenemos ni de lejos datos suficientes para estimarlo?

deathkiller escribió: Por si no lo habeis visto el unico video (una demo tecnica) de algo funcionando en la Xbox 360 (solo algo de reducción en la frecuencia de relog pero por lo demas el hardware definitibo):http://www.xboxyde.com/news_1610_en.html

La demo era originalmente de la r520 por lo que no esta muy optimizada para la r500 (Xenos).

shadow land escribió:Yo solo se, que si alguien piensa que esta generación no le va a sorprender, o es que es un flipao de la vida, o es que no tiene ni la más remota idea de lo que se le viene encima (y no me refiero especiamente a capacidades gráficas)

Ferdopa escribió:Hay juegos como Half Life 2 que van perfectamente en cualquier equipo, y la optimización de código en esta generación será tan importante (o más) que el rendimiento de las consolas (sobre el papel totalmente sobrado).

la memoria inteligente del Xenos no hace el HDR lo hacen los shaders unificados creo yo ¿no?

CapiXbox escribió:¿Perdón alguien puede explicar lo que es el HDR y poner un link o pegar todo lo que puede hacer esa mini GPU hija con la memoria?

deathkiller escribió:shadow land la memoria inteligente del Xenos no hace el HDR lo hacen los shaders unificados creo yo ¿no?

deathkiller escribió:Y los de la ropa si estamos diciendo lo mismo no se por que te empeñas en que parezca que no es asi. Los PCs lo pueden hacer desde hace tiempo pero ningun juego lo hace por que no funcionaria en la mayoria de los PCs, por eso es un avance un sistema donde no solo se pueda hacer si no que se haga.

deathkiller escribió:Esto es un ejemplo de cosas que pueden hacer las targetas de nvidia de pc actuales pero que no se ve en juegos por lo de la optimización:

satellite escribió:hoy en ArsTecnica han colgado un artículo sobre la CPU de X360, y es muy muy interesante..

os dejo aquí el enlace, espero que os sea interesante.

un saludo

arstechnica. La famosa Sintesis, pero en x360 escribió:In a nutshell, procedural synthesis is about making optimal use of system bandwidth and main memory by dynamically generating lower-level geometry data from statically stored higher-level scene data.

Limitations

There are two problems with this idea, the first being that it's more expensive than it sounds. The costs of creating art assets for a 3D game are going through the roof along with the size and complexity of the games themselves. The "hire more artists" approach just doesn't scale well when you consider that the games of the future will have large, richly detailed, extremely realistic environments that consume tens gigabytes of storage space. A common number that I've seen tossed around as a budget for the next generation of games is US$20 million, which puts game development in the same league as the movies in terms of production costs.

The Xbox 360's solution to this problem is to store high-level descriptions of objects in main memory, and have the GPU procedurally generate the geometry (i.e., the vertex data) of the objects on the fly. So in the case of our forest, main memory stores information about the tree, like the type, size, location of each leaf, etc., along with other relevant data like the direction of the prevailing wind. This information is passed into the Xbox 360's Xenon CPU, where the vertex data that defines the polygons out of which the tree is made are generated by one or more running threads. These threads then feed that vertex data directly into the GPU (by way of a special set of write buffers in the L2 cache, but more on that later). The GPU then takes that vertex information and renders the trees normally, just as if it had gotten that information from main memory.



he end result of all this is that the amount of data that is stored in main memory and moved into the CPU is much less than the amount of data that the CPU puts out and that the GPU ends up processing. Microsoft refers to this ratio of stored scene data to rendered vertex data as a compression ratio, the idea being that main memory stores a "compressed" version of the scene, while the GPU renders a "decompressed" version of the scene.

The technique of compressing scene data for storage in main memory and then decompressing it by means of procedural synthesis allows game developers to do more with a console's limited system memory. The console provides plenty of CPU-to-GPU bandwidth and enough computing power to procedurally render objects in real time

Microsoft's Xbox 360 can use the Xenon CPU to tessellate curves in real-time. The higher order curves can be stored in compact form in main memory, and then transferred to the Xenon where they're tessellated into vertex data. As with the procedural geometry generation described above, this dynamically generated vertex data is then passed directly to the GPU for rendering.

Real-time tessellation has a few advantages. First, storing models as collections of higher order curves is a more compact than storing them as vertex lists. This is especially true for high-polygon-count models, where the higher number of polygons approximates the original curves better but also makes for more vertex data. So real-time tessellation is another form of data compression that lets developers use a limited amount of source data, main memory, and bus bandwidth to render a highly detailed, data-intensive scene.

The second upside to dynamic tessellation is that a model that is tessellated in real-time can be rendered using a variable number of polygons, depending on the demands of the particular scene that's rendering at the moment. This allows the software to control the level of detail (LOD) of each model dynamically.

Real-time skinning

This patent (patent number 20050099417) that Microsoft was recently granted covers a method for using procedural synthesis to do real-time skinning of 3D characters. The basic idea behind the patent appears to be as follows. Artists using standard tools (i.e.., motion capture, 3D rendering tools, etc.) generate a character model along with a series of key poses in an animation for that model. This model consists of a set of bones that have been skinned with a deformable skin.

The Xenon uses the key poses that are stored in system memory and interpolates new poses as needed based on the stored poses. These new poses have skin that deforms in natural ways, and are essentially new 3D models that are generated on the fly by the procedural synthesis code. This is yet another example of the use of procedural synthesis to cut down on the amount of data stored in memory. Instead of storing a sequence of models for a character animation, the Xenon is able to generate the animation sequence dynamically from a few exemplary forms.

Interestingly enough, the patent also appears to cover a feature that allows the procedural synthesis logic to send only the vertices that have changed between two poses along to the GPU, so that the entire model doesn't have to be retransmitted across the bus. This will help cut down on bus traffic in instances where the characters' movements in between frames are slight. (NOTA: Mientras Sony decia bobaliconadas con PS2 y su sintesis, llega MS y las mata callando... je, irónico sobre todo ahora queesta CELL... se nota quien es gente que piensa en el programador, y quien tiene a 4 ingenieros "locos")

arstechnica. Sintesis y mundos dinámicos. Como escribió:
The Xbox 360's Xenon CPU consists of three identical PowerPC cores connected to a shared 1MB L2 cache. The overall layout of Xenon is depicted in the diagram below:



Each of the cores, which I'm going to call a PowerPC Processing Element (PPE) from here on out, has a 64K split L1 cache (32K instructions/32K data) and can handle up two simultaneous threads of execution using simultaneous multithreading (SMT).
According to Microsoft's patents, Microsoft envisions a procedurally rendered game as having at least two primary components.

* Host thread: A game's host thread will contain the main thread of execution for the game. This thread will handle the high-level parts of the 3D engine, and will control the data generation thread.
* Data generation thread: The actual procedural synthesis of object geometry takes place in this thread. This thread outputs vertex lists that represent objects in the game and are intended to be consumed by the GPU.

These two threads could run on the same PPE, or they could (more likely) run on two separate PPEs

I said above that data generation threads produce vertex lists that are intended for the GPU, but I didn't tell you that these lists don't exactly go directly to the GPU. There are two options for the vertex data output of these threads, one of which is that they can be moved into main memory for later use by the GPU. This would happen in situations where the GPU doesn't need the data immediately and would like to stream it from memory at a later time. The other, more commonly taken option for the data generation thread's output is that it is sent to the GPU by way of the L2 cache.

arstechnica. Cuando la cache L2, NO es una cache escribió:
Xenon's L1 and L2 caches can function in the conventional manner described above, but they can also function quite differently. More specifically, Xenon invests programmers with an unprecedented level of control over how their applications use the caches. Insofar as they can fall under the explicit control of the programmer, the Xenon's caches, and its L2 cache in particular, can function remarkably like the "local storage" that's attached to each of the Synergistic Processing Elements (SPEs) in IBM's Cell processor.

In the Xbox 360's procedural synthesis scheme, the GPU is still a consumer, but the role of the producer that feeds it is played by the Xenon CPU. The Xenon can produce "decompressed" vertex data in greater volumes and at a much higher rate than traditional main memory could, which is the whole point of procedural synthesis. Often, however, the Xenon will produce vertex data faster than the GPU can consume it.

When Xenon overproduces vertex data, that data has to be stored somewhere while it waits for consumption by the GPU. Fortunately, the Xenon's PPEs have a very fast data store that is both near at hand and sits directly between the PPEs and the GPU. This data store is the Xenon's shared L2 cache.

A programmer can place a thread in write streaming mode, which means that the system will wire down (to use traditional virtual memory terminology) or lock (to use Microsoft's terminology) a set of cache lines and attach that set directly and exclusively to a particular thread. This set is then initialized as a FIFO queue, so that it can act as a write buffer to store the output of a data generation thread. The data generation thread feeds its vertex data output directly into this FIFO queue (bypassing the L1 cache entirely), and the GPU reads that vertex data directly from this queue using a modified DMA protocol.



In the Xenon's L2 cache, an arbitrary number of the sets can be locked and turned into FIFO queues for private, exclusive use by individual data generation threads. The sets that aren't locked look to the Xenon like normal L2 cache. This means that non-write-streaming threads can use the non-locked L2 cache space normally