drneo escribió:buenas tengo un problema a ver si me pueden ayudar ....
el rollo es que la conexion a internet me va perfecta, puedo jugar a los juegos en la one online sin problemas, inicia bien la sesion, pero alguien me explica porque coño no me sale el bazar de la consola?¿?¿
al encenderla se queda ahi cargando todo el rato y despues sale un mensaje diciendo, tienes problemas para conectarte?¿ podria ser un problema nuesttro..
si le das ahi te lleva a la red, y ahi me sale mi conexion y dice todos los servicios estan disponibles, yo no entiendo nada, porque no me sale lo de juegos?¿ y para poder ir al bazar y esas cosas¿?¿
lleva asi un par de dias ya...
![[fumando]](/images/smilies/nuevos/fumando.gif "fumando")
Forzimbras escribió:Os funciona el Live? A mi no.
![[reojillo]](/images/smilies/nuevos2/ooooops.gif "reojillo")
no salía en abril la actu? Estoy apuntado en el programa de las betas,pero se supone que tendrían que avisarme antes y a mí no me ha llegado nada!! Mi no entender...Un saludo!! Matujk escribió:Hola, púes a mí se me está actualizando!!
Salva90 escribió:Forzimbras escribió:Os funciona el Live? A mi no.
Si que va...
Forzimbras escribió:Salva90 escribió:Forzimbras escribió:Os funciona el Live? A mi no.
Si que va...
Nada, nada, cosas de la betas de las actualizaciones xD Ahora sin venir a cuento me ha salido un mensaje de una actualización del sistema de 1GB y pico por arte de magia. Supongo que sería eso.
Lungprodg66 escribió:Madre mia yo de los AC's estoy hasta los cojones, salen como churros, yo tengo el 1 y el 3 y paso de comprar mas, acabas hasta el moño de siempre lo mismo, atalayas, etc etc
darksch escribió:hsaoud escribió:Me cuesta creer que Xbox One vaya a lanzar un juego con GI en tiempo real. Es un proceso muy costoso, y como no sea que la One tiene algo que no sepamos, o definitivamente "va a tirar de la nube" no veo claro que tengamos un juego con ésa tecnología ... aunque espero equivocarme jejeje
Yo opto por la ESRAM, los ingenieros de X1 han dicho que se han basado en un modelo de súper-computación, con la arquitectura CPU+GPU+ESRAM. Además la ESRAM es ideal para este tipo de buffers o capas que no son de color (que no requieran texturas), porque además puedes usar el modo de compresión de buffer más comprimido que soporte ya que en una capa de este tipo no apreciarás los artefactos de compresión aún siendo muy comprimido, con la posterior ventaja de que para pasarlo a la DDR3 también te va a pillar poco ancho al ser un buffer más pequeño al ser muy comprimido.
f5inet escribió:darksch escribió:hsaoud escribió:Me cuesta creer que Xbox One vaya a lanzar un juego con GI en tiempo real. Es un proceso muy costoso, y como no sea que la One tiene algo que no sepamos, o definitivamente "va a tirar de la nube" no veo claro que tengamos un juego con ésa tecnología ... aunque espero equivocarme jejeje
Yo opto por la ESRAM, los ingenieros de X1 han dicho que se han basado en un modelo de súper-computación, con la arquitectura CPU+GPU+ESRAM. Además la ESRAM es ideal para este tipo de buffers o capas que no son de color (que no requieran texturas), porque además puedes usar el modo de compresión de buffer más comprimido que soporte ya que en una capa de este tipo no apreciarás los artefactos de compresión aún siendo muy comprimido, con la posterior ventaja de que para pasarlo a la DDR3 también te va a pillar poco ancho al ser un buffer más pequeño al ser muy comprimido.
Yo apuesto mas por el tema que los chicos de Redmond han añadido una extension al DirectX de la consola para meter los 'drawcall' en una mini-eSRAM y que sea la GPU quien lea y ejecute directamente esos Draw-Call, sin necesidad de estar siendo 'alimentada' por la CPU.
DirectX hasta la version 11.2 es muy dependiente de la velocidad de la CPU, mas que nada, porque DirectX siempre ha confiado en acaparar un unico nucleo para 'alimentar' la GPU de tareas. basicamente, aunque tengas la GPU mas potente del mundo, si no eres capaz de tenerla ocupada mandandole tareas, llega el momento que se vuelve 'ociosa' porque no tiene nada que hacer (la GPU se queda esperando a la CPU) y es cuando decimos que un juego o aplicacion es 'CPU-bound' (o sea, su rendimiento esta limitado por la CPU).
En TomsHardware teneis un monton de analisis en los cuales el mismo juego, aumenta de framerate al aumentar la potencia de la CPU, siendo la misma GPU.
Este caso es mucho mas sangrante con los cores Jaguar, que son de bajo rendimiento. La solucion que habran tomado en Microsoft es usar un pequeño pool de ram ultra-rapida (eSRAM) para 'encolar' los draw-calls y que sea la GPU quien los ejecute. adicionalmente, es posible que los draw-calls puedan ser marcados como 'alta prioridad' o 'baja prioridad'. Un ejemplo de un drawcall de alta prioridad seria ejecutar un shader grafico para pintar en pantalla, mientras que un drawcall de baja prioridad seria uno para calcular un reflejo en una textura (que si da tiempo en ese frame, perfecto, y sino, para el siguiente)
En la imagen, se ven los dos 'pools' de eSRAM en la derecha (2x16MB=32MB) y una pequeña eSRAM entre los modulos quad-jaguar. Esa pequeña eSRAM (que calculando a ojo serian 4MB) seria la cola de drawcalls que TODOS los cpus Jaguar podrian alimentar y seria la GPU quien sacara directamente los drawcalls para mantenerse alimentada.
Cabe destacar que la razon de esta arquitectura es por el pobre rendimiento y adaptacion de DirectX a entornos multicore de bajo rendimiento. DirectX no ha tenido problemas mientras tuviese una CPU potente capaz de mantener alimentada a la GPU, el problema surge CUANDO NO ES ASI, y es en estos momentos de la 'era multicore' (tener muchos cores de poca potencia, y apagar los que no necesites para ahorrar energia) cuando se le ven las verguenzas a DirectX. es por eso que se ha desarrollado Mantle y que los de OpenGL dicen que pueden superar en 4 o 5 veces el rendimiento de DirectX, y lo hacen, pero en CPUs MODESTAS. en CPUs que son potentes de por si, como un i7, DirectX no tiene tal problema.
El problema existia en DirectX, y los de Microsoft han desarrollado diversas tecnicas para superarlo, como crear una nueva version de DirectX (v12) que sea capaz de ejecutar drawcalls de forma asincrona y simultanea (adaptada y optimizada para entornos multicore) y metiendo una cola de tareas en XboxONE.
y la gran pregunta ¿Tiene OpenGL y/o PS4 este problema? es posible que en algun momento lo tuviesen. ¿lo han arreglado? Ya lo veremos. Lo que si es cierto es que XboxONE, a partir del update que meta DirectX12 y que las desarrolladoras tengan los SDKs actualizados a DX12, ya no tendran ese problema.
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
Ha quedado todo muy bien explicadito f5inet escribió:darksch escribió:hsaoud escribió:Me cuesta creer que Xbox One vaya a lanzar un juego con GI en tiempo real. Es un proceso muy costoso, y como no sea que la One tiene algo que no sepamos, o definitivamente "va a tirar de la nube" no veo claro que tengamos un juego con ésa tecnología ... aunque espero equivocarme jejeje
Yo opto por la ESRAM, los ingenieros de X1 han dicho que se han basado en un modelo de súper-computación, con la arquitectura CPU+GPU+ESRAM. Además la ESRAM es ideal para este tipo de buffers o capas que no son de color (que no requieran texturas), porque además puedes usar el modo de compresión de buffer más comprimido que soporte ya que en una capa de este tipo no apreciarás los artefactos de compresión aún siendo muy comprimido, con la posterior ventaja de que para pasarlo a la DDR3 también te va a pillar poco ancho al ser un buffer más pequeño al ser muy comprimido.
Yo apuesto mas por el tema que los chicos de Redmond han añadido una extension al DirectX de la consola para meter los 'drawcall' en una mini-eSRAM y que sea la GPU quien lea y ejecute directamente esos Draw-Call, sin necesidad de estar siendo 'alimentada' por la CPU.
DirectX hasta la version 11.2 es muy dependiente de la velocidad de la CPU, mas que nada, porque DirectX siempre ha confiado en acaparar un unico nucleo para 'alimentar' la GPU de tareas. basicamente, aunque tengas la GPU mas potente del mundo, si no eres capaz de tenerla ocupada mandandole tareas, llega el momento que se vuelve 'ociosa' porque no tiene nada que hacer (la GPU se queda esperando a la CPU) y es cuando decimos que un juego o aplicacion es 'CPU-bound' (o sea, su rendimiento esta limitado por la CPU).
En TomsHardware teneis un monton de analisis en los cuales el mismo juego, aumenta de framerate al aumentar la potencia de la CPU, siendo la misma GPU.
Este caso es mucho mas sangrante con los cores Jaguar, que son de bajo rendimiento. La solucion que habran tomado en Microsoft es usar un pequeño pool de ram ultra-rapida (eSRAM) para 'encolar' los draw-calls y que sea la GPU quien los ejecute. adicionalmente, es posible que los draw-calls puedan ser marcados como 'alta prioridad' o 'baja prioridad'. Un ejemplo de un drawcall de alta prioridad seria ejecutar un shader grafico para pintar en pantalla, mientras que un drawcall de baja prioridad seria uno para calcular un reflejo en una textura (que si da tiempo en ese frame, perfecto, y sino, para el siguiente)
En la imagen, se ven los dos 'pools' de eSRAM en la derecha (2x16MB=32MB) y una pequeña eSRAM entre los modulos quad-jaguar. Esa pequeña eSRAM (que calculando a ojo serian 4MB) seria la cola de drawcalls que TODOS los cpus Jaguar podrian alimentar y seria la GPU quien sacara directamente los drawcalls para mantenerse alimentada.
Cabe destacar que la razon de esta arquitectura es por el pobre rendimiento y adaptacion de DirectX a entornos multicore de bajo rendimiento. DirectX no ha tenido problemas mientras tuviese una CPU potente capaz de mantener alimentada a la GPU, el problema surge CUANDO NO ES ASI, y es en estos momentos de la 'era multicore' (tener muchos cores de poca potencia, y apagar los que no necesites para ahorrar energia) cuando se le ven las verguenzas a DirectX. es por eso que se ha desarrollado Mantle y que los de OpenGL dicen que pueden superar en 4 o 5 veces el rendimiento de DirectX, y lo hacen, pero en CPUs MODESTAS. en CPUs que son potentes de por si, como un i7, DirectX no tiene tal problema.
El problema existia en DirectX, y los de Microsoft han desarrollado diversas tecnicas para superarlo, como crear una nueva version de DirectX (v12) que sea capaz de ejecutar drawcalls de forma asincrona y simultanea (adaptada y optimizada para entornos multicore) y metiendo una cola de tareas en XboxONE.
y la gran pregunta ¿Tiene OpenGL y/o PS4 este problema? es posible que en algun momento lo tuviesen. ¿lo han arreglado? Ya lo veremos. Lo que si es cierto es que XboxONE, a partir del update que meta DirectX12 y que las desarrolladoras tengan los SDKs actualizados a DX12, ya no tendran ese problema.
f5inet escribió:darksch escribió:hsaoud escribió:Me cuesta creer que Xbox One vaya a lanzar un juego con GI en tiempo real. Es un proceso muy costoso, y como no sea que la One tiene algo que no sepamos, o definitivamente "va a tirar de la nube" no veo claro que tengamos un juego con ésa tecnología ... aunque espero equivocarme jejeje
Yo opto por la ESRAM, los ingenieros de X1 han dicho que se han basado en un modelo de súper-computación, con la arquitectura CPU+GPU+ESRAM. Además la ESRAM es ideal para este tipo de buffers o capas que no son de color (que no requieran texturas), porque además puedes usar el modo de compresión de buffer más comprimido que soporte ya que en una capa de este tipo no apreciarás los artefactos de compresión aún siendo muy comprimido, con la posterior ventaja de que para pasarlo a la DDR3 también te va a pillar poco ancho al ser un buffer más pequeño al ser muy comprimido.
Yo apuesto mas por el tema que los chicos de Redmond han añadido una extension al DirectX de la consola para meter los 'drawcall' en una mini-eSRAM y que sea la GPU quien lea y ejecute directamente esos Draw-Call, sin necesidad de estar siendo 'alimentada' por la CPU.
DirectX hasta la version 11.2 es muy dependiente de la velocidad de la CPU, mas que nada, porque DirectX siempre ha confiado en acaparar un unico nucleo para 'alimentar' la GPU de tareas. basicamente, aunque tengas la GPU mas potente del mundo, si no eres capaz de tenerla ocupada mandandole tareas, llega el momento que se vuelve 'ociosa' porque no tiene nada que hacer (la GPU se queda esperando a la CPU) y es cuando decimos que un juego o aplicacion es 'CPU-bound' (o sea, su rendimiento esta limitado por la CPU).
En TomsHardware teneis un monton de analisis en los cuales el mismo juego, aumenta de framerate al aumentar la potencia de la CPU, siendo la misma GPU.
Este caso es mucho mas sangrante con los cores Jaguar, que son de bajo rendimiento. La solucion que habran tomado en Microsoft es usar un pequeño pool de ram ultra-rapida (eSRAM) para 'encolar' los draw-calls y que sea la GPU quien los ejecute. adicionalmente, es posible que los draw-calls puedan ser marcados como 'alta prioridad' o 'baja prioridad'. Un ejemplo de un drawcall de alta prioridad seria ejecutar un shader grafico para pintar en pantalla, mientras que un drawcall de baja prioridad seria uno para calcular un reflejo en una textura (que si da tiempo en ese frame, perfecto, y sino, para el siguiente)
En la imagen, se ven los dos 'pools' de eSRAM en la derecha (2x16MB=32MB) y una pequeña eSRAM entre los modulos quad-jaguar. Esa pequeña eSRAM (que calculando a ojo serian 4MB) seria la cola de drawcalls que TODOS los cpus Jaguar podrian alimentar y seria la GPU quien sacara directamente los drawcalls para mantenerse alimentada.
Cabe destacar que la razon de esta arquitectura es por el pobre rendimiento y adaptacion de DirectX a entornos multicore de bajo rendimiento. DirectX no ha tenido problemas mientras tuviese una CPU potente capaz de mantener alimentada a la GPU, el problema surge CUANDO NO ES ASI, y es en estos momentos de la 'era multicore' (tener muchos cores de poca potencia, y apagar los que no necesites para ahorrar energia) cuando se le ven las verguenzas a DirectX. es por eso que se ha desarrollado Mantle y que los de OpenGL dicen que pueden superar en 4 o 5 veces el rendimiento de DirectX, y lo hacen, pero en CPUs MODESTAS. en CPUs que son potentes de por si, como un i7, DirectX no tiene tal problema.
El problema existia en DirectX, y los de Microsoft han desarrollado diversas tecnicas para superarlo, como crear una nueva version de DirectX (v12) que sea capaz de ejecutar drawcalls de forma asincrona y simultanea (adaptada y optimizada para entornos multicore) y metiendo una cola de tareas en XboxONE.
y la gran pregunta ¿Tiene OpenGL y/o PS4 este problema? es posible que en algun momento lo tuviesen. ¿lo han arreglado? Ya lo veremos. Lo que si es cierto es que XboxONE, a partir del update que meta DirectX12 y que las desarrolladoras tengan los SDKs actualizados a DX12, ya no tendran ese problema.
f5inet escribió:darksch escribió:hsaoud escribió:Me cuesta creer que Xbox One vaya a lanzar un juego con GI en tiempo real. Es un proceso muy costoso, y como no sea que la One tiene algo que no sepamos, o definitivamente "va a tirar de la nube" no veo claro que tengamos un juego con ésa tecnología ... aunque espero equivocarme jejeje
Yo opto por la ESRAM, los ingenieros de X1 han dicho que se han basado en un modelo de súper-computación, con la arquitectura CPU+GPU+ESRAM. Además la ESRAM es ideal para este tipo de buffers o capas que no son de color (que no requieran texturas), porque además puedes usar el modo de compresión de buffer más comprimido que soporte ya que en una capa de este tipo no apreciarás los artefactos de compresión aún siendo muy comprimido, con la posterior ventaja de que para pasarlo a la DDR3 también te va a pillar poco ancho al ser un buffer más pequeño al ser muy comprimido.
Yo apuesto mas por el tema que los chicos de Redmond han añadido una extension al DirectX de la consola para meter los 'drawcall' en una mini-eSRAM y que sea la GPU quien lea y ejecute directamente esos Draw-Call, sin necesidad de estar siendo 'alimentada' por la CPU.
DirectX hasta la version 11.2 es muy dependiente de la velocidad de la CPU, mas que nada, porque DirectX siempre ha confiado en acaparar un unico nucleo para 'alimentar' la GPU de tareas. basicamente, aunque tengas la GPU mas potente del mundo, si no eres capaz de tenerla ocupada mandandole tareas, llega el momento que se vuelve 'ociosa' porque no tiene nada que hacer (la GPU se queda esperando a la CPU) y es cuando decimos que un juego o aplicacion es 'CPU-bound' (o sea, su rendimiento esta limitado por la CPU).
En TomsHardware teneis un monton de analisis en los cuales el mismo juego, aumenta de framerate al aumentar la potencia de la CPU, siendo la misma GPU.
Este caso es mucho mas sangrante con los cores Jaguar, que son de bajo rendimiento. La solucion que habran tomado en Microsoft es usar un pequeño pool de ram ultra-rapida (eSRAM) para 'encolar' los draw-calls y que sea la GPU quien los ejecute. adicionalmente, es posible que los draw-calls puedan ser marcados como 'alta prioridad' o 'baja prioridad'. Un ejemplo de un drawcall de alta prioridad seria ejecutar un shader grafico para pintar en pantalla, mientras que un drawcall de baja prioridad seria uno para calcular un reflejo en una textura (que si da tiempo en ese frame, perfecto, y sino, para el siguiente)
En la imagen, se ven los dos 'pools' de eSRAM en la derecha (2x16MB=32MB) y una pequeña eSRAM entre los modulos quad-jaguar. Esa pequeña eSRAM (que calculando a ojo serian 4MB) seria la cola de drawcalls que TODOS los cpus Jaguar podrian alimentar y seria la GPU quien sacara directamente los drawcalls para mantenerse alimentada.
Cabe destacar que la razon de esta arquitectura es por el pobre rendimiento y adaptacion de DirectX a entornos multicore de bajo rendimiento. DirectX no ha tenido problemas mientras tuviese una CPU potente capaz de mantener alimentada a la GPU, el problema surge CUANDO NO ES ASI, y es en estos momentos de la 'era multicore' (tener muchos cores de poca potencia, y apagar los que no necesites para ahorrar energia) cuando se le ven las verguenzas a DirectX. es por eso que se ha desarrollado Mantle y que los de OpenGL dicen que pueden superar en 4 o 5 veces el rendimiento de DirectX, y lo hacen, pero en CPUs MODESTAS. en CPUs que son potentes de por si, como un i7, DirectX no tiene tal problema.
El problema existia en DirectX, y los de Microsoft han desarrollado diversas tecnicas para superarlo, como crear una nueva version de DirectX (v12) que sea capaz de ejecutar drawcalls de forma asincrona y simultanea (adaptada y optimizada para entornos multicore) y metiendo una cola de tareas en XboxONE.
y la gran pregunta ¿Tiene OpenGL y/o PS4 este problema? es posible que en algun momento lo tuviesen. ¿lo han arreglado? Ya lo veremos. Lo que si es cierto es que XboxONE, a partir del update que meta DirectX12 y que las desarrolladoras tengan los SDKs actualizados a DX12, ya no tendran ese problema.
![[plas]](/images/smilies/aplauso.gif "Aplausos")
f5inet escribió:darksch escribió:hsaoud escribió:Me cuesta creer que Xbox One vaya a lanzar un juego con GI en tiempo real. Es un proceso muy costoso, y como no sea que la One tiene algo que no sepamos, o definitivamente "va a tirar de la nube" no veo claro que tengamos un juego con ésa tecnología ... aunque espero equivocarme jejeje
Yo opto por la ESRAM, los ingenieros de X1 han dicho que se han basado en un modelo de súper-computación, con la arquitectura CPU+GPU+ESRAM. Además la ESRAM es ideal para este tipo de buffers o capas que no son de color (que no requieran texturas), porque además puedes usar el modo de compresión de buffer más comprimido que soporte ya que en una capa de este tipo no apreciarás los artefactos de compresión aún siendo muy comprimido, con la posterior ventaja de que para pasarlo a la DDR3 también te va a pillar poco ancho al ser un buffer más pequeño al ser muy comprimido.
Yo apuesto mas por el tema que los chicos de Redmond han añadido una extension al DirectX de la consola para meter los 'drawcall' en una mini-eSRAM y que sea la GPU quien lea y ejecute directamente esos Draw-Call, sin necesidad de estar siendo 'alimentada' por la CPU.
DirectX hasta la version 11.2 es muy dependiente de la velocidad de la CPU, mas que nada, porque DirectX siempre ha confiado en acaparar un unico nucleo para 'alimentar' la GPU de tareas. basicamente, aunque tengas la GPU mas potente del mundo, si no eres capaz de tenerla ocupada mandandole tareas, llega el momento que se vuelve 'ociosa' porque no tiene nada que hacer (la GPU se queda esperando a la CPU) y es cuando decimos que un juego o aplicacion es 'CPU-bound' (o sea, su rendimiento esta limitado por la CPU).
En TomsHardware teneis un monton de analisis en los cuales el mismo juego, aumenta de framerate al aumentar la potencia de la CPU, siendo la misma GPU.
Este caso es mucho mas sangrante con los cores Jaguar, que son de bajo rendimiento. La solucion que habran tomado en Microsoft es usar un pequeño pool de ram ultra-rapida (eSRAM) para 'encolar' los draw-calls y que sea la GPU quien los ejecute. adicionalmente, es posible que los draw-calls puedan ser marcados como 'alta prioridad' o 'baja prioridad'. Un ejemplo de un drawcall de alta prioridad seria ejecutar un shader grafico para pintar en pantalla, mientras que un drawcall de baja prioridad seria uno para calcular un reflejo en una textura (que si da tiempo en ese frame, perfecto, y sino, para el siguiente)
En la imagen, se ven los dos 'pools' de eSRAM en la derecha (2x16MB=32MB) y una pequeña eSRAM entre los modulos quad-jaguar. Esa pequeña eSRAM (que calculando a ojo serian 4MB) seria la cola de drawcalls que TODOS los cpus Jaguar podrian alimentar y seria la GPU quien sacara directamente los drawcalls para mantenerse alimentada.
Cabe destacar que la razon de esta arquitectura es por el pobre rendimiento y adaptacion de DirectX a entornos multicore de bajo rendimiento. DirectX no ha tenido problemas mientras tuviese una CPU potente capaz de mantener alimentada a la GPU, el problema surge CUANDO NO ES ASI, y es en estos momentos de la 'era multicore' (tener muchos cores de poca potencia, y apagar los que no necesites para ahorrar energia) cuando se le ven las verguenzas a DirectX. es por eso que se ha desarrollado Mantle y que los de OpenGL dicen que pueden superar en 4 o 5 veces el rendimiento de DirectX, y lo hacen, pero en CPUs MODESTAS. en CPUs que son potentes de por si, como un i7, DirectX no tiene tal problema.
El problema existia en DirectX, y los de Microsoft han desarrollado diversas tecnicas para superarlo, como crear una nueva version de DirectX (v12) que sea capaz de ejecutar drawcalls de forma asincrona y simultanea (adaptada y optimizada para entornos multicore) y metiendo una cola de tareas en XboxONE.
y la gran pregunta ¿Tiene OpenGL y/o PS4 este problema? es posible que en algun momento lo tuviesen. ¿lo han arreglado? Ya lo veremos. Lo que si es cierto es que XboxONE, a partir del update que meta DirectX12 y que las desarrolladoras tengan los SDKs actualizados a DX12, ya no tendran ese problema.
Horizonte de sucesos escribió:[...]
Que opinas de esa modificación que se ve en los jaguar y que no debería de estar ahí (en la esquina y de color blanco)?
Qué puede ser y para que puede valer?
f5inet escribió:Yo apuesto mas por el tema que los chicos de Redmond han añadido una extension al DirectX de la consola para meter los 'drawcall' en una mini-eSRAM y que sea la GPU quien lea y ejecute directamente esos Draw-Call, sin necesidad de estar siendo 'alimentada' por la CPU.
DirectX hasta la version 11.2 es muy dependiente de la velocidad de la CPU, mas que nada, porque DirectX siempre ha confiado en acaparar un unico nucleo para 'alimentar' la GPU de tareas. basicamente, aunque tengas la GPU mas potente del mundo, si no eres capaz de tenerla ocupada mandandole tareas, llega el momento que se vuelve 'ociosa' porque no tiene nada que hacer (la GPU se queda esperando a la CPU) y es cuando decimos que un juego o aplicacion es 'CPU-bound' (o sea, su rendimiento esta limitado por la CPU).
En TomsHardware teneis un monton de analisis en los cuales el mismo juego, aumenta de framerate al aumentar la potencia de la CPU, siendo la misma GPU.
Este caso es mucho mas sangrante con los cores Jaguar, que son de bajo rendimiento. La solucion que habran tomado en Microsoft es usar un pequeño pool de ram ultra-rapida (eSRAM) para 'encolar' los draw-calls y que sea la GPU quien los ejecute. adicionalmente, es posible que los draw-calls puedan ser marcados como 'alta prioridad' o 'baja prioridad'. Un ejemplo de un drawcall de alta prioridad seria ejecutar un shader grafico para pintar en pantalla, mientras que un drawcall de baja prioridad seria uno para calcular un reflejo en una textura (que si da tiempo en ese frame, perfecto, y sino, para el siguiente)
En la imagen, se ven los dos 'pools' de eSRAM en la derecha (2x16MB=32MB) y una pequeña eSRAM entre los modulos quad-jaguar. Esa pequeña eSRAM (que calculando a ojo serian 4MB) seria la cola de drawcalls que TODOS los cpus Jaguar podrian alimentar y seria la GPU quien sacara directamente los drawcalls para mantenerse alimentada.
Cabe destacar que la razon de esta arquitectura es por el pobre rendimiento y adaptacion de DirectX a entornos multicore de bajo rendimiento. DirectX no ha tenido problemas mientras tuviese una CPU potente capaz de mantener alimentada a la GPU, el problema surge CUANDO NO ES ASI, y es en estos momentos de la 'era multicore' (tener muchos cores de poca potencia, y apagar los que no necesites para ahorrar energia) cuando se le ven las verguenzas a DirectX. es por eso que se ha desarrollado Mantle y que los de OpenGL dicen que pueden superar en 4 o 5 veces el rendimiento de DirectX, y lo hacen, pero en CPUs MODESTAS. en CPUs que son potentes de por si, como un i7, DirectX no tiene tal problema.
El problema existia en DirectX, y los de Microsoft han desarrollado diversas tecnicas para superarlo, como crear una nueva version de DirectX (v12) que sea capaz de ejecutar drawcalls de forma asincrona y simultanea (adaptada y optimizada para entornos multicore) y metiendo una cola de tareas en XboxONE.
y la gran pregunta ¿Tiene OpenGL y/o PS4 este problema? es posible que en algun momento lo tuviesen. ¿lo han arreglado? Ya lo veremos. Lo que si es cierto es que XboxONE, a partir del update que meta DirectX12 y que las desarrolladoras tengan los SDKs actualizados a DX12, ya no tendran ese problema.
f5inet escribió: [...]
![[tadoramo]](/images/smilies/adora.gif "Adorando")
