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

[Phoenix. 5 364]

Nie wiem dlaczego ludzie nadal mysla, ze te mody to to samo co MFG na Blackwell 

[skypan 1 887]

  

32 minuty temu, sideband napisał(a):

nie musi wspierać starego parcha 

 

Parcha mówisz.

Edytowane Czwartek o 17:21 przez skypan

[musichunter1x 1 440]

Heh, pewnie znowu jestem spóźniony z tematem lub mam błędne informacje. 

Podłubałem trochę w temacie mieszczenia się DLSS transformer w cache. Ampere traci nawet na presecie K, mimo że używa FP16, ponieważ 4mb cache w takim rtx3070 nie pomieści transformera, a opóźnienia Vramu są wielokrotnie większe.

Aby zmieścić 4K DLSS Performance preset K potrzeba ~40mb, mniejsze rozdzielczości i tryby mieszczą się w 32mb.

 

Natomiast preset M zajmuje mniej niż 32MB przy 4K Performance, ale preset L przebija już 32mb, okolice 35-40mb..
Przy Ultra Performance preset L spada już poniżej 32mb...
Więc najpewniej tutaj leży jedna z przyczyn zalecania tych presetów do trybu Performance, a drugiego do 4K UP.
48mb ma dopiero rtx4070super oraz rtx5070...

Edit. RR dodaje jest swoje, więc ciekawe na ilu skończy się.  Muszą dodać RR do FP8, bo inaczej dopiero 1440p DLSS Perfomance z RR ledwo nie przekracza 32mb.

Edytowane wczoraj o 12:55 przez musichunter1x

[VRman 3 151]

o, bardzo ciekawe.

 

Nie patrzyłem na testy 5080tki, ale ona ma 64MB. 

Może wypadki przy pracy typu -10% wydajności względem DLSS4 na 5070tkach się nie zdarzają na 5080?

 

PS. Nie wiem czy trafiłeś z dedukcją, ale ja od dawna się śmieję z pelikanów co łyknęli "przecież to jest preset do ultra performance" bo tak powiedziały ludki z Nvidii.

[musichunter1x 1 440]

23 godziny temu, VRman napisał(a):

PS. Nie wiem czy trafiłeś z dedukcją, ale ja od dawna się śmieję z pelikanów co łyknęli "przecież to jest preset do ultra performance" bo tak powiedziały ludki z Nvidii.

Edit. Dobra już nieważne, sideband wyjaśnił temat.
Edit.2 W sumie to już nie wiem czy mam częściową rację czy nie, bo niektórzy nie rozumieją że cache zachowuje się teraz inaczej niż przed Ampere. 

Poczekajmy aż dodadzą RR na FP8 to wtedy 32MB pewnie nie starczy, no chyba że w 1080p.  
AI coś tam plecie, że RR dla presetu K to dodatkowy koszt 10-20-30MB, oczywiście zależy od rozdzielczości. FP8 powinno obniżyć to o ~połowę i wtedy będzie działać z presetem M oraz L.

 

Dodając....

RR niby dalej działa na FP16, więc mogą zmniejszyć zużycie cache, gdy przejdą na FP8 i chyba na to czekamy?
1080p DLSS quality, preset K + RR = 28-32MB, ale może wyskoczyć poza 32MB.
1440p DLSS balance, preset M + RR = 24-28MB, quality dobija już do ~40MB

2160p DLSS performance, preset M + RR = 32-36MB, przynajmniej rtx4070 już ma 36MB  
To samo ale na quality  = 42-48MB

 

ALE, jeszcze inne rzeczy walczą o miejsce w L2 cache, więc dobrze mieć zapas. Ta reszta może zając 6-24MB, a może nawet więcej, bo przy natywnej pokazuje mi do ~50MB w 4k.

Więc jeśli gry już wrzucają te swoje drobnostki do cache to wtedy architektury z >=32MB zyskują i takie rtx4060ti / 5060 będą lepsze od rtx3070.

Edit... Jeszcze jedno dodając:
PS5 i PS5 Pro maja tylko 4MB cache, więc nic dziwnego że nie mogą ogarnąć lepszego skalowania w sposób nie zjadający wydajności. 
Xbox Series X podobnie -5MB, Switch 2 - 4MB, więc na szeroką optymalizację do bufora trochę poczekamy...

Edytowane 1 godzinę temu przez musichunter1x

[sideband 2 195]

Dobra rada polecam dokształcić się w kwestii działania GPU i pamięci podręcznej różnych poziomów.

Niezła produkcja dyrdymałów 

[musichunter1x 1 440]

6 godzin temu, sideband napisał(a):

Dobra rada polecam dokształcić się w kwestii działania GPU i pamięci podręcznej różnych poziomów.

Niezła produkcja dyrdymałów 

? Jest cache na każdy SM - L1, L2 wspólny o którym pisałem i od biedy AMD dorobiło sobie "L3" - infinity cache.
Pomaga to szczególnie mocno, gdy mieszczą się małe kluczowe elementy, co skraca czas dostępu, bo Vram ma znacznie większe opóźnienia.
Skupiłem się na DLSS, ponieważ komplet danych zajmuje sporo miejsca i musi być w całości w cache, inaczej dostaje opóźnieniem z Vramu i karta czeka, choć nadal to niewiele.
Gdy załaduje pewne rzeczy do cache to nie czeka potem na dostęp do nic, dzięki niższemu opóźnieniu.

Nvidia wręcz chwali się optymalizacją DLSS, tak aby dane zmieściły się w cache...

Edit. Doprecyzuję że chodzi głównie o DLSS Transformer, ponieważ ma "całościowy" kontekst obrazu, a nie małe, najbliższe wycinki, stąd zajmuje więcej cache lub siedzi we Vram, działając wolnej przez opóźnienia.

Edytowane 16 godzin temu przez musichunter1x

[sideband 2 195]

Nawet nie wiesz jak zbudowane jest L2 w ADA/Blackwell  

Tam nie masz jednego dużego L2 tylko składa się z kawałków i jest podzielona na partycje  Oczywiście w starszych architekturach było to samo z z tą różnicą, że istniało bezpośrednio przywiązanie L2 do ROP i kontrolera pamięci.

GPU wykonuje równolegle wiele obliczeń jednocześnie takie rozwiązanie ma wpływ na efektywniejsze wykorzystanie GPU.

Rozmiar został dobrany tak by zwiększyć Hit rate przy konkretnych obliczeniach i poprawić działanie podsystemu pamięci. W pamięci podręcznej są tylko trzymane dane, które nie zmieściły się w L1, ale zarazem do których GPU potrzebuje częsty i szybki dostęp dlatego lądują w L2. Zwiększanie L2 w nieskończoność nic nie da 

Przykładowo w 5090 rzeczywista przepustowość wynosi 0.9x względem teoretycznej po przepełnieniu L2 co jest doskonałym wynikiem. Do rozmiaru L2 przepustowość wynosi ~2.2x.

[VRman 3 151]

O, post bez szydery, po prostu czyste info.

 

Można? Można!

 

Tak trzymać!

[leven 720]

Zgadza się, z 2 razy to czytałem i jest git 

[SebastianFM 411]

To są bzdury, że akurat DLSS wymaga dużego cache. NVIDIA w generacji RTX 40 znacznie zmniejszyła przepustowość pamięci a duży cache to rekompensuje. Było już wiele dyskusji na ten temat więc myślę, że nie ma co do tego wracać. Wystarczy sobie porównać specyfikację i wydajność w grach RTX 3090 Ti z RTX 4070 Ti.

 

Używając profilera NVIDIA Nsight Graphics można uzyskać dużo ciekawych informacji.

 

Ilość danych przetwarzanych przez DLSS jest dużo większa niż rozmiar cache, nawet przy rozdzielczości wyjściowej 1080p.

 

DLSS 4.5 (v310.5.2), Performance, Preset M.

Całe przetwarzanie DLSS na GPU (RTX 4070 Ti) zajmuje w zależności od rozdzielczości wyjściowej:

1080p: 0,79 ms,

1440p: 1,24 ms,

4K: 2,75 ms.

Raczej z tych czasów nie wynika, że rozmiar cache ma wpływ na wydajność. W rozdzielczości 4K jest 4 razy więcej danych do przetworzenia i 4 razy więcej obliczeń niż w 1080p a czas jest 3,48 razy dłuższy.

 

Przy rozdzielczości wyjściowej 4K podczas jednego przetwarzania DLSS, Performance, Preset M odczytywanych z pamięci VRAM jest 477 MB a zapisywanych 416 MB.

[Kadajo 8 207]

Z tego wynika ze większy cache by przyspieszył wykonywanie obliczeń.

Zresztą, jeśli kolejne karty będą miały faktycznie większy cache to i tak pod nie przede wszystkim będzie robiona optymalizacja wiec wielkość cache, tak czy siak, ma znaczenie.

A że DLSS jest praktycznie teraz już podstawa dla Nvidii to wszytko jest ze sobą powiązane.

[SebastianFM 411]

@Kadajo, to są błędne wnioski. Ograniczeniem jest wydajność jednostek obliczeniowych.

[Kadajo 8 207]

Czyli na każdej karcie cache jest wykorzystywany w sposób maksymalnie optymalny ?

[musichunter1x 1 440]

@sideband Dzięki za komentarz, ale dalej nie wiem czy się zrozumieliśmy... Przecież  skądś kojarzę, że L2 jest wspólny dla wszystkich jednostek obliczeniowych... Chodzi mi o sposób obsługi, a nie budowę, gdy mówię o "wspólnym" L2.

Wiem że cache ma niby nadrobić przepustowość pamięci od Ady, ale chodzi mi magazynowanie w nim elementów wymagających szybkiego dostępu...
Ponoć od czasów Ampere można "rezerwować" cześć L2 np. dla elementów DLSS - wagi sieci neuronowej, wektory ruchu, buforowanie poprzednich klatek, gdzie w L2 są tylko aktualnie przetwarzane elementy lub tylko niektóre dane...
Przejmowanie funkcji L1 to tylko jedna z czynności wykonywanej przez L2...

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

To są bzdury, że akurat DLSS wymaga dużego cache. NVIDIA w generacji RTX 40 znacznie zmniejszyła przepustowość pamięci a duży cache to rekompensuje. 

Nadrabianie przepustowości to tylko jedna z funkcji...

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

Ilość danych przetwarzanych przez DLSS jest dużo większa niż rozmiar cache, nawet przy rozdzielczości wyjściowej 1080p.

Przy rozdzielczości wyjściowej 4K podczas jednego przetwarzania DLSS, Performance, Preset M odczytywanych z pamięci VRAM jest 477 MB a zapisywanych 416 MB.

Tutaj kompletnie nie rozumiemy się, ponieważ dla mnie oczywiste jest, że chodzi o aktualnie przetwarzane elementy i małe, kluczowe rzeczy które można zmieścić w cache... Niektóre wymieniłem wyżej w tym komentarzu. Choćby cały bufor poprzedniej klatki nie będzie w cache, tylko potrzebne elementy. 

Edit. Na szybko z pomocą AI sporządziłem listę przykładowych rzeczy, które trafiają do cache, gwiazdka to funkcje wykonywane również przez L1:

Spoiler

1. AI i Rekonstrukcja Obrazu (DLSS / Tensor Cores)

Wagi sieci neuronowej (Weights)

Fragmenty obrazu wejściowego (Input Tiles)*

Wektory ruchu (Motion Vectors)*

Embeddingi/Tokeny wizualne (DLSS Transformer)

Aktywacje warstw sieci (Activations)

Dane z akceleratora przepływu optycznego (OFA)

2. Śledzenie Promieni (Ray Tracing / RT Cores)

Struktury BVH (Węzły drzewa obiektów)*

Dane o przecięciach promienia z trójkątem (Intersection Data)

Stany promieni (Ray States)

Mapy widoczności (Visibility Buffers)

Dane Micro-Mesh (Displacement)*

Radiance Cache (Oświetlenie pośrednie)

3. Grafika Tradycyjna i Geometria (Rasteryzacja)

Fragmenty tekstur i mapy MIP (Texture Cache)*

Bufory głębi (Z-Buffer / Depth Buffer)

Atrybuty wierzchołków (Vertex/Index Data)*

Tablice parametrów globalnych (Constant Buffers)*

Dane teselacji i geometrii proceduralnej*

Tile Status Payloads (Informacje o kafelkach ekranu)

4. Obliczenia i Programowanie (CUDA / GPGPU)

Zrzuty rejestrów (Register Spills / Local Memory)

Operatory atomowe i liczniki (Atomic Counters)

Bariery synchronizacji między rdzeniami (Sync Barriers)

Bufory pamięci globalnej (Global Memory Buffers)

Tablice stron pamięci (Page Tables)

Dane stosu (Stack Data)

5. Systemowe i Zarządzanie Potokiem

Mikrokod shaderów (Shader Instructions)*

Kolejki poleceń (Command Queues)

Struktury sortowania instrukcji (SER - Shader Execution Reordering)

Metadane kompresji pamięci (Compression Metadata)

Firmware sterujący taktowaniem i energią

Bufory akumulacji czasowej (Temporal Buffers)

Edit.2 Również poprosiłem o tabelkę z oszacowanym zapotrzebowaniem na te elementy... Oczywiście im niższa rozdzielczość tym mniejsze zapotrzebowanie. Raczej nie bierze pod uwagę użycia FP8 w niektórych przypadkach:

Edytowane 2 godziny temu przez musichunter1x

[SebastianFM 411]

@musichunter1x, jak się stawia jakąś tezę to wypadałoby mieć argumenty na jej poparcie a tobie ich brakuje.

 

Porównanie wydajności DLSS na różnych kartach graficznych z różnym rozmiarem pamięci cache potwierdza, że nie masz racji w tym temacie.

 

 

RTX 4090 ma większy rozmiar cache od RTX 4080 o 12,5% natomiast ma o 50% wydajność w 4K.

RTX 4090 ma większy rozmiar cache od RTX 4070 Ti o 50% natomiast ma prawie 2 razy wyższą wydajność w 4K.

 

Zwróćcie uwagę, że właśnie w 4K jest największa różnica w wydajności a przy niewystarczającym rozmiarze pamięci cache byłaby zupełnie odwrotna tendencja.

[musichunter1x 1 440]

17 minut temu, SebastianFM napisał(a):

 

RTX 4090 ma większy rozmiar cache od RTX 4080 o 12,5% natomiast ma o 50% wydajność w 4K.

RTX 4090 ma większy rozmiar cache od RTX 4070 Ti o 50% natomiast ma prawie 2 razy wyższą wydajność w 4K.

 

Zwróćcie uwagę, że właśnie w 4K jest największa różnica w wydajności a przy niewystarczającym rozmiarze pamięci cache byłaby zupełnie odwrotna tendencja.

? Ale rozumiesz że FPS nie skaluje się liniowo z cache? Jeśli potrzebne dane mieszczą się to nie ma dodatkowych opóźnień wynikających z czekania na Vram. Jeśli cache wystarcza to wydajność zależy tylko od mocy obliczeniowej, a wątpię by Nvidia pokazała tabelkę na przykładzie przekroczenia cache... Jak już to pewnie zakładają brak potrzeby sięgania bezpośrednio do Vramu..., bo jest  za dużo zmiennych przy przekroczeniu, aby to uwzględnić w prostej tabelce... Choćby różne opóźnienia dla gddr6, gddr6x, gddr7, przepustowość, stopień przekroczenia cache, rodzaj wyrzuconych danych do Vramu...
Przekroczenie cache to spadek wydajności o kilka % i potencjalne rwanie, choć zależy ile i co wrzuciło do Vramu, bo może to być większy ubytek.

Edytowane 2 godziny temu przez musichunter1x

[Phoenix. 5 364]

Cache toCache  i to tak jakby mowic, ze w ryzneach 3D cos sie nie miesci w cache i dziala wolnej co jest oczywiscie blednym stwierdzeniem wiedzac po pierwsze jak dziala pamiec cache  

[SebastianFM 411]

@musichunter1x, co ty mi tłumaczysz? Właśnie gdyby w wyższej rozdzielczości był spadek wydajności większy niż to wynika z większej ilości obliczeń spowodowanej większą liczbą pikseli, to wtedy możnaby spekulować, że rozmiar cache jest niewystarczający. Przy DLSS coś takiego nie ma miejsca. W 4K przetwarzanie DLSS zajmuje 4 razy dłużej niż w 1080p. Karta z 2 razy większą wydajnością w obliczeniach ma 2 razy krótszy czas przetwarzania pomimo tego, że nie ma 2 razy większego cache.

[musichunter1x 1 440]

23 minuty temu, Phoenix. napisał(a):

Cache toCache  i to tak jakby mowic, ze w ryzneach 3D cos sie nie miesci w cache i dziala wolnej co jest oczywiscie blednym stwierdzeniem wiedzac po pierwsze jak dziala pamiec cache  

Dla mnie cache to po części taki odpowiednik kondensatora, ale mam wrażenie że kompletnie pomijasz większą ilość i wagę elementów które obecnie tam trafiają... Karta doładuje sobie potrzebne dane z Vramu, ale problemem są opóźnienia.
Ada usprawniła również zarządzanie wymianą tych danych...

 

Nie skupiasz się przypadkiem na samej roli cache jako ""kondensatora", nie biorąc pod uwagę jakie elementy tam trafiają i co się dzieje gdy nie są tam w całości lub na czas?

19 minut temu, SebastianFM napisał(a):

Karta z 2 razy większą wydajnością w obliczeniach ma 2 razy krótszy czas przetwarzania pomimo tego, że nie ma 2 razy większego cache.

Bo nie musi mieć 2 razy wiekszego cache? Przecież nie to argumentuję... Z czym się tutaj kłócisz, bo sam już nie wiem...
Jeśli cache nie starcza na raz to GPU czeka aż Vram dośle potrzebne rzeczy i wtedy jest mały przestój o ten czas potrzebny na dosłanie. Nvidia mogła tak dobrać przypadek testowy, by nigdy nie przekroczyło, aby mieć czyste dane o mocy obliczeniowej. 

Edytowane 1 godzinę temu przez musichunter1x

[Phoenix. 5 364]

Ale cache to nie ram, tam dane przelatuja po prostu   

Tam sie nic nie chowa w takim potocznym rozumieniu jak alokacja w ramie.

[musichunter1x 1 440]

29 minut temu, Phoenix. napisał(a):

Ale cache to nie ram, tam dane przelatuja po prostu   

Tam sie nic nie chowa w takim potocznym rozumieniu jak alokacja w ramie.

Ale ja to wiem... Chyba ciągle obracasz się w czasach sprzed Ampere, gdzie wprowadzili L2 Cache Residency Control.
Chodzi o to, że obecnie jest tak używany do niektórych danych, bo można wcześniej zaplanować jakie będą potrzebne...
Zamiast czekać aż karta będzie potrzebowała np. elementów bufora z poprzedniej klatki, to można załadować je tuż wcześniej, w odpowiednim momencie lub po prostu zadbać by miało miejsce / zapobiec ich usunięciu z cache.
Tak to karta sprawdziłaby czy jest w L1, L2 i wydała żądanie o przesłanie z Vramu, co spowodowałoby mały przestój przez czekanie na dużo wolniejszy Vram... 

Edit. Serio już myślałem że pogubiłem się przy sprawdzaniu tematu, ale po prostu nie rozumiecie co mam na myśli, bo ciągle mówicie o funkcji cache sprzed Ampere...
Teraz przynajmniej mam przypuszczenie co do kolejnego elementu przyczyniającego się do gorszej wydajność m.in. DLSS na Turing.

Edytowane 1 godzinę temu przez musichunter1x

[SebastianFM 411]

33 minuty temu, musichunter1x napisał(a):

Jeśli cache nie starcza na raz to GPU czeka aż Vram dośle potrzebne rzeczy i wtedy jest mały przestój o ten czas potrzebny na dosłanie.

Ty cały czas robisz błędne założenia. GPU przetwarza obraz/dane małymi fragmentami. Przetwarzanie jest podzielone na etapy i jest rozłożone w czasie. W każdym etapie każdy SM dostaje do przetworzenia małą część. Jak skończy przetwarzanie to dostaje kolejną.

[musichunter1x 1 440]

@SebastianFMPrzecież nie o tej podstawie jest dyskusja...
Tak, przetwarzane jest małymi fragmentami, sam to wspominam i nie wiem po co w innym komentarzu pisałeś o całym pliku DLSS, gdy chodziło mi o przechowywanie elementów z poprzedniej klatki w cache. Od Ampere mogą decydować o zarządzaniu danymi w cache, bez poleganiu na samej automatyce układu. CNN miało właśnie mniejsze fragmenty, transformer stara się patrzeć "całościowo" na piksele, stąd większy rozmiar danych, któe mogą skorzystać z niskich opóźnień.
Tak, dane są ładowane do cache na bieżąco, "rozłożone w czasie"... Chodzi właśnie o redukcje przestojów przez poprawę zarządzania tym, co ma się znaleźć w L2 i zapobiegnięciu usunięciu potrzebnych danych przy ładowaniu kolejnych. Pewne dane skorzystają na planowanym umieszczeniu w cache dzięki niższym opóźnieniom... Właśnie na tym zyskuje m.in. DLSS oraz RT.

Serio niektórzy nie rozumieją, że od Ampere trochę zmieniło się, gdzie Ada umożliwiła ciekawszą utylizację L2 przez większy rozmiar... Developerzy mogą tego nie optymalizować, skoro konsole nadal siedzą na paru MB.

Edit. Sam już nie wiem, kto jest tu ignorantem ja czy reszta.  
To o czym mówię jest możliwe od czasu wprowadzenia m.in. L2 Cache Residency Control.
Od tamtego czasu GPU nie używa cache tylko jako strumienia, teraz może być wydzielone "trwałe" miejsce na dane, które skorzystają na trochę dłuższej obecności lub zagwarantowanym miejscu. Piszecie tak, jakby to było niemożliwe.

@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.

Edytowane 34 minuty temu przez musichunter1x