Tags Posts tagged with "opengl es"

opengl es

przez -
0 1393
Khronos Group

Podczas trwającej konferencji SIGGRAPH, Khronos Group udostępniło specyfikację OpenGL ES 3.2 i nowe rozszerzenia dla OpenGL. W pierwszym przypadku dodano sporo nowości: teselację, cieniowanie geometryczne, jednostki obliczeniowe ogólnego zastosowania (compute shaders), kompresję tekstur ASTC a także zaimplementowano Android Extension Pack (AEP). Google zapowiedziało, że w 2016 roku doda pełna obsługę nowego standardu do systemu Android. Dodatkowo pojawi się także wsparcie dla specyfikacji Vulkan, razem ze wstępną implementacją w sterownikach.

OpenGL ES 3.2

Khronos Safety Critical Working Group planuje również specyfikację OpenGL SC 2.0 na 2016 roku, która będzie pochodną OpenGL ES 2/3. W przyszłości ma się pojawić całkowicie nowa generacji API do grafiki i obliczeń, która będzie bazowała na SPIR-V i Vulkan.

Podsystemy graficzne Mir i Wayland otrzymają pełną obsługę dzięki Vulkan Window System Integration.

przez -
11 831
Khronos Group

Grupa Khronos ogłosiła wydanie specyfikacji OpenGL ES 3.1, w pełni wolnego podzbioru OpenGL dla urządzeń mobilnych. OpenGL for Embedded Systems posiada pewną ilość funkcji dostępną w normalnym OpenGL i istnieje możliwość uruchomienia danej aplikacji na normalnym komputerze. Najnowsza wersja jest w pełni kompatybilna z poprzednimi wydaniami oraz otrzymała funkcje z OpenGL 4.4.

Najważniejsze zmiany:

  • Dodano shadery obliczeniowe (compute shaders), czyli jednostki obliczeniowe, które pozwalają wykorzystać moc karty graficznej
  • Dodano separate shader objects
  • Dodano pośrednie rysowanie jednej rzeczy wiele razy (Indirect draw commands), które umożliwia procesorowi graficznemu na obliczanie i przechowywanie parametrów dla wielu komend rysowania w buforze obiektów i ponownego ich wykorzystania, w jednej komendzie rysowania. Jest to efektywne podczas renderowania wielu obiektów z małą ilością trójkątów
  • Zwiększono możliwości teksturowania
  • Udoskonalono język shaderów – pojawiły się nowe operacje arytmetyczne i bitfiled, a także funkcje włączające nowoczesne styl programowania shaderów
  • Dodano opcjonalne rozszerzenia

przez -
5 495

Grupa Khronos, odpowiedzialna za wiele standardów graficznych, przedstawiła światu założenia dotyczące następne wersji OpenGL ES. Dokument nosi tytuł OpenGL ES Next i zawiera szczegółowe wytyczne, odnośnie następcy standardu OpenGL ES 3.0. OpenGL ES 4.x lub OpenGL ES 3.x powinien pojawić się w tym roku, dokładnie dwa lata po swoim poprzedniku.

Nowości w API:

  • Wsteczna kompatybilność z OpenGL ES 2.0 i OpenGL ES 3.0
  • Shadery obliczeniowe (compute shaders), które można wykorzystać do rozproszonych obliczeń, jak obrazy, dźwięk i przetwarzanie geometryczne w potoku graficznym
  • Separate shader objects
  • Komendy pośredniego rysowania wielu rzeczy na raz (Indirect draw)
  • Enhanced texturing functionality including texture gather, multisample textures and stencil textures
  • Enhanced shading language functionality
  • Brak teselacji i shaderów geometrii

przez -
1 431
OpenGL

Norbert Nopper ogłosił dostępność GLUSa na minikomputer Raspberry Pi. GLUS to biblioteka pomocnicza C dla OpenGL 3 i OpenGL 4, która używa GLEW i GLFW, aby zapewniać niezależność od platformy systemowej. Wspierane są także specyfikacje OpenGL ES 2.0 i OpenGL ES 3.0, a sama biblioteka może zostać przeniesiona na inny system operacyjny, poprzez podmianę tylko jednego pliku.

przez -
2 360
Intel

Firma Intel poinformowała, że procesory Intel Sandy Bridge poprawnie wspierają specyfikację OpenGL ES 3.0. Wcześniej poinformowano, że procesory Intel Ivy Bridge otrzymały wsparcie, dzięki czemu dwie generacje są zdolne do obsługi tejże technologii. Wyniki prac zostały przesłane do Khronos Group, która w ciągu 30 dni sprawdzi i zatwierdzi wszystko.

Procesory Sandy Bridge posiadają karty graficzne Intel HD 2000 i Intel HD 3000. Niedawno wydana Mesa 9.1 posiada już wbudowaną obsługę OpenGL ES 3.0.

przez -
4 492
Intel

Firma Intel poinformowała, że procesory Intel Ivy Bridge poprawnie wspierają specyfikację OpenGL ES 3.0. Warto tutaj dodać, że owe wsparcie zostało dodane do deweloperskiej wersji Mesa 9.1 i działa aktualnie z jądrem Linux 3.6. Procesory Ivy Bridge posiadają karty graficzne Intel HD 2500 i Intel HD 4000 i aktualnie posiadają wsparcie dla OpenGL 3.1. Prócz tego kompatybilne z nową specyfikacją są: PowerVR 6 Rogue Hood, Qualcomm MSM8974 i Qualcomm MSM8064.

Teraz wyniki prac zostały przesłane do Khronos Group, która w ciągu 30 dni będzie sprawdzała i zatwierdzała wszystko. Jednakże ze względu na zbliżającą się konferencję Mobile World Congress, okres ten może ulec skróceniu. Na koniec warto wspomnieć, że IGP w procesorach Sandy Bridge: Intel HD 2000 i HD 3000 są w stanie nieoficjalnie uruchomić OpenGL ES 3.0. Intel w niedługim czasie powinien wysłać do Khronos kolejne porcję sterowników do zatwierdzenia.

przez -
38 853

W 2008 roku Kristian Høgsberg zapoczątkował nowy projekt w świecie Linuksa – Wayland. Jego celem było stworzenie następcy obecnego X Servera, wraz z menadżerami okien i sporą ilością funkcji, które obecnie posiada jądro Linux. Tak narodził się Wayland – protokół systemu okien, który łączy w sobie menadżera kompozycji oraz system okien. Jest on swojego rodzaju protokołem dla kompozytora, który łączy się z klientami i posiada towarzyszącą mu bibliotekę implementującą, napisaną w języku C.

Częścią projektu Wayland jest Weston, który jest implementacją kompozytora Waylanda. Weston może działać, jako klient X lub Linux KMS, i zapewnia kilka przykładowych klientów. Kompozytor Weston jest szybki i minimalistyczny, dzięki czemu nadaje się dla urządzeń mobilnych i wbudowanych.

X Server

Poniżej zamieszczamy rysunek działania X Servera:
Architektura X Server

  1. Jądro otrzymuje sygnał z urządzenia wejściowego i przesyła go do X Servera poprzez sterownik wejścia evdev. Jądro wykonuje całą żmudną pracę poprzez sterowanie urządzeniem i tłumaczeniem specyficznych protokołów dla standardowego zdarzenia wejściowego evdev.
  2. X Server decyduje, którego okna dotyczy sygnał i śle go do klientów, które zostały wybrane do danego zdarzenia w tym oknie. X Server nie wie aktualnie, jak to zrobić, ponieważ lokalizacja okna na ekranie jest kontrolowana przez kompozytor i może zostać to zmienione na wiele sposobów, których X Server nie obsługuje.
  3. Klient czeka na zdarzenie i decyduje, co zrobić. Często interfejs graficzny musi zostać zmieniony, w odpowiedzi na zdarzenie, może został kliknięty przycisk zamknięcia, lub wskaźnik najechał na przycisk, który powinien zostać podświetlony. Tak więc klient wysyła żądanie renderowania z powrotem do serwera X.
  4. Kiedy X Server otrzymał żądanie renderowania, wysyła to do sterownika, aby umożliwić mu zaprogramowanie sprzętu do renderowania. X Server oblicza także przylegający region renderowania i wysyła to do kompozytora, jako zdarzenie zniszczenia.
  5. Następnie kompozytor otrzymuje od zdarzenia zniszczenia, że coś zostało zmienione w oknie, i powinna zostać ponownie narysowana część ekranu, na którym jest owe okno widoczne. Kompozytor jest odpowiedzialny za renderowanie całej zawartości ekranu i okien X. Potem musi jeszcze raz przesłać to przez X Server, aby zakończyć renderowanie.
  6. X Server otrzymuje żądanie renderowania od kompozytora i kopiuje back bufor do front bufora, lub wykonuje tzw. pageflip.

Wayland

Oto, jak działa Wayland:
Architektura Wayland

  1. Jądro otrzymuje żądanie i wysyła je do kompozytora. Odbywa się to podobnie, jak w X Server, ponieważ możemy użyć wszystkich sterowników wejścia, zawartych w jądrze.
  2. Kompozytor przegląda swoją obecną scenę graficzną (Scene Graph), aby ustalić które okno powinno otrzymać zdarzenie. Scene Graph wysyła sygnał, co ma obecnie na ekranie, a kompozytor próbuje zrozumieć zmianę, jaką ma zaimplementować do elementów sceny. Warto zaznaczyć, że typy transformacji wykonywane na oknie, są ograniczone jedynie do możliwości kompozytora, tak długo, jak może on obliczać wsteczną transformację dla zdarzeń wejścia.
  3. Klient podłączony do Waylanda, wykonuje całe renderowanie. Wysyła żądanie do kompozytora, aby zainicjować region, który został zaktualizowany.
  4. Kompozytor zbiera żądania zniszczenia od klientów, a następnie zmienia cały obraz na ekranie. Kompozytor może bezpośrednio wysłać ioctl, aby zaplanować pageflip z KMS.

Zalety i wady nowego protokołu

Jak zatem widzimy Wayland niweluje wiele niepotrzebnych czynności, jakie są wykonywane przez X Server. Patrząc po obecnych możliwościach, jakie możemy wykonywać z jego wykorzystaniem, czyni go to przyszłościowym rozwiązaniem. Aktualnie jednak jest sporo problemów:

  • Brak wsparcia od nVidia i AMD, w kwestii własnościowych sterowników. Jedyne, które aktualnie współpracują dobrze, to te od Intela.
  • Brak transparentności sieciowej. Wiele osób zarzuca brak tej cechy, jednakże Windows też tego nie posiada i nikt nie narzeka. Wykorzystywane są programy typu RDP, VNC.
  • Nie ma natywnego OpenGL. Domyślnie API OpenGL dla systemów Linux, posiada w nazwie GLX i jest ściśle związane z Xami. Jedynym niezależnym API jest OpenGL ES, który został przystosowany dla urządzeń mobilnych, jak Android, który nie korzysta z Xów.
  • Brak łatwego przenoszenia na inne platformy. Wayland jest silnie związany z mechanizmami, zawartymi w jądrze Linux.

przez -
15 647

Grupa Khronos ogłosiła wydanie specyfikacji OpenGL ES 3.0, w pełni wolnego podzbioru OpenGL dla urządzeń mobilnych. OpenGL for Embedded Systems posiada pewną ilość funkcji dostępną w normalnym OpenGL i istnieje możliwość uruchomienia danej aplikacji na normalnym komputerze. Najnowsza wersja jest w pełni kompatybilna z OpenGL ES 2.0 i posiada cechy OpenGL 3.3 i OpenGL 4.2.

  • Dodano ulepszenia dla potoku renderującego, dzięki czemu uruchomiono akcelerację zaawansowanych efektów graficznych. Są to: occlusion queries, transform feedback, instanced rendering i wsparcie dla renderowania minimum 4 lub więcej framebufforów.
  • Dodano wysokiej jakości kompresję tekstur ETC2 / EAC, jako podstawową funkcjonalność, która eliminuje potrzebę stosowania różnych zestawów tekstur na każdej platformie
  • Nowa wersja języka shaderów GLSL ES z pełnym wsparciem dla 32 bitowych operacji stało- i zmiennoprzecinkowych
  • Udoskonalono funkcje tekstur, w tym wsparcie dla zmiennoprzecinkowych tekstur, tekstur 3D, tekstur głębokości, tekstur wierzchołków, tekstur NPOT, tekstur R/RG, niezmiennych tekstur, dwuwymiarowych tekstur tablicowych, swizzles, LOD i mip level clamps, seamless cube maps i sampler objects
  • Dodano zestaw wymagań, wielkość tekstur i formatów buforów renderowania, co skraca implementację i pozwala pisać łatwiej przenośne programy

Polecane

OSWorld

7 1219
Drodzy Czytelnicy, prowadzimy portal OSWorld.pl już ponad 10 lat. Z przykrością stwierdzamy, że mamy na niego coraz mniej czasu, dlatego chcielibyśmy przekazać prowadzenie serwisu osobie...