Dlaczego grafika wektorowa przyspieszana sprzętowo nie została zdjęta?

Pracuję nad aplikacją, która obejmuje manipulowanie ścieżkami wektorowymi w czasie rzeczywistym przy 60 klatkach na sekundę i jestem bardzo zaskoczony, jak mało informacji na ten temat. Na początku próbowałem zaimplementować swój pomysł przy użyciu CoreGraphics, ale nie działał on odpowiednio do moich celów . Potem odkryłem, że istnieje standard Khronos dla przyspieszanej sprzętowo grafiki wektorowej o nazwie OpenVG i na szczęście życzliwa dusza napisała pół-implementację OpenGL ES o nazwie MonkVG .

Ale pomimo faktu, że OpenVG jest bardzo praktycznym API, wydaje się być mniej lub bardziej porzucony przez Khronos. Według Wikipedii od 2011 r. Grupa robocza „postanowiła… nie organizować regularnych spotkań [sic] w celu dalszej standaryzacji”. Najlepsza dokumentacja, którą mogę znaleźć, składa się z jednej karty referencyjnej. Co więcej, w Internecie nie ma prawie żadnych przykładów OpenVG. W mgnieniu oka mogę znaleźć setki samouczków OpenGL, ale wydaje się, że OpenVG wyraźnie brakuje.

Można by pomyśleć, że wektory przyspieszane sprzętowo byłyby ważniejsze w dzisiejszym świecie szybko rosnących rozdzielczości i wydaje się, że wiele firm wdraża własne sposoby na to. Na przykład Qt i Flash mają schematy wektorów przyspieszanych sprzętowo, a wiele narzędzi Adobe ma opcjonalne przyspieszenie sprzętowe. Ale wygląda na to, że koło zmienia się na nowo, gdy standard już istnieje!

Czy jest coś, czego mi brakuje w OpenVG, co sprawia, że ​​nie nadaje się do użytku w świecie rzeczywistym? A może po prostu norma nie dotarła na czas, a teraz jest przeznaczona dla niejasności? Czy uważasz, że w przyszłości jest miejsce na znormalizowany interfejs API dla grafiki wektorowej przyspieszanej sprzętowo, czy może po prostu łatwiej będzie zastosować tradycyjne techniki oparte na rastrze? A może wektory po prostu wychodzą, zanim jeszcze się pojawią?

aktualizacja: patrz dół odpowiedzi

Ta odpowiedź przychodzi nieco za późno, ale mam nadzieję, że rzucę światło na innych (szczególnie teraz, gdy standardowy komitet C ++ chce włączyć Cairo do standardowej wersji):

Powodem, dla którego tak naprawdę nikt nie dba o „przyspieszoną grafikę wektorową”, jest sposób działania układów GPU. Procesory graficzne wykorzystują masową równoległość i możliwości SIMD do pokolorowania każdego piksela. AMD zazwyczaj działa w blokach 64 x 64 8 x 8 pikseli, podczas gdy karty NVIDIA zwykle działają w 32 x 32 4x4 pikseli [Patrz aktualizacja u dołu]

Nawet jeśli renderują trójkąt 3D, GPU działa na całych quadach, które obejmuje ten trójkąt. Więc jeśli trójkąt nie obejmuje wszystkich 8x8 pikseli w bloku (lub 4x4 w przypadku NVIDII), GPU obliczy kolor nieosłoniętych pikseli, a następnie odrzuci wynik. Innymi słowy, marnowana jest moc przetwarzania dla niepokrytych pikseli. Chociaż wydaje się to marnotrawstwem, działa niewiarygodnie dobrze do renderowania dużych trójkątów 3D w połączeniu z ogromną liczbą rdzeni GPU (bardziej szczegółowe informacje tutaj: Optymalizacja podstawowego rasterizera ).

Kiedy więc spojrzymy wstecz na rasteryzację wektorową, zauważysz, że podczas rysowania linii, nawet jeśli są one grube, istnieje ogromna pusta przestrzeń. Dużo marnowanej mocy obliczeniowej, a co ważniejsze, przepustowość (która jest główną przyczyną zużycia energii, a często wąskim gardłem) Tak więc, chyba że narysujesz linię poziomą lub pionową o wielokrotności grubości 8, i idealnie dopasowuje się do 8 granic pikselowych, zmarnowana zostanie duża moc obliczeniowa i przepustowość.

Ilość „marnotrawstwa” można zmniejszyć, obliczając kadłub do renderowania (tak jak robi to NV_path_rendering), ale procesor graficzny jest nadal ograniczony do bloków 8x8 / 4x4 (prawdopodobnie również testy porównawcze GPU NVIDIA skalują się lepiej przy wyższych rozdzielczościach, proporcjach piksele_zakresowane / piksele jest znacznie niższy).

To dlatego wiele osób nawet nie dba o „przyspieszenie wektorowe hw”. Procesory graficzne po prostu nie nadają się do tego zadania.

NV_path_rendering jest bardziej wyjątkiem niż normą i wprowadzili nowatorską sztuczkę polegającą na użyciu bufora szablonów; który obsługuje kompresję i może znacznie zmniejszyć wykorzystanie przepustowości.

Niemniej jednak jestem sceptyczny wobec renderowania NV_path_renderingu, a przy odrobinie googlingu pokazuje, że Qt podczas korzystania z OpenGL (inaczej zalecany sposób) jest znacznie szybszy niż NV_ NV_path_rendering: NV Ścieżka renderowania Innymi słowy, slajdy NVIDII „przypadkowo” porównują wersję XRender z Qt. Ups

Zamiast twierdzić, że „wszystko rysowanie wektorowe z przyspieszaniem sprzętowym jest szybsze”, programiści Qt bardziej uczciwie przyznają, że rysowanie wektorowe przyspieszone sprzętowo nie zawsze jest lepsze (zobacz, jak wyjaśniono ich renderowanie: Grafika i wydajność Qt - OpenGL )

I nie dotknęliśmy części grafiki wektorowej „edycja na żywo”, która wymaga generowania pasków trójkąta w locie. Podczas edytowania złożonych plików SVG może to w rzeczywistości spowodować poważne obciążenie.

Niezależnie od tego, czy jest to lepsze czy nie, zależy to w dużej mierze od aplikacji; jeśli chodzi o twoje pierwotne pytanie „dlaczego nie wystartowało”, mam nadzieję, że teraz na nie odpowiedziano: istnieje wiele wad i ograniczeń, które należy wziąć pod uwagę, często wywołując sceptycyzm u wielu ludzi, a nawet zachęcając ich, by nie wdrożyli jednego .

aktualizacja: Zwrócono mi uwagę, że liczby są całkowicie nie na podstawie, ponieważ wspomniane GPU nie rasteryzują w blokach 64x64 i 32x32, ale raczej 8x8 = 64 i 4x4 = 16. To prawie unieważnia wnioski z postu. Wkrótce zaktualizuję ten post później, dodając więcej aktualnych informacji.

Nie sądzę, że to prawda, że nikt tak naprawdę nie dba o „przyspieszoną grafikę wektorową”, jak napisano w tej odpowiedzi .

Wydaje się, że Nvidii trochę to obchodzi. Poza Kilgardem, który jest głównym gościem technicznym w NV_path_rendering (odtąd NVpr, aby uratować moje palce), prezydent Khronos, Neil Trevett, który jest także wiceprezesem Nvidii, promował NVpr w miarę możliwości w ciągu ostatnich kilku lat; zobacz jego talk1 , talk2 lub talk3 . I to chyba trochę się opłaciło. W chwili pisania tego tekstu NVpr jest teraz używany w Google Skia (która z kolei jest używana w Google Chrome) i niezależnie [od Skia] w wersji beta programu Adobe Illustrator CC (beta), zgodnie ze slajdami Kilgarda na GTC14 ; są tam także filmy wideo z przemówień: Kilgard i Adobe. Wydaje się, że deweloper z Kairu (pracujący dla Intela) jest zainteresowany NVpr. Deweloperzy Mozilla / Firefox również eksperymentowali z NVpr i tak naprawdę dbają o grafikę wektorową przyspieszaną przez GPU, jak pokazuje to FOSDEM14 .

Microsoft dba również trochę, ponieważ stworzył Direct2D , który jest dość szeroko stosowany [jeśli uważasz, że twórca Mozilli z wyżej wspomnianej rozmowy].

Przejdźmy teraz do pierwotnego pytania: istnieją rzeczywiście techniczne powody, dla których użycie procesorów graficznych do renderowania ścieżek nie jest proste. Jeśli chcesz przeczytać o tym, jak renderowanie ścieżek różni się od standardowej geometrii 3D wierzchołków i co sprawia, że ​​przyspieszenie GPU renderowania ścieżek nie jest trywialne, to Kilgard ma bardzo dobry post podobny do FAQ , który niestety jest ukryty gdzieś na forum OpenGL.

Aby uzyskać więcej informacji na temat działania Direct2D, NVpr i podobnych, możesz przeczytać artykuł Siggraph 2012 Kilgarda , który oczywiście koncentruje się na NVpr, ale również dobrze sprawdza się przy wcześniejszych podejściach. Wystarczy powiedzieć, że szybkie hacki nie działają zbyt dobrze ... (jak zaznaczono w tekście pytania PSE). Istnieją znaczne różnice w wydajności między tymi podejściami omówionymi w tym artykule i pokazanymi w niektórych wczesnych wersjach demonstracyjnych Kilgarda, np. ten film . Powinienem również zauważyć, że oficjalny dokument rozszerzenia NVpr szczegółowo opisuje kilka ulepszeń wydajności na przestrzeni lat.

Tylko dlatego NVpr nie była tak wielka, na Linuksie w 2011 roku (w pierwszym wydanym realizacji), jako że 2011 blogu z Qt Zack Rusin powiedział, to nie znaczy, że przyspieszenie GPU wektorów / ścieżki jest beznadziejna jako odpowiedź pana Goldberga wydaje się, że z tego wywnioskowałem. Kilgard w rzeczywistości odpowiedział na koniec tego postu na blogu zaktualizowanymi sterownikami wykazującymi poprawę 2x-4x w stosunku do szybszego kodu Qt, a Rusin nic już nie powiedział.

Valve Corp. dba również o renderowanie wektorowe przyspieszane przez GPU, ale w bardziej ograniczony sposób, odnoszące się do renderowania czcionek / glifów. Mieli ładną, szybką implementację wygładzania dużych czcionek za pomocą akcelerowanych GPU pól odległości podpisanych (SDF) zaprezentowanych na Siggraph 2007 , który jest wykorzystywany w ich grach takich jak TF; na YouTube jest film pokazujący technikę (ale nie jestem pewien, kto to zrobił).

Podejście SDF zostało udoskonalone przez jednego z deweloperów Cairo & pango w postaci GLyphy ; jego autor wygłosił wykład na linux.conf.au 2014. Wersja zbyt długo nie oglądana polega na tym, że przybliża krzywą Beziera do krzywizny Beziera, aby uczynić obliczenia SDF bardziej wykonalnym w przestrzeni wektorowej (a nie rastrowej) (Valve zrobiła to drugie). Ale nawet przy aproksymacji łuku-splajnu obliczenia wciąż były powolne; powiedział, że jego pierwsza wersja działała przy 3 fps. Więc teraz dokonuje on częściowego wyrównywania dla rzeczy, które są „zbyt daleko”, które wyglądają jak forma LOD (poziom szczegółowości), ale w przestrzeni SDF. Dzięki tej optymalizacji jego wersje demonstracyjne działały przy 60 fps (i prawdopodobnie było to ograniczone przez Vsync). Jednak jego shadery są niezwykle złożone i przekraczają granice sprzętu i sterowników. Powiedział coś w stylu: „dla każdej kombinacji sterowników / systemów operacyjnych musieliśmy coś zmienić”. Znalazł także istotne błędy w kompilatorach shaderów, niektóre z nich zostały następnie naprawione przez ich twórców. Brzmi więc bardzo podobnie do tworzenia gier AAA ...

Na innym sprzęcie wydaje się, że Microsoft zlecił / określił trochę nowego sprzętu GPU w celu ulepszenia ich implementacji Direct2D za pomocą sprzętu używanego przez Windows 8, jeśli jest dostępny . Nazywa się to rasteryzacją niezależną od celu ( TIR ), co jest nieco mylące co do tego, co faktycznie robi, co zostało określone w zgłoszeniu patentowym Microsoft . AMD twierdziło, że TIR poprawił wydajność grafiki wektorowej 2D o około 500% . I między nimi a Nvidią odbyła się „wojna słów”, ponieważ nie mają tego procesory graficzne Keplera, a procesory graficzne oparte na GCN AMD. Nvidia potwierdziłaże rzeczywiście jest to trochę nowy sprzęt, a nie po prostu coś, co może zapewnić aktualizacja sterownika. W blogu Sinofsky'ego znajduje się kilka dodatkowych szczegółów, w tym kilka rzeczywistych testów porównawczych TIR. Cytuję tylko ogólne bity pomysłu:

Aby poprawić wydajność podczas renderowania nieregularnej geometrii (np. granic geograficznych na mapie), używamy nowej funkcji sprzętowej o nazwie Target Independent Rasterization lub TIR.

TIR pozwala Direct2D poświęcić mniejszą liczbę cykli procesora na teselację, dzięki czemu może szybciej i wydajniej przekazywać instrukcje graficzne GPU bez utraty jakości obrazu. TIR jest dostępny w nowym sprzęcie GPU zaprojektowanym dla systemu Windows 8, który obsługuje DirectX 11.1.

Poniżej znajduje się wykres pokazujący poprawę wydajności renderowania wygładzonej geometrii z różnych plików SVG na GPU DirectX 11.1 obsługującego TIR: [wycinek wykresu]

Ściśle współpracowaliśmy z naszymi partnerami w dziedzinie grafiki [czytaj AMD], aby zaprojektować TIR. Dramatyczne ulepszenia były możliwe dzięki temu partnerstwu. Sprzęt DirectX 11.1 jest już na rynku i współpracujemy z naszymi partnerami, aby zapewnić, że więcej produktów obsługujących TIR będzie szeroko dostępnych.

Wydaje mi się, że była to jedna z miłych rzeczy dodanych przez Win 8, które zostały w większości utracone przez świat w fiasku Metro UI ...

Prawdopodobnie dlatego, że jego zalety nie przewyższają kosztów.