XBOX Series X

Lammothh escribió:Sobretodo en los estudios japoneses, no he visto un juego nipón a 60fps de inicio en mi puñetera vida.
Supongo que si cerramos los ojillos como ellos la fluidez aumenta...

Yo creo que el salto en potencia de la CPU permitirá que en la próxima gen haya bastantes más juegos a 60 frames.

Algunos os flipáis demasiado. En esta generación no vamos a ver ni un sólo juego a 120 fps. No se han establecido aún los 60 fps y ya estamos pidiendo 120 fps en consolas q como máximo costarán 500 euros.

daniel78 escribió:Algunos os flipáis demasiado. En esta generación no vamos a ver ni un sólo juego a 120 fps. No se han establecido aún los 60 fps y ya estamos pidiendo 120 fps en consolas q como máximo costarán 500 euros.

Solo en la plei cinco, que es la mejor del mundo.

logeim1924 escribió:

Xlooser escribió:¿Alguien cree en un modo 120 fps en Scarlett? Ya sé que al 99,99999% le parece una locura, pero intentad decir por qué.

Eso tendra que ser en función de juegos no de consolas. Microsoft no puede obligar a nadie a que hagan juegos como ellos quieren

Pero dios que ha pasado solo hace 20 horas que no estoy. Y ya hay gente diciendo 120fps?

Joder no conivartamos esto en la mierda del poder oculto del cell ni la segunda gpu secreta de one. Por dios. Nos vamos a tragar un sin fin d e juegos a 30fps. Para que hablemos de 120fps

Lammothh escribió:

daniel78 escribió:Algunos os flipáis demasiado. En esta generación no vamos a ver ni un sólo juego a 120 fps. No se han establecido aún los 60 fps y ya estamos pidiendo 120 fps en consolas q como máximo costarán 500 euros.

Solo el la plei cinco, que es la mejor del mundo.

Of course.

Xlooser escribió:

eloskuro escribió:

Xlooser escribió:¿Alguien cree en un modo 120 fps en Scarlett? Ya sé que al 99,99999% le parece una locura, pero intentad decir por qué.

Porque con 60 fps sobra.

Salvo en VR.

Entonces crees que Microsoft salvará a los que quieren jugar a 120 fps de una imagen mediocre. Yo creo que les dejaría elegir. El motivo de no ponerlo sería/será técnico.

Habría suficiente gente queriendo jugar a 120 fps como para que merezca la pena hacer juegos a 120 fps?

Por poder, el fifa que ya va a 4k/60 en PS4 pro seguro que lo podían poner a 120 fps fácilmente. Pero la pregunta es ¿para qué? ¿Cuál es la ventaja?

Xlooser escribió:¿Alguien cree en un modo 120 fps en Scarlett? Ya sé que al 99,99999% le parece una locura, pero intentad decir por qué.

No saquemos las cosas de contexto que todo viene de este mensaje en el que el lo empieza ya habla de que no va a ocurrir, solo (o yo lo he entendido así) pide que motivos hay, para que no ocurra porque (supongo que yo ni idea) técnicamente es posible, con ajustes porquerías y sin llevar esas cosas que molan que tanto se piden.

Mi teoría de porqué no va a pasar es porque realmente no hay mercado para eso, no se demanda y al no demandarse seguiremos con 30/60. Eso si es muy probable que hayan muchos mas a 60 por lo que se lee.

David Ricardo escribió:

Xlooser escribió:

eloskuro escribió:Porque con 60 fps sobra.

Salvo en VR.

Entonces crees que Microsoft salvará a los que quieren jugar a 120 fps de una imagen mediocre. Yo creo que les dejaría elegir. El motivo de no ponerlo sería/será técnico.

Habría suficiente gente queriendo jugar a 120 fps como para que merezca la pena hacer juegos a 120 fps?

Por poder, el fifa que ya va a 4k/60 en PS4 pro seguro que lo podían poner a 120 fps fácilmente. Pero la pregunta es ¿para qué? ¿Cuál es la ventaja?

Si se parte desde un diseño para poder ofrecer 120 fps, es mucho más fácil escalar la CPU y más fácil aún escalar la GPU para que los 60 fps y los 30 fps sean estables. Es que veo difícil que Phil Spencer se refiriera a 60 fps cuando hablaba de "altos framerates", además de que las especificaciones de Microsoft para su Realidad Mixta son 90 fps para la versión ultra. Seguro que superar la barrera de los 60 fps en consola es algo que Microsoft ha pensado, aunque no se materialice al final.

Para mí no hay ventaja en los 120 fps, en la mayoría de juegos elegiré 30 fps; un modo 60 fps si la resolución es de al menos 1440p (1080p y que el juego escale muy bien es para pensárselo, como con el Gears 4) y la carga gráfica no se recorta mucho. He visto juegos en PC con pantalla G-Sync entre 80 y 90 fps, una gozada, pero de lejos me quedo con 50 pulgadas y una calidad de imagen excelente.


@logeim1924 eso ya lo sé. Cuando digo Microsoft, me refiero a sus juegos, no a que va a obligar al resto de compañías.


@Eaniel Kashal gracias.

Xlooser escribió:

David Ricardo escribió:

Xlooser escribió:Entonces crees que Microsoft salvará a los que quieren jugar a 120 fps de una imagen mediocre. Yo creo que les dejaría elegir. El motivo de no ponerlo sería/será técnico.

Habría suficiente gente queriendo jugar a 120 fps como para que merezca la pena hacer juegos a 120 fps?

Por poder, el fifa que ya va a 4k/60 en PS4 pro seguro que lo podían poner a 120 fps fácilmente. Pero la pregunta es ¿para qué? ¿Cuál es la ventaja?

Si se parte desde un diseño para poder ofrecer 120 fps, es mucho más fácil escalar la CPU y más fácil aún escalar la GPU para que los 60 fps y los 30 fps sean estables. Es que veo difícil que Phil Spencer se refiriera a 60 fps cuando hablaba de "altos framerates", además de que las especificaciones de Microsoft para su Realidad Mixta son 90 fps para la versión ultra. Seguro que superar la barrera de los 60 fps en consola es algo que Microsoft ha pensado, aunque no se materialice al final.

Para mí no hay ventaja en los 120 fps, en la mayoría de juegos elegiré 30 fps; un modo 60 fps si la resolución es de al menos 1440p (1080p y que el juego escale muy bien es para pensárselo, como con el Gears 4) y la carga gráfica no se recorta mucho. He visto juegos en PC con pantalla G-Sync entre 80 y 90 fps, una gozada, pero de lejos me quedo con 50 pulgadas y una calidad de imagen excelente.


@logeim1924 eso ya lo sé. Cuando digo Microsoft, me refiero a sus juegos, no a que va a obligar al resto de compañías.


@Eaniel Kashal gracias.

Si haces el juego para que la CPU lo mueva a 120 fps, al bajarlo a 60 o 30 la CPU estará totalmente desaprovechada. Y la GPU tampoco la exprimes igual de bien si tienes varios modos distintos como si te centrases solo en un objetivo concreto de frames.

4K/60fps para paneles caseros es lo ideal.
8K es una pollada en 65" o menos y 120fps una exageración sin sentido consume recursos, energía, calor...

esto va a ser un day 1

Xlooser escribió:¿Alguien cree en un modo 120 fps en Scarlett? Ya sé que al 99,99999% le parece una locura, pero intentad decir por qué.

Sin saber nada de hardware me atrevo a contestar:

Yo no lo creo, porque juegos que fuesen a 120 fps... Pocos. Y en plataformas cerradas gusta poco a los devs dejar los fps desbloqueados.

David Ricardo escribió:

Xlooser escribió:

David Ricardo escribió:Habría suficiente gente queriendo jugar a 120 fps como para que merezca la pena hacer juegos a 120 fps?

Por poder, el fifa que ya va a 4k/60 en PS4 pro seguro que lo podían poner a 120 fps fácilmente. Pero la pregunta es ¿para qué? ¿Cuál es la ventaja?

Si se parte desde un diseño para poder ofrecer 120 fps, es mucho más fácil escalar la CPU y más fácil aún escalar la GPU para que los 60 fps y los 30 fps sean estables. Es que veo difícil que Phil Spencer se refiriera a 60 fps cuando hablaba de "altos framerates", además de que las especificaciones de Microsoft para su Realidad Mixta son 90 fps para la versión ultra. Seguro que superar la barrera de los 60 fps en consola es algo que Microsoft ha pensado, aunque no se materialice al final.

Para mí no hay ventaja en los 120 fps, en la mayoría de juegos elegiré 30 fps; un modo 60 fps si la resolución es de al menos 1440p (1080p y que el juego escale muy bien es para pensárselo, como con el Gears 4) y la carga gráfica no se recorta mucho. He visto juegos en PC con pantalla G-Sync entre 80 y 90 fps, una gozada, pero de lejos me quedo con 50 pulgadas y una calidad de imagen excelente.


@logeim1924 eso ya lo sé. Cuando digo Microsoft, me refiero a sus juegos, no a que va a obligar al resto de compañías.


@Eaniel Kashal gracias.

Si haces el juego para que la CPU lo mueva a 120 fps, al bajarlo a 60 o 30 la CPU estará totalmente desaprovechada. Y la GPU tampoco la exprimes igual de bien si tienes varios modos distintos como si te centrases solo en un objetivo concreto de frames.

Si se mantiene igual sí. La IA y las físicas se pueden escalar, es más fácil pasar de menos complejo a más complejo que al revés.

Para lograr unos fps objetivo lo único que importa es el frametime: 33.3 ms, 16.6 u 8.3, ajustar tus cálculos a que se hagan en determinado tiempo dado no es tan misterioso.

Una duda rápida, El HDR al activarlo consume muchos recursos? En plan no se si se pierde un 10% de rendimiento respecto al SDR por ejemplo. O no tiene nada que ver?

Jony ReyeS escribió:Una duda rápida, El HDR al activarlo consume muchos recursos? En plan no se si se pierde un 10% de rendimiento respecto al SDR por ejemplo. O no tiene nada que ver?

Sobre esto que comentas solo lo encontré información que lo relaciona al Pc , nada de consolas

Xlooser escribió:Si se mantiene igual sí. La IA y las físicas se pueden escalar, es más fácil pasar de menos complejo a más complejo que al revés.

Para lograr unos fps objetivo lo único que importa es el frametime: 33.3 ms, 16.6 u 8.3, ajustar tus cálculos a que se hagan en determinado tiempo dado no es tan misterioso.

La respuesta te la das tú solo. ¿Por qué es más fácil pasar de menos complejo a más complejo? Porque si diseñas tu juego para que vaya a 120 fps, es fácil añadir pijadas para rellenar el tiempo de cpu extra que tienes. Pero si lo diseñas para que vaya a 60 o 30, es muy difícil quitarle cosas para doblar o cuadruplicar el frame rate. Porque va a haber cosas esenciales al juego que no vas a poder escalar. Pues eso es el aprovechamiento extra de la CPU que podrías haber hecho, que te estás perdiendo por haber diseñado el juego en base a que pueda ir a 120 fps.

Magnarock escribió:

14 DAYS

Ya está confirmado que este año la conferencia de ms va a durar 2 horas(la primera vez en la historia).Nos queda nada!

David Ricardo escribió:

Xlooser escribió:Si se mantiene igual sí. La IA y las físicas se pueden escalar, es más fácil pasar de menos complejo a más complejo que al revés.

Para lograr unos fps objetivo lo único que importa es el frametime: 33.3 ms, 16.6 u 8.3, ajustar tus cálculos a que se hagan en determinado tiempo dado no es tan misterioso.

La respuesta te la das tú solo. ¿Por qué es más fácil pasar de menos complejo a más complejo? Porque si diseñas tu juego para que vaya a 120 fps, es fácil añadir pijadas para rellenar el tiempo de cpu extra que tienes. Pero si lo diseñas para que vaya a 60 o 30, es muy difícil quitarle cosas para doblar o cuadruplicar el frame rate. Porque va a haber cosas esenciales al juego que no vas a poder escalar. Pues eso es el aprovechamiento extra de la CPU que podrías haber hecho, que te estás perdiendo por haber diseñado el juego en base a que pueda ir a 120 fps.

Te has liado.

Si diseñas para 120 fps, lo que controla la CPU es poco complejo. Si dispones del doble de tiempo puedes complicar más los cálculos. Hacer esto es más fácil.

Si diseñas para 60 fps, lo que controla la CPU es más complejo. Si de repente dispones de la mitad de tiempo debes simplificar los cálculos. Hacer esto no es trivial.

¿Por qué un juego que se ha pensado para 30 fps es tan difícil ponerlo a 60? Por eso mismo. Estoy convencido de que en todos los juegos con varios modos, el diseño está orientado a ofrecer 60 fps. El modo a 30 fps es sólo complicar los cálculos.

Xlooser escribió:

David Ricardo escribió:

Xlooser escribió:Si se parte desde un diseño para poder ofrecer 120 fps, es mucho más fácil escalar la CPU y más fácil aún escalar la GPU para que los 60 fps y los 30 fps sean estables. Es que veo difícil que Phil Spencer se refiriera a 60 fps cuando hablaba de "altos framerates", además de que las especificaciones de Microsoft para su Realidad Mixta son 90 fps para la versión ultra. Seguro que superar la barrera de los 60 fps en consola es algo que Microsoft ha pensado, aunque no se materialice al final.

Para mí no hay ventaja en los 120 fps, en la mayoría de juegos elegiré 30 fps; un modo 60 fps si la resolución es de al menos 1440p (1080p y que el juego escale muy bien es para pensárselo, como con el Gears 4) y la carga gráfica no se recorta mucho. He visto juegos en PC con pantalla G-Sync entre 80 y 90 fps, una gozada, pero de lejos me quedo con 50 pulgadas y una calidad de imagen excelente.


@logeim1924 eso ya lo sé. Cuando digo Microsoft, me refiero a sus juegos, no a que va a obligar al resto de compañías.


@Eaniel Kashal gracias.

Si haces el juego para que la CPU lo mueva a 120 fps, al bajarlo a 60 o 30 la CPU estará totalmente desaprovechada. Y la GPU tampoco la exprimes igual de bien si tienes varios modos distintos como si te centrases solo en un objetivo concreto de frames.

Si se mantiene igual sí. La IA y las físicas se pueden escalar, es más fácil pasar de menos complejo a más complejo que al revés.

Para lograr unos fps objetivo lo único que importa es el frametime: 33.3 ms, 16.6 u 8.3, ajustar tus cálculos a que se hagan en determinado tiempo dado no es tan misterioso.

En los juegos retrocompatibles si podrian ponerlos a 120fps, pero con las pocas tv que hay con mas de 60fps no creo

Xlooser escribió:

David Ricardo escribió:

Xlooser escribió:Si se mantiene igual sí. La IA y las físicas se pueden escalar, es más fácil pasar de menos complejo a más complejo que al revés.

Para lograr unos fps objetivo lo único que importa es el frametime: 33.3 ms, 16.6 u 8.3, ajustar tus cálculos a que se hagan en determinado tiempo dado no es tan misterioso.

La respuesta te la das tú solo. ¿Por qué es más fácil pasar de menos complejo a más complejo? Porque si diseñas tu juego para que vaya a 120 fps, es fácil añadir pijadas para rellenar el tiempo de cpu extra que tienes. Pero si lo diseñas para que vaya a 60 o 30, es muy difícil quitarle cosas para doblar o cuadruplicar el frame rate. Porque va a haber cosas esenciales al juego que no vas a poder escalar. Pues eso es el aprovechamiento extra de la CPU que podrías haber hecho, que te estás perdiendo por haber diseñado el juego en base a que pueda ir a 120 fps.

Te has liado.

Si diseñas para 120 fps, lo que controla la CPU es poco complejo. Si dispones del doble de tiempo puedes complicar más los cálculos. Hacer esto es más fácil.

Si diseñas para 60 fps, lo que controla la CPU es más complejo. Si de repente dispones de la mitad de tiempo debes simplificar los cálculos. Hacer esto no es trivial.

¿Por qué un juego que se ha pensado para 30 fps es tan difícil ponerlo a 60? Por eso mismo. Estoy convencido de que en todos los juegos con varios modos, el diseño está orientado a ofrecer 60 fps. El modo a 30 fps es sólo complicar los cálculos.

No entiendo dónde se supone que me he liado. A mi parecer, tú estás diciendo lo mismo que yo.

logeim1924 escribió:

Xlooser escribió:

David Ricardo escribió:Si haces el juego para que la CPU lo mueva a 120 fps, al bajarlo a 60 o 30 la CPU estará totalmente desaprovechada. Y la GPU tampoco la exprimes igual de bien si tienes varios modos distintos como si te centrases solo en un objetivo concreto de frames.

Si se mantiene igual sí. La IA y las físicas se pueden escalar, es más fácil pasar de menos complejo a más complejo que al revés.

Para lograr unos fps objetivo lo único que importa es el frametime: 33.3 ms, 16.6 u 8.3, ajustar tus cálculos a que se hagan en determinado tiempo dado no es tan misterioso.

En los juegos retrocompatibles si podrian ponerlos a 120fps, pero con las pocas tv que hay con mas de 60fps no creo

Es más difícil transformar un diseño existente a 60 fps y ponerlo a 120 que diseñar desde 0 para conseguir 120 fps.

Si en Battlefiled V retiran el bloqueo para Scarlett, correría a 120 fps una gran parte del tiempo, pero las bajadas de frames serían impredecibles. Zen2 es mucho más poderoso, lo que garantizaría pocas bajadas.


@David Ricardo pues que replicas lo que yo he dicho en mi primer comentario y sin embargo pretendes invalidarlo. Lo he aclarado por si no habías entendido lo que dije.

Primero dices:

Porque si diseñas tu juego para que vaya a 120 fps, es fácil añadir pijadas para rellenar el tiempo de cpu extra que tienes

Al final dices:

Pues eso es el aprovechamiento extra de la CPU que podrías haber hecho, que te estás perdiendo por haber diseñado el juego en base a que pueda ir a 120 fps.

Es contradictorio.

En realidad no hay diferencia. Los juegos que aún se diseñaban así podemos mirar en los japos, ejemplos como Dark Souls, hecho para 30 fps, todo metido ahí fijo a piñón, y si lo ponías a 60 fps se iba todo al garete.

Pero en occidente ya por lo general, y seguramente en oriente bastantes, no se diseña en base a fps, los frames van por deltas de tiempo, de ahí que lo pones en PC y se te adaptan los fps a lo que tengas. Esto en cuanto a movimiento.
En cuanto a los cálculos (mejor dicho la lógica) físicas, IA, y cosas que dependan de actualizaciones por segundo, se establece una tasa, por ej. la IA no se ejecuta en todas las iteraciones, y en caso de la física pues se interpola en caso de ser necesario (si no un objeto a mucha velocidad podría atravesar a otro). Pero esto no tiene relación directa con lo que vemos en el sentido de que se diseñe para tal o cual tasa.

Es decir, la lógica se establece 1º en función de lo que se busque, y luego lo que vemos es resultado de "capturar" en base a un delta de tiempo pasado en base a lo que se ha calculado. Es decir se aplican los vectores de movimiento, rotación, frame de animación y etc. en base a dicho delta.

A partir de ahí es tocar a según los objetivos a alcanzar.

Un ejemplo claro lo tenemos en el reciente Rage 2, el juego a 30 y 60 se comporta exactamente igual, eso sería poco probable en caso de haber cambiado el diseño se verían algunas cosas distintas. Sin embargo lo que se ve en cada versión no es si no el resultado de dibujar cada X o Y ms (según la tasa de fps) el "mejunje" que se está procesando de fondo, el cual no vemos, lo que vemos es la captura que se le hace a cada fotograma.

Y ese delta es mucho más fácil aumentarlo que disminuirlo. Si de inicio cuentas con que tienes 8.3 ms, adaptar tu lógica para tardar 16.6 ms es más fácil que al revés.

Yo, la pregunta que me haría sería:

¿Una lógica del juego diseñada para 16.6 ms ofrece mejores resultados que una pensada para 8.3 ms y adaptada a 16.6?

Es que la lógica no se mete en 8 ni 16 ms, son cosas que van aparte.

Por un lado estableces la lógica, cómo la vas a actualizar, ahí depende más de la velocidad de los objetos, o de la inteligencia.

Por otro lado cada cuánto haces captura. El dibujado en sí consume, y no sólo GPU, así que no es sólo cuestión de querer hacerlo, si no se tener capacidad para poder bajarlo.

Le puedes hacer perfectamente una captura cada 8 ms a una lógica que se actualiza cada 40ms. Simplemente vas a ver desplazamientos suaves entre cambios menos frecuentes.

Xlooser escribió:Y ese delta es mucho más fácil aumentarlo que disminuirlo. Si de inicio cuentas con que tienes 8.3 ms, adaptar tu lógica para tardar 16.6 ms es más fácil que al revés.

Yo, la pregunta que me haría sería:

¿Una lógica del juego diseñada para 16.6 ms ofrece mejores resultados que una pensada para 8.3 ms y adaptada a 16.6?

Pregunta de examen

¿Que puedes extrapolar de un profile típico de un juego de unity ?

Que los colorines son muy chulos?

De verdad. Próxima parada ingenieros de la NASA . Le mande un MP @N-N para ver si se puede crear un hilo exclusivamente para Scarlet , con lo básico para los que no entendemos y no nos interesan tanto los técnicismos .

Por ejemplo : Tendrá 11 TFLOP

No me interesa si el SSD se tira a la GPU por parte de madre a la CPU por culpa de los Rops

Hombre lo de la pregunta de examen es de traca......pon 4 respuestas para hacer quiniela al menos!

Xlooser escribió:

logeim1924 escribió:

Xlooser escribió:Si se mantiene igual sí. La IA y las físicas se pueden escalar, es más fácil pasar de menos complejo a más complejo que al revés.

Para lograr unos fps objetivo lo único que importa es el frametime: 33.3 ms, 16.6 u 8.3, ajustar tus cálculos a que se hagan en determinado tiempo dado no es tan misterioso.

En los juegos retrocompatibles si podrian ponerlos a 120fps, pero con las pocas tv que hay con mas de 60fps no creo

Es más difícil transformar un diseño existente a 60 fps y ponerlo a 120 que diseñar desde 0 para conseguir 120 fps.

Si en Battlefiled V retiran el bloqueo para Scarlett, correría a 120 fps una gran parte del tiempo, pero las bajadas de frames serían impredecibles. Zen2 es mucho más poderoso, lo que garantizaría pocas bajadas.


@David Ricardo pues que replicas lo que yo he dicho en mi primer comentario y sin embargo pretendes invalidarlo. Lo he aclarado por si no habías entendido lo que dije.

Primero dices:

Porque si diseñas tu juego para que vaya a 120 fps, es fácil añadir pijadas para rellenar el tiempo de cpu extra que tienes

Al final dices:

Pues eso es el aprovechamiento extra de la CPU que podrías haber hecho, que te estás perdiendo por haber diseñado el juego en base a que pueda ir a 120 fps.

Es contradictorio.

La explicación la tienes en la parte que has omitido de mi mensaje:

David Ricardo escribió:Porque va a haber cosas esenciales al juego que no vas a poder escalar. Pues eso es el aprovechamiento extra de la CPU que podrías haber hecho, que te estás perdiendo por haber diseñado el juego en base a que pueda ir a 120 fps.

Si diseñas el juego contando con que va a ir a 60 frames, vas a meter una serie de mecánicas esenciales que puedes calcular en el tiempo que tienes. Si diseñas el mismo juego para ir a 120 frames, tendrás que meterle unas mecánicas más simples. Luego le puedes añadir pijadas para usar el tiempo de CPU sobrante cuando vaya a 60 frames, pero la parte esencial del juego estará limitada por lo que puedas hacer a 120 frames.

darksch escribió:Es que la lógica no se mete en 8 ni 16 ms, son cosas que van aparte.

Por un lado estableces la lógica, cómo la vas a actualizar, ahí depende más de la velocidad de los objetos, o de la inteligencia.

Por otro lado cada cuánto haces captura. El dibujado en sí consume, y no sólo GPU, así que no es sólo cuestión de querer hacerlo, si no se tener capacidad para poder bajarlo.

Le puedes hacer perfectamente una captura cada 8 ms a una lógica que se actualiza cada 40ms. Simplemente vas a ver desplazamientos suaves entre cambios menos frecuentes.

Sin saber nada de desarrollo de grandes proyectos, porque no he trabajado nunca en desarrollo, entiendo que si ese tiempo entre capturas es mayor, el tiempo del que puedes disponer para la lógica es mayor para idéntico resultado.

Como bien dices, ya suponía que fueran procesos separados, pero en un sistema de tiempo real sí hay límites de tiempo a la hora de ofrecer la respuesta. Aunque tampoco lo parezca, ya sé que la CPU no se para cuando otra parte, por ejemplo la GPU, está renderizando lo que ha dicho la CPU.

Por concretar, los daños de impacto tienen que calcularse sí o sí todos o cada ciertos frames, con lo que hay un tiempo límite. Por otra parte, lo que ha renderizado la GPU no va a ser eterno y sólo tendrá sentido en un período de tiempo determinado. A mí no me parece que el frametime sea completamente independiente de la lógica que haya por detrás, algo que también deduzco de tu comentario. Ni tampoco creo que lo será de los comandos que el usuario introduce a través del pad.

La imagen que ha puesto el otro forero, con pregunta capciosa incluida, muestra, según entiendo, procesos independientes entre sí pero que el desarrollador deberá tener en cuenta en conjunto y hacer la captura cuando todos estén en un estado aceptable para ofrecer un buen resultado a la hora de dibujar el frame y que el usuario no note nada raro. Vamos, que para lograr un buen resultado todo el diseño está planificado, no creo que haya sitio a la arbitrariedad, al menos premeditada.

Si es así, tomar una captura cada 8.3 ms es muy diferente de hacerlo cada 16.6 ms ó 33.3, pero pasar de 8.3 a 16.6 será más sencillo que al revés.

Siéntete libre de corregirme en todo lo que quieras, tú eres desarrollador en C y yo sólo un aficionado.


@Camtrack he reconocido abiertamente y varias veces que no tengo ni idea de desarrollo, menos aún de un videojuego, sólo me veo capaz de deducir y sacar conclusiones de lo que leo. Te doy la enhorabuena por la innecesaria tarea de tirarme a los leones y las gracias por enseñarme que la carga de CPU para el renderizado es mucho mayor de lo que yo creía, con lo que la X tiene un mejor diseño del que le asignaba y la diferencia entre su CPU y el resto es mayor del que dicen las especificaciones.

Ahora te pregunto yo por ello, que entiendo que eres un experto, si no no sabrías si te doy una respuesta errónea. Explícamelo.


@David Ricardo eso es lo que yo creo que se puede escalar. No veo una mecánica compleja como un todo, sino como una suma de mecánicas simples.

Xlooser escribió: @David Ricardo eso es lo que yo creo que se puede escalar. No veo una mecánica compleja como un todo, sino como una suma de mecánicas simples.

No veo cómo cambia lo que estoy argumentando. Sustituye que las mecánicas no podrán ser tan complejas por que no podrán calcular tantas mecánicas simples y el argumento se sostiene igual.
Un juego diseñado para ir a 60 fps permite más libertad de diseño que uno diseñado para ir a 120 fps y que luego pasan a 60.

Que haya llegado el dia en que eche de menos las cosas de indigo ...

Buenas gente.

Xlooser escribió:- Yo tengo entendido que son los Tensor Cores los que están conmutados con los shaders, no los RT Cores. Bueno, ambos están conectados a la misma caché, en teoría los Shader siguen trabajando con sus registros. Leeré el paper que has pasado, me parece muy interesante, gracias.

Los Tensor Cores es una forma muy elegante y bonita de decir ALUs especializadas para operar con matrices. En la arquitectura Turing hay tres tipos de ALUs dentro de un SM: ALUs para operar con flotantes, ALUs para operar con enteros y ALUs para operar con matrices del tirón. Las tres están "al mismo nivel" por decirlo de alguna forma. Un Tensor Core no es una unidad específica independiente como puede ser una unidad de textura o los RT Cores, es una ALU más. A partir de esta arquitectura las operaciones de enteros y las de flotantes pueden ejecutarse en paralelo (no así para los Tensor Cores), pero las dependencias de datos están ahí y la mejora será mucho menor q el 36% que clama a los 4 vientos Nvidia. AMD actualmente no tiene este doble camino de datos por lo q cuando la gente se pregunta pq una arquitectura rinde más que otra o pq los teraflops de una no son como los otros es entre otras cosas por esta serie de cositas que aunq sumen poco, pasito a pasito se convierten en grandes diferencias.

Xlooser escribió:- Antes veía absurdo medir en TF una posible unidad sólo para recorrer el BVH porque se supone que los TF marcan cálculo, pero ahora me pregunto ¿cómo funciona un "RT Core"?¿qué hace para saber si un rayo colisiona con un elemento? ¿Quién calcula el ángulo de entrada del rayo? ¿y el de salida que se convierte en el de entrada para un nuevo rebote? Honestamente, no tengo ni idea. Si eso lo hacen unidades "RT Core" y además se pueden usar como Shaders si no se quiere RT, el diseño es cojonudo. Aunque si es tan bueno...........toda la GPU tendría esa disposición.

Como he dicho en mi mensaje anterior, lo realmente intensivo, lo jodido en raytracing es calcular las intersecciones de un rayo con la geometría de la escena. Y pq es esto así?. Primero pq cada vez que lanzas un rayo, ese rayo tiene que "probarse" con todos los triángulos de toda la geometría de la escena (por cada rayo!!!!), y segundo no hay una coherencia en los datos que ayude en el proceso.

Qué se hace para aliviar este problema?. Se discretiza, se usan estructuras de datos jerárquicas que agrupen la geometría de la escena en pequeños paquetes de triángulos que sean mas manejables y a su vez los "envuelven" en "volúmenes mas grandes" y así sucesivamente, estos "volúmenes mas grandes" los agrupan y los "envuelven en "volumenes mas grandes"...asi hasta obtener un único volumen que agrupe a todo. Ahora puedes iterar sobre esta estructura de forma que si un rayo no interseca un "volumen" que contiene todos los paquetes de niveles inferiores, puedes descartar todo lo q esté dentro de ese volumen. Esto hace q realices muchas menos comprobaciones y por tanto ahorres trabajo. Nvidia usa un BVH (Bounding volume hierarchy), que hace justamente lo q digo anteriormente.

Un RT Core acelera este proceso haciendo fundamentalmente 2 cosas: la primera es comprobar si un rayo interseca con los volúmenes que se han construido anteriormente, descartando jeráquicamente todo lo q "cuelgue" de dicho volumen hasta que se "queda" con un paquete de triángulos. La segunda es, una vez determinado dicho paquete de triángulos, comprobar uno por uno si el rayo impacta con alguno de ellos y "lo devuelve".

Un shader es el encargado de iniciar el proceso (es el q lanza el rayo desde donde quiere y con la dirección que quiere), le dice a los RT Cores: tio este rayo con quién impacta?. Una vez tiene esa información se "programa" qué hacer con ella, desde usarla para calcular el color, o la distancia o lanzar otro rayo desde el punto de intersección del rayo anterior...

Puesto que todo el proceso de calcular la intersección de un rayo con la geometría se hace aparte (y lleva su tiempo), el shader que ha lanzado el rayo puede dedicarse a hacer otras tareas (solapamiento de tareas).

darksch escribió:Bueno pues sabiendo que si trabajan en paralelo, a pensar en que otras opciones de optimización pueden andar.

- Scheduler que ayude a paralelizar mejor, para no depender totalmente del programador.
- Usar eSRAM (o la RAM) para almacenar una estructura simplificada, esto claro lo haría el compilador transparente al desarrollador, para no volver a caer en el error de lo específico, para hacer el recorrido de los rayos más basto en dicha estructura, y así luego los RT Cores sólo lo harían en detalle en un nivel más reducido.

Sugerencias?

Ya lo han hecho, échale un ojo a lo q pongo justo arriba.

Un saludo.

Eaniel Kashal escribió:Que haya llegado el dia en que eche de menos las cosas de indigo ...

Ni tanto , ni tan calvo . Todos los extremos y/o excesos son malos , debería haber un equilibrio.

Ahora estamos en el extremo del coñazo

PD: me quedé sin mensajes por hoy

@NosferatuX

No tengo que esperar a nada . Por eso le mandé un MP a N-N , para poder hacer otro para la gente de patio y que vosotros podáis aquí seguir con lo vuestro .

Claro , lo sencillo es no entrar , pero como la gran mayoría seguramente que cuando ve un nuevo mensaje entra para ver si es algo interesante. No hay más narices que entrar para ver si lo es o no

@TCR

No se tacho de loco a nadie . Todos sabemos por que lo babearon y todos , el 99% estábamos de acuerdo de que había sobrepasado el límite . No es justo decir ahora lo contrario

@Xlooser

Eres más inteligente que todo eso . Seguro que me has entendido perfectamente

THANOS-TITAN-Z escribió:De verdad. Próxima parada ingenieros de la NASA . Le mande un MP @N-N para ver si se puede crear un hilo exclusivamente para Scarlet , con lo básico para los que no entendemos y no nos interesan tanto los técnicismos .

Por ejemplo : Tendrá 11 TFLOP

No me interesa si el SSD se tira a la GPU por parte de madre a la CPU por culpa de los Rops

Pues te esperas a que Vandal lo diga cuando se sepa y ya esta, porque la mayoria de webs se quedaran con ese dato y ya.
A mi si me interesa todo el entramado de las arquitecturas, eficiencia y demas, los Teraflops son como los bits de hace 30 años, para que se peguen en los foros. (o en el patio!!)

Eaniel Kashal escribió:Que haya llegado el dia en que eche de menos las cosas de indigo ...

Se le tachó de loco por insistir en que tendría RT y mira...

Padre nuestro!traenos a Indigo.Necesitamos mas Extasis

Vale, creo que es la palabra shader la que lleva a confusión, me refiero a las ALUs que hasta ahora conocemos, las INT y FP32, las matriciales son nuevas. Los Tensor Core, aparte de ser impresionantes, sólo añaden dependencia de datos, con lo que no bloquean las demás ALUs, entendido.


Me refiero a que el RT Core de algún modo determina si el rayo colisiona, supongo que no será porque sí y hará cálculos en base al ángulo de entrada. Ya sean cálculos en FP32, FP16 o FP8 se podrán medir en TF y, como dice algún rumor, se podrá usar esa capacidad para otra tarea.


@THANOS-TITAN-Z qué poca tolerancia, que no te guste un tema no quiere decir que sobre en el foro, que es lo que quieres dar a entender. Según lo que dijiste tú, el hilo que deseas sólo tendrá un post "11 TF" y se podrá cerrar.

Hola a todos!!! Feliz Domingo!

Ya conocemos la duración de la conferencia de Xbox en el E3 2019



Ya conocemos la duración de la conferencia de Xbox en este E3 2019. La cifra sale del canal oficial de youtube de Xbox Brasil y resulta bastante más larga de lo que hemos visto estos últimos años por parte de Microsoft en el E3. Recientemente se filtró lo que podía ser esa conferencia y todos los anuncios que se llevarían a cabo, algunos más probables que otros, pero desde luego la duración que hoy se ha hecho oficial sería bastante acorde a la gran cantidad de anuncios, demos y juegos que se verían según la filtración que os enseñamos hace unos días.
 
La duración de la conferencia de Xbox en el E3 2019 será de 120 minutos, dos horas para ser más generales. La conferencia comenzará el 9 de junio a las 22:00 y (según estos datos) terminará a las doce de la noche. La hora local es de la 1:00 p. m. PDT del domingo 9 de junio, por si queréis hacer los cálculos en vuestros horarios locales.
 
Dos horas dan para mucho y más si lo comparamos con la duración de las anteriores conferencias de Xbox en el pasado ya que la de 2016 duró 90 minutos, la de 2017 duró 95 minutos y la del año pasado llegó a los 100. Ya la conferencia de 2018 se consideró por unanimidad como la mejor de todo el E3 por su ritmo y cantidad de anuncios, así que este año puede que Microsoft consiga superarse a si misma y brindarnos un E3 de lo más espectacular. ¿Cuáles son vuestras apuestas? ¿Os parece correcta esta duración?

Fuente:
https://www.somosxbox.com/duracion-conf ... 019/820753

@THANOS-TITAN-Z no es por el baneo, que el motivo como bien dices fue otro, sino por la insistente persecución que había con él.

Que todos sabemos que a veces se excedía y parecía un loro pero tampoco hacía daño. Los spoilers son otro tema, ahí nada que decir.

Que conste que a mí el hilo me gusta. Hay cosas interesantes, otras entretenidas y otras que leo por encima por desinterés y en ese sentido, dentro de esa variedad, el muchacho no era diferente al resto en cambio casi todo eran quejas.

Dicho esto prosigan.

TCR escribió:@THANOS-TITAN-Z no es por el baneo, que el motivo como bien dices fue otro, sino por la insistente persecución que había con él.

Que todos sabemos que a veces se excedía y parecía un loro pero tampoco hacía daño. Los spoilers son otro tema, ahí nada que decir.

Que conste que a mí el hilo me gusta. Hay cosas interesantes, otras entretenidas y otras que leo por encima por desinterés y en ese sentido, dentro de esa variedad, el muchacho no era diferente al resto en cambio casi todo eran quejas.

Dicho esto prosigan.

Vamos por la pagina 88 y es la primera vez que lo digo . Creo que no he matado a nadie . Yo digo de hacer como el Hilo de Xbox , que esa era mi idea cuando lo cree y después otro parecido al de poder de la nube como hubo en aquel entonces . No creo que plantear eso sea malo

THANOS-TITAN-Z escribió:@Xlooser

Eres más inteligente que todo eso . Seguro que me has entendido perfectamente

Es un coñazo para una gran parte de los lectores, pero tiene sitio. Seguro que hay también bastantes que agradecen estas divagaciones.

Pues a mí me parece que el hilo está mejor que nunca. Y eso que en mi caso es como si estuviese todo en chino mandarín.

Indigo tendrá sus defectos, pero es buen tio, es como un valverde pero flipandose un poco.

Xlooser escribió:

THANOS-TITAN-Z escribió:@Xlooser

Eres más inteligente que todo eso . Seguro que me has entendido perfectamente

Es un coñazo para una gran parte de los lectores, pero tiene sitio. Seguro que hay también bastantes que agradecen estas divagaciones.

Tiene sitio y me parece perfecto. Por eso si me dejan hacer otro seguiréis teniendo vuestro sitio Tanto los que sabéis y como los que no , que aún así lo ven bien

Yo lo único que sé, es que cada vez que hay un tema interesante de lo que sea, se crea un hilo aparte para no molestar en este y al final hay 20 hilos en los que nadie entra y este se queda vacío también porque ya hay un hilo para esto, un hilo para aquello..... Se trata de unificar, no de dividir en hilos infinitos.

No creo que haya problema en crear otro del estilo “Anaconda sin chip gordo ni tecnicismos”. Aunque creo que tendría pocas entradas, aparte de lo que ya se sabe de 2 modelos y TF aproximados, no hay más que decir. De haberlo se hubiera puesto ya aquí y no se ha puesto nada más.

Xlooser escribió:

THANOS-TITAN-Z escribió:@Xlooser

Eres más inteligente que todo eso . Seguro que me has entendido perfectamente

Es un coñazo para una gran parte de los lectores, pero tiene sitio. Seguro que hay también bastantes que agradecen estas divagaciones.

De hecho yo solo entro por las pajas mentales.

@THANOS-TITAN-Z

Buenas tardes, creo que el comentario de @darksch lo resume muy bien:

darksch escribió:No creo que haya problema en crear otro del estilo “Anaconda sin chip gordo ni tecnicismos”. Aunque creo que tendría pocas entradas, aparte de lo que ya se sabe de 2 modelos y TF aproximados, no hay más que decir. De haberlo se hubiera puesto ya aquí y no se ha puesto nada más.

Yo entiendo que más de uno (yo me incluyo) nos perdamos cuando se entra en ciertos tecnicismos pero no creo que abrir un nuevo hilo sea la solución (al menos por ahora).

Un saludo.