Hablemos del interior de Xbox One

.

.

.

Si es que el trolling se esta profesionalizando. Ahora tienen intel, reparto de tareas... están mejor organizados que la arquitectura de la XOne

Pero aun siguen las especulaciones sobre el diseño raro de la consola?? No me lo puedo creer

eloskuro escribió:http://www.extremetech.com/gaming/164934-xbox-one-bus-bandwidths-graphics-capabilities-and-odd-soc-architecture-confirmed-by-microsoft

Here’s the important points, for comparison’s sake. The CPU cache block attaches to the GPU MMU, which drives the entire graphics core and video engine. Of particular interest for our purposes is this bit: “CPU, GPU, special processors, and I/O share memory via host-guest MMUs and synchronized page tables.” If Microsoft is using synchronized page tables, this strongly suggests that the Xbox One supports HSA/hUMA and that we were mistaken in our assertion to the contrary. Mea culpa.

You can see the Onion and Garlic buses represented in both AMD’s diagram and the Microsoft image above. The GPU has a non-cache-coherent bus connection to the DDR3 memory pool and a cache-coherent bus attached to the CPU. Bandwidth to main memory is 68GB/s using 4×64 DDR3 links or 36GB/s if passed through the cache coherent interface. Cache coherency is always slower than non-coherent access, so the discrepancy makes sense.

Extremetech se autoedito para no llevarse zascas en este sentido

Yo lo vuelvo a repetir. Me da igual lo que diga ese tal Herebus. Esta es una publicación seria con los huevos pelaos de hacer analisis tecnológicos.

En hot chips se vio que en los esquemas oficiales(fuente primaria) que, la Xbox one soporta HSA/hUMA. ¿Como lo han conseguido tecnicamente? No se, pero los esquemas están ahí. Extremetech lo dice...

this strongly suggests that the Xbox One supports HSA/hUMA and that we were mistaken in our assertion to the contrary. Mea culpa.

Y dice más....

The other major mystery of the ESRAM cache is the single arrow running from the CPU cache linkage down to the GPU-ESRAM bus. It’s the only skinny black arrow in the entire presentation and its use is still unclear. It implies that there’s a way for the CPU to snoop the contents of ESRAM, but there’s no mention of why that capability isn’t already provided for on the Onion/Garlic buses and it’s not clear why they’d represent this option with a tiny black arrow rather than a fat bandwidth pipe.

Segun los esquemas, la CPU puede espiar lo que hay en la ESRAM.

Ellos no saben muy bien como lo pueden hacer, pero los esquemas estan ahí.



Hay cosas que MS y AMD se callan.... Es lógico. AMD lucha contra Intel, y no puede mostrar todos los ases en la manga que tiene.

Los 3000 millones son ni más ni menos que para vender la tecnología de 2015 en el 2013 (o 2014 como estaba planificado originalmente). Se cogió una base ya hecha (Jaguar y Sea Island) y se cambió la arquitectura y añadió hardware para implementarlo.

Es decir, lo que los hardware llevarán ya en su propia estructura interna por así decirlo para tener todo eso (DX12, multicontexto/hilo, Full HSA) en XOne se ha hecho con hardware "periférico" (a la base antes mencionda). Todo metido en un SoC.

.

.

http://www.computer.org/csdl/mags/mi/pr ... 756701.pdf

marjalone escribió:http://www.computer.org/csdl/mags/mi/preprint/06756701.pdf

MMU hardware maps guest virtual addresses to
guest physical addresses to physical addresses
for virtualization and security. The
implementation sizes caching of fully translated page addresses and uses large pages where
appropriate to avoid significant performance
impact from the two-dimensional translation.
System software manages physical memory
allocation. System software and hardware keep
page tables synchronized so that CPU, GPU,
and other processors can share memory, pass
pointers rather than copying data, and a linear
data structure in a GPU or CPU virtual space
can have physical pages scattered in DRAM and
SRAM. The unified memory system frees
applications from the mechanics of where data
is located, but GPU-intensive applications can
specify which data should be in SRAM for best
performance.
The GPU graphics core and several specialized
processors share the GPU MMU, which
supports 16 virtual spaces. PCIe input and
output and audio processors share the IO MMU,
which supports virtual spaces for each PCI
bus/device/function. Each CPU core has its own
MMU (CPU access to SRAM maps through a
CPU MMU and the GPU MMU).
The design provides 32 GB/second peak DRAM
access with hardware-maintained CPU cache
coherency for data shared by the CPU, GPU,
and other processors. Hardware-maintained
coherency improves performance and software
reliability.

HSA/hUMA en Xbox One Fuente oficial

eloskuro escribió:

marjalone escribió:http://www.computer.org/csdl/mags/mi/preprint/06756701.pdf

MMU hardware maps guest virtual addresses to
guest physical addresses to physical addresses
for virtualization and security. The
implementation sizes caching of fully translated page addresses and uses large pages where
appropriate to avoid significant performance
impact from the two-dimensional translation.
System software manages physical memory
allocation. System software and hardware keep
page tables synchronized so that CPU, GPU,
and other processors can share memory, pass
pointers rather than copying data, and a linear
data structure in a GPU or CPU virtual space
can have physical pages scattered in DRAM and
SRAM. The unified memory system frees
applications from the mechanics of where data
is located, but GPU-intensive applications can
specify which data should be in SRAM for best
performance.
The GPU graphics core and several specialized
processors share the GPU MMU, which
supports 16 virtual spaces. PCIe input and
output and audio processors share the IO MMU,
which supports virtual spaces for each PCI
bus/device/function. Each CPU core has its own
MMU (CPU access to SRAM maps through a
CPU MMU and the GPU MMU).
The design provides 32 GB/second peak DRAM
access with hardware-maintained CPU cache
coherency for data shared by the CPU, GPU,
and other processors. Hardware-maintained
coherency improves performance and software
reliability.

HSA/hUMA en Xbox One Fuente oficial

Pero no decian que era imposible o no podia ser en one ?

Grinch escribió:

eloskuro escribió:

marjalone escribió:http://www.computer.org/csdl/mags/mi/preprint/06756701.pdf

MMU hardware maps guest virtual addresses to
guest physical addresses to physical addresses
for virtualization and security. The
implementation sizes caching of fully translated page addresses and uses large pages where
appropriate to avoid significant performance
impact from the two-dimensional translation.
System software manages physical memory
allocation. System software and hardware keep
page tables synchronized so that CPU, GPU,
and other processors can share memory, pass
pointers rather than copying data, and a linear
data structure in a GPU or CPU virtual space
can have physical pages scattered in DRAM and
SRAM. The unified memory system frees
applications from the mechanics of where data
is located, but GPU-intensive applications can
specify which data should be in SRAM for best
performance.
The GPU graphics core and several specialized
processors share the GPU MMU, which
supports 16 virtual spaces. PCIe input and
output and audio processors share the IO MMU,
which supports virtual spaces for each PCI
bus/device/function. Each CPU core has its own
MMU (CPU access to SRAM maps through a
CPU MMU and the GPU MMU).
The design provides 32 GB/second peak DRAM
access with hardware-maintained CPU cache
coherency for data shared by the CPU, GPU,
and other processors. Hardware-maintained
coherency improves performance and software
reliability.

HSA/hUMA en Xbox One Fuente oficial

Pero no decian que era imposible o no podia ser en one ?

Poca cosa pueden decir despues de esto y lo de extremetech. Lo sabian todo de la xbox one... Pero llevan 1 año sin ver la flechita negra de la CPU a la eSRAM...

@Urian se equivoca al limitar el uso del segundo graphic command únicamente al sistema operativo. Puede hacerse en un juego y una pista la podeis tener en Halo 2 Aniversary. Seguramente un motor se este ejecutando en un contexto y y el motor antiguo en otro contexto. EL resultado no es que el rendimiento sea el doble. Por ejemplo halo 2 no va a 1080p. Pero permite ejecutar un contexto u otro de forma instantánea y sin relentizaciones en el cambio de uno a otro. No he jugado al juegoy no se si se puede hacer pero me juego el cuello a que podrías renderizar el segundo motor el antiguo como un cuadrito o viewport en el remasterizado y viceversa. Eso claramente esta construido sobre el doble contexto y sobre los dos graphics commands y también por supuesto se utiliza para integrar el juego en el sistema operativo. Skype en el juego o la tv en el juego o el juego en la tv. O por ejemplo para renderizar en 3d si llegase el caso de unas posibles y futurinles gafas 3d.

Incluso se puedan renderizar fondos en una prioridad y el frente en otra.

Pero lo que no va a hacer es multiplicar por 2 o por 2,5 el rendimiento. Es la misma microsoft la que ante el doble numero de aves de la consola rival advierte que eso no hace que una gpu sea mas potente que otra. Y los Aces cumplen en gpgpu un papel similar el graphic command en pintado.

Luego tampoco es cierto que el incremento por tener esto vaya a ser del 60 o 75% y por otro lado esta técnica ya se esta usando. No se necesita dx12 ya que es parte del api nativa de xbo y doy algunos ejemplos donde seguramente se use. A parte que sistematicamente hay algunos que se olvidan de que también se dispone de dos colas de pintado de diferente prioridad en ps4 por lo que seguramente pues hacer cosas al menos similares a xbo en ese aspecto.

No han salido noticias en ningún medio porque es un documento publicado hace meses del que en pequeñas dosis Microsoft ha diseminado en sus múltiples conferencias. De hecho en algunas otras conferencias ha dado datos que aquí no figuran como los 8 Mb de esram adicionales entre las dos cpus. La verdad es que hay ciertos usuarios que intentan maximizar las diferencias hacia uno y otro lado. No hace falta decir nombres... Y luego ya ha directamente personas que tienen un serio transtorno mentiroso compulsivo. Y tampoco voy a decir nombre per obvio. La discusion de todo esto hace que una u otra maquina rindan marginalmente mas y el que piense que una va a dejar en bragas a la otra que se vayan olvidando y que recuerden de que las APUs son hardware de perfil bajo. Que incluso apus optimizadas para juegos siguen estando recortadas en cpu y gpu y lo estamos viendo constantemente con juegos con relentizaciones en los que la teselacion brilla por su ausencia en la que los 60 frames son una quimera que solo han alcanzado 4 juegos.

En cuanto al HSA. Si ya dijo la propia AMD que ambas tenían soluciones customizadas de coherencia de cache entre la gpu y la cpu. Y en el propio paper y en el hotchip aparece el dato. También advierte en el paper podeis leerlo que no tiene acceso coherente la esram porque no es una memoria cacheable pero si tiene acceso a esos datos la cpu. Lo que pasa es que como vas a mantener coherentes un bloque de memoria compartida que no tiene cache? Pues difícilmente. Teniendo otra memoria paralela en cpu y una tercera con los datos de ambas? Muy caro por esoel paper advierte que por costes la memoria esram no es coherente o tiene ciertas restricciones. No es que la cpu no pueda acceder a ella. Lo que no puede es acceder gratis sin protegerla con un mutex excluyente ya que si lo hace interrumpe a la gpu.para eso han metido los data move wngine. A parte de para facilitar el trasiego de datos para que la cpu pueda actúa como ente ciego a esa memoria si lo desea y no interrumpa a la gpu. Si la cpu puede escribir en la memoria puede leer de ella. Obvio. Eso es malo? No. Es bueno porque garantiza un ancho de banda exclusivo para la gpu que permite por ejemplo mantener un acceso coherente superior en xbo.mantener la coherencia implica reducir el ancho de banda. Ps4 debe repartir sus 175 gb/s entre la cpu ka gpu y mantener la coherencia de las caches de ambas.

Incluso jugar a Halo 2 con sus dos versiones, cada uno en uno de los dos contextos y poner snap del skype... 3 contextos xD
Nah... era broma...

Me parece muy interesante tu reflexion.

Yo creo que DX12 aportará facilidad para estas capacidades extra del doble pipe y la reducción de draw calls. Ahora mismo no creo que muchos third party puedan meterse a programar dos contextos diferentes. Seguramente con la implementación de DX12 vendrán funciones faciles y herramientas en las middlewares para estas cosas.

Eso hará que aprovechen mejor el 100% del hardware. Que eso equivale a un boost actual de un 10% o un 50% ? Eso está por ver y creo que es solo especular. Pero a fin de cuentas, es lo que nos mola en el hilo.
Por eso linkamos de vez en cuando slides que pueden no tener nada que ver con la xbox one. Porque queremos averigüar entre todos, por donde van a ir los tiros.

isma82, de donde sale que Xbox One tenga 8 mb de ESRAM adicionales? no te estaras confundiendo?

me acuesto y cuando me levanto hay como 8 pgns para leer!! (vivo en honduras asi que cuando yo estoy durmiendo para ustedes esta empezando el dia) esto esta bueno, hace unos dias atras casi casi no habia nada de que hablar, pero ahora da gusto ver comentarios (y unos mas que otros claro)

eloskuro escribió:Incluso jugar a Halo 2 con sus dos versiones, cada uno en uno de los dos contextos y poner snap del skype... 3 contextos xD
Nah... era broma...

Me parece muy interesante tu reflexion.

Yo creo que DX12 aportará facilidad para estas capacidades extra del doble pipe y la reducción de draw calls. Ahora mismo no creo que muchos third party puedan meterse a programar dos contextos diferentes. Seguramente con la implementación de DX12 vendrán funciones faciles y herramientas en las middlewares para estas cosas.

Eso hará que aprovechen mejor el 100% del hardware. Que eso equivale a un boost actual de un 10% o un 50% ? Eso está por ver y creo que es solo especular. Pero a fin de cuentas, es lo que nos mola en el hilo.
Por eso linkamos de vez en cuando slides que pueden no tener nada que ver con la xbox one. Porque queremos averigüar entre todos, por donde van a ir los tiros.

Puede haber un rendimiento incrementado de un 30 o 50 pero en parte por la mejora de la gestión multihilo del api y la optimizacion de la cpu. El dato de mejora de xbo con dx12 no es oficial y cualquiera que digamos es especulativo. En pc dicen que ronda el 50 o 60% por lógica en xbo debería ser menor porque ya implementa acceso a bajo nivel y otra serie de características. Pero es especulativo. Habrá mejoras en gpu? Puessi es full compatible debería haberlas. Debera haber técnicas de rendering nuevas y tendremos que ver si son solo estéticas o son de optimización.

@Cyborg_Ninja Hay una traspa del hotchip que pone 47 Mb de ram embebida en el chip. Las caches de cpu son 4 Mb y si no recuerdo mal la de los dos bloques de la gpu tambirn son o 2 o 4... Vamos que si sumas 32+4+4 no te dan 47 Mb. El resto que son unos 8-10 están en las litografías entre las dos cpus y la gpu y en principio Microsoft no ha dicho ni pio de para que valen. Mi teoria es que ahí se fragua la coherencia de cache de xbo. Pero es mi teoría. No puedo ratificarla con un doc.

@isma82 es lo que te iba decir, que antes digiste que necesitarían una memoria adicional de caché en la CPU para hacer full HSA, y podrían ir por ahi los tiros de ese pool de memoria de eSRAM que se ven en las imágenes del SoC, ya podéis ir sacando la escuadra y cartabón para medir de cuantos MB es, pero a ojímetro diría que es 16+16+8 ... pero bueno, me sorprende que microsoft dijese que hay 32 MB de eSRAM, podrían ser 12+12+8 ? aunque sería muy raro ya que 12 no es potencia de 2.

Pada escribió:@isma82 es lo que te iba decir, que antes digiste que necesitarían una memoria adicional de caché en la CPU para hacer full HSA, y podrían ir por ahi los tiros de ese pool de memoria de eSRAM que se ven en las imágenes del SoC, ya podéis ir sacando la escuadra y cartabón para medir de cuantos MB es, pero a ojímetro diría que es 16+16+8 ... pero bueno, me sorprende que microsoft dijese que hay 32 MB de eSRAM, podrían ser 12+12+8 ?

A mi me cuadra que sean 8. Porque ademas si es para mantener la coherencia de las caches de la cpu y la gpu cuadra bastante porque son entre las dos caches son 6-8 por lo que automáticamente se pueden copiar las caches en esa metacache y ahí es en la que la gpu y la cpu pueden acceder sin perturbar las caches de cpu y gpu no interrumpirse unas a las otras. Esto puede que no afecte por tanto al ancho de banda general del sistema. Pero que haces con la estam? Pues nada. Mantener la coherencia en la esram hubiera sido muy costoso. No puedes copiarla en otro bloque de memoria por ser demasiado grande. Meterle una cache seria un poco ridículo ya que la sram ua es cache en si misma (en cuanto a la ventaja que estas tienen sobre la gddr/ddr3 ya que comparten tecnologia) y hacerlo mediante el bus del sistema podria ser caro en ancho de banda.

Y solo nombra 32 normalmente porque esa memoria yo creo la maneja el sistema y el programador no tiene control sobre ella.

Buenas gente. Esto se os está yendo de madre, en serio. Dejar las disputas personales, las tonterías del astroturfing (q manda cojones ya...), las conspiraciones y los dos bandos estúpidos.

@Cyborg_Ninja pues chico es el mismo mensaje que puse en este mismo hilo en la página 699. Tampoco creo q tenga que dar explicaciones de donde escribo (tb lo hice en su momento en Meristation, a veces escribo en Beyond3d y me dejo caer muy poco por GAF aunq lo suelo leer bastante). Me suelen enviar mensajes para q me pase por foros y comente o me preguntan directamente por MP e intento responder a todos. Mi presencia en ese foro es bastante reducida por no decir casi testimonial ya q me siento más a gusto en EOL.

@enaguas no tengo inconveniente en escribir a partir de ahora mis mensajes como si todos los q leéis el hilo tuvierais una ingeniería. Si ves ese tono pedagógico como tu lo llamas, es pq cuando escribo un mensaje intento que lo entienda el mayor número de gente posible independientemente de sus conocimientos (por eso uso tantos ejemplos y símiles). Intento que la gente entienda lo q digo, aunq no tenga los conocimientos para ellos. Para hablar con ingenieros ya tengo Beyond3D.

Contestando a la primera parte del mensaje de @pspskulls sobre los dos contextos gráficos, y ya se q soy pesado pero es q es así , Ms ha dejado claro, para que se usa su segundo Graphics Command Processor, y no estoy hablando de ACEs ni nada por el estilo hablo concretamente del segundo y famoso contexto para el sistema. El ejemplo que pones de las sombras no es el más acertado para explicar tu postura y es curioso pq me va a servir para explicar los famosos contextos.

Siguiendo tu ejemplo, el pase de sombras es muy muy sencillo, puesto q lo único q tienes q hacer es un par de multiplicaciones de un vector por una matriz en el vertex shader y en el pixel shader nada. Estamos de acuerdo en que computacionalmente es ligero (tb depende de cuantos vértices quieras transformar, no es lo mismo hacer una sombra de una malla de 500 vertices que de 1000000 ). El problema llega cuando te topas de bruces con la funcionalidad fija del pipeline gráfico, mas concretamente con las ROPs. Las ROPs se encargan, entre otras cosas, de rasterizar, esto quiere decir coger la información q tenemos de un triángulo y pasarla a "pixeles". En este tipo de shaders que son tan ligeros, las ROPs se usan muy intensamente y se llegan a colapsar, pq no son capaces de rasterizar lo suficientemente rápido y la GPU se para.

Ahora imagínate que en vez de tener un contexto enviando a las ROPs información tienes 2 como propones tu, que va a pasar?. Que si antes se saturaban, y creeme q lo hacen con mucha facilidad recordar el paper de Emil Person, ahora q le estás enviando el doble de trabajo, no se van a saturar van a explotar . Vas a tener un cuello de botella ENORME y se te va a volver a parar la GPU.

Este tipo de trabajo es síncrono, es un pipeline a fin de cuentas, y tiene q hacerse en un orden determinado y tiene q pasar por unas etapas fijas si o si, las cuales vas a saturar quieras o no. Pq en esos huecos de computo dnd las CUs están paradas quieren meter trabajo asincrono de GPGPU?. Pq los compute shader (GPGPU) no usan la funcionalidad fija, por lo q usas la potencia de cálculo de las CUs sin tenerte q preocupar por esa funcionlidad fija, solo ocupan las CUs por lo q se pueden llevar a cabo de forma simultánea y asíncrona. Estas tareas además suelen ser independientes, puedes tener muchas planificadas en los ACEs y usar esos huecos donde el pipeline gráfico está saturado y deja a las CUs libres como el viento. Por otra parte tampoco creais q la GPU es un colador, q si existen los huecos ociosos pero su arquitectura está pesanda para el rendimiento, tampoco hay milagros.

Pero volvamos a los dos contextos, sistema y juego. Entrevista de DF, si de nuevo:

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes. The two render pipes can allow the hardware to render title content at high priority while concurrently rendering system content at low priority. The GPU hardware scheduler is designed to maximise throughput and automatically fills "holes" in the high-priority processing. This can allow the system rendering to make use of the ROPs for fill, for example, while the title is simultaneously doing synchronous compute operations on the Compute Units.

Ojito con lo que resalto en negrita pq es la clave. El sistema funciona justo al contrario de como lo entiende pspskull. Computacionalmente el shader q pueda usar la interfaz del sistema o una aplicación es sencillo no, lo siguiente. Si las sombras eran sencillas esto es como hacer la "o" con un canuto para una GPU . Que es lo q más se usa en este shader?. Pues al igual q las sombras...las ROPs...anda mira...las cosas empiezan a cuadrar. Si yo tengo dos graphics command processor uno de ellos para el sistema de baja prioridad, y otro para el juego de alta prioridad, podría mientras que las ROPs están "libres" pq estoy haciendo trabajo gráfico (o computación) para el juego, aprovechar esta funcionalidad fija para rellenar mis cuadraditos que tienen los botones, las letras...y q precisamente usan de manera mas extensiva las ROPs. Si a esto le sumas el 2 o 3% que tiene el sistema reservado para sí, podrías perfectamente transformar 100 vértices de la interface con ese tanto por ciento y usar las ROPs para dibujar pq están paradas sin ningún impacto en el rendimiento. Lo dice en la última frase, blanco y en vasija, leche fija.

Por último cuando en el mensaje se habla de Forward+, las técnicas revolucionarias, nunca antes vistas... En un forward + se usa un compute shader para determinar las luces que afectan a un cuadrado de la pantalla y se guarda en una lista de luces, una por cuadrado. Posteriormente cuando renderizas el pixel, se mira en q "cuadrado" está y tomamos esa lista para aplicarle las luces de dicha lista.

Si estás haciendo esto estás usando GPGPU por narices, por lo q lo del doble contexto gráfico ya como q se va a freír espárragos y no pinta nada aquí . Cuando vas a hacer GPGPU tienes q dividir el trabajo en hebras y esto se hace con divisiones primero en grupos y posteriormente tienes q decir cuantas hebras tiene cada grupo. Si alguien ha programado CUDA, o incluso OpenMP sabe a lo q me refiero. Las hebras que forman cada grupo tienen una particularidad, por ejemplo semáformos para sincronización, comparten memoria, tiene cerrojos, pueden comunicarse. Entre grupos esto no existe esta libertad. Si tienes 1920x1080 pixeles y usas "cuadrados" de 16x16 (q es lo más normal en GCN pq va bien) necesitas: 1920/16 = 120; 1080/16 = 68 por lo q tendrías 120x68 grupos de 16x16 hebras cada uno. Cada hebra trabaja sobre un pixel y escribe en la lista de luces de ese grupo (comparten información como he dicho antes), de ahí la división en grupos/hebras y pq se hace así. Esto ocupa todas las CUs, todas todas todas las q puedas y más , no hace un cuadradito a la vez hace todo lo q puedea a la vez.

La latencia no importa demasiado más bien nada, pq?. Pq las GPUs son arquitecturas que maximizan el throughput, esto es, el trabajo por unidad de tiempo, no la latencia. Toda su arquitectura está pensada para ello por ejemplo pudiendo entrelazar tareas cuando hay q esperar un dato, se maximiza la cantidad de trabajo del grupo, por lo q la ocultan muy muy bien y siempre están haciendo trabajo útil, a parte la adicción de cachés como GDS o LDS en las CUs han ayudado aún más si cabe. Los mismos arquitectos de XboxOne lo dicen en la entrevista si a mi no me creeis.

HSA es mucho mas que un espacio compartido de memoria, y cuatro cosas más, hay una lista muy maja de especificaciones que se tienen q cumplir tanto software como hardware para ser HSA compilant, ninguna de las dos lo son. La característica más destacada que tiene es que al compartir un espacio de memoria y ser este totalmente unificado, no hace falta hacer copias de los datos en los q va a trabajar la GPU y posteriormente volverlos a copiar en la memoria del sistema, se evitan las copias que destrozan el rendimiento. Esto tanto XboxOne como Ps4 lo tienen y es un buen paso para todos.

Por cierto ya q estoy, q me estaba bajando cosas de Nvidia...mirad lo q me he encontrado:

http://docs.nvidia.com/gameworks/index. ... apping.htm

http://docs.nvidia.com/gameworks/index. ... sample.htm

Oye, pero no eran estas dos de las características exclusivas que iba a traer DirectX12?. Como que están en OpenGL???. Brujería...

Si has llegado hasta aquí te mereces un premio.

Un saludo.

@eloskuro llevan 1 año sin "ver" muchas más cosas.

@Pada la X360 tenía 10 MB de eDRAM que no es potencia de 2. Este tipo de memorias tan especiales seguramente se fabriquen en bloques menores de 1, 2 o 4 MB.

¿De qué otro foro estabais hablando?

Del tocho que acaban de poner me he fijado en "la latencia no importa". Bueno en un sistema compartido díselo a la CPU si importa o no.
@Polyteres no te inventes las cosas, en la propia entrevista que pusiste decía claramente que no está dedicada sólo al sistema, y que podía usarse en rellenar huecos de la aplicación en alta prioridad. Parece que seguimos sin "ver" como decía @eloskuro.

No comentaré más al respecto.

Buenas tardes.

Antes de que salga de nuevo por aquí, ya que pregunta @darksch, lo de otros foros se queda en otros foros. Ni es tema del hilo ni es buena idea traer los temas a este foro para reírse.

Un saludo.

bueno estuve calculando el área de cada SRAM y un pool grande equivale a 6,25 veces el pequeño aproximadamente, asi que no puede ser 16 + 16 + 8 ni 12 + 12 + 8. Si asumimos que cada pool grande es de 16 el pequeño se quedaría en 2,56 MB

@Polyteres creo que te obcecas con lo del sistema, esa entrevista es anterior a la salida de la consola, es probable de aquellas que la reserva estuviese prefijada de esa manera, como lo del 10% que tenían reservado, pero son las típicas cosas que pueden configurar al gusto y aunque esté planeado no necesitan ir contándolo por ahí, pero bueno es mi opinion de no profesional .

Interesantísimo y claro como el agua pspskulls. Lo guardo. Ahí queda eso.

pspskulls escribió:Bueno, creo que hacen falta algunos datos más para entender lo que dije.

Empezaré comentando que Halo MCC lo único que utiliza es un context switch para cambiar del contexto gráfico que dibuja el juego remasterizado al contexto que renderiza el antiguo. El efecto es rápido puesto que es "gratis": la memoria unificada ya contiene toda lo necesario para renderizar ambos juegos, con lo que una vez hecho el switch de contexto simplemente se renderiza el frame de ese contexto, no hay más. Y mientas un contexto dibuja el otro queda dormido (la lógica de juego es la misma, sólo cambia el contexto con el que dibujamos esa lógica).

Añadir que SÓLO, y repito, SÓLO One tiene doble contexto GRÁFICO, y repito, GRÁFICO. PS4 puede tener dobles colas para renderizado y las peticiones de render irán procesándose según la GPU quede libre. Pero eso no es simultáneo, es primero una petición y luego la otra. Esto se realiza en DX12 mediante nuevos objetos llamados bundles, que se preparan por CPU de dos en dos y se mandan simultáneamente a GPU para renderizar. Aquí tenéis a la izquierda el código DX11, y a la derecha DX12:



Se puede ver cómo hasta hoy en DX11 preparas y pintas el draw 1 y después preparas y puntas el draw 2. En DX12 preparas los 2 y los 2 los renderiza al mismo tiempo.

Bien, comentáis que DX12 se centra en la mejora de rendimiento para la CPU, y en parte así es. Lo que pasa es que, ya tenemos datos oficiales de rendimiento (que sí puedo comentar ya que son públicos) sobre la prueba que hizo Microsoft con 3D Mark y otras pruebas. Lógicamente la prueba se realizó sobre un PC, pero lo que me interesa de la mismo son la serie de resultados que ofrecieron para evitar de una vez por todas el tópico de que DX12 sólo mejorará la parte de CPU y por ello está sobretodo enfocado al mercado PC. No hace falta más que acudir a esas pruebas de Microsoft y hacer mínimos cálculos con excel para darse cuenta en qué optimiza DX12.

Para empezar:


Este es un ejemplo CLARO de optimización de CPU. Es una escena en que la GPU no tiene carga ninguna. Simples cajas que tardan cero coma en pasar y renderizarse por la GPU. Es un ejemplo claro de optimización de drawcalls (llamadas a pintar) que son MUY costosas y que siempre parten de la CPU (es el paso en el que la CPU le dice a la GPU: oye, pinta esto). El tiempo en CPU vemos que pasa de 0.74ms en DX11 a 0.09ms en DX12. Aquí vemos que, no es que doble el rendimiento, es que en DX12 la CPU es 8 veces más rápida. Por supuesto esto es CPU para RENDERIZAR, aquí no entran temas de IA, físicas y otras tareas que una CPU desempeña y por supuesto afectan al rendimiento.

Ahora lo más interesante. En la escena de 3D Mark (algo que sí es más parecido a lo que viene siendo renderizar un juego), tenemos lo siguiente:



Me he permitido hacer un excel:

dx12.jpg

Por supuesto esto será una GPU de la leche y no es totalmente extrapolable a One, pero SÍ podemos observar que en esa escena cuyo cómputo de CPU puede resultar sencillo (básicamente llamadas de drawcall y por ello se gana en DX12 un 23% de rendimiento), por la parte de únicamente GPU (GFX-only) con DX12 sólo el rendering está duplicando el rendimiento con un 100% tardando justo la mitad para los procesos gráficos de la escena y ahorrándose 3.33ms. Esto demuestra que DX12 está LEJOS de SÓLO optimizar la parte de CPU de un juego, sinó que gracias a su doble contexto se beneficia totalmente la GPU. Como digo esto en One no va a ser tan brutal por la potencia de su GPU pero bien me creo algo aproximado de un 50% como ya comenté en mi mensaje anterior. Y para muestra el gráfico clarísimo:



En que podéis comprobar los rectángulos amarillos que son proceso gráfico como reflejo en gráfico de los datos. Arriba los 4 hilos de CPU en DX11, abajo los mismos 4 hilos en DX12.

Si queréis documentaros algo más, de aquí podéis ver las imagenes que he sacado:
http://www.dualshockers.com/2014/04/07/directx-12-unveiled-by-microsoft-promising-large-boost-impressive-tech-demo-shows-performance-gain/
http://www.pcworld.com/article/2110085/next-gen-directx-12-graphics-tech-revealed-hitting-microsoft-platforms-in-2015.html

A Polyteres...

1. Microsoft dice que, MIENTRAS estás en el dashboard usarían un contexto para el dashboard y el otro para el juego. Eso NO IMPLICA que ahora con DX12 puedas EN EL JUEGO usar 2 contextos simultáneos. Así que, si quieres inventarte cosas adelante.

2. Por supuesto que los ROPs son importantes, pero lo que no se puede pretender es hacer creer a la gente que One no tiene suficiente capacidad como para renderizar simultáneamente 2 contextos gráficos para un par de sombras, vas fino.

3. Las técnicas de rendering son tan nuevas o viejas como cuando se empiezan a utilizar y desde luego Forward+ lo hemos visto de momento en FH2 y para de contar. Respecto a lo de la latencia... bueno mejor no voy a comentar nada.

4. Y NO, PS4 no puede hacer NADA de lo que he comentado hasta el momento con la misma eficacia que One, simplemente porque ni tiene doble contexto gráfico simultáneos ni tiene eSRAM.

5. No voy a entrar al trapo ni tengo más tiempo para repetir muchas cosas, así que quien quiera que se guarde estos dos últimos mensajes míos porque cosas así difícilmente voy a repetir.

Esa gráfica no muestra el rendimiento de la GPU si no de la CPU. Son cuatro threads de CPU evidentemente y la parte amarilla del direct3d es el tiempo que se come la api de pintado de cpu no de GPU. El rendimiento en GPU en esa gráfica no aparece por ningún sitio.

En cuanto a lo de halo 2. Microsoft dijo que se ejecutaban los dos motores a la vez y que por eso caía el rendimiento y no llegaba a 1080p. No creo que sea un simple cambio de contexto por dos razones. Cambiar de contexto implicaría vaciar el pipeline y volverla a llenar con lo cual el cambio seria seguramente mas brusco y no justificaría la reduccion de resolución del juego. Aunque en este caso estamos haciendo suposiciones ambos dos. Pero yo le veo mucho sentido por la propia declaración de Microsoft de que decía que ejecutaba los dos simultaneament. Pero mira seria una buena pregunta para una entrevista a 343i

En cuanto a lo de que se puede usar fuera del sistema. Opino lo mismo.

Otra nueva lección de pspskulls, no me cansare de repetirlo. Por lo menos en este tema en concreto ha demostrado argumentar con más brillantez que nadie pero con diferencia. Tanto por como expone los temas a nivel técnico, como el respeto con que lo hace ante gente que entiende más o menos.
Además totalmente objetivo bajo mi punto de vista. Me has resuelto en solo dos posts un montón de dudas y contradicciones que tenía en mente.

Felicidades por la argumentación

@pspskulls

Genial, no porque digas lo que quiero oir, si no, porque lo expones todo bien y sin troleos. Como dios manda!

Algunas personas da gusto leerlas aunque no entienda la mitad de lo que dicen xD

Mi opinión personal, desde que se lanza una consola hasta que acaba su ciclo de vida comercial se optimizan sus herramientas para mejorar su rendimiento gráfico, solo hace falta ver los primeros juegos de PS360 y los últimos, me parece que se le esta dando demasiada importancia una optimizacion de software para las herramientas de XO, cuando seguro que lanzan unas cuantas cada año a los desarrolladores, XO actúa a un nivel mas bajo que DX12 en PC aunque se beneficie que ciertas mejoras yo no creo que veamos una mejora tan sustancial como algunos preveen.

La consola salio al mercado con overclock y se añadió la "potencia" extra que proporcionaba Kinect al eliminar el mismo, esto solo lo haces cuando ya sabes de antemano que no van a tener un gran amento de rendimiento por otro lugar, la consola mejorara mediante optimizacion con el tiempo, pero que nadie espere milagros, repito es opinión personal.

Yo es que leo al que escribe las biblias en verso y adecuándolas a sus preferencias y omitiendo lo que le interesa me entra la risa floja. Nunca he conseguido enlazar tantas contradicciones pero bueno halla cada uno. Ponerse a dar lecciones de una arquitectura que uno desconoce es el deporte de este Foro y el de muchos otros.Esto me recuerda a cuando salio la 360 y sus shaders unificados...que salían "expertos" hasta debajo de las piedras asegurando que todo eso era un fracaso y que no daba ninguna mejora y no había nada mejor que la arquitectura que llevaba el RSX de ps3 o hablar de una API que aun ni ha salido y catalogarla ya. Como cuando hablaban halla en el 2008 diciendo que dx11 no incorporaba novedades respecto a DX9c y que era todo una quimera. Me pregunto donde estarán ahora todos esos expertos ?! Porque siempre hay "expertos" de estos gen tras gen.
Respecto a los comentarios de pspskulls : Claros , brillantes y entendibles para todos . Así da gusto pero siempre hay alguno que pese a no querer ver las cosas se empeñe en que los demás tampoco deberían...

Me voy a comprar un sombrero. Bravo por @pspskulls. Asi da gusto leer el hilo.

Hookun escribió:Yo es que leo al que escribe las biblias en verso y adecuándolas a sus preferencias y omitiendo lo que le interesa me entra la risa floja. Nunca he conseguido enlazar tantas contradicciones pero bueno halla cada uno. Ponerse a dar lecciones de una arquitectura que uno desconoce es el deporte de este Foro y el de muchos otros.Esto me recuerda a cuando salio la 360 y sus shaders unificados...que salían "expertos" hasta debajo de las piedras asegurando que todo eso era un fracaso y que no daba ninguna mejora y no había nada mejor que la arquitectura que llevaba el RSX de ps3 o hablar de una API que aun ni ha salido y catalogarla ya. Como cuando hablaban halla en el 2008 diciendo que dx11 no incorporaba novedades respecto a DX9c y que era todo una quimera. Me pregunto donde estarán ahora todos esos expertos ?! Porque siempre hay "expertos" de estos gen tras gen.
Respecto a los comentarios de pspskulls : Claros , brillantes y entendibles para todos . Así da gusto pero siempre hay alguno que pese a no querer ver las cosas se empeñe en que los demás tampoco deberían...

Son los mismos que estan ahora nonstop metiendo mierda, solo que se cambian el nick de la verguenza que les da a ellos mismos.

No se si es cosa mia pero juraria que leo usuarios riendose de lo mismo que defendian a muerte hace unos meses

Nada mejor que acudir a la fuente para explicar los diagramas que algunos parece no terminan de pillar aunque estan muy claros....


3DMark – Multi-thread scaling + 50% better CPU utilization

If you’re a gamer, you know what 3DMark is – a great way to do game performance benchmarking on all your hardware and devices. This makes it an excellent choice for verifying the performance improvements that Direct3D 12 will bring to games. 3DMark on Direct3D 11 uses multi-threading extensively, however due to a combination of runtime and driver overhead, there is still significant idle time on each core. After porting the benchmark to use Direct3D 12, we see two major improvements – a 50% improvement in CPU utilization, and better distribution of work among threads.



Forza Motorsport 5 Tech Demo – console-level efficiency on PC

http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-12.aspx


This pair of screenshots further illustrates the model. Total CPU time is dramatically reduced in DX12 by efficiently reallocating data across all cores. Interestingly, while these two screen shots are the same frame, they aren’t using the same lighting model. No word yet on whether or not that’s caused by DX12’s alpha status, or if it’s the results of other lighting changes and program updates.


http://www.extremetech.com/gaming/178904-directx-12-detailed-backwards-compatible-with-all-recent-nvidia-gpus-will-deliver-mantle-like-capabilities

Tiempo de cpu chicos. La rodaja D3D representa el tiempo que tarda el api en ejecutarse en pc en cpu. Se reduce el coste de cpu del api... De esa grafica no se puede sacar el % de mejora de la gpu.

pspskulls escribió:Bueno, creo que hacen falta algunos datos más para entender lo que dije.

Empezaré comentando que Halo MCC lo único que utiliza es un context switch para cambiar del contexto gráfico que dibuja el juego remasterizado al contexto que renderiza el antiguo. El efecto es rápido puesto que es "gratis": la memoria unificada ya contiene toda lo necesario para renderizar ambos juegos, con lo que una vez hecho el switch de contexto simplemente se renderiza el frame de ese contexto, no hay más. Y mientas un contexto dibuja el otro queda dormido (la lógica de juego es la misma, sólo cambia el contexto con el que dibujamos esa lógica).

Añadir que SÓLO, y repito, SÓLO One tiene doble contexto GRÁFICO, y repito, GRÁFICO. PS4 puede tener dobles colas para renderizado y las peticiones de render irán procesándose según la GPU quede libre. Pero eso no es simultáneo, es primero una petición y luego la otra. Esto se realiza en DX12 mediante nuevos objetos llamados bundles, que se preparan por CPU de dos en dos y se mandan simultáneamente a GPU para renderizar. Aquí tenéis a la izquierda el código DX11, y a la derecha DX12:



Se puede ver cómo hasta hoy en DX11 preparas y pintas el draw 1 y después preparas y puntas el draw 2. En DX12 preparas los 2 y los 2 los renderiza al mismo tiempo.

Bien, comentáis que DX12 se centra en la mejora de rendimiento para la CPU, y en parte así es. Lo que pasa es que, ya tenemos datos oficiales de rendimiento (que sí puedo comentar ya que son públicos) sobre la prueba que hizo Microsoft con 3D Mark y otras pruebas. Lógicamente la prueba se realizó sobre un PC, pero lo que me interesa de la mismo son la serie de resultados que ofrecieron para evitar de una vez por todas el tópico de que DX12 sólo mejorará la parte de CPU y por ello está sobretodo enfocado al mercado PC. No hace falta más que acudir a esas pruebas de Microsoft y hacer mínimos cálculos con excel para darse cuenta en qué optimiza DX12.

Para empezar:


Este es un ejemplo CLARO de optimización de CPU. Es una escena en que la GPU no tiene carga ninguna. Simples cajas que tardan cero coma en pasar y renderizarse por la GPU. Es un ejemplo claro de optimización de drawcalls (llamadas a pintar) que son MUY costosas y que siempre parten de la CPU (es el paso en el que la CPU le dice a la GPU: oye, pinta esto). El tiempo en CPU vemos que pasa de 0.74ms en DX11 a 0.09ms en DX12. Aquí vemos que, no es que doble el rendimiento, es que en DX12 la CPU es 8 veces más rápida. Por supuesto esto es CPU para RENDERIZAR, aquí no entran temas de IA, físicas y otras tareas que una CPU desempeña y por supuesto afectan al rendimiento.

Ahora lo más interesante. En la escena de 3D Mark (algo que sí es más parecido a lo que viene siendo renderizar un juego), tenemos lo siguiente:



Me he permitido hacer un excel:

dx12.jpg

Por supuesto esto será una GPU de la leche y no es totalmente extrapolable a One, pero SÍ podemos observar que en esa escena cuyo cómputo de CPU puede resultar sencillo (básicamente llamadas de drawcall y por ello se gana en DX12 un 23% de rendimiento), por la parte de únicamente GPU (GFX-only) con DX12 sólo el rendering está duplicando el rendimiento con un 100% tardando justo la mitad para los procesos gráficos de la escena y ahorrándose 3.33ms. Esto demuestra que DX12 está LEJOS de SÓLO optimizar la parte de CPU de un juego, sinó que gracias a su doble contexto se beneficia totalmente la GPU. Como digo esto en One no va a ser tan brutal por la potencia de su GPU pero bien me creo algo aproximado de un 50% como ya comenté en mi mensaje anterior. Y para muestra el gráfico clarísimo:



En que podéis comprobar los rectángulos amarillos que son proceso gráfico como reflejo en gráfico de los datos. Arriba los 4 hilos de CPU en DX11, abajo los mismos 4 hilos en DX12.

Si queréis documentaros algo más, de aquí podéis ver las imagenes que he sacado:
http://www.dualshockers.com/2014/04/07/directx-12-unveiled-by-microsoft-promising-large-boost-impressive-tech-demo-shows-performance-gain/
http://www.pcworld.com/article/2110085/next-gen-directx-12-graphics-tech-revealed-hitting-microsoft-platforms-in-2015.html

A Polyteres...

1. Microsoft dice que, MIENTRAS estás en el dashboard usarían un contexto para el dashboard y el otro para el juego. Eso NO IMPLICA que ahora con DX12 puedas EN EL JUEGO usar 2 contextos simultáneos. Así que, si quieres inventarte cosas adelante.

2. Por supuesto que los ROPs son importantes, pero lo que no se puede pretender es hacer creer a la gente que One no tiene suficiente capacidad como para renderizar simultáneamente 2 contextos gráficos para un par de sombras, vas fino.

3. Las técnicas de rendering son tan nuevas o viejas como cuando se empiezan a utilizar y desde luego Forward+ lo hemos visto de momento en FH2 y para de contar. Respecto a lo de la latencia... bueno mejor no voy a comentar nada.

4. Y NO, PS4 no puede hacer NADA de lo que he comentado hasta el momento con la misma eficacia que One, simplemente porque ni tiene doble contexto gráfico simultáneos ni tiene eSRAM.

5. No voy a entrar al trapo ni tengo más tiempo para repetir muchas cosas, así que quien quiera que se guarde estos dos últimos mensajes míos porque cosas así difícilmente voy a repetir.

Gracias de nuevo por las explicaciones pspskull y por esforzarte en hacer que hasta los más topillos te entendamos .

Por otra parte todo esto se va a traducir en más y mejores juegos que es lo que nos interesa, que ya sabemos que el software se va mejorando durante casi toda la vida de las consolas pero esta notícia de que xbox one está preparada por Hardware para el software futuro es una estupenda noticia, aunque algunos la intenten ningunear a toda costa, al final los juegos hablarán cómo ya dijeron.

Salu2

isma82 escribió:Nada mejor que acudir a la fuente para explicar los diagramas que algunos parece no terminan de pillar aunque estan muy claros....


3DMark – Multi-thread scaling + 50% better CPU utilization

If you’re a gamer, you know what 3DMark is – a great way to do game performance benchmarking on all your hardware and devices. This makes it an excellent choice for verifying the performance improvements that Direct3D 12 will bring to games. 3DMark on Direct3D 11 uses multi-threading extensively, however due to a combination of runtime and driver overhead, there is still significant idle time on each core. After porting the benchmark to use Direct3D 12, we see two major improvements – a 50% improvement in CPU utilization, and better distribution of work among threads.



Forza Motorsport 5 Tech Demo – console-level efficiency on PC

http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-12.aspx


This pair of screenshots further illustrates the model. Total CPU time is dramatically reduced in DX12 by efficiently reallocating data across all cores. Interestingly, while these two screen shots are the same frame, they aren’t using the same lighting model. No word yet on whether or not that’s caused by DX12’s alpha status, or if it’s the results of other lighting changes and program updates.


http://www.extremetech.com/gaming/178904-directx-12-detailed-backwards-compatible-with-all-recent-nvidia-gpus-will-deliver-mantle-like-capabilities

Tiempo de cpu chicos. La rodaja D3D representa el tiempo que tarda el api en ejecutarse en pc en cpu. Se reduce el coste de cpu del api... De esa grafica no se puede sacar el % de mejora de la gpu.

Sí, aquí Isma tiene razón. He malinterpretado el gráfico del 3d mark, fácil porque como parecían mostrar la creación de un frame desde su lógica hasta su present. Pero solo hablan de optimización de cpu. Edito el post para no llevar a confusión. Por lo demás lo mantengo.

Sorry chicos por el lapsus no volverá a ocurrir (voz de rey).

en graficos tambien , me acuerdo del paso directx9 al 11 y decian que no supondria casi nada y al final siempre la optimacion siempre mejora los graficos , si en pc se supone un 70% en la one esta por ver pero por ahi andara , no olvidemos que xone es full hardware dx12 y las pruebas no se an hecho en full hardware dx12 , ademas del cuello de botella que tienen los pequeños jaguars , cargandolo todo a un nucleo con el dx11

http://www.redgamingtech.com/dx12-70-pe ... -xbox-one/

http://blogs.msdn.com/b/directx/archive ... vings.aspx

Si cuando implementen dx12 la nasa utilizara la xbox. Venga ya hombre!!!

optimus1_prime escribió:Si cuando implementen dx12 la nasa utilizara la xbox. Venga ya hombre!!!

mira lo que hace dx12 con un i5 gpu HD4400 de 19 pasa a 33 fps a la prueba me remito

optimus1_prime escribió:Si cuando implementen dx12 la nasa utilizara la xbox. Venga ya hombre!!!

http://tech.firstpost.com/news-analysis ... 91721.html

http://www.techradar.com/news/gaming/co ... ce-1159025

Eso ya está. La próxima vez que entres diciendo cosas así sin aportar nada ya sabes, mira algo por lo menos

optimus1_prime escribió:Si cuando implementen dx12 la nasa utilizara la xbox. Venga ya hombre!!!

Gran aporte, perfectamente explicado y solucionando todas las dudas que tenemos
Muchas gracias

optimus1_prime escribió:Si cuando implementen dx12 la nasa utilizara la xbox. Venga ya hombre!!!

No entreis al trapo. Que el hilo ya estaba reconducido

Raistlin2891 escribió:

optimus1_prime escribió:Si cuando implementen dx12 la nasa utilizara la xbox. Venga ya hombre!!!

http://tech.firstpost.com/news-analysis ... 91721.html

http://www.techradar.com/news/gaming/co ... ce-1159025

Eso ya está. La próxima vez que entres diciendo cosas así sin aportar nada ya sabes, mira algo por lo menos

Ostras tiene que estar buscandose los dientes por el suelo. menudo zas

Buenos días.

El hilo iba muy bien, a ver si entre todos somos capaces de que continúe así en vez de citar una y otra vez un comentario. Si dejáis que moderación actúe, ese comentario no pasa de ahí, si le dais coba, hacéis que se desvíe el hilo por completo y se pierdan los aportes que se estaban comentando.

Un saludo.

ahona escribió:Buenos días.

El hilo iba muy bien, a ver si entre todos somos capaces de que continúe así en vez de citar una y otra vez un comentario. Si dejáis que moderación actúe, ese comentario no pasa de ahí, si le dais coba, hacéis que se desvíe el hilo por completo y se pierdan los aportes que se estaban comentando.

Un saludo.

Lo siento no volverá a ocurrir, es que no lo vi ayer y me pareció una obra maestro. Sorry.

De nuevo para quitarse el sombrero @pspskulls . Gracias por tus aportes.

Trabajo demasiado

http://www.elotrolado.net/viewtopic.php?f=200&t=1992540&p=1737660873&hilit=fill#p1737660873

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes. The two render pipes can allow the hardware to render title content at high priority while concurrently rendering system content at low priority. The GPU hardware scheduler is designed to maximise throughput and automatically fills "holes" in the high-priority processing. This can allow the system rendering to make use of the ROPs for fill, for example, while the title is simultaneously doing synchronous compute operations on the Compute Units.

Y luego nos dices:

podría mientras que las ROPs están "libres" pq estoy haciendo trabajo gráfico (o computación) para el juego, aprovechar esta funcionalidad fija para rellenar mis cuadraditos que tienen los botones, las letras

Ahí está, para dibujar los cuadraditos del HUD, anda que es lo mismo que lo que ha dicho el arquitecto.

Te lo pongo desde otra perspectiva: lo que en otras plataformas es necesario reservar 4 CU para usarlas asíncronamente, en XOne no haría falta pues ya se pillarían las que quedaran libres no necesarias en el ROP.

Ya estamos poniendo unidades ociosas a trabajar, y esto es sólo el principio.

Tampoco obsesionarse con los ROP que lleva los que necesita:

GCN 1.0 combines every 64 shader processor with 4 TMUs and 1 ROP to a compute unit (CU)

Es decir que poner más ROP para los 768 shader cores que tiene sería improductivo puesto que no habría suficientes shader cores con que alimentarlos. En lugar de eso mejor optar por usar las unidades libres en las otras cosas que pueden hacer sin necesidad de las ROP.

Además, una ROP de GCN no es lo mismo:
http://computadoras.about.com/od/conoce-Tarjeta-Grafica/a/Rop-Tarjeta-Grafica.htm

AMD en su arquitectura Graphic Core Next utiliza los términos ROP Z/stencil y Color ROP

Esto ya lo digo suponiendo, no sé si alguien podría responder mejor. Con esto de las ROP separadas, en un motor por tiles, ¿no se podría hacer la z-pass del próximo tile mientras se hace la de color del anterior al mismo tiempo?, de forma asignándole a un mismo CU usando sus 64 shader repartidos entre la z-pass de un tile y la color-pass de otro, cada uno usando la parte del ROP que necesite. Es decir, si hay veces que realmente estás limitado por la color-ROP (como las sombras, o zonas de shader simples), y hay shader cores sin hacer nada, igual se les puede ocupar con una z-pass.

Porque cuando se habla de ROP creo que sólo se habla de color ROP:
http://www.amd.com/en-gb/products/graphics/desktop/7000/7700#

◾32 z/stencil ROP units
◾8 color ROP units

Por lo que si son unidades separadas, deberían poder funcionar de forma independiente.

Creo recordar, hablando del diseño, la mención de que la z-pass sería casi gratis. Con una mezcla de la eSRAM y su dualidad lectura/escritura, y quizás se debería añadir la capacidad de poder hacer 2 cosas a la vez.

Para los que dicen q Xbox One es una 7770.

Assuming that this information is accurate, the major difference between Durango and a standard GCN is in the cache structure. Modern Radeons have a 16K L1 cache that’s four-way set associative and a shared L2 cache that’s 16-way associative. Durango reportedly has a 64-way associative L1 cache (still at 16K) and an 8-way associative L2.

Here’s why that’s significant. A CPU/GPU cache has two goals: First, it needs to provide the data the CPU is looking for as quickly as possible. Second, it needs to be accurate. Increasing the set associativity of a cache increases the chance that the processor will find the data it is looking for — but it also increases search time.



The other major difference between GCN and Durango is the amount of L2 cache per SC/CU. The Radeon 7970 has 32 Compute Units and 768K of L2 cache total split into six 128K blocks. Durango has 12 Compute Units and 512K of L2 cache, broken into four 128K blocks. Proportionally, there’s a great deal more L2 cache serving each CU with Durango.

http://www.extremetech.com/gaming/14757 ... gen-radeon

Fuente: vgleaks

Vaya, parece que Xbox One tiene unas caches "diferentes" en su GPU.

http://gamingbolt.com/directx-12-and-mantle-have-draw-call-performance-of-7-5-times-of-directx-11

AMD recently held a presentation in Singapore talking about the future of GPU technologies. The event was titled Future of Compute and it was attended by the industry’s top developers. During the event, Futuremark’s Oliver Baltuch took center stage to gauge the differences between DirectX 12, DirectX 11 and Mantle.
Futuremark’s provides PC and mobile benchmark tools which includes 3DMark. Using 3D Mark, Oliver showcased the difference between DirectX 12 and Mantle. Surprisingly the performance of draw calls on both the API is similar but when one compares it to DX 11, it’s almost 7.5 times greater.
Draw Call is one of the performance parameter which is an indication of how many objects can be drawn on the screen and it seems like DX12 and Mantle have the same capacity. Now we are not sure whether this will hold true in case of practical implementation as AMD’s Mantle is still being adopted by developers and DX 12 is still a year away.

Other advantages of DX12 include 50% reduction in CPU cycles and bottlenecks in a dual GPU configuration. It should possibly benefit the Xbox One as well since it uses an API which is similar to DirectX.



-----
Más del amigo oliver


“We were very happy when Microsoft chose 3DMark to show some of the benefits of DirectX 12,” explains Oliver. “In their demo, they showed two major improvements over DirectX 11 – a 50% improvement in CPU utilization, and better distribution of work among threads.”

“With DirectX 12 game developers will be able to create richer scenes with more objects. DirectX 12 also introduces a set of new rendering features that will improve the efficiency of algorithms used in rendering and collision detection.” However he thinks it’s too early to deliver a final verdict about its benefits since it is still more than year away from launch. “It’s too early to know the exact performance gains, but when DirectX 12 is ready we’ll be there with a 3DMark benchmark that shows the new possibilities,” he added.

Given that Futuremark are deep into bench-marking, we asked Oliver’s thoughts about Microsoft’s claim of making the Xbox One more powerful using the cloud. Oliver’s response was positive.

“It does look promising, doesn’t it? I imagine the challenge will be to use it in such a way that gameplay isn’t compromised if the console is offline, or has a poor connection. It will be interesting to see how developers make use of it,” he said.