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

[SebastianFM 413]

@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 440]

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 2 godziny temu przez musichunter1x

[tomcug 3 057]

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 887]

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 440]

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 1 godzinę temu przez musichunter1x

[tomcug 3 057]

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 440]

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 1 godzinę temu przez musichunter1x

[Kadajo 8 208]

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 057]

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 887]

3 minuty temu, Kadajo napisał(a):

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

Dlaczego ?

[musichunter1x 1 440]

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 1 godzinę temu przez musichunter1x