2012-06-14 10 views
25

Jakie są wady stosowania zawsze alginment 1?glPixelStorei (GL_UNPACK_ALIGNMENT, 1) Wady?

glPixelStorei(GL_UNPACK_ALIGNMENT, 1) 
glPixelStorei(GL_PACK_ALIGNMENT, 1) 

Czy wpłynie to na wydajność w nowoczesnych procesach graficznych?

+0

Masz na myśli, że oprócz faktu, że niektóre z twoich danych mogą nie mieć rzędów wyrównanych do 1 bajta? –

+0

W przypadku tekstur innych niż POTS może mieć wpływ na szybkość wysyłania/pobierania. W przypadku tekstur POTS nie powinno to mieć żadnego efektu. –

+0

@DietrichEpp: Co to są tekstury POTS? – ronag

Odpowiedz

39

Jak dane nie mogą być wyrównane do 1 bajtu?

Sugeruje to niezrozumienie tego, co row alignment in pixel transfer operations means.

Dane obrazu przesyłane do OpenGL mają zostać zgrupowane w wiersze. Każdy wiersz zawiera width liczbę pikseli, przy czym każdy piksel jest wielkością zdefiniowaną przez parametry formatu i typu. Tak więc format GL_RGB z typem GL_UNSIGNED_BYTE spowoduje, że piksel ma 24 bity. Oczekuje się, że piksele będą spakowane, więc rząd 16 z tych pikseli zajmie 48 bajtów.

Każdy wiersz powinien być wyrównany do określonej wartości, zgodnie z definicją GL_PACK/UNPACK_ALIGNMENT. Oznacza to, że wartość dodawana do wskaźnika, aby przejść do następnego wiersza, to: align(pixel_size * width, GL_*_ALIGNMENT). Jeśli rozmiar w pikselach wynosi 3 bajty, szerokość wynosi 2, a wyrównanie wynosi 1, a wielkość bajtów wiersza wynosi 6. Jeśli wyrównanie wynosi 4, rozmiar bajtów wiersza wynosi osiem.

Zobacz problem?

Dane obrazu, które mogą pochodzić z formatu pliku obrazu załadowanego do niektórych programów ładujących grafikę, mają wyrównanie wiersza. Czasami jest wyrównany do 1 bajtu, a czasami nie jest. Obrazy DDS mają wyrównanie określone jako część formatu. W wielu przypadkach obrazy mają wyrównania w wierszach 4-bajtowych; rozmiary pikseli mniejsze niż 32-bity będą więc miały dopełnienie na końcu wierszy o określonych szerokościach. Jeśli wyrównanie, które dajesz OpenGL, nie pasuje do tego, otrzymujesz zniekształconą teksturę.

Ustawienie wyrównania jest zgodne z wyrównaniem formatu obrazu. Jeśli wiesz lub w inny sposób możesz upewnić się, że wyrównanie wiersza ma zawsze wartość 1 (i jest to mało prawdopodobne, chyba że masz własny format obrazu lub program zapisujący DDS), musisz ustawić wyrównanie wierszy, aby był dokładnie tym, jakiego formatu obrazu używasz.

+0

Tak, to ma sens, nie myślałem w kategoriach rzędów. Więc jeśli mogę kontrolować "bajtowe wiersze/wiersze" (co mogę, skoro i tak muszę skopiować dane do PBO), jakie wyrównanie będzie najbardziej optymalne? Czy jest jakaś poprawa wydajności przy użyciu 8 bajtowego wyrównania? – ronag

+0

Jeśli mam dane GL_RGB, czy powinienem je sam przekonwertować na GL_RGBA podczas kopiowania do PBO? – ronag

+2

@ronag: Jest mało prawdopodobne, aby pokonać wydajność rozpakowania i jest to bardzo skomplikowana funkcja zapisu za pomocą SIMD. Wygląda na to, że wymaga to dużo pracy, co musiałoby być uzasadnione benchmarkami pokazującymi, że twoja aplikacja jest ograniczona przez prędkość wysyłania * i *, że ładowanie ma niekorzystny wpływ na rozpakowywanie. –

9

Czy wpłynie to na wydajność w nowoczesnych procesach graficznych?

Nie, ponieważ ustawienia przechowywania pikseli są istotne tylko w przypadku przesyłania danych z GPU lub do GPU, a mianowicie wyrównania danych. Raz w pamięci GPU jest wyrównany w dowolny sposób, jaki pożądają układy GPU i sterownik.

+2

Myślę, że pyta, czy jeden lub więcej procesorów graficznych wymagałoby procesorów do wykonania pewnych modyfikacji danych przed przesłaniem. Oznacza to, że GPU nie może obsłużyć wierszy wyrównanych bajtowo. –

+4

Pytam, czy i kiedy może to wpłynąć na pobieranie/pobieranie gpu i czy są jeszcze inne aspekty, o których muszę pomyśleć. – ronag

+2

@ronag: Cóż, jeśli GPU nie poradzi sobie z formatem danych oryginalnych danych, format danych musi zostać najpierw przekonwertowany przez sterownik. Ponieważ jednak od czasu do czasu przesyłasz dane tekstury, generuje to jedynie bardzo mały czas procesora. Jednak przesyłanie danych nie jest tym, co uważam za problem z wydajnością GPU. Wąskim gardłem jest wyraźnie CPU i magistrala danych. – datenwolf