Target clones

Compilar o software nativamente no computador costumava melhorar o desempenho na CPU em cerca de 30 %, em comparação com pacotes pré-compilados. O motivo é que o compilador faz otimizações específicas para o hardware alvo no qual é compilado, enquanto os pacotes pré-compilados precisam permanecer genéricos e acionar otimizações mais conservadoras em prol de um suporte amplo. Note que os kernels OpenCL são, de qualquer forma, compilados para a sua GPU específica usando o seu driver OpenCL, então a história é diferente nesse caso.

Em 2016, o GCC introduziu os target clones , seguido em 2023 pelo CLang, para o qual adicionei suporte no Darktable em 2019 apenas em algumas partes (notavelmente, o equalizador de tons). Esse experimento nunca havia sido estendido a todo o software até agora.

Os target clones basicamente permitem compilar diferentes versões do código, otimizadas para diferentes arquiteturas de hardware, e o software escolherá a versão certa para executar em tempo de execução. Como isso depende do ifunc, só há suporte no Linux (e mesmo lá, não para todas as versões da libc) e no Mac OS Intel, então não espere suporte no Windows. O mesmo recurso no Windows teria que ser codificado manualmente.

Com os target clones generalizados, os pacotes AppImage do Ansel agora rodam significativamente mais rápido, e dentro de uma margem de 5 % em comparação com compilações nativas (ou seja, compilar você mesmo). Esta é uma mão estendida a todos os usuários menos familiarizados com computadores, que não conseguem compilar o software por conta própria e geralmente coincidem com o grupo que possui hardware fraco.

Linux AppImage

Há 2 meses, foi corrigido um bug irritante que forçava a recompilação de todos os kernels OpenCL a cada início do AppImage. O motivo era que o AppImage é montado em um contêiner aleatório (instável entre reinicializações), enquanto a verificação de integridade realizada nos kernels (para recompilar somente quando eles mudam) fixava o caminho do binário no código. Essa penalidade exclusiva do AppImage agora está resolvida.

Os AppImages foram modificados para aceitar argumentos de linha de comando e expor outros binários além da GUI principal. Isso permite:

  1. obter registros de depuração através de ./Ansel-xxxx-x86_64.AppImage -d dev -d perf -d opencl -d verbose,
  2. processar imagens sem GUI através de ./Ansel-xxxx-x86_64.AppImage ansel-cli input.raw output.tif
  3. chamar outros programas internos (veja a documentação).

Devido a problemas de dependências no Ubuntu, o AppImage teve que ser atualizado para o Ubuntu 24.04, o que o torna agora compatível com todos os sistemas Linux que suportam pelo menos a libc 2.39. Você pode verificar a sua própria versão da libc executando ldd --version em um terminal. O AppImage do Ansel é, portanto, compatível com:

  1. Ubuntu 24.04,
  2. Debian 13,
  3. Linux Mint 22,
  4. Pop!_OS 24.04,
  5. Fedora 40,
  6. openSUSE Leap 16

Note que o AppImage do Ansel não empacota mais a biblioteca OpenMP, já que ela entrava em conflito com alguns auxiliares de depuração de uma forma estranha. Ele agora usará a do sistema. Se não estiver instalada (o que seria raro no Linux), ela faz parte do ecossistema do GCC (libgomp).

Imagens Docker

Compilações noturnas também foram adicionadas como imagens Docker . Elas permitirão executar o ansel-cli em servidores de backend. Note, porém, que a Ansel CLI não é segura para rodar em servidores com acesso público à web, pois não previne injeção de código e não sanitiza as entradas do usuário de forma alguma. As imagens Docker são baseadas no Ubuntu 24.04.

Um caso de uso possível das imagens Docker seria executar fazendas de renderização para delegar as exportações de imagens do Ansel a servidores com GPUs grandes:

  • enviar o RAW e o XMP de edição para o servidor,
  • receber o JPG resultante.

Em redes razoavelmente rápidas, isso evitaria que os usuários comprassem hardware caro se só o usam raramente em seu pleno potencial, ao mesmo tempo em que compartilha o custo de um servidor remoto 24/7 entre os usuários.

MacOS

Compilações noturnas para MacOS foram adicionadas em outubro passado para a arquitetura Apple M (Arm64). Em setembro de 2025, o Github adicionou runners para o MacOS 15 Sonoma na arquitetura Intel. Isso permitiu adicionar suporte a Intel i386 para as compilações noturnas do Ansel hoje. Ambas as arquiteturas são compiladas no MacOS 15 Sonoma.

Note que a arquitetura Apple Intel  está prevista para ser descontinuada pelo Github em agosto de 2027, já que a Apple encerrou o suporte a essa arquitetura. Depois disso, não haverá uma forma fácil de compilar o Ansel para hardware Apple Intel.

Sobre as compilações noturnas

As compilações noturnas são geradas automaticamente em runners do Github (pense neles como servidores virtuais que você pode iniciar e parar a partir de scripts para executar tarefas), toda manhã entre 5 e 7 da manhã UTC. Os pacotes gerados são adicionados às notas de pré-lançamento , que funcionam como um repositório e fornecem 1,5 ano de históricos de compilação, para que você tenha a chance de reverter para uma versão que funcionava anteriormente, caso mudanças no código quebrem repentinamente a aplicação de uma forma que impeça você de usá-la.

As compilações noturnas dependem inteiramente:

  • do Github para fornecer os runners,
  • do Homebrew  para fornecer o ecossistema de dependências do MacOS,
  • do MSYS Pacman  para fornecer o ecossistema de dependências do Windows,
  • do Ubuntu  para fornecer o ecossistema de dependências do Linux.

São muitos terceiros dos quais depender, e as compilações noturnas frequentemente quebram simplesmente porque o Github descontinuou um runner ou porque o MSYS/Ubuntu/Homebrew renomeou um pacote, removeu-o ou atualizou-o para uma versão mais nova que muda a API e quebra com as partes internas do Ansel. Então, apesar da aparente automatização de todo o fluxo de trabalho, a manutenção regular ainda é necessária e as compilações noturnas podem permanecer quebradas por algum tempo.

Créditos

Gostaria de agradecer:

Translated from English by : Claude. In case of conflict, inconsistency or error, the English version shall prevail.