#56 Pues que hagan un remake jajajaja
#25 Eso no lo había oído. Al final con el tiempo terminan saliendo estas cosas. Gracias por el apunte.
#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.
#24 He seguido un poco el tema por Gaming Nexus, y han confirmado que algunos de los procesadores eran defectuosos y han tenido que cambiarlos (les pasó con uno de los que le mandaron para las reviews). Esperemos que no vaya a mas.
#25 Eso no lo había oído. Al final con el tiempo terminan saliendo estas cosas. Gracias por el apunte.
#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.
#20 En un primer momento dijeron que era por un tema (indeterminado) de calidad y que querían asegurarse y hacer más pruebas:
https://arstechnica.com/gadgets/2024/07/quality-issue-pushes-amds-ryzen-9000-cpu-launch-from-july-to-august/
Puede que lo del etiquetado fuese coincidencia... o que han aprovechado para hacer un poco de márqueting a costa de Intel. Quien sabe...
#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.
#24 He seguido un poco el tema por Gaming Nexus, y han confirmado que algunos de los procesadores eran defectuosos y han tenido que cambiarlos (les pasó con uno de los que le mandaron para las reviews). Esperemos que no vaya a mas.
#25 Eso no lo había oído. Al final con el tiempo terminan saliendo estas cosas. Gracias por el apunte.
#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.
Hay que recordar que lo que es open source es el kernel module, no los drivers en sí. AMD e Intel sí que publican controladores enteros open source y no sólo el modulo. Que parece que ahora nVidia es open source y nada más lejos de la realidad
#1 #2 #7 #8 Haced caso a #43
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 un cambio convenientte para nvidia (y también para los usuarios, pero como "daños colaterales") y que tarde o temprano iba a realizar. Que siga adelante y empiece a abrir otros componetes sería genial, pero muy dudoso.
La otra ventaja que tiene esto es que actualmente los drivers abiertos que antes funcionaban de aquella manera por falta de documentación, ahora tienen una base completamente funcional sobre la que trabajar, será más fácil desarrollarlos y tendrán acceso a las funcionalidades de nvidia que antes sólo podían ver desde lejos, empezando por la gestión de energía (importante porque el control de voltajes y temperaturas es lo que hace que puedas "darle caña" al hardware convenientemente y sacarle rendimiento, cosa que en muchos modelos de tarjetas de nvidia no podían arriesgarse por poder freír las tarjetas y tenían valores seguros pero que permitían rendimientos muy mediocres).
Pero vamos, buena noticia, lejos de ser LA NOTICIA que vende el titular.
#31 pues no sé qué decirte, sigue las mismas políticas de siempre. Esto del módulo de kernel abierto simplemente es modularizar, facilitarse la mantenibilidad e integración con el código de linux y poco más. Para hacernos una idea, ni siquiera se puede usar en otros unix, así que los drivers cerrados de nvidia seguirán existiendo o empezarán a dejarlos sin soporte (que la gente porte de su driver de linux a otros unix si quieren).
#24 ¿Tienes el vsync desactvado o algún problema con freesync? ¿estás en x11? muy extraño lo que comentas... yo tengo una 6600 y nunca he llegado a ver problemas de sincronización con mi monitor, incluso a grandes frecuencias.
#55 vaya pedazo de respuesta. Muchas gracias.
#1 #2 #7 #8 Haced caso a #43
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 un cambio convenientte para nvidia (y también para los usuarios, pero como "daños colaterales") y que tarde o temprano iba a realizar. Que siga adelante y empiece a abrir otros componetes sería genial, pero muy dudoso.
La otra ventaja que tiene esto es que actualmente los drivers abiertos que antes funcionaban de aquella manera por falta de documentación, ahora tienen una base completamente funcional sobre la que trabajar, será más fácil desarrollarlos y tendrán acceso a las funcionalidades de nvidia que antes sólo podían ver desde lejos, empezando por la gestión de energía (importante porque el control de voltajes y temperaturas es lo que hace que puedas "darle caña" al hardware convenientemente y sacarle rendimiento, cosa que en muchos modelos de tarjetas de nvidia no podían arriesgarse por poder freír las tarjetas y tenían valores seguros pero que permitían rendimientos muy mediocres).
Pero vamos, buena noticia, lejos de ser LA NOTICIA que vende el titular.
#31 pues no sé qué decirte, sigue las mismas políticas de siempre. Esto del módulo de kernel abierto simplemente es modularizar, facilitarse la mantenibilidad e integración con el código de linux y poco más. Para hacernos una idea, ni siquiera se puede usar en otros unix, así que los drivers cerrados de nvidia seguirán existiendo o empezarán a dejarlos sin soporte (que la gente porte de su driver de linux a otros unix si quieren).
#24 ¿Tienes el vsync desactvado o algún problema con freesync? ¿estás en x11? muy extraño lo que comentas... yo tengo una 6600 y nunca he llegado a ver problemas de sincronización con mi monitor, incluso a grandes frecuencias.
#55 vaya pedazo de respuesta. Muchas gracias.
#26 No entiendo a qué esperas. Yo llevo usando steam con Debian estable desde hace años, y desde la aparición de Protón casi todo va de cine. Además exite Heroic como frontend para Epic Y GoG, entre otros con gran compatibilidad también. No se a qué esperas para cambiarte.
#46 A un SteamOs más directo, quiero poder gestionar el 99% con el mando y olvidarme de lo demás.
#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.
#59 en las sociedades socialistas era igual ,los viejos edemas no tenian nada
El fenómeno tiene hasta canción "oficial"...
#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...
#69 lo importante es sacar todo el dinero que puedas del comprador, lo otro está en tu cabeza.
En SOC si la extensión es no quiere que ningún SO sin firmar por la empresa pueda leer o escribir la RAM tienes un ladrillo, lo mismo que apagar o encender núcleos, un SOC de 40 núcleos pequeños y 16 grandes pueden dejarlo limitado a solo un núcleo pequeño o la GPU en algo con pantalla integrada.
Alguna empresa sacará algo ceñido al estándar para que pueda funcionar con sistemas libres para evitar desarrollar software, otras van a optar por multiplicar las barreras a límites con X86 o ARM no podían.
#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.
Si no me crees a mi sobre lo de riscv, léete esto:
https://www.kernel.org/doc/html/v5.12/riscv/patch-acceptance.html
"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.
Compara con el infierno que es ARM, lleno de documentos de SOCs específicos e incompatibles entre si en mayor o menor medida:
https://www.kernel.org/doc/html/v5.12/arm/index.html
Al menos ARM64 está mejor organizado y saneado (de hecho, RiscV parte un poco de esto y lo mejora para su arquitectura):
https://www.kernel.org/doc/html/v5.12/arm64/index.html
#66 ISA no es arquitectura, ARM por lo menos tiene un penalización en precio y licencia para meter cosas a mayores fuera ARM.
La extensión si es la gestión de encendido para ahorro de energía del propio SoC o gestión de memoria, caso de Andes, significa que si no es el software propio tienes un ladrillo.
https://riscv.org/wp-content/uploads/2017/05/Tue0900-170509-AndeStarV5.pdf#page=20 En ese PDF te va quedar claro que van a querer hacer ese infierno a peor, es más barato generarlo que con ARM.
#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
#66 Quien hace silicio no se ciñe al estándar: https://patchwork.kernel.org/project/linux-riscv/patch/20231122121235.827122-9-peterlin@andestech.com/
https://lwn.net/Articles/954941/
La cuestión es quien compra este silicio precisamente lo quiere por eso, y que el consumidor final del producto pase por el aro de estar atado a soporte de la empresa compradora del silicio, de hecho esto ya ha pasado:
#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...
#69 lo importante es sacar todo el dinero que puedas del comprador, lo otro está en tu cabeza.
En SOC si la extensión es no quiere que ningún SO sin firmar por la empresa pueda leer o escribir la RAM tienes un ladrillo, lo mismo que apagar o encender núcleos, un SOC de 40 núcleos pequeños y 16 grandes pueden dejarlo limitado a solo un núcleo pequeño o la GPU en algo con pantalla integrada.
Alguna empresa sacará algo ceñido al estándar para que pueda funcionar con sistemas libres para evitar desarrollar software, otras van a optar por multiplicar las barreras a límites con X86 o ARM no podían.
#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.
#64 tú y el grueso de los consumidores quieren que sea así, quién fabrica puede querer lo contrario y pagar el desarrollo, sea propio o por una empresa externa como Sifive o Andes, para lo contrario. Por mucha filosofía que pongas el que paga manda, y si la clientela no va a castigar el caos de la incompatibilidad a propósito, ya que eso se premia en la obsolescencia, la evolución de compatibilidades a a ser peor que ARM.
Por eso openrisck, opensparck y otras que depende de una sociedad superior que es de arquitectura abierta aparte de una ISA abierta no se tocan.
Que hay núcleos y algunas arquitecturas abiertas en risc-v si, que Andes o Sifive tienen su arquitectura propia también.
#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.
Si no me crees a mi sobre lo de riscv, léete esto:
https://www.kernel.org/doc/html/v5.12/riscv/patch-acceptance.html
"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.
Compara con el infierno que es ARM, lleno de documentos de SOCs específicos e incompatibles entre si en mayor o menor medida:
https://www.kernel.org/doc/html/v5.12/arm/index.html
Al menos ARM64 está mejor organizado y saneado (de hecho, RiscV parte un poco de esto y lo mejora para su arquitectura):
https://www.kernel.org/doc/html/v5.12/arm64/index.html
#66 ISA no es arquitectura, ARM por lo menos tiene un penalización en precio y licencia para meter cosas a mayores fuera ARM.
La extensión si es la gestión de encendido para ahorro de energía del propio SoC o gestión de memoria, caso de Andes, significa que si no es el software propio tienes un ladrillo.
https://riscv.org/wp-content/uploads/2017/05/Tue0900-170509-AndeStarV5.pdf#page=20 En ese PDF te va quedar claro que van a querer hacer ese infierno a peor, es más barato generarlo que con ARM.
#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
#66 Quien hace silicio no se ciñe al estándar: https://patchwork.kernel.org/project/linux-riscv/patch/20231122121235.827122-9-peterlin@andestech.com/
https://lwn.net/Articles/954941/
La cuestión es quien compra este silicio precisamente lo quiere por eso, y que el consumidor final del producto pase por el aro de estar atado a soporte de la empresa compradora del silicio, de hecho esto ya ha pasado:
#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...
#69 lo importante es sacar todo el dinero que puedas del comprador, lo otro está en tu cabeza.
En SOC si la extensión es no quiere que ningún SO sin firmar por la empresa pueda leer o escribir la RAM tienes un ladrillo, lo mismo que apagar o encender núcleos, un SOC de 40 núcleos pequeños y 16 grandes pueden dejarlo limitado a solo un núcleo pequeño o la GPU en algo con pantalla integrada.
Alguna empresa sacará algo ceñido al estándar para que pueda funcionar con sistemas libres para evitar desarrollar software, otras van a optar por multiplicar las barreras a límites con X86 o ARM no podían.
#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 productos específicamente optimizados para ninguna arquitectura y verás que el consumo para hacer las mismas tareas está equilibrado o incluso es menor en la solución de amd). Y quitando apple, el resto de soluciones arm que han tratado de competir, no han podido (ya sea por compatibilidad/software, porque el rendimiento sin ser malo no podía compararse, etc). Del mismo modo, Intel también tiene soluciones que compiten de tú a tú con el resto en determinadas condiciones o para determinado software (optimizado).
Está claro que el problema es definir correctamente qué prestaciones necesitas y en qué entornos te mueves (soluciones de refrigeración púramente pasivas y limitadores de voltaje, etc. existen también en el mundo x86).
Volviendo al tema Risc-V, ya hay disponibles numerosas placas de desarrollo de dispositivos Risc-V, muchas más para probar cosas y desarrollar mientras se ponen al mercado productos realmente competitivos de nueva generación. Aún no ha salido un producto que sea killer usando RiscV, pero si hay alternativas relativamente competitivas respecto de algunos productos. Y RiscV tiene un importante papel en sitios donde menos pensarías. Por ejemplo, las gráficas NVIDIA tienen un controlador RISCV integrado desde 2016 que se encarga de hacer cosas que antes hacían los drivers por software, descargándolos y permitiendo bajar las latencias de ciertos procesos internos. Igualmente, todo es cuestión de pasta, se avanza más rápido cuanta más pasta tengas (que se lo pregunten a apple, por ejemplo, la pasta que se deja en desarrollar procesadores que sólo usan ellos, incluso comparada con la que se dejan fabricantes que venden y licencian sus procesadores a terceros, donde se juegan sus ingresos). A RiscV la apoyan empresas más bien emergentes (comparados con los monstruos que son los apple, qualcomm, intel, amd... y los fabricantes chinos). Y aún así, no están tan lejos en ciertas cosas comparados con "las grandes arquitecturas" y cada vez atraen más atención y recursos.
#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).
#6 Lo primero y más importante: Es estándar.
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.
#17 nada legal impide que mierdas sean mucho peores en risc-v y por nada es que los que están poniendo dinero precisamente es la característica que están vendiendo, modifico mi IP core para vendertela y hacer el sistema incompatible con otros clientes a los que les vendo mi IP, lo que viene a ser «configuracion y personalizacion».
#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.
#64 tú y el grueso de los consumidores quieren que sea así, quién fabrica puede querer lo contrario y pagar el desarrollo, sea propio o por una empresa externa como Sifive o Andes, para lo contrario. Por mucha filosofía que pongas el que paga manda, y si la clientela no va a castigar el caos de la incompatibilidad a propósito, ya que eso se premia en la obsolescencia, la evolución de compatibilidades a a ser peor que ARM.
Por eso openrisck, opensparck y otras que depende de una sociedad superior que es de arquitectura abierta aparte de una ISA abierta no se tocan.
Que hay núcleos y algunas arquitecturas abiertas en risc-v si, que Andes o Sifive tienen su arquitectura propia también.
#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.
Si no me crees a mi sobre lo de riscv, léete esto:
https://www.kernel.org/doc/html/v5.12/riscv/patch-acceptance.html
"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.
Compara con el infierno que es ARM, lleno de documentos de SOCs específicos e incompatibles entre si en mayor o menor medida:
https://www.kernel.org/doc/html/v5.12/arm/index.html
Al menos ARM64 está mejor organizado y saneado (de hecho, RiscV parte un poco de esto y lo mejora para su arquitectura):
https://www.kernel.org/doc/html/v5.12/arm64/index.html
#66 ISA no es arquitectura, ARM por lo menos tiene un penalización en precio y licencia para meter cosas a mayores fuera ARM.
La extensión si es la gestión de encendido para ahorro de energía del propio SoC o gestión de memoria, caso de Andes, significa que si no es el software propio tienes un ladrillo.
https://riscv.org/wp-content/uploads/2017/05/Tue0900-170509-AndeStarV5.pdf#page=20 En ese PDF te va quedar claro que van a querer hacer ese infierno a peor, es más barato generarlo que con ARM.
#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
#66 Quien hace silicio no se ciñe al estándar: https://patchwork.kernel.org/project/linux-riscv/patch/20231122121235.827122-9-peterlin@andestech.com/
https://lwn.net/Articles/954941/
La cuestión es quien compra este silicio precisamente lo quiere por eso, y que el consumidor final del producto pase por el aro de estar atado a soporte de la empresa compradora del silicio, de hecho esto ya ha pasado:
#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...
#17 yo hablo de mejores prestaciones no de filosofía tecnología
#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 productos específicamente optimizados para ninguna arquitectura y verás que el consumo para hacer las mismas tareas está equilibrado o incluso es menor en la solución de amd). Y quitando apple, el resto de soluciones arm que han tratado de competir, no han podido (ya sea por compatibilidad/software, porque el rendimiento sin ser malo no podía compararse, etc). Del mismo modo, Intel también tiene soluciones que compiten de tú a tú con el resto en determinadas condiciones o para determinado software (optimizado).
Está claro que el problema es definir correctamente qué prestaciones necesitas y en qué entornos te mueves (soluciones de refrigeración púramente pasivas y limitadores de voltaje, etc. existen también en el mundo x86).
Volviendo al tema Risc-V, ya hay disponibles numerosas placas de desarrollo de dispositivos Risc-V, muchas más para probar cosas y desarrollar mientras se ponen al mercado productos realmente competitivos de nueva generación. Aún no ha salido un producto que sea killer usando RiscV, pero si hay alternativas relativamente competitivas respecto de algunos productos. Y RiscV tiene un importante papel en sitios donde menos pensarías. Por ejemplo, las gráficas NVIDIA tienen un controlador RISCV integrado desde 2016 que se encarga de hacer cosas que antes hacían los drivers por software, descargándolos y permitiendo bajar las latencias de ciertos procesos internos. Igualmente, todo es cuestión de pasta, se avanza más rápido cuanta más pasta tengas (que se lo pregunten a apple, por ejemplo, la pasta que se deja en desarrollar procesadores que sólo usan ellos, incluso comparada con la que se dejan fabricantes que venden y licencian sus procesadores a terceros, donde se juegan sus ingresos). A RiscV la apoyan empresas más bien emergentes (comparados con los monstruos que son los apple, qualcomm, intel, amd... y los fabricantes chinos). Y aún así, no están tan lejos en ciertas cosas comparados con "las grandes arquitecturas" y cada vez atraen más atención y recursos.
#2 Yo creo que la mejor explicacion sobre Risc-V que es y que implica, es esta serie de artiiculo. Por si alguien quiere ampliar informacion.
https://architecnologia.es/risc-v-introduccion-a-la-isa
#6 Basicamente libertad. Seguramente las ventajas se veran mas en el futuro que ahora. O el hecho de que haya una alternativa RISC-V puede evitar que lo fabricantes propietariios de las licencias abusen.
Explicacion Mas elaborada en #17
#14 Yo entiendo que no es obligatorio como se sepa como funciona el micro por dentro. Solo que como se interactua con él. Las instrucciones que se usan y qué hacen.
#22 Excelente artículo, muchas gracias.
#40 Sí, ya lo ví. Gracias!
#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.
#48 y cuando no, también. Con el tiempo se ha visto que el software libre no es la solución sino un parche. La solución es luchar contra las patentes de software y dar la propiedad a quien la haya copiado de manera que se pueda hacer lo que les dé la gana con la copia.
#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).
#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...)
#4 Así es. Estos países no prosperan porque las multinacionales y los estados serviles a las mismas, no les dejan directa o indirectamente. Un país necesita una generación en paz como mínimo para comenzar a desarrollarse. Las migraciones son el trágico efecto secundario de nuestro bienestar.
#33 Échale un ojo al guión original:
https://thescriptlab.com/wp-content/uploads/scripts/prometheus.pdf
(aquí un resumen de las diferencias)
https://www.relatospulp.com/peliculas/analisis/211-prometheus-el-guion-original-de-jon-spaihts.html
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.