Wieści ze świata OpenSource: 15 – 20 stycznia 2014 r.

Wielu posiadaczy kart AMD Radeon zapewne ucieszy właśnie opublikowany Linux 3.13. W tym wydaniu naprawiono błąd, powodujący w kartach serii 7000 wyłączenie wszystkich (poza pierwszym) procesorów przetwarzających shadery. Efekt? Najnowsza wersja otwartego sterownika do tych GPU pozwala osiągnąć nawet 6-krotnie wyższą od wcześniejszej wydajność. Wstępne testy na DOTA2 pokazują średnio ponad 60 klatek na sekundę przy najwyższych ustawieniach grafiki. Zamknięty sterownik Catalyst wyciąga średnio dwa razy tyle, ale nie jest to już tak duża dysproporcja, jak kilka lat temu. Z pozostałych zmian w nowym kernelu, na uwagę zasługuje poprawka domyślnie włączająca wyjście audio złącza HDMI we wszystkich kartach AMD Radeon.
Bardziej szczegółowy opis nowego wydania Linuksa przedstawię przy innej okazji.

Steam Dev DaysVOGL oraz portowanie gier na Linuksa

Steam jest oprogramowaniem zamkniętym i raczej nic się w tym zakresie nie zmieni. Jednak Valve nie zamierza po prostu podczepić się pod ekosystem OpenSource i nie dać w zamian nic poza marketingiem (tego argumentu często używa się przeciwko firmie Canonical i Ubuntu). Na zakończonych niedawno Steam Dev Days wiele się mówiło o przenoszeniu gier na SteamOS oraz o tym, jak Valve zamierza w tym pomóc.

Bardzo ciekawa była prezentacja Ryana Gordona, dotycząca portowania gier. Zaleca on przede wszystkim rozpoczęcie od SDL2 lub jednego z dostępnych silników (Unreal3, Unity3D, ID Tech4, Leadworks i oczywiście ich własny Source), co zdejmuje z deweloperów ciężar zmartwień o sterowniki do kart graficznych, czy rozdrobnienie ekosystemu, spowodowane nieskończoną liczbą dystrybucji Linuksa. Kolejnym krokiem jest oczywiście OpenGL. Lepiej najpierw przepisać grę na SDL2/OpenGL tak, aby działała pod Windowsem, a dopiero potem brać się za port linuksowy. W ten sposób 90% pracy można wykonać bez instalowania Linuksa. Gordon zwraca też uwagę na fakt, że linuksowe systemy plików rozróżniają wielkie/małe litery, o czym wielu początkujących deweloperów zapomina.

A co z innymi narzędziami potrzebnymi w procesie deweloperskim? Wszystko się znajdzie, jeśli programista nie jest fanatycznie przywiązany do Visual Studio. Sporo uwagi poświęcono Qt Creator, jako najlepszemu IDE dla deweloperów linuksowych gier.

Dlaczego warto rozważyć wejście na ten rynek? Bo chociaż jest stosunkowo niewielki, to konkurencja też nie jest duża. Ponadto jest otwarty, w przeciwieństwie do ekosystemów Microsoftu, Apple oraz Google, gdzie to giganci decydują co i kiedy może pojawić się w ich sklepach.

Istotnym elementem procesu rozwoju oprogramowania jest jego debugowanie. W przypadku zwykłych aplikacji nie ma z tym problemu, jednak debugowanie aplikacji OpenGL zawsze kulało. Na brak porządnego (czytaj: graficznego) debuggera dla OpenGL narzekano od wielu lat – tę niedogodność wskazywano jako jedną z głównych barier, stojących na przeszkodzie do wykorzystania OpenGL w grach. Odpowiedzią Valve jest VOGL (Valve OpenGL debugger), który, po pierwsze, pisany jest bezpośrednio na Linuksa (a nie na Windowsa, a potem portowany, co w przypadku tego typu oprogramowania jest średnio udanym pomysłem), a po drugie, będzie w całości udostępniony na otwartej licencji. W tej chwili VOGL obsługuje wszystkie rozszerzenia OpenGL 1 – 3.3, a do końca tego roku ma mieć pełne wsparcie dla wersji 4.x. VOGL korzysta z kompilatora LLVM, chociaż radzi sobie też z GCC (kosztem wydajności). Sądząc po licznych prezentacjach i komentarzach podczas Steam Dev Days, to właśnie LLVM będzie lepszym wyborem dla deweloperów gier. Chociaż takie zdanie nigdzie nie padło, to osobiście właśnie takie wrażenie odniosłem.

Źródła:
VOGL (Blog Richarda Geldreicha oraz tutaj)
Portowanie gier na Linuksa (slajdy z prezentacji Ryana Gordona)

W skrócie

W najnowszej deweloperskiej wersji Wine (1.7.11) pojawiła się możliwość wyświetlania windowsowego menu Start, gdy Wine uruchamiane jest w trybie „desktop”. Nadal trwają prace nad strumieniem poleceń Direct3D (D3D command stream) i już niedługo te poprawki (znacznie zwiększające wydajność uruchamianych za pomocą Wine aplikacji Direct3D) powinny trafić do wydania stabilnego.

Oficjalne wyjaśnienia AMD w sprawie osTestBackdoorATI:
Twitter: „osTestBackdoorATI to funkcja używana w naszych automatycznych testach, pozwalająca uzyskać statystyki użycia pamięci.”
Phoronix: „Symbol znaleziony wewnątrz libamdocl64.so dotyczy procedur testowych, które nie są wykorzystywane podczas normalnej pracy i AMD jest pewne, że bezpieczeństwo końcowych użytkowników nie zostało naruszone. Ta oraz inne funkcje testowe zostaną usunięte z publicznych bibliotek wraz z następnymi wydaniami.”
Nowe Catalysty są już dostępne. Wersja 13.30 umożliwia obsługę rdzeni graficznych w najnowszych APU tego producenta (architektura Kaveri).

W pogoni za nowymi technologiami producenci sprzętu znowu idą na skróty. Tak było z ACPI (moim zdaniem dokument opisujący standardy ACPI częściej używany jest jako podkładka pod kubek z kawą, niż pomoc przy wdrożeniu), czy Optimusem (liczne BSOD-y na Windows 8 po automatycznej aktualizacji sterowników jednej firmy, bez aktualizacji sterowników drugiej firmy). Teraz mamy ekrany o rozdzielczości 4k, które w rzeczywistości są dwoma panelami (lewy/prawy). Taka konfiguracja powoduje, że X.org (a wraz z nim wszystkie aplikacje GUI) widzi te dwa panele jako dwa osobne monitory. Program, zamiast rozciągnąć obraz na dwa panele, uruchamia się na jednym, gry nie maksymalizują się na obu panelach, itp. Co powinno się z tym zrobić? Napisać jakiś paskudny hack, który ukryje drugi panel, czy poczekać aż producenci przestaną ciąć koszty i dwupanelowe monitory 4k umrą śmiercią naturalną?

The Banner Saga jest już dostępna na Steamie.

Korekta: Ionash