Kompilacja Blendera pod Linux Mint 18 z cmake 6

Wstęp

Kompilacja Blendera w tej wesji systemu wydaje się wyjątkowo prosta. Całość zajmuje kilkanaście minut za pierwszym razem, a gdy przygotować sobie odpowiedni skrypt, to nawet kilka razy krócej. Zapraszam do zapoznania się z procedurą, którą każdy, kto nie boi się wpisywania poleceń na konsoli – może wykonać.

Wzorem poprzednich poradników, w których opisane są metody postępowania ze starszymi wersjami Blendera i starszymi wydaniami systemów, najpierw warto określić, co będzie nam potrzebne.

Dla kogo poradnik, i co przygotować

Jeżeli jesteś zaawansowanym użytkownikiem Linuxa, zapewne nie raz już kompilowałeś różne programy i nie jest dla Ciebie nowością że w praktyce proces ten sprowadza się do skonfigurowania źródeł, ich kompilacji, instalacji, i ewentualnie wprowadzenia usprawnień. W tym procesie robimy dokładnie to samo, czyli na początku jest odpowiednik configure (w tym przypadku cmake), potem zwykłe budowanie (make) i na końcu instalacja, która może być już opcjonalna. Ten poradnik jest przeznaczony dla osób, które już mają zainstalowanego Linuxa i nie są tak zupełnie, absolutnie początkujące. Powinny przynajmniej wiedzieć, jak uruchomić okno terminala. Oprócz elementarnej wiedzy, potrzebne będą:

  • Zainstalowany system Linux Mint 18 w wersji MATE (moja ulubiona, ale może być pewnie z dowolnym innym środowiskiem, np. Cinnamon).
  • Uruchomiony terminal w którym wykonamy wszystkie polecenia (zwykle można znaleźć w Menu takie polecenie jak Terminal lub Emulator terminala).
  • Dostęp do sieci – bezwarunkowo potrzebujemy tego do pobrania plików.

Jeżeli korzystamy z dystrybucji Linux Mint 18, to system GIT powinniśmy już mieć zainstalowany. Jeżeli nie, wystarczy zainstalować go używając managera pakietów, lub bezpośrednio w terminalu wpisać sudo apt install git. Można przy tym obserwować postęp instalacji w postaci paska postępu, co jest nowością dodaną dopiero w tej dystrybucji. Podobnie można zainstalować program cmake, jeżeli okaże się, że go nie posiadamy. Pozostałe potrzebne do kompilacji narzędzia i biblioteki zostaną pobrane podczas etapu przygotowania do kompilacji, przez skrypt install_deps.sh.

Etap 1 – pobieranie źródeł

Źródła Blendera pobieramy z głównego repozytorium kodu za pomocą git. W pokazanym poniżej oknie możemy zobaczyć zestaw wszystkich poleceń, które trzeba wykonać. Są one także dostępne na stronie Dev:Doc/Building Blender/Linux/Generic Distro/CMake w postaci listy poleceń:

mkdir ~/blender-git
cd ~/blender-git
git clone http://git.blender.org/blender.git
cd blender
git submodule update --init --recursive
git submodule foreach git checkout master
git submodule foreach git pull --rebase origin master

 

Pobieranie Blendera z repozytorium

Pobieranie Blendera z repozytorium kodu, cały proces w jednym oknie.

W odróżnieniu od poleceń na stronie cytowanej powyżej, w moim przypadku umieszczam Blendera wraz z całym kodem w katalogu ~/bin/blender-git, który w moim komputerze jest standardową lokalizacją na tego typu programy. Domyślnie byłoby to bez katalogu ~/bin.

Po pobraniu katalogu z Blenderem mamy źródła i wszystkie kody napisane przez developerów na swoim komputerze. Możemy zmieniać, co chcemy! To jest potęga Open-Source. Aby przystąpić do przygotowania systemu do kompilacji, trzeba zainstalować szereg dodatkowych pakietów z oprogramowaniem, w tym kompilatory i linkery, oraz biblioteki z których Blender korzysta (np. do obsługi filmów lub przestrzeni kolorów). Aby takie przygotowanie wykonać, musimy doinstalować i pobrać z Internetu wszystkie niezbędne zależności. Najprościej wykorzystać gotowy skrypt, który to zrobi za nas, a który nazywa się install_deps.sh.

Etap 2 – instalowanie zależności

Przechodzimy do katalogu ~/blender-git/blender (lub jak u mnie – do ~/bin/blender-git/blender za pomocą polecenia cd, jeżeli jeszcze tam nie jesteśmy). Następnie powinniśmy uruchomić skrypt konfigurujący nasze środowisko. Można uruchamiać go wiele razy, jeżeli coś się nie powiedzie, co najwyżej będą znowu pobrane pewne pliki, ale sam skrypt niczego nie powinien popsuć. Wpisujemy zgodnie z zaleceniem developerów:

build_files/build_environment/install_deps.sh

Ten skrypt uruchomiłem u siebie nieco inaczej. Po pierwsze, określiłem dodatkowe opcje, które wymuszą inne docelowe miejsca dla pobranych plików i instalacji. Wszystkie opcje zebrane są w zrzucie z okna pokazanym poniżej.

installdeps

Opcje install_deps.sh zastosowane w moim przypadku.

Działanie tych opcji jest następujące (można wywołać install_deps.sh z opcją --help, aby zobaczyć spis wszystkich możliwych opcji):

--source ścieżka

Katalog, w którym zebrane zostaną źródłowe, pobrane z internetu wersje wymaganych przez Blendera dodatkowych bibliotek. Ten katalog najlepiej trzymać gdzieś na uboczu, aby niepotrzebnie nie pałętał się na widoku – nie będziemy do niego często zaglądać. U mnie, ponieważ całość trzymam w ~/bin/blender-git, podałem ~/bin/blender-git/depssrc. W katalogu tym zebrane zostały paczki LLVM-3.4.tar.gz, CLANG-3.4.tar.gz, OpenColorIO-1.0.9.tar.gz i OpenImageIO-1.6.9.tar.gz. Wszystkie zostały także tam rozpakowane do odpowiednich podkatalogów (to typowe dla paczek stosowanych w systemach linuxowych – paczki rozpakowane tworzą katalog z całą zawartością, oczywiście to tylko konwencja).

--install ścieżka

Katalog, w którym pobrane wcześniej paczki zostaną zainstalowane po ich kompilacji. W moim przypadku ścieżkę podałem trochę myląco, bo ustawiłem ją na ~/bin/blender-git/install, co może sugerować, że jest tam zainstalowany Blender. Do tego katalogu również zbyt często zaglądać nie musimy. W przypadku mojej instalacji utworzone zostały tam katalogi ocio-1.0.9, oiio-1.6.9, llvm-3.4 oraz osd-3.0.2, wszystkie dodatkowo podlinkowane do prostych nazw ocio, oiio, llvm oraz osd. Dzięki temu możemy zmienić katalog z biblioteką np. ocio na inny, ale prowadzący do niej link pozostanie, i nie trzeba będzie niczego więcej zmieniać w przypadku ręcznego manipulowania plikami i zależnościami. Nie trzeba na szczęście niczego takiego robić, proces jest całkowicie automatyczny.

-t NUMER

Opcja ta określa ile jednoczesnych instancji kompilatora można wywołać podczas procesu kompilacji. Ten techniczny żargon oznacza tylko tyle, że po prostu nasz Blender może kompilować się szybciej, bo będzie się odbywało po kilka plików na raz. Aby uzyskać przyspieszenie, trzeba jednak posiadać procesor wielordzeniowy. Liczbę wątków kompilacji ustawiamy na o jeden większą niż liczba rdzeni w procesorze, który posiadamy. W moim przypadku kompilować się będzie 13 plików na raz bez żadnego spowolnienia, a zatem teoretycznie kompilacja przebiegnie 13 razy szybciej niż gdybym kompilował używając tylko jednego rdzenia.

--with-all

Opcja ta włącza wszystkie dodatkowe funkcje, pakiety i możliwości Blendera. Tworzy się w ten sposób po prostu full-wypasioną wersję, zawierającą wszystkie dodatkowe skrypty dołączone do dystrybucji, itp. Oczywiście jest Cycles, jest Edytor Sekwencji Wideo, jest nawet Open Shading Language (czyli Otwarty Język Cieniowania) przydatny do tworzenia własnych materiałów. Ta opcja ustawia wszystko tak, aby zostało skompilowane i począwszy od tego miejsca, część funkcji Blendera można wyłączyć. Jeżeli coś się nie kompiluje, albo nie potrzebujemy wbudowanego silnika do tworzenia gier, możemy ograniczyć tutaj planowaną kompilację.

--skip-osl

Ta opcja powoduje, że w Blenderze nie zostanie skompilowany moduł odpowiedzialny za tworzenie własnych materiałów do Cycles w języku OSL. Nie będę zatem miał możliwości programowania materiałów w tym języku, niestety. Z tego co pamiętam, nigdy nie udało mi się skompilować Blendera z tą opcją włączoną, dlatego trochę być może odruchowo ją wyłączam. Może w przyszłości dam OSL-owi szansę i sprawdzę czy może już się kompiluje bez problemów.

--skip-opencollada

Jest to druga funkcja, która u mnie nigdy nie działała poprawnie, i nie udawało mi się jej skompilować, prawdopodobnie z powodu jakichś niespełnionych zależności. Ponieważ nie potrzebuję obsługi plików w formacie DAE (czyli Collada), mogę tę opcję spokojnie wyłączyć.

--no-confirm

W ten sposób wyłączamy pytanie, czy uruchomić proces instalowania i kompilowania zależności. Skrypt domyślnie zadaje to pytanie, a ponieważ chcę zmierzyć czas wykonania (widzisz polecenie time na początku wiersza?), czas na udzielenie odpowiedzi nieco by wynik zakłócał. Gdy wszystkie opcje są określone, i znane, nie muszę dodatkowo potwierdzać co ma być zrobione. Możliwe jednak, że ta opcja ma znaczenie głębsze, i wyłącza ewentualne następne pytania, które skrypt w pewnych sytuacjach by zadał, np. przy nadpisywaniu jakichś bibliotek itp. Jednak nigdy się z tym nie spotkałem, i na luzie mogę włączyć działanie automatyczne w tym przypadku. Uruchomienie skryptu wiąże się także z użyciem sudo do zainstalowania nowych składników systemu i bibliotek. Wtedy trzeba podać swoje hasło. Jeżeli jednak w ciągu pięciu minut użyliśmy polecenia sudo wcześniej, takie pytanie nie jest zadawane i przy okazji pomiar czasu pracy nadal ma sens.

Po zakończeniu działania skryptu widać ekran mniej więcej taki, jak przedstawiony na zrzucie okna poniżej.

poinstalldeps

Zakończenie działania skryptu install_deps.sh i wyświetlenie opcji kompilacji.

Gdy skrypt zakończy pracę (u mnie na całkiem nowym systemie, gdzie trzeba było pobrać z Internetu i zainstalować wszystkie biblioteki, trwało to ponad 9 minut), w oknie terminala wyświetlone zostają ważne informacje, które wykorzystamy w następnym kroku – podczas kompilacji samego Blendera. W tym momencie mamy zarówno system, jak i źródła przygotowane do tego, aby je skompilować. Jedyne co musimy zrobić, to wykonać polecenie pokazane w oknie powyżej. Aby jednak go nie przepisywać, wystarczy wykorzystać miłą cechę systemów Linuxowych, gdzie wystarczy zaznaczyć myszą tekst, a potem poprzez kliknięcie kółkiem myszy wkleić go w jakiś plik tekstowy i następnie wykonać. Tę operację opisuję poniżej w prostych kilku krokach.

Etap 3 – kompilacja Blendera

Aby wygodnie skompilować Blendera, wystarczy podać dość długie polecenie wygenerowane przez cmake, zawierające wszystkie ustawione przez nas opcje oraz sporo dodatkowych informacji. Te informacje zawierają głównie ścieżki do dodatkowych elementów i bibliotek używanych przez Blendera. Zostaną one na końcu połączone z programem. Nie musimy przepisywać ręcznie tego polecenia, aby je wykonać. Wystarczy zaznaczyć je myszą tak jak pokazałem w poniższym oknie:

zaznaczenie

Polecenie kompilacji zaznaczone myszą. Aby zaznaczyć taki tekst w terminalu, trzeba po nim przeciągnąć lewym klawiszem myszy.

Gdy już zaznaczymy myszą odpowiedni tekst, możemy w tym samym oknie spokojnie dopisać polecenie, które stworzy plik do którego następnie zaznaczony tekst wkleimy. Aby to zrobić, wpisujemy polecenie tworzące nowy plik, w moim przypadku jest to run.sh:

cat > run.sh

Takie polecenie utworzy NOWY plik o nazwie run.sh, i będzie czekać, aż coś napiszemy. Gdy jakiś plik o tej nazwie istniał wcześniej, jego zawartość zostanie utracona. Nie pojawi się żaden dodatkowy znak zachęty – terminal będzie wyglądał tak, jakby się jakoś „zawiesił”. Możemy jednak pisać i w tym właśnie momencie należy wkleić zaznaczony wcześniej tekst. W przypadku Linux Mint 18, tekst po zaznaczeniu jest już od razu w schowku, zapamiętany, więc w żadnym razie nie wolno naciskać Ctrl+C (ta kombinacja przerwie cały proces). Wystarczy wcisnąć kółko myszy (bez kręcenia nim) w pobliżu wpisanego polecenia, aby wkleić tekst. Jeżeli to nie działa, możemy też wklejać naciskając Shift+Insert, jeżeli jeszcze mamy na klawiaturze takie klawisze. W ostatecznym wypadku można sprawdzić, czy po kliknięciu prawym klawiszem myszy w zaznaczenie będzie gdzieś tam opcja „Skopiuj” lub „Copy„. Analogicznie wklejamy. Gdy pracujemy pod Windows, a na serwer Linuxowy jesteśmy zalogowani zdalnie, te wszystkie operacje wykonywane w oknie Putty mogą działać inaczej. W Putty standardowo może być tak, że lewy klawisz myszy zaznacza tekst, a prawy klawisz myszy wkleja to, co zostało zaznaczone. Trzeba zatem wykazać tutaj odrobinę świadomości systemowej, i wiedzieć, co działa, i co się robi.

zapisaniedorun

Wklejenie zaznaczonego tekstu do pliku „run.sh„. Można wkleić naciskając kółko myszy lub (czasami działa) klawisze shift+insert. Na końcu tekstu wciskamy klawisz enter a potem ctrl+d aby zamknąć plik.

Gdy tekst już zostanie wklejony, powinien wypełnić terminal od krawędzi do krawędzi, tak jak na zrzucie okna pokazanym powyżej. Aby wpisywanie tekstu zakończyć, naciskamy klawisz Enter, aby wstawić nową linię do tekstu, a następnie wpisujemy znak końca pliku, którym w Linuxie jest Ctrl+D. Trzeba po prostu taki skrót nacisnąć. W efekcie powinniśmy zobaczyć, że powrócił nam znak zgłoszenia systemu (który u mnie pokazuje skrócony login, nazwę maszyny i ścieżkę, wszystkie w ładnych kolorach, bo tak lubię).

Ostatnim krokiem przed uruchomieniem polecenia make jest nadanie plikowi run.sh atrybutu, który pozwoli go wykonywać. Generalnie nie potrzebujemy tego, wystarczy napisać polecenie „sh run.sh”, aby wystartował, ale to dużo pisania. Prościej jest, gdy mogę wpisać po prostu „./run.sh„. Dlatego skrypt „run.sh” należy uprawomocnić poprzez nadanie mu praw pozwalających na wykonanie. Bez zbędnych szczegółów, robi się to poleceniem:

chmod +x run.sh

Po takiej akcji skrypt nie zmieni treści, ale będziemy mogli go uruchomić jak zwykły program. A wtedy wystartuje kompilacja i wykonane zostaną zapisane w skrypcie polecenia – tutaj będzie to tylko jedno, duże polecenie make. Zatem uruchamiamy skrypt, wpisując dokładnie kropkę, ukośnik, i nazwę skryptu:

./run.sh

A potem oczywiście wciskamy klawisz Enter. Skrypt powinien rozpocząć pracę od razu, a w oknie terminala pojawiać się będzie mnóstwo kolorowych napisów. U siebie robię to trochę inaczej, tak jak pokazuję w oknie poniżej:

kompilacja

Uruchomienie kompilacji Blendera z przekierowaniem standardowego wyjścia skryptu do pliku run.log. U siebie nie muszę dodawać kreski ukośnej z kropką („./„) do nazwy, ponieważ mam w specjalny sposób zdefiniowane ścieżki. W systemie domyślnie trzeba pisać nazwę z poprzedzającą ją kropką i ukośnikiem, jeżeli chce się uruchomić skrypt.

Warto tutaj zwrócić uwagę, że u siebie napisałem to polecenie w taki sposób, że zmierzony zostanie czas wykonania skryptu run.sh, a wyniki, czyli to, co ten skrypt napisze zostaną zapisane do pliku run.log. Nazwa jest dowolna. Oczywiście zapisane zostanie do pliku tylko to, co skrypt (a właściwie polecenie make) zdecyduje napisać samo z siebie, jako komunikaty. Ponieważ jest ich sporo, będzie to całkiem spory plik, natomiast w terminalu się one nie pojawią. Dzięki temu nie zobaczę masy kolorowego tekstu, który oglądałem wiele razy przy poprzednich kompilacjach. Operacja wykonywana przez znak „>” to przekierowanie – wszystkie komunikaty zamiast na terminal, trafią do pliku, gdzie mogę je potem spokojnie przeczytać, nawet po roku. Działanie tego przekierowania jest jednak bardzo sprytne. Tylko normalne teksty, i zwykłe komunikaty zostaną wysłane do pliku. Program make potrafi także wypisać informacje, które mają inne znaczenie – są to ostrzeżenia oraz błędy. Takie informacje wypisywane są innym kanałem, który też trafi na terminal, i nie będzie wysłany do pliku. W efekcie widzę o wiele mniej informacji, i są to tylko i wyłącznie błędy, ostrzeżenia lub jakieś inne ważne rzeczy. Okno z takim rodzajem „raportu” wygląda podobnie do normalnego okna w którym odbywa się kompilacja, ale tekstu jest jednak mniej. Gdyby Blender skompilował się absolutnie bez żadnego ostrzeżenia, to nie powinno być żadnych napisów, jednak taki przypadek chyba nie jest możliwy już od bardzo dawna…

podgladbledow

Wygląd i filtrowana treść okna widocznego podczas kompilacji Blendera.

Podczas procesu kompilacji powstaje oczywiście Blender, oraz plik run.log, w którym zbierane są normalne komunikaty o przebiegu kompilacji. Jeżeli chcemy zobaczyć, co w tym pliku się pojawia, to możemy zrobić to np. w drugim oknie, wpisując polecenie:

tail -f run.log

Polecenie to otwiera plik run.log, wypisuje ostatnie dziesięć wierszy, i czeka, aż pojawią się w pliku nowe dane, które natychmiast są znowu wypisywane. Dzięki temu możemy oglądać co w pliku pojawia się w czasie rzeczywistym – podobnie, jakbyśmy oglądali po prostu terminal bez logowania wpisów do pliku. Polecenie pokazane jest poniżej w oknie.

podgladloga

Sposób na wyświetlenie zawartości pliku z logiem z kompilacji. Polecenie tail działa do momentu wciśnięcia Ctrl+C.

Wynik działania polecenia tail to po prostu wyświetlenie zawartości pliku run.log, który wypełnia się w trakcie kompilacji tekstem. Można dzięki temu wiedzieć, która część Blendera kompiluje się właśnie w tej chwili. Widać także ogólny procent postępu kompilacji pokazywany przez make.

podgladkompilacji

Postęp kompilacji widoczny po wyświetleniu loga. Widać, że kompilowane są różne elementy Blendera na raz, dzięki opcji -t.

Po zakończeniu kompilacji, jeżeli nie było błędów, naszym oczom ukaże się miły dla oka komunikat (zgadnij, w którym oknie?):

udanakompilacja2

Ostatnie komunikaty kompilacji, oraz informacja, że „pomyślnie zbudowano Blendera”.

W drugim oknie także będzie widoczna interesująca informacja, dzięki poleceniu time, które użyte zostało wcześniej. Dowiadujemy się, jak długo trwało budowanie Blendera. W moim przypadku pierwsza kompilacja trwała prawie 4 minuty, i Blender jest gotowy!

udanakompilacja1

Informacja o długości czasu kompilacji, widoczna dzięki użyciu polecenia time, które po prostu uruchamia proces i mierzy czas jego wykonania.

sprawdzanieczydziala

Zawartość katalogu build_linux po udanej kompilacji Blendera.

Czy mamy gotowego do pracy Blendera? Tak. Ale należy zauważyć, że jest to Blender skompilowany z opcjami domyślnymi w pewnym sensie, mimo ustawionych przez nas zależności w install_deps.sh. Taki Blender w postaci całego pakietu jest po zakończonej kompilacji umieszczany w katalogu build_linux, jak widać poniżej. Sam plik wykonywalny Blendera umieszczany jest w podkatalogu bin. Jest to dość typowe dla systemów Linuxowych, i takiego Blendera można zainstalować w pełni systemowo lub używać lokalnie z tego katalogu w którym jest umieszczony. Zobacz okno poniżej, gdzie wylistowałem (za pomocą polecenia ls) zawartość build_linux, oraz build_linux/bin.

W praktyce robię trochę inaczej. Polecenie make, które uruchamia cały złożony proces kompilacji i linkowania, oprócz parametrów, które już ma wpisane (te wszystkie zmienne definiowane po opcji -D), może także przyjąć jeszcze jedno malutkie słowo, które określa rodzaj wykonywanej kompilacji. W przypadku domyślnym, Blender jest instalowany do katalogu build_linux i pokazałem ten przypadek powyżej. Gdy jednak dodać do polecenia make słowo full, napisane na końcu, powstaje pełna, zmaksymalizowana wersja Blendera, i jest ona umieszczona w katalogu build_linux_full. Można mieć na uwadze, że ta wersja jest najpełniejszą z możliwych, w danej gałęzi kodu (jest to pełna gałąź master).

Aby sprawdzić, czy Blender skompilowany domyślnie (lub z opcją full) działa, wystarczy go uruchomić. Po uruchomieniu powinniśmy zobaczyć nasz ulubiony program i wersję z datą ostatniej modyfikacji:

dziala

Wygląd Blendera skompilowanego opisaną w poradniku metodą.

Trzeba mieć na uwadze, że tak skompilowany Blender ma wbudowany silnik gier, obsługę edytora wideo, a także Cycles. Jednakże wsparcie dla kart graficznych nie jest włączone, i Cycles będzie potrafił renderować sceny tylko przy wykorzystaniu procesora. W przypadku posiadania odpowiednio nowej karty graficznej firmy NVIDIA, można pokusić się o wykorzystanie jej mocy do przyspieszenia obliczeń związanych z renderowaniem. W tym celu nie trzeba nawet rekompilować Blendera! Wszystko, co trzeba jest już gotowe. Brakuje tylko odpowiednich zależności w systemie, które – nie wiem dlaczego – nie są instalowane przez skrypt install_deps.sh, i trzeba to zrobić samemu.

Uruchamianie Cycles i zaawansowane informacje

Aby umożliwić Cycles renderowanie z wykorzystaniem GPU (ang. Graphics Processing Unit – Jednostka Przetwarzania Grafiki), trzeba doinstalować do systemu bibliotekę wspierającą kompilację kodów źródłowych, przeznaczonych do wykonania tylko na procesorze graficznym. Odpowiedzialna za to biblioteka w systemie Linux Mint to nvidia-cuda-toolkit. Instalacja tej biblioteki jest bardzo prosta – wystarczy wykonać w terminalu polecenie:

sudo apt install nvidia-cuda-toolkit

Tak wygląda okno terminala w systemie, w którym tej paczki jeszcze nie instalowano:

Instalacja paczki SDK dla NVIDII pociąga za sobą konieczność doinstalowania również dodatkowych innych paczek.

Instalacja paczki SDK dla NVIDII pociąga za sobą konieczność doinstalowania również dodatkowych innych paczek, które zawierają narzędzia do kompilacji programów wykonywanych na kartach graficznych i pakiety, które obsługują masywnie zrównoleglone obliczenia z różnych dziedzin matematyki.

I gotowe. Może pojawić się pytanie o hasło użytkownika, ponieważ instalacja tej biblioteki wymaga szerszych uprawnień. Ponowne uruchomienie Blendera powinno w opcjach konfiguracji mieć dostępną kartę graficzną dla Cycles. Tak było w moim przypadku, bez dodatkowej kompilacji! Aby to jednak działało, należy w ogóle w systemie mieć aktywną kartę NVIDIA i wykorzystywać własnościowy sterownik tej firmy. Wybranie Cycles i włączenie renderowanego podglądu (lub rozpoczęcie renderowania na GPU) za pierwszym razem uruchomi kompilację bibliotek Cycles przeznaczonych dla karty graficznej. Wewnętrznie, w sposób niewidzialny dla zwykłego użytkownika wykonane zostaną polecenia w postaci:

sh -c "nvcc" -arch=sm_52 -m64 --cubin \
 "/home/piotao/bin/blender-git/build_linux_full/bin/2.77/scripts/addons/cycles/kernel/kernels/cuda/kernel.cu" \
 -o "/home/piotao/.config/blender/2.77/cache/cycles_kernel_sm52_A6454295E750AA7EBCCC513A7AFDBC64.cubin" \
 --ptxas-options="-v" --use_fast_math \
 -I"/home/piotao/bin/blender-git/build_linux_full/bin/2.77/scripts/addons/cycles/kernel" \
 -DNVCC -D__KERNEL_CUDA_VERSION__=75

Są one dostosowane do systemu w którym kompilowaliśmy Blendera, i spowodują utworzenie specjalnych binarnych plików *.cubin, które ładowane bezpośrednio na kartę wykonają obliczenia szybciej niż procesor (zależy to oczywiście od szybkości karty i procesora). Proces kompilacji za pomocą nvcc może potrwać dość długo (czasem kilka minut lub dłużej), i może wymagać sporo pamięci. Warto także pamiętać, że Cycles podczas renderowania w wersji standardowej ma mniejsze wymagania pamięciowe, niż w wersji eksperymentalnej. Oznaczenie sm52 oznacza możliwości obliczeniowej mojej karty graficznej (wykryte automatycznie). Jeżeli Twoja karta ma inne możliwości obliczeniowe, Cycles skompiluje się na inną wersję. Warto pilnować aby zakupiona w przyszłości przez nas karta graficzna miała możliwości obliczeniowe na poziomie do najmniej 2.0, a najlepiej większe. Starsze karty, z sm 1.0 lub 1.3 nie są już wspierane i nie można ich użyć w obecnych wersjach Cycles. Opcje -m64 określają „bitowość” systemu, -arch to architektura karty (można wygenerować obiekty cubin dla różnych kart), ptxas to opcje dla wewnętrznego asemblera, w tym wypadku tylko tryb „gadatliwy”, --use_fast_math włącza obliczenia mniej precyzyjne, ale szybsze. Opcje -D ustawiają różne zmienne sterujące kompilacją, a opcja -I określa skąd mają być pobierane dodatkowe kody źródłowe. Opcja -cubin wymusza odpowiedni format binarny sterownika obliczeń ładowanego na kartę graficzną. Można optymalizować te opcje, określając np. wielkość bloku pamięci shared na karcie, ale jest to raczej bardzo zaawansowany rodzaj zabawy, i w moich testach nie dawał zbytniego przyrostu wydajności, więc pominę takie hakerskie próby milczeniem.

Zakończenie

Poprzednie wersje poradnika na temat kompilacji znajdują się tutaj:

Pozostaje mi życzyć Wam udanej kompilacji w nowych systemach typu Linux Mint, i ekscytujących osiągnięć w samym Blenderze!

pio

6 thoughts on “Kompilacja Blendera pod Linux Mint 18 z cmake

  1. Odpowiedz vfvf Gru 2,2016 21:09

    jak skompilowac samo cycles bez blendera?
    niektorzy chca generowac pliki jak w povrayu i renderowac to normalnie

  2. Odpowiedz WickedHarts Lis 6,2016 20:31

    Makefile:160: recipe for target ‚all’ failed
    make[1]: *** [all] Error 2
    GNUmakefile:124: recipe for target ‚all’ failed
    make: *** [all] Error 2

    Myślę że chciałbym wiedzieć dlaczego wystąpił mi tak błąd??

    • Odpowiedz piotao Lis 11,2016 15:28

      Ten błąd nastąpił wcześniej, tutaj widzisz tylko komunikat, że „niestety, buba”. Trzeba po takiej nieudanej kompilacji przewinąć okno i poszukać miejsca w którym wypisany został faktyczny kod błędu. Wtedy można się zorientować co dokładnie się stało i zadziałać odpowiednio do sytuacji.
      Zwykle może pomóc wyłączenie niepotrzebnych modułów Blendera (u mnie np. kiedyś notorycznie nie kompilowała się Collada albo OSL) albo doinstalowanie brakujących zależności. Może też być to błąd w kodzie – źródła pobrane z GIT mają to do siebie, że są bardzo ‚wczesne’ i o stabilności nikt nawet nie mówi. Jeżeli nie da się naprawić błędu, czasami wystarczy parę dni poczekać, i zwykle problem znika po paru następnych commitach. Można też zgłosić bugreport https://developer.blender.org/ tutaj i jest to najlepsze co możemy zrobić, jeżeli sami nie potrafimy naprawić kodu.

  3. Odpowiedz Mariusz Sie 5,2016 12:52

    Przydał by się opis dla Windows-a :)

  4. Odpowiedz noyva85 Lip 13,2016 23:20

    nie trzeba juz instalować cuda-toolkit w linux mint18 , ubuntu,…
    wystarczy zainstalować kernela 4.4.0 i sterowniki nvidia z repozytoriów.
    po restarcie wszystko działa nawet cuda. jądro wspiera cuda :D

    • Odpowiedz piotao Lip 14,2016 01:42

      U mnie w takim razie coś nie tak było z tym wsparciem – na kernelu 4.4.0-28-generic blender nie widział w ogóle CUDA, dopiero jak doinstalowałem paczkę. Nvidia jest z repo, paczka o nazwie nvidida-361. U Ciebie były jakieś różnice?

A Ty co o tym myślisz?