Threadripper 3990x i dławienie się podczas renderingu

[Winoo1]

Witka!

W zeszłym tygodniu dotarł do mnie zestaw małego majsterkowicza, czyli setup na Threadripperze 3990x. Niby wszystko ładnie, niby pięknie, ale...jest małe "ale". Otóż podczas renderowania animacji procesor podczas renderowania...dławi się. Proces wygląda następująco: odpalam render ( vray next + 3ds max, primary engine irradiance map lub bruteforce zamiennie, secondary - lightcache ). Pierwsza klatka zasuwa jak szalona. Druga podczas liczenia lightcache już przydusza rendering i z kilku sekund liczenia lightcache robi się kilkanaście - kilkadziesiąt. Po kilku klatkach przeliczanie lightcache dla klatki wzrasta do 2-4 minut, co jest absurdalne, gdyż jak wspomniałem - w pierwszej klatce lightcache policzył sie w kilka sekund. Zainstalowany był Win 10 pro. Myślałem, że to może wersja windowsa, więc nabyłem Win 10 pro for workstation. Zupdate'owałem system i...guzik. Dalej to samo. Zauważyłem, że jak podłączam distributed rendering, to rendernode zawiesza buckety na drugiej i kolejnych klatkach po wpięciu się w rendering i ich zwolnienie nawet na praktycznie zerowej geometrii trwa kilka minut. Komputery są podpięte pod NAS Synology DS216j i na rendernodzie oraz poprzednim komputerze zbudowanym na xeon 2683V4 wszystko działało bez problemów.
Płyta główna pod threadripperem to Aorus master TR40, RAM to 128 GB ( 4x32 GB ) 3200MHZ Kingston, zasilacz 1000W. Na brak prądu proc nie narzeka, temperatury są na poziomie 72 stopni podczas 24 godzinnego renderingu, więc to nie tu leży źródło problemu.

Czy ktoś zetknął się w praktyce z tym problemem i jest w stanie coś podpowiedzieć?
Z góry dziękuję i pozdrawiam
Bart

[SWRSC]

1. Czy jest to NEXT najaktualniejszy?
2. Odpal tak dla testu jakąkolwiek scenę (najlepiej nową), gdzie nic się nie rusza (ani obiekty, ani kamera), ale licz to jako "animację" na kilka klatek (LC w mode "single frame" + bruteforce). Sprawdź czy ten efekt również występuje.

vRay od nie pamiętam dokładnie której wersji wprowadził do LC algorytmy wspomagające adaptive lights. W zależności od tego co się dzieje w scenie, LC może liczyć szybciej lub wolniej. Dlatego przetestuj kompa na statycznej scenie, gdzie nic się nie zmienia. Naprowadzi Cię to nieco bliżej rozwiązania problemu.

[Winoo1]

Dzięki serdeczne za pomoc. Co mnie naprawdę zastanawia, to to, że na poprzednim komputerze na xeonie nie miałem chyba tego problemu ( przynajmniej nie przypominam sobie ) licząc tą samą animację. Przetestuję dla pewności. Jeśli to to będzie powodowało problem z lightcache, to znaczy, że trzeba będzie liczyć na full evaluation lights, prawda? Aby całkowicie wyeliminować optymalizację świateł. A mój vray to ostatnia wersja nexta. Czasem mam wrażenie, że Chaosi zamiast ułatwiać życie to je coraz bardziej komplikują. Vray 3.6 był znacznie bardziej responsywny przy starcie renderingu i zrzucaniu pamięci po wyrenderowaniu. Ech...

[SWRSC]

Wiesz co, na początku też miałem podobne przemyślenia, ale ostatecznie to ta optymalizacja jest naprawdę świetna. U nas wyeliminowało to praktycznie wszystkie problemy z GI i vRay stał się w końcu silnikiem bezproblemowym jeśli chodzi o liczenie animacji.
 

"Przetestuję dla pewności. Jeśli to to będzie powodowało problem z lightcache, to znaczy, że trzeba będzie liczyć na full evaluation lights, prawda?"

Nie rezygnowałbym z adaptive, bo to naprawdę niezły boost jeśli chodzi o czasy renderingu. Jeśli okaże się, że przy zaproponowanym teście LC liczy się poprawnie to szukałbym przyczyny w scenie, która stwarza problemy. vRay sam z siebie nie powinien generować takich wzrostów czasu liczenia LC z klatki na klatkę - problem leży gdzieś indziej (np w geometrii, która zmienia liczbę swoich poligonów z klatki na klatkę).
Możesz opisać dokładniej co liczysz? Może jakieś screeny/podgląd na to co się dzieje w animacji?

[Winoo1]

Załączam klatkę z animacji dla podglądu. Raz ją już liczyłem na poprzednim sprzęcie i nie przypominam bym na xeonie miał z tym problem. Scena jest ciężka, bierze około 50 GB ram, nie ma zmieniającej się geometrii, są po prostu animowane obiekty. Nigdy wcześniej z takim problemem się nie zetknąłem. Samo liczenie LC przebiega mniej więcej tak samo i zabiera tyle samo czasu, ale problem zaczyna się po zapisie obrazów i kompilacji następnej klatki ( ale de facto w statusie renderera jest napisane, że trwa "calculating lightcache" ). No i podczas tego  procesor jest obciążony na 100 % a potrafią buckety nie ruszyć się przez 2 minuty.
Nie wiem czy to ma jakieś znaczenie, ale poprzednią rewizję liczyłem na windowsie 7, a teraz na windowsie 10 for workstations.

Edytowane 22 Październik 2020 przez Winoo1

[SWRSC]

Rozumiem, że liczysz lokalnie, bez backburnera? Kilka propozycji, które przetestuj osobno wg poniższej kolejności:

1. W Task manager zmniejsz priorytet dla 3dsmax na "poniżej normalnego" - to u nas rozwiązywało kilka problemów z długim zapisem klatek i ogólna responsywnością systemu. Generalnie zawsze to robimy, polecam.

2. Sprawdź czy na pewno masz wyłączony bitmap pager (w zależnie od wersji maxa ta opcja będzie dostępna z poziomu UI lub z poziomu max scripu - znajdziesz w sieci komendę wyłączającą bitmap pager). Może jakimś cudem się włączył.

3. Wyłącz globalnie displacement, nawet jak jesteś przekonany, że go nie wstawiałeś w scenie (vRay > global switches);

4. Ten punkt łączy się z trzecim. Więc jak trzeci nie pomógł, to tutaj również wyłącz displacement oraz w zakładce vRay Settings > System ustaw Default geometry na static. Przy okazji upewnij się, że Dyn mem limit, mb masz ustawiony na wartość "0".

5. Czy korzystasz w scenie z jakiś pluginów do scattera geometrii? Jeśli tak to dla testu wyłącz cała warstwę z taką geometrią i odpal render.
5b. Wyłącz również wszystkie obiekty proxy.

6. Sprawdź liczenie przy wyłączonym Motion Blur

 

Jak masz czas aby przetestować powyższe to podziel się spostrzeżeniami. Chętnie pomogę w razie dalszych problemów.

 

[Winoo1]

Dziękuję serdecznie za wskazówki! Motion blur to postpro w fusion. Jesli chodzi o scattery, to używam forestpacków. Renderuję wszystko lokalnie, bez Backburnera. Jakoś nigdy się do niego nie przekonałem, chociaż próbowałem. Pozostałe wskazówki zaimplementuję, przetestuję i dam znaka.

 

Dzieki!

[Winoo1]

Zdaje się, że winowajcą są vrayproxy. Wszystkie wykonane czynności do punktu z vrayproxy nie przyniosły efektów. Dopiero wywalenie ze sceny proksiaków wyeliminowało problem. Będę musiał się przyjrzeć dokładnie w czym tkwi zagadka. Na pewno nie jest to problem z normalbumpami, nie sądzę aby to był także problem z shaderami, bo wszystko robię w vrayu i pilnuje by nie było zarzynających silnik "obcych" wkładów. W każdym razie - wiem gdzie szukać dalej. Serdeczne dzięki SWRSC za nakierowanie na potencjalne źródła kłopotów!

[SWRSC]

Hej, cieszę się, że mamy już jakiś trop 🙂 Jeśli to proxy to może być problem również z RAM komputera (w sensie jego ilości) i przepustowością pamięci. Ile masz go na pokładzie? Dysk to SSD?

Proponuję sprawdzić, czy podczas tego długiego liczenia LC w drugiej i kolejnych klatkach dysk twardy mieli coś - Task manager. Generalnie jego użycie powinno iść na 100% przez pierwsze sekundy liczenia LC, a później już niemalże na 0%. Jeśli dysk mieli na 100% przez cały okres liczenia LC to jest problem z bitmap pager lub z niewystarczającą ilością RAM w komputerze.
No albo jakaś wolna konfiguracja, której bardzo wolno zajmuje przerzucenie 50GB sceny do RAM, ale to raczej nie w tym przypadku.

Jeszcze jedna sprawa - Twoje największe tekstury w scenie jaką mają rozdzielczość?
I druga - te proxy masz utworzone na obecnej wersji vRay czy pochodzą ze starszych scen/starszej wersji vRay?

Jeśli chcesz też debugować proxy - zacznij od tych najcięższych (rozmiar pliku proxy). Kolejno rób hide ze sceny zaczynając właśnie od tych ciężkich.

Edytowane 23 Październik 2020 przez SWRSC

[Winoo1]

hejhej!

ramu na pokładzie mam 128 GB i jest to kingston HyperX ( 4x32 GB ) 3200 MHz. Dysk natomiast to Aorus NVMe Gen4 m2.  Sprawdzę jak to wygląda z aktywnością dysku podczas liczenia LC. Z tego co kojarzę, to dysk miał aktywność tak jak piszesz - na początku liczenia, później nie. Ale upewnię się dzisiaj jeszcze i dam znać. Ciekawe jest to, że po wywaleniu proxy ( gdzie geometria poza proxy także jest ciężka ) scena się kompiluje i liczy LC w sumie około 4-5 sekund, co jest świetnym wynikiem.

Co do tekstur - największe tekstury są 8k, i są to tekstury asfaltu. Jest ich w sumie chyba tylko 6. Pozostałe wahają się od 1,5K do 2,5K. No i tak jak wspomniałem - na scenie bez proxy nie ma żadnego problemu z renderingiem.

Proxy były tworzone także na NEXT, ale  na poprzednich update, bo to było jakoś w lipcu 2018.

 

Dla porównania - wyrenderowałem 120 klatek sceny na bruteforce + LC bez proxy - czas renderingu na klatkę - 3 minuty . Bajeczka 🙂

 

Edytowane 23 Październik 2020 przez Winoo1

[blood_brother]

Może naiwne pytanie, ale profile XMP, czy jak to się tam u AMD nazywa, włączyłeś?

[SWRSC]

ok, w updatach NEXTa były dwie kluczowe zmiany w proxy. Spróbuj debugować kolejno modele proxy tak jak wyżej opisałem. Jak znajdziesz wadliwą serię to może wygenerowanie go na nowo pomoże.

Sprzęt, tekstury - to raczej wszystko ok.

[Sebazx6r]

Ja jebie. Qrde naprawdę współczuję. 

Masakra. Brak mi słów. 

[c0ffymachyne]

Wczytujesz vray proxy z sieci ? Jaj szybka masz siec ? Twoj opis sugeruje ze cos moze byc albo liczone kadorazowo od poczatku animacji. lightcache ? Moze masz jakas zaleznosc czasowa w scene... Masz moze animacje w vray proxy czy tylko statyczne obiekty zanimaowane w maxie ?