Las librerías gráficas DirectX se actualizan cada cierto tiempo y, con ellas llegan una serie de mejoras en el rendimiento y la calidad gráfica de los títulos más punteros. Pero esta vez DirectX 12 no estará sola, ya que AMD ha creado su propia alternativa con Mantle, que asegura una mejor funcionalidad. ¿Qué ventajas tiene cada una? ¿Cómo se beneficiarán los PCs y las nuevas consolas de ello?
La primera arquitectura GPU compatible con Direct3D 12 (DirectX engloba muchas cosas) ya está en la calle y es Maxwell.
Y las consolas no se programan a bajísimo nivel. Utilizan API también. A ver si os creéis que los shaders se programan con el ensamblador de las GPUs. Eso sería una locura.
En agosto el nuevo OpenGL con bajos sobrecostes también será anunciado. Mantle desaparecerá como lágrimas bajo la lluvia. Aunque habrá servido como revulsivo para la modernización de las API gráficas.
#9 Donde se nota un mayor ancho de banda es en la fluidez, no en la calidad de imagen (directamente), dado que montan idéntico chip con idénticas capacidades, pero (incluso con la liberación de potencia de no reservar nada para usar kinect) con menos unidades de procesamiento. Y en el apartado cpu la xbox tiene una cpu más rápida, pero igualmente con menos unidades de procesamiento (la rapidez en este caso podría compensar en tareas que requieran más potencia de un procesador y penalizar tareas que requieran distribuír más la potencia entre todos los procesadores, aunque de nuevo la diferencia en la práctica apenas se va a notar entre las consolas). Quizá aprovechen para meter algo más de carga gráfica o elevar mínimamente la resolución, pero será casi inapreciable a estas alturas, donde unos millones de polígonos más no se notan o un buen filtro hace inapreciable perder miles de pixels de resolución. De todos modos, busca cualquier análisis del impacto de la velocidad de la memoria en apus amd y verás que efectivamente hay una ganancia sustancial de rendimiento al subir esta y por ende aumentar el ancho de banda disponible (o sea, la memoria hace de cuello de botella).
Xbox one contraataca la lentitud de la memoria poniendo una memoria intermedia ultrarápida que hace de caché (estrategia que se ha confirmado muy útil en otras consolas como gamecube, wii y xbox 360, y que se va a aplicar en futuras apus de amd para el mercado pc y servidores (eso si, con memorias más lentas y baratas, supongo que solo en el primer caso), pero la cantidad que han puesto no es suficiente para las necesidades de los programadores (también se quejaban de que era insuficiente en el caso de la 360, ojo, pero en aquel entonces la contienda era más pareja porque la play4 tenía un cuello de botella parecido en el acceso a los coprocesadores que integraba cell).
Una vez visto que técnicamente realmente la ps4 si que es más potente (lo único donde la xbox tendría ventaja real es que el chip de audio está separado y no consumiría recursos cpu, mientras que la ps4 lo tiene unificado con el resto, pero incluso así la ps4 tendría ancho de banda más que suficiente para que meter el audio no afecte al rendimiento), te digo que efectivamente, la capacidad de procesamiento es tal que salvo que hagan chapuzas programando se podrá conseguir prácticamente lo mismo en cuanto a cantidad y calidad con ambas consolas, pero que siempre va a ir un poquito más suave en la play. La baza de xbox one es kinect, y hasta ahora no han conseguido un juego que venda la consola por su uso con el kinect y que suponga un antes y un después en el desarrollo para este periférico. Justamente creo que esto se conseguirá con la llegada de los cascos de realidad virtual, donde el uso de mandos puede romper un poco la inmersión, pero para eso aún queda.
#8 Una api simplemente es una capa de abstracción que define acciones sobre lo que puede hacer el hardware. Si eres capaz de ejecutar lo que se supone que hacen esas llamadas con el hardware que tienes (o por software), aunque no esté específicamente diseñado para ello, ya es compatible con esa api. Imaginemos que hay una llamada para sacar la ropa de la lavadora y colocarla en una de estas secadoras con tensores que a la vez planchan y guardarla en el armario, todo de una tacada. Si tu hardware no tiene una secadora de estas, podría intentar simularla dejándola secar un rato y luego pasándole una plancha manual y luego doblándola y luego llevándola al armario. Hace el doble de pasos, usa tecnología "desfasada" y por lo tanto es más lenta, pero hace lo mismo y por lo tanto cumple con la api. O se puede hacer por software: el humano de turno, después de fregar a mano, retuerce la ropa pa escurrirla, la pone a secar, la alisa un poco con las manos, la dobla como puede y luego la guarda. La ropa queda arrugada, mojada y ha tardado mucho más todavía en realizar todo el proceso, pero el resultado es más o menos el pedido, y por lo tanto sería compatible con esa api.
A lo que voy es que el trabajo de soportar una api a menudo es cosa más de los drivers que del hardware subyacente. Solo que a menudo el coste de intentar hacer que un hard antiguo soporte un api nuevo es demasiado grande o imposible. En el segundo caso el ejemplo más claro es que las antiguas tarjetas gráficas con cálculo de iluminación y geometría fijos nunca podrán funcionar ni hacer lo que hacen las gpus programables actuales. En el primero están tarjetas que soportan la api X.0 y con actualizaciones de drivers son capaces de soportar la api X.y.
Como ejemplo claro, mantle solo es soportada por las últimas generaciones de apus y gpus, que son las que disponen de hardware que es permite hacer de manera fácil las cosas que mantle pide, y de paso es una api hecha a medida de sus apus, porque se encarga de minimizar el ancho de banda usado por las gráficas -que es su cuello de botella- y el overhead de la api: en lugar de darte una lista de 100 instrucciones para hacer ciertas cosas, que dan lugar a 100 peticiones, intercambio de datos y sincronización entre cpu y gpu, las agrupan y te dan una lista de 5 cosas que engloban a aquellas, minimizando la comunicación necesaria para desarrollar las tareas (entre otras optimizaciones).
#10
No me vengas a dar lecciones porque te has metido un churromerinismo de campeonato además de dar información errónea acerca de lo que hace Mantle.
Mantle estrictamente hablando reduce los sobrecostes de la CPU, nada más. Y a día de hoy tarjetas NVIDIA con cpus Intel rápidas obtiene el mismo rendimiento que tarjetas AMD con Mantle.
Donde Mantle va bien es cuando se tienen CPUs poco potentes.
#11 ¿Qué es lo que he dicho yo arriba? eso mismo. Y cito "porque se encarga de minimizar el ancho de banda usado por las gráficas -que es su cuello de botella- y el overhead de la api". Si te piensas que la cantidad de instrucciones de la cpu a la gpu (el overhead, sobreuso de cpu en simular aspectos de apis antiguas/desfasadas o llamadas indirectas o repetitivas a cosas que una gpu puede hacer de manera más fácil y mejor) no afectan al ancho de banda (aumentando las latencias, ocupando espacio en los buses, redundancia de datos en memoria para poder hacer operaciones entre ellos) es porque no estás entendiendo nada de lo que digo.
Ahora... ¿qué información errónea he dado sobre mantle? ¿por qué no me corriges?
¿y por qué mezclas churras con merinas? ahora mismo estás comparando amd con mantle con nvidia con procesadores intel sin venir a cuento solo para (no) explicar que las últimas versiones de otras apis ya disponen de optimizaciones similares y/o que otro hardware por potencia bruta es superior (y desde que salieron las apus, cualquier dedicada y cualquier procesador de gama media ya las superaban holgadamente, desde que se anunciaron las consolas de nueva generación ya se sabía que tendrían la potencia de un portátil por el hardware que iban a llevar, desde antes de que se anunciara mantle ya existía un debate en la comunidad opengl sobre el overhead que llevaba la api encima y lo ineficiente que podía llegar a ser en algunos casos). ¿No es más justo, fácil y COMPARABLE algo así como amd con mantle vs sin mantle? (porque no podemos comparar nvidia sin mantle vs nvidia con mantle o un ganancias de nvidia con mantle vs ganancias de amd con mantle)
#11 Aparte de que una cosa es la programación de shaders y otra cosa es meter una api compleja de por medio. Como bien sabrás, los shaders se compilan y se "cargan" en la tarjeta, pero es como cualquier otro lenguaje, si sabes lo que escribes puedes hacerlo a pelo y/o realizar optimizaciones específicas para tu hardware concreto (y dado que una consola es un hard cerrado, mejor que un compilador generalista que funciona sobre una amplia gama de hardware, buscas lo que más eficiente haga tu código; evidentemente en los sdk de las consolas habrá un compilador que las estruje todo lo posible). Luego, aparte de los shaders, está el resto de la api. No creo que en consolas encuentres un d3d o un opengl completo, como mucho parte de una implementación que se ajuste a tu hardware, quitando toda parte que sea "compatibilidad con versiones anteriores" o "características que no monte tu hardware". Incluso así, hay compañías que se crean sus propias herramientas, o sea, trabajan sobre el metal a pelo (el soporte y optimización de motores de middleware tipo unreal/unity/cryengine para consolas debe ser lo más eficiente posible, basan su prestigio en eso).
Todo esto es para decirte que si, que la gran mayoría de los programadores no usan hard a pelo por la sencilla razón de que usan middlewares que ya les solucionan la papeleta, ni siquiera tiran de apis, usan frameworks ya hechos y dedican sus esfuerzos al scriptado y programación de otras cosas mientras le dejan el trabajo de diseñar shaders, texturas y escenarios a diseñadores. Pero los que realmente trabajan en motores propios de algo de nivel si que lo hacen, por mucho que a ti te parezca una burrada, lo mismo con los ingenieros de gráficos que luego optimizan los shaders y descubren y liman los cuellos de botella existentes y demás.
#15 No tienen por qué programarse a pelo. HLSL son las siglas de "High Level" Shader Language, y es el lenguaje de shaders de microsoft. O sea, se compila para dar lenguaje a verdaderas instrucciones para la máquina. Y esto es así porque las GPU son unidades programables, como lo son las CPU.
Y si, tanto el HSLS como el GLSL (GL Shading Language, la contrapartida de openGL) son en realidad los compiladores que traducen ese lenguaje a código GPU genérico (cada versión de los shaders tienen sus peculiaridades, pero todas las familias de tarjetas gráficas que las soportan comparten el mismo código compilado, con optimizaciones por familias o modelos, igual que las cpus van optimizadas por familias o modelos), y ese compilador va en los drivers de tus amadas tarjetas gráficas (¿no has leído nunca en ninguno de los juegos a los que juegas cuando cargan un nivel alguna frase similar a "compilando shaders"?). También existen compiladores alternativos, dado que hay otros lenguajes de shading por ahí. Nvidia presentó originalmente cg con sus geforce3, el primer lenguaje de definición de shaders antes de que surgieran los estándares para directX y openGL. Renderman tiene un lenguaje de shaders propio, así como Blender y otros programas de modelado, etc.
Ya solo por la frase "API es el intérprete entre el motor de un juego y el hardware de una consola o PC" merece que no llegue a portada. Con lo fácil que es la típica analogía de que son las palanquitas, volantitos y botoncitos que mueven y dirigen el motor que hay debajo... (que si, que el que sabe puede manejar un motor sin necesidad de un cuadro de mandos, pero es más fácil y cómodo con las palanquitas). Y que directx y opengl son cuadros de mando hipercomplejos y con un montón de botones que pulsar para hacer cualquier cosa y que por ahí viene mantle, que propone cuadros más claros, con menos botones y que cada botón hace una o más acciones, evitando tener que conocer combinaciones de los mismos como antes... en fin.
Luego para rematar, le echa la culpa del menor rendimiento de one respecto a play4 a las directx, cuando a una consola se la programa lo más a pelo posible, obviando directx y yendo al bajo nivel y sobre todo porque desde la mesa de diseño por componentes y demás ya se sabe que la play4 es más potente que la one (entre otras cosas porque el gran cuello de botella de las apus de amd es el ancho de banda de la memoria y ps4 tiene muchísimo más que one).
Luego el tema de las interrupciones tiene guasa. Imaginas que un ordenador es inteligente y suelta bips y esas cosas. Todas las interrupciones hay que programarlas, son avisos de que se ha realizado alguna tarea o de que se ha llegado a un estado especial, el sistema operativo gestiona esos avisos y/o los delega al usuario para que los gestione, pero no todo va solo, así, mágicamente como tu piensas. Antes de que un timer te avise cada segundo tienes que programarlo para que te avise cada segundo. Y tienes que controlar su estado, para que cada segundo sepa que lo has atendido y que siga avisándote. Que por cierto, antes había (y seguramente haya algún trasto aún) hardware que no sabía lo que eran las interrupciones ¿cómo funcionaba entonces? ¿qué hacía el SO para controlarlo? pues lo hacía. Así que si, estás retorciendo mis palabras para que digan lo que tu quieres y darte la razón.
Haciendo de nuevo gala de tu estupidez supina. Lo único que hay que hacer es activar el sistema de interrupciones y eso ya funciona sólo. Luego tú si quieres le asignas las funciones a ejecutar cuando se activa esa interrupción. Y harás los controles que sean necesarios.
Nada funciona sin interrupciones o sin reloj. Las interrupciones es algo básico para el funcionamiento de cualquier computador. La espera activa no es una opción. Por favor, ¿nos mola gastar ciclos de CPU tontamente o qué?
Y seguirá lloviendo. La investigación es punta de lanza
Gracias por la obviedad , gracias a papers que tu desprestigias
¿Desprestigiar?, todo lo contrario: le he dado valor, imbécil. se han desarrollado nuevos filtros, formas de hacer cálculos que mejoren la efectividad y precisión de la teselación
Jajajajaja (que si no lo recuerdas, ya estaba empezando a aparecer con la radeon original, pero se desechó porque tenía demasiadas limitaciones en esa época como la de renderizar esquinas o superficies puntiagudas y chupaba demasiados recursos, aparte de que fue una de aquellas muchas extensiones que no se llegaron a integrar en dx ni en opengl)
Sobre todo porque la teselación tiene mucho que ver con renderizar. Y si, muchas cosas no se terminan aplicando, pero sirven de base para investigaciones futuras.
Gracias por repetir lo que yo he dicho.
El hardware solito hay que programarlo para que haga esas cosas. El SO se encarga de eso, listillo. Una sierra se dedica a dar vueltas solitas, pero hace falta un humano o un robot o cadena de montaje para que los troncos lleguen y se corten.
Las cosas básicas las hace el hardware solito y para cosas como la coherencia de memoria se requiere una intervención mínima del sistema operativo que entrega la información necesaria al hardware. Eso en mi pueblo no es programar el hardware. Programar es dirigir. Indicar información NO es dirigir.
Me parece que no sabes de la misa a la mitad. Abstráete idiota. Además, casi todo lo que comentas (coherencia, etcétera) se hace con mecanismos hardware que el driver (sistema operativo) no tiene que manejar, incluyendo una eSRAM cuyo acceso se pueda programar (ya ves, indicar que quieres almacenar esos objetos en la eSRAM o no, un volatile), y eso encima se controla desde API externa al driver, API que es idéntica entre consolas y hardware para PC de AMD y portable a hardware Intel y NVIDIA. Dicho por la propia AMD. Todo son feature levels.
NVIDIA mantiene el mismo driver para NT Kernel, Linux, BSD y Solaris. ¿Cómo crees que podría mantener un driver para tantos sistemas que según tú son tan diferentes y tienen tantas variaciones que entonces resulta IMPOSIBLE manejar a todos por igual? La solución es muy fácil: una programación adecuada que permite aprovechar igualmente al máximo el hardware.
Y lo mismo ocurre con las consolas. AMD ha cogido el driver de Linux y lo ha empleado en las consolas, ni más ni menos.
Así pues, deja hablar a los mayores.
¿Lista de especificaciones?, ni tan siquiera te has molestado en leer el artículo, teniendo la cara de afirmar que aportas enlaces cuando esos mismos enlaces me dan a mí la razón.
#20
Tienen características estándares, el hardware es el mismo, los drivers son los mismos y la API es exactamente la misma.
No sabes de qué estás hablando.
He leído los enlaces que me has pasado, y además varias veces. No vienes a contar ni decir nada nuevo. Paso de darte enlaces, he tenido ya demasiadas veces esta misma discusión con otra mucha gente que igual que tú, no saben y su experiencia, si es que tienen alguna, viene por limitaciones suyas.
¿Programar a pelo? Ya no se programa a pelo, si es que por programar a pelo entiendes escribir tú mismo el ensamblador cuando hay software que lo puede hacer mejor que tú. Los tiempos del ensamblador hace muchísimo tiempo que han pasado, incluyendo los tiempos de la PS2 y su SDK que era una bazofia obligando a los desarrolladores a hacer sus típicas chapuzas, que obviamente no usaban ensamblador de la GPU sino que usaban las funciones del driver del chip gráfico de PS2.
Las consolas de generaciones anteriores no tenían ningún SO. Absolutamente ninguno. Wii (no confundir con U) no tiene sistema operativo. El BIOS (masculino, no femenino) no es un sistema operativo.
La API Glide fue ideada por 3DFx pero no es exclusiva del hardware 3DFx, ha sido portada a otro hardware.
#18
No te estoy diciendo que tienen características no estándares. Precisamente te estoy diciendo lo contrario. Las Radeon R9 son un superconjunto de la GPU que llevan PS4 y Xbox One, es decir, llevan más funcionalidad. Y las APU de AMD también llevarán más funcionalidad.
Respecto a todo lo demás, erróneo, desactualizado y mentiras populares de gente sin conocimientos y de empresas sin ningún conocimiento de investigación de arquitectura.
La play3 tiene hypervisor y sistema operativo. La ps2 no. En tiempos de ps2 existía la API Glide que fue portada a otras plataformas hardware.
#19 Si no son de una generación ni de otra, no encajan ni en los drivers y apis de una ni de la otra, se tienen que ajustar las cosas porque su comportamiento es diferente, o sea, tienen características no estándares. Lo mismo que las gráficas dolphin y xenos eran tarjetas híbridas e intergeneracionales que no eran comparables con sus equivalentes en pc porque tenían características más avanzadas que la generación con la que coexistieron, pero quedaban desfasadas respecto a la generación siguiente.
¿Tu has leído los enlaces que te he pasado en serio? ¿dónde pone todo eso? ¿dónde están tus enlaces que corrigen lo que yo he puesto para hacer esas afirmaciones? ¿te has parado a pensar que todos esos datos erróneos, desactualizados y mentiras populares provienen de gente de la scene, que ha programado a pelo esas consolas y que conocen mejor sus tripas que tu y de gente que ha usado los sdks oficiales y sabe de lo que habla?
Sobre lo del SO, todas las consolas actuales tienen un sistema operativo para gestionar los recursos, antes de manera muy básica, ahora con las capacidades multimedia, los dashboard y demás, de manera bastante más compleja. Las muy viejas pasaban con una simple BIOS, porque no necesitaban más. La api glide era única y exclusiva para hardware 3dfx, que salvo en algunas recreativas no se usó más allá del pc.
#24
No estoy retorciendo ninguna palabra tuya. Estás retorciendo tú las mías, empezando porque hablas de distintas familias cuando son la misma familia. Resulta que A y C son iguales y la única diferencia es que el núcleo familiar de A tiene más dedos en las manos que los del núcleo familiar C. Los drivers no son la ropa que llevan sino los tenedores que utilizan, los cuales pueden ser usados independientemente del número de dedos en las manos. Es más, al tener más dedos los tenedores pueden aprovechar más capacidades de articulación de la mano y adoptar posturas más complejas.
El sistema es distinto pero la arquitectura es la misma y por tanto hacen exactamente lo mismo que hacen con los drivers para Windows y Linux, BSD, etcétera: tienen todos una base común, lo cual demuestra tu total desconocimiento sobre el tema y la absurdidad de tus comentarios.
Los BIOS son un sistema básico para operaciones de entrada y salida, no son un gestor de hardware. El que gestiona el hardware es el programa que hace uso de las rutinas de un BIOS.
¿La gente investiga porque le sale del alma o porque luego aplican esa investigación en el desarrollo de productos?
La gente investiga lo que puede y a veces lo que quiere. Y de ahí a que se aplique en el mercado dista un largo trecho, sobre todo de unos papers de hace bastante tiempo usando una GTX 295 con un pseudoensamblador que en todo caso ya habrá sido superado por nuevas versiones del nvcc al añadir cada vez un lenguaje C más completo, incorporando resultados de ese paper y otros (un compilador es lo que genera el ensamblador). Anda que no ha llovido desde entonces.
Ni tan siquiera aciertas en lo que es y hace un sistema operativo y en el modo en el que los recursos son asignados a los procesos y cómo éstos recursos son controlados (pista: lo hace el hardware el solito mediante interrupciones, el SO sólo realiza unas pequeñas comprobaciones) y eres ya lo suficientemente mayor como para corregirte tú mismo.
Ya te he dicho que para soportar Glide no necesitas un hardware específico. Glide ha sido portada a otro hardware, no ha sido emulada. Ahora me dirás que Wine es un emulador (Wine Is Not an Emulator). Otro grotesco fallo más de tu comentario
¿tienes más errores para mi?
Sí, todo tu absurdo comentario que ignora todo lo que digo, incluyendo el hecho de que BIOS no es femenino sino masculino. En base a eso no tienes perdón de nadie ni de nada y tus réplicas resultan insustanciales en tanto que no muestras respeto alguno, basta ésta última pregunta a la que respondo.
#25 No se usan igual porque no son iguales, no es un tenedor con menos dientes, si instalas unos drivers de A o de C para B cascará. No es "no puedo ejecutar funcionalidades que no tengo" sino que cascará porque internamente son diferentes aunque se basen en el mismo diseño, que no la misma arquitectura. Empezando porque tanto la ps4 como la xbox1 tienen una memoria diferente y una memoria extra, lo que cambia no solo la lógica de control de la memoria, sino su relación con el resto de componentes. Tu los metes en una misma familia, yo opino que los cambios son lo suficientemente importantes como para pensar que son familias distintas. Igual que la serie 5000 y la 6000 son revisiones de la misma familia, pero los cambios en la 6000 son suficientes como para separarlas. Como ya te he dicho, no es lo mismo adaptar una cosa que funciona parecida a decir: cojo los drivers y añado x pa usar nuevas funcionalidades y ya está. Es como cambiar el sentido de una calle en una ciudad. Parece un cambio chorra, pero no basta con eso, hay muchas partes que se ven afectadas con ese cambio tan tonto, tanto como para tener que reorganizar todo el tráfico. Se nota que has escrito muchos drivers para tener tan claro que yo estoy equivocado y no asumir que quizá tu estés simplificando absurdamente las cosas.
Otro asunto: windows, linux y bsd tienen maneras completamente diferentes de acceder a los recursos de la máquina. Coge un driver linux e intenta hacerlo funcionar en bsd y verás que no puede. Y eso que son primos hermanos, y que bsd consigue soportar hardware gracias a que portan los mismos de linux. Ahora piensa en todas las diferencias arquitecturales que hay entre los drivers linux y los drivers windows. Compara los tamaños, pesos y dependencias entre drivers de linux y windows. Respóndeme por qué no están funcionales todas las funcionalidades que tienen los drivers de windows en linux si los drivers son iguales o comparten la mayor parte. Podríamos decir que hay un backend diferente por arquitectura y un frontend igual para todos, hasta ahí podría concedértelo, pero meter una capa de abstracción para aislar la arquitectura subyacente en algo tan delicado y que afecte al rendimiento tanto como unos drivers gráficos es bastante duro y arriesgado. Sería viable si windows y linux fueran más similares pero son demasiado disparejos: la gestión de memoria es diferente, la gestión energética es diferente, la gestión de los buses es diferente, la comunicación con la cpu es diferente... que programar cuatro registros sea igual en uno y otro lado no implica que la gestión de los datos obtenidos sea la misma. Tanto que de hecho no es así. Si quieres una muestra, échale un ojo a los drivers de intel, que los oficiales son libres y abiertos. Intenta portarlos a windows.
Y seguirá lloviendo. La investigación es punta de lanza, gracias a papers que tu desprestigias se han desarrollado nuevos filtros, formas de hacer cálculos que mejoren la efectividad y precisión de la teselación (que si no lo recuerdas, ya estaba empezando a aparecer con la radeon original, pero se desechó porque tenía demasiadas limitaciones en esa época como la de renderizar esquinas o superficies puntiagudas y chupaba demasiados recursos, aparte de que fue una de aquellas muchas extensiones que no se llegaron a integrar en dx ni en opengl), formas de exprimir el hardware, nuevas aproximaciones a los gráficos generados por ordenador, etc. Y si, muchas cosas no se terminan aplicando, pero sirven de base para investigaciones futuras.
Es un sistema básico de operaciones de entrada y salida. Ya lo dice su nombre, para empezar, y luego porque para gestionar el hardware puedes gestionarlo a pelo si te apetece. Me cito: "La BIOS son pequeñas rutinas tipo: activa el chip este, aplica configuración, ponlo en modo de funcionamiento tal, etc. O sea, gestionar el hardware". No he dicho que sean gestores de hardware como si es un SO, sino que sirven para gestionarlo, y que por lo tanto en principio tienen una misma misión. Luego he dicho que un sistema operativo extiende esas funcionalidades para gestionar los recursos directamente, pero que en el fondo las aplicaciones ven lo mismo: una capa de abstracción para no acceder a los mismos directamente. En caso de la BIOS por facilitar la vida a los programadores y/o dar funcionalidades software para aislar el hardware subyacente (muchas veces, los programadores obvian las rutinas de la bios y realizan operaciones de inicialización y control directamente y luego al haber revisiones de consolas y cambiar los firmwares hay juegos que no funcionan, no porque el cambio de firmware afectara, sino porque el hardware ya no es el mismo y no usaban las rutinas que aportaba el firmware y hacían de abstracción para esas tareas; incluso hay veces que sin cambiar el hardware, retoques en las firmwares tienen comportamientos laterales indeseados), en caso del SO para permitir más de una tarea accediendo a los recursos pseudoconcurrentemente (o sea, solo unas cosillas como dices tu). Luego el tema de las interrupciones tiene guasa. Imaginas que un ordenador es inteligente y suelta bips y esas cosas. Todas las interrupciones hay que programarlas, son avisos de que se ha realizado alguna tarea o de que se ha llegado a un estado especial, el sistema operativo gestiona esos avisos y/o los delega al usuario para que los gestione, pero no todo va solo, así, mágicamente como tu piensas. Antes de que un timer te avise cada segundo tienes que programarlo para que te avise cada segundo. Y tienes que controlar su estado, para que cada segundo sepa que lo has atendido y que siga avisándote. Que por cierto, antes había (y seguramente haya algún trasto aún) hardware que no sabía lo que eran las interrupciones ¿cómo funcionaba entonces? ¿qué hacía el SO para controlarlo? pues lo hacía. Así que si, estás retorciendo mis palabras para que digan lo que tu quieres y darte la razón.
De nuevo: no ha sido portado a hardware, ha sido emulado por software; quita la capa de software y no funcionará. Coger las funciones que forman parte del api y rellenarlas con código que se ejecuta en otras arquitecturas o softwares de manera que imite el hardware subyacente es emular de toda la vida, coger y hacer un hardware que ejecute esa api no lo es, es ejecutar esa api en una arquitectura diferente, o sea portarlo a esa arquitectura. O lo que es lo mismo: ejecutar directx en linux es portar (coges el mismo hardware y usas la misma api, pero cambiándola para que funcione); ejecutar la api para el emotion engine en windows o en linux es emular, porque debajo no hay un emotion engine o un hardware que lo emule, lo que hay es una capa de software que lo imita. Precisamente WINE no es un emulador porque lo que hace es traducir las apis de windows en operaciones similares a otras apis pero es imposible emularlas porque no sabemos realmente qué es lo que hacen (vemos los efectos a las causas, pero los efectos colaterales pueden pasar por alto, así como las funcionalidades ocultas, que es lo que hace que haya fallos en la emulación cada vez que se tropiezan con un bug en las apis de windows, un uso no documentado o un comportamiento anómalo no descrito (que tienen que reproducir y/o buscar la forma de sortear para que los programas funcionen).
El hardware solito hay que programarlo para que haga esas cosas. El SO se encarga de eso, listillo. Una sierra se dedica a dar vueltas solitas, pero hace falta un humano o un robot o cadena de montaje para que los troncos lleguen y se corten.
Sobre el respeto, yo he dado argumentos, con pruebas, enlaces a las pruebas, de manera constructiva, explicando las cosas paso a paso, no ignorando lo que dices, sino aclarándotelo dado que das razones sin justificación alguna. Tu insultas, vas con una superioridad absurda y juzgando sin venir a cuento y encima te quejas de las formas. Ya eso es de recochineo. Espero que no me contestes más, dado que las contestaciones que das son echar balones fuera y desacreditar argumentos sin un contraargumento más allá del no tienes ni puta idea.
El GLSL es derivado del nVidia Cg (C for graphics). Y cada driver tiene un compilador de shaders propio que aplica las optimizaciones necesarias para cada modelo de tarjeta gráfica.
El programador lo único que tiene que tener en cuenta son cosas como ancho de banda de memoria y cantidad de memoria disponibles así como la cantidad de unidades de cómputo que dispone una gráfica. Poco más debe tener en cuenta.
La PS4 y Xbox One llevan arquitectura GCN con cosas de la GCN 1.1 como tener más ACEs. Es decir, son un híbrido a medio camino entre radeon hd 7000 y radeon r9. Luego también llevan algunas pequeñas mejoras que les pueden permitir rendir algo más de lo que lo haría una GPU con el mismo número de unidades de cómputo pero nada más. Esas mejoras se añadirán a las APU 100% HSA de AMD, con la ventaja de que en un PC tendrás una tarjeta gráfica adicional para gráficos, por lo que tendrás la GPU de la APU dedicada para shaders de cómputo mientras que en PS4 y Xbox One los núcleos de cómputo de la única GPU que disponen deben tener un uso debidamente planificado y balancear con mucho cuidado los shaders de cómputo y los shaders de gráficos.
"A funny thing about PS2DEV is that there probably is more source code for undocumented parts than there is for documented parts of the PS2. There is an ongoing joke among the most passionate PS2DEV developers, which is “We only to tools™”. What this refers to is that we only make low level tools for developers and not high level libraries which are easy to use. Since the core of PS2DEV (PS2SDK) developers has been more interested in low level programming, there have not been many graphics libraries for the PS2. I think the reason for this is that anyone who sat down and read the GS and VU manuals, would be able to do it and therefor it is not an interesting challenge, just hard work.
The really hardcore PS2 developers would write custom graphics libraries which are specialized for every part of their application, to get the maximum performance out of the PS2, especially the VUs. Since the PS2 is so flexible it is very difficult to make a powerful graphics library which works well for everything."
y sobre la play3, que ya tiene una GPU más parecida a los estándares actuales y sacado del primer enlace:
"And in fact, many games don’t even use PSGL all that much, but use the lower-level LibGCM or go down to the bare metal themselves (the advantage of a console: hardware is fixed)."
Entiendo que sobre la play4, que está más diseñada para que sea fácil programar para ella, en el inicio de ciclo se apoyen en apis del fabricante todo lo posible, pero según vayan conociendo las tripas, las compañías más gordas que quieran exprimir el hardware (y las que fabrican engines o middlewares ya lo están haciendo) van a ir a pelo en aquellas cosas que requieran un desempeño crítico.
¿qué me quieres decir con una lista de especificaciones? ¿no te he dicho ya que los cambios no están en las unidades de procesado sino en la organización de la memoria? ¿crees, por poner un ejemplo, que dos versiones de la misma tarjeta, una agp y una pci se comunican igual con el ordenador? ¿crees que acceden a la memoria del sistema del mismo modo, que usan los mismos comandos para el bus? ¿no? ¿y por qué piensas que internamente funcionan igual una tarjeta que tiene una memoria unificada esram programable (que puede hacer de caché compartida por todas las unidades de procesado o usarse independientemente) de una tarjeta que no dispone de lo mismo y que en cambio sustituye un controlador de memoria DDR3 por uno para GDDR5, que tienen velocidades, latencias, etc. distintas? ¿crees que solo hay que cambiar un par de parámetros y ya está? ¿te das cuenta de que para acceder a configuraciones hUMA con esram hay que cambiar completamente la forma que tienes de garantizar la coherencia de las cachés dado que hay un nivel de memoria más? ¿te das cuenta de que el que sea programable añade complejidad extra que no es una simple caché? ¿te das cuenta de que hay formas de almacenar geometrías demás datos que necesita la gráfica en una memoria aparte y que tienes que controlar todo el proceso? ¿te crees que no hay cambios más que significativos en los drivers para eso, crees que no hay cambios en las apis para soportar esas cosas? Que no es solo ejecutar ese comando, es cambiar la forma de hacer todos los direccionamientos de memoria. Y una vez más está el punto de que no se programan de la misma manera esos drivers en una consola basada en windows, que tiene su gestión de memoria que en una consola basada en bsd, que tiene otra distinta, y también hay que tener en cuenta que no toda la memoria está disponible para juegos, se reserva parte para aplicaciones, así que hay que gestionar la seguridad para que las aplicaciones no puedan leer partes de la memoria, esram o la caché y extraer información sobre juegos y viceversa. Una vez más, la xbox necesita más mecanismos para controlar lo que pasa en esram, o sea, más diferencias en el hardware y en la api.
Muchos cambios que a ti te parecen triviales, porque te empeñas en señalar que las unidades de cómputo son iguales (y que por lo tanto el soporte vía drivers tengan una o dos más o menos es el mismo), y obvias aquello que las diferencia (y que las diferencia de otros sistemas no hUMA) que es la gestión de memoria).
>Tienen características estándares, el hardware es el mismo, los drivers son los mismos y la API es exactamente la misma.
No, no lo son. Las características extra que tienen respecto al estándar no son las mismas que hay en la siguiente generación, entre otras cosas porque están adaptadas a las consolas y su contexto, mientras que las que lleven las tarjetas gráficas de la siguiente generación han sido pulidas y adaptadas a los pcs. Y se usan de manera diferente, así que las apis tienen que cambiar para reflejarlo. Y los drivers son muy diferentes porque:
a) el hardware de consola es diferente. No es lo mismo hacer drivers para una arquitectura Intel de 32 bits que para una de 64 bits, que para una arquitectura IBM. Y no es lo mismo hacer drivers para una ps4 que para una xbox one, por el simple hecho de que tienen una arquitectura de memoria diferente (y seguro que más cosas, dado que es sabido que ambas tienen procesadores de apoyo y memorias extra que son diferentes entre ambas y que harán que la forma de acceder a los recursos varíe un tanto), aunque el resto de componentes sea prácticamente igual.
>No sabes de qué estás hablando.
Pasas de darme enlaces, pero no me dices en qué cosas estoy equivocado y por qué, simplemente sueltas el argumento de yo soy mejor que tu y tengo más conocimientos, sin siquiera demostrarlo con argumentos. Dame cualquier indicación de softwares que evitaban tener que hacer chapuzas a mano. Y luego dime cómo lo escribieron, porque antes de una librería o un lenguaje, hay que crearlos. Y luego asegúrame categóricamente que nadie ha tocado una línea de ensamblador en ps3 ni en xbox360, pero dándome datos. Ah, por cierto, aunque me vas a decir que nadie lo usa deberías mirar http://eprint.iacr.org/2012/137.pdf y http://renderingpipeline.com/graphics-literature/low-level-gpu-documentation/ pa hacerte una idea de cómo funciona la cosa de verdad.
>Las consolas de generaciones anteriores no tenían ningún SO
Si que ha habido máquinas anteriores a la play2 con SO ¿alguien ha dicho Dreamcast? querían incluírlo en la máquina, pero al final no viene en la máquina en si, sino en los discos de los juegos y aplicaciones (muchos traían una versión de windows ce preparada para usar directx). La xbox original también tenía SO, basado en win2000 antes de que apareciera la wii. Otras consolas tienen firmwares que hacen las veces de BIOS (que como sabrás son las rutinas básicas que permiten interactuar con el hardware y que realizan las tareas de inicialización del mismo cuando arrancas la máquina). El sistema operativo hace básicamente lo mismo que una bios, pero con más capacidades de gestión de recursos (permitiendo multitarea, por ejemplo, en lugar de dejar que los juegos usen los recursos en exclusiva), pero en las consolas antiguas o poco potentes no tenía sentido añadir más capas de abstracción. Ahora que las consolas hacen un poco de centro multimedia si tiene sentido que lo hagan.
>La API Glide fue ideada por 3DFx pero no es exclusiva del hardware 3DFx, ha sido portada a otro hardware.
Falso. Que ciertas placas incluyeran chips 3dfx no hace que la api glide se ejecute en otro hardware. Y productos que montaran chips de 3dfx más allá de las gráficas de pc y algunas recreativas no hay. Cita desde la wikipedia: "Originally developed for arcade games that included non-Intel architectures, Glide was created to handle error prone tasks like chip initialization for the programmer, but implemented nothing more than what the Voodoo hardware was directly capable of."
Vamos, que para soportar glide, tu tarjeta tiene que ser un clon de un modelo de 3dfx o montar un chip de 3dfx. Más:
"3dfx had therefore created a strong advantage for itself by aggressively promoting Glide, which was designed specifically around the Voodoo hardware, and therefore did not suffer from the performance hit of a higher level abstraction layer."
"By 2000, the improved performance of Direct3D and OpenGL on the average personal computer, coupled with the huge variety of new 3D cards on the market, the widespread support of these standard APIs by the game developer community and the closure of 3dfx, made Glide obsolete."
#22
Pero es que no hay ningún estándar. Deja de decir sandeces.
El driver es el mismo. El fabricante del hardware es el mismo. AMD ha empleado el mismo frontend para ambas consolas y ha creado los módulos necesarios para esas dos consolas.
Dreamcast no tenía SO y Xbox 1 sí tenía SO, pero no PS2. Xbox 1 es posterior a PS2. Encima Xbox 1 era más potente y rendía más que PS2.
BIOS es masculino, no femenino (Basic Input Output System). El sistema operativo no hace lo mismo que un BIOS y no es una capa de abstracción mayor que un BIOS, es otra cosas distinta ni supone una pérdida de rendimiento dado que cuando un proceso entra en CPU tiene toda la CPU y el hardware para el igual que la tendría en un hardware sin sistema operativo y con un buen planificador incluso hasta el programa puede ir mejor sin caer en errores tontos del programador que tenga que planificarse el sólo todo el hardware (me parto el culo con los procesadores multinúcleo de hoy día).
Ya te he dicho las cosas en las que estás equivocado. Los softwares que evitaban hacer chapuzas son los compiladores. Si Sony y otros fabricantes de consolas no los tenían disponibles por usar software cerrado y privativo pues qué quieres que diga.
Para soportar Glide basta con que ofrezcas la misma API que Glide y la portes a tu driver/módulo de kernel de GPU.
#23 A ver, ¿en qué sentido piensas que uso "estandar"? ¿en el de "grupo de características iguales dentro de una familia" o en el de "especificaciones de la indústria"? si es lo segundo ganas tu, pero estarías retorciendo mis palabras para que signifiquen lo que a ti te da la gana. Sobre decir sandeces, ahí van otras pocas: estoy diciendo que hay dos familias, A y C, cada una con una serie de características comunes entre todos sus miembros. A tiene tres piernas y C tiene tres brazos. Los drivers son la ropa que llevan, así que los pantalones de A no le sirven a C y las camisas de C no le sirven a A. Y que enmedio han desarrollado B, que ni es A, ni es C, porque han llegado a la conclusión de que le sobra una pierna a A, pero aún no han aprendido a desarrollar el tercer brazo, así que le han incrustado un pie en el ombligo, pero con la nueva capacidad de "dedo pulgar oponible" que C implementará en la mano extra. O sea, tiene capacidades de C, es superior a A, pero ni le sirven los pantalones ni le sirve la camisa, hay que adaptar las cosas. Luego pueden aprovechar trabajo hecho en B para hacer los pantalones para C, pero la camisa hay que hacerla nueva. Conclusión: NO son los mismos drivers ni funcionan igual, ¿se puede reaprovechar código de unas generaciones a otras? si, siempre y cuando los cambios internos no sean demasiado drásticos, pero el driver cambia y mucho. Y más cuando estás creando un driver para un sistema y una arquitectura (de la máquina) distinta. Porque no es lo mismo un driver para una consola basada en windows que una consola basada en bsd, porque la arquitectura de memoria es diferente, así que el acceso a recursos también lo es.
¿La gente investiga porque le sale del alma o porque luego aplican esa investigación en el desarrollo de productos?
Sobre Dreamcast y wince: http://www.segasaturno.com/portal/viewtopic.php?t=5724. Como ves, hay muchos juegos desarrollados sobre wince, y además del runtime tiene que haber alguien que gestione los recursos por debajo para que el runtime funcione (si, un wince optimizado para dreamcast). Que solo ejecute una tarea no quiere decir que debajo no haya un SO (mira si no los primeros iOS). BIOS es del género que me de la gana, si tu quieres que sea macho, pues chachi. BIOS es acrónimo de las rutinas básicas de entrada salida, como ves todo femenino.
La BIOS son pequeñas rutinas tipo: activa el chip este, aplica configuración, ponlo en modo de funcionamiento tal, etc. O sea, gestionar el hardware. También son atajos que resumen cosas repetitivas o muy usadas en una sola llamada, para ahorrar trabajo al programador, o una forma de abstraer capacidades hardware subyacentes para homogeneizar acceso a recursos a muy bajo nivel (las BIOS vga permitían manejar tarjetas de muchos fabricantes y con diferentes capacidades programandolas de la misma manera y accediendo a los recursos de la misma manera).
Un sistema operativo es un gestor de recursos del sistema, nada más y nada menos. Se apoya o sustituye a la BIOS porque su tarea primaria es la misma, controlar el hardware, aunque su radio de acción sea más amplio. Los programas piden recursos y el SO se encarga de reservarlos para ellos para que no haya conflictos de dos programas accediendo a los mismos recursos a la vez, y esto es lo que diferencia un sistema operativo de una bios: está pensado para que más de un proceso o programa use los recursos, y para conseguir eso se los apropia y da acceso a los recursos de manera indirecta, siendo el SO el que los controla y el que se hace responsable de lo que pase (al contrario que la bios, que los pone a la disposición del programa y se desentiende). Como ya dije, en las antiguas consolas no tenía sentido que más de un programa funcionara a la vez, así que solo habían firmwares (BIOS es la nomenclatura PC para llamar a todo firmware compatible con los IBM PC originales y así se ha ido llamando desde entonces, quizá hasta la nomenclatura es anterior).
Ya te he dicho que para soportar glide necesitas un hardware específico. Cualquier cosa que no sea eso implica emular (y eso no es soporte hardware). Glide estaba demasiado atado al hardware (por eso cada revisión del hardware tenía su propia librería glide, que implementaba esa api). Ahora glide es opensource, pero hacer drivers que soporten glide es una estupidez salvo para emulación (hay implementaciones como openglide o dgvodoo que funcionan sobre dx y ogl desde hace años). Pero es muy distinto esto que dices ahora (Para soportar Glide basta con que ofrezcas la misma API que Glide y la portes a tu driver/módulo de kernel de GPU.) que lo que dijiste antes (La API Glide fue ideada por 3DFx pero no es exclusiva del hardware 3DFx, ha sido portada a otro hardware) porque NO ha sido portada a ningún hardware, ha sido emulada por software (cambiar llamadas glide por llamadas dx o ogl es mero software por mucho que el resultado sea acelerado por hardware, crear un hardware que entienda llamadas glide es hacer un chip 3dfx-compatible, como ves son cosas muy distintas).
Comentarios
Si quereos una NVIDIA Volta, la primera arquitectura gráfica con soporte nativo para DirectX 12. "preparad la cartera"
y opengl no vale, cómo no es propietaria...
desinformación.
La primera arquitectura GPU compatible con Direct3D 12 (DirectX engloba muchas cosas) ya está en la calle y es Maxwell.
Y las consolas no se programan a bajísimo nivel. Utilizan API también. A ver si os creéis que los shaders se programan con el ensamblador de las GPUs. Eso sería una locura.
En agosto el nuevo OpenGL con bajos sobrecostes también será anunciado. Mantle desaparecerá como lágrimas bajo la lluvia. Aunque habrá servido como revulsivo para la modernización de las API gráficas.
#9 Donde se nota un mayor ancho de banda es en la fluidez, no en la calidad de imagen (directamente), dado que montan idéntico chip con idénticas capacidades, pero (incluso con la liberación de potencia de no reservar nada para usar kinect) con menos unidades de procesamiento. Y en el apartado cpu la xbox tiene una cpu más rápida, pero igualmente con menos unidades de procesamiento (la rapidez en este caso podría compensar en tareas que requieran más potencia de un procesador y penalizar tareas que requieran distribuír más la potencia entre todos los procesadores, aunque de nuevo la diferencia en la práctica apenas se va a notar entre las consolas). Quizá aprovechen para meter algo más de carga gráfica o elevar mínimamente la resolución, pero será casi inapreciable a estas alturas, donde unos millones de polígonos más no se notan o un buen filtro hace inapreciable perder miles de pixels de resolución. De todos modos, busca cualquier análisis del impacto de la velocidad de la memoria en apus amd y verás que efectivamente hay una ganancia sustancial de rendimiento al subir esta y por ende aumentar el ancho de banda disponible (o sea, la memoria hace de cuello de botella).
Xbox one contraataca la lentitud de la memoria poniendo una memoria intermedia ultrarápida que hace de caché (estrategia que se ha confirmado muy útil en otras consolas como gamecube, wii y xbox 360, y que se va a aplicar en futuras apus de amd para el mercado pc y servidores (eso si, con memorias más lentas y baratas, supongo que solo en el primer caso), pero la cantidad que han puesto no es suficiente para las necesidades de los programadores (también se quejaban de que era insuficiente en el caso de la 360, ojo, pero en aquel entonces la contienda era más pareja porque la play4 tenía un cuello de botella parecido en el acceso a los coprocesadores que integraba cell).
Una vez visto que técnicamente realmente la ps4 si que es más potente (lo único donde la xbox tendría ventaja real es que el chip de audio está separado y no consumiría recursos cpu, mientras que la ps4 lo tiene unificado con el resto, pero incluso así la ps4 tendría ancho de banda más que suficiente para que meter el audio no afecte al rendimiento), te digo que efectivamente, la capacidad de procesamiento es tal que salvo que hagan chapuzas programando se podrá conseguir prácticamente lo mismo en cuanto a cantidad y calidad con ambas consolas, pero que siempre va a ir un poquito más suave en la play. La baza de xbox one es kinect, y hasta ahora no han conseguido un juego que venda la consola por su uso con el kinect y que suponga un antes y un después en el desarrollo para este periférico. Justamente creo que esto se conseguirá con la llegada de los cascos de realidad virtual, donde el uso de mandos puede romper un poco la inmersión, pero para eso aún queda.
#8 Una api simplemente es una capa de abstracción que define acciones sobre lo que puede hacer el hardware. Si eres capaz de ejecutar lo que se supone que hacen esas llamadas con el hardware que tienes (o por software), aunque no esté específicamente diseñado para ello, ya es compatible con esa api. Imaginemos que hay una llamada para sacar la ropa de la lavadora y colocarla en una de estas secadoras con tensores que a la vez planchan y guardarla en el armario, todo de una tacada. Si tu hardware no tiene una secadora de estas, podría intentar simularla dejándola secar un rato y luego pasándole una plancha manual y luego doblándola y luego llevándola al armario. Hace el doble de pasos, usa tecnología "desfasada" y por lo tanto es más lenta, pero hace lo mismo y por lo tanto cumple con la api. O se puede hacer por software: el humano de turno, después de fregar a mano, retuerce la ropa pa escurrirla, la pone a secar, la alisa un poco con las manos, la dobla como puede y luego la guarda. La ropa queda arrugada, mojada y ha tardado mucho más todavía en realizar todo el proceso, pero el resultado es más o menos el pedido, y por lo tanto sería compatible con esa api.
A lo que voy es que el trabajo de soportar una api a menudo es cosa más de los drivers que del hardware subyacente. Solo que a menudo el coste de intentar hacer que un hard antiguo soporte un api nuevo es demasiado grande o imposible. En el segundo caso el ejemplo más claro es que las antiguas tarjetas gráficas con cálculo de iluminación y geometría fijos nunca podrán funcionar ni hacer lo que hacen las gpus programables actuales. En el primero están tarjetas que soportan la api X.0 y con actualizaciones de drivers son capaces de soportar la api X.y.
Como ejemplo claro, mantle solo es soportada por las últimas generaciones de apus y gpus, que son las que disponen de hardware que es permite hacer de manera fácil las cosas que mantle pide, y de paso es una api hecha a medida de sus apus, porque se encarga de minimizar el ancho de banda usado por las gráficas -que es su cuello de botella- y el overhead de la api: en lugar de darte una lista de 100 instrucciones para hacer ciertas cosas, que dan lugar a 100 peticiones, intercambio de datos y sincronización entre cpu y gpu, las agrupan y te dan una lista de 5 cosas que engloban a aquellas, minimizando la comunicación necesaria para desarrollar las tareas (entre otras optimizaciones).
#10
No me vengas a dar lecciones porque te has metido un churromerinismo de campeonato además de dar información errónea acerca de lo que hace Mantle.
Mantle estrictamente hablando reduce los sobrecostes de la CPU, nada más. Y a día de hoy tarjetas NVIDIA con cpus Intel rápidas obtiene el mismo rendimiento que tarjetas AMD con Mantle.
Donde Mantle va bien es cuando se tienen CPUs poco potentes.
#11 ¿Qué es lo que he dicho yo arriba? eso mismo. Y cito "porque se encarga de minimizar el ancho de banda usado por las gráficas -que es su cuello de botella- y el overhead de la api". Si te piensas que la cantidad de instrucciones de la cpu a la gpu (el overhead, sobreuso de cpu en simular aspectos de apis antiguas/desfasadas o llamadas indirectas o repetitivas a cosas que una gpu puede hacer de manera más fácil y mejor) no afectan al ancho de banda (aumentando las latencias, ocupando espacio en los buses, redundancia de datos en memoria para poder hacer operaciones entre ellos) es porque no estás entendiendo nada de lo que digo.
Ahora... ¿qué información errónea he dado sobre mantle? ¿por qué no me corriges?
¿y por qué mezclas churras con merinas? ahora mismo estás comparando amd con mantle con nvidia con procesadores intel sin venir a cuento solo para (no) explicar que las últimas versiones de otras apis ya disponen de optimizaciones similares y/o que otro hardware por potencia bruta es superior (y desde que salieron las apus, cualquier dedicada y cualquier procesador de gama media ya las superaban holgadamente, desde que se anunciaron las consolas de nueva generación ya se sabía que tendrían la potencia de un portátil por el hardware que iban a llevar, desde antes de que se anunciara mantle ya existía un debate en la comunidad opengl sobre el overhead que llevaba la api encima y lo ineficiente que podía llegar a ser en algunos casos). ¿No es más justo, fácil y COMPARABLE algo así como amd con mantle vs sin mantle? (porque no podemos comparar nvidia sin mantle vs nvidia con mantle o un ganancias de nvidia con mantle vs ganancias de amd con mantle)
#11 Aparte de que una cosa es la programación de shaders y otra cosa es meter una api compleja de por medio. Como bien sabrás, los shaders se compilan y se "cargan" en la tarjeta, pero es como cualquier otro lenguaje, si sabes lo que escribes puedes hacerlo a pelo y/o realizar optimizaciones específicas para tu hardware concreto (y dado que una consola es un hard cerrado, mejor que un compilador generalista que funciona sobre una amplia gama de hardware, buscas lo que más eficiente haga tu código; evidentemente en los sdk de las consolas habrá un compilador que las estruje todo lo posible). Luego, aparte de los shaders, está el resto de la api. No creo que en consolas encuentres un d3d o un opengl completo, como mucho parte de una implementación que se ajuste a tu hardware, quitando toda parte que sea "compatibilidad con versiones anteriores" o "características que no monte tu hardware". Incluso así, hay compañías que se crean sus propias herramientas, o sea, trabajan sobre el metal a pelo (el soporte y optimización de motores de middleware tipo unreal/unity/cryengine para consolas debe ser lo más eficiente posible, basan su prestigio en eso).
Todo esto es para decirte que si, que la gran mayoría de los programadores no usan hard a pelo por la sencilla razón de que usan middlewares que ya les solucionan la papeleta, ni siquiera tiran de apis, usan frameworks ya hechos y dedican sus esfuerzos al scriptado y programación de otras cosas mientras le dejan el trabajo de diseñar shaders, texturas y escenarios a diseñadores. Pero los que realmente trabajan en motores propios de algo de nivel si que lo hacen, por mucho que a ti te parezca una burrada, lo mismo con los ingenieros de gráficos que luego optimizan los shaders y descubren y liman los cuellos de botella existentes y demás.
#14
Los shaders ya se programan a pelo. Por eso, no tiene sentido lo que dices. Y ya lo de "compilador genérico" es que es el descojone máximo.
#15 No tienen por qué programarse a pelo. HLSL son las siglas de "High Level" Shader Language, y es el lenguaje de shaders de microsoft. O sea, se compila para dar lenguaje a verdaderas instrucciones para la máquina. Y esto es así porque las GPU son unidades programables, como lo son las CPU.
Y si, tanto el HSLS como el GLSL (GL Shading Language, la contrapartida de openGL) son en realidad los compiladores que traducen ese lenguaje a código GPU genérico (cada versión de los shaders tienen sus peculiaridades, pero todas las familias de tarjetas gráficas que las soportan comparten el mismo código compilado, con optimizaciones por familias o modelos, igual que las cpus van optimizadas por familias o modelos), y ese compilador va en los drivers de tus amadas tarjetas gráficas (¿no has leído nunca en ninguno de los juegos a los que juegas cuando cargan un nivel alguna frase similar a "compilando shaders"?). También existen compiladores alternativos, dado que hay otros lenguajes de shading por ahí. Nvidia presentó originalmente cg con sus geforce3, el primer lenguaje de definición de shaders antes de que surgieran los estándares para directX y openGL. Renderman tiene un lenguaje de shaders propio, así como Blender y otros programas de modelado, etc.
¿Una marca de foi-grass?
Ya solo por la frase "API es el intérprete entre el motor de un juego y el hardware de una consola o PC" merece que no llegue a portada. Con lo fácil que es la típica analogía de que son las palanquitas, volantitos y botoncitos que mueven y dirigen el motor que hay debajo... (que si, que el que sabe puede manejar un motor sin necesidad de un cuadro de mandos, pero es más fácil y cómodo con las palanquitas). Y que directx y opengl son cuadros de mando hipercomplejos y con un montón de botones que pulsar para hacer cualquier cosa y que por ahí viene mantle, que propone cuadros más claros, con menos botones y que cada botón hace una o más acciones, evitando tener que conocer combinaciones de los mismos como antes... en fin.
Luego para rematar, le echa la culpa del menor rendimiento de one respecto a play4 a las directx, cuando a una consola se la programa lo más a pelo posible, obviando directx y yendo al bajo nivel y sobre todo porque desde la mesa de diseño por componentes y demás ya se sabe que la play4 es más potente que la one (entre otras cosas porque el gran cuello de botella de las apus de amd es el ancho de banda de la memoria y ps4 tiene muchísimo más que one).
#6 Espera a ver la diferencia en los gráficos en las dos consolas, yo creo que no será representativa de la mayor potencia gráfica de PS4.
Luego el tema de las interrupciones tiene guasa. Imaginas que un ordenador es inteligente y suelta bips y esas cosas. Todas las interrupciones hay que programarlas, son avisos de que se ha realizado alguna tarea o de que se ha llegado a un estado especial, el sistema operativo gestiona esos avisos y/o los delega al usuario para que los gestione, pero no todo va solo, así, mágicamente como tu piensas. Antes de que un timer te avise cada segundo tienes que programarlo para que te avise cada segundo. Y tienes que controlar su estado, para que cada segundo sepa que lo has atendido y que siga avisándote. Que por cierto, antes había (y seguramente haya algún trasto aún) hardware que no sabía lo que eran las interrupciones ¿cómo funcionaba entonces? ¿qué hacía el SO para controlarlo? pues lo hacía. Así que si, estás retorciendo mis palabras para que digan lo que tu quieres y darte la razón.
Haciendo de nuevo gala de tu estupidez supina. Lo único que hay que hacer es activar el sistema de interrupciones y eso ya funciona sólo. Luego tú si quieres le asignas las funciones a ejecutar cuando se activa esa interrupción. Y harás los controles que sean necesarios.
Nada funciona sin interrupciones o sin reloj. Las interrupciones es algo básico para el funcionamiento de cualquier computador. La espera activa no es una opción. Por favor, ¿nos mola gastar ciclos de CPU tontamente o qué?
Y seguirá lloviendo. La investigación es punta de lanza
Gracias por la obviedad
, gracias a papers que tu desprestigias
¿Desprestigiar?, todo lo contrario: le he dado valor, imbécil.
se han desarrollado nuevos filtros, formas de hacer cálculos que mejoren la efectividad y precisión de la teselación
Jajajajaja
(que si no lo recuerdas, ya estaba empezando a aparecer con la radeon original, pero se desechó porque tenía demasiadas limitaciones en esa época como la de renderizar esquinas o superficies puntiagudas y chupaba demasiados recursos, aparte de que fue una de aquellas muchas extensiones que no se llegaron a integrar en dx ni en opengl)
Sobre todo porque la teselación tiene mucho que ver con renderizar.
Y si, muchas cosas no se terminan aplicando, pero sirven de base para investigaciones futuras.
Gracias por repetir lo que yo he dicho.
El hardware solito hay que programarlo para que haga esas cosas. El SO se encarga de eso, listillo. Una sierra se dedica a dar vueltas solitas, pero hace falta un humano o un robot o cadena de montaje para que los troncos lleguen y se corten.
Las cosas básicas las hace el hardware solito y para cosas como la coherencia de memoria se requiere una intervención mínima del sistema operativo que entrega la información necesaria al hardware. Eso en mi pueblo no es programar el hardware. Programar es dirigir. Indicar información NO es dirigir.
Me parece que no sabes de la misa a la mitad. Abstráete idiota. Además, casi todo lo que comentas (coherencia, etcétera) se hace con mecanismos hardware que el driver (sistema operativo) no tiene que manejar, incluyendo una eSRAM cuyo acceso se pueda programar (ya ves, indicar que quieres almacenar esos objetos en la eSRAM o no, un volatile), y eso encima se controla desde API externa al driver, API que es idéntica entre consolas y hardware para PC de AMD y portable a hardware Intel y NVIDIA. Dicho por la propia AMD. Todo son feature levels.
NVIDIA mantiene el mismo driver para NT Kernel, Linux, BSD y Solaris. ¿Cómo crees que podría mantener un driver para tantos sistemas que según tú son tan diferentes y tienen tantas variaciones que entonces resulta IMPOSIBLE manejar a todos por igual? La solución es muy fácil: una programación adecuada que permite aprovechar igualmente al máximo el hardware.
Y lo mismo ocurre con las consolas. AMD ha cogido el driver de Linux y lo ha empleado en las consolas, ni más ni menos.
Así pues, deja hablar a los mayores.
¿Lista de especificaciones?, ni tan siquiera te has molestado en leer el artículo, teniendo la cara de afirmar que aportas enlaces cuando esos mismos enlaces me dan a mí la razón.
#20
Tienen características estándares, el hardware es el mismo, los drivers son los mismos y la API es exactamente la misma.
No sabes de qué estás hablando.
He leído los enlaces que me has pasado, y además varias veces. No vienes a contar ni decir nada nuevo. Paso de darte enlaces, he tenido ya demasiadas veces esta misma discusión con otra mucha gente que igual que tú, no saben y su experiencia, si es que tienen alguna, viene por limitaciones suyas.
¿Programar a pelo? Ya no se programa a pelo, si es que por programar a pelo entiendes escribir tú mismo el ensamblador cuando hay software que lo puede hacer mejor que tú. Los tiempos del ensamblador hace muchísimo tiempo que han pasado, incluyendo los tiempos de la PS2 y su SDK que era una bazofia obligando a los desarrolladores a hacer sus típicas chapuzas, que obviamente no usaban ensamblador de la GPU sino que usaban las funciones del driver del chip gráfico de PS2.
Las consolas de generaciones anteriores no tenían ningún SO. Absolutamente ninguno. Wii (no confundir con U) no tiene sistema operativo. El BIOS (masculino, no femenino) no es un sistema operativo.
La API Glide fue ideada por 3DFx pero no es exclusiva del hardware 3DFx, ha sido portada a otro hardware.
#18
No te estoy diciendo que tienen características no estándares. Precisamente te estoy diciendo lo contrario. Las Radeon R9 son un superconjunto de la GPU que llevan PS4 y Xbox One, es decir, llevan más funcionalidad. Y las APU de AMD también llevarán más funcionalidad.
Respecto a todo lo demás, erróneo, desactualizado y mentiras populares de gente sin conocimientos y de empresas sin ningún conocimiento de investigación de arquitectura.
La play3 tiene hypervisor y sistema operativo. La ps2 no. En tiempos de ps2 existía la API Glide que fue portada a otras plataformas hardware.
#19 Si no son de una generación ni de otra, no encajan ni en los drivers y apis de una ni de la otra, se tienen que ajustar las cosas porque su comportamiento es diferente, o sea, tienen características no estándares. Lo mismo que las gráficas dolphin y xenos eran tarjetas híbridas e intergeneracionales que no eran comparables con sus equivalentes en pc porque tenían características más avanzadas que la generación con la que coexistieron, pero quedaban desfasadas respecto a la generación siguiente.
¿Tu has leído los enlaces que te he pasado en serio? ¿dónde pone todo eso? ¿dónde están tus enlaces que corrigen lo que yo he puesto para hacer esas afirmaciones? ¿te has parado a pensar que todos esos datos erróneos, desactualizados y mentiras populares provienen de gente de la scene, que ha programado a pelo esas consolas y que conocen mejor sus tripas que tu y de gente que ha usado los sdks oficiales y sabe de lo que habla?
Sobre lo del SO, todas las consolas actuales tienen un sistema operativo para gestionar los recursos, antes de manera muy básica, ahora con las capacidades multimedia, los dashboard y demás, de manera bastante más compleja. Las muy viejas pasaban con una simple BIOS, porque no necesitaban más. La api glide era única y exclusiva para hardware 3dfx, que salvo en algunas recreativas no se usó más allá del pc.
#24
No estoy retorciendo ninguna palabra tuya. Estás retorciendo tú las mías, empezando porque hablas de distintas familias cuando son la misma familia. Resulta que A y C son iguales y la única diferencia es que el núcleo familiar de A tiene más dedos en las manos que los del núcleo familiar C. Los drivers no son la ropa que llevan sino los tenedores que utilizan, los cuales pueden ser usados independientemente del número de dedos en las manos. Es más, al tener más dedos los tenedores pueden aprovechar más capacidades de articulación de la mano y adoptar posturas más complejas.
El sistema es distinto pero la arquitectura es la misma y por tanto hacen exactamente lo mismo que hacen con los drivers para Windows y Linux, BSD, etcétera: tienen todos una base común, lo cual demuestra tu total desconocimiento sobre el tema y la absurdidad de tus comentarios.
Los BIOS son un sistema básico para operaciones de entrada y salida, no son un gestor de hardware. El que gestiona el hardware es el programa que hace uso de las rutinas de un BIOS.
¿La gente investiga porque le sale del alma o porque luego aplican esa investigación en el desarrollo de productos?
La gente investiga lo que puede y a veces lo que quiere. Y de ahí a que se aplique en el mercado dista un largo trecho, sobre todo de unos papers de hace bastante tiempo usando una GTX 295 con un pseudoensamblador que en todo caso ya habrá sido superado por nuevas versiones del nvcc al añadir cada vez un lenguaje C más completo, incorporando resultados de ese paper y otros (un compilador es lo que genera el ensamblador). Anda que no ha llovido desde entonces.
Ni tan siquiera aciertas en lo que es y hace un sistema operativo y en el modo en el que los recursos son asignados a los procesos y cómo éstos recursos son controlados (pista: lo hace el hardware el solito mediante interrupciones, el SO sólo realiza unas pequeñas comprobaciones) y eres ya lo suficientemente mayor como para corregirte tú mismo.
Ya te he dicho que para soportar Glide no necesitas un hardware específico. Glide ha sido portada a otro hardware, no ha sido emulada. Ahora me dirás que Wine es un emulador (Wine Is Not an Emulator). Otro grotesco fallo más de tu comentario
¿tienes más errores para mi?
Sí, todo tu absurdo comentario que ignora todo lo que digo, incluyendo el hecho de que BIOS no es femenino sino masculino. En base a eso no tienes perdón de nadie ni de nada y tus réplicas resultan insustanciales en tanto que no muestras respeto alguno, basta ésta última pregunta a la que respondo.
#25 No se usan igual porque no son iguales, no es un tenedor con menos dientes, si instalas unos drivers de A o de C para B cascará. No es "no puedo ejecutar funcionalidades que no tengo" sino que cascará porque internamente son diferentes aunque se basen en el mismo diseño, que no la misma arquitectura. Empezando porque tanto la ps4 como la xbox1 tienen una memoria diferente y una memoria extra, lo que cambia no solo la lógica de control de la memoria, sino su relación con el resto de componentes. Tu los metes en una misma familia, yo opino que los cambios son lo suficientemente importantes como para pensar que son familias distintas. Igual que la serie 5000 y la 6000 son revisiones de la misma familia, pero los cambios en la 6000 son suficientes como para separarlas. Como ya te he dicho, no es lo mismo adaptar una cosa que funciona parecida a decir: cojo los drivers y añado x pa usar nuevas funcionalidades y ya está. Es como cambiar el sentido de una calle en una ciudad. Parece un cambio chorra, pero no basta con eso, hay muchas partes que se ven afectadas con ese cambio tan tonto, tanto como para tener que reorganizar todo el tráfico. Se nota que has escrito muchos drivers para tener tan claro que yo estoy equivocado y no asumir que quizá tu estés simplificando absurdamente las cosas.
Otro asunto: windows, linux y bsd tienen maneras completamente diferentes de acceder a los recursos de la máquina. Coge un driver linux e intenta hacerlo funcionar en bsd y verás que no puede. Y eso que son primos hermanos, y que bsd consigue soportar hardware gracias a que portan los mismos de linux. Ahora piensa en todas las diferencias arquitecturales que hay entre los drivers linux y los drivers windows. Compara los tamaños, pesos y dependencias entre drivers de linux y windows. Respóndeme por qué no están funcionales todas las funcionalidades que tienen los drivers de windows en linux si los drivers son iguales o comparten la mayor parte. Podríamos decir que hay un backend diferente por arquitectura y un frontend igual para todos, hasta ahí podría concedértelo, pero meter una capa de abstracción para aislar la arquitectura subyacente en algo tan delicado y que afecte al rendimiento tanto como unos drivers gráficos es bastante duro y arriesgado. Sería viable si windows y linux fueran más similares pero son demasiado disparejos: la gestión de memoria es diferente, la gestión energética es diferente, la gestión de los buses es diferente, la comunicación con la cpu es diferente... que programar cuatro registros sea igual en uno y otro lado no implica que la gestión de los datos obtenidos sea la misma. Tanto que de hecho no es así. Si quieres una muestra, échale un ojo a los drivers de intel, que los oficiales son libres y abiertos. Intenta portarlos a windows.
Y seguirá lloviendo. La investigación es punta de lanza, gracias a papers que tu desprestigias se han desarrollado nuevos filtros, formas de hacer cálculos que mejoren la efectividad y precisión de la teselación (que si no lo recuerdas, ya estaba empezando a aparecer con la radeon original, pero se desechó porque tenía demasiadas limitaciones en esa época como la de renderizar esquinas o superficies puntiagudas y chupaba demasiados recursos, aparte de que fue una de aquellas muchas extensiones que no se llegaron a integrar en dx ni en opengl), formas de exprimir el hardware, nuevas aproximaciones a los gráficos generados por ordenador, etc. Y si, muchas cosas no se terminan aplicando, pero sirven de base para investigaciones futuras.
Es un sistema básico de operaciones de entrada y salida. Ya lo dice su nombre, para empezar, y luego porque para gestionar el hardware puedes gestionarlo a pelo si te apetece. Me cito: "La BIOS son pequeñas rutinas tipo: activa el chip este, aplica configuración, ponlo en modo de funcionamiento tal, etc. O sea, gestionar el hardware". No he dicho que sean gestores de hardware como si es un SO, sino que sirven para gestionarlo, y que por lo tanto en principio tienen una misma misión. Luego he dicho que un sistema operativo extiende esas funcionalidades para gestionar los recursos directamente, pero que en el fondo las aplicaciones ven lo mismo: una capa de abstracción para no acceder a los mismos directamente. En caso de la BIOS por facilitar la vida a los programadores y/o dar funcionalidades software para aislar el hardware subyacente (muchas veces, los programadores obvian las rutinas de la bios y realizan operaciones de inicialización y control directamente y luego al haber revisiones de consolas y cambiar los firmwares hay juegos que no funcionan, no porque el cambio de firmware afectara, sino porque el hardware ya no es el mismo y no usaban las rutinas que aportaba el firmware y hacían de abstracción para esas tareas; incluso hay veces que sin cambiar el hardware, retoques en las firmwares tienen comportamientos laterales indeseados), en caso del SO para permitir más de una tarea accediendo a los recursos pseudoconcurrentemente (o sea, solo unas cosillas como dices tu). Luego el tema de las interrupciones tiene guasa. Imaginas que un ordenador es inteligente y suelta bips y esas cosas. Todas las interrupciones hay que programarlas, son avisos de que se ha realizado alguna tarea o de que se ha llegado a un estado especial, el sistema operativo gestiona esos avisos y/o los delega al usuario para que los gestione, pero no todo va solo, así, mágicamente como tu piensas. Antes de que un timer te avise cada segundo tienes que programarlo para que te avise cada segundo. Y tienes que controlar su estado, para que cada segundo sepa que lo has atendido y que siga avisándote. Que por cierto, antes había (y seguramente haya algún trasto aún) hardware que no sabía lo que eran las interrupciones ¿cómo funcionaba entonces? ¿qué hacía el SO para controlarlo? pues lo hacía. Así que si, estás retorciendo mis palabras para que digan lo que tu quieres y darte la razón.
De nuevo: no ha sido portado a hardware, ha sido emulado por software; quita la capa de software y no funcionará. Coger las funciones que forman parte del api y rellenarlas con código que se ejecuta en otras arquitecturas o softwares de manera que imite el hardware subyacente es emular de toda la vida, coger y hacer un hardware que ejecute esa api no lo es, es ejecutar esa api en una arquitectura diferente, o sea portarlo a esa arquitectura. O lo que es lo mismo: ejecutar directx en linux es portar (coges el mismo hardware y usas la misma api, pero cambiándola para que funcione); ejecutar la api para el emotion engine en windows o en linux es emular, porque debajo no hay un emotion engine o un hardware que lo emule, lo que hay es una capa de software que lo imita. Precisamente WINE no es un emulador porque lo que hace es traducir las apis de windows en operaciones similares a otras apis pero es imposible emularlas porque no sabemos realmente qué es lo que hacen (vemos los efectos a las causas, pero los efectos colaterales pueden pasar por alto, así como las funcionalidades ocultas, que es lo que hace que haya fallos en la emulación cada vez que se tropiezan con un bug en las apis de windows, un uso no documentado o un comportamiento anómalo no descrito (que tienen que reproducir y/o buscar la forma de sortear para que los programas funcionen).
El hardware solito hay que programarlo para que haga esas cosas. El SO se encarga de eso, listillo. Una sierra se dedica a dar vueltas solitas, pero hace falta un humano o un robot o cadena de montaje para que los troncos lleguen y se corten.
Sobre el respeto, yo he dado argumentos, con pruebas, enlaces a las pruebas, de manera constructiva, explicando las cosas paso a paso, no ignorando lo que dices, sino aclarándotelo dado que das razones sin justificación alguna. Tu insultas, vas con una superioridad absurda y juzgando sin venir a cuento y encima te quejas de las formas. Ya eso es de recochineo. Espero que no me contestes más, dado que las contestaciones que das son echar balones fuera y desacreditar argumentos sin un contraargumento más allá del no tienes ni puta idea.
#26
Se usan igual porque son iguales:
http://wccftech.com/playstation-4-vs-xbox-one-vs-pc-ultimate-gpu-benchmark/
Y ahora ves a darle la chapa a otro, que ya has dado suficiente el coñazo con tus gilipolleces.
#0, lo tuyo no son las etiquetas
#0 Lo conoce todo el mundo, desde aquí hasta a Tombuctú...
El GLSL es derivado del nVidia Cg (C for graphics). Y cada driver tiene un compilador de shaders propio que aplica las optimizaciones necesarias para cada modelo de tarjeta gráfica.
El programador lo único que tiene que tener en cuenta son cosas como ancho de banda de memoria y cantidad de memoria disponibles así como la cantidad de unidades de cómputo que dispone una gráfica. Poco más debe tener en cuenta.
La PS4 y Xbox One llevan arquitectura GCN con cosas de la GCN 1.1 como tener más ACEs. Es decir, son un híbrido a medio camino entre radeon hd 7000 y radeon r9. Luego también llevan algunas pequeñas mejoras que les pueden permitir rendir algo más de lo que lo haría una GPU con el mismo número de unidades de cómputo pero nada más. Esas mejoras se añadirán a las APU 100% HSA de AMD, con la ventaja de que en un PC tendrás una tarjeta gráfica adicional para gráficos, por lo que tendrás la GPU de la APU dedicada para shaders de cómputo mientras que en PS4 y Xbox One los núcleos de cómputo de la única GPU que disponen deben tener un uso debidamente planificado y balancear con mucho cuidado los shaders de cómputo y los shaders de gráficos.
#17 ya me estás diciendo que tienen características no estándares, que evidentemente no vienen en las apis estándares. Sobre lo de que Cg inspiró a GLSL... quizá deberías leer esto (http://scalibq.wordpress.com/2010/05/15/sony%E2%80%99s-playstation-3%E2%80%99s-main-graphics-api-is-not-opengl): "...Cg, which was developed by nVidia and Microsoft, and is closely related to Direct3D’s HLSL, but NOT OpenGL’s GLSL"
Te pongo un extracto de un texto interesante (http://lukasz.dk/playstation-2-programming/an-introduction-to-ps2dev/). Es sobre la play2, pero es extrapolable a hardware más reciente:
"A funny thing about PS2DEV is that there probably is more source code for undocumented parts than there is for documented parts of the PS2. There is an ongoing joke among the most passionate PS2DEV developers, which is “We only to tools™”. What this refers to is that we only make low level tools for developers and not high level libraries which are easy to use. Since the core of PS2DEV (PS2SDK) developers has been more interested in low level programming, there have not been many graphics libraries for the PS2. I think the reason for this is that anyone who sat down and read the GS and VU manuals, would be able to do it and therefor it is not an interesting challenge, just hard work.
The really hardcore PS2 developers would write custom graphics libraries which are specialized for every part of their application, to get the maximum performance out of the PS2, especially the VUs. Since the PS2 is so flexible it is very difficult to make a powerful graphics library which works well for everything."
y sobre la play3, que ya tiene una GPU más parecida a los estándares actuales y sacado del primer enlace:
"And in fact, many games don’t even use PSGL all that much, but use the lower-level LibGCM or go down to the bare metal themselves (the advantage of a console: hardware is fixed)."
Entiendo que sobre la play4, que está más diseñada para que sea fácil programar para ella, en el inicio de ciclo se apoyen en apis del fabricante todo lo posible, pero según vayan conociendo las tripas, las compañías más gordas que quieran exprimir el hardware (y las que fabrican engines o middlewares ya lo están haciendo) van a ir a pelo en aquellas cosas que requieran un desempeño crítico.
¿Es un estándar abierto? No...pues ya sabéis el camino a casita...asco de producto comercial de directx
¿qué me quieres decir con una lista de especificaciones? ¿no te he dicho ya que los cambios no están en las unidades de procesado sino en la organización de la memoria? ¿crees, por poner un ejemplo, que dos versiones de la misma tarjeta, una agp y una pci se comunican igual con el ordenador? ¿crees que acceden a la memoria del sistema del mismo modo, que usan los mismos comandos para el bus? ¿no? ¿y por qué piensas que internamente funcionan igual una tarjeta que tiene una memoria unificada esram programable (que puede hacer de caché compartida por todas las unidades de procesado o usarse independientemente) de una tarjeta que no dispone de lo mismo y que en cambio sustituye un controlador de memoria DDR3 por uno para GDDR5, que tienen velocidades, latencias, etc. distintas? ¿crees que solo hay que cambiar un par de parámetros y ya está? ¿te das cuenta de que para acceder a configuraciones hUMA con esram hay que cambiar completamente la forma que tienes de garantizar la coherencia de las cachés dado que hay un nivel de memoria más? ¿te das cuenta de que el que sea programable añade complejidad extra que no es una simple caché? ¿te das cuenta de que hay formas de almacenar geometrías demás datos que necesita la gráfica en una memoria aparte y que tienes que controlar todo el proceso? ¿te crees que no hay cambios más que significativos en los drivers para eso, crees que no hay cambios en las apis para soportar esas cosas? Que no es solo ejecutar ese comando, es cambiar la forma de hacer todos los direccionamientos de memoria. Y una vez más está el punto de que no se programan de la misma manera esos drivers en una consola basada en windows, que tiene su gestión de memoria que en una consola basada en bsd, que tiene otra distinta, y también hay que tener en cuenta que no toda la memoria está disponible para juegos, se reserva parte para aplicaciones, así que hay que gestionar la seguridad para que las aplicaciones no puedan leer partes de la memoria, esram o la caché y extraer información sobre juegos y viceversa. Una vez más, la xbox necesita más mecanismos para controlar lo que pasa en esram, o sea, más diferencias en el hardware y en la api.
Muchos cambios que a ti te parecen triviales, porque te empeñas en señalar que las unidades de cómputo son iguales (y que por lo tanto el soporte vía drivers tengan una o dos más o menos es el mismo), y obvias aquello que las diferencia (y que las diferencia de otros sistemas no hUMA) que es la gestión de memoria).
>Tienen características estándares, el hardware es el mismo, los drivers son los mismos y la API es exactamente la misma.
No, no lo son. Las características extra que tienen respecto al estándar no son las mismas que hay en la siguiente generación, entre otras cosas porque están adaptadas a las consolas y su contexto, mientras que las que lleven las tarjetas gráficas de la siguiente generación han sido pulidas y adaptadas a los pcs. Y se usan de manera diferente, así que las apis tienen que cambiar para reflejarlo. Y los drivers son muy diferentes porque:
a) el hardware de consola es diferente. No es lo mismo hacer drivers para una arquitectura Intel de 32 bits que para una de 64 bits, que para una arquitectura IBM. Y no es lo mismo hacer drivers para una ps4 que para una xbox one, por el simple hecho de que tienen una arquitectura de memoria diferente (y seguro que más cosas, dado que es sabido que ambas tienen procesadores de apoyo y memorias extra que son diferentes entre ambas y que harán que la forma de acceder a los recursos varíe un tanto), aunque el resto de componentes sea prácticamente igual.
>No sabes de qué estás hablando.
Pasas de darme enlaces, pero no me dices en qué cosas estoy equivocado y por qué, simplemente sueltas el argumento de yo soy mejor que tu y tengo más conocimientos, sin siquiera demostrarlo con argumentos. Dame cualquier indicación de softwares que evitaban tener que hacer chapuzas a mano. Y luego dime cómo lo escribieron, porque antes de una librería o un lenguaje, hay que crearlos. Y luego asegúrame categóricamente que nadie ha tocado una línea de ensamblador en ps3 ni en xbox360, pero dándome datos. Ah, por cierto, aunque me vas a decir que nadie lo usa deberías mirar http://eprint.iacr.org/2012/137.pdf y http://renderingpipeline.com/graphics-literature/low-level-gpu-documentation/ pa hacerte una idea de cómo funciona la cosa de verdad.
>Las consolas de generaciones anteriores no tenían ningún SO
Si que ha habido máquinas anteriores a la play2 con SO ¿alguien ha dicho Dreamcast? querían incluírlo en la máquina, pero al final no viene en la máquina en si, sino en los discos de los juegos y aplicaciones (muchos traían una versión de windows ce preparada para usar directx). La xbox original también tenía SO, basado en win2000 antes de que apareciera la wii. Otras consolas tienen firmwares que hacen las veces de BIOS (que como sabrás son las rutinas básicas que permiten interactuar con el hardware y que realizan las tareas de inicialización del mismo cuando arrancas la máquina). El sistema operativo hace básicamente lo mismo que una bios, pero con más capacidades de gestión de recursos (permitiendo multitarea, por ejemplo, en lugar de dejar que los juegos usen los recursos en exclusiva), pero en las consolas antiguas o poco potentes no tenía sentido añadir más capas de abstracción. Ahora que las consolas hacen un poco de centro multimedia si tiene sentido que lo hagan.
>La API Glide fue ideada por 3DFx pero no es exclusiva del hardware 3DFx, ha sido portada a otro hardware.
Falso. Que ciertas placas incluyeran chips 3dfx no hace que la api glide se ejecute en otro hardware. Y productos que montaran chips de 3dfx más allá de las gráficas de pc y algunas recreativas no hay. Cita desde la wikipedia: "Originally developed for arcade games that included non-Intel architectures, Glide was created to handle error prone tasks like chip initialization for the programmer, but implemented nothing more than what the Voodoo hardware was directly capable of."
Vamos, que para soportar glide, tu tarjeta tiene que ser un clon de un modelo de 3dfx o montar un chip de 3dfx. Más:
"3dfx had therefore created a strong advantage for itself by aggressively promoting Glide, which was designed specifically around the Voodoo hardware, and therefore did not suffer from the performance hit of a higher level abstraction layer."
"By 2000, the improved performance of Direct3D and OpenGL on the average personal computer, coupled with the huge variety of new 3D cards on the market, the widespread support of these standard APIs by the game developer community and the closure of 3dfx, made Glide obsolete."
FIN
#22
Pero es que no hay ningún estándar. Deja de decir sandeces.
El driver es el mismo. El fabricante del hardware es el mismo. AMD ha empleado el mismo frontend para ambas consolas y ha creado los módulos necesarios para esas dos consolas.
Y nadie usa ensamblador de GPUs, prueba de ello lo tienes en http://renderingpipeline.com/graphics-literature/low-level-gpu-documentation/ y http://eprint.iacr.org/2012/137.pdf, una excelente documentación y trabajo de investigación para crear drivers para GPUs y bibliotecas como CUDA u OpenCL.
Dreamcast no tenía SO y Xbox 1 sí tenía SO, pero no PS2. Xbox 1 es posterior a PS2. Encima Xbox 1 era más potente y rendía más que PS2.
BIOS es masculino, no femenino (Basic Input Output System). El sistema operativo no hace lo mismo que un BIOS y no es una capa de abstracción mayor que un BIOS, es otra cosas distinta ni supone una pérdida de rendimiento dado que cuando un proceso entra en CPU tiene toda la CPU y el hardware para el igual que la tendría en un hardware sin sistema operativo y con un buen planificador incluso hasta el programa puede ir mejor sin caer en errores tontos del programador que tenga que planificarse el sólo todo el hardware (me parto el culo con los procesadores multinúcleo de hoy día).
Ya te he dicho las cosas en las que estás equivocado. Los softwares que evitaban hacer chapuzas son los compiladores. Si Sony y otros fabricantes de consolas no los tenían disponibles por usar software cerrado y privativo pues qué quieres que diga.
Para soportar Glide basta con que ofrezcas la misma API que Glide y la portes a tu driver/módulo de kernel de GPU.
FIN.
#23 A ver, ¿en qué sentido piensas que uso "estandar"? ¿en el de "grupo de características iguales dentro de una familia" o en el de "especificaciones de la indústria"? si es lo segundo ganas tu, pero estarías retorciendo mis palabras para que signifiquen lo que a ti te da la gana. Sobre decir sandeces, ahí van otras pocas: estoy diciendo que hay dos familias, A y C, cada una con una serie de características comunes entre todos sus miembros. A tiene tres piernas y C tiene tres brazos. Los drivers son la ropa que llevan, así que los pantalones de A no le sirven a C y las camisas de C no le sirven a A. Y que enmedio han desarrollado B, que ni es A, ni es C, porque han llegado a la conclusión de que le sobra una pierna a A, pero aún no han aprendido a desarrollar el tercer brazo, así que le han incrustado un pie en el ombligo, pero con la nueva capacidad de "dedo pulgar oponible" que C implementará en la mano extra. O sea, tiene capacidades de C, es superior a A, pero ni le sirven los pantalones ni le sirve la camisa, hay que adaptar las cosas. Luego pueden aprovechar trabajo hecho en B para hacer los pantalones para C, pero la camisa hay que hacerla nueva. Conclusión: NO son los mismos drivers ni funcionan igual, ¿se puede reaprovechar código de unas generaciones a otras? si, siempre y cuando los cambios internos no sean demasiado drásticos, pero el driver cambia y mucho. Y más cuando estás creando un driver para un sistema y una arquitectura (de la máquina) distinta. Porque no es lo mismo un driver para una consola basada en windows que una consola basada en bsd, porque la arquitectura de memoria es diferente, así que el acceso a recursos también lo es.
¿La gente investiga porque le sale del alma o porque luego aplican esa investigación en el desarrollo de productos?
Sobre Dreamcast y wince: http://www.segasaturno.com/portal/viewtopic.php?t=5724. Como ves, hay muchos juegos desarrollados sobre wince, y además del runtime tiene que haber alguien que gestione los recursos por debajo para que el runtime funcione (si, un wince optimizado para dreamcast). Que solo ejecute una tarea no quiere decir que debajo no haya un SO (mira si no los primeros iOS). BIOS es del género que me de la gana, si tu quieres que sea macho, pues chachi. BIOS es acrónimo de las rutinas básicas de entrada salida, como ves todo femenino.
La BIOS son pequeñas rutinas tipo: activa el chip este, aplica configuración, ponlo en modo de funcionamiento tal, etc. O sea, gestionar el hardware. También son atajos que resumen cosas repetitivas o muy usadas en una sola llamada, para ahorrar trabajo al programador, o una forma de abstraer capacidades hardware subyacentes para homogeneizar acceso a recursos a muy bajo nivel (las BIOS vga permitían manejar tarjetas de muchos fabricantes y con diferentes capacidades programandolas de la misma manera y accediendo a los recursos de la misma manera).
Un sistema operativo es un gestor de recursos del sistema, nada más y nada menos. Se apoya o sustituye a la BIOS porque su tarea primaria es la misma, controlar el hardware, aunque su radio de acción sea más amplio. Los programas piden recursos y el SO se encarga de reservarlos para ellos para que no haya conflictos de dos programas accediendo a los mismos recursos a la vez, y esto es lo que diferencia un sistema operativo de una bios: está pensado para que más de un proceso o programa use los recursos, y para conseguir eso se los apropia y da acceso a los recursos de manera indirecta, siendo el SO el que los controla y el que se hace responsable de lo que pase (al contrario que la bios, que los pone a la disposición del programa y se desentiende). Como ya dije, en las antiguas consolas no tenía sentido que más de un programa funcionara a la vez, así que solo habían firmwares (BIOS es la nomenclatura PC para llamar a todo firmware compatible con los IBM PC originales y así se ha ido llamando desde entonces, quizá hasta la nomenclatura es anterior).
Ya te he dicho que para soportar glide necesitas un hardware específico. Cualquier cosa que no sea eso implica emular (y eso no es soporte hardware). Glide estaba demasiado atado al hardware (por eso cada revisión del hardware tenía su propia librería glide, que implementaba esa api). Ahora glide es opensource, pero hacer drivers que soporten glide es una estupidez salvo para emulación (hay implementaciones como openglide o dgvodoo que funcionan sobre dx y ogl desde hace años). Pero es muy distinto esto que dices ahora (Para soportar Glide basta con que ofrezcas la misma API que Glide y la portes a tu driver/módulo de kernel de GPU.) que lo que dijiste antes (La API Glide fue ideada por 3DFx pero no es exclusiva del hardware 3DFx, ha sido portada a otro hardware) porque NO ha sido portada a ningún hardware, ha sido emulada por software (cambiar llamadas glide por llamadas dx o ogl es mero software por mucho que el resultado sea acelerado por hardware, crear un hardware que entienda llamadas glide es hacer un chip 3dfx-compatible, como ves son cosas muy distintas).
¿tienes más errores para mi?
y yo que pensaba que un API es un agente de la propiedad inmobiliaria je je. Lo que aprende uno cada día. fantástico artículo.