- Las CPU y GPU actuales usan eFuses y firmware firmado que bloquean funciones a nivel interno, imposibilitando activarlas con simples puentes físicos.
- La aceleración por hardware y otras características dependen del sistema operativo, drivers y BIOS, que deshabilitan recursos cuando detectan riesgos de estabilidad o compatibilidad.
- Los problemas modernos de rendimiento o arranque se diagnostican revisando alimentación, RAM, GPU, BIOS y usando códigos de error o software de reparación, no manipulando el silicio.
El mundillo del hardware ha cambiado radicalmente desde aquellos tiempos en los que bastaba con hacer un puente entre un par de pines o cortar una pista en la placa para desbloquear núcleos, activar caché extra o convertir una GPU modesta en el modelo superior. Hoy, cuando algo va mal en tu PC o tu portátil, ya no es tan fácil “trucar” el equipo a base de puentes y soldador, y la mayoría de los problemas se resuelven trasteando con drivers, BIOS o configuración del sistema, no haciendo magia en el silicio.
Ese cambio no es casual ni responde solo a que los fabricantes se hayan vuelto “tacaños”, sino a una combinación de factores: diseños mucho más complejos, integración brutal de componentes en la propia CPU o GPU, nuevos mecanismos de seguridad, control de firmware y, sobre todo, un enfoque muy estricto de validación y garantía. Todo ello se nota cuando te encuentras con casos reales como un portátil que no activa la aceleración de vídeo por hardware, una GPU que deja de funcionar tras una actualización o un PC que ni siquiera llega a dar señal en pantalla.
Por qué antes se podía “puentear” y ahora no
Durante muchos años fue relativamente habitual “desbloquear” hardware simplemente activando conexiones físicas: procesadores AMD en los que se podían liberar núcleos ocultos, GPUs capadas por BIOS que se convertían en modelos superiores o funciones de placa base que se activaban soldando o uniendo ciertos pines. Todo eso se basaba en un enfoque muy sencillo: usar el mismo chip para varios productos diferentes y limitarlo por hardware mínimo o por microcódigo muy básico.
En la actualidad, CPU y GPU se diseñan bajo una lógica de segmentación mucho más estricta. La desactivación de unidades (núcleos, CU, cachés, bloques de vídeo) se hace mediante fusibles internos (eFuses) grabados en fábrica, no con simples pistas externas en la placa. Esos fusibles se programan en la oblea para definir exactamente qué partes del chip están activas, qué frecuencias soporta, qué límites de potencia tiene y qué funciones adicionales (como ciertas instrucciones o motores de codificación) están disponibles.
Además, el firmware interno juega un papel clave. En una GPU moderna, el driver y el firmware validan en cada arranque qué recursos están certificados para uso normal. Aunque físicamente el silicio compartiera diseño con un modelo superior, si los eFuses dicen que un bloque está desactivado, el firmware ni lo ve ni lo inicializa. No hay ya una simple pista que puedas puentear con un destornillador; lo que manda es la configuración quemada a nivel de transistor.
Los fabricantes aprovechan este sistema también para gestionar el rendimiento y la garantía. Con una misma base de silicio pueden crear varios modelos, pero se aseguran de que cada uno cumpla unos límites concretos de potencia, temperatura y estabilidad. Permitir que cualquiera pudiera reactivar bloques o subir el TDP de manera “pirata” implicaría un número enorme de fallos, devoluciones y reclamaciones que ninguna marca está dispuesta a asumir.
Seguridad, firmware y bloqueo de funciones en CPU y GPU
Otro motivo por el que ya no es posible desbloquear funciones con puentes físicos es la seguridad. CPU como los AMD Ryzen o los Intel modernos incluyen zonas protegidas (PSP, Intel ME y similares) que gestionan arranque seguro, carga de firmware, criptografía y certificación de que el hardware no ha sido manipulado. Estas zonas se apoyan en claves firmadas y en eFuses que garantizan que el chip arranca en un estado “confiable”.
En el caso de las GPU ocurre algo parecido. Motores de decodificación y codificación de vídeo, soporte para códecs como HEVC o AV1, o capacidades de cómputo acelerado, están controlados por firmware cerrado y firmado. Los drivers comprueban que la combinación de hardware y firmware es válida antes de exponer esas funciones al sistema operativo. Si algo “no cuadra”, la solución que toma el sistema suele ser sencilla: deshabilitar la aceleración por hardware.
Por eso, cuando un software como un navegador o un programa de edición no puede usar la aceleración de GPU, no hay ningún truco de puentes que valga. Hace falta que sistema, controladores, BIOS/UEFI y firmware estén alineados. Si uno de esos elementos falla, el resultado se parece mucho a lo que sufren muchos usuarios: funciones atenuadas, opciones de hardware bloqueadas y aplicaciones que tiran solo de CPU aunque tengas una buena gráfica instalada.
La consecuencia práctica es clara: la “época dorada” de destripar tarjetas, puentear contactos y convertir un modelo barato en otro más caro ha pasado a la historia. En su lugar, lo que hacemos los usuarios es pelear con configuraciones, reinstalar drivers o revisar ajustes de BIOS y del propio sistema operativo para conseguir que el hardware funcione como debe.
Ejemplo real: aceleración de hardware desactivada en Linux
Un caso muy ilustrativo es el de un portátil Lenovo con un AMD Ryzen 7 PRO 7840U funcionando bajo Pop!_OS con kernel 6.8, donde tanto Firefox como Chrome aparecían con la aceleración de hardware completamente deshabilitada. No es que el chip no tuviera capacidad de sobra; de hecho, las iGPU RDNA y los motores de vídeo de estos procesadores son muy capaces. El problema era que, por la razón que fuera, el sistema no los estaba aprovechando.
En entornos Linux, la activación de la aceleración de GPU depende de varios factores simultáneos: que el kernel cuente con soporte para el hardware, que la pila gráfica (Mesa, controladores de AMD, Vulkan/OpenGL) esté actualizada y bien configurada, y que el navegador esté compilado con las banderas adecuadas para activar el offload de vídeo. Si alguno de esos elementos está a medio hacer o no se ha testeado a fondo con un modelo concreto de CPU, los desarrolladores suelen optar por dejar la aceleración desactivada por defecto.
No suele ser que “nadie se haya molestado en activarlo” de forma arbitraria, sino más bien que hay dudas de estabilidad, bugs pendientes o comportamientos raros que, desde el punto de vista del desarrollador, es mejor evitar en producción. Prefieren que el vídeo se reproduzca por CPU, aunque sea menos eficiente, antes que arriesgarse a cuelgues, glitches o pantallas negras para parte de los usuarios.
En esta clase de problemas, muchos usuarios tienden a pensar en soluciones de hardware, pero la realidad es que casi todo se juega en el terreno del software: versión de drivers, parámetros del kernel, flags de lanzamiento de los navegadores y configuración de aceleración en el escritorio. Y, a diferencia de lo que ocurría hace años, no hay forma física de forzar desde fuera que ese motor de vídeo se use: o el stack de software lo habilita, o nunca entra en juego.
