En general era una película con más sentido. Los ejecutivos de la fox presionaron para hacer cambios y metierno a Lindelof y se puso a cambiar cosas y añadir ideas y a quitar el alien de la ecuación y al final pasa lo que pasa, pierdes coherencia.
#23 Si es algún problema nos enteraremos con el tiempo. Pero lo dudo, cuando tienes a la competencia mal por haber cometido una cagada gorda, con proveedores devolviendo procesadores a mansalva y demás, no quieres ser tú el próximo y si quieres que te vean como una opción sólida y confiable. Ya es suficientemente sonrojante cagarla con el serigrafiado de los procesadores (básicamente tirar a la basura una parte de la producción y gastar un montón de pasta y tiempo en reemplazarla.
#4 Para conseguir los e-cores se dedicaron a recortarlos mucho y tampoco consiguieron niveles de eficiencia asombrosos. AMD con sus procesadores "c" mucho más similares y menos recortados que sus hermanos mayores, consiguieron mucho más sacrificando mucho menos.
#17 Si te refieres a las gráficas actuales, no son realmente malas; se han visto muy lastradas por unos drivers y un software deficiente. Aparte, las gráficas las lanzaron más pensando en el mercado del cómputo e IA, donde el software que tienen si es más competitivo y maduro y saca a relucir lo mejor del hardware. La tercera generación de esta arquitectura (recordemos que la primera apenas llegó al público general, esperaron a la segunda generación para tratar de evitar los problemas que al final tuvo), que está al caer, ya tendrá la mayor parte de los problemas resueltos o muy mitigados y mostrará un aspecto muchísimo más competitivo.
Si te refieres a las Iris y demás, intel nunca apostó en serio por ellas, simplemente eran un complemento necesario para sus procesadores y para retener el mercado de ordenadores de oficina y poco más.
#12 A Intel lo que le pasó es lo que les ha pasado a muchas tecnológicas: pusieron a mando a un burócrata o a un ejecutivo con ínfulas. Con Pat han puesto a un ingeniero que ha reconducido un poco la situación (recordemos que vienen de la era de las grandes vulnerabilidades y del reciclaje de series de procesadores, con apenas aumentos de rendimiento o características aprovechando las horas bajas de amd y llenos de actuaciones sobre el mercado muy cuestionables para imponer sus condiciones a distribuidores y fabricantes de equipos), pero al final los que mandan son los inversores y ejecutivos.
#7 El retraso de los procesadores de AMD (que fue un par de semanas, tampoco gran cosa) fue una cagada con el etiquetado, nada que ver con problemas en los procesadores en si (o sea, los procesadors eran de una serie y el etiquetado que les ponían decía que eran de otra serie). Vamos, lo necesario para retirar una partida mal etiquetada y fabricar y enviar los correctamente etiquetados.
#4 Teniendo en cuenta las fábricas e ingenieros que tiene Intel en Israel (que recordemos fueron los artífices de su linea de procesadores core, los que recuperaron la Intel fuerte tras la crisis del pentium IV), imagino que a inestabiidad en la zona, entre otros motivos, habrá tenido algo que ver.
Este titular lleva a confusión, se puede pensar que habla del driver de las tarjetas gráficas y sólo es una parte concreta. De hecho, esto no lo hace un driver libre. Eso sólo es un componete que simplemente empata las cosas con los drivers cerrados de AMD en cuanto a "libertad", o sea, la parte integrada en el kernel libre y abierta para que sea distribuído libre y abierto, mantenido y actualizado constantemente, el resto del driver cerrado a cal y canto, sólo accesible vía la distribución del fabricante, con funcionalidades cerradas, etc.
Se trata de la parte de kernel que forma parte de los drivers, un cacho de lo que en los antiguos drivers de nvidia tenías que compilar cada vez que actuaizabas a una versión nueva de kernel (que antes se tenía que hacer a mano reinstalando los drivers, luego con DKMS se hacía automáticamente porque se enganchaba a cada actualización y se hacía sin intervención del usuario). El que haya sufrido que de pronto el ordenador no te arrancara, no te pasara de la consola de texto o salieran todo tipo de problemas gráficos sabrá de lo que hablo.
La ventaja es obvia, en lugar de tener un módulo de kernel con un montón de código y unas interfaces genéricas que tenían que compilarse para cada nueva versión de kernel, ahora esta parte está integrada en el kernel, con lo que las actualizaciones de la máquina ya no te van a romper nada y la calidad del soporte de drivers y nuevas funcionalidades en linux no afectarán como antes a las gráficas nvidia.
Ahora, sólo es un componente. Todo lo que está fuera del kernel (la parte del driver que "toca" el hardware"), sigue siendo completamente cerrada. O sea, ahora nvidia sigue el mismo modelo que los drivers cerrados de AMD desde hace muchos años.
Todo lo que tenga que ver con sus tecnologías propietarias y cerradas seguirá siendo propietario y cerrado. Todo lo que tiene que ver con computación o IA o tecnologías para juegos. Esto sólo es… » ver todo el comentario
#1 Como todas las sociedades capitalistas. Y incluso diría que todas las sociedades, a la larga. El poder tiende a concentrarse en pocas manos, y el dinero es una forma de poder.
#67 ¿Pero tú entiendes el significado de la palabra extensión? ¿una cosa que es aparte del estándar y que puedes implementar o no? ¿quieres ir por favor a la ilustración de la página numerada como 25? ¿no lo ves en el dibujito, o incluso con un diagrama te pierdes?
RISC-V KERNEL -> Baseline -> Full feature y luego, fuera de todo esto "codesense, stacksafe, powerbrake, dsp/fp extensions, security extensions, custom extensions, etc."
Incluso vienen así puestas en conjuntos, para que veas y diferencies que hay capas que son superconjuntos de otras capas, y luego cosas en conjuntos completamente separados...
No ya es que ni leas tus propios enlaces... es que te lo ponen de la manera más sencilla posible y lo ignoras...
Pero es más, en la 27 dice literalmente:
Adopting RISC-V as Natural ISA Evolution: V5m+ more Andes Ext.
O sea, la v5m + extensiones de Andes
#68 De tu propio enlace:
"The Andes PMU extension provides the same mechanism as Sscofpmf, allowing us to reuse the SBI PMU driver to support event sampling and mode filtering."
¿qué más da que hagan extensiones propias? son extensiones, tú añades lo que quieras mientras la base sea la misma para todos. ¿Por qué te iban a pedir que no añadieras cosas? lo importante es que seas compatible a nivel de base, si otros fabricantes no soportan tus extensiones o no son estándar da igual. No aprovechas esas funcionalidades, pero todo sigue funcionando... no rompen nada.
"To make use of this custom PMU extension, "xandespmu" needs to be appended to the riscv,isa-extensions for each cpu node in device-tree, and enable CONFIG_ANDES_CUSTOM_PMU."
¿Y si no quieres usar esa extensión? ¡pues no la usas! no es imprescindible para tener un riscV corriendo, del mismo modo que no es imprescindible tener una de las nuevas extensiones de intel AMX para poder usar un kernel x86 en un amd... ¿necesitas soporte de intel en caso de que sus extensiones rompan? pues igual que cuando sus instrucciones de división fallaban en los pentium... ¿eso en qué afecta al resto de procesadores intel que no tienen esas extensiones o las de otros fabricantes? ¿impiden que amd pueda implementar las extensiones cuando le interese? pues eso...
#65 ¿Entiendes lo que he dicho? da igual las extensiones que añadan los fabricantes, son extensiones opcionales u optativas, la base funciona igual y un kernel de linux para riscv arrancará en cualquiera, así que puedes usarlos aunque no explotes todas sus características, igual que se hace con un x86. ¿Que el fabricante de turno podrá hacer lo que le de la gana igualmente? por supuesto. Pero sería tirarse piedras contra su propio tejado y perder soporte oficial de linux. ¿Que x86 no es la mejor arquitectura con la que compararse, teniendo en cuenta que el código de arranque se sus procesadores tiene muchísima tela que cortar? también, aunque la cosa mejorará mucho cuando el soporte a 32 bits sea eliminado más pronto que tarde en software, y quién sabe cuándo y quién dará el primer paso, en hardware.
"Additionally, the RISC-V specification allows implementors to create their own custom extensions. These custom extensions aren’t required to go through any review or ratification process by the RISC-V Foundation. To avoid the maintenance complexity and potential performance impact of adding kernel code for implementor-specific RISC-V extensions, we’ll only to accept patches for extensions that have been officially frozen or ratified by the RISC-V Foundation. (Implementors, may, of course, maintain their own Linux kernel trees containing code for any custom extensions that they wish.)"
Poder usar un kernel genérico para usar placas RiscV es una ventaja que muy pocos fabricantes pueden ignorar, saber que en el kernel sólo va a acabar lo que haya sido ratificado por la fundación o extensiones de terceros estables y probadas (como las extensiones de vulkan u opengl) y que cualquier fabricante podrá implementarlas si son útiles y necesarias también es un plus. Mantener tu propia rama de linux, drivers, etc. es lo que hace que ARM sea un caos y sea imposible mantener teléfonos actualizados y con soporte, siempre hay alguna pieza de la cadena que empieza a tener incompatibilidades o problemas con lo demás más pronto que tarde.
#19 Pero un chip RiscV debe funcionar en todos lados, otra cosa es que uses esas mierdas o las ignores. RiscV no es ARM (que licencia y olvida), la filosofía es "comparte la base tal cual, estándar y sin tocar y funcionarás en todos lados; y las mierdas que quieras añadir por tu lado, irán por separado". ¿Recuerdas que habían ordenadores pentium soportando mmx y otros que no? pues el software o aprovechaba mmx o no, pero todo seguía funcionando (más o menos lento, pero funcionaba). Con ARM esto no es así, tienes que compilar con compiladores diferentes y generar código diferente, a veces tan sustancialmente diferente que no funciona en los dispositivos ARM de la competencia o en los tuyos propios de meses atrás, las diferencias llegan a esos extremos.
#20 ¿Y de qué van las mejores prestaciones? ¿de ocultarlas bajo las soluciones de siempre (añadir cosas que aceleren otras cosas por hardware y optimizar el software propio para exprimirlas, aunque el rendimiento con el software de terceros apeste hasta que les sueltes pasta o les convenzas de que optimicen específicamente para ti) y pagar más para tener mejores tecnologías de fabricación para poder luego decir que su solución es mejor que la de los demás? ¿como lo de presumir que las arquitecturas ARM son mejores y consumen menos cuando se fabrican en los mejores nodos de fabricación y con técnicas de fabricación específicas para lograr poco consumo porque su nicho de mercado es el móvil, servidores flojitos pero con "high core count" y como mucho portátiles pero que escalan horriblemente mal?
Te voy a poner un ejemplo: ¿Sabes quién fue la primera arquitectura que apostó por muchísimos cores ligeros y poco potentes para atacar el mercado de los servidores web y java? la sun SPARC (en particular, a partir del UltraSparc T2 -8 cores con 8 hilos cada uno, hasta 64 threads simultáneas- y T3 -16 cores con 16 hilos cada uno, 128 hilos, que se dice pronto-) . Y tuvo relativo éxito, pero al final el mercado buscaba cosas más generalistas y potentes y murió. ¿Sabes qué otra arquitectura intentó algo similar? bulldozer de amd. Y falló en parte por estar fabricados con tecnología que intel podía barrer tranquilamente (aunque con gran capacidad multitarea, poco potentes y consumiendo más que los procesadores de intel). Y ojo, que hablamos de la tecnología que movió la play4.
Justamente ahora AMD tiene soluciones que aunan todo y por eso están comiéndose ciertos mercados: tienen cpus con gran cantidad de capacidad multiproceso, con muchísima potencia cada núcleo individual y con un consumo contenidísimo y mucho menor que el de los productos de sus rivales en sus mismas gamas y tecnologías de fabricación equivalentes (si, incluso comparados con apple... sácalos de… » ver todo el comentario
#52 Son cosas diferentes y atacan ámbitos diferentes. MS y otras han tenido que asociarse para permitir usar patentes en desarrollos de software libre porque se dieron cuenta de que estaban pisándose su propia prosperidad con eso (dado que las compañías propietarias hacen mucho dinero con el software libre y demandarse unas a otras por cosas que usan todas al final era una tontería).
Cada dispositivo ARM es modificado por cada empresa para añadir sus mierd... cosas, tienen software de arranque distinto, etc. Hacer un kernel ARM universal (como podría ser un x86 o un riscv) es imposible ahora mismo.
RISC-V ha tomado un camino diferente: extensiones (estándares y no estándares). RISC-V base es soportado por todos y luego cada uno soportará las extensiones que necesite. Si por lo que sea, añade extensiones no estándares, no afectaría a un kernel que soporte la base de RISC-V, simplemente no las aprovecharía.
Además, las extensiones tratan de pensarse, madurarse y estandarizarse en comité para que sean útiles, bien diseñadas y permitan añadir un valor importante al conjunto de la arquitectura. Lo contrario que ARM, vamos.
#13 GPL vale, porque promueve que se comparta lo que se desarrolle (y ahí va tanto funcionalidades como parches de seguridad; la calidad y el alcance del código sube y todos salen beneficiados) .
El problema que apunta #8 es debido a la moda de usar licencias que permiten hacer lo que quieras con los fuentes. De ahí si que hay muchísima gente que se aprovecha del trabajo de los demás sin que el resto se beneficie.
Por otro lado, nadie evita que alguien pueda cobrar o enriquecerse usando software libre; de hecho, la GPL permite y anima a cobrar por el trabajo que se realiza.
#97 Precalcular siempre es más rápido porque una vez hechos los cálculos, nunca vas a tener que repetirlos (se guardan en disco o memoria y ya está). Y eso no implica hacerlo siempre o la primera vez que ejecutas el juego, lo haces "de fábrica". De hecho, algunos aspectos de todos los niveles son "precalculados" (las luces y sombras de los escenarios de juegos de la época se generan, se dibujan y se guardan, son estáticas, se cargan con el nivel y se añaden como una capa de dibujado más). De hecho, en el quake original y muchos otros juegos, los niveles se compilaban. Eso de lenguajes de scripting dinámicos donde las cosas de un juego se evalúan sobre la marcha llegaría más tarde (a partir del unreal, probablemente el quake 2 o poco antes).
#30 El copro hacía operaciones en coma flotante muy precisas, pero también de manera muy lenta (para los estándares actuales ya ni te cuento). No tanto las operaciones en si (si no hubieran sido rápidas, no tendría sentido) sino la comunicación con el procesador (el procesador se quedaba "bloqueado" a la espera, cedía el control de ejcución al coprocesador por así decirlo y luego lo recuperaba). Esto, como comprenderás, es un lastre muy grande para un juego que quiere mover muchísimas cosas por pantalla muchas veces por segundo.
"nother point not addressed in the existing answers relates to the latency associated with accessing an external coprocessor.
The first math coprocessors, while much faster than doing the same work on a CPU, still took many clock cycles to complete each operation. The overhead (bus cycles) associated with transferring data between the two chips was "lost in the noise". In other words, there was no penalty for putting those functions in a separate chip.
However, as coprocessors got faster, this overhead became a significant bottleneck on throughput, and this is what drove integrating them directly into the CPU chip."
#2 Seguiría tratándose los síntomas y no la causa. Pero claro, las guerras de la región y los intereses de segundos y terceros países en las materias primas, etc. son cosas mucho más complejas y delicadas de abordar porque implicaría cuestionar nuestro modelo económico, social y en parte nuestro modo de vida... eso para cualquier político es un suicidio (ya les cuesta ponerle freno a las corporaciones, incluso cuando se demuestra fehacientemente que están violando leyes, acuerdos y regulaciones...)
#174 Hay juegos de windows que no funcionan en windows y si en linux...
De todos modos, no es una bala mágica, muchos dependen de implementaciones específicas de ciertas cosas (o sea, se programaron con librerías que tenían bugs de forma que se aprovechaban de ellos o los ignoraban y seguían a sus cosas). Es imposible cubrir todos los posibles casos y hacer que todo funcione (en parte porque la solución sería parchear las aplicaciones que no funcionan bien, no poner mil excepciones en la emulación de esas librerías para cubrir todos los casos).
Fíjate la que se ha armado porque AMD en sus últimos drivers, para poder ampliar el número de juegos que soportan su FSR3 (que como los DLSS, necesita que sean incorporados dentro de los propios juegos, no son una simple "capa" de post procesado) se le ocurrió que los drivers podrían coger e inyectar ese código directamente en los juegos en tiempo de ejecución (así, sin necesidad de que los juegos soportaran FSR 3.0, podías tener FSR gratis). El problema es que ciertos medios y controles antipiratería validan que el ejecutable del juego sea íntegro y no haya sido modificado (para filtrar a los hackers que hacen trampas modificando el propio juego y demás) y esto ha cantado por todos lados y muchos han sido baneados... pero vamos, lo suyo sería eso, parchear el propio juego (algo así como lo que hace gog para que ciertos juegos antiguos puedan funcionar en equipos nuevos).
#181 ¿Y qué tiene que ver el kernel con eso? justamente el kernel es la parte más conservadora de todo el sistema. Probablemente aún funcionarían cosas hechas incluso para kernels viejérrimos como los 2.4 o 2.6 en equipos actuales. ¿Qué pasa? las librerías... nadie programa a pelo sólo usando interfaces de kernel, todo el mundo echa mano de librerías, y estas mueren, cambian, se abandonan, mutan... es lo que hace que los programas dejen de funcionar en linux (o en windows... ¿o acaso cuando hay cambio de versión no hay cosas que dejan de funcionar?).
thescriptlab.com/wp-content/uploads/scripts/prometheus.pdf
(aquí un resumen de las diferencias)
www.relatospulp.com/peliculas/analisis/211-prometheus-el-guion-origina
En general era una película con más sentido. Los ejecutivos de la fox presionaron para hacer cambios y metierno a Lindelof y se puso a cambiar cosas y añadir ideas y a quitar el alien de la ecuación y al final pasa lo que pasa, pierdes coherencia.