mitardo escribió:Keihanzo escribió:Para usar el sentido común no se necesita el poder de la nube.
Si tu lo dices... yo te creo, amigo Sandro.chris76 escribió:Asi es,no hay mas,el problema es que todos queremos una consola gamer y ms contruyo otra cosa,y aqui la mayorio se niega a ver la realidad
Todos ? Yo sabia perfectamente que me compré. Si tu no lo sabias no lo extrapoles a los demás.
P.D : No se que es peor si los videntes que tienen micrófonos en las salas de juntas de Microsoft o los que se miran el ombligo y ven todo el universo conocido.
dicanio1 escribió:Mira que el hilo esta bien para ir aprendiendo cosas aunque sobre la xbox nadie puede llegar a saber que nos vamos a encontrar en un futuro por lo compleja que es... pero estos últimos días da pena entrar y leer a algunos que vienen a lo que vienen..
GROCKEVOR escribió:dicanio1 escribió:Mira que el hilo esta bien para ir aprendiendo cosas aunque sobre la xbox nadie puede llegar a saber que nos vamos a encontrar en un futuro por lo compleja que es... pero estos últimos días da pena entrar y leer a algunos que vienen a lo que vienen..
No solo no sabemos qué nos vamos a encontrar por lo compleja que es la consola, y qué será capaz de ofrecer dicha máquina, si no también por lo "complejos" que son los propios responsables de ella. Me refiero a sus movimientos, rectificaciones, cambios de rumbo... Y yo que sé. Qué es lo que quieren, o intentan hacer de ella? En un principio, la idea, era tener un sistema multimedia completo, junto a un dispositivo que sería muy importante y añadiría muchas funcionalidades extras a la consola. Después, ya no pretenden ser tan multimedia, y sí una videoconsola de juegos en toda regla. Ahora, ese dispositivo tan importante, ya no lo es tanto, hasta el punto que ya van a vender la propia consola sin él.
Entonces... Se centrarán exclusivamente en que ONE sea una videoconsola, dejando a un lado muy secundario lo multimedia, o ambos aspectos los trabajarán bien? Kinect ya pasa a ser algo muy secundario y prescindible, o no se olvidarán de él, y demostrarán, con el paso del tiempo, que sigue siendo una parte muy importante de la consola?
Qué nos vamos a encontrar... Qué nos vamos a encontrar!!!
Stylish escribió:Creo que ya comprendo bastante bien la arquitectura de One. Y sigo pensando, ¿qué ganan con respecto a la competencia? Incluso bien aprovechada no van a ser (mucho) más potentes, y ni siquiera han salido al mercado a menor precio. Lo único que han conseguido es forzar a todo el mundo a aprovechar y adaptarse a su arquitectura en lugar de seguir con el know-how que ya tenían, teniendo además la rémora de parecer menos potentes al principio de la generación y pinchar ventas gracias a eso y al sobreprecio de Kinect.
Vería sentido a este planteamiento sólo bajo dos supuestos: si fueran 100€ más baratos que la competencia o que fueran ostensiblemente más potentes.
La pregunta que hay que responder no es ¿cómo? sino ¿por qué?
Stylish escribió:Creo que ya comprendo bastante bien la arquitectura de One. Y sigo pensando, ¿qué ganan con respecto a la competencia? Incluso bien aprovechada no van a ser (mucho) más potentes, y ni siquiera han salido al mercado a menor precio. Lo único que han conseguido es forzar a todo el mundo a aprovechar y adaptarse a su arquitectura en lugar de seguir con el know-how que ya tenían, teniendo además la rémora de parecer menos potentes al principio de la generación y pinchar ventas gracias a eso y al sobreprecio de Kinect.
Vería sentido a este planteamiento sólo bajo dos supuestos: si fueran 100€ más baratos que la competencia o que fueran ostensiblemente más potentes.
La pregunta que hay que responder no es ¿cómo? sino ¿por qué?
BladneiR escribió:HispaCoder escribió:Entonces, se supone que cuando saquen un juego programado para PC, bajo directx 12, será muy facil portarlo a One (en 1 o 2 días!!!??) Si esto es cierto... sería la bomba entiendo no? porque vale, al final para One irá recortado respecto al PC, pero la versión de PC es la más completa y facil de hacer de primeras (hablo desde la ignorancia), y de esta forma practicamente los desarrollos de PC y One urían de la mano no?
No. No es tan fácil como nos quieren hacer creer.
Polyteres escribió:Buenas gente. @Stylish espero q la compresión del hardware de XboxOne no la hayas conseguido después de leer el artículo que han puesto más arriba. Si es así, es erróneo.
Un saludo.
Zokormazo escribió: Otro tema sera el tweaking y optimizacion para sacarle todo a la consola. Eso probablemente necesitara mas tiempo.
Polyteres escribió:Buenas gente. @Stylish espero q la compresión del hardware de XboxOne no la hayas conseguido después de leer el artículo que han puesto más arriba. Si es así, es erróneo.
Un saludo.
Te he visto asegurar q Xbox One monta una 7790, q no sería full Dx12 y q no estaba pensada para ello, q no tiene arquitectura de supercomputación. Eso sí, sin aportar ningún solo dato.
mitardo escribió:Zokormazo escribió: Otro tema sera el tweaking y optimizacion para sacarle todo a la consola. Eso probablemente necesitara mas tiempo.
Con suerte dicha tarea las hace DX12. A fin de cuenta las DX no son mas que unas librerías que intentan usar el 100% del hardware que ya tienes.
Lo único que se me ocurre que Microsoft realmente tenga un "plan" para que los ports entre sus plataformas (pc y Xbox juan) sean realmente eficientes y pongo como ejemplo la Xbox Original que recibía ports de buena calidad en tiempos bastante cortos en comparación con su sucesora.
Szasz escribió:Buenas Polyteres. No se si tienes una cruzada personal con flashbackman360, algunos mensajes cruzados q habéis tenido en los dos foros lo parece.
Me gustaría saber cual es la visión adecuada de el hardware de One. El estilo pantene(por q yo lo valgo) no suele ir conmigo y me gusta informarme y buscar datos. ( sin animo de ofender)
Probablemente en la información q da flash haya datos erróneos y no sea veraz al 100%. Sin embargo, tú tampoco estas exento del error y por lo tanto de la desinformación.
Te he visto asegurar q Xbox One monta una 7790, q no sería full Dx12 y q no estaba pensada para ello, q no tiene arquitectura de supercomputación. Eso sí, sin aportar ningún solo dato.
No voy a poner en duda tu conocimiento, porque se que lo tienes. Pero considero, que tus conocimientos en arquitecturas(ya no hablar de nuevas arquitecturas) son limitados y por supuesto, carentes de verdades absolutas.
Dicho esto, no demos cosas por sentadas y esperemos a los acontecimientos. Porque solo el tiempo, dara o quitara la razón.
P.D: Por sino lo sabías, Microsoft contrato a ingenieros de IBM e Intel y dispone de dos centros gigantescos de supercomputación. Los avances no han sido pequeños.
Cuanto menos, la posibilidad existe.
Un saludo
darksch escribió:Te he visto asegurar q Xbox One monta una 7790, q no sería full Dx12 y q no estaba pensada para ello, q no tiene arquitectura de supercomputación. Eso sí, sin aportar ningún solo dato.
No me lo creo. Espero que no sea cierto porque entonces me perdería la credibilidad, ciertamente. Me parecería más de alguien que le gusta meter tecnicismos para liar a la gente para decir lo que le venga en gana, y a conveniencia.
Es decir, que los propios ingenieros de M$ dicen que el hardware está hecho en base al paralelismo del DX12 y "no estaba pensada para ello", también dicen que está basada en arquitectura de super-computación (por el GPGPU + buses + eSRAM), y " no tiene arquitectura de supercomputación".
Venga ya hombre, no creo que se llegue a eso.
Zokormazo escribió:Ni en los sueños mas humedos una API te va a sacar todo el provecho posible de una consola.
eloskuro escribió:Por cierto. Halo 5 va a estar desarrollado con un moto grafico hecho desde 0 para el hardware de xbox one. He entendido que llevan 3 años haciendolo.
Szasz escribió:Esto dijo antes del tweet confirmando full Dx12:
"Buenas gente. no, no hemos llegado a la misma conclusión. No pienso que el hardware de One sea específico para DirectX 12, ni que esté optimizado para ello, pq el hardware es el que es y una API lo único q hace es darle soporte no al revés. One mejorará como todas las consolas han hecho a lo largo de su ciclo de vida independientemente de la salida de una API para PC. Un saludo."
He leido ya varias veces lo de optimización de microcódigo...paralelismo...doble precisión...wooow como suena, tiene q ser la leche.
Por partes. Si nos centramos en Ms, q es lo q nos importa, la GPU de Xbox360 por la arquitectura que tenía (q era muy buena por otra parte), era muy sensible a las instrucciones que estabas ejecutando. Que quiere decir esto?. Pues q depende del orden en el que ejecutaras las instrucciones, depende de las dependencias que hubiera entre ellas, depende incluso del tipo de instrucciones que estuvieras ejecutando, el aprovechamiento de la GPU podia ser o muy bueno o irse al carajo pero de forma brutal. Era una arquitectura muy muy sensible a las operaciones y si querías obtener el máximo rendimiento tenías q hilar muy fino.
AMD sacó nuevas versiones de sus tarjetas basadas en VLIW 4 y 5. Este tipo de arquitectura tb es muy sensible al microcódigo de hecho casi más. En este caso el orden en el q ejecutes las instrucciones es vital.
Para poder optimizar el uso del hardware y hacer q rinda mucho mas proximo a su pico máximo teórico, AMD sacó una nueva arquitectura, la famosa GCN. GCN es completamente diferente a lo q había hecho hasta ahora AMD. A groso modo está formada por un número variable de Compute Units, un número variable de ROPs un número variable de ACEs y un command proccessor.
Que es una CU y pq está formada?.
Una CU es el corazón de la arquitectura GCN, es dnd se hace el proceso con los datos. Está formada por:
- 4 unidades SIMD de 16 elementos cada una. Que es una unidad SIMD?. Una unidad q es capaz de procesar una única instruccion sobre muchos datos (Single Instruction Multiple Data), las ALUs de las q todo el mundo habla. Al tener 4 de 16 tenemos 64 por CU. Son capaces de hacer muchas instrucciones (suman, restan, multiplican, dividen...) y sobre muchos tipos de datos (enteros, float, double...). Cada instrucción tarda un número de ciclos. A más jodida es (no es lo mismo una suma que una división) más ciclos tarda, a más precisión tenga el dato(single o double)...mas ciclos tarda. Como máximo puede hacer una instrucción MADD por ciclo de reloj (2 operaciones por ciclo. Una instrucción MADD es una multiplicación seguida de una suma (muy importante en gráficos). Por tanto si queremos calcular los FLOPs teóricos tenemos:
4 SIMD x 16 ALUs por SIMD x 2 operaciones por ciclo x 12 (numero de CUs) x 853 MHz (numero de ciclos) = 1.31TFlops.
Eyyy los números empiezan a cuadrar si como nos han dicho están basados en Sea Island. Si, pero es q hay más. Veremos pq, si estamos BASADOS en Sea Island no hay 128ALUs por CU o pq no hay 64 SP + 64 DP, pq sería incluso perjudicial.
- Una unidad de salto: para resolver instrucciones de salto. Se usan bastante en programación pueden ser por ejemplo para iterar en un bucle o condiciones de tipo, si pasa esto haz aquello.
- Una unidad escalar: solo se usa para operaciones escalares. Es otra ALU q opera con un único dato a la vez.
- 4 buffers de instrucciones (uno por cada SIMD): podemos guardar hasta 10 Wavefront (un wavefront es un grupo de 64 hebras)
- Un chorrazo de registros, de hecho hay 64KB por cada SIMD, es decir 4x64KB de registros. Este número no es casual y tiene que ver con la cantidad de hebras simultáneas q podemos tener en paralelo ejecutándose, y tiene relación directa con el número de ALUs y con el número de Wavefront.
- 64KB de una memoria local se usa para sincronización y compartición de datos entre las distintas SIMD.
- 16KB de caché.
- 4 TMUs (unidades de textura).
- Un planificador de hebras (automático oiga, para poder manejar todo el tinglado del paralelismo sin sudar y de forma automática).
Primera sorpresa: Ni en gráficos ni en tareas de GPGPU (relacionadas con juegos, no computación científica o simulación atmosférica o física cuántica de partículas ) la doble precisión es importante o se usa. No se necesita la precisión q te brinda tener datos de 64 bits de ancho. Tiene muchíiiiiisimos problemas y se evita siempre usarlos. Uno de ellos es q se tarda mucho mas en hacer una operación, otro problema importante el ancho de banda q necesitas se dispara.
Curioso q XboxOne tenga 64 ALUs solo para DP cuando no las va a usar ni siquiera en tareas de GPGPU, o cuando el ancho de banda de tus buses van a sufrir como perros para mantener dichas CUs trabajando. Mas curioso es aún cuando a Ms se le ha llenado la boca de decir optimización, recursos, COMPRESIÓN, ahorro en los datos...y luego lo tiras todo por la borda poniendo esto...claro muy lógico, y repito cuando no lo necesitas ni lo vas a usar.
Pero es q si seguimos...pq dividir en 2 tipos de ALU tus CU en 64 y 64?. Si las ALUs que tienes de SP tb son capaces de hacer trabajo con DP, como lo son...pq no pones mejor 128 ALUs con toda la capacidad y sea yo quien decida que utilizar en cada momento según me convenga?. O sea q me capas a 1.31TF en SP y me das otros 1.31TF en DP y si no uso DP para nada, o si quiero usar mas SP?. No tiene sentido.
Por otra parte, los registros al ser para datos de 32 bits tendrías la mitad. Si no es así y has metido registros específicos de 64 bits en mismo número q los de SP tendrias cada CU del tamaño de la palma de la mano y no se verían las famosas rallitas es q serían monstruosas respecto a una CU Sea Island.
Pero seguimos...el buffer de instrucciones q tienes dnd guardas hasta 10 wavefront es de 64 hebras si tienes q meter trabajo de SP y DP el número de hebras simultáneas que una CU va a poder manejar va a descender de forma alarmante y esto a su vez va a hacer q puedas aprovechar menos el hardware!.
Pero es q si haces todos esos cambios...ya no eres una arquitectura basada en Sea Island, es q directamente eres otra arquitectura totalmente diferente.
Os acordáis de lo q he dicho del microcódigo no?. Pq no pasa en la arquitectura GCN?. Pq cuando un grupo de hebras se tiene q parar por ejemplo para esperar una textura, el planificador de la CU es capaz de coger este grupo, "quitarlo" del SIMD en el q se está ejecutando, guardar todos los datos en los registros de ese SIMD y ejecutar otro wavefront, ocultando las latencias, siendo menos sensible a como ordenes las intrucciones es decir, es mucho menos sensible al microcódigo, y se mejora muchísimo el aprovechamiento.
Que sería mejor?. Meter mas SIMD de 16 ALUs cada uno pudiendo aumentar el entrelazado y por tanto el pico de aprovechamiento?. O meter mas ALUs por SIMD pudiendo entrelazar menos y teniendo más parada la CU?. Se responde solo.
Tanto esto como el paralelismo dentro de una GPU es algo inherente al hardware, a la arquitectura GCN de AMD (tb funcionan asi las Nvidia no es exclusivo) no es algo propio y exclusivo de XboxOne ni es algo q tenga q ver con DirectX12.
Buenas gente. No, no me has entendido y sigues poniendo en mis dedos cosas que yo no he escrito. Microsoft empezó a desarrollar su consola hace mucho tiempo, tanto q ni siquiera sabía q iba a tener DirectX 12, pero es q por otra parte lo vuelvo a repetir, el software da soporte al hardware no al revés. Si no lo entiendes no puedo hacer mucho mas.
XboxOne tiene su propia API, la cual mejoran con cada iteración. De aquí a 2016 q es cuando se verán los primeros juegos con DirectX 12 espero q Microsoft haya mejorado la API de XboxOne significativamente, por el bien de XboxOne.
xBacix escribió:Se nota que Polyteres entiende del mundo de la programación. Sus post se respetan porque habla y contesta de manera educada y desde sus conocimientos. Lo que no me gusta es que solo se pase por aquí o por los hilos de Xbox One a bajar los humos de las características de la One.
Polyteres escribió:Szasz escribió:Esto dijo antes del tweet confirmando full Dx12:
"Buenas gente. no, no hemos llegado a la misma conclusión. No pienso que el hardware de One sea específico para DirectX 12, ni que esté optimizado para ello, pq el hardware es el que es y una API lo único q hace es darle soporte no al revés. One mejorará como todas las consolas han hecho a lo largo de su ciclo de vida independientemente de la salida de una API para PC. Un saludo."
Buenas gente. Y lo sigo pensando. El hardware es el q es, y las APIs le dan soporte, no al revés. Otra cosa diferente son las especificaciones iniciales que tu quieres q tenga el hardware cuando lo diseñas, es decir lo q pueda hacer. Primero se hace el hardware (con unas especificaciones) y luego el software no al revés. Tb dije que si XboxOne es compatible con DirectX 12 es muy probable que toda la familia Sea Island tb lo sea como creo q así lo han dejado entrever. Sigo pensando que DirectX 12 tiene más cambios a nivel de driver/OS que a nivel de arquitectura hardware, veremos. En todo caso es mi opinión y no tengo pq pedir perdón por ella.
@antonio @Chifrinillo con respecto al artículo de pq es erróneo hay q bajar a un nivel bastante bastante profundo de cómo funciona realmente una GPU y sobre todo como funciona explicitamente la arquitectura GCN (ya sea 1.0 o 1.1 familia Sea Island en las q están basadas según la famosa entrevista).
Había escrito un megaultra-tochaco inmenso (pero inmenso de verdad jajaja) de como funciona un driver, el OS, una API, una GPU a bajo nivel y como lo hacen las GPU de AMD con arquitectura GCN pero al leerlo me he dado cuenta q me he pasado jajaja. Asiq he escrito otro megatocho pero contesto mas concretamente al artículo:He leido ya varias veces lo de optimización de microcódigo...paralelismo...doble precisión...wooow como suena, tiene q ser la leche.
Por partes. Si nos centramos en Ms, q es lo q nos importa, la GPU de Xbox360 por la arquitectura que tenía (q era muy buena por otra parte), era muy sensible a las instrucciones que estabas ejecutando. Que quiere decir esto?. Pues q depende del orden en el que ejecutaras las instrucciones, depende de las dependencias que hubiera entre ellas, depende incluso del tipo de instrucciones que estuvieras ejecutando, el aprovechamiento de la GPU podia ser o muy bueno o irse al carajo pero de forma brutal. Era una arquitectura muy muy sensible a las operaciones y si querías obtener el máximo rendimiento tenías q hilar muy fino.
AMD sacó nuevas versiones de sus tarjetas basadas en VLIW 4 y 5. Este tipo de arquitectura tb es muy sensible al microcódigo de hecho casi más. En este caso el orden en el q ejecutes las instrucciones es vital.
Para poder optimizar el uso del hardware y hacer q rinda mucho mas proximo a su pico máximo teórico, AMD sacó una nueva arquitectura, la famosa GCN. GCN es completamente diferente a lo q había hecho hasta ahora AMD. A groso modo está formada por un número variable de Compute Units, un número variable de ROPs un número variable de ACEs y un command proccessor.
Que es una CU y pq está formada?.
Una CU es el corazón de la arquitectura GCN, es dnd se hace el proceso con los datos. Está formada por:
- 4 unidades SIMD de 16 elementos cada una. Que es una unidad SIMD?. Una unidad q es capaz de procesar una única instruccion sobre muchos datos (Single Instruction Multiple Data), las ALUs de las q todo el mundo habla. Al tener 4 de 16 tenemos 64 por CU. Son capaces de hacer muchas instrucciones (suman, restan, multiplican, dividen...) y sobre muchos tipos de datos (enteros, float, double...). Cada instrucción tarda un número de ciclos. A más jodida es (no es lo mismo una suma que una división) más ciclos tarda, a más precisión tenga el dato(single o double)...mas ciclos tarda. Como máximo puede hacer una instrucción MADD por ciclo de reloj (2 operaciones por ciclo. Una instrucción MADD es una multiplicación seguida de una suma (muy importante en gráficos). Por tanto si queremos calcular los FLOPs teóricos tenemos:
4 SIMD x 16 ALUs por SIMD x 2 operaciones por ciclo x 12 (numero de CUs) x 853 MHz (numero de ciclos) = 1.31TFlops.
Eyyy los números empiezan a cuadrar si como nos han dicho están basados en Sea Island. Si, pero es q hay más. Veremos pq, si estamos BASADOS en Sea Island no hay 128ALUs por CU o pq no hay 64 SP + 64 DP, pq sería incluso perjudicial.
- Una unidad de salto: para resolver instrucciones de salto. Se usan bastante en programación pueden ser por ejemplo para iterar en un bucle o condiciones de tipo, si pasa esto haz aquello.
- Una unidad escalar: solo se usa para operaciones escalares. Es otra ALU q opera con un único dato a la vez.
- 4 buffers de instrucciones (uno por cada SIMD): podemos guardar hasta 10 Wavefront (un wavefront es un grupo de 64 hebras)
- Un chorrazo de registros, de hecho hay 64KB por cada SIMD, es decir 4x64KB de registros. Este número no es casual y tiene que ver con la cantidad de hebras simultáneas q podemos tener en paralelo ejecutándose, y tiene relación directa con el número de ALUs y con el número de Wavefront.
- 64KB de una memoria local se usa para sincronización y compartición de datos entre las distintas SIMD.
- 16KB de caché.
- 4 TMUs (unidades de textura).
- Un planificador de hebras (automático oiga, para poder manejar todo el tinglado del paralelismo sin sudar y de forma automática).
Primera sorpresa: Ni en gráficos ni en tareas de GPGPU (relacionadas con juegos, no computación científica o simulación atmosférica o física cuántica de partículas ) la doble precisión es importante o se usa. No se necesita la precisión q te brinda tener datos de 64 bits de ancho. Tiene muchíiiiiisimos problemas y se evita siempre usarlos. Uno de ellos es q se tarda mucho mas en hacer una operación, otro problema importante el ancho de banda q necesitas se dispara.
Curioso q XboxOne tenga 64 ALUs solo para DP cuando no las va a usar ni siquiera en tareas de GPGPU, o cuando el ancho de banda de tus buses van a sufrir como perros para mantener dichas CUs trabajando. Mas curioso es aún cuando a Ms se le ha llenado la boca de decir optimización, recursos, COMPRESIÓN, ahorro en los datos...y luego lo tiras todo por la borda poniendo esto...claro muy lógico, y repito cuando no lo necesitas ni lo vas a usar.
Pero es q si seguimos...pq dividir en 2 tipos de ALU tus CU en 64 y 64?. Si las ALUs que tienes de SP tb son capaces de hacer trabajo con DP, como lo son...pq no pones mejor 128 ALUs con toda la capacidad y sea yo quien decida que utilizar en cada momento según me convenga?. O sea q me capas a 1.31TF en SP y me das otros 1.31TF en DP y si no uso DP para nada, o si quiero usar mas SP?. No tiene sentido.
Por otra parte, los registros al ser para datos de 32 bits tendrías la mitad. Si no es así y has metido registros específicos de 64 bits en mismo número q los de SP tendrias cada CU del tamaño de la palma de la mano y no se verían las famosas rallitas es q serían monstruosas respecto a una CU Sea Island.
Pero seguimos...el buffer de instrucciones q tienes dnd guardas hasta 10 wavefront es de 64 hebras si tienes q meter trabajo de SP y DP el número de hebras simultáneas que una CU va a poder manejar va a descender de forma alarmante y esto a su vez va a hacer q puedas aprovechar menos el hardware!.
Pero es q si haces todos esos cambios...ya no eres una arquitectura basada en Sea Island, es q directamente eres otra arquitectura totalmente diferente.
Os acordáis de lo q he dicho del microcódigo no?. Pq no pasa en la arquitectura GCN?. Pq cuando un grupo de hebras se tiene q parar por ejemplo para esperar una textura, el planificador de la CU es capaz de coger este grupo, "quitarlo" del SIMD en el q se está ejecutando, guardar todos los datos en los registros de ese SIMD y ejecutar otro wavefront, ocultando las latencias, siendo menos sensible a como ordenes las intrucciones es decir, es mucho menos sensible al microcódigo, y se mejora muchísimo el aprovechamiento.
Que sería mejor?. Meter mas SIMD de 16 ALUs cada uno pudiendo aumentar el entrelazado y por tanto el pico de aprovechamiento?. O meter mas ALUs por SIMD pudiendo entrelazar menos y teniendo más parada la CU?. Se responde solo.
Tanto esto como el paralelismo dentro de una GPU es algo inherente al hardware, a la arquitectura GCN de AMD (tb funcionan asi las Nvidia no es exclusivo) no es algo propio y exclusivo de XboxOne ni es algo q tenga q ver con DirectX12.
Quizás siga este mensaje en otro momento e intente explicar más cosas pero de momento...me he cansado de escribir jajaja.
Un saludo.
Sergitos2 escribió:xBacix escribió:Se nota que Polyteres entiende del mundo de la programación. Sus post se respetan porque habla y contesta de manera educada y desde sus conocimientos. Lo que no me gusta es que solo se pase por aquí o por los hilos de Xbox One a bajar los humos de las características de la One.
Igual no baja los humos, igual es que por aquí los humos de las características están muy subidos
papatuelo escribió:@polyteresBuenas gente. No, no me has entendido y sigues poniendo en mis dedos cosas que yo no he escrito. Microsoft empezó a desarrollar su consola hace mucho tiempo, tanto q ni siquiera sabía q iba a tener DirectX 12, pero es q por otra parte lo vuelvo a repetir, el software da soporte al hardware no al revés. Si no lo entiendes no puedo hacer mucho mas.
XboxOne tiene su propia API, la cual mejoran con cada iteración. De aquí a 2016 q es cuando se verán los primeros juegos con DirectX 12 espero q Microsoft haya mejorado la API de XboxOne significativamente, por el bien de XboxOne.
Szasz escribió:papatuelo escribió:@polyteresBuenas gente. No, no me has entendido y sigues poniendo en mis dedos cosas que yo no he escrito. Microsoft empezó a desarrollar su consola hace mucho tiempo, tanto q ni siquiera sabía q iba a tener DirectX 12, pero es q por otra parte lo vuelvo a repetir, el software da soporte al hardware no al revés. Si no lo entiendes no puedo hacer mucho mas.
XboxOne tiene su propia API, la cual mejoran con cada iteración. De aquí a 2016 q es cuando se verán los primeros juegos con DirectX 12 espero q Microsoft haya mejorado la API de XboxOne significativamente, por el bien de XboxOne.
Bueno, parece q en el tema Dx12 al menos, estaba equivocado.
antonio613 escribió:Vamos a ver estamos diciendo que microsoft que ya ha dicho que One soporta full directX12 y un fulano de un foro dice que no.
Le hacemos caso al fulano microsoft miente.
Os vais a dar una hostia cuando salgan juegos como quantum break, halo 5, gears,...
No se que hacéis posteando en un foro cuando sabéis más que los ingenieros que hicieron la consola...
Sergitos2 escribió:xBacix escribió:Se nota que Polyteres entiende del mundo de la programación. Sus post se respetan porque habla y contesta de manera educada y desde sus conocimientos. Lo que no me gusta es que solo se pase por aquí o por los hilos de Xbox One a bajar los humos de las características de la One.
Igual no baja los humos, igual es que por aquí los humos de las características están muy subidos
Sergitos2 escribió:antonio613 escribió:Vamos a ver estamos diciendo que microsoft que ya ha dicho que One soporta full directX12 y un fulano de un foro dice que no.
Le hacemos caso al fulano microsoft miente.
Os vais a dar una hostia cuando salgan juegos como quantum break, halo 5, gears,...
No se que hacéis posteando en un foro cuando sabéis más que los ingenieros que hicieron la consola...
Hombre yo no lo sé, pero hoy por hoy como pa fiarse de lo que te diga Microsoft.
Nuhar escribió:Sergitos2 escribió:xBacix escribió:Se nota que Polyteres entiende del mundo de la programación. Sus post se respetan porque habla y contesta de manera educada y desde sus conocimientos. Lo que no me gusta es que solo se pase por aquí o por los hilos de Xbox One a bajar los humos de las características de la One.
Igual no baja los humos, igual es que por aquí los humos de las características están muy subidos
+1Sergitos2 escribió:antonio613 escribió:Vamos a ver estamos diciendo que microsoft que ya ha dicho que One soporta full directX12 y un fulano de un foro dice que no.
Le hacemos caso al fulano microsoft miente.
Os vais a dar una hostia cuando salgan juegos como quantum break, halo 5, gears,...
No se que hacéis posteando en un foro cuando sabéis más que los ingenieros que hicieron la consola...
Hombre yo no lo sé, pero hoy por hoy como pa fiarse de lo que te diga Microsoft.
-1
Ni tanto, ni tan calvo jajaja.
Y un respeto al fulano del foro que al menos esta expresando su teoría de forma educada y argumentandola, no es la primera ni la última vez que se destapa mentiras de una empresa, ¿o recordamos los 2 Tflops de ps3? Por decir una de las mayores salvajadas que se han dicho, pero vamos, que Microsoft con la X1 esta dando tantos bandanzos que yo al menos no me creo lo que me diga.
Veo que muestran cosas pero quiero verlas en la consola a ver si es verdad.
BladneiR escribió:...
BladneiR escribió:Para aplicaciones y juegos indies, sí, será más fácil llevarlos a Xbox One, pero en cuanto a grandes desarrollos (juegos triple A) de alta carga gráfica, no será tan sencillo como parece o como nos quieren hacen creer.
P. D.: No sé a que viene esa contestación tuya, llena de ironía y con cierto aire de superioridad, háztelo mirar, y sobre todo respeta las opiniones y la forma de pensar de los demás.
Saludos!!
Szasz escribió:eloskuro escribió:Por cierto. Halo 5 va a estar desarrollado con un moto grafico hecho desde 0 para el hardware de xbox one. He entendido que llevan 3 años haciendolo.
Ayer lo dije. Halo 5 + Dx12, se iría a 2015. Pero ahora tengo la duda de q vayan a mostrar material in game. Creo q nos quedaremos con CGI.
Polyteres escribió:@Szasz la diferencia entre lo q yo pienso y lo q piensa el autor de ese artículo es q yo soy más simple, es decir, me baso en lo q ha dicho Microsoft y no en la interpretación de lo q no ha dicho, buscando patentes y cosas raras para q cuadre. Que el dia de mañana Ms dice q XboxOne no lleva lo q lleva y lleva otra cosa pues perfecto me lo creeré de nuevo xD.
Un saludo.