SantyagoSantyago
Avatar

Witaj!
Blog archiwalny. Już niebawem nowy serwis!

YouTube RSS Facebook GitHub

Po półtorarocznym okresie ciężkiej pracy, światło dzienne ujrzało API Vulkan 1.0 od grupy Khronos, mające konkurować z DirectX 12. Szumnie zapowiadany i dostępny od dłuższego czasu DX12 miał zrewolucjonizować rynek gier, jednak do dnia dzisiejszego nic ciekawego na tym polu się nie wydarzyło. Czy Vulkan ma szansę na inny los?

Za Vulkanem stoi dziś potężna grupa, wśród której możemy wymienić firmy takie jak NVIDIA, Intel, Samsung, Valve, Google i wiele innych. Kluczową rolę jednak odegrał tutaj AMD, ponieważ Vulkan czerpie bardzo wiele z autorskiego Mantle, któremu nie udało się zwojować zbyt wiele.

Sterowniki

Już teraz dostępne są sterowniki NVIDIA wspierające Vulkana, oznaczone numerami 356.39 dla systemu operacyjnego Windows oraz 355.00.26 dla Linuksa. Obsługiwane karty rodzin GeForce 900m GeForce 700, GeForce 600, a także Quadro. Co ciekawe, firma udostępniła również sterowniki dla systemu Linux4Tegra, który napędza takie jednostki jak Jetson TK1 oraz Jetson TX1. Spodziewajcie się więc osobnego wpisu na ten temat.

AMD także przygotowało odpowiednie sterowniki dla swoich kart Radeon, gdzie minimalne wymagania to Windows 7 z SP1. Wspierane są praktycznie wszystkie rodziny kart graficznych. Niestety nie wiadomo jeszcze nic o sterownikach dla systemu Linuks.

Gotowymi sterownikami pochwalił się również Qualcomm dla swoich układów Adreno, a także Imagination dla układów PowerVR.

Oczywiście nie możemy zapomnieć o Intelu, który jako jedyny producent układów graficznych prężnie wspiera ruch Open-Source.

Co na to wszystko Microsoft? Kto stawia, że nagle pojawij się DirectX 12 dla starszych wersji, niż Windows 10?

Reklama

W poprzednim tygodniu opisywałem świetną płytkę NodeMCU v2 opartą na układzie ESP8266. Oprócz podstawowych zagadnień, pokazywałem również jak wgrać nowy firmware w postaci binarnej jaki przygotowali twórcy. Najnowsza dostępna wersja w dniu tego wpisu to NodeMCU 0.9.6 datowana na 2015/02/16. Możemy jednak wgrać nowszy build, a nawet skorzystać z rozwojowego drzewa dev120.

Wszystko czego będziemy potrzebowali to Linuksa, trochę czasu i odrobinę miejsca na dysku twardym (około 4GB)

ESP Open SDK

W pierwszej kolejności sklonujmy repozytorium ESP Open SDK i przygotujmy zestaw odpowiednich narzędzi:

  1. cd ~
  2. mkdir nodemcu
  3. cd nodemcu/
  4. git clone https://github.com/pfalcon/esp-open-sdk.git
  5. cd esp-open-sdk/
  6. make STANDALONE=y

W zależności od posiadanego sprzętu i prędkości sieci, proces ten może zając od kilku do kilkunastu minut. Po tym czasie powinien wyświetlić się komunikat o pomyślnym wykonaniu zadania z prośbą o modyfikację zmiennej środowiskowej PATH. W moim przypadku będzie to:

  1. export PATH=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/bin:$PATH

Sprawdźmy jeszcze, czy wszystko jest poprawnie, wydając poniższe polecenie:

  1. xtensa-lx106-elf-gcc -v

Using built-in specs.
COLLECT_GCC=xtensa-lx106-elf-gcc
COLLECT_LTO_WRAPPER=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/libexec/gcc/xtensa-lx106-elf/4.8.2/lto-wrapper
Target: xtensa-lx106-elf
Configured with: /home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/src/gcc-4.8.2/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=xtensa-lx106-elf --prefix=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf --with-local-prefix=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot --disable-libmudflap --with-sysroot=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG 1.20.0' --disable-__cxa_atexit --with-gmp=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-mpfr=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-mpc=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-isl=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-cloog=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-libelf=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --enable-lto --enable-target-optspace --disable-libgomp --disable-libmudflap --disable-nls --disable-multilib --enable-languages=c,c++
Thread model: single
gcc version 4.8.2 (crosstool-NG 1.20.0):

Możemy przystąpić do budowania firmware

Ponownie klonujemy repozytorium - tym razem zawierające firmware:

  1. cd ~/nodemcu/
  2. git clone https://github.com/nodemcu/nodemcu-firmware.git
  3. cd nodemcu-firmware.git/

Na tym etapie musimy zdecydować, czy interesuje nas gałąź master (obecnie z wersją 0.9.6), czy może chcemy spróbować deweloperskiej wersji 1.2.0. Jeśli tak, wybieramy gałąź dev120. Jeśli nie, pomijamy poniższe polecenie:

  1. git checkout dev120

Na koniec nie pozostaje nam już nic innego, jak wydanie polecenia kompilacji:

  1. make

Kiedy kompilacja dobiegnie końca, możemy przygotować nasz firmware i wgrać go NodeMCU v2 (oczywiście podłączająć go do USB):

  1. tools/esptool.py elf2image app/.output/eagle/debug/image/eagle.app.v6.out
  1. tools/esptool.py write_flash -fm dio -fs 32m -ff 40m 0x00000 app/.output/eagle/debug/image/eagle.app.v6.out-0x00000.bin 0x10000 app/.output/eagle/debug/image/eagle.app.v6.out-0x10000.bin

I praktycznie tyle. Sprawdźmy jeszcze za pomocą minicoma, czy rezultat jest zgodny z oczekiwaniami:

  1. minicom -D /dev/ttyUSB0 -b 9600

Po restarcie powinniśmy ujrzeć świeży firmware:

Custom firmware

Przed kompilacją i wgraniem, możemy zmodyfikować konfigurację naszego firmwareu edytując plik app/include/user_modules.h.

Właśnie tutaj zdecydujemy o dostępności poszczególnych modułów, oszczędzając tym samym cenne kilobajty.

Czasami zdarza się sytuacja, w której potrzebujemy uruchomić oprogramowanie napisane wyłącznie pod architekturę x86 na komputerze wyposażonym w procesor ARM. Do niedawna jedynym rozwiązaniem było skorzystanie z QEMU i obrazu systemu operacyjnego. Firma Elbrus Technologies opracowała oprogramowanie Exagear Desktop, które pozwala na uruchomienie aplikacji x86 bezpośrednio w naszym systemie, bez konieczności uruchomienia maszyny wirtualnej, z której korzystanie może być nieco niewygodne. Dodatkową zaletą, która wymienia producent jest prędkość działania, większa czterokrotnie od rozwiązania QEMU. Testy jakie przeprowadzono na ODROID-XU z procesorem Exynos5 Octa Cortex™-A15 1.6Ghz wyglądają naprawdę zachęcająco:

Wyniki SysBench / GeoBench
 

Dzięki Exagear Desktop możemy również zainstalować Wine i mieć dostęp dla programów, przeznaczonych na system operacyjny Windows.

Instalacja odbywa się poprzez umieszczenie klucza licencyjnego w katalogu z plikiem instalacyjnym i jego uruchomieniem. Niestety aktywacja klucza odbywa się przez Internet, który zostaje przypisany do konkretnego urządzenia. Oznacza to, że nie będzie możliwe wykorzystanie go na innym. Na chwilę obecną klucz licencyjny został przeceniony z kwoty 30$ na 15$ - warto więc zainteresować się jego kupnem.

Plik instalacyjny zawiera specjalnie przygotowany system Ubuntu 12.04 LTS, który instalowany jest do katalogu /opt. Wydając polecenie exagear, zostajemy przeniesieni do chrootowanego 32-bitowego systemu w architekturze x86, w którym możemy operować jak w standardowej dystrybucji Ubuntu. Należy zwrócić uwagę, czy nasze jądro posiada moduł binfmt_misc oraz podział pamięci wirtualnej w konfiguracji 3G/1G. Nasz procesor musi być co najmniej w architekturze ARMv7 oraz wspierać instrukcje  NEON oraz VFP32.

Po wejściu w środowisko x86 otrzymujemy do dyspozycji wirtualny procesor i686 taktowany zegarem 1GHz i obsługą instrukcji takich jak: MMX, SSE, SSE2, SSE4_1.

Na pierwszy ogień postanowiłem zainstalować program Eagle firmy CadSoft. Po doinstalowaniu wymaganych pakietów, mogłem już przystąpić do pracy.

CadSoft Eagle uruchomione na platformie Jetson TK1

Skoro mamy dostęp do x86 to dlaczego nie spróbować Wine i pokusić się o uruchomienie programu dla systemu Windows? Nic prostszego, apt-get install wine i już możemy instalować programy. Dla przykładu popularny Total Commander.

Niestety nie ma róży bez kolców. W obecnej wersji nie jest możliwe korzystanie z oprogramowania, które wymaga bezpośredniego dostępu do modułów jądra oraz skorzystanie z akeceleracji OpenGL. Co ciekawe udało mi się zainstalować Steam, jednak dalsza zabawa nie jest możliwa, ponieważ wykrywa on własnościowy sterownik NVIDIA w nieobsługiwanej wersji 1.4 (2.1.2). Pech chciał, że numeracja sterownika dla Tegra TK1 jest diametralnie inna, niż tych standarowych układów. Gdyby tylko udało się podmienić numer wersji na minium 304.22, to kto wie? :) Maszyna parowa jak się patrzy.

Po udanej zbiórce w serwisie Kickstarter, silnik Leadworks w wersji 3.1 zawitał właśnie w wersji beta na Linuksa. Silnik z powodzeniem może być wykorzystywany do tworzenia produkcji z segmentu AAA, obsługuje standard OpenGL 4.x, oferując dodatkowo wsparcie dla silnika fizyki Newton Game Dynamics, który został wykorzystany między innym w serii Penumrba.

Leadworks 3 pozwala również na wykorzystanie bibliotek OpenAL, EAX oraz udostępnia deffered rendering (alternatywna metoda oświetlania obiektów), zunifikowany system oświetlenia (dynamiczne oświetlenie i miękkie cienie), a także zestaw narzędzi i modułów dla szerokiej gamy języków programowania takich jak: Java, C#, VB.NET, Python, C/C++, BlitzMax oraz Lua.

Do pełni szczęścia wymagane są własnościowe sterowniki NVIDIA lub AMD, które obsługują OpenGL 4. Na chwilę obecną, Mesa wspiera jedynie OpenGL 3 i jest w ciągłej fazie rozwojowej.

Warto zaznaczyć, że Leadwerks pojawi się również na konferencji Steam Dev Days, która planowana jest na 15 i 16 stycznia w Seattle w stanie Waszyngton. Steam Dev Days przeznaczony jest dla twórców gier, zainteresowanych wkroczeniem do świata SteamOS i przyłączenia się do ambitnych planów Valve.


The Zone / Dave Lee


Combat Helo / Tricubic Studios

Poniżej możecie zobaczyć materiał, który był umieszczony w serwisie Kickstarter.

Kilka filmików z działania silnika Leadwerks.

 

Udostępniono kolejną wersję wieloplatformowego projektu FFmpeg 2.1, zawierającego szereg narzędzi do nagrywania, konwertowania i przetwarzania treści Audio/Video. Nowa wersja uzyskała nazwę kodową "Fourier".

Wśród długiej listy zmian, możemy wyróżnić takie perełki jak: dodanie natywnego, wolnego od wszelkich opłat licencyjnych dekodera VP9 opracowanego przez Google oraz dekodera standardu HEVC (High Efficiency Video Coding) - znanego szerzej pod oznaczeniem H.265. Standard H.265 oferuje rozdzielczości UHDTV (7680 × 4320), a pliki zakodowane tym kodekiem mogą zajmować dwa razy mniej miejsca przy zachowaniu takiej samej jakości w stosunku do kodeka H.264.

Na uwagę zasługuje również dodana możliwość przeszukiwania strumieniu danych protokołu RTMP, a także zdolność odczytywania informacji EXIF, zaszytych w obrazach JPEG. Dekoder WebP również doczekał się aktualizacji, pozwalającej na odtwarzanie materiału wideo, posiadającego kanał przeźroczystości Alpha.

Również jedną z oczekiwanych zmian, jest dodana obsługa wyjścia audio PulseAudio oraz zdolność wyświetlania strumienia wideo do bufora ramki (frame-buffer).

Warto również wspomnieć o możliwości dekodowania strumienia AAC Enhanced Low-Delay, mającego szerokie zastosowanie w telefonii VoIP. AAC ELD jest zdolny do przenoszenia pełnego pasma w zakresie do 20kHz przy opóźnieniu mniejszym niż 20ms -  ujmując prościej - jakość Full HD dla dźwięku w komunikacji IP :)

Źródła i więcej informacji: http://www.ffmpeg.org/download.html