Autor Wątek: BlossomRenderFactory - moj pierwszy powazny silnik graficzny  (Przeczytany 9289 razy)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 24, 2008, 23:38:28
Cytuj
Pierwszy jako tekstura, gdzie obok zaznaczone jest "Mips: 1", a raz jako powierzchnie. Obydwa te zasoby maja ten sam rozmiar
Tak, czy inaczej, w pamięci karty graficznej masz ten zasób trzymany tylko raz (powierzchnia jest elementem tekstury). "Mips: 1" może znaczyć po prostu brak mipmap (jeden poziom).

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

maxest

  • Gość
# Marzec 24, 2008, 23:55:38
Ahh.. chyba juz lapie. Czyli gdybym mial pelen lancuch mipmap to tekstura zajmowalaby w pamieci tyle bajtow, ile zajmuja wszystkie mipmapy.

A jeszcze odnosnie tego:
Cytuj
Możesz użyć "uniwersalnej" formy blendingu:
Color = Src + Dst*Alpha
No bo jesli bede renderowal w taki sposob przezroczysty obiekt np. 3 razy (bo beda trzy swiatla), to czy aby na pewno dostane w miare ladnie oswietlony, przezroczysty obiekt?

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 25, 2008, 00:34:24
Cytuj
No bo jesli bede renderowal w taki sposob przezroczysty obiekt np. 3 razy (bo beda trzy swiatla), to czy aby na pewno dostane w miare ladnie oswietlony, przezroczysty obiekt?
Jeżeli shadery napiszesz poprawnie, to tak. Jak zwykle polecam zapisać sobie idealną postać równania i rozpisać sobie całość na przebiegi, żeby nic się nie zgubiło. :)

Offline Ventor

  • Użytkownik

# Marzec 25, 2008, 10:00:39
Jak widać na screenach poniżej, w rozdzielczości 1280x1024 prawie 125MB jest zajęte, więc pewnie coś się jednak nie zmieściło (w 1024x768 - niecałe 100MB). Przy okazji zauważyłem ciekawą rzecz - nieważne w którą stronę bym patrzył zawsze renderowane są wszystkie trójkąty (20050 sztuk) - nie stosujesz chociażby frustum culling? W takiej sytuacji jestem już pewny, że większa ilości geometrii zabije wydajność nawet na szybkich sprzętach.




//Edit
Rozwiązała się też zagadka rozmywania - nawet na high jest tak jak Krzysiek K. mówił, czyli bufor ekranu jest skalowany do wielkości okna i stąd to rozmycie. Widać to po rozmytych literkach PerfHUD-a. Przypuszczam, że do tworzenia device-a używasz rozmiarów całego okna a nie obszaru roboczego (client rect) i stąd ten problem.
« Ostatnia zmiana: Marzec 25, 2008, 10:58:16 wysłana przez Ventor »

maxest

  • Gość
# Marzec 25, 2008, 11:23:51
No rzeczywiscie... ale to naprawde jest imho dziwne bo przeciez az tyle zasobow nie tworze...
Cullingu rzeczywiscie zadnego nie ma - dla takiej ilosc trojkatow to nie ma teraz wiekszego sensu :) Poza tym trzeba potestowac troche geometrii ;)

Cytuj
Przypuszczam, że do tworzenia device-a używasz rozmiarów całego okna a nie obszaru roboczego (client rect) i stąd ten problem.
Ano - uzywam biezacej rozdzielczosci pulpitu. Chociaz to i tak nie ma wiekszego znaczenia bo koniec koncow wszystkie bedzie full-screen

Mozesz mi powiedziec jak odpaliles tego perfHud'a? Bo gdy przeciagam ikonke-exeka swojej aplikacji na skrot perfHud'a to w uruchomionej aplikacji dostaje komunikat zebym utworzyl urzadzenie perfHud czy cus... a w quick tutorialu nie wiedziec czemu zalozyli sobie ze to juz zostalo zrobione... :)

Offline Charibo

  • Redaktor

# Marzec 25, 2008, 12:12:23
Cytuj
W takiej sytuacji jestem już pewny, że większa ilości geometrii zabije wydajność nawet na szybkich sprzętach.
spójrz na wykresik, na tych screenach z PerfHUD-a, ile % czasu zajmuje VS :)

Adapter PerfHUD-a 5 nazywa się bodaj właśnie "PerfHUD", a 4. - "NVPerfHUD". No i urządzenie musi być typu REF - szukasz poprostu adaptera o tej nazwie i go używasz, zamiast D3DADAPTER_DEFAULT :)

Btw, w Quick Guide wszystko jest -> łącznie z przykładowym kodem z tego co pamiętam :P

maxest

  • Gość
# Marzec 25, 2008, 12:30:27
Ano - udalo mi sie to zrobic. Kod uzylem jak w tym Guide'ie, ale zapomnialem wstawic w CreateDevice zmienna AdapterToUse :D. Tylko nie wiem czemu na kazdym wykresie pokazuje sie tekst "Data unavailable"... Poza tym jak Ventor dal rade odpalic te aplikacje bez ustawionego odpowiedniego adaptera? :P

Offline Ventor

  • Użytkownik

# Marzec 25, 2008, 12:44:28
Cytat: maxest
Mozesz mi powiedziec jak odpaliles tego perfHud'a? Bo gdy przeciagam ikonke-exeka swojej aplikacji na skrot perfHud'a to w uruchomionej aplikacji dostaje komunikat zebym utworzyl urzadzenie perfHud czy cus... a w quick tutorialu nie wiedziec czemu zalozyli sobie ze to juz zostalo zrobione... :)
CreateDevice(1, D3DDEVTYPE_REF, ...reszta bez zmian);

Cytat: Charibo
Cytuj
W takiej sytuacji jestem już pewny, że większa ilości geometrii zabije wydajność nawet na szybkich sprzętach.
spójrz na wykresik, na tych screenach z PerfHUD-a, ile % czasu zajmuje VS :)
Przecież większa ilość geometrii to nie tylko dłuższy czas wykonywania vertex shaderów. Potrzeba więcej pamięci na samą geometrię i tekstury, zwiększa się ilość wywołań DrawIndexedPrimitive. Nie bez powodu wymyśla się takie rzeczy jak sprzętowe instancje, właśnie po to żeby ograniczyć ilość DIP-ów. Zwiększa się też ilość SetRenderState i to wszystko dla kilku przebiegów. Dwukrotne zwiększenie ilości obiektów dla pięciu przebiegów powoduje 10-krotne zwiększenie ilości DIP-ów, czyli ten % o którym mówisz zwiększy się 10-krotnie. Oprócz tego dochodzą obliczenia na CPU pomijalne przy małej ilości geometrii, ale dla większych mogą być zauważalne.

Cytat: maxest
Poza tym jak Ventor dal rade odpalic te aplikacje bez ustawionego odpowiedniego adaptera? :P
Na codzień mam do czynienia z reverse engineeringiem i poradziłem sobie z tym w pół minuty :P

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 25, 2008, 12:57:52
Cytuj
Ano - uzywam biezacej rozdzielczosci pulpitu. Chociaz to i tak nie ma wiekszego znaczenia bo koniec koncow wszystkie bedzie full-screen
Mam nadzieję, że nie mylisz tutaj pojęcia "full-screen" z maksymalizacją okna, jak to masz teraz? :)

Cytuj
Dwukrotne zwiększenie ilości obiektów dla pięciu przebiegów powoduje 10-krotne zwiększenie ilości DIP-ów, czyli ten % o którym mówisz zwiększy się 10-krotnie.
Proponuję jeszcze raz zastanowic się nad powyższym zdaniem i w razie potrzeby przypomnieć sobie jak się liczyło proporcje w podstawówce. ;)

Offline Charibo

  • Redaktor

# Marzec 25, 2008, 13:05:58
Cytuj
Przecież większa ilość geometrii to nie tylko dłuższy czas wykonywania vertex shaderów. Potrzeba więcej pamięci na samą geometrię i tekstury, zwiększa się ilość wywołań DrawIndexedPrimitive. Nie bez powodu wymyśla się takie rzeczy jak sprzętowe instancje, właśnie po to żeby ograniczyć ilość DIP-ów. Zwiększa się też ilość SetRenderState i to wszystko dla kilku przebiegów. Dwukrotne zwiększenie ilości obiektów dla pięciu przebiegów powoduje 10-krotne zwiększenie ilości DIP-ów, czyli ten % o którym mówisz zwiększy się 10-krotnie. Oprócz tego dochodzą obliczenia na CPU pomijalne przy małej ilości geometrii, ale dla większych mogą być zauważalne.
OK, ale wierzchołki w porównaniu do na przykład tekstur zajmują prawie nic miejsca -wierzchołek z normalną, binormalną, tangentem i koordynatami tex.  zajmuje 14 bajtów - czyli 1mln wierz daje ~13MB - połowę tekstury 1024x1024 ;)

Ilość DP to osobny kłopot - jeśli ktos szafowałby DPkami to jasne, ale tak się przecież nie robi - każdy zna podstawowe zasady i raczej baczuje co się da. Poza tym, od pewnego stopnia wielkość batcha już nie robi aż takiej różnicy. Inną kwestią jest to, że wzrost szczegółowości geometrii nie musi wiązać się ze wzrostem ilości batchy. Pamiętajmy, że można poprostu zwiększyć ilość wierzchołków w poszczególnych modelach - wtedy CPU sprawa będzie zwisać, natomias dla karty strata nie będzie duża (o ile będziemy pamiętać o pooptymalizowaniu siatki pod kątem vertex cache).

Offline Kamil Trzciński

  • Użytkownik

# Marzec 25, 2008, 13:32:48
zajmuje 14 bajtów

Hey,

A to ciekawe jak... 3x float na sama pozycje zajmuje 12 bajtow, 2x float na coords zajmuje 8 bajtow... normala z tangentem i binormalem da sie upakowac w 8 bajtow.

Pozdrawiam, KT.
« Ostatnia zmiana: Marzec 25, 2008, 13:36:07 wysłana przez Kamil Trzciński »

Offline Ventor

  • Użytkownik

# Marzec 25, 2008, 13:33:38
Cytat: Charibo
wierzchołek z normalną, binormalną, tangentem i koordynatami tex.  zajmuje 14 bajtów - czyli 1mln wierz daje ~13MB - połowę tekstury 1024x1024 ;)
Taki wierzchołek zajmuje 14 floatów, czyli 56 bajtów, dla miliona to niecałe 56MB, a to dużo nawet jak na kartę z 256MB. Tekstura 1024x1024 to jak dla mnie (A8R8G8B8) około 4MB, więc ja nie wiem jakiej "kompresji" używasz, że 13MB to połowa tekstury :D

Cytuj
każdy zna podstawowe zasady i raczej baczuje co się da.
Jak np wyrenderujesz dwa zupełnie różne obiekty jednym DIP-em? Nie da się, chyba, że do każdego wierzchołka dodasz jakiś indeks obiektu, żeby VS wiedział których macierzy używać, albo policzysz na CPU (zakładając oczywiście że oba korzystają z tych samych tekstur).

Cytuj
Poza tym, od pewnego stopnia wielkość batcha już nie robi aż takiej różnicy.
Wilekość nie, ale ilość tak, a będzie to w przybliżeniu ilość renderowanych obiektów * ilość przebiegów.

Cytuj
Inną kwestią jest to, że wzrost szczegółowości geometrii nie musi wiązać się ze wzrostem ilości batchy.
No tak, ale zwiększanie szczegółowości kilku obiektów nie ma sensu, bo to nadal będzie kilka obiektów. Dodaj 100 zupełnie różnych, kilkadziesiąt tekstur i będzie slideshow.

Offline mINA87

  • Użytkownik

# Marzec 25, 2008, 13:57:44
Wilekość nie, ale ilość tak, a będzie to w przybliżeniu ilość renderowanych obiektów * ilość przebiegów.
Też nie do końca, bo pewna grupa scenowa miała duży problem - driver nVIDII wykrzaczał się, bo przepełniany był bufor - cała scena leciała w jednym batchu.

Offline Charibo

  • Redaktor

# Marzec 25, 2008, 14:00:39
E, macie racje, coś mi się z liczeniem walnęło, sorry.  Ale nadal - zazwyczaj nie trzeba "przepychać" aż tylu wierzchołków do karty.

Cytuj
Jak np wyrenderujesz dwa zupełnie różne obiekty jednym DIP-em? Nie da się, chyba, że do każdego wierzchołka dodasz jakiś indeks obiektu, żeby VS wiedział których macierzy używać, albo policzysz na CPU (zakładając oczywiście że oba korzystają z tych samych tekstur).
Sam wcześniej wspomniałeś o instancingu - ale jak mówię - przy tak prostej scenie jak ma maxest, zwiększenie ilości baczy raczej nic nie zmieni i instancing nie jest tu potrzebny.

Cytuj
Wilekość nie, ale ilość tak, a będzie to w przybliżeniu ilość renderowanych obiektów * ilość przebiegów.
No właśnie nie do końca - zwiększając -ilość- baczy powinno się też zwiększać ich -wielkość- (która ogólnie powinna być jak największa - avg. bacz albo zostaje b.z. albo rośnie) wtedy dostajemy ładnie zrównoleglony CPU<->GPU. Taki złoty środek nie wiem czy jest w ogóle możliwy do osiągnięcia, jak to ze złotymi środkami bywa, ale próbować należy.

Stąd właśnie ten trend przerzucania coraz większej ilości zadań na grafikę - bez spadku wydajności otrzymujemy "za darmo" czas procesora na inne rzeczy niż rendering.

Cytuj
No tak, ale zwiększanie szczegółowości kilku obiektów nie ma sensu, bo to nadal będzie kilka obiektów. Dodaj 100 zupełnie różnych, kilkadziesiąt tekstur i będzie slideshow.
Ma sens! Ten właśnie kłopot przecież obchodzimy normalmapami - zwiększenie szczegółowości poszczególnych modeli.

Offline Esidar

  • Użytkownik

# Marzec 25, 2008, 15:34:08
Stąd właśnie ten trend przerzucania coraz większej ilości zadań na grafikę - bez spadku wydajności otrzymujemy "za darmo" czas procesora na inne rzeczy niż rendering.

Nic nie jest za darmo. Jeśli wszystko przerzucisz na grafikę, to (w ekstremalnym przypadku) będziesz miał tyle VS/PS ile rodzajów obiektów. I będzie jednak różnica między rysowaniem wszystkiego na prostym jednym VS (jedna zmiana stanu), a między rysowaniem wszystkiego na 400 różnych VS (400 zmian stanu) które raz coś tam animują, raz coś tam przerabiają, raz coś generują itd.

A trend idzie w robienie 100 rzeczy jednocześnie na 100 procesorach (CPU) a nie przepychania 100 różnych rzeczy przez jeden procesor (GPU) :)

Dla przykładu na Xbox jest "prawie" bezpośredni dostęp do sprzętu i tam wykonanie dużej ilości DIP zajmuje dużo mniej czasu niż zmiany stanów (materiałów, shader'ów itd) i tam instancing prawie nic nie daje.