Techniki rekonstrukcji obrazu w grach - NVIDIA DLSS, AMD FSR, Intel XeSS, Sony PSSR oraz inne

[SebastianFM 416]

@tomcug, mam dla ciebie bardzo proste wyjaśnienie skąd taka różnica między RTX 2080 Ti i RTX 3080 Ti. Obliczenia wykonywane przez rdzenie Tensor to tylko połowa pracy. W najnowszym DLSS wykonywanych jest też bardzo dużo obliczeń na zwykłych jednostkach, a tutaj już jest duża różnica w wydajności.

[musichunter1x 1 442]

26 minut temu, tomcug napisał(a):

RTX 2080 Ti dwa razy dłużej przetwarza w 4K przy modelu L od RTX 3080 Ti, a oba GPU mają praktycznie tyle samo cache. Pamięć cache to nie jest magiczne pudełko, że dosypujesz więcej i więcej i pomaga w nieskończoność

Nie no Tomcug, ty też.
Przecież ja nie mówię że zwiększenie cache to rozwiązanie na wszystko i boost wydajności, tylko że gdy zabraknie cache na zamieszczenie konkretnych, potrzebnych danych w konkretnym momencie to powstanie przestój. 
Nawet wyżej podałem funkcję, która może przyczynić się do lepszego zarządzania cache przez Ampere -  L2 Cache Residency Control.
W tym co podałeś nie ma nic o tym, ile zajmują elementy z bufora poprzedniej klatki itp. 

Na dodatek Ampere wprowadziło sprawniejsze "asynchronous compute" co m.in. trochę odciążyło cache.
To wszystko właśnie służy minimalizowaniu przestojów...

Edytowane 20 godzin temu przez musichunter1x

[tomcug 3 061]

7 minut temu, SebastianFM napisał(a):

@tomcug, mam dla ciebie bardzo proste wyjaśnienie skąd taka różnica między RTX 2080 Ti i RTX 3080 Ti. Obliczenia wykonywane przez rdzenie Tensor to tylko połowa pracy. W najnowszym DLSS wykonywanych jest też bardzo dużo obliczeń na zwykłych jednostkach, a tutaj już jest duża różnica w wydajności.

Ok, wszystko jasne.

20 minut temu, musichunter1x napisał(a):

Nie no Tomcug, ty też.

Gdybyś miał jakieś sensowne argumenty, a nie teorię pisaną patykiem po wodzie, to można by to było traktować poważnie  Wracając jeszcze do tabelek NVIDII, RTX 4070 Ti vs RTX 3080 Ti to kolejny ciekawy przykład. RTX 4070 Ti ma 8x więcej cache L2, a w 4K z profilem L przewaga to tylko 67%. Coś się nie spinają te "keszowe" rewelacje.

[skypan 1 888]

Mogli by bardziej ogarnąć te opisy ustawień a nie np. L,K,M. Jak ktoś nie jest w temacie to guano to mówi. Mają tyle miejsca, że bez problemu zmieściły by się opisy czy to jest jakaś ultra wydajność czy coś innego. O wyskakujących dymkach to już nie wspomnę gdzie był by jeszcze rozszerzony opis na jakich kartach czy tam rozdzielczościach najlepiej się to sprawdza.

[musichunter1x 1 442]

Dobra, sam zmęczyłem się tą rozmową, a uciekło już meritum... Więc powtórzę sedno:

Skupiam się na kwestii opóźnienia wywołania danych z Vram, gdy akurat nie ma potrzebnych danych w cache, bo nie zdążyło ich przerzucić lub całość nie mieści się na raz. Dawniej karty skupiały się na intensywnym mieleniu danych, szybko zastępując cache następną porcją, aby jak najszybciej wykarmić rdzenie.
Teraz mogą zarezerwować fragment cache pod daną strukturę danych, aby zawsze była na miejscu, gdy jest potrzebna, bez czekania na wywołanie Vramu i przesłanie tego dalej... Dlatego wspominam L2 Cache Residency Control.
Również więcej elementów może być wywołanych "bezpośrednio" z Vramu, co zrobiło miejsce na inne elementy..., a raczej zwiększyło skuteczność upakowania danych bez przestoi. Dlatego wspomniałem o usprawnionym asynchronous compute w Ampere, które pozwala pominąć rejestr, kopiując dane w tle.

 

Rzucając tymi szacunkami użycia cache przez DLSS chciałem, aby ktoś zweryfikował w jakim stopniu zużycie pokrywa się z rzeczywistością... Nie dostałem żadnych informacji ile danych ładują katy do cache na rzecz DLSS, tylko ciągle przypomnienia "jak działa cache", gdy cały czas chodzi mi o redukcje przestojów przez umieszczenie danych w cache na czas...

Edytowane 19 godzin temu przez musichunter1x

[tomcug 3 061]

6 minut temu, musichunter1x napisał(a):

Teraz mogą zarezerwować fragment cache pod daną strukturę danych, aby zawsze była na miejscu, gdy jest potrzebna, bez czekania na wywołanie Vramu i przesłanie tego dalej... Dlatego wspominam L2 Cache Residency Control.
Również więcej elementów może być wywołanych "bezpośrednio" z Vramu, co zrobiło miejsce na inne elementy..., a raczej zwiększyło skuteczność upakowania danych bez przestoi.

Ale to jest tylko Twoja teoria, że to przynosi poprawę, na co nie ma żadnych praktycznych przesłanek, że karty z mało pojemną cache mają jakieś przestoje w obliczeniach i więcej cache dałoby poprawę. Nie ma dowodów, nie ma sprawy.

7 minut temu, musichunter1x napisał(a):

Nie dostałem żadnych informacji ile danych ładują katy do cache na rzecz DLSS

Nie wydaje mi się, żeby dało się to sprawdzić. Ale tę kwestię na pewno rozjaśni @SebastianFM, bo on się bawi profilerem od NVIDII.

[musichunter1x 1 442]

12 minut temu, tomcug napisał(a):

że karty z mało pojemną cache mają jakieś przestoje w obliczeniach i więcej cache dałoby poprawę. Nie ma dowodów, nie ma sprawy.
Nie wydaje mi się, żeby dało się to sprawdzić. 

Nvidia niby chwali się, że skutecznie upycha pewne dane do cache... Deweloperzy od czasów Ampere mogę wydzielać fragment L2, aby był "trwalszy" choćby dla jakiś kluczowych danych DLSS. Rozchodzi mi się o wielkość takich danych, które są tam upychane przy pomocy L2 Persistence, dodanym w Residency Control.
Stąd mój logiczny wniosek, że jeśli karta nie zmieści elementów, które skorzystałyby z trwałego L2 to musi być jakiś przestój. Mogę mylić się co do wielkości tych danych, bo to próbowałem oszacować przy pomocy AI.

 

Szkoda że dopiero teraz doprecyzowałem swoją tezę  

Edytowane 19 godzin temu przez musichunter1x

[Kadajo 8 217]

25 minut temu, skypan napisał(a):

Mogli by bardziej ogarnąć te opisy ustawień a nie np. L,K,M. Jak ktoś nie jest w temacie to guano to mówi. Mają tyle miejsca, że bez problemu zmieściły by się opisy czy to jest jakaś ultra wydajność czy coś innego. O wyskakujących dymkach to już nie wspomnę gdzie był by jeszcze rozszerzony opis na jakich kartach czy tam rozdzielczościach najlepiej się to sprawdza.

Jak ktoś nie jest w temacie nie powinien w ogóle tego ruszać.

[tomcug 3 061]

6 minut temu, musichunter1x napisał(a):

Deweloperzy od czasów Ampere mogę wydzielać fragment L2, aby był "trwalszy" choćby dla jakiś kluczowych danych DLSS. Rozchodzi mi się o wielkość takich danych, które są tam upychane przy pomocy L2 Persistence, dodanym w Residency Control.

Nigdy się nie interesowałem tą funkcjonalnością, ale gwarantuję Ci, że nawet jeżeli jest taka możliwość, to nikt DLSS tak nie implementuje

[skypan 1 888]

3 minuty temu, Kadajo napisał(a):

Jak ktoś nie jest w temacie nie powinien w ogóle tego ruszać.

Dlaczego ?

[musichunter1x 1 442]

35 minut temu, tomcug napisał(a):

 to nikt DLSS tak nie implementuje

Mogę głównie przy pomocy AI próbować coś wygrzebać, bo z pamięci to niewiele wygrzebię.
Na pewno wagi modelu i parametry sieci są zapisane jako "Persisting", jedno to 2-4MB drugie ~1MB.
Wektory ruchu itp. rzeczy z bufora klatki ciągle zmieniają się, więc tego należałoby nie liczyć, ale nadal musi przejść przez cache w odpowiednim momencie...
ALE, właśnie CNN miało ponoć "wagi statyczne", Transformer posiada jeszcze "mapy uwagi" - Attention Maps,  a same wagi są większe. Najlepiej, aby oba miały przypisany, trwały L2, gdzie AI szacuje to na 18-24MB + 6-10MB = 24-34MB, dla samych Model Weights oraz Attention Maps.
Użycie RR trochę dodaje MB do obu.

Wystarczy mi tematu na dziś. 
Edit. Tylko  dodam, że FP8 powinno zmniejszyć to o połowę lub coś zbliżonego.
Edit.2 Jeszcze wróciłem sprawdzić co powie w przypadku gddr6x rtx3060ti, bo przepustowość powinna trochę nadrobić braki cache. Wypluła coś takiego względem CNN, szacunki dla 1440p, chyba quality... Dla Performance wypluło już 1-3% dla gddr6x, względem gddr6 5-8%.

Edytowane 19 godzin temu przez musichunter1x

[Kadajo 8 217]

1 godzinę temu, skypan napisał(a):

Dlaczego ?

Zalecane ustawienia są optymalne.

Jak sobie wyobrażasz taki opis ?

Techniczne aspekty tych presetow sa skomplikowane i nie ma w sumie "jednego najlepszego", obejrzyj jakieś testy, chociażby ostatni Digital Foundry.

Tego się nie da opisać w dwóch zdaniach i założę się, że te opisy by więcej ludziom namieszały w głowach niż pomogły.

Presety mają różne optymalizację które nie koniecznie muszą być optymalne dla danej gry, jeśli je wymusisz co może powodować błędy w grafice.

Poza tym presety są ułożone od najstarszego do najnowszego wiec łatwo się i tak połapać. Ale jeszcze raz najnowszy nie musi oznaczać że dla danej gry będzie najlepszy.

Dlatego jeszcze raz napisze, zalecane ustawienia Nvidii są w tym przypadku naprawdę ok i nie ma większego sensu ich ruszać, chyba że dla zabawy.

[sideband 2 204]

4 godziny temu, musichunter1x napisał(a):

@sidebandMógłbyś odnieść się do L2 Cache Residency Control? Na dodatek powtórzę - nie zrozumieliśmy się w przypadku "wspólnego L2".
Przecież nie chodzi o fizyczne położenie L2, lecz o wspólne adresowanie danych dla "wszystkich rdzeni". W CPU są oddzielne dla każdego rdzenia, w GPU tak nie jest.

To dotyczy przecież tylko CUDA i nie ma żadnego zastosowania w grach  

Czy jest to wykorzystane przy DLSS tego nie wiem poza tym patrząc na benchmarki często ta opcja nie przynosi żadnego kopa 

Poza tym dużo istotniejsza jest L0/L1 i rejestry na dane w samych SM-ach. Przykładowo w Turingu L1 nie tylko jest 2x szybsza względem Pascala, ale też posiada 2.5x niższe opóźnienia. Od Ampere są spore zmiany L1 o czym można poczytać w specyfikacji.

 

Przykładowo Hopper 2x pojemniejszą L1 niż Blackwell, ale w Blackwellu skompensowano to wydajniejszą i pojemniejszą L2. Istotne też jest by ładowanie dodatkowych tranzystorów miał sens i przynosił chociażby wzrost wydajności na wat.

 

Specyfika L1 jest taka, że ta pamięć nie może być pojemna i stąd wynika jej duża szybkość. Za to można stworzyć więcej mniejszych SM-ów tylko czy to ma sens tego nie wiem  

Dodatkowy spadek wydajności w Turingu z DLSS + RT wynika z tego, że nie może liczyć jednocześnie DLSS + RT, a Ampere już tak 

 

GPU projektuje się na emulatorach to można sprawdzać wiele scenariuszy w przybliżeniu  Poza tym widać architektura NV zaczyna witać się ze ścianą prędzej czy później dojdzie do dużych zmian w architekturze.

 

[musichunter1x 1 442]

39 minut temu, sideband napisał(a):

Specyfika L1 jest taka, 

Tylko że mówię typowo o L2, a ta funkcja jest używa właśnie przy DLSS. 

 

Jedynie wcześniej przesadziłem z szacunkami użycia cache, bo malo co korzysta z "trwałego" trybu L2 i prawie wszystko działa tak, jak argumentowaliście w tym wątku.

[SebastianFM 416]

Zrobiłem takie porównanie, DLSS 4.5 (v310.5.2), DLAA, Preset M, 1080p vs 4K. Celowo użyłem DLAA, żeby rozmiar danych wchodzących był większy. Z całego przetwarzania DLSS zaznaczyłem w obydwu przypadkach te same 5 etapów. Statystyki po prawej stronie dotyczą tylko zaznaczonego fragmentu.

 

1080p.

 

4K.

 

Widać, że w wyższej rozdzielczości jest odczytywanych i zapisywanych w pamięci VRAM więcej danych jednak nie wpływa to negatywnie na wydajność.

[tomcug 3 061]

Ja Ci mogę to bardzo prosto przetestować. Wziąć 3060 Ti GDDR6X i 3070, zobaczymy czy 608 vs 448 GB/s coś pomoże przy DLSS 4.5.

[MaxaM 1 837]

@SebastianFM

Wydaje mi się, że nie do końca rozumiesz co @musichunter1x chce przekazać.

To co pokazałeś dowodzi w zasadzie nic. Dla uproszczenia przyjmijmy, że przetwarzanie DLSS, to instrukcje, jakieś stałe, tablice + dane do przetworzenia.

Instrukcje, stałe i tablice najprawdopodobniej niemal zawsze rezydują w cache ze względu na powtarzalność algorytmów. Pewnie jest to maksymalnie parę MB.

Z kolei przetwarzane dane są duże i niekoniecznie potrzebują opierania się o cache. Tu mogą lecieć już dane wręcz w GB z VRAM jak pokazałaś wyżej.

Problem może właśnie nastąpić gdy ze względu na mniejszy cache instrukcje i stałe DLSS zaczną wypadać z niego pogorszając wydajność DLSS i być może nawet to pokazujesz na screenshotach w postaci paru procent różnicy w hit ratcie.

A być może też w grę wchodzi właśnie zafixowanie na stałe w cache instrukcji i stałych DLSS aby nigdy nie wypadały z niego (dostępne właśnie od Ampere).

Czy tak się dzieje, nie wiem.

Pewnie byłoby trzeba przeanalizować co dokładnie robią wątki DLSS, jakie mają opóźnienia w których miejscach, ale pewnie nie ma takich publicznych narzędzi.

Czy da się podglądać cache używając dostępnych publicznie narzędzi? Jeśli tak, to przynajmniej można byłoby stwierdzić, czy coś siedzi w cache na stałe włączając DLSS

Edytowane 15 godzin temu przez MaxaM

[SebastianFM 416]

@MaxaM, kolejna porcja domysłów i zgadywanek. Ja natomiast opieram się na faktach. Próbujecie być mądrzejsi od inżynierów NVIDIA. Ty się mądrzysz o jakimś wypadaniu jakichś stałych danych, jakichś instrukcji z cache. Wiesz w ogóle o czym piszesz?

[MaxaM 1 837]

@SebastianFM

Ja piszę na razie o oczywistych faktach, że do cache lądują i instrukcje jak i dane. Chociaż instrukcje to bardziej L1.

Na razie w swoich wywodach opierasz się na przetwarzanych danych pomijając całkowicie jak się zachowują właśnie instrukcje i przede wszystkim duże stałe w kontekście cache, o których ciągle mówi @musichunter1x

Więc ja nie wiem co to za insynuacja o bycie mądrzejszym od inżynierów nvidii.

W ogóle co to za obrona poprzez atak? Domysły, że instrukcje lecą do cache? Weź na wstrzymanie albo odnieś się do clue tego o czym pisze @musichunter1x, jego hipotezy  

 

Edytowane 14 godzin temu przez MaxaM

[skypan 1 888]

4 godziny temu, Kadajo napisał(a):

Jak sobie wyobrażasz taki opis ?

Dla mnie te ustawienia to nic innego jak dodatkowe ustawienia jakości obrazu jakie mamy w grze i opis w panelu Nvidii mógł by zawierać opis chociażby jakie ustawienia zalecane są do konkretnych kart np. K (RTX 2xxx-3xxx itp.) Samo dodanie czy dane ustawienie odpowiada do Ultra Performance czy też nie znacząco ułatwiło by zrozumienie co kryje się pod daną literą. A jak ktoś nie ogarnia co i jak, nie chce tego ruszać to te opisy w niczym by nie przeszkadzały

Edytowane 13 godzin temu przez skypan

[JohnyWol 113]

48 minut temu, skypan napisał(a):

Dla mnie te ustawienia to nic innego jak dodatkowe ustawienia jakości obrazu jakie mamy w grze i opis w panelu Nvidii mógł by zawierać opis chociażby jakie ustawienia zalecane są do konkretnych kart np. K (RTX 2xxx-3xxx itp.) Samo dodanie czy dane ustawienie odpowiada do Ultra Performance czy też nie znacząco ułatwiło by zrozumienie co kryje się pod daną literą. A jak ktoś nie ogarnia co i jak, nie chce tego ruszać to te opisy w niczym by nie przeszkadzały

Ale tak się nie da opisać, bo to który preset będzie lepszy zależy raz że od sprzetu, (czyli głównie która to generacja GPU) a dwa to także od konkretnej gry.

 

W skrócie i maksymalnym uproszczeniu:

- presety A do E to najstarszy typ DLSS czyli tzw CNN. Ma najmniejsze obciążenie dla sprzętu, ale też niższą jakość obrazu,  większe smużenie

- presety J i K to tzw. DLSS Transformer (1 generacja zwana tez DLSS 4.0). Daje dużo wyższa jakość obrazu, lepszą ostrość (zwłaszcza w ruchu) ale też  jest bardziej wymagające

- presety L i M to najnowsza generacja DLSS Transformer (2 generacja) tzw. DLSS 4.5. Na kartach RTX 2xxx i RTX 3xxx powoduje duży spadek wydajności, na kartach RTX 4xxx i RTX 5xxx też moze wynieść nawet do 10% w niektórych przypadkach. Maja jeszcze lepsza jakosc obrazu niz DLSS 4.0 i wyzsza ostrość obrazu i dlatego też Presety L i M są stworzone głównie z myślą o stosowaniu dla trybów Ultra Performance i Performance. Oczywiście można też korzystać w trybach Balanced, Quality i DLAA ale nie w każdej grze obraz bedzie wyglądał lepiej niż preset K, a wydajność na pewno będzie niższa

 

Więc tak na prawdę jedyny opis ktory mogli by dodać to np. że jest to DLSS 3, DLSS 4.0 Transformer v1 i DLSS Transformer v2.

 

Jak nie chcesz soe bawić w eksperymentowanie i testowanie który tryb najlepiej ci pasuje pod względem wydajności i jakości obrazu to najlepiej użyć ustawoen zalecany. Wtedy dla trybów DLAA, Quality i Transformer jest używany DLSS 4.0 a dla Performance i Ultra Performance DLSS 4.5. Nie wiem tylko czy tak ustawia też na kartach RTX 2xxx i RTX 3xxx, bo może wtedy zalecane pomijają np. DLSS 4.5 ze względu na spadek wydajności 

[SebastianFM 416]

@MaxaM, to nie ja robię wywody tylko wy nie mając pojęcia nawet o podstawowych rzeczach. Piszesz, że to co pokazałem nic nie wnosi a to ty nie potrafisz wyciągnąć z tego sensownych wniosków. Np. drugi i czwarty etap z tych zaznaczonych przeze mnie. W 1080p nie odczytują z VRAM, ponieważ przetwarzane dane mieszczą się w cache. W 4K podczas tych dwóch etapów trwających 1,2 ms odczytywanych jest z pamięci VRAM około 130 MB danych. Czy wpływa to negatywnie na wydajność? Oczywiście, że nie, nawet w najmniejszym stopniu. To właśnie obala hipotezę @musichunter1x'a, że trzeba coś blokować w cache, że są jakieś niby przycięcia jak dane nie mieszczą się w cache, itp.

[skypan 1 888]

10 godzin temu, JohnyWol napisał(a):

Ale tak się nie da opisać, bo to który preset będzie lepszy zależy raz że od sprzetu, (czyli głównie która to generacja GPU) a dwa to także od konkretnej gry.

Dla mnie sam sobie zaprzeczyłeś  Nie da się a się da z tego co czytam.  Całe dwa posty o tym napisałem 

[musichunter1x 1 442]

15 godzin temu, SebastianFM napisał(a):

Zrobiłem takie porównanie, DLSS 4.5 (v310.5.2), DLAA, Preset M, 1080p vs 4K. Celowo użyłem DLAA, żeby rozmiar danych wchodzących....

Eh, tylko nie zwróciłeś uwagi że DLSS 4.5 używa FP8 co zmniejsza wielkość danych, ale w sumie nie da rady inaczej, bo na Ada nawet preset K działa w FP8. Dopiero preset L używa więcej parametrów, ale musiałbym sprawdzić, które są "trwałe", bo moje początkowe teoretyzowania nie rozróżniały tego. W skrócie - moje dumania były błędne, ale z innego powodu niż sugerowaliście... No jeszcze kompletnie błędne było założenie, że znacznie więcej elementów może korzystać z "L2 persistance".

 

Już wspomniałem w poprzednim komentarzu, że przesadziłem z szacunkami użycia cache, bo niewiele rzeczy używa trybu "trwałego", nawet w DLSS Transformer są to głównie 2 elementy. Na 48MB nie przekroczysz tego, może nawet na 32MB przy FP8.

 

Więc moje początkowe założenia były rozdmuchane i w sumie trzebaby czekać ma kolejną wersję DLSS z jeszcze większą objętością elementów w "trwałym L2".

Ewentualnie możnaby testować na Ampere preset K, ale tam i tak zawsze przekroczy cache przez co nawet nie spróbuje załadować na stałe tych 2 elementów, które w CNN były znacznie mniejsze.

 

Edit. No i te piękne dane z testu niestety raczej nie pokazują ile cache wydzielono jako "persistent L2", ale dziękuję za zaangażowanie. Może jeszcze są tam dodatkowo informacje?

 

Edit.2 Potem spróbuję poszukać czy coś jeszcze zauważalnie korzysta z L2 persistence. Wcześniej wkleiłem tylko listę przykładowych elementów mielonych przez cache i już nie dziwię się skąd wasze oburzenie, bo rzeczywiście tam raczej wszystko lub większość używa cache w klasycznym sposób. Jedynie "trwały L2" ogranicza pulę wolnego L2 dla reszty. 

Edytowane 46 minut temu przez musichunter1x