Casi no llego a tiempo para promocionar la «Tarde de soberanía tecnológica» que nos viene de la mano de la incansable asociación GNU/Linux València. Este viernes 30 de enero a las 17:30 en las Nave. ¿Te interesa? Sigue leyendo.

Tarde de soberanía tecnológica de la mano de GNU/Linux València

Me complace presentaros un nuevo evento de la Asociación sin Ánimo de Lucro GNU/Linux València que siguen sus actividades este 2025 con una jornada de concienciación y liberación.

En palabras de los organizadores:

La información básica es la siguiente:

Viernes 30 de Enero de 2026
¡Entrada libre!
Edificio Las Naves (Carrer Joan Verdeguer, 16, 46024, València)
17:00 Taller de instalación/ayuda GNU/Linux
17:30 Arranque de presentaciones
20:00 Finalización del evento.

Más información: GNU/Linux València

La entrada Tarde de soberanía tecnológica de la mano de GNU/Linux València se publicó primero en KDE Blog.

mjpg-streamer toma archivos JPG de cámaras web, sistemas de archivos u otros complementos de entrada compatibles con Linux-UVC y los transmite como M-JPEG a través de HTTP a navegadores web, VLC y otro software.

Mediante este software libre publicado bajo una licencia GNU GPL, que realmente es muy ligero de uso que podemos ejecutarlo en un equipo de bajos recursos como una Raspberry por ejemplo, podremos transmitir via streming vídeos que captamos con nuestros dispositivos de vídeo.

En mi caso he instalado el software en mi portátil viejo con openSUSE Tumbleweed y utilizo su webcam integrada para emitir en streaming el vídeo. Pudiéndolo ver incluso fuera de mi red local, veamos cómo.

El software lo conocí gracias a un artículo publicado en el blog Un bruto con Debian:

• https://unbrutocondebian.blogspot.com/2025/08/como-ver-mi-webcam-en-toda-mi-red.html

Así que quise probarlo yo mismo en mi openSUSE.

En ese artículo anterior, se muestra cómo compilar el software para tenerlo funcionando. En mi caso, una rápida búsqueda en los repositorios de openSUSE me dió como resultado que ya estaba disponible para utilizarlo. Así que medianta un simple comando como sudo zypper in mjpg-streamer ya lo tenía instalado en mi equipo.

Es hora de probarlo. Así que abrí la tapa de la webcam de mi equipo y ejecuté este comando

mjpg_streamer -i "input_uvc.so -d /dev/video0" -o "output_http.so -p 1234"

Mediante el argumento de -i le estoy diciendo qué dispositivo de entrada utilizar para emitir el streaming. En mi caso es /dev/vidoe0 pero ¿será igual en tu caso?

Para saberlo puedes ejecutar esto:

for device in /dev/video; do udevadm info "$device" | { grep -q 'CAPABILITIES=.:capture:' && echo "$device" ;}; done

y te dará el dispositivo que podrás utilizar como entrada.

Mediante el argumento -o le decimos que queremos que emita en http levantando un servidor al que conectarnos desde otro equipo de nuestra red. Y un puerto diferente que utilizar, en mi caso he optado por el 1234, pero puedes utilizar el que quieras.

Con esto, si todo va bien ya estará emitiendo el streaming. A mí me da algunos errores del tipo: «UVCIOC_CTRL_ADD – Error at Pan (relative): Inappropriate ioctl for device (25)» pero son más bien informativos de que algunas funcionalidades no están soportadas por el dispositivo, pero se pueden ignorar.

Ahora comprobaremos si todo está funcionando bien. Lo primero sera testearlo desde el propio equipo. Para ello abrimos un navegador y metemos esta dirección: localhost:1234/?action=stream y deberíamos ver lo que captura la webcam del portátil.

Muy bien. Ahora vamos a otro equipo de nuestra red local y vamos a ver si también podemos acceder al streaming. Ahora necesitamos poner la IP del equipo que está ejecutando el software en vez de localhost: 192.168.1.42:1234/?action=stream

¿Vemos algo? si la respuesta es sí, genial!! Si no nos conecta a esa IP pero sí lo veíamos cuando ejecutábamos localhost, entonces quizás es problema del cortafuegos. Necesitamos abrir ese puerto para poder acceder. En openSUSE ejecuté:

sudo firewall-cmd --zone=public --add-port=1234/tcp --permanent
sudo firewall-cmd --reload

Y confirmar mediante:

sudo firewall-cmd --list-ports

Donde debería aparecer algo como: tcp/1234 confirmando que el puerto está abierto. Volvemos a navegar por la url anterior: 192.168.1.42:1234/?action=stream y debería ya aparecer nuestra emisión en streaming.

Al igual que en el artículo del bruto con Debian, también tuve que aumentar el número de frames capturado para ver una secuencia más real y fluida. Así que en mi caso también lo subí a 60 frames que especificamos mediante la opción -f

¿Podemos ver ese streming desde fuera de nuestra red local?

La respuesta es sí, pero utilizando un servicio de dns dinámica y tocando en nuestro router para redirigir el tráfico que hagamos a ese puerto a la IP de nuestro equipo local (que deberá ser siempre la misma).

Para esto yo he utilizado el servicio https://freemyip.com/

Así mi desde fuera de la red puedo acceder mediante la url:

http://midominio.freemyip.com:1234/?action=stream

Si no quieres que cualquiera pueda conectarse, igual es buena idea correr mjpg-streamer con contraseña mediante la opción -c

Yo a mayores lo que hago es incrustar el streming en un documento html y le digo a mjpg-streamer que para el servidor abra ese archivo. Así en una carpeta miusuario/www/ tengo uno archivo index.html con su archivo de estilo css y todo. Y dentro del index.html incrusto el streaming mediante un bloque iframe

 http://midominio.freemyip.com:1234/?action=stream

Y al final el comando completo de mjpg-streamer en mi caso quedaría así:

mjpg_streamer -i "input_uvc.so -d /dev/video0 -f 60" -o "output_http.so -p 1234 -w /home/victorhck/www/"

Y desde el navegador iría a la dirección:

http://midominio.freemyip.com:1234/

Así si apuntas con la webcam al rincón preferido de tus gaticos les podrás ver cómo duermen durante todo el día esperando a que llegues tu para empezar a correr por toda la casa…

Enlaces de interés

• https://sourceforge.net/projects/mjpg-streamer/
• https://github.com/jacksonliam/mjpg-streamer
• https://unbrutocondebian.blogspot.com/2025/08/como-ver-mi-webcam-en-toda-mi-red.html

São Paulo, janeiro de 2026 A comunidade openSUSE deu um passo decisivo para consolidar o conceito de AI PC no ecossistema Linux com o lançamento oficial de um driver em formato RPM que habilita o uso da Unidade de Processamento Neural (NPU) presente nos processadores Intel Core Ultra. A novidade permite que notebooks e desktops executem cargas de trabalho de inteligência artificial de forma local, eficiente e energeticamente otimizada, diretamente no sistema operacional.

O pacote, batizado de linux-npu-driver, foi desenvolvido e empacotado no âmbito da iniciativa openSUSE for Innovators, passando a integrar oficialmente as distribuições openSUSE Tumbleweed, Slowroll e Leap. Com isso, o Linux passa a oferecer suporte prático a um dos pilares centrais da nova geração de PCs com IA: a aceleração dedicada por hardware.

A NPU é um acelerador especializado integrado aos processadores Intel Core Ultra, projetado para executar inferência de redes neurais com altíssima eficiência energética. Atuando de forma complementar à CPU e à GPU integrada, ela possibilita o offloading inteligente de tarefas de IA, reduzindo consumo de energia, impacto térmico e latência características especialmente relevantes em notebooks e cenários de uso contínuo.

“Os PCs com Intel Core Ultra foram concebidos desde o início para executar cargas de trabalho de inteligência artificial de forma local, eficiente e persistente”, explica Yuri Daglian, engenheiro de aplicações da Intel. “A disponibilização oficial do driver da NPU no openSUSE conecta definitivamente o hardware ao software e fortalece o ecossistema de AI PC no Linux, abrindo espaço para aplicações de IA generativa, visão computacional e modelos de linguagem rodando diretamente no dispositivo do usuário.”

Na prática, o suporte à NPU permite acelerar inferência de modelos ONNX, pipelines de visão computacional, modelos quantizados e fluxos híbridos que combinam CPU, GPU e NPU. Para o usuário final, isso significa que o sistema operacional passa a reconhecer e explorar plenamente os recursos de IA já presentes no hardware — algo que até então permanecia inacessível no Linux.

Entretanto, o uso efetivo da NPU depende também de software compatível. Atualmente, o principal caminho é o OpenVINO, toolkit de código aberto da Intel voltado à otimização e implantação de modelos de IA, que precisa ser compilado com o backend específico da NPU habilitado.

“O driver é a base de tudo. Sem ele, a NPU simplesmente não existe para o sistema operacional”, afirma Alessandro Faria, cofundador da Multicortex, embaixador do openSUSE Linux e parceiro do programa Intel Innovator, responsável pelo empacotamento do linux-npu-driver. “Como comunidade de código aberto, temos a responsabilidade de democratizar tecnologias emergentes e reduzir barreiras de acesso. Garantir que o openSUSE acompanhe a revolução da IA executada localmente faz parte desse compromisso.”

Além do driver da NPU, o próprio OpenVINO passou a estar disponível nativamente no openSUSE, resultado de um trabalho pioneiro de compatibilização entre as políticas técnicas da Intel e os padrões da distribuição. Segundo Alessandro, o processo envolveu ajustes profundos no fluxo de compilação, dependências e no modelo de instalação, viabilizando uma integração limpa e suportada oficialmente.

“O OpenVINO simplesmente não rodava no openSUSE. Primeiro foi preciso torná-lo compatível; depois, adaptar o processo de instalação para que ele funcionasse de forma nativa”, explica. “Esse é um esforço colaborativo, construído com código aberto, que não beneficia apenas o openSUSE, mas serve de referência para todo o ecossistema Linux.”

Lançado em 2018, o OpenVINO já é utilizado por centenas de milhares de desenvolvedores ao redor do mundo para acelerar inferência de IA da borda ao data center. O toolkit oferece otimização automática de hardware, recursos avançados de quantização e compressão de modelos, suporte a modelos generativos e LLMs, além de integração com tecnologias como oneAPI, oneDNN e oneTBB.

Com a infraestrutura básica agora disponível no openSUSE, a expectativa da comunidade é que cada vez mais aplicações passem a oferecer suporte nativo à NPU da Intel, consolidando a execução de inteligência artificial local, eficiente e segura diretamente no PC do usuário um dos fundamentos centrais da nova geração de AI PCs com Intel Core Ultra.

Publicação original: https://newsroom.intel.com/pt/client-computing/opensuse-passa-suportar-npu-intel-viabiliza-ia-em-pcs-com-core-ultra

Reading files and monitoring directories became a lot more efficient in recent syslog-ng releases. However, it is also needed manual configuration. Version 4.11 of syslog-ng can automatically configure the optimal setting for both.

Read more at https://www.syslog-ng.com/community/b/blog/posts/automatic-configuration-of-the-syslog-ng-wildcard-file-source

Hoy ha sido lanzada la segunda beta de Plasma 6.6. Así que, para los que disfruten de probar cosas nuevas es el momento de probar esta versión y reportar los errores que se encuentren. ¡No pierdas la oportunidad de contribuir al desarrollo de Plasma!

Lanzada la beta de Plasma 6.6

Tras los habituales meses de vida, Plasma 6.5 empieza ver languidecer su reinado. Es el momento de probar la versión de escritorio que la va a sustituir. En otras palabras, ha sido lanzada la beta de Plasma 6.6 y estas son algunas de sus mejoras extraídas de los artículos «Esta semana en Plasma»

• Inhibición de suspensión con mando: el sistema ya no entrará en modo de suspensión ni bloqueará la pantalla automáticamente mientras estés usando un controlador de videojuegos.
• Soporte nativo para sensores de luz ambiental: en los portátiles modernos (como el Framework 13 o equipos con AMD Ryzen) ahora pueden ajustar el brillo de la pantalla automáticamente según la luz de la habitación.
• Mejoras críticas en HDR: se han corregido problemas de color en juegos de Windows ejecutados a través de Wine, Proton y Steam Play, logrando que el HDR se vea con la fidelidad esperada.
• Conexión WiFi mediante código QR: ahora se puede escanear un código para conectarse a una red inalámbrica sin escribir contraseñas.
• Teclas Lentas (Slow Keys) en Wayland: implementada esta función de accesibilidad que permite definir cuánto tiempo se debe mantener pulsada una tecla para que sea válida, evitando pulsaciones accidentales.
• Efecto Zoom con puntero centrado: ahora el efecto de lupa ahora incluye un modo donde el puntero siempre se mantiene en el centro físico de la pantalla, evitando la desorientación en monitores grandes.
• Acciones globales multimedia: se han añadido nuevos atajos configurables para avanzar o retroceder (5 o 30 segundos) en cualquier reproductor multimedia compatible con el protocolo MPRIS.
• Fijación de widgets (Pins): los widgets de «Navegador Web» y «Volumen de Audio» ahora incluyen un botón de chincheta para mantener sus ventanas emergentes abiertas mientras interactúas con ellas.
• Reflejo de pantalla (Mirroring) robusto: soporte para duplicar pantallas en Wayland ha sido rediseñado para ser fluido y fiable, eliminando los fallos visuales de versiones anteriores.
• Tono de piel en Emojis: el selector de emojis permite ahora predefinir un tono de piel preferido para todos los emojis de personas y manos, evitando tener que elegirlo manualmente cada vez.

Si queréis la lista de cambios completa solo tenéis que ver el changelog.

Más información: KDE

Pruébalo y reporta errores

Todas las tareas dentro del mundo del Software Libre son importantes: desarrollar, traducir, empaquetar, diseñar, promocionar, etc. Pero hay una que se suele pasar por alto y de la que solo nos acordamos cuando las cosas no nos funcionan como debería: buscar errores.

Desde el blog te animo a que tú seas una de las personas responsables del éxito del nuevo lanzamiento de Plasma 6.6 de la Comunidad KDE. Para ello debes participar en la tarea de buscar y reportar errores, algo básico para que los desarrolladores los solucionen para que el despegue del escritorio esté bien pulido. Debéis pensar que en muchas ocasiones los errores existen porque no le han aparecido al grupo de desarrolladores ya que no se han dado las circunstancias para que lo hagan.

Para ello debes instalarte esta beta y comunicar los errores que salgan en bugs.kde.org, tal y como expliqué en su día en esta entrada del blog.

La entrada Lanzada la segunda beta de Plasma 6.6 se publicó primero en KDE Blog.

Em projetos de IA, é comum a equipe de TI usar uma GPU “padrão de homologação” na nuvem (por exemplo, NVIDIA T4 no ambiente de teste) para compilar, testar e validar o pipeline. O problema aparece quando esse mesmo binário é executado em GPUs mais novas no ambiente produtivo e o desempenho fica absurdamente abaixo do que o hardware poderia entregar (e ninguém percebe por diversos fatores).

O motivo costuma ser simples: o binário foi compilado mirando a Compute Capability errada.

A Compute Capability (CC) é o identificador (X.Y) que representa o conjunto de recursos e instruções suportados por uma geração de GPUs NVIDIA. Na tabela oficial da NVIDIA, por exemplo, a T4 é CC 7.5 e a RTX 4060 Ti é CC 8.9. A seguir, vamos entender o porquê isso importa tanto e usar o seu exemplo real para mostrar o impacto: 4,30 ms vs 0,13 ms um ganho de ~33× (≈ +3208%, frequentemente arredondado como “3300%”). https://developer.nvidia.com/cuda/gpus

O que é Compute Capability e por que ela manda no desempenho

Compute Capability não é “marketing” é um contrato técnico entre o seu código e a microarquitetura da GPU. Ela define:

• Quais instruções existem (ISA/SASS disponível naquele SM)
• Quais otimizações o compilador pode aplicar
• Quais recursos de hardware podem ser usados (ex.: instruções especializadas, caminhos de memória, operações assíncronas, etc.)
• Qual PTX (código intermediário) pode ser gerado sem “assumir” features que não existem na GPU-alvo

A NVIDIA lista CC por GPU e deixa explícito que diferentes modelos mapeiam para CC diferentes (T4=7.5; RTX 4060 Ti=8.9). Em termos práticos: compilar para CC antiga em uma GPU nova pode “capar” o compilador, porque ele precisa gerar um código que só usa features garantidas naquela CC antiga.

Como o nvcc decide o que vai rodar: PTX, SASS e “fatbinary”

O nvcc normalmente gera:

• PTX (intermediário, “assembly virtual”)
• CUBIN/SASS (binário nativo para um SM específico, ex.: sm_75, sm_89)
• Tudo isso pode ser empacotado num fatbinary dentro do executável

Na documentação do nvcc, a NVIDIA explica que o executável carrega imagens de código e, em tempo de execução, o runtime/driver escolhe a imagem mais apropriada para a GPU presente.

E aqui mora o ponto-chave:

• Se você inclui SASS nativo para a GPU (sm_89 na 4060 Ti), ela roda direto com o melhor código possível.
• Se você não inclui SASS para aquela GPU, mas inclui PTX, o driver pode fazer JIT (compilar na hora) porém limitado ao PTX e às features assumidas naquele PTX.
• Se você inclui apenas código para uma GPU mais antiga e/ou PTX “antigo”, você pode até rodar, mas deixa performance na mesa.

O artigo técnico da NASA sobre compilação CUDA resume bem o modelo em 2 estágios (PTX → CUBIN) e descreve o papel de compute_XY vs sm_XY, além do JIT e do fatbinary como estratégia de portabilidade. Este texto da NASA foi inspiração deste post: https://www.nas.nasa.gov/hecc/support/kb/compiling-cuda-applications-for-different-generations-of-nvidia-gpus-at-nas_700.html

O caso real: time compila no ambiente de homologação T4 (CC 7.5) e executa na RTX 4060 Ti (CC 8.9)

Compilação “errada” (mirando T4 / compute_75)

Um equipe compila na instância com T4 (muito usada em homologação e testes) com:

$ nvcc matmul.cu -o matmul_wrong -arch=compute_75 -gencode arch=compute_75,code=sm_75

Executando esse binário numa RTX 4060 Ti (CC 8.9), o resultado medido foi:

$ ./matmul_wrong
Tempo de execução: 4.30 ms

Compilação “certa” (mirando a GPU real do alvo / compute_89)

Agora compilando especificamente para a RTX 4060 Ti:

$ nvcc matmul.cu -o matmul_right -arch=compute_89 -gencode arch=compute_89,code=sm_89

Resultado:

$ ./matmul_right
Tempo de execução: 0.13 ms

O “ganho de 3300%” (matemática do impacto)

• Speedup (vezes mais rápido): 4,30 / 0,13 ≈ 33,08×
• “% mais rápido” (comparando contra o tempo menor): (4,30 − 0,13) / 0,13 × 100 ≈ 3207,7%
• Redução do tempo: (4,30 − 0,13) / 4,30 × 100 ≈ 97,0%

Ou seja: chamar isso de “~3300%” é um arredondamento comum o número exato pelo seu benchmark dá ~3208%.

Por que a Compute Capability errada pode causar um abismo desses?

Mesmo que o código-fonte CUDA seja igual, o código gerado pode mudar drasticamente quando você troca o alvo (sm_75 → sm_89), porque:

1. Instruções e agendamentos diferentes
   • O backend (ptxas) gera SASS específico por arquitetura. Mirar sm_89 permite escolher instruções, latências e scheduling adequados ao hardware.
2. Limitação por “conjunto mínimo de features”
   • Quando você gera PTX assumindo compute_75, você está dizendo ao compilador: “use apenas o que é garantido em CC 7.5”.
   • Mesmo rodando numa GPU CC 8.9, o caminho pode ficar preso a decisões conservadoras (ou depender mais de JIT).
3. JIT não é “milagre”: ele compila o que você deu
   • Se você entrega PTX antigo, o driver compila, mas não inventa features que o PTX/arquitetura-alvo não permitiram assumir. A própria doc do nvcc descreve que PTX pode ser embutido e compilado dinamicamente quando não há binário nativo adequado.

Homologação na nuvem ≠ alvo final

• No exemplo, a T4 (CC 7.5) é ótima para CI e testes, mas não pode ditar o “target único” se você entrega para desktops Ada (CC 8.9) e isso vale muito em pipelines de IA (inferencia, kernels custom, extensões CUDA, etc.).

A melhor prática para times: compile uma vez e rode bem em T4 e em 4060 Ti

Em vez de escolher “T4 ou 4060 Ti”, faça o executável carregar ambos:

• SASS nativo para T4 (sm_75) → sem JIT, ótimo no ambiente de teste/homologação
• SASS nativo para 4060 Ti (sm_89) → máximo desempenho no desktop
• PTX para forward-compat (opcional, mas recomendado quando você não controla todos os alvos)

A própria documentação do nvcc mostra como --generate-code/-gencode permite repetir arquiteturas e também como incluir PTX (usando code=compute_XX) para JIT quando não existir SASS correspondente.

Exemplo de “fat binary” bem pragmático para seu cenário:

$ nvcc matmul.cu -o matmul_fat \
--generate-code arch=compute_75,code=sm_75 \
--generate-code arch=compute_89,code=sm_89 \
--generate-code arch=compute_89,code=compute_89

Assim:

• Na T4, ele usa sm_75.
• Na RTX 4060 Ti, ele usa sm_89.
• Em GPUs futuras (acima de 8.9), se não houver SASS exato, ainda há PTX 8.9 para o driver compilar via JIT.

Benchmark honesto: duas dicas rápidas para não “se enganar”

Seu micro benchmark já é excelente para ilustrar o ponto, mas em artigo eu sempre recomendo mencionar:

• Warm-up: rode o kernel algumas vezes antes de medir (evita pegar JIT/cache/boost “frio”).
• Várias iterações: meça média/mediana de N execuções (evita ruído de clock/boost).

Isso não muda a mensagem principal (CC correta importa), mas dá credibilidade técnica.

O código do exemplo (para referência no artigo)

Abaixo está o kernel e a medição por cudaEvent exatamente como você forneceu (um microbenchmark simples para evidenciar diferenças de codegen/arquitetura):

#include <stdio.h>
#include <cuda.h>

__global__ void matmul_kernel(float *A, float *B, float *C, int N) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;

    if (idx < N) {
        float sum = 0.0f;
        for (int i = 0; i < N; i++) {
            sum += A[idx * N + i] * B[i * N + idx];
        }
        C[idx] = sum;
    }
}

int main() {
    const int N = 1024;
    const int size = N * N * sizeof(float);

    float *hA = (float*)malloc(size);
    float *hB = (float*)malloc(size);
    float *hC = (float*)malloc(N * sizeof(float));

    for(int i = 0; i < N*N; i++){
        hA[i] = 1.0f;
        hB[i] = 1.0f;
    }

    float *dA, *dB, *dC;
    cudaMalloc(&dA, size);
    cudaMalloc(&dB, size);
    cudaMalloc(&dC, N * sizeof(float));

    cudaMemcpy(dA, hA, size, cudaMemcpyHostToDevice);
    cudaMemcpy(dB, hB, size, cudaMemcpyHostToDevice);

    dim3 block(256);
    dim3 grid((N + block.x - 1) / block.x);

    // Medição
    cudaEvent_t start, stop;
    cudaEventCreate(&start);
    cudaEventCreate(&stop);

    cudaEventRecord(start);
    matmul_kernel<<<grid, block>>>(dA, dB, dC, N);
    cudaEventRecord(stop);

    cudaDeviceSynchronize();

    float ms = 0.0f;
    cudaEventElapsedTime(&ms, start, stop);

    printf("Tempo de execução: %.2f ms\n", ms);

    cudaMemcpy(hC, dC, N * sizeof(float), cudaMemcpyDeviceToHost);

    cudaFree(dA); cudaFree(dB); cudaFree(dC);
    free(hA); free(hB); free(hC);

    return 0;
}

Fechando: a regra de ouro

Se o seu time como no exemplo aqui, compila em T4 (CC 7.5) para homologação, mas o alvo também inclui Ada (CC 8.9), não escolha um único target.

• Compute Capability certa = performance “de graça”
• Compute Capability errada = gargalo invisível que pode custar ordens de grandeza (como seus 33×)

E o melhor: corrigir isso geralmente é só ajustar flags de build e de quebra você padroniza uma entrega que roda bem em cloud e local.

Checklist final para o time de TI (cloud + desktop)

• Não compile “só para a GPU da de testes” se o binário roda fora dela
• Gere fat binary com -gencode para todos os alvos relevantes
• Inclua PTX (ex.: code=compute_XX) quando você não controla 100% dos alvos
• Padronize isso no CMake/CI (não deixe o dev “lembrar” na mão)
• Documente o CC alvo por ambiente (homologação, dev, produção)

Conclusão

Compute Capability não é detalhe: é uma decisão de engenharia de build que pode te entregar performance “de graça” ou te fazer carregar um gargalo invisível por meses.

Em projetos de IA, é comum a equipe de TI usar uma GPU “padrão de homologação” na nuvem (por exemplo, NVIDIA T4 no ambiente de teste) para compilar, testar e validar o pipeline. O problema aparece quando esse mesmo binário é executado em GPUs mais novas no ambiente produtivo e o desempenho fica absurdamente abaixo do que o hardware poderia entregar (e ninguém percebe por diversos fatores).

O motivo costuma ser simples: o binário foi compilado mirando a Compute Capability errada.

A Compute Capability (CC) é o identificador (X.Y) que representa o conjunto de recursos e instruções suportados por uma geração de GPUs NVIDIA. Na tabela oficial da NVIDIA, por exemplo, a T4 é CC 7.5 e a RTX 4060 Ti é CC 8.9. A seguir, vamos entender o porquê isso importa tanto e usar o seu exemplo real para mostrar o impacto: 4,30 ms vs 0,13 ms um ganho de ~33× (≈ +3208%, frequentemente arredondado como “3300%”). https://developer.nvidia.com/cuda/gpus

O que é Compute Capability e por que ela manda no desempenho

Compute Capability não é “marketing” é um contrato técnico entre o seu código e a microarquitetura da GPU. Ela define:

• Quais instruções existem (ISA/SASS disponível naquele SM)
• Quais otimizações o compilador pode aplicar
• Quais recursos de hardware podem ser usados (ex.: instruções especializadas, caminhos de memória, operações assíncronas, etc.)
• Qual PTX (código intermediário) pode ser gerado sem “assumir” features que não existem na GPU-alvo

A NVIDIA lista CC por GPU e deixa explícito que diferentes modelos mapeiam para CC diferentes (T4=7.5; RTX 4060 Ti=8.9). Em termos práticos: compilar para CC antiga em uma GPU nova pode “capar” o compilador, porque ele precisa gerar um código que só usa features garantidas naquela CC antiga.

Como o nvcc decide o que vai rodar: PTX, SASS e “fatbinary”

O nvcc normalmente gera:

• PTX (intermediário, “assembly virtual”)
• CUBIN/SASS (binário nativo para um SM específico, ex.: sm_75, sm_89)
• Tudo isso pode ser empacotado num fatbinary dentro do executável

Na documentação do nvcc, a NVIDIA explica que o executável carrega imagens de código e, em tempo de execução, o runtime/driver escolhe a imagem mais apropriada para a GPU presente.

E aqui mora o ponto-chave:

• Se você inclui SASS nativo para a GPU (sm_89 na 4060 Ti), ela roda direto com o melhor código possível.
• Se você não inclui SASS para aquela GPU, mas inclui PTX, o driver pode fazer JIT (compilar na hora) porém limitado ao PTX e às features assumidas naquele PTX.
• Se você inclui apenas código para uma GPU mais antiga e/ou PTX “antigo”, você pode até rodar, mas deixa performance na mesa.

O artigo técnico da NASA sobre compilação CUDA resume bem o modelo em 2 estágios (PTX → CUBIN) e descreve o papel de compute_XY vs sm_XY, além do JIT e do fatbinary como estratégia de portabilidade. Este texto da NASA foi inspiração deste post: https://www.nas.nasa.gov/hecc/support/kb/compiling-cuda-applications-for-different-generations-of-nvidia-gpus-at-nas_700.html

O caso real: time compila no ambiente de homologação T4 (CC 7.5) e executa na RTX 4060 Ti (CC 8.9)

Compilação “errada” (mirando T4 / compute_75)

Um equipe compila na instância com T4 (muito usada em homologação e testes) com:

$ nvcc matmul.cu -o matmul_wrong -arch=compute_75 -gencode arch=compute_75,code=sm_75

Executando esse binário numa RTX 4060 Ti (CC 8.9), o resultado medido foi:

$ ./matmul_wrong
Tempo de execução: 4.30 ms

Compilação “certa” (mirando a GPU real do alvo / compute_89)

Agora compilando especificamente para a RTX 4060 Ti:

$ nvcc matmul.cu -o matmul_right -arch=compute_89 -gencode arch=compute_89,code=sm_89

Resultado:

$ ./matmul_right
Tempo de execução: 0.13 ms

O “ganho de 3300%” (matemática do impacto)

• Speedup (vezes mais rápido): 4,30 / 0,13 ≈ 33,08×
• “% mais rápido” (comparando contra o tempo menor): (4,30 − 0,13) / 0,13 × 100 ≈ 3207,7%
• Redução do tempo: (4,30 − 0,13) / 4,30 × 100 ≈ 97,0%

Ou seja: chamar isso de “~3300%” é um arredondamento comum o número exato pelo seu benchmark dá ~3208%.

Por que a Compute Capability errada pode causar um abismo desses?

Mesmo que o código-fonte CUDA seja igual, o código gerado pode mudar drasticamente quando você troca o alvo (sm_75 → sm_89), porque:

1. Instruções e agendamentos diferentes
   • O backend (ptxas) gera SASS específico por arquitetura. Mirar sm_89 permite escolher instruções, latências e scheduling adequados ao hardware.
2. Limitação por “conjunto mínimo de features”
   • Quando você gera PTX assumindo compute_75, você está dizendo ao compilador: “use apenas o que é garantido em CC 7.5”.
   • Mesmo rodando numa GPU CC 8.9, o caminho pode ficar preso a decisões conservadoras (ou depender mais de JIT).
3. JIT não é “milagre”: ele compila o que você deu
   • Se você entrega PTX antigo, o driver compila, mas não inventa features que o PTX/arquitetura-alvo não permitiram assumir. A própria doc do nvcc descreve que PTX pode ser embutido e compilado dinamicamente quando não há binário nativo adequado.

Homologação na nuvem ≠ alvo final

• No exemplo, a T4 (CC 7.5) é ótima para CI e testes, mas não pode ditar o “target único” se você entrega para desktops Ada (CC 8.9) e isso vale muito em pipelines de IA (inferencia, kernels custom, extensões CUDA, etc.).

A melhor prática para times: compile uma vez e rode bem em T4 e em 4060 Ti

Em vez de escolher “T4 ou 4060 Ti”, faça o executável carregar ambos:

• SASS nativo para T4 (sm_75) → sem JIT, ótimo no ambiente de teste/homologação
• SASS nativo para 4060 Ti (sm_89) → máximo desempenho no desktop
• PTX para forward-compat (opcional, mas recomendado quando você não controla todos os alvos)

A própria documentação do nvcc mostra como --generate-code/-gencode permite repetir arquiteturas e também como incluir PTX (usando code=compute_XX) para JIT quando não existir SASS correspondente.

Exemplo de “fat binary” bem pragmático para seu cenário:

$ nvcc matmul.cu -o matmul_fat \
--generate-code arch=compute_75,code=sm_75 \
--generate-code arch=compute_89,code=sm_89 \
--generate-code arch=compute_89,code=compute_89

Assim:

• Na T4, ele usa sm_75.
• Na RTX 4060 Ti, ele usa sm_89.
• Em GPUs futuras (acima de 8.9), se não houver SASS exato, ainda há PTX 8.9 para o driver compilar via JIT.

Benchmark honesto: duas dicas rápidas para não “se enganar”

Seu micro benchmark já é excelente para ilustrar o ponto, mas em artigo eu sempre recomendo mencionar:

• Warm-up: rode o kernel algumas vezes antes de medir (evita pegar JIT/cache/boost “frio”).
• Várias iterações: meça média/mediana de N execuções (evita ruído de clock/boost).

Isso não muda a mensagem principal (CC correta importa), mas dá credibilidade técnica.

O código do exemplo (para referência no artigo)

Abaixo está o kernel e a medição por cudaEvent exatamente como você forneceu (um microbenchmark simples para evidenciar diferenças de codegen/arquitetura):

#include <stdio.h>
#include <cuda.h>

__global__ void matmul_kernel(float *A, float *B, float *C, int N) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;

    if (idx < N) {
        float sum = 0.0f;
        for (int i = 0; i < N; i++) {
            sum += A[idx * N + i] * B[i * N + idx];
        }
        C[idx] = sum;
    }
}

int main() {
    const int N = 1024;
    const int size = N * N * sizeof(float);

    float *hA = (float*)malloc(size);
    float *hB = (float*)malloc(size);
    float *hC = (float*)malloc(N * sizeof(float));

    for(int i = 0; i < N*N; i++){
        hA[i] = 1.0f;
        hB[i] = 1.0f;
    }

    float *dA, *dB, *dC;
    cudaMalloc(&dA, size);
    cudaMalloc(&dB, size);
    cudaMalloc(&dC, N * sizeof(float));

    cudaMemcpy(dA, hA, size, cudaMemcpyHostToDevice);
    cudaMemcpy(dB, hB, size, cudaMemcpyHostToDevice);

    dim3 block(256);
    dim3 grid((N + block.x - 1) / block.x);

    // Medição
    cudaEvent_t start, stop;
    cudaEventCreate(&start);
    cudaEventCreate(&stop);

    cudaEventRecord(start);
    matmul_kernel<<<grid, block>>>(dA, dB, dC, N);
    cudaEventRecord(stop);

    cudaDeviceSynchronize();

    float ms = 0.0f;
    cudaEventElapsedTime(&ms, start, stop);

    printf("Tempo de execução: %.2f ms\n", ms);

    cudaMemcpy(hC, dC, N * sizeof(float), cudaMemcpyDeviceToHost);

    cudaFree(dA); cudaFree(dB); cudaFree(dC);
    free(hA); free(hB); free(hC);

    return 0;
}

Fechando: a regra de ouro

Se o seu time como no exemplo aqui, compila em T4 (CC 7.5) para homologação, mas o alvo também inclui Ada (CC 8.9), não escolha um único target.

• Compute Capability certa = performance “de graça”
• Compute Capability errada = gargalo invisível que pode custar ordens de grandeza (como seus 33×)

E o melhor: corrigir isso geralmente é só ajustar flags de build e de quebra você padroniza uma entrega que roda bem em cloud e local.

Checklist final para o time de TI (cloud + desktop)

• Não compile “só para a GPU da de testes” se o binário roda fora dela
• Gere fat binary com -gencode para todos os alvos relevantes
• Inclua PTX (ex.: code=compute_XX) quando você não controla 100% dos alvos
• Padronize isso no CMake/CI (não deixe o dev “lembrar” na mão)
• Documente o CC alvo por ambiente (homologação, dev, produção)

Conclusão

Compute Capability não é detalhe: é uma decisão de engenharia de build que pode te entregar performance “de graça” ou te fazer carregar um gargalo invisível por meses.

Una de las aplicaciones que utilizo de forma recurrente y que creo que se utiliza poco es Tellico, un organizador de colecciones de KDE que en realidad es un fabuloso editor bases de datos para usuarios que no dominan este tipo de estructuras. Es por ello que estoy interesado en su desarrollo y me interesa conocer la evolución de Tellico 4, su última versión que fue actualizada recientemente. Veamos cómo ha ido mejorando este software.

Evolución de Tellico 4, las novedades tras el salto a Qt6

Desde el lanzamiento de Tellico 4.0 en septiembre de 2024, esta aplicación ha evolucionado principalmente hacia la consolidación de la arquitectura Qt6/KDE Frameworks 6, al tiempo que va mejorando en la automatización de datos y su soporte multiplataforma.

El pasado 21 de enero fue anunciada su versión más reciente, la 4.1.5, que sigue añadiendo cambios y novedades mostrando el buen estado de esta magnifica aplicación. Veámos en detalle qué cosas se han mejorado en poco más de un año:

1. Transición Tecnológica (Qt6 y Qt5) Soporte Dual: Tellico 4.x ha mantenido la compatibilidad tanto con Qt5 como con Qt6. Sin embargo, la versión 4.1.5 ha sido anunciada como la última que funcionará con Qt5. De esta forma, la futura versión 4.2 requerirá obligatoriamente Qt6, lo que permitirá una mejor integración con Plasma 6 y nos ofrecerá mejoras notables.
2. Mejoras en Importación y Gestión de Imágenes Importador CSV mejorado: Tellico ahora permite cargar imágenes directamente y ofrece una opción para gestionar enlaces de imágenes (vía URL o rutas locales).
3. Actualización de GCstar: Se ha optimizado el importador de colecciones de GCstar para que pueda leer modelos de colecciones externas.
4. Actualización de Fuentes de Datos (Web): Dado que los sitios web cambian sus API con frecuencia, se han actualizado casi todos los motores de búsqueda integrados:

• OpenLibrary: Ahora permite extraer la trama (plot) de los libros y se ha optimizado la búsqueda de autores.
• iTunes: Se añadió la capacidad de especificar el país para las búsquedas y se mejoraron los resultados de películas.
• Discogs y Moviemeter: Ahora permiten configurar el tamaño de las imágenes descargadas.
• Arxiv e IGDB: Correcciones en las búsquedas por ID y actualizaciones de conexión.
• Varios: Se han ajustado las fuentes de IMDb, MusicBrainz, Filmaffinity y ComicVine para mantener su funcionamiento.

4. Interfaz y Experiencia de Usuario:
   • Nuevos atajos de teclado: Se han añadido atajos estándar de KDE para navegar entre pestañas (Anterior/Siguiente).
   • Traducciones: Se añadió un nuevo elemento de menú para cambiar el idioma de la aplicación de forma más sencilla (v4.0.1).
   • Personalización: Se incluyó un tooltip que muestra el nombre interno de los campos personalizados, útil para quienes crean sus propias plantillas.
   • Corrección en Wayland: Se solucionaron errores con el icono de la barra de tareas en sesiones de Wayland.
5. Estabilidad y Corrección de Errores Mejoras en impresión: Se corrigieron fallos críticos que cerraban la aplicación al usar la vista previa de impresión o al imprimir directamente; se han parcheado errores que causaban cierres al intentar abrir archivos truncados o dañados; se corrigió el uso de XML para arquitecturas con procesadores ARM.

¿Qué es tellico?

Cuando me inicié en el mundo de KDE, uno de los programas que más me llamaron la atención fue Tellico, un excelente gestor de colecciones que te permite personalizar los campos de una forma sencilla, práctica y rápida. Empecé a utilizarlo para organizar mi colección de libros, de cómics, de películas en DVD, etc.

Lamentablemente, mi vida se fue complicando y mi tiempo para organizar cosas desapareciendo, así que perdí de vista al magnífico programa de Robby Stephenson y dejé de utilizarlos. Hace un par de años lo volví a utilizar para llevar el control de miembros de KDE España y de mis alumnos de TFG, con excelentes resultados.

En resumidas cuentas, Tellico es el organizador definitivo de cualquier tipo de colecciones. La aplicación incorpora de serie algunos tipos de colecciones como libros, películas  cómics  juegos, sellos, vinos, etc., eso si, estas colecciones son editables, es decir, tienes la posibilidad de cambiar, borrar o añadir campos.

Más información: Tellico

La entrada Evolución de Tellico 4, las novedades tras el salto a Qt6 se publicó primero en KDE Blog.

Me congratula presentaros el episodio 65 de KDE Express, titulado «esLibre2026 José Castillo Lema – OCaml y Containerlab» donde David Marzal habla de forma distendida con José Castillo Lema sobre las charlas que realizará en esLibre 2026.

Episodio 65 de KDE Express: esLibre2026 José Castillo Lema – OCaml y Containerlab

Comenté hace ya bastante tiempo que había nacido KDE Express, un audio con noticias y la actualidad de la Comunidad KDE y del Software Libre con un formato breve (menos de 30 minutos) que complementan los que ya generaba la Comunidad de KDE España, aunque ahora estamos tomándonos un tiempo de respiro por diversos motivos, con sus ya veteranos Vídeo-Podcast que todavía podéis encontrar en Archive.org, Youtube, Ivoox, Spotify y Apple Podcast.

De esta forma, a lo largo de estos 65 episodios, promovidos principalmente por David Marzal, nos han contado un poco de todo: noticias, proyectos, eventos, etc., convirtiéndose (al menos para mi) uno de los podcast favoritos que me suelo encontrar en mi reproductor audio.

En palabras de David:

Especial esLibre 2026 Melide destacando algunas de las ponencias, hoy tenemos a José Castillo Lema:

Ingeniero de software en el equipo de Telco 5G en Red Hat, habiendo pasado por posiciones como consultor, arquitecto y líder técnico para proyectos relacionados con virtualización de redes. Ha estado diseñando e implementando soluciones IaaS/PaaS (i.e.: OpenStack y Kubernetes/OpenShift), durante los últimos 10 años, e impartiendo cursos de posgrado durante los últimos 7 años en diversos masters (Cloud Computing, Big Data, IA, Blockchain, Mobile, …) y cursos para empresas.

• Web personal: https://josecastillolema.github.io
• GitLab/GitHub: https://github.com/josecastillolema/
• kube-burner: https://www.cncf.io/projects/kube-burner/

Que nos trae dos charlas:

• OCaml vs Python: ventajas de lenguajes (verdaderamente) funcionales Charla larga (30 min)
• Web del proyecto: https://ocaml.org/
• Público objetivo: Interesados en programación y programación funcional.
• OCaml es un lenguaje de programación funcional de propósito general y tipado estático, con inferencia de tipos, tipos inductivos, pattern matching, variantes, etc. además de ser muy eficiente. En esta charla veremos las principales características del lenguaje (comparadas con código Python equivalente) y hablaremos sobre el tooling y futuro del lenguaje.
• https://propuestas.eslib.re/2026/charlas/ocaml-vs-python-ventajas-de-lenguajes-verdaderamente-funcionales

---

Containerlab: crea tu propio laboratorio de redes

• Charla larga (alrededor de 30 minutos)
• Web del proyecto: https://containerlab.dev/
• Público objetivo: Profesores, alumnos, personas interesadas en aprender redes de computadores, containers, virtualización, etc.
• Containerlab es un herramienta para orquestar y gestionar laboratorios de redes basados ​​en contenedores. Se encarga de iniciar los contenedores, crear el cableado virtual entre ellos para crear topologías de laboratorio a elección del usuario y gestionar el ciclo de vida de los laboratorios. Descubre como puedes usar la para crear ambientes interactivos en ambientes compartidos como Github Codespaces.
• https://propuestas.eslib.re/2026/charlas/containerlab-crea-tu-propio-laboratorio-de-redes

---

PD: Este es el primer episodio que colgamos con los subtitulos transcipción identificando quien habla, así que si teneis un reproducotr moderno de podcast como estos y habeis llegado hasta aquí leyendo, comentarnos algo

Por cierto, también podéis encontrarlos en Telegram: https://t.me/KDEexpress

La entrada Episodio 65 de KDE Express: esLibre2026 José Castillo Lema – OCaml y Containerlab se publicó primero en KDE Blog.

This article was written by Marcus Rueckert, Build Service Engineer at SUSE. This article originally appeared on the ‘Nordisch by Nature‘ blog under the same title and has been slightly updated for the suse.com blog. The End of Spec File Sprawl? Enter Declarative RPM For decades, the RPM spec file has been the “Swiss Army […]

The post Declarative RPM: Cleaning Up Your Spec Files appeared first on SUSE Communities.