Skocz do zawartości

Rekomendowane odpowiedzi

Przeczytaj dokładnie co napisałem.

 

Na przykładzie Intela:

"On the AMD GPU, the graphics driver module does not appear in the working thread but is concentrated on the main thread (see Figure 6), which means that a single immediate context bears a large amount of driver load, thus increasing the time of the working threads waiting for the main thread."

 

Nie korzysta z tego jak powinien. Nawet gościu z AMD na reddicie to potwierdził.

 

Druga sprawa. Specjalnie zwróciłem uwagę, że Fermi ma rozbudowany sheduler sprzętowy, a mimo wszystko DCL wspiera. Co oznacza, że nie przeszkadza on w zgodności z dcl.

 

Możesz się zastanowić nawet, czy zredukowanie sprzętowego schedulera, nie było podeyktowane, tym,że w NV stwierdzili, że poprzez działanie kontekstów sami lepiej ogarną scheduling niż dedykowany rozbudowany sprzętowy scheduler.

 

Warto to rozpatrzyć w kategorii gier DX 11 vs 12. Gdzie karty NV często wypadają lepiej w DX11, niż 12. Gdzie w poprawnie zrobionej konwersji DX 12. Też dostają Boost do wydajności.

 

Kolejna sprawa to mantle, Dx12.

One się nie wzięły znikąd w 2013/2014. Co już zostało napisane. AMD kładzie szczególny nacisk na nie, bo właśnie leży w DX11.

 

https://techreport.com/review/26239/a-closer-look-at-directx-12/

Co nie zmienia faktu, że Dx12 potrafi być upierdliwy z punktu widzenia dewelopera.

 

Na takim przykładzie:

 

"Think about memory management, for example. The way DirectX 11 works is, if you want to allocate a texture, before you can use it, the driver basically pre-validates that that memory is resident on the GPU. So, there’s work going on in the driver and on the CPU to validate that that memory is resident. In a world where the developer controls memory allocation, they will already know whether they’ve allocated or de-allocated that memory. There’s no check that has to happen. Now, if the developer screws up and tries to render from a texture that isn’t resident, it’s gonna break, right? But because they have control of that, there’s no validation step that will need to take place in the driver, and so you save that CPU work. "

 

Nie wszyscy muszą być za. A na pewno devsi wiedzieli, że będzie sporo z tym problemów xD

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)

Przeczytaj dokładnie co napisałem.

 

Na przykładzie Intela:

"On the AMD GPU, the graphics driver module does not appear in the working thread but is concentrated on the main thread (see Figure 6), which means that a single immediate context bears a large amount of driver load, thus increasing the time of the working threads waiting for the main thread."

 

Nie korzysta z tego jak powinien. Nawet gościu z AMD na reddicie to potwierdził.

 

Druga sprawa. Specjalnie zwróciłem uwagę, że Fermi ma rozbudowany sheduler sprzętowy, a mimo wszystko DCL wspiera. Co oznacza, że nie przeszkadza on w zgodności z dcl.

 

Możesz się zastanowić nawet, czy zredukowanie sprzętowego schedulera, nie było podeyktowane, tym,że w NV stwierdzili, że poprzez działanie kontekstów sami lepiej ogarną scheduling niż dedykowany rozbudowany sprzętowy scheduler.

 

Dobra, mówimy trochę o tym samym, ale się jakby nie możemy zrozumieć. Wiem, że temat łatwy nie jest, sam musiałem te szczątkowe materiały czytać po kilka razy, żeby się jakoś ułożyło.

 

Scheduler - to ogólne określenie na mechanizm, na którym kolejkuje się jakieś zadania. I ten scheduler wg jakichś kryteriów je uruchamia.

Standardowo scheduler występuje w karcie w powiązaniu z shaderami, dzieje się tak i w NV i AMD. W AMD mamy hardware'owy, w NV ostatni taki był w Fermim.

Teraz istotne, o takim rodzaju schedulera (powiązanym z shaderami) nie mówimy, bo on nie ma nic wspólnego z kolejkowaniem wywołań do DX11.

 

W GCNach od 3 generacji jest drugi sprzętowy scheduler, który kolejkuje wywołania draw do D3D. Oznacza to tyle, że każde takie wywołanie, zanim trafi do obróbki w sterowniku (w efekcie czego zostanie m.in skompilowane do programu shaderów) , musi być zakolejkowane na tym sprzętowym schedulerze (w NV nie ma czegoś podobnego). Oznacza to tyle, że zamiast obrabiać te odwołania bezpośrednio w wątkach CPU, w których się pojawiły (jak w NV), sterownik AMD musi je pościągać na wątek główny, zakolejkować w swoim schedulerze i dopiero obrabiać w kolejności, w jakiej ten scheduler będzie je wypluwał. Dlatego tak jak Intel pisze, następuje koncentracja obciążenia na głównym wątku (bo ten prawdopodobnie zajęty jest odpytywaniem z zadań wątków roboczych), a zatrzymanie wątków roboczych (bo prawdopodobnie chodzi o zablokowanie dostępu do ich danych roboczych, które przegląda wątek główny).

 

Teraz co ciekawego jeszcze znalazłem, dokument z 2013r, czyli przed publikacją DX12 przez MS:

http://developer.amd.com/wordpress/media/2013/05/GCNPerformanceTweets.pdf

 

To są zalecenia dla programistów, jak programować GCNy, czyli zasady tworzenia silników gier. 2013r to jeszcze przed wprowadzeniem tego hardware'owego schedulera do GCNów. AMD wymyśliło sobie inny od NV sposób postępowania, jest tu kilka ciekawych rzecz:

Tip #45 - wygląda że sterownik potrafi rozpraszać na wątki CPU samą kompilację (zamianę D3D -> program shaderów)

Tip #31 (kluczowy) - mówi jak najbardziej optymalnie pod GCNy organizować odwołania do D3D (jeden dedykowany wątek, na którym silnik ma realizować wszystkie odwołania do D3D; wszystkie inne działania silnika mają się odbywać poza tym wątkiem; w sumie coś zbieżnego z DX12).

 

Wygląda to wszystko tak, że AMD sobie wymyśliło jakiś sposób robienia renderingu (i to nie chodziło o DX12) najlepszy z ich punktu widzenia. I zaimplementowało to po części w hardwarze, co w sumie mocno ogranicza możliwość użycia innego sposobu. I teraz możemy mówić o silnikach gier zgodnych z ich modelem (które nie będą się zatykać), albo niezgodnych (i wtedy będzie problem).

Edytowane przez GregM00

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Jak sobie przeczytasz dobrze wypowiedź gościa z AMD, z redditowego wątku. On się odnosił do tego co przytoczyłeś.

 

"The best way to do DX11 is from our GCN Performance tip #31: A dedicated thread solely responsible for making D3D calls is usually the best way to drive the API.Notes: The best way to drive a high number of draw calls in DirectX11 is to dedicate a thread to graphics API calls... "

 

Zalecenia dotyczące programowania pod sprzęt, robi się pod to, co sprzęt potrafi i wychodzi mu najlepiej. Jeżeli z czymś radzi sobie źle, się tego unika.

Polaris ze swoim przerobionym schedulerem nie zmienia tego, że dalej sobie nie radzi z kontekstami. A w konkretnych warunkach takie Hawaii sobie radzi tak samo dobrze.

 

Więc znowu. To, że sobie AMD coś wymyśliło. Nie znaczy, że jest to w jakiś sposób optymalne rozwiązanie. Albo inaczej. W tych konkretnych warunkach.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Więc znowu. To, że sobie AMD coś wymyśliło. Nie znaczy, że jest to w jakiś sposób optymalne rozwiązanie. Albo inaczej. W tych konkretnych warunkach.

 

Z tym się w pełni zgadzam. Kłopot w tym, że na bazie tego co przyjęli, zrobili coś w sprzęcie (scheduler do draw) i moim zdaniem to skutecznie uniemożliwia zrobienie z tym czegokolwiek (implementacja jakiegoś innego modelu). Dlatego mija 7 lat od tego 2013r i tu nadal jest tak samo jeśli chodzi o DX11. Nie zaimplementują niczego innego (DCL, rozpraszania procesowania draw'ów).

I to wg mnie nawet nie jest kwestia jakiejś złej woli, że nie chcą, po prostu zaprojektowany sprzęt tylko jedną ścieżkę umożliwia (myślę, że np. NV świadomie zrezygnowała z pewnych rozwiązań sprzętowych, bo software'owe dają dużo większą elastyczność, nawet kosztem jakiegoś narzutu).

Co do AMD, jak pokazują testy Intela, nawet wywołania draw'ów w ramach deferred context są bez sensu, bo ewentualny zysk jest zjadany koniecznością przerzucenia tych odwołań z powrotem na wątek główny (a jeśli dobrze rozumiem, ideą deferred context było generowanie opóźnionych odwołań przez wątki robocze, poza wątkiem głównym). Więc to jest pewnie zaimplementowane tylko po to, żeby silniki gier z tego korzystające mogły JAKOŚ działać na AMD.

 

Na ewentualny plus, to w DX12 ten hardware'owy scheduler wydaje się (patrzę na wykresy porównawcze Intela) generować trochę mniejszy narzut niż to wychodzi u NV (sprzęt vs soft). Ale w DX12 zatkanie nie jest problemem, więc to w sumie realnie nic nie znaczy.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Zaktualizowałem windowa do wersji 2004 i tak sobie testuje pomału system z sterownikami 20.5.1.

Na razie jedna dziwna sprawa , wynik w Geekbenchu mi się coś nie zgadza :hmm:

O ile w OpenCL mam ok 65264 pkt. to wynik vulcan wydaje mi się za niski, 49756 pkt ,na RX580 miałem 51941 :/

 

RX580:

https://browser.geekbench.com/v5/compute/69013

 

RX5700

https://browser.geekbench.com/v5/compute/1005856

 

Nie wiem czy to wina nowego systemu czy sterowników a może tak ma być ?

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

@GregM00

 

Żeby przerwać tę karuzelę śmiechu, mam dwie proste propozycje. Po pierwsze, wyszukaj sobie, czym tak naprawdę jest ten "software scheduling" w architekturach po Fermim, którym tak żonglujesz na lewo i prawo (bo nie jest tym, co próbujesz wciskać). Po drugie, zorientuj się, jakie jest naprawdę zadanie HWS obecnego od Polarisa, którym też żonglujesz bez ładu i składu (bo cytat "a new one to schedule execution of draw and compute queues" bynajmniej nie oznacza, że to do niego w pierwszej kolejności trafią draw calls inicjowane przez silnik gry). Bo póki co Twoja działalność w tym wątku to jedynie klepanie jak katarynka głupotek rozpowszechnianych w sieci pewnie już setki razy, od czasów tego pamiętnego filmiku, który tak samo u podstaw przyjętych założeń jest pomieszaniem z poplątaniem:

 

https://www.youtube.com/watch?v=nIoZB-cnjc0

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

@tomcug,

odnosisz się do czegoś, czego nie napisałem. Wyraźnie chcesz sobie pogadać sam ze sobą :)

Nie przeszkadzam w zabawie.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

@zgredzik86

już kojarzę, Ty jesteś ten Kolega, co od lutego czeka i ma nadzieję, że przez zmianę sterowników karta zacznie działać poprawnie.

Rozważałeś wariant, że to nie kwestia sterowników i możesz tak czekać w nieskończoność?

Wiem, że to nic nie musi znaczyć, ale tutaj nikt ze sterownikami nie ma takiego kłopotu, żeby waliły się "po całości". Owszem, są jakieś konkretne problemy w grach, z jakimś modelem monitora, z dwoma monitorami, itp.

Wiemy i przerabialiśmy problemy z niestabilnością pamięci, która jest chyba głównym źródłem zwiech.

Jest też jakaś niekonkretna informacja, że dla oszczędności część AIB robiła PCB do RX5600XT (czy tylko te modele?) w zaniżonych standardach (w stosunku do referentów), co przekładało się na przekłamania na ścieżkach w komunikacji rdzenia z pamięciami - co też prowadziło do stałych zwiech (w zależności od wysokości taktowania pamięci), albo mniej częstych jeśli taktowanie było na granicy błędu (wysypka po kilku godzinach).

 

Na moje Twoja karta już dawno powinna być w serwisie Gigabyte, bo być może z tym ostatnim masz do czynienia i jedyne co można zrobić, to ją wymienić na model z lepszej jakości PCB (sporo się zmieniło, kiedy AMD ogłosiło, że model 5600XT ma mieć wyżej taktowaną pamięć).

ver 1.0 nie bedzie działać z biosem FA0, kości pamieci są do dupy.micron wypuszcza 3 lub 4 rodzaje kosci o tym samym oznaczeniu,ale różnią sie taktowaniami.

 

ver 1.0 nie bedzie działać z biosem FA0, kości pamieci są do dupy.micron wypuszcza 3 lub 4 rodzaje kosci o tym samym oznaczeniu,ale różnią sie taktowaniami.

 

https://www.micron.com/products/graphics-memory/gddr6/part-catalog

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

a propos utrzymywania wyższego taktowania vramu na nie których monitorach na forum amd udzieliła odpowiedz.

 

"I checked with the product team and their feedback is that depending on specific display configurations (resolution and refresh rate combinations) and background tasks, RX 5000 Series GPUs may maintain memory frequency to ensure an optimal user experience. This behavior is expected and does not impact the RX 5000 GPU in any way."

 

 

 

https://community.amd.com/thread/241665

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)

a propos utrzymywania wyższego taktowania vramu na nie których monitorach na forum amd udzieliła odpowiedz.

 

"I checked with the product team and their feedback is that depending on specific display configurations (resolution and refresh rate combinations) and background tasks, RX 5000 Series GPUs may maintain memory frequency to ensure an optimal user experience. This behavior is expected and does not impact the RX 5000 GPU in any way."

 

 

 

https://community.amd.com/thread/241665

Najszybsze rozwiazanie problemu, uznac takie zachowanie za oczekiwane zeby zachowac niezapomniane wrazenia na pulpicie, "it's not a bug, it's a feature" :lol2:

Edytowane przez Phoenixsuple

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
This behavior is expected and does not impact the RX 5000 GPU in any way."

17W GPU power na pulpicie mam, gdy memki wskakują na 1750MHz (vs 4-5W, gdy siedzimy @ 200MHz) :lol2:

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Zdaje się, że problem 'high idle clocks' dotyczy wszystkich producentów GPU, i to od dawna. Widocznie tak ma być. Jedyne co ja bym teraz zrobił wiedząc, że tak się zachowują zegary, to kupiłbym inny drugi monitor.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Głupie podejście. Powinni wprowadzić certyfikację monitorów i sprawa zupełnie inaczej by wyglądała. A tak, to "wina AMD".

Mówię o pojedynczym monitorze, wsparcie dla dwóch to odrębna sprawa.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Chyba sobie jaja robisz szczerbaty.gif

 

To wszystko jest w gestii AMD i producenci monitorów nie mają nic do tego. Od lat AMD zawsze ma z czymś problem, ale fani marki jak zwykle twierdzą, że to nie wina AMD. I właśnie przez takie idiotycznie myślenie tak to będzie wyglądało nadal, przecież nie ma żadnego problemu ze strony AMD lol2.gif

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)

Nie, nie robię sobie jaj. Temat był wałkowany parę stron do tyłu. Sterownik pod Linuxem ma ten sam problem.

Przełączanie stanów P-state pamięci w trakcie wyświetlania obrazu da zakłócenia. Dlatego przełączać te stany można tylko w trakcie trwania V-Blank.

Jeśli V-Blank w danym monitorze dla konkretnej rozdzielczości i odświeżania trwa za krótko, to się ich nie przełącza.

 

Korzyść dla twórców monitorów ze skracania V-Blank jest matematycznie oczywista (mniejsze "niewidoczne obszary" -> niższe wartości pixel clock -> tańsza matryca). Dlatego to co ostatnio pisałem - warto rozważyć zakup "G-Sync compatible", bo przynajmniej NV weryfikuje parametry monitorów.

 

Coraz częściej na tym forum mam wrażenie, że nawet lekko trudniejsze tematy to ściana, zamiast tego w kółko jak mantrę powtarza się jakieś banały.

Edytowane przez GregM00

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Nowe sterowniki coś mi nie podeszły. Nagle Mafia 3 miała spadki z 60 do 30 fps (jakby jakiś tryb pół synchronizacji pionowej się włączył, bo gdzieś w jakiejś grze widziałem takie ustawienie, chyba w SoTR). Dźwięk zaczął krzaczyć, ogólnie coś nie halo. Co prawda ustawiłem UV na 1050 mV@2020 MHz, ale potem podniosłem napięcie i dalej to samo było. Wróciłem do poprzednich sterów i jak ręką odjął :)

PS. Mam Plazmę 3D (aktywne) Samsunga E6500 (chyba z 2012 roku), więc moim zdaniem matryca powinna być 100 lub 120 Hz. Dlaczego nie mogę ustawić takiego odświeżania w windows (max to 60 Hz)?

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)

PS. Mam Plazmę 3D (aktywne) Samsunga E6500 (chyba z 2012 roku), więc moim zdaniem matryca powinna być 100 lub 120 Hz. Dlaczego nie mogę ustawić takiego odświeżania w windows (max to 60 Hz)?

Ta matryca ma 60Hz.

 

btw. To wcina 300W w czasie pracy. Burżuazja po całości.

Edytowane przez smilehunter

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)

Ta matryca ma 60Hz.

 

btw. To wcina 300W w czasie pracy. Burżuazja po całości.

 

Aż tak źle nie jest. 300 W to w trybie 3D, w 2D "tylko" 180-200 W �� nie wiem czy są już lepsze tv do grania - 16 ms input lag w ukrytym nieco trybie PC, świetna rozdzielczość i płynność ruchomego obrazu, plastyczność obrazu, fajna czerń (jednak gorsza niż na początku), brak smużenia, powidoków, duchów itd. Jak wyjdą nowe konsole to być może kupię w końcu coś 4k.

 

Ps. Shadow of Tomb Raider w 3D to zupełnie inna gra i przeżycia. Rozumiem, że już tv 3D nie produkują? Trzeba na VR się przerzucić. 

Edytowane przez majki84

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Żadne okazje. Aorusa mam za 1440zl od nich, to jest okazja :). Devila tez miałem od nich za 1580zl kupionego :). Teraz nie ma tam okazji :).

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)

Głupie podejście. Powinni wprowadzić certyfikację monitorów i sprawa zupełnie inaczej by wyglądała. A tak, to "wina AMD".

Mówię o pojedynczym monitorze, wsparcie dla dwóch to odrębna sprawa.

 

Wiedza pieniądze kosztuje ;) wczoraj w lokalnym lombardzie wyrwałem AOC AGON AG352UCG6 35" 3440x1440 120Hz VA (tak, G-Sync only, ale naprawdę tanio i w idealnym stanie z pudłem). No i mam wreszcie solidne pole robocze na jednym monitorze i przyzwoitą częstotliwość odświeżania bez "high idle MCLK". W idle do 100Hz MCLK ładnie się trzyma na 100MHz (przy czym jak coś się dzieje na ekranie to sobie podskakuje do 500 bez artefaktów, czyli zmiany spokojnie mieszczą się w VBlank), dopiero przy 120Hz mam wjazd na full 875MHz. Brak freesynca przeżyję, jedyne z czym jeszcze muszę powalczyć to Vulkan pod linuksem (Doom na Vulkanie ustawiony na Adaptive Sync robi mi hard crash systemu - chyba nie zdaje sobie sprawy, że monitor ma tylko G-Sync): Obrazek

Edytowane przez Jenot

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

NV coś planowała w zeszłym roku, żeby odblokować ichnie moduły ładowane do monitorów dla innych kart i konsoli, tak, żeby monitory z G-Sync mogły działać jako adaptive-sync. Ale czy coś z tego konkretnie wyszło to nie wiem.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Wyszło - "G-Sync compatible", czyli nowe monitory będą zgodne z VESA Adaptive Sync, stare bez update'u firmware'u nihuhu.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)

Nie nie, chodzi o czyste monitory G-Sync, czyli te z układem scalonym od NV. Ten układ miał wspierać też adaptive-sync dla innych kart.

"G-Sync compatible" to jest Freesync + certyfikacja NV parametrów monitora, bez tego dedykowanego układu scalonego NV. Sam układ scalony NV podbija cenę monitora o jakieś $200, bo NV tego nie daje za free.

 

Czyli jest "G-Sync" z układem (LFC działający od 1Hz w górę, robiony po stronie monitora) i "G-Sync compatible" bez (z LFC robionym przez mnożenie częstotliwości po stronie karty graficznej). Te drugie są zgodne z Freesync. A te pierwsze "miały być".

 

https://images.nvidia.com/content/images/nvidia-g-sync-monitor-stack-comparison.png

Edytowane przez GregM00

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się

  • Ostatnio przeglądający   1 użytkownik

×
×
  • Dodaj nową pozycję...