r   e   k   l   a   m   a
r   e   k   l   a   m   a

OpenGL 4.5 już gotowy: w pogoni za Direct3D, ale z poszanowaniem potrzeb profesjonalistów

Strona główna AktualnościOPROGRAMOWANIE

Dzisiaj grupa Khronos przedstawiła OpenGL 4.5, najnowszą wersję standardowego interfejsu programowania grafiki trójwymiarowej. W nieustannym pościgu za własnościowymi rozwiązaniami, na czele z microsoftowym Direct3D, otwarty standard zyskuje nowe, podpatrzone u konkurentów rozwiązania – ale czy wystarczą one na coraz bardziej komplikującym się rynku grafiki 3D?

Biblioteka graficzna Microsoftu zdobyła popularność wśród twórców gier nie tylko ze względu na popularność Windows, na którym ich obecność była gwarantowana przez producenta. Direct3D stał się z czasem technicznie bardzo udanym, innowacyjnym API, pozwalającym programistom na wygodne korzystanie z różnorodnego middleware (oprogramowanie pośredniczące).

Jedną z takich ułatwiających życie funkcji Direct3D jest Direct State Access (DSA), pozwalający na ominięcie skomplikowanego, niewygodnego cyklu wywołań, niezbędnych by program mógł operować na obiektach. Bez DSA, by np. ustawić właściwości tekstury, konieczna jest aktywacja jednostki teksturującej, a następnie przypisanie tekstury do jednostki teksturującej. Dopiero wtedy można ustawiać jej własności. O ile masochistyczny programista robi to wszystko ręcznie, to mamy do czynienia ze zwykłą niedogodnością. Gorzej, jeśli sięga po jakieś biblioteki warstwy pośredniej – wtedy nie wystarczy przypisać powiązań i aktywacji, trzeba je jeszcze po całej operacji usunąć, by nie doszło do konfliktu z ustawieniami, które mogła narzucić sama aplikacja za pomocą middleware.

r   e   k   l   a   m   a

Z DSA programista może ustawiać i odpytywać właściwości wszelkich obiektów graficznych bez przejmowania się aktywowaniem jednostek graficznych i ich powiązaniami. Upraszcza to tworzenie middleware – i to jest jeden z powodów, dla których producenci gier chętniej spoglądali w stronę Microsoftu.

Co prawda DSA zadebiutowało w OpenGL już jakiś czas temu, wraz z wersją 2.1, było jednak tylko rozszerzeniem, a nie oficjalną częścią standardu. Programiści nie mogli liczyć, że w danej implementacji OpenGL rozszerzenie to zostanie wykorzystane. Teraz sytuacja ta się zmieni, tworzenie middleware dla OpenGL będzie łatwiejsze, a to może skłonić producentów, by sięgnęli pod to wieloplatformowe API, zamiast zamykać się w świecie Windows, już nie tak panującego na rynku, jak było to dziesięć lat temu.

Pozostałe istotne zmiany w nowym OpenGL to przede wszystkim większa kontrola nad przesyłaniem poleceń do procesora graficznego i ich wykonywaniem. Ma to przede wszystkim pomóc przeglądarkom, w których oczekuje się (w imię bezpieczeństwa i stabilności) kompletnej izolacji programów 3D napisanych w WebGL – webowej odmianie OpenGL.

Grupa Khronos poinformowała również o wydaniu języka SPIR 2.0, będącego językiem pośredniczącym do obliczeń równoległych na procesorach graficznych. W teorii przypomina to OpenCL, ale OpenCL jest językiem C-podobnym, podczas gdy wielu programistów nie programuje w C, ale np. C++ czy Pythonie. SPIR rozwiązuje ten problem dzięki kompilatorom dla różnych innych języków, przekształcających z pomocą kompilatora LLVM napisany w nich kod w kod SPIR, który następnie uruchamiany jest na maszynie wirtualnej OpenCL uruchomionej na docelowym urządzeniu. Wersja 2.0 tego języka przynosi pełną obsługę OpenCL 2.0.

Warto podkreślić, że Grupa Khronos widzi jednak w OpenGL nie tylko interfejs grafiki do gier, ale też interfejs dla profesjonalistów, spełniający wymagania producentów profesjonalnego oprogramowania graficznego – czyli w świecie, w którym Microsoft czy ludzie od gier nie mają praktycznie nic do powiedzenia. W dalszym rozwoju OpenGL nie powinniśmy się więc spodziewać jakichś radykalnych zmian, choćby ze względu na obawę na reakcję tychże producentów. Będzie on przebiegał w znacznie bardziej ewolucyjny sposób, niż np. w wypadku wspomnianego Mantle API, w którym AMD zainteresowane jest jedynie wydajnością, wydajnością i jeszcze raz wydajnością.

Nie oznacza to, że Khronos zamierza odpuścić sobie rynek API dla graczy. Wręcz przeciwnie. Dzisiaj poinformowano także o rozpoczęciu prac nad budowanym od podstaw OpenGL Next Generation. To z założenia uniwersalne API grafiki nie będzie kompatybilne z klasycznym OpenGL-em, w zamian jednak ma zapewnić znacznie większą wydajność dzięki zbliżeniu do sprzętu i większej kontroli nad obciążeniami roboczymi zarówno GPU jak i CPU. Więcej o OpenGL NG napiszemy już niebawem (jak tylko przeczytamy szkic dokumentacji).

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.