Krótki przegląd interfejsu API Vulkan

O co więc chodzi w tym nowym API Vulkan i dlaczego powinno nas to obchodzić?

Oto interfejs API Vulkan w stu słowach lub mniej: jest to interfejs API o niskich kosztach ogólnych, zbliżony do metalu, przeznaczony do grafiki 3D i aplikacji obliczeniowych. Vulkan jest w zasadzie kontynuacją OpenGL. Pierwotnie był określany jako „inicjatywa OpenGL nowej generacji” i zawiera kilka fragmentów z Mantle API firmy AMD. Vulkan ma zapewniać wiele zalet w porównaniu z innymi interfejsami API GPU, umożliwiając doskonałą obsługę wielu platform, lepszą obsługę procesorów wielowątkowych, mniejsze obciążenie procesora i odrobinę agnostycyzmu systemu operacyjnego. Powinno to również ułatwić tworzenie sterowników i umożliwić wstępną kompilację sterowników, w tym korzystanie z shaderów napisanych w różnych językach.

To 93 słowa, więc jeśli nie jesteś zainteresowany, możesz pominąć następne 3500. Jeśli z drugiej strony chcesz dowiedzieć się więcej o nadchodzącym graficznym API, które będzie z nami przez wiele lat, zacznę od podstaw.

Jak powstało Vulkan API

Vulkan został pierwotnie ogłoszony przez Khronos Group w marcu 2015 r., a wstępną datę premiery ustalono na koniec 2015 r. Jeśli nie znasz Khronos, jest to konsorcjum branżowe non-profit założone piętnaście lat temu przez jedne z największych nazwisk w przemysł graficzny, w tym ATI (obecnie część AMD), Nvidia, Intel, Silicon Graphics, Discrete i Sun Microsystems. Nawet jeśli nie słyszałeś o Khronos, prawdopodobnie słyszałeś o niektórych ich standardach, takich jak: OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA i glTF.

Do tej pory prawdopodobnie myślisz „Ach, to ci goście”, więc mogę pominąć resztę wstępu i skupić się na samym API.

W przeciwieństwie do swojego poprzednika lub poprzedników, Vulkan został zaprojektowany od podstaw, aby działał na różnych platformach, od telefonów komórkowych i tabletów po konsole do gier i wysokiej klasy komputery stacjonarne. Podstawowy projekt interfejsu API jest warstwowy, a raczej modułowy, dzięki czemu umożliwia tworzenie wspólnej, ale rozszerzalnej architektury do walidacji kodu, debugowania i profilowania, bez wpływu na wydajność. Krhonos twierdzi, że warstwowe podejście zapewni znacznie większą elastyczność, będzie katalizatorem silnych innowacji w narzędziach GPU różnych dostawców i zapewni bardziej bezpośrednią kontrolę GPU, wymaganą przez zaawansowane silniki gier.

Teraz rozumiem, że wielu technofilów ma zastrzeżenia do terminów marketingowych, takich jak „elastyczny”, „rozszerzalny” i „modułowy”, ale tym razem mamy do czynienia z prawdziwym McCoyem. W rzeczywistości jest to podstawowa idea Vulkan: ma być interfejsem API dla mas, od dzieci grających na smartfonach po ich rodziców projektujących budynki i gry na stacjach roboczych.

Teoretycznie Vulkan może być używany w sprzęcie do obliczeń równoległych, do kontrolowania dziesiątek miliardów rdzeni GPU, w maleńkich urządzeniach do noszenia i zabawkowych dronach, w drukarkach 3D, samochodach, zestawach VR i prawie wszystkim innym z kompatybilnym procesorem graficznym.

Aby uzyskać więcej informacji, proponuję zapoznać się z oficjalnym przeglądem Vulkan w formacie PDF.

DNA płaszcza AMD

Jeśli podejście zbliżone do metalu brzmi dziwnie znajomo, być może śledziłeś zapowiedzi procesorów graficznych AMD przez ostatnie dwa lata. AMD zaskoczyło obserwatorów branży, gdy ogłosiło swój interfejs Mantle API w 2013 r., a po raz kolejny zaskoczyło ich, gdy zdecydowało się wyciągnąć wtyczkę z interfejsu API, ogłaszając w marcu 2015 r., że nie wyda Mantle 1.0 jako publicznego SDK. Krótko mówiąc, Mantle obiecał zapewnić znaczną poprawę wydajności i wydajności w niektórych sytuacjach, zwłaszcza na froncie procesora, ponieważ zmniejszy to obciążenie przetwarzania. Brzmiało to jak dobry pomysł, ponieważ gracze mogli składać niestandardowe komputery z nieco wolniejszymi procesorami i inwestować więcej pieniędzy w najwyższej klasy karty graficzne. Brzmiało to bardzo wygodnie również dla AMD, ponieważ firma od lat nie miała konkurencyjnego procesora z wyższej półki, chociaż wciąż ma dobre produkty GPU.

Gdy płaczący fanboys AMD zebrali się, by opłakiwać odejście ich zbawiciela, Mantle został cudownie wskrzeszony. Dobra wiadomość nadeszła w postaci wpisu na blogu, napisanego przez wiceprezesa AMD ds. obliczeń wizualnych i percepcyjnych, Raję Koduri. Przypadkowo, zgodnie z motywem religijnym, pewnego razu Koduri wygłosił kazanie na wierzchowcu podczas premiery AMD na Hawajach w 2013 roku, ale ja robię dygresję.

Żarty na bok, zespół Koduriego wykonał dobrą robotę. Chociaż płaszcz nie stał się nowym standardem w branży, stał się podstawą dla Vulkan. Największą różnicą jest to, że Vulkan nie będzie ograniczony do sprzętu AMD GCN; będzie działać na znacznie większej liczbie procesorów graficznych od różnych dostawców. Prawdopodobnie widzisz, dokąd z tym zmierzam; trochę lepiej jest mieć pojedynczy interfejs API graficzny o niskim nakładzie pracy, który działa na różnych systemach operacyjnych i platformach sprzętowych, niż mieć własne interfejsy API dla różnych architektur GPU, systemów operacyjnych i tak dalej.

Vulkan API po prostu bierze sporą część tortu Mantle i dzieli się nim ze wszystkimi, niezależnie od systemu operacyjnego, sprzętu, rasy czy religii.

Aha, i jest jeszcze jedna rzecz: Mantle w końcu zmusił Microsoft i Khronos do zrobienia czegoś z rozdęciem i nieefektywnością DirectX i OpenGL. To był delikatny, przyjacielski kopniak w tył, lub „badonkadonk”, jak lubi to ująć jeden z Toptalerów.

Jak Vulkan wypada w porównaniu z OpenGL?

Oczywiście muszę nakreślić podstawowe różnice między Vulkanem a OpenGL. Khronos wymyślił prostą ilustrację, pokazującą, jak duże rozdęcie sterowników można wyeliminować dzięki nowemu interfejsowi API.

Vulkan pozwala aplikacjom zbliżyć się do metalu, eliminując w ten sposób potrzebę dużej ilości pamięci i zarządzania błędami, a także wiele języka źródłowego cieniowania. Kierowcy będą lżejsi, szczuplejsi i wredniejsi. Vulkan będzie polegał tylko na języku pośrednim SPIR-V, a ponieważ ma zunifikowane API dla rynków mobilnych, stacjonarnych i konsolowych, powinien również otrzymać bardziej czułą, kochającą opiekę programistów.

Ale czekaj, czy to po prostu nie odciąża twórców gier? Jasne, będą mogli wydajniej korzystać ze sprzętu, ale co z własnymi godzinami pracy? W tym miejscu do walki wkracza warstwowe podejście ekosystemowe.

Deweloperzy będą mogli wybrać trzy różne poziomy lub poziomy ekosystemu Vulkan.

• Używaj Vulkan bezpośrednio , aby uzyskać maksymalną elastyczność i kontrolę.
• Użyj bibliotek i warstw Vulkan, aby przyspieszyć rozwój.
• Korzystaj z Vulkan za pośrednictwem gotowych silników gier, w pełni zoptymalizowanych pod kątem nowego interfejsu API.

Pierwsza opcja oczywiście nie będzie dla wszystkich, ale podejrzewam, że przydałaby się fajne oprogramowanie do testów porównawczych. Khronos spodziewa się, że druga opcja będzie „bogatym obszarem dla innowacji”, ponieważ wiele narzędzi i warstw będzie opartych na otwartym kodzie źródłowym i ułatwi przejście z OpenGL. Jeśli wydawca ma jakieś tytuły OpenGL, które wymagają poprawek i aktualizacji, to właśnie tego użyłby.

Ta ostatnia opcja jest prawdopodobnie najbardziej kusząca, ponieważ ciężkie podnoszenie zostało wykonane przez przemysł wagi ciężkiej, takiej jak Unity, Oxide, Blizzard, Epic, EA, Valve i inne.

Oto krótka tabela OpenGL vs. Vulkan:

Szczerze mówiąc, nie sądzę, aby porównywanie tych dwóch było nawet sprawiedliwe. Vulkan jest pochodną Mantle, podczas gdy OpenGL to mastodont z bagażem 20 lat. Vulkan ma porzucić mnóstwo starszych rzeczy; o to chodzi. Vulkan ma usprawnić testowanie i implementację, uprościć sterowniki i poprawić przenośność programu cieniującego za pośrednictwem języka pośredniego SPIR-V.

To prowadzi nas do następnego pytania. Co tak naprawdę oznacza Vulkan dla programistów?

Oczekuje się, że SPIR-V zmieni ekosystem językowy

Więc gdzie SPIR-V wchodzi w grę i co dzieje się ze starym dobrym GLSL?

GSLS na razie pozostanie przy życiu i będzie pierwszym językiem cieniowania obsługiwanym przez Vulkan. Tłumacz z GLSL na SPIR-V zrobi wszystko, a voila!, SPIR-V będzie gotowy do nakarmienia głodnego środowiska uruchomieniowego Vulkan. Twórcy gier będą mogli używać back-endów SPIR-V i Vulkan, prawdopodobnie polegając na front-endach kompilatorów z otwartym kodem źródłowym. Oprócz GLSL, Vulkan może obsługiwać jądra OpenCL C, podczas gdy prace nad dodaniem obsługi C++ trwają. Kolejną opcją są przyszłe języki, frameworki i narzędzia specyficzne dla domeny. Khronos wspomina nawet o możliwości opracowania nowych języków eksperymentalnych.

Niezależnie od tego, co postanowią deweloperzy, wszystkie drogi prowadzą do Vulkan przez SPIR-V, a następnie do wielu różnych urządzeń.

SPIR-V ma poprawić przenośność na trzy sposoby:

• Wspólne narzędzia
• Pojedynczy zestaw narzędzi dla jednego dostawcy ISV
• Prostota

Ponieważ nie będzie potrzeby, aby każda platforma sprzętowa zawierała tłumacza języka wysokiego poziomu, programiści będą mieli do czynienia z mniejszą ich liczbą.

Indywidualny ISV może wygenerować SPIR-V za pomocą jednego zestawu narzędzi, eliminując w ten sposób problemy z przenośnością języka wysokiego poziomu.

SPIR-V jest prostszy niż typowy język wysokiego poziomu, ułatwiając implementację i przetwarzanie.

Wydajność zostanie poprawiona na wiele sposobów, w zależności od implementacji Vulkan:

• Koniec z front-endem kompilatora, dużo przetwarzania można wykonać w trybie offline
• Przepustki optymalizacyjne mogą się rozliczać szybciej, optymalizacje wykonywane offline
• Wiele shaderów źródłowych redukuje się do tego samego strumienia instrukcji języka pośredniego

Khronos nie podaje żadnych danych dotyczących wydajności i zauważa, że ​​„przebieg na pewno będzie się różnił”. Wszystko będzie zależeć od tego, jak używany jest Vulkan. Jeśli chcesz poznać szczegóły, zapoznaj się z białą księgą SPIR-V.

Vulkan wygląda obiecująco z perspektywy programisty

Przedstawiłem kilka funkcji, które powinny sprawić, że Vulkan i SPIR-V będą popularne w społeczności deweloperów, a Khronos również chce przekazać tę kwestię. Perspektywa wykorzystania tych samych narzędzi i umiejętności do rozwoju na wielu platformach wydaje się intrygująca, zwłaszcza teraz, gdy luka w wydajności między różnymi platformami się zmniejsza.

Oczywiście tworzenie wysokobudżetowej gry AAA na komputery PC pozostanie niezwykle złożonym i czasochłonnym procesem, wymagającym dużej ilości gotówki i zasobów ludzkich, ale platformy mobilne i zintegrowane procesory graficzne zastosowane w najnowszych procesorach Intel i AMD zapewniają już wiele Wydajność GPU dla zwykłego gracza. Poza tym mali, niezależni deweloperzy lub freelancerzy są bardziej skłonni do pracy nad wieloplatformowymi grami casualowymi niż tytułami AAA masowo produkowanymi przez głównych wydawców.

Khronos przedstawia następujące zalety, jakie umożliwia SPIR-V:

• Deweloperzy mogą używać tego samego kompilatora front-end na wielu platformach, aby wyeliminować problemy z przenośnością między dostawcami
• Czas kompilacji modułu cieniującego/jądra wykonawczego zostanie skrócony, ponieważ sterownik musi przetwarzać tylko SPIR-V
• Deweloperzy nie muszą rozpowszechniać kodu źródłowego modułu cieniującego/jądra, dzięki czemu mogą cieszyć się dodatkowym poziomem ochrony IP
• Sterowniki są prostsze i bardziej niezawodne, ponieważ nie ma potrzeby dołączania kompilatorów front-end
• Deweloperzy mają lepszy obraz alokacji pamięci i mogą odpowiednio dostosować swoje podejście do alokacji pamięci

Jestem pewien, że zgodzisz się, że brzmi to dobrze, ale przed nami jeszcze długa droga.

Vulkan: Działa, ale praca w toku

Jak powiedziałem, prace nad Vulkanem wciąż trwają i do końca roku powinniśmy mieć pełną specyfikację. Jednak z tego, co widzieliśmy do tej pory, nowy interfejs API może odblokować dużą wydajność nawet na sprzęcie obecnej generacji.

Najlepsza ilustracja Vulkana, jaką do tej pory widziałem, pochodzi z Imagination Technologies, jednego z wiodących producentów mobilnych GPU. Imagination Technologies GPU IP jest używany we wszystkich gadżetach iOS, wraz z wieloma innymi projektami System-on-Chip opartymi na architekturze ARM, a nawet w niektórych niskonapięciowych układach Intel x86.

W zeszłym tygodniu Imagination opublikował post na blogu szczegółowo opisujący wzrost wydajności, jaki umożliwił Vulkan. Wybór sprzętu był nieco nietypowy: odtwarzacz Google Nexus, oparty na rzadko używanym czterordzeniowym procesorze Intela z procesorem graficznym PowerVR G6430. Urządzenie zostało przetestowane z najnowszym sterownikiem Vulkan API dla procesorów graficznych PowerVR, podczas gdy test referencyjny został przeprowadzony na OpenGL ES 3.0. Różnica w wydajności była po prostu oszałamiająca.

Scena zawiera łącznie 400 000 obiektów o różnych poziomach szczegółowości, od 13 000 do 300 wierzchołków. Szerokie ujęcie pokazuje około miliona trójkątów, trochę alfa na roślinach i około dziesięciu różnych tekstur dla gnomów i roślin. Każdy typ obiektu używa innego shadera, a gnomy nie są instancjami, każde wywołanie rysowania może być zupełnie innym obiektem, z różnymi materiałami, ale wynik końcowy byłby podobny.

Jest jednak duże zastrzeżenie: nie jest to wzrost wydajności, jakiego można się spodziewać w prawdziwym życiu. Zespół Imagination Technologies użył przesadzonego scenariusza, aby podkreślić wyższość Vulkana, aby przesunąć go do granic możliwości, a w tym konkretnym scenariuszu granica jest na korzyść Vulkan vs OpenGL ES. Należy również pamiętać, że ten test jest związany z GPU , ale nadal jest dobrą ilustracją doskonałego wykorzystania procesora przez Vulkan.

Jak Vulkan zmniejsza wykorzystanie procesora?

Pamiętasz tę tabelę OpenGL vs. Vulkan, którą mieliśmy wcześniej, a dokładniej, ten kafelkowy bit renderowania ? Prawdopodobnie nie, więc oto w skrócie: Imagination używała Vulkana do grupowego rysowania wywołań w kafelkach i renderowania kafelka na raz. W zależności od tego, gdzie znajduje się kafelek w momencie renderowania ramki, może on pojawiać się lub znikać, zmieniać poziom szczegółowości i tak dalej. W OpenGL ES wszystkie wywołania rysowania są dynamiczne, są przesyłane z każdą ramką, zgodnie z tym, co znajduje się w polu widzenia. Wywołania Draw, które zostały już wykonane, nie mogą być buforowane.

W rezultacie OpenGL ES potrzebuje wielu wywołań trybu jądra, aby zmienić stan sterownika i go zweryfikować. Vulkan tego nie robi, ponieważ opiera się na wstępnie wygenerowanych poleceniach (buforach poleceń), aby zmniejszyć obciążenie procesora i wyeliminować potrzebę sprawdzania poprawności lub kompilacji podczas pętli renderowania. Zespół Imagination opisał możliwość ponownego wykorzystania buforów poleceń jako „przydatną w pewnych okolicznościach” i możliwą do wykorzystania „w dużym stopniu” w wielu grach i aplikacjach.

Drugim zmieniaczem gry jest równoległe generowanie buforów , które umożliwia Vulkanowi wykorzystanie mocy wszystkich rdzeni procesora. OpenGL ES został zaprojektowany przed pojawieniem się wielordzeniowych układów mobilnych, ale w ciągu ostatnich trzech lat branża przeszła od dwóch, przez cztery, do ośmiu i dziesięciu rdzeni procesorów, dzięki układom SoC serii A firmy Apple i Nvidia Tegra z Denver chipy jako jedyne godne uwagi wyjątki. Mówiłem o trendach mobilnego SoC w jednym z moich poprzednich artykułów na blogu, obejmującym nadchodzący kompilator Optymalizacji Androida, więc możesz go sprawdzić, aby uzyskać dodatkowe informacje.

Spróbujmy analogii: gdyby Vulkan był silnikiem spalinowym, magazynowałby i ponownie wykorzystywał część swojej mocy, podobnie jak turbosprężarka i intercooler (bufory poleceń) i mógłby wykorzystywać cztery, sześć, osiem lub nawet dziesięć cylindrów bez utraty wydajności (równoległe generowanie bufora). Porównywanie Vulkan do OpenGL ES brzmi trochę jak porównywanie nowego, pomniejszonego silnika turbo ze starym, jednocylindrowym silnikiem w Triumph Trophy twojego dziadka.

Cóż, przynajmniej dziadek był prawdziwym rockmanem, a nie modą.

Efektem końcowym jest znacznie wydajniejsze środowisko, zdolne do dobrego wykorzystania całego dostępnego sprzętu, w przeciwieństwie do OpenGL ES, który w większości scenariuszy jest powiązany z procesorem. Oznacza to, że Vulkan może zapewnić podobny poziom wydajności przy niższym taktowaniu procesora, zmniejszając w ten sposób zużycie energii i dławienie.

Potencjalne wady Vulkan API (Uwaga dotycząca spoilera: nie ma ich zbyt wiele)

nie czepiam się; Uważam, że ważne jest również wymienienie zalet i wad Vulkan API. Na szczęście nie ma zbyt wielu wad poza kilkoma drobnymi i potencjalnie jednym lub dwoma dużymi. Jeśli uważasz, że Vulkan jest najlepszą rzeczą od czasu krojonego chleba i chcesz spróbować w swoim następnym projekcie, możesz rozważyć kilka z tych punktów:

• Dodano złożoność kodu w niektórych scenariuszach
• Czas na rynek
• Poziom wsparcia branży
• Vulkan może nie być tak odpowiedni lub skuteczny na niektórych platformach (komputerach stacjonarnych)
• Przekonanie programistów do korzystania z Vulkan na niektórych platformach
• Ograniczona kompatybilność ze starszym sprzętem

Jeśli programista chce zaimplementować niektóre z fajnych funkcji opisanych w tym poście, będzie to wymagało sporego nakładu pracy. Każdy będzie musiał zostać zaimplementowany w kodzie, ale dobrą wiadomością jest to, że liderzy branży ułatwią ten proces dzięki nowym aktualizacjom sterowników.

Kolejnym problemem jest czas wprowadzenia produktu na rynek, podobnie jak implementacja Vulkan w starszych aplikacjach i grach. Vulkan to wciąż zapowiedź techniczna; wstępne specyfikacje i implementacje spodziewane są do końca 2015 roku, więc realistycznie rzecz biorąc, prawdopodobnie nie zobaczymy wielu rzeczywistych aplikacji przed połową 2016 roku.

Wsparcie przemysłu nie powinno stanowić problemu; W końcu jest to standard Khronos, ale może to trochę potrwać. To jeden z powodów, dla których skupiłem się w tym poście na segmencie mobilnym; Oprogramowanie i sprzęt mobilny ewoluują szybciej i może minąć jeszcze kilka kwartałów, zanim zobaczymy, jak Vulkan wywrze wpływ na platformy stacjonarne. Tak właśnie działa branża, w niszy komputerów stacjonarnych jest o wiele więcej rzeczy, o które należy się martwić: obsługa profesjonalnych aplikacji, hordy graczy z widłami, którzy małpują nad każdą rozdartą klatką i tak dalej. Jednak fakt, że Vulkan wywodzi się z płaszcza AMD, jest zachęcający.

Chociaż Vulkan może zdziałać cuda w środowisku związanym z procesorem, zwłaszcza z wielordzeniowymi mobilnymi układami SoC, ten wzrost wydajności będzie ograniczony na platformach stacjonarnych. Komputery stacjonarne obsługują procesory wielordzeniowe o wyższym poziomie wydajności, a większość aplikacji wymagających pod względem graficznym jest związana z procesorami graficznymi.

Dopóki wszystkie elementy układanki nie ułożą się na swoim miejscu, niektórzy programiści mogą niechętnie rzucać się w oczy i bawić z Vulkanem. Wiele osób po prostu nie ma czasu na eksperymenty, a nowe umiejętności uczą się tylko wtedy, gdy jest to absolutnie konieczne. Spalanie dużej ilości pieniędzy i marnowanie roboczogodzin na dostosowywanie istniejących gier mobilnych do korzystania z Vulkan na tym wczesnym etapie nie będzie opcją dla wielu programistów i wydawców.

Kolejnym źródłem obaw może być kompatybilność ze starszym sprzętem. Vulkan będzie potrzebował sprzętu OpenGL ES 3.1 lub OpenGL 4.1 wraz z nowymi sterownikami. Na przykład procesory graficzne PowerVR serii 6 firmy Imagination Technologies mogą go obsługiwać, ale seria 5 nie. Seria Adreno 400 firmy Qualcomm obsługuje OpenGL ES 3.1, ale seria 300 nie. Serie Mali T600 i T700 firmy ARM obsługują OpenGL ES 3.1, ale w starszych konstrukcjach z serii T400 brakuje obsługi. Na szczęście, zanim Vulkan stanie się odpowiedni, większość urządzeń z nieobsługiwanymi procesorami graficznymi zniknie z obrazu. Należą do nich iPhone 5/5C, iPad czwartej generacji i urządzenia Samsung oparte na niektórych układach Exynos z serii 5000. Urządzenia oparte na Qualcomm mogą nie mieć tyle szczęścia, ponieważ procesory graficzne z serii Adreno 300 są używane w stosunkowo nowych i płodnych projektach, takich jak Snapdragon 410, Snapdragon 600, Snapdragon 800 i 801. Podejrzewam jednak, że większość z nich zniknie do czasu Vulkan staje się naprawdę istotny.

Żyj długo i renderuj

Jest jeszcze za wcześnie, aby powiedzieć, czy Vulkan zmieni grę, ale myślę, że zgodzisz się, że ma duży potencjał. Myślę, że będzie to wielka sprawa i opieram to założenie na dziesięcioletnim doświadczeniu obejmującym branżę GPU. Zajmie to jednak trochę czasu i podejrzewam, że Vulkan będzie odczuwalny na urządzeniach mobilnych, zanim zacznie zmieniać krajobraz komputerów stacjonarnych.

Mniej więcej w tym samym czasie, zoptymalizowane pod kątem Vulkan sterowniki, silniki gier i gry, otrzymamy nowy sprzęt do zabawy i nie mam na myśli tylko drobnych poprawek sprzętowych. Rozwój mobilnych układów SoC utknął w martwym punkcie z wielu powodów, którymi teraz nie będę się zajmować, ale rok 2016 będzie wielkim rokiem dla branży, ponieważ węzły 14/16 nm FinFET staną się dostępne dla większej liczby producentów i staną się ekonomicznie opłacalne dla sprzętu głównego nurtu, a nie flagowe żetony.

Deweloperzy będą mieli znacznie potężniejszy i wydajniejszy sprzęt do zabawy, a nowy interfejs API o niskim nakładzie graficznym będzie wisienką na torcie. Mam szczerą nadzieję, że dostawcy sprzętu przestaną używać rozdzielczości wyświetlania jako chwytu marketingowego, ponieważ bezsensownie wysokie rozdzielczości nie poprawiają jakości obrazu, ale nadal marnują energię. Niestety, ponieważ przeciętny konsument tego nie rozumie i chce zobaczyć większe liczby na pudełku, podejrzewam, że nie nastąpi to w najbliższym czasie. Zamierzam zbadać ten dziwny problem w jednym z moich nadchodzących postów, więc jeśli denerwuje Cię to, bądź na bieżąco i nie krępuj się wyładować w sekcji komentarzy.