Klony docelowe (target clones)

Kompilowanie oprogramowania natywnie na komputerze poprawiało czasy działania na CPU o około 30 % w porównaniu z gotowymi pakietami. Powodem jest to, że kompilator dokonuje specyficznych optymalizacji dla docelowego sprzętu, na którym jest kompilowany, podczas gdy gotowe pakiety muszą pozostać uniwersalne i uruchamiają bardziej zachowawcze optymalizacje ze względu na szerokie wsparcie. Zwróć uwagę, że jądra OpenCL i tak są kompilowane dla Twojego konkretnego GPU przy użyciu Twojego sterownika OpenCL, więc tam sytuacja wygląda inaczej.

W 2016 roku GCC wprowadziło klony docelowe , a w 2023 roku dołączył CLang, dla którego dodałem wsparcie w Darktable w 2019 roku tylko w niektórych częściach (w szczególności w korektorze tonalnym). Ten eksperyment nigdy dotąd nie został rozciągnięty na całe oprogramowanie.

Klony docelowe zasadniczo pozwalają zbudować różne wersje kodu, zoptymalizowane pod różne architektury sprzętowe, a oprogramowanie w czasie wykonywania wybierze właściwą do uruchomienia. Ponieważ opiera się to na ifunc, jest to wspierane tylko na Linuksie (i nawet tam nie dla wszystkich wersji libc) oraz na Mac OS Intel, więc nie oczekuj wsparcia dla Windows. Ta sama funkcja na Windows musiałaby zostać zakodowana ręcznie.

Dzięki uogólnionym klonom docelowym pakiety Ansel AppImage działają teraz znacznie szybciej, w granicach 5 % w porównaniu z natywnymi kompilacjami (czyli samodzielnym kompilowaniem). To wyciągnięta ręka do wszystkich mniej obeznanych z komputerami użytkowników, którzy nie potrafią sami skompilować oprogramowania i zwykle pokrywają się z grupą posiadającą słaby sprzęt.

Linux AppImage

2 miesiące temu naprawiono irytujący błąd wymuszający rekompilację wszystkich jąder OpenCL przy każdym uruchomieniu AppImage. Powodem było to, że AppImage montowane są w losowym kontenerze (niestabilnym pomiędzy restartami), podczas gdy kontrola integralności wykonywana na jądrach (aby rekompilować tylko wtedy, gdy się zmieniły) miała zaszytą na sztywno ścieżkę pliku binarnego. Ta obciążająca wyłącznie AppImage kara została teraz rozwiązana.

AppImage zostały zmodyfikowane, aby przyjmować argumenty wiersza poleceń i udostępniać inne pliki binarne niż główny interfejs graficzny. Pozwala to:

  1. uzyskać dzienniki debugowania poprzez ./Ansel-xxxx-x86_64.AppImage -d dev -d perf -d opencl -d verbose,
  2. przetwarzać obrazy bez interfejsu graficznego poprzez ./Ansel-xxxx-x86_64.AppImage ansel-cli input.raw output.tif
  3. wywoływać inne wewnętrzne programy (zobacz dokumentację).

Z powodu problemów z zależnościami na Ubuntu, AppImage musiał zostać zaktualizowany do Ubuntu 24.04, co sprawia, że jest teraz kompatybilny ze wszystkimi systemami Linux wspierającymi co najmniej libc 2.39. Możesz sprawdzić swoją wersję libc, uruchamiając ldd --version w terminalu. Ansel AppImage jest zatem kompatybilny z:

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

Zwróć uwagę, że Ansel AppImage nie dołącza już biblioteki OpenMP, ponieważ w dziwny sposób powodowała ona konflikt z niektórymi narzędziami do debugowania. Będzie teraz używać tej systemowej. Jeśli nie jest zainstalowana (co byłoby rzadkością na Linuksie), stanowi część ekosystemu GCC (libgomp).

Obrazy Docker

Kompilacje nocne zostały dodane również jako obrazy Docker . Pozwolą one uruchamiać ansel-cli na serwerach backendowych. Zwróć jednak uwagę, że Ansel CLI nie jest bezpieczny do uruchamiania na serwerach z publicznym dostępem do sieci, ponieważ w żaden sposób nie zapobiega wstrzykiwaniu kodu ani nie waliduje danych wejściowych użytkownika. Obrazy Docker są oparte na Ubuntu 24.04.

Jednym z możliwych zastosowań obrazów Docker byłoby uruchamianie farm renderujących, aby przenieść eksport obrazów Ansel na serwery z dużym GPU:

  • wyślij RAW i XMP z edycją na serwer,
  • odbierz powstały JPG.

W rozsądnie szybkich sieciach zapobiegłoby to kupowaniu przez użytkowników drogiego sprzętu, jeśli tylko rzadko wykorzystują go w pełni, przy jednoczesnym dzieleniu kosztu zdalnego serwera działającego 24/7 pomiędzy użytkownikami.

MacOS

Nocne kompilacje MacOS zostały dodane w październiku ubiegłego roku dla architektury Apple M (Arm64). We wrześniu 2025 roku Github dodał runnery dla MacOS 15 Sonoma na architekturze Intel. Pozwoliło to dziś dodać wsparcie Intel i386 dla nocnych kompilacji Ansel. Obie architektury są kompilowane na MacOS 15 Sonoma.

Zwróć uwagę, że architektura Apple Intel  jest planowana do wycofania przez Github w sierpniu 2027 roku, ponieważ Apple zakończyło wsparcie dla tej architektury. Po tym nie będzie już łatwego sposobu na zbudowanie Ansel dla sprzętu Apple Intel.

O nocnych kompilacjach

Nocne kompilacje są automatycznie generowane na runnerach Github (możesz myśleć o nich jak o wirtualnych serwerach, które możesz uruchamiać i zatrzymywać ze skryptów, aby wykonywać różne rzeczy), każdego ranka między 5 a 7 rano UTC. Wygenerowane pakiety są dodawane do informacji o wersji wstępnej , które działają jako repozytorium i zapewniają 1,5 roku historii kompilacji, dzięki czemu masz szansę wrócić do wcześniej działającej wersji, jeśli zmiany w kodzie nagle zepsują aplikację w sposób uniemożliwiający Ci jej używanie.

Nocne kompilacje są całkowicie zależne:

  • od Github w zakresie dostarczania runnerów,
  • od Homebrew  w zakresie dostarczania ekosystemu zależności MacOS,
  • od MSYS Pacman  w zakresie dostarczania ekosystemu zależności Windows,
  • od Ubuntu  w zakresie dostarczania ekosystemu zależności Linux.

To dużo podmiotów zewnętrznych, na których trzeba polegać, a nocne kompilacje często się psują tylko dlatego, że Github wycofał runnera albo jeden z MSYS/Ubuntu/Homebrew zmienił nazwę pakietu, usunął go lub zaktualizował do nowszej wersji, która zmienia API i psuje się z wewnętrznymi mechanizmami Ansel. Tak więc, mimo pozornej automatyzacji całego procesu, regularne utrzymanie jest wciąż potrzebne, a nocne kompilacje mogą przez pewien czas pozostawać zepsute.

Podziękowania

Chciałbym podziękować:

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