Hablemos del interior de Xbox One

A mi me llama esto la atención. Especialmente el último párrafo:

DirectX 12: Every core can talk to the GPU at the same time and, depending on the driver, I could theoretically start taking control and talking to all those cores.

That’s basically the difference. Oversimplified to be sure but it’s why everyone is so excited about this.

The GPU wars will really take off as each vendor will now be able to come up with some amazing tools to offload work onto GPUs.

La guerra de GPUs realmente despegara cuando las diferentes marcas sean capaces de desarrollar herramientas increíbles para descargar trabajo en la GPU.

Microsoft a puesto mucho empeño en esto. Si vamos a la hotchips, vemos esto:

1) special audio, graphics, and video processors offload CPU and GPU cores

2) • CPU,GPU, specialized processors,and IO share memory via host-guest MMUs with synchronized page tables again

3) • High bandwidth CPU cache coherency

4) • 200+ GB/second power efficient memory system balanced to CPU,GPU, specialized processors, andIO requirements


5) • DX11.1+ graphics core with custom graphics and compute command processors to offload CPU and improve GPGPU

Procesadores espéciales y Customs compute Commands processors para descargar la CPU y mejorar el GPGPU.

papatuelo escribió:Cuantifica la mejora de rendimiento en general en (N-1)X100%, siendo N el número de nucleos. En ONE sería un 700% teórico según esa ecuación. ¿Con esto podríamos ver ray tracing? Recuerdo a quien le interese que Spencer ya dijo estar jugando con Ray Tracing.

Bueno ONE tiene disponibles 6.5/6.8 nucleos o asi, no? Con lo que estaria diciendo un 550/580%, de partido de CPU, suponiendo ONE actual DX11, que seguramente ya este usando cositas.
Ademas tambien añadie que a efectos reales este calculo no tiene sentido porque no se cuadraria una utilizacion real del 100% de todo. Pero bueno, el caso es que queda mas o menos confirmado un enorme incremento en ese punto a medio largo plazo.

Zokormazo escribió:Ojo a los quotes:

Third, if you’re a XBox One fan, don’t assume this will give the XBO superiority. By the time games come out that use this, you can be assured that Sony will have an answer.

No esperemos una reduccion del gap, ya que el resto no estan mirando las musañaras

Realmente dice que es mejor no asumir que esto vaya a dar superioridad a ONE, y en base a una respuesta que piensa que habra, pero que aun tiene que haber.
Lo que es la reduccion del gap ya es real y tiene pinta de aumentar. Aunque los juegos diran como siempre.

@neclart: ese ultimo quote es mio no de @papatuelo xD

Y viendo lo que dicen los de portal, normal que baje el gap, han bajado mucho el overhead que suponen los drawcalls

Donde si se va a abrir una buena brecha sera entre consola y pc,sobre todo en equipos con cpus de gama media que estarian limitando a la grafica

Zokormazo escribió:@neclart: ese ultimo quote es mio no de @papatuelo xD

Y viendo lo que dicen los de portal, normal que baje el gap, han bajado mucho el overhead que suponen los drawcalls

Eso sólo si se estaba CPU bound el juego en concreto. Sin embargo lo que es puramente GPU es por la mejora del driver a nivel de GPU en sí. Que Destiny se pudiera poner a 1080p es por velocidad de dibujado no por CPU.

Es como cuando te mejoran el driver en PC, el overhead no se puede bajar porque eso es cosa del SO a nivel de driver en user-mode, y rinde mejor, por el mejor uso de los propios componentes al cual va dirigido el driver en cuestión.

darksch escribió:

Zokormazo escribió:@neclart: ese ultimo quote es mio no de @papatuelo xD

Y viendo lo que dicen los de portal, normal que baje el gap, han bajado mucho el overhead que suponen los drawcalls

Eso sólo si se estaba CPU bound el juego en concreto. Sin embargo lo que es puramente GPU es por la mejora del driver a nivel de GPU en sí. Que Destiny se pudiera poner a 1080p es por velocidad de dibujado no por CPU.

Es como cuando te mejoran el driver en PC, el overhead no se puede bajar porque eso es cosa del SO a nivel de driver en user-mode, y rinde mejor, por el mejor uso de los propios componentes al cual va dirigido el driver en cuestión.

En lo que dice el de portal se benefician todos, ya sea cpu-bound o no.

El tio esta diciendo que desde que salio la consola a hoy en dia en cada iteracion del SDK estan añadiendo drawcalls con cada vez menos overhead en cpu. De eso se benefician todos, tanto un juego muy intensivo en cpu como uno que no lo sea tanto, dado que los juegos gpu-bound se convierten en cpu-bound debido a los drawcalls con tanto peso en el lado cpu. Si aligeras ese peso, no saturas tan rapido la cpu con drawcalls.

Zokormazo escribió:

darksch escribió:

Zokormazo escribió:@neclart: ese ultimo quote es mio no de @papatuelo xD

Y viendo lo que dicen los de portal, normal que baje el gap, han bajado mucho el overhead que suponen los drawcalls

Eso sólo si se estaba CPU bound el juego en concreto. Sin embargo lo que es puramente GPU es por la mejora del driver a nivel de GPU en sí. Que Destiny se pudiera poner a 1080p es por velocidad de dibujado no por CPU.

Es como cuando te mejoran el driver en PC, el overhead no se puede bajar porque eso es cosa del SO a nivel de driver en user-mode, y rinde mejor, por el mejor uso de los propios componentes al cual va dirigido el driver en cuestión.

En lo que dice el de portal se benefician todos, ya sea cpu-bound o no.

El tio esta diciendo que desde que salio la consola a hoy en dia en cada iteracion del SDK estan añadiendo drawcalls con cada vez menos overhead en cpu. De eso se benefician todos, tanto un juego muy intensivo en cpu como uno que no lo sea tanto, dado que los juegos gpu-bound se convierten en cpu-bound debido a los drawcalls con tanto peso en el lado cpu. Si aligeras ese peso, no saturas tan rapido la cpu con drawcalls.

Los de portal???

No lo pillo, no se a que te refieres.

Por cierto de lo que os decia de que se produjo una sustitucion del API y no una simple mejora.

two separate graphics drivers for the Xbox One's onboard Radeon hardware: we know about the mono-driver - Microsoft's GPU interface designed to offer the best performance from the hardware, but there was also the user-mode driver (UMD)

(UMD) A well-placed source informs us that while it was an Xbox One-specific driver, it had a lot of additional checking and error-catching, designed to help debugging and to get software up and running on the console as soon as possible - at the expense of raw performance.

Yes, remarkably Microsoft had two GPU drivers in circulation, all the way up to May 2014 when the user-mode driver was finally consigned to the dustbin.

The focus on the mono-driver appears to pay off as throughout 2014, Microsoft posts GPU performance improvements nearly every month, including some remarkable increases in draw call efficiency in July.

papatuelo escribió:Los de portal???

No lo pillo, no se a que te refieres.

El de la entrevista de metro que anduvimos hablando antes perdon, tanta multitarea me lio xD

Esto concretamente:

Oles Shishkovstov: Let's put it that way - we have seen scenarios where a single CPU core was fully loaded just by issuing draw-calls on Xbox One (and that's surely on the 'mono' driver with several fast-path calls utilised). Then, the same scenario on PS4, it was actually difficult to find those draw-calls in the profile graphs, because they are using almost no time and are barely visible as a result.

In general - I don't really get why they choose DX11 as a starting point for the console. It's a console! Why care about some legacy stuff at all? On PS4, most GPU commands are just a few DWORDs written into the command buffer, let's say just a few CPU clock cycles. On Xbox One it easily could be one million times slower because of all the bookkeeping the API does.

But Microsoft is not sleeping, really. Each K that has been released both before and after the Xbox One launch has brought faster and faster draw-calls to the table. They added tons of features just to work around limitations of the DX11 API model. They even made a DX12/GNM style do-it-yourself API available - although we didn't ship with it on Redux due to time constraints.

Lo que esta hablando aqui, la mejora en el sdk con drawcalls cada vez mas rapidos y con menos overhead, benefician tanto a los juegos gpu-bound como a los cpu-bound.

A los cpu-bound obviamente porque la carga que le suponen en cpu las tareas gpu es menor, y por lo tanto hay mas cpu para tareas cpu.

A los gpu-bound porque llegaran mas tarde a saturar la cpu y por lo tanto en convertirse cpu-bound por los drawcalls de gpu y por lo tanto podran meter mas tralla a la gpu.

Claro, el UMD se mejoró desde que salio hasta que fue sustituido por el mono driver. Pero el UMD aun en su últimos momento no iba bien con los draw. De ahí que Metro que saco el juego en agosto se quejara, xq con el que había lidiado era con el primero y no con el segundo.

Una vez que el Mono estuvo disponible para todos el tema de los draw mejoró cada más hasta que en julio secibió una mejora sustancial.

Esos son los famosos maletines de microsoft.

Ahora que ya más o menos podemos mejorar los 1080p, libera CPU para iluminación y objetos en pantalla y te puedes hacer una idea de qu el impacto puede llegar a ser muy importante

Phil Spencer
@XboxP3
@7kayhan @albertpenello We've done experiments with Realtime Raytracing. A ton of potential with this tech, amazing visuals.
9:06 - 1 de mar. de 2014

Ya, pero que el CPU bound podría afectar en el framerate, o ser culpable de tener que bajar resolución (reduzcamos a esto el dibujado para entendernos) por tener que delegar en la GPU tareas de CPU (caso AC Unity) que no se debieran, es decir más allá de lo que debiera delegarse.

Pero poder subir un juego a 1080p es puramente por velocidad de dibujado, no por CPU bound ni sus derivados, y eso es aumento en el rendimiento del propio driver de cara únicamente a la GPU.

Es decir, que se han mejorado ambas cosas, reducción de overhead y además "velocidad de dibujado" u optimización de la propia GPU.

Faltan por liberar aún la multi-comunicación CPU-GPU core (sin el límite 1:1) y el multi-contexto o dualidad de la GPU, para poder simultaneizar render con GPGPU y poder así delegar aún más cosas a la GPU, gran ventaja respecto ahora que requiere una reserva previa de CUs para GPGPU, además de no garantizar la ejecución paralela que ahora mismo más bien es asíncrona cuando el único contexto se lo permite.

sin saber y entender mucho de tecnisismos yo lo veo asi:
luego de pasar al Modo Driver han mejorado muchas cosas pero la pregunta siempre es ¿cuantos juegos han salido ya aprobechando este driver? yo creo que muy pocos, porque apenas se ha liberado y pues hay que ir trabajando el el, asi que asumo que en este 2015 se veran ya las mejoras en el mundo real (digo en los juegos que salgan a la calle), lo mismo sucedera con DX12, tendra que pasar un tiempo para que los desarrolladores se acostumbren (aun mas tiempo ya que incorpora nuevas cosas), asi que los resultados definitivamente no se veran de un dia para otro, los primeros juegos seran los exclusivos y yo espero de aqui a 2 años ver una realidad de DX12 en los demas juegos asi que a seguir esperando y a seguir aguantando burla hasta que esto se haga realida.

con respecto a DX12: http://hardzone.es/2014/08/17/intel-mue ... s-hd-4400/
si esto es viejo, si esto es de PC, sin embargo no deja de sorprenderme que en un mismo Hardware pase de 19FPS a 33FPS osea pasa a de practicamente injugable a casi perfectamente jugable (en caso de los juegos) se obtuvo un 73% de rendimiento aprox en esa prueba, sera por eso que algunos dicen que es casi el doble de rendimiento, que en la ONE no se vera tan "extremo" claro que no, pero que habra mejora eso seguro

"El hardware de la actual generación de consolas es capaz de reproducir los CGI de las precuelas de Star Wars en tiempo real y con mejor calidad (más fuentes de luz)

https://twitter.com/draginol/status/555786666762584065

Evidentemente habla de hacerlo con las nuevas APIs, DX 12 en nuestro caso. Pero eso es lo que vamos a poder ver cuando DX 12 este fuera.

papatuelo escribió:

"El hardware de la actual generación de consolas es capaz de reproducir los CGI de las precuelas de Star Wars en tiempo real y con mejor calidad (más fuentes de luz)

https://twitter.com/draginol/status/555786666762584065

Evidentemente habla de hacerlo con las nuevas APIs, DX 12 en nuestro caso. Pero eso es lo que vamos a poder ver cuando DX 12 este fuera.

The current gen console hardware is capable of doing the Star Wars prequel CGI in real time with better quality (more light sources).

=/=

The current gen consoles hardware is capable of doing the Star Wars prequel CGI in real time with better quality (more light sources).

Console en este caso es adjetivo, no sustantivo. Es obvio que se refiere a One, pero no por el twit. Por cierto, ¿cual es la cgi que dice?

Esta bien traducido y habla en general, se refiere a todo el hardware de la actual gen. Ve a su tweeter y lo mismo te llevas un susto .

El CGI es todo lo que haya en CGI en la peli y creo que en especial

https://www.youtube.com/watch?v=5qZJ85MdS-g

Es que realmente en esa frase tampoco hay nada demasiado especial, vamos yo no habria necesitado que el me lo dijera, tengo claro que esos niveles de detalle con mejor iluminacion se ven a lo largo de esta generacion. Otra cosa es los engañados que se piensan que esto es hardware estandar de hace años.

Es mas, ni siquiera esta aclarando que se refiera a gameplay, que es en lo que yo pienso, habla de reproducir en tiempo real, o no aclara mas. Lo cual pues directamente ya se ha visto en demos, la famosa del mago y otras.

papatuelo escribió:Esta bien traducido y habla en general, se refiere a todo el hardware de la actual gen. Ve a su tweeter y lo mismo te llevas un susto .

El CGI es todo lo que haya en CGI en la peli y creo que en especial

https://www.youtube.com/watch?v=5qZJ85MdS-g

¿Que susto me voy a llevar? Como si me interesara la competencia mínimamente...

De todas maneras mírate esa cuenta de Twitter y comprueba que se da por hecho que la competencia tendrá respuesta a DX12 y se enseñará en la GDC.

Lógicamente One sigue teniendo como ventaja su arquitectura, pero de la misma manera que se ha cerrado el gap ahora, se puede volver a cerrar.

No obstante estoy bastante seguro de que con la 'nueva forma de equilibrar el hardware' que impone la nueva forma de hacer las cosas tener un procesador mas lento en multihilo te quitará rendimiento en la GPU. Y este es el kit: puedes responder, pero no has pensado en ello con antelación y te puede pasar factura.

Solo dice "hacer en tiempo real" pero hacer sonaba muy feo en español.

Por otro lado, no es facil alcanzar el nivel de los CGI de la pelicula de star wars. Si lees el articulo de DX 12 dice que cuando ves la peli parece real pero sabes que no lo es, el cerebro te dice que no lo es. Según Wardell eso es debido a la iluminación. Eso es lo que dice que va a mejorar.

En su anterior artículo dijo reproducir en tiempo real la batalla en el abismo de Helm.

@stylish a mi la competencia también me da igual, era solo un chascarrillo. De hecho no son mi competencia, serán la de Microsoft en todo caso. Si tenemos dos consolas entregando gráficos a nivel de CGI, mejor para todos, no estaría mal jugar on God of War 4 a nivel de cinemática.

Yo solo estoy en este hilo, lo he dicho chorrocientasmil veces, xq todos estos avances hacen que me pique la curiosidad cosa mala. Por más que haya biliosos que se piensen que por ser curioso eres un fanboy,

Me baso en la entrevista a los creadores de Metro, cuando dijeron eso de "en la otra son unos cuantos DWORD".

Lo que yo creo es que la otra está ya bastante cerca de su límite en cuanto a tema de overhead y comunicación CPU-GPU. Por lo tanto la mejora la veo más factible a nivel de driver, que se optimice, aunque me parece que tampoco está muy lejos de lo que puede hacer. A partir de ahí, pericia y trucos de los desarrolladores. Recordemos que no es OpenGL puro, si no GNM/X que incluye extensiones que pueden estar usando ya todo lo que tenga sin necesidad de esperar al nuevo OpenGL. Es decir que yo creo que el sistema de la otra está ya bastante pulido a este respecto desde que salió, y el margen de mejora es más limitado.

Y como 2ª cuestión, al no llevar dualidad en el propio hardware, no podrá, simplemente por limitaciones de éste, utilizar la técnica del parelelismo render/GPGPU reaprovechando unidades, tendrá que seguir usando el clásico sistema de reservar CUs para cada cosa.

A mi me cansa un poco que cada vez que hablamos d euna novedad se diga `ppor aqui "la otra tambien podrá hacerlo". Estamos en el foro de XBO. No hace falta comprarlo con PS4. Estamos hablando de mejoras de software de xbo actuales y futuras, para la arquitectura de XBO, que muchos creemos que es novedosa y que tiene mucho futuro y recorrido por delante. Lo que hagan los otros nos da igual. Que se busquen sus habichuelas con su 40% de more powa

Stylish escribió:De todas maneras mírate esa cuenta de Twitter y comprueba que se da por hecho que la competencia tendrá respuesta a DX12 y se enseñará en la GDC.

Pero se refiere a PC, no a consolas, no ? Yo supuse que hablaba de OpenGL ... y también dijeron algo de que nosecuantas empresas de la industria estaban colaborando en algo que nos sorprendería en la GDC.

En consola el bacalao bueno va a estar en los APIs de bajo nivel, lo que suelen llamar Metal, que yo aun no estoy seguro de si en esos APIs también estaba la limitación de que solo un hilo podría hablar de forma simultanea con la GPU ...

cercata escribió:

Stylish escribió:De todas maneras mírate esa cuenta de Twitter y comprueba que se da por hecho que la competencia tendrá respuesta a DX12 y se enseñará en la GDC.

Pero se refiere a PC, no a consolas, no ? Yo supuse que hablaba de OpenGL ... y también dijeron algo de que nosecuantas empresas de la industria estaban colaborando en algo que nos sorprendería en la GDC.

En consola el bacalao bueno va a estar en los APIs de bajo nivel, lo que suelen llamar Metal, que yo aun no estoy seguro de si en esos APIs también estaba la limitación de que solo un hilo podría hablar de forma simultanea con la GPU ...

en el articulo que linkaron un poco antes (del mismo tio) da a entender que tanto en pc como en otras plataformas. Se puede deducir que conoce la existencia de al menos otra api mas aparte de dx12/mantle con esa implementacion, y que en el GDC sabremos mas sobre todo eso.

@cercata, ¿has leido el artículo que hemos puesto?

La ganancia no es por ser más o menos close to metal, evidentemente close to metal rinde más cualquier sistema.

Pero lo que supone DX 12 es unas X veces de ganancia sobre cualquier API anterior, close to metal o no close to metal, por el hecho de hacer uso de el multihilo de una forma eficiente.

Este tipo de API multihilo van a aparecer para todas las plataformas, con beneficios para todas.

Luego por otro lado cada una de estas API estarán más o menos depuradas e incluso incluiran recursos que serán más eficientes con hardware dedicado como ya dijeron en la presentación de las Nvidia Maxwell.

Asi que wardell practicamente esta hablando del efecto del multihilo, exclusivamente, a eso hay que restar la pericia del desarrollador y sumar cualquier otro beneficio que se consiga por otro lado, ya sea software o hardware.

Sobre lo del CGI, tampoco es que sea el mejor CGI de la historia del cine, pero no estaria nada mal si fuera verdad.

Pero bueno, yo sigo esperando los juegos en calidad avatar que ya hace tiempo que dijeron que veriamos y creo que puedo esperar sentado mucho tiempo.

Las luces veo posible que sean mejores que las de ese CGI. La composicion completa, distancias de dibujados, numero de elementos en pantalla, lo siento pero no me lo creo, pese a ir a una resolucion mucho mas baja.

Se usan farms con cientos de procs cañeros dandolo todo durante cientos de horas para renderizar estas cosas.

Zokormazo escribió:en el articulo que linkaron un poco antes (del mismo tio) da a entender que tanto en pc como en otras plataformas.

Si, pero plataformas de arquitectura heterogénea, no ? Tablets, consolas Android, etc ...

En arquitecturas homogéneas, como puede ser la ONE o cualquier consola clásica, yo es que no le veo sentido.

Yo lo que aun no sé es cual va a ser el API Metal de la ONE de cara al futuro, si algo inspirado de DX12, o no.
Y digo inspirado, pq aunque el API sea el mismo, la implementación interna va a ser (o debería ser) muy diferente, mucho mas eficiente que en un PC o demas plataformas heterogeneas, y ademas podrían meterle funciones extras que no serían posibles en PC o demás arquitecturas heterogéneas.

@papatuelo, si, lo he leido, el de DX12 oversimplified, no ?
Lo que no se es si el API Metal viejo de la ONE tenia esa limitación también, o solo pasaba en el API DX11.

cercata escribió:Si, pero plataformas de arquitectura heterogénea, no ? Tablets, consolas Android, etc ...

En arquitecturas homogéneas, como puede ser la ONE o cualquier consola clásica, yo es que no le veo sentido.

En cualquier plataforma donde tengas mas de un core de cpu (vamos, hoy en dia en todos lados) el poder paralelizar los drawcalls tendra sus ventajas. Mayores o menores dependiendo de cada caso concreto, pero vamos, si tienes dos cores y uno no puedes usarlo para tirar drawcalls, el poder usarlo siempre te dara una ventaja frente a la situacion anterior.

En el caso de las consolas lo mismo, y siendo cores de bajo consumo y eficiencia aun mas, porque se saturara mas rapido el core si tiene que tirar de todos los drawcalls, mientras que si los repartes tienes unos cuantos mas donde poder paralelizar esa tarea.

La paralelizacion va a ser muy importante para sacarle jugo a las consolas de ahora. En la anterior generacion teniamos cpus muy potentes con "pocos" threads, ahora tenemos cpus poco potentes con muchos cores. Paralelize or die

Zokormazo escribió:En cualquier plataforma donde tengas mas de un core de cpu (vamos, hoy en dia en todos lados) el poder paralelizar los drawcalls tendra sus ventajas. Mayores o menores dependiendo de cada caso concreto, pero vamos, si tienes dos cores y uno no puedes usarlo para tirar drawcalls, el poder usarlo siempre te dara una ventaja frente a la situacion anterior.

Sí, ya lo se. Y también se que esa era una limitación de DX11 en PC.
Pero no se si la variante de DX11 para ONE también la tenía, y tampoco se si el API Metal de la ONE la tenía.

cercata escribió:

Zokormazo escribió:En cualquier plataforma donde tengas mas de un core de cpu (vamos, hoy en dia en todos lados) el poder paralelizar los drawcalls tendra sus ventajas. Mayores o menores dependiendo de cada caso concreto, pero vamos, si tienes dos cores y uno no puedes usarlo para tirar drawcalls, el poder usarlo siempre te dara una ventaja frente a la situacion anterior.

Sí, ya lo se. Y también se que esa era una limitación de DX11 en PC.
Pero no se si la variante de DX11 para ONE también la tenía, y tampoco se si el API Metal de la ONE la tenía.

Por lo que dice el de metro, en DX11 one existe exactamente el mismo problema y con much overhead en cpu por las drawcalls. El tema del overhead parece que han ido evolucionando a mejor, pero lo de la paralelizacion sigue exactamente igual.

EDIT: Sobre la API pepito, ni idea @cercata. Yo ayer preguntaba lo mismo. Cuando el de metro habla de que existe una API DIY estilo DX12, parece que esta diciendo que en esa API (que al principio no habia) si que se puede paralelizar los drawcalls al estilo de mantle/dx12, pero no me aventuraria a asegurarlo con rotundidad xD

A ver lo que muestran el miercoles, parece que ahora tambien animan a seguir la conferencia a los de Xbox.

Ayer me llegó un email que el día 21 hay actualización de contrato de la preview de windows 10, creo que viene acompañada de un update, con suerte podemos probar alguna cosita que vaya a haber en la consola ¿navegador? ¿Cortana?

Nuhar escribió:A ver lo que muestran el miercoles, parece que ahora tambien animan a seguir la conferencia a los de Xbox.

Ayer me llegó un email que el día 21 hay actualización de contrato de la preview de windows 10, creo que viene acompañada de un update, con suerte podemos probar alguna cosita que vaya a haber en la consola ¿navegador? ¿Cortana?

Se nos cambian el EULA. De paso me entere que tengo un NDA de 5 años sobre la preview win10 xD

WTF, 5 años? Si dentro de 5 años ya estaremos hablando de windows 12 xD

@zokomarzo

Insisto en que el API pepito como tu le llamas es el Driver Mono, que se libero en Mayo, este estoy casi seguro de que sigue estando basado en DX 11, pero si es por fin un driver close to metal.

Esta vez no lo has metido en la ecuación pero te recuerdo que dice estilo Dx12 o GMN. ¿GMN es multihilo eficiente?

Yo creo que ahí a lo que se refiere es precisamente que el driver mono es close to metal.

Los resultados son los que podemos ver en la última oleada de juegos, pero no son el impulso del que habla Wardell por el uso del multihilo.

Mas que nada los developer de metro dicen que el problema con los calls solo se produce con el UMD, no tienen el más mínimo problema con GMN y asumo que este tampoco es multihilo.

Si asumes que por manejar los call eficientemente tanto el GMN como el MONO son multihilo como lo será DX 12, menudo mojon de Gen nos vamos a comer.

Zokormazo escribió:EDIT: Sobre la API pepito, ni idea @cercata. Yo ayer preguntaba lo mismo. Cuando el de metro habla de que existe una API DIY estilo DX12, parece que esta diciendo que en esa API (que al principio no habia)

Lo que dice el de metro vale, pero en la intro del articulo ponen otra jollita, lo de saltarte DX11. Y yo me pregunto, ¿ desde cuando ? ¿ Para todos a la vez ? ¿ Los de Forza 5 tuvieron acceso anticipado a eso ? Pq si te puedes saltar el API, puedes paralelizar las Drawcalls por tu cuenta ... aunque sea muy dificil.

"Did you know that Microsoft now allows developers to bypass DX11 and talk to the hardware directly ..."

"In general - I don't really get why they choose DX11 as a starting point for the console. It's a console! Why care about some legacy stuff at all? On PS4, most GPU commands are just a few DWORDs written into the command buffer, let's say just a few CPU clock cycles. On Xbox One it easily could be one million times slower because of all the bookkeeping the API does.

But Microsoft is not sleeping, really. Each K that has been released both before and after the Xbox One launch has brought faster and faster draw-calls to the table. They added tons of features just to work around limitations of the DX11 API model. They even made a DX12/GNM style do-it-yourself API available - although we didn't ship with it on Redux due to time constraints."

Zokormazo escribió:

cercata escribió:

Zokormazo escribió:En cualquier plataforma donde tengas mas de un core de cpu (vamos, hoy en dia en todos lados) el poder paralelizar los drawcalls tendra sus ventajas. Mayores o menores dependiendo de cada caso concreto, pero vamos, si tienes dos cores y uno no puedes usarlo para tirar drawcalls, el poder usarlo siempre te dara una ventaja frente a la situacion anterior.

Sí, ya lo se. Y también se que esa era una limitación de DX11 en PC.
Pero no se si la variante de DX11 para ONE también la tenía, y tampoco se si el API Metal de la ONE la tenía.

Por lo que dice el de metro, en DX11 one existe exactamente el mismo problema y con much overhead en cpu por las drawcalls. El tema del overhead parece que han ido evolucionando a mejor, pero lo de la paralelizacion sigue exactamente igual.

EDIT: Sobre la API pepito, ni idea @cercata. Yo ayer preguntaba lo mismo. Cuando el de metro habla de que existe una API DIY estilo DX12, parece que esta diciendo que en esa API (que al principio no habia) si que se puede paralelizar los drawcalls al estilo de mantle/dx12, pero no me aventuraria a asegurarlo con rotundidad xD

No. No dice eso ni se le parece. Insistis en lo de la api estilo dX12 pero NO habia en agosto una api DX12 para desarrolladores (por lo menos para los que no son First party)

But Microsoft is not sleeping, really. Each K that has been released both before and after the Xbox One launch has brought faster and faster draw-calls to the table. They added tons of features just to work around limitations of the DX11 API model. They even made a DX12/GNM style do-it-yourself API available - although we didn't ship with it on Redux due to time constraints.

do-it-yourself No habla de que tienen una API DX 12. Habla de una API DX11 en la que los desarrolladores tienen mucho más control para elegir como hacer esas draw calls. A mi modo de ver habla de que la misma API mono, tenia una nueva revision y que en esa revisión estaba abierta la posibilidad a meter mano a bajo nivel hasta cierto punto.

Eso no es tener una API DX12. Solo dice que en ese aspecto tenia una similitud con DX12 y GNM

No dice nada de API DX12. Solo habla de la nueva itiración de la API "mono" que hay actualmente.

De hecho en la sdk filtrada se ve claramente lo que digo. Dejaros de pajas metales de API parecida a DX12...
DX12 es diametralmente diferente a DX11

@papatuelo: Yo mas que close to metal, el concepto correcto diria que es DIY, vamos, no api driven. Porque la frase exacta que dice es "They even made a DX12/GNM style do-it-yourself API available"

Una API hazlo tu mismo del estilo DX12/GNM. Yo aqui entiendo que esta hablando de que el api hace menos cosas por ti (controlar drawcalls?) en pos de que lo haga el desarrollador.

Esto incluye la paralelizacion de los drawcalls? A saber. Pero vamos, una de las caracteristicas mas importante de DX12 frente a DX11 se supone que precisamente es esa no? El api no hace nada, lo controlas tu, tu te lo guisas tu te lo comes, tu envias las drawcalls como te apetezca, en un core, en dos, en cuatro...

No son pajas mentales papa, lo dice el con sus palabras. "Incluso han dispuesto una api hazlo-tu-mismo estilo DX12/GNM"

@eloskuro: Como es eso de que no compara con DX12 en la frase "They even made a DX12/GNM style do-it-yourself API available"... Ahi lo esta comparando con DX12, no con DX11. sobe que lo dice exactamente no lo se, pero esta claro que la comparacion la hace con DX12 y no DX11 xD

Zokormazo escribió:@papatuelo: Yo mas que close to metal, el concepto correcto diria que es DIY, vamos, no api driven. Porque la frase exacta que dice es "They even made a DX12/GNM style do-it-yourself API available"

Una API hazlo tu mismo del estilo DX12/GNM. Yo aqui entiendo que esta hablando de que el api hace menos cosas por ti (controlar drawcalls?) en pos de que lo haga el desarrollador.

Esto incluye la paralelizacion de los drawcalls? A saber. Pero vamos, una de las caracteristicas mas importante de DX12 frente a DX11 se supone que precisamente es esa no? El api no hace nada, lo controlas tu, tu te lo guisas tu te lo comes, tu envias las drawcalls como te apetezca, en un core, en dos, en cuatro...

No son pajas mentales papa, lo dice el con sus palabras. "Incluso han dispuesto una api hazlo-tu-mismo estilo DX12/GNM"

@eloskuro: Como es eso de que no compara con DX12 en la frase "They even made a DX12/GNM style do-it-yourself API available"... Ahi lo esta comparando con DX12, no con DX11. sobe que lo dice exactamente no lo se, pero esta claro que la comparacion la hace con DX12 y no DX11 xD

Pero sigue siendo la API mono que hemos visto en los sdk filtrados. Punto. Esta es la prueba.

Graphics: Throughout the coming months there are plenty of updates corresponding to the low-level D3D monolithic runtime. Hardware video encoding/decoding is added in March, along with asynchronous GPU compute support. By May, support for the user-mode driver is completely removed in favour of the mono-driver, explaining (in part at least) the marked improvement in Xbox One GPU performance in shipping titles from Q2 2014 onwards. The focus on the mono-driver appears to pay off as throughout 2014, Microsoft posts GPU performance improvements nearly every month, including some remarkable increases in draw call efficiency in July.

Eurogamer

http://www.eurogamer.net/articles/digitalfoundry-2015-evolution-of-xbox-one-as-told-by-sdk-leak

The focus on the mono-driver appears to pay off as throughout 2014, Microsoft posts GPU performance improvements nearly every month, including some remarkable increases in draw call efficiency in July

La entrevista de los de Metro es en agosto. Esta implementacion de drawcalls en en julio. Por lo tanto papatuelo tiene razón. No hay mas que hablar.

Usáis la palabra driver y la palabra API de forma indistinta. UMD y mono son drivers o son API? Si son drivers obviamente ambos son la ultima capa antes de la GPU, y si son API tienen debajo su directx y su driver!

De esa frase puedes interpretar lo qu quieras, logicamente da una pincelada y tu a partir de ahí pintas el cuadro, es como si te doy una frase y me dices que de ahí puedes deducir el libro completo con desenlace incluido.

El hecho, es que mejoraron la eficiencia de los Drawcalls, pero lo más probable es que no lo hicieran usando el multihilo eficiente que va a funcionar en DX 12. El problema en cualquier API actual es que tu puedes mandar lo que quieras donde quieras, pero siempre irá serializado, no puedes hacerlo de forma simultanea. Wardell dice que en el GDC veremos los primeros juegos que hacen uso de esa tecnología, asi que aun no hemos visto nada de eso. Los juegos del paritygate son gracias al Mono que es realmente una API console style no como el UMD que era una API de PC.

Documento técnico de Brad wardell:

in DirectX 10/11, all your cores could talk to DirectX but it was serialized (i.e. they entered a queue before being sent to the GPU).

@stylish Yo entiendo que es la API, pero en el SDK lo llaman driver

papatuelo escribió:Insisto en que el API pepito como tu le llamas es el Driver Mono, que se libero en Mayo, este estoy casi seguro de que sigue estando basado en DX 11, pero si es por fin un driver close to metal.

Esta vez no lo has metido en la ecuación pero te recuerdo que dice estilo Dx12 o GMN. ¿GMN es multihilo eficiente?

Yo creo que ahí a lo que se refiere es precisamente que el driver mono es close to metal.

Vale, ya creo que lo veo clarisimo, entre esto que has puesto, y lo de Eurogamer/Metro ...

Con el paso de UMD a Mono, hubo 2 ventajas:
1) Mejora en el rendimiento de DX11, sin que los desarrolladores tengan que cambiar código; mejora sustancial, ya que ademas de optimizarlo, al estar mas maduro, pasaron el driver de modo usuario a modo kernel, y quitaron código innecesario de chekeos.
2) Abrieron un nuevo API (pepito), que permite a los desarrolladores acceso completo al metal (DX11 para ONE es mas cercano al metal que DX11 en PC, pero esto aun mas), pero esto si que requiere curro por parte de los devs.

Y con DX12, llega ademas la mejor gestión del multi-hilo en la parte de DX.

papatuelo escribió:De esa frase puedes interpretar lo qu quieras, logicamente da una pincelada y tu a partir de ahí pintas el cuadro, es como si te doy una frase y me dices que de ahí puedes deducir el libro completo con desenlace incluido.

El hecho, es que mejoraron la eficiencia de los Drawcalls, pero lo más probable es que no lo hicieran usando el multihilo eficiente que va a funcionar en DX 12. El problema en cualquier API actual es que tu puedes mandar lo que quieras donde quieras, pero siempre irá serializado, no puedes hacerlo de forma simultanea. Wardell dice que en el GDC veremos los primeros juegos que hacen uso de esa tecnología, asi que aun no hemos visto nada de eso. Los juegos del paritygate son gracias al Mono que es realmente una API console style no como el UMD que era una API de PC.

Documento técnico de Brad wardell:

in DirectX 10/11, all your cores could talk to DirectX but it was serialized (i.e. they entered a queue before being sent to the GPU).

@stylish Yo entiendo que es la API, pero en el SDK lo llaman driver

Pues si lo llaman driver es driver, y tendría bastante más sentido. Por definicion un driver define la forma que tiene el sistema operativo con el hardware. Es posible que en el SDK ya se cuente con el driver mono y estas consolas de desarrollo puedan activarlo, no obstante por mucho que se pueda activar no quiere decir que el sistema operativo de nuestras One lo tenga activado o siquiera instalado.

Stylish escribió:Usáis la palabra driver y la palabra API de forma indistinta. UMD y mono son drivers o son API? Si son drivers obviamente ambos son la ultima capa antes de la GPU, y si son API tienen debajo su directx y su driver!

Son drivers, que soportan APIS:

UMD: Driver en modo usuario que soporta el APIs DX11.X
Mono: Driver en modo kernel que soporta los APIs DX11.X + pepito
Siguiente versión de mono: Driver en modo kernel que soporta los APIs DX12 + pepito2

Zokormazo escribió:

Nuhar escribió:A ver lo que muestran el miercoles, parece que ahora tambien animan a seguir la conferencia a los de Xbox.

Ayer me llegó un email que el día 21 hay actualización de contrato de la preview de windows 10, creo que viene acompañada de un update, con suerte podemos probar alguna cosita que vaya a haber en la consola ¿navegador? ¿Cortana?

Se nos cambian el EULA. De paso me entere que tengo un NDA de 5 años sobre la preview win10 xD

WTF, 5 años? Si dentro de 5 años ya estaremos hablando de windows 12 xD

Hombre, es lógico que cambien el EULA por una simple razón (es la que se me ocurrió al leer el correo): vamos a pasar de technologic preview a consumer preview y, simplemente, los datos que va a grabar el sistema por defecto van a ser diferentes. Ahora incluirá menos captura de todo lo que se hace. Lo de los 5 años supongo es (aparte de palabrería barata) porque puede haber cosas en la preview que no salgan en la versión final.

En lo que refiere al interior de la XBOX tendremos que estar atentos al evento porque si parece que va a participar el equipo XBOX. Esto es idea mía, repito, exclusiva mía: me huele que van a presentar/comentar algo para el futuro que conlleve la integración de la XBOX máquina (no el servicio) con el resto de dispositivos (juego streaming, etc, etc.) y algo aparte que, esto sí, sea del servicio XBOX Live.

@ZxspectruM: me parecio curioso eso del NDA de 5 años, para la preview de un producto que sale este año al que puede acceder todo quisqui xD Supongo que sera de la tipica plantilla que usan xD

cercata escribió:

Stylish escribió:Usáis la palabra driver y la palabra API de forma indistinta. UMD y mono son drivers o son API? Si son drivers obviamente ambos son la ultima capa antes de la GPU, y si son API tienen debajo su directx y su driver!

Son drivers, que soportan APIS:

UMD: Driver en modo usuario que soporta el APIs DX11.X
Mono: Driver en modo kernel que soporta los APIs DX11.X + pepito
Siguiente versión de mono: Driver en modo kernel que soporta los APIs DX12 + pepito2

La version de la api que controle dx12 no se llamaría mono. Tendrá que ser dual api .

@ZxspectruM, se han pasado, poner un NDA en la EULA, en la vida he visto un NDA que no este "firmado" ...
Yo tengo la preview un poco muerta de Risa, me gusto mucho en su día, aunque me decepciono que no trajese DX12. A ver si el 21 nos dan la campanada.

eloskuro escribió:La version de la api que controle dx12 no se llamaría mono. Tendrá que ser dual api .

Lo de mono de donde viene ? De monolítico ... siguiendo la nomenclatura la suyo hubiese sido KMD.

Pero sí, lo que dices es una paradoja

cercata escribió:

Stylish escribió:Usáis la palabra driver y la palabra API de forma indistinta. UMD y mono son drivers o son API? Si son drivers obviamente ambos son la ultima capa antes de la GPU, y si son API tienen debajo su directx y su driver!

Son drivers, que soportan APIS:

UMD: Driver en modo usuario que soporta el APIs DX11.X
Mono: Driver en modo kernel que soporta los APIs DX11.X + pepito
Siguiente versión de mono: Driver en modo kernel que soporta los APIs DX12 + pepito2

Exacto. Aunque la API close-to-the-metal de más posibilidades y tuvieran liberadas características DX12 desde su salida, que no todas ojo, y lo dijeron, "algunas", hay una capa que ninguna API puede saltarse.

En este caso recordemos que la capa más inferior, el hypervisor, que es quien reparte los recursos y finalmente hace uso directo del hardware, está basado aún en Windows 8.1, el cual al no ser compatible full DX12 no implemente la dualidad, y quizás alguna cosa más como la comunicación múltiple entre cores CPU-GPU, es decir que con base Windows 8.1 eso no se puede simplemente. Así que por mucho que te pongas close-to-the-metal no vas a poder usarlo todo hasta que la base se actualice a Windows 10 y ya por fin se implementen, a nivel de driver, y éste requiere características de Windows 10 no presentes en Windows 8.1, dichas características.

darksch escribió:En este caso recordemos que la capa más inferior, el hypervisor, que es quien reparte los recursos y finalmente hace uso directo del hardware

Ahí me has roto, cuando pensaba que ya lo entendia bien ... me había olvidado por completo del hypervisor.

¿ No cabria la posibilidad de que algunas direcciones de memoría (algunos registros de la GPU por ejemplo), sean directamente accesibles por el Exclusive OS sin pasar por el hypervisor, suponiendo que el hypervisor ha tenido que autorizarlo primero, y que se la CPU misma la que se encarge de permitir o denegar dichos accesos ?

Las ultimas CPUs X86/X64 traen algo de soporte nativo para virtualización.

papatuelo escribió:Documento técnico de Brad wardell:



[

Jeje me parto..

Chifrinillo escribió:

papatuelo escribió:Documento técnico de Brad wardell:



[

Jeje me parto..

En serio, lo ha colgado Bad Wardell, debe ser un paper que ha preparado para la GDC.

papatuelo escribió:

Chifrinillo escribió:

papatuelo escribió:Documento técnico de Brad wardell:



[

Jeje me parto..

En serio, lo ha colgado Bad Wardell, debe ser un paper que ha preparado para la GDC.

Pues a mi me parece la mejor explicación de Dx12 q he visto. Cualquiera lo entiende.

Szasz escribió:Pues a mi me parece la mejor explicación de Dx12 q he visto. Cualquiera lo entiende.

Claro, pero ademas es gracioso. Doblemente genial.