Szasz escribió:Das a entender que únicamente se le llama así por su GPU, en ese caso muchísima gente tiene un supercomputador en casa.
Nadie ha pensado q esa distribución podría ser mas correcta para el diseño de su APU, quizás para disipar calor, o para mejorar los yields, por una cuestión meramente de diseño de máscaras...hay mil motivos por los q puede tener esa disposición....
Szasz escribió:Aparece una declaración de Phill Spencer hablando de pruebas de raytracing en Xbox One, "con resultados impresionantes". No se le da importancia a esta declaración, supongo q es tomado como una herramienta de marketing q no debe ser tomada en cuenta.
Declaraciones de Microsoft hablando de la computación en la nube, del impulso q le daran a Xbox One. Se duda claramente de q esta información sea real y posible.
Entrevista a los ingenieros de Xbox One, todo es tomado al pie de la letra y no puede haber ni un matiz q se distancie de esa declaración.
Declaraciones de q Xbox esta hecha para cambiar con el tiempo. No hay MCUs, no lo dicen en la entrevista.
Aparece una declaración de Phill Spencer diciendo q Dx12 no sera un "game changer". Dx12 no supondrá ningún cambio.
Y podría dar miles de ejemplos en los q una información es tomada en serio o no dependiendo de las conveniencias de cada uno. Pero decir, q todo ha sido explicado ya, me parece un poco presuntuoso. Más aún cuando Microsoft esta buscando la manera de hacer demostraciones de ancho de banda y de la tecnología de la nube.
Is ESRAM really that much of a pain to work with?
Oles Shishkovstov: Actually, the real pain comes not from ESRAM but from the small amount of it. As for ESRAM performance - it is sufficient for the GPU we have in Xbox One. Yes it is true, that the maximum theoretical bandwidth - which is somewhat comparable to PS4 - can be rarely achieved (usually with simultaneous read and write, like FP16-blending) but in practice I've seen only a few cases where it becomes a limiting factor.
But Microsoft is not sleeping, really. Each SDK 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.
Szasz escribió:Por poner un ultimo ejemplo, refiriéndome a la entrevista a los desarrolladores de Redux , se puede leer como Microsoft les dio una API de Dx11 de PC, que sobrecarga de trabajo un hilo. Tú mismo, por sentido común, dijiste que las APIs de consolas no son así y que repartiría el trabajo adecuadamente. Sí, dijiste que las herramientas mejoran con el tiempo (que empeoren es imposible), pero negaste la posibilidad que esto pasara.
Digital Foundry: DirectX as an API is very mature now. Developers have got a lot of experience with it. To what extent do you think this is an advantage for Xbox One? Bearing in mind how mature the API is, could you optimise the silicon around it?
Andrew Goossen: To a large extent we inherited a lot of DX11 design. When we went with AMD, that was a baseline requirement. When we started off the project, AMD already had a very nice DX11 design. The API on top, yeah I think we'll see a big benefit. We've been doing a lot of work to remove a lot of the overhead in terms of the implementation and for a console we can go and make it so that when you call a D3D API it writes directly to the command buffer to update the GPU registers right there in that API function without making any other function calls. There's not layers and layers of software. We did a lot of work in that respect.
I don't really get why they choose DX11 as a starting point for the console
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).
But Microsoft is not sleeping, really. Each SDK 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
salocin21 escribió:Lo que dice en la entrevista es lo que ya se había hablado antes, que la api que usaba One no era direcxt 12 si no una para salir del paso.
Supongo que sera una versión modificada de DirectX 11.2 que tiene alguna funcionalidad de DirectX 12 adaptada con algunas llamadas close to metal especificas.
Pero claro sigue siendo una api muy ineficaz para el hardware que monta one, y DirectX 12 si que va a marcar diferencias importantes.
jor79 escribió:salocin21 escribió:Lo que dice en la entrevista es lo que ya se había hablado antes, que la api que usaba One no era direcxt 12 si no una para salir del paso.
Supongo que sera una versión modificada de DirectX 11.2 que tiene alguna funcionalidad de DirectX 12 adaptada con algunas llamadas close to metal especificas.
Pero claro sigue siendo una api muy ineficaz para el hardware que monta one, y DirectX 12 si que va a marcar diferencias importantes.
Concuerdo contigo. Pero de ahi a que Xone ya implemente DX12 no me la creo, como tampoco me creo que sea la panacea como algunos creen.
Saludos
Szasz escribió:No es que Dx12 sea la panacea, hay ya no entro. Pero la API actual es un "flop", un fracaso, y te lo están diciendo literalmente los de Metro Redux, no yo.
Dx12 sera una importante mejora, más por demérito de la actual que por merito propio. El resto de teorías sobre Dx12 quedan en suspenso.
papatuelo escribió:
En fin, que sí, que ya lo sabemos todo.
Barcelo Cola escribió:Todos sabemos que One ahorro en hardware para invertir en Kinect
Pero bueno,llegado este momento,tengo ilusion con los nuevos SDK esos de los que tan bien hablan,a ver si aumenta el rendimiento de la consola,que por ahora me decepciona un poco...
Szasz escribió:papatuelo escribió:
En fin, que sí, que ya lo sabemos todo.
Esto como se traduciría.
Yo solía ser una buena fuente de Microsoft. Entonces Microsoft me dío todo a cambio de un acuerdo de no divulgación (NDA). Ahora estoy jodido o soy un desastre?
Marcollo escribió:http://soloxboxone.com/2014/08/27/desarrollador-de-metro-redux-piensa-que-directx-12-sera-importante-para-xbox-one/
Parece que lo mejor de ONE aun esta por verse
Marcollo escribió:http://soloxboxone.com/2014/08/27/desarrollador-de-metro-redux-piensa-que-directx-12-sera-importante-para-xbox-one/
Parece que lo mejor de ONE aun esta por verse
Marcollo escribió:http://soloxboxone.com/2014/08/27/desarrollador-de-metro-redux-piensa-que-directx-12-sera-importante-para-xbox-one/
Parece que lo mejor de ONE aun esta por verse
Actually, the real pain comes not from ESRAM but from the small amount of it. As for ESRAM performance - it is sufficient for the GPU we have in Xbox One. Yes it is true, that the maximum theoretical bandwidth - which is somewhat comparable to PS4 - can be rarely achieved (usually with simultaneous read and write, like FP16-blending) but in practice I've seen only a few cases where it becomes a limiting factor.
Actualmente, el verdadero problema no viene de la ESRAM ni de su pequeño tamaño. Su rendimiento es suficiente para la GPU que tiene la Xbox One. Si, es cierto que su máximo teórico de ancho de banda (comparable a lo que pasa en PS4) rara vez se consigue, normalmente sucede cuando se usa la lectura y escritura simultánea, como en el FP16-blending, pero en la práctica solo he visto unos pocos casos en los que fuera un factor limitador.
Realmente el verdadero dolor [como problema] no viene de la eSRAM sino de la pequeña cantidad de esta. En cuanto al rendimiento de la eSRAM - es suficiente para la GPU que tenemos en XboxOne. Si es cierto, que el máximo ancho de banda teórico - el cual es en cierto modo comparable al de Ps4 - puede ser conseguido en raras ocasiones (generalmente con lecturas y escrituras simultáneas, como mezclas en FP16 [punto flotante de 16 bits]) pero en la práctica solo he visto unos cuantos caso en los que llega a ser un factor limitante.
Szasz escribió:La traducción de la noticia no es correcta. Hay algunos errores llamativos.
Pero la forma de afrontar la noticia de 3djuegos es lamentable. Sensacionalismo puro y duro en busca de visitas. Ni siquiera son capaces de dejar el link para leer la noticia original.
Con el tema del ancho de banda, en TEORÍA es bastante superior el de One, lo que pasa que por su peculiaridad es difícil alcanzarlo.
Pero realmente pueden sumarse ambos ancho de banda (tanto de la DDR3 como de la Sram)
"Nick Baker: First of all, there's been some question about whether we can use ESRAM and main RAM at the same time for GPU and to point out that really you can think of the ESRAM and the DDR3 as making up eight total memory controllers, so there are four external memory controllers (which are 64-bit) which go to the DDR3 and then there are four internal memory controllers that are 256-bit that go to the ESRAM. These are all connected via a crossbar and so in fact it will be true that you can go directly, simultaneously to DRAM and ESRAM."
Esto en teoría da 109 (read) + 109 (write) + 68 (DDR3)= 286 gb/s
El problema es que en la práctica baja sustancialmente.
"The same discussion with ESRAM as well - the 204GB/s number that was presented at Hot Chips is taking known limitations of the logic around the ESRAM into account. You can't sustain writes for absolutely every single cycle. The writes is known to insert a bubble [a dead cycle] occasionally... One out of every eight cycles is a bubble, so that's how you get the combined 204GB/s as the raw peak that we can really achieve over the ESRAM. And then if you say what can you achieve out of an application - we've measured about 140-150GB/s for ESRAM. That's real code running. That's not some diagnostic or some simulation case or something like that. That is real code that is running at that bandwidth. You can add that to the external memory and say that that probably achieves in similar conditions 50-55GB/s and add those two together you're getting in the order of 200GB/s across the main memory and internally."
Segun Microsoft tienen medidos corriendo código real 140-150GB/s para la Sram y 50-55GB/s para la DDR3, lo que hace un total de 200GB/s reales.
Y esto es algo que me choca mucho. Es un ancho de banda muy grande y esta medido y comprobado por ellos.
Por lo que tengo la impresión de que en los primeros Ks el ancho de banda venia capado. Por eso el tweet de Phill Spencer diciendo que se había liberado ancho de banda en los ultimos Ks. Algo que concuerda con esto:
"Nick Baker: When we started, we wrote a spec. Before we really went into any implementation details, we had to give developers something to plan around before we had the silicon, before we even had it running in simulation before tape-out, and said that the minimum bandwidth we want from the ESRAM is 102GB/s. That became 109GB/s [with the GPU speed increase]. In the end, once you get into implementing this, the logic turned out that you could go much higher."
Así q los chicos de Metro Redux han programado el juego con unas herramientas muy verdes, ya que no se han aprovechado de nada de esto. Que por cierto, han hecho un gran trabajo.