AMD NAVI

[Dario+ 380]

Raczej sterowniki nic do tego nie mają , wczoraj wyszła jakaś aktualizacja gry i wydaję mi się że dużo stabilniej a sterowników nie zmieniałem (20.5.1)

 

A co do błędu 6068 , jest opis na stonie śledzenia gry

https://trello.com/b/PNA6fkWY/infinity-ward-modern-warfare

 

 

 

We've identified an issue that is causing hang crashes on the GPU, particularly during Campaign cutscenes. These crashes will be addressed in an upcoming patch.

 

Workaround: Try running VRAM under maximum and/or run the game with the default settings.

Edytowane 6 Czerwca 2020 przez DariŽ

[Kemotnik 0]

Panowie , jak to u was jest z black screenami? Bo u mnie na RX 5600XT nadal wystepują, tzn grając w warzona czasami mam bląd Directx 6068, a czasami poprostu zwieche i frez komputera.

Zauwazyłem , ze wystepuje to ttylko raz, tzn wlączam komputer, pogram z 15min i jes black screen.

Zreseuje, wlącze od nowa i juz moge grac cały czas bez problemu.

U mnie na sterach 20.4.2 wszystkie gry działają stabilnie, tylko oczywiście tradycyjnie co któreś uruchomienie komputera czasami obraz nie zatrybi, ale to już przywykłem.

Zastanawiam się tylko, czy w ogóle naprawią to na Navi xD .

[Dario+ 380]

"co któreś uruchomienie komputera czasami obraz nie zatrybi"

 

tz ? podczas uruchomienia windowsa masz BS czy jak ?

[Kemotnik 0]

"co któreś uruchomienie komputera czasami obraz nie zatrybi"

 

tz ? podczas uruchomienia windowsa masz BS czy jak ?

Żaden BS - po prostu brak obrazu, bez komunikatu monitora HDMI off.

[Dario+ 380]

Żaden BS - po prostu brak obrazu, bez komunikatu monitora HDMI off.

Może musiał byś sprawdzić inny kable hdmi , inne złącze w monitorze lub na karcie. Spróbować DP jeśli monitor posiada.

[rudzik12345 8]

Grałęm teraz ze dwie godzinki po usunieciu recznym i zainstalowaniu sterów i nie miałem BS.

Zobaczymy jak dlugo

[Kemotnik 0]

Może musiał byś sprawdzić inny kable hdmi , inne złącze w monitorze lub na karcie. Spróbować DP jeśli monitor posiada.

Na innym kablu było to samo, innego złącza raczej nie sprawdzę, bo monitor był zakupiony w lutym 2011, więc tylko HDMI wchodzi w grę.

[smilehunter 507]

A musisz za te sterowniki zapłacić żeby sprawdzić? ?

 

W miejsce Linuxa wstaw Driver AMD

[Jenot 262]

 

 

W miejsce Linuxa wstaw Driver AMD

 

PEBKAC.

Edytowane 6 Czerwca 2020 przez Jenot

[GregM00 450]

Takie pytanie - jest sens instalowania tych sterowników z Maja, czy sobie odpuścić? Bo tam widziałem, że ktoś miał problemy z Mafią III, pytanie, jak z innymi grami.

 

Jeśli pytasz o jakiś możliwy przypadek przy pracy, czyli że w sterowniku pojawi się jakiś generalny bug, to pewnie wszystko jest możliwe, ale tak jak używam Radeonów, to nie kojarzę sytuacji, żebym musiał się cofać do tyłu ze względu na coś.

Z Mafią III i fixowaniem fps'ów na 30 klatkach to chyba problem z brodą (oryginalnie port na PC miał podobno takie ograniczenie na 30fps'ów, może coś tam zostało - coś kojarzę że czytałem o przełączaniu z gry do desktopu).

 

Zainstalowanie nowego sterownika nawet nie wymaga resetu Windows'a (zajmuje ze 30s), dlatego słusznie @DariŽ napisał, że najszybciej po prostu samemu sprawdzić. To nie jest taka oszczędność czasu żeby było warto to rozkminiać.

[GregM00 450]

W kolejnej części AC: Odyssey jest wykorzystany ten sam silnik ale już bez bibliotek Gameworks bo usunięcie ich wymagało partnerstwo z AMD. W tej części położono nacisk na optymalizacje pod kątem sprzętu AMD ale z racji braku MT w DX11 w lokacjach gdzie procesor zaczyna odgrywać istotną rolę wydajność AMD jest słaba i to nie wina developera, silnika graficznego, kosmitów tylko wina sterowników AMD.

W Atenach RTX2060 potrafił generować taką samą ilość kl/s co RX 5700XT ale już po wyjściu z miasta RX 5700XT potrafi odjechać grubo ponad 30% w 1440p.

 

Gdzieś mi uciekł ten post

 

Gdyby przyczyną był "brak MT w DX11", to byłby widoczny taki efekt, jak w testach MT Intela - zatkanie na pierwszym wątku CPU:

 

Ponadto, Microsoft w specyfikacji D3D 11 podaje https://docs.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-render-multi-thread-support

The runtime supports multithreading and command lists regardless of driver and hardware support; if there is no driver and hardware support for either multithreads or command lists, the runtime will emulate the functionality. For more information about multithreading, see Introduction to Multithreading in Direct3D 11.

Więc jeśli problemem byłby "brak MT w DX11", to powinno się to przełożyć na wysokie obciążenie procesora i kiepskie fps'y.

 

Co do tego "braku MT jeszcze", MS w tym samym linku odnośnie detekcji wsparcia MT w hardware, specyfikacja:

To check for driver support for multithreading:

 

[...]

If DriverConcurrentCreates is TRUE, a driver can create more than one resource at the same time (concurrently) on different threads.

 

If DriverCommandLists is TRUE, the driver supports command lists. That is, rendering commands issued by an immediate context can be concurrent with object creation on separate threads with low risk of a frame rate stutter.

 

If DriverConcurrentCreates is FALSE, a driver does not support concurrent creation, which means the amount of concurrency possible is extremely limited. The graphics hardware cannot create objects of different types on different threads simultanueously. Additionally, the graphics hardware cannot use an immediate context to issue render commands while the graphics hardware attempts to create a resource on another thread.

 

Za Intelem:

MT jest, nie ma DCLi.

 

Za NV (D3D11 Deferred Contexts, Bryan Dudash, Developer Technology, NVIDIA):

DCLe nie są wymagane w hardware, żeby silnik mógł używać DC.

 

Cała ta emulacja powinna dawać widoczny efekt w postaci narzutu na CPU. Jeśli tego w obciążeniu CPU nie widać, fps'y kiepskie, a karta się nudzi, to jak dla mnie problem w czym innym.

Edytowane 7 Czerwca 2020 przez GregM00

[DjXbeat 2312]

DCL - Driver Command List jest ściśle związany z działanie MT w DX11. Jego brak jest praktycznie, równoznaczny z brakiem MT w DX11 i tak to się właśnie objawia, wystarczy porównać działanie konkretnego API w kontekście drawcalls.

Porównaj sobie ilość generowanych drawcalls w DX11 3dmark API Overhead na sterowniku nV i sterowniku AMD. Ta różnica, która jest bardzo duża ściśle związana jest z DCL i działaniem MT i ta różnica przekłada się liniowo na wydajność w grach.

Jedynym winowajcą za niską wydajność w DX11 jest sterownik AMD.

 

Cała ta emulacja powinna dawać widoczny efekt w postaci narzutu na CPU. Jeśli tego w obciążeniu CPU nie widać, fps'y kiepskie, a karta się nudzi, to jak dla mnie problem w czym innym.

A skąd wiesz, że nie widać?

To, że monitoring w grach wskazuje obciążenie procesora np w 60% nie oznacza, że jest obciążony w 60% bo w danym momencie aplikacja może korzystać tylko z połowy wątków, rdzeni i wykorzystywać je w 100% efektywnie. Właśnie tego zdecydowana większość osób nie rozumie, że w grach procesor potrafi być już w 100% efektywnie wykorzystany pomimo tego, że monitoring wskazuje niskie zutylizowanie wątków.

 

Prosty przykład:

W grze X procesor jest obciążony w 75% a karta nV generuje 65kl/s w lokacji procesorowej

W grze X procesor jest obciążony w 75% a karta AMD generuje 50kl/s w lokacji procesorowej.

 

Te 75% to jest tylko wskazanie monitoringu bo procesor jest przez aplikacja w 100% efektywnie wykorzystywany. W obydwu przypadkach procesor w związku z aplikacją ma takie same operacje do wykonania ale jest pewna różnica - na karcie graficznej AMD dodatkowo może pojawiać się emulacja DC, która jest dodatkowym obciążeniem dla procesora. Czy będzie to widać po większym obciążeniu procesora? Nie bo ten w obydwu przypadkach jest już w 100% efektywnie wykorzystywany więc emulacja DC wpłynie tylko na spadek wydajności a pozostałe wskazania zostaną bez zmian.

 

Kolejny przykład dla zrozumienia jak działa dodatkowe obciążenie.

W aplikacji CinebencR20 procesor jest w 100% wykorzystany generując 3800pkt.

Jeśli podczas testu w Cinebench R20 procesor będzie miał dodatkowe obciążenie np konwertowanie plików to w dalszym ciągu procesor będzie wykorzystywany w 100% ale wynik Cinebencha R20 znacznie spadnie np do 3000pkt.

 

Podstawowym błędem jaki większość osób popełnia analizując wydajność w grach to sugerowanie się monitoringiem zużycia procesora

Edytowane 7 Czerwca 2020 przez DjXbeat

[GregM00 450]

Zignorowałeś z 90% tego, co przytoczyłem w swoim poście, a tam nie ma dywagacji, ale suche informacje od Intela, MS i NV.

Niewidoczny bootleneck? Są dostępne informacje o obciążalności wątków CPU w tej grze, które pokazują że nic takiego nie ma miejsca:

[smilehunter 507]

OSD nie pokaże zapchanego kontroler pamięci, kaszy L3. Na monitorigu pokazana tylko jedna ze składowych cepa.

[sideband 8789]

Sprawdź 60fps vs 30fps różnice w obciążeniu CPU będą praktycznie niewidoczne zwłaszcza na mocnym i wielowątkowym CPU. Dlatego testowałem narzut w inny sposób 

 

Jak na nieszczęście w każdej grze w której działa MT nie ma problemu z narzutem DX11 czy DX12 developer musi uaktywnić MT i jest to proste. W nowym tombie nie wiem czy celowo czy nie brak MT pod DX11 dlatego gra działa mizernie na AMD i NV oraz wykorzystuje tak samo mało "mocy" CPU. Także musi być wsparcie ze strony gry i sterowników by MT działało.

Edytowane 7 Czerwca 2020 przez sideband

[DjXbeat 2312]

OSD nie pokaże zapchanego kontroler pamięci, kaszy L3. Na monitorigu pokazana tylko jedna ze składowych cepa.

Jemu nie wytłumaczysz, że monitoring utylizacji CPU nie odzwierciedla realnego obciążenia procesora. Można mu tłumaczyć jak krowie na rowie ale szkoda na to czasu

 

Zignorowałeś z 90% tego, co przytoczyłem w swoim poście, a tam nie ma dywagacji, ale suche informacje od Intela, MS i NV.

Niewidoczny bootleneck? Są dostępne informacje o obciążalności wątków CPU w tej grze, które pokazują że nic takiego nie ma miejsca:

Nic nie zignorowałem bo wszystko jest zawarte w mojej wypowiedzi. To Ty wbij sobie do tego pustego łba, że monitoring utylizacji CPU nie odzwierciedla realnego wykorzystania procesora przez aplikacje - gry.

Jak to zrozumiesz to dalej będziesz miał już z górki zrozumieć resztę bo to co napisałeś opiera się właśnie o efektywne wykorzystanie procesora. Skupiasz uwagę na monitoringu cpu, który nie oddaje realnego i efektywnego wykorzystania procesora przez daną gre.

 

Prosty przykład o którym wspomniał Sideband - blokada na 60fps i 30fps. W obydwu przypadkach monitoring wskaże Ci podobne obciążenie procesora a realnie przy 60fps procesor jest znacznie mocniej obciążony niż przy 30fps.

Edytowane 7 Czerwca 2020 przez DjXbeat

[GregM00 450]

Prawie spadłem ze śmiechu z krzesła

 

Animowanie świata gry w 3D - to jest stały element, niezależny od fps'ów (bo te mają związek z renderingiem już przy generacji obrazu 2D), który w głównej mierze robi silnik i przekłada się to na stałe obciążenie CPU.

 

Jak ktoś nie rozumie, jak działa MT w DX11, to tutaj można uzupełnić wiedzę: https://docs.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-render-multi-thread-render

 

@DjXbeat, to już 2gi raz jak bluzgasz w moją stronę, jak masz za dużo emocji trudnych do opanowania, to walnij łbem o ścianę.

[DjXbeat 2312]

Animowanie świata gry w 3D - to jest stały element, niezależny od fps'ów (bo te mają związek z renderingiem już przy generacji obrazu 2D), który w głównej mierze robi silnik i przekłada się to na stałe obciążenie CPU.

Obciążenie procesora w zależności od ilości generowanych klatek jest zmienne a nie stałe więc kolejny raz napisałeś totalne bzdury. Im wyższa ilość klatek na sekundę tym procesor ma więcej operacji do liczenia!

 

Prawie spadłem ze śmiechu z krzesła

Widocznie za pisanie głupot ktoś się upomina o ciebie.

 

@DjXbeat, to już 2gi raz jak bluzgasz w moją stronę

Może w taki sposób dotrze jeśli w normalny sposób jesteś oporny.

Edytowane 7 Czerwca 2020 przez DjXbeat

[sideband 8789]

Ilość klatek bezpośrednio przekłada się na draw calls Także wychodzi twoja niewiedza

 

Narzut tylko ogranicza liczbę draw calls i jeżeli dochodzimy do sytuacji kiedy limiterem wydajności jest tylko draw calls to Ci żaden program nie wykaże wzrostu obciążenia CPU. Skoro draw calls jest wąskim gardłem to spada ilość klatek skoro mniej klatek to ...... Bez MT wzrost taktowania CPU kiepsko przekłada się na wzrost wydajności ze względu na wykorzystanie tylko głównie jednego wątka dla draw calls.

 

Przy pomocy aplikacji do sprawdzania obciążenia CPU czy bezpośrednio w grze nie sprawdzisz narzutu na CPU.

Edytowane 7 Czerwca 2020 przez sideband

[tomcug 3969]

No i dodajmy, że to "zatkanie" wcale nie musi dotyczyć pierwszego wątka, jak sobie ekipa od różnych dziwnych teorii ubzdurała po slajdach od AMD. Ostatnio widziałem sytuację, gdzie "zatykał" się ostatni wątek i co? Widocznie menedżer zadań się pomylił i przerotował wszystkie procesory logiczne o jedną pozycję Zresztą, windowsowy scheduler sam w sobie potrafi przeróżne cuda robić.

Edytowane 7 Czerwca 2020 przez tomcug

[Dario+ 380]

No i dodajmy, że to "zatkanie" wcale nie musi dotyczyć pierwszego wątka, jak sobie ekipa od różnych dziwnych teorii ubzdurała po slajdach od AMD. Ostatnio widziałem sytuację, gdzie "zatykał" się ostatni wątek i co? Widocznie menedżer zadań się pomylił i przerotował wszystkie procesory logiczne o jedną pozycję Zresztą, windowsowy scheduler sam w sobie potrafi przeróżne cuda robić.

Od którejś ,niedawnej aktualizacji windowana w ogóle scheduler działa inaczej. O ile wcześniej mój cpu bostował do 4200Mhz na jednym rdzeniu jeśli tylko był jeden wykorzystywany to od jakiegoś czasu nigdy, max 4100. Windows tak zarządza zadaniami że nigdy nie jest wykorzystywany tylko jeden rdzeń. Przynajmniej tak zauważyłem u siebie.

[GregM00 450]

Nie wychodzi moja niewiedza, ale wasze zafiksowanie na jakiejś specyficznej teorii nie do potwierdzenia, która się nijak ma do oficjalnych informacji jak rzeczy powinny działać.

 

@DjXbit, użyłem sformułowania "w głównej mierze", a Ty to chyba przeczytałeś jako "wyłącznie" i się odniosłeś do swojej interpretacji

 

@sideband, nie wiemy jak wygląda narzut, właściwie nic nie wiemy, widzimy tylko efekt a z ogólnych opisów działania środowiska można tylko spekulować, co może odpowiadać za dany efekt.

 

@tomcug, dlatego zazwyczaj używa się sformułowania "główny wątek" (aczkolwiek jeśli nawet ktoś napisze "pierwszy", to wiadomo o co chodzi, bo programując na wątkach, główny jest zawsze pierwszym).

 

OK, moja wersja z czym jest problem, która uwzględnia to, co stoi w dokumentach opisujących sposób działania środowiska D3D 11.

Zacznę od tego, jak powinno działać, to co przytaczałem wcześniej, czyli sposób robienia MT w DX11 wg Microsoftu (oparty na Deferred Context i Command List):

https://docs.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-render-multi-thread-render

https://docs.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-render-multi-thread-command-list

 

Na głównym wątku w ramach Immediate Context lecą zlecenia bezpośrednie do GPU. Na innym wątku (wątkach) roboczych, mogą być uruchomione DC, w ramach których następuje przetwarzanie draw'ów, gromadzenie efektu w command listach, do późniejszego wykonania przez GPU.

Jeśli sterownik nie wspiera któregoś elementu - emulację załatwia środowisko D3D 11.

Tyle teoria.

Teraz kluczowa rzecz, żeby ogarnąć co się dzieje. NV zaimplementowała to powyższe w sterowniku, ale dodała coś jeszcze, co wychodzi poza specyfikację D3D 11. Mianowicie sterownik NV może przerzucać to przetwarzanie draw'ów z DC na inne wątki, a na końcu kolejkować z powrotem na odpowiednie Command Lists. W efekcie nawet silnik rozpisany zgodnie ze specyfikacją na 2 wątki (główny z IC, drugi z DC) będzie używał wszystkich dostępnych na danym CPU wątków (wg specyfikacji powinni to robić devsi w ramach silnika świadomie decydując które wątki robocze będą pracować z DC).

 

Problem polega na tym, że takiego mechanizmu nie ma w specyfikacji D3D 11, to jest coś extra dodane przez NV. Teoretycznie na plus (bo to w sumie świetna rzecz), ale efekt uboczny jest taki, że devsi od silnika przy D3D 11, którzy uwzględniają tylko NV, nie zauważą problemu z nierównomiernym rozłożeniem obciążenia, bo sterownik NV im to zakryje.

Patrząc na to od strony zgodności ze specyfikacją D3D 11 - problem leży po stronie silnika gry, który bez extra wspomagania ze strony sterownika NV gdzieś się zatyka. Dokładnie to widać przy AC:O (nieobciążone wątki, nieobciążone GPU) i nie potrzeba kombinować z jakimś zatykaniem cache'ów, pamięci i innymi podobnymi rzeczami.

[sideband 8789]

Wiadomo wszystko narzut sterownika nic innego nie może zredukować draw calls.

 

I nie tylko z DX11 ma problem AMD, ale i też z OpenGL i to od lat może sobie poczytać o tym nawet na forum khronos-a Tylko żebyś nie zemdlał jaka jest różnica na korzyść sterów NV w GL-u

[Dario+ 380]

https://www.techpowerup.com/268211/amd-declares-that-the-era-of-4gb-graphics-cards-is-over

Era kart 4GB się kończy twierdzy AMD

Ciekawe jak z 6GB

[Putout 17]

https://www.techpowerup.com/268211/amd-declares-that-the-era-of-4gb-graphics-cards-is-over

Era kart 4GB się kończy twierdzy AMD

Ciekawe jak z 6GB

 

dobre na dziś, kiepskie na jutro.