AMD NAVI

[Mar_S 1427]

Przecież wszystko co ma zrobić AMD jest oparte o biblioteki Microsoftu a nie własne technologie, co oznacza że każdy RTX będzie mógł działać dokładnie tak samo jak karty AMD, a w drugą stronę już nie.

No i to oznacza także że każda karta zgodna z DX12 będzie mogła robić to co karty z tym całym RDNA2, oczywiście pod warunkiem że nie uwalą ich sterownikami.

[Jenot 262]

Wróć te kilka stron do tyłu, było o tym, że Navi wchodzi w te wyższe taktowania kiedy liczba linii VBlank wysyłana przez monitor w EDID jest za krótka. Żeby to rozwiązać pod Windows, bierze się CRU (edytor EDID) i generuje automatyczny EDID w oparciu o ogólny standard LCD. O kilka Hz spada max taktowanie, ale VBlank jest ok. I na takim nowym EDID (zastępującym ten wysłany przez monitor) karta (pamięć) zaczyna działać normalnie.

 

W Linuxie masz inne narzędzia, ale w sumie chodzi o to samo - zapisać EDID, sprawdzić VBlank, jeśli dziwnie krótki, to wyedytować (ustawić jakieś normalne standardy LCD), podać nowy plik jako parametr dla kernela.

 

OK, rozpoznania bojem ciąg dalszy

W przypadku konfiguracji dwumonitorowej problemem nie jest VBlank (to znaczy on też, ale nie bezpośrednio), tylko to, że zmiany MCLK powinny odbywać się w czasie trwania VBlank, a na dwóch monitorach (zwłaszcza różnych, o różnych modelineach), nie bardzo idzie uzyskać jednoczesność VBlank. Jeśli zmiana MCLK nastąpi gdy jest wyświetlana klatka to będzie paskudne miganie na jednym z monitorów. Z informacji zasięgniętych z LKML, phoronix i reddicie - częstotliwość MCLK będzie schodziła na minimum w przypadku dwóch identycznych monitorów przy konfiguracji gdy częstotliwość odchylania pionowego jest w obydwu taka sama (np. 60Hz/60Hz), lub częstotliwość jednego jest wielkokrotnością drugiego (np. 60Hz/120Hz), wtedy zmiana MCLK będzie robiona przy VBlank "wolniejszego" monitora i nie będzie artefaktów, w każdym innym przypadku MCLK jest ustawione na max, i koniec. Pewnie pod Windows jest tak samo. Na grupach "kernelowych" ciągle trwa dyskusja jak to elegancko obejść, ale łatwo nie będzie.

[GregM00 450]

OK, rozpoznania bojem ciąg dalszy

W przypadku konfiguracji dwumonitorowej problemem nie jest VBlank (to znaczy on też, ale nie bezpośrednio), tylko to, że zmiany MCLK powinny odbywać się w czasie trwania VBlank, a na dwóch monitorach (zwłaszcza różnych, o różnych modelineach), nie bardzo idzie uzyskać jednoczesność VBlank. Jeśli zmiana MCLK nastąpi gdy jest wyświetlana klatka to będzie paskudne miganie na jednym z monitorów. Z informacji zasięgniętych z LKML, phoronix i reddicie - częstotliwość MCLK będzie schodziła na minimum w przypadku dwóch identycznych monitorów przy konfiguracji gdy częstotliwość odchylania pionowego jest w obydwu taka sama (np. 60Hz/60Hz), lub częstotliwość jednego jest wielkokrotnością drugiego (np. 60Hz/120Hz), wtedy zmiana MCLK będzie robiona przy VBlank "wolniejszego" monitora i nie będzie artefaktów, w każdym innym przypadku MCLK jest ustawione na max, i koniec. Pewnie pod Windows jest tak samo. Na grupach "kernelowych" ciągle trwa dyskusja jak to elegancko obejść, ale łatwo nie będzie.

 

OK, zaczyna mi się to układać w całość. Teraz pytanie uzupełniające, po co karta ma podwyższać taktowanie pamięci, jeśli nie pracuje w 3D? Czy to jest powiązane z odczytem klatki z pamięci (żeby ją wysłać do monitora)? W sensie, zaczyna się VBlank, karta zwiększa taktowanie pamięci (w zamyśle, na bardzo krótki przedział czasu), czyta z niej dane klatki, na koniec obniża taktowanie. Jeśli VBlank jest za krótkie (kończy się zbyt szybko, przed zakończeniem tej operacji na pamięci), to taktowanie pozostaje wysokie (z przyczyn, które opisałeś). W przypadku dwóch monitorów - no tu by się ta moja teoria o odczycie nie zgadzała, bo przy dwukrotności szybszy monitor musiałby dostawać dane nowej klatki w połowie wyświetlania poprzedniego

Edytowane 26 Maja 2020 przez GregM00

[GregM00 450]

Przecież wszystko co ma zrobić AMD jest oparte o biblioteki Microsoftu a nie własne technologie, co oznacza że każdy RTX będzie mógł działać dokładnie tak samo jak karty AMD, a w drugą stronę już nie.

No i to oznacza także że każda karta zgodna z DX12 będzie mogła robić to co karty z tym całym RDNA2, oczywiście pod warunkiem że nie uwalą ich sterownikami.

 

Tak, tylko biblioteki Microsoftu nie mają bezpośredniego przełożenia na sprzęt, a całą robotę na niskim poziomie muszą odwalić jednostki liczące na karcie. Plus sterownik, który jest pomiędzy. I to jest raczej główne miejsce decyzyjne co i jak robić. Przykładowo Tensor Cores w NV mogą prowadzić obliczenia z dowolną precyzją, zależnie od potrzeby przetworzenia liczby danych. Czyli gdzieś na poziomie bibliotek MS to będzie VSR, który na samym dole przełoży się na to, że rdzenie przełączą się z liczb zmiennoprzecinkowych na całkowite (za sprawą decyzji sterownika), zwiększając tym samym kilkukrotnie szybkość przetwarzania kosztem jakości.

Efekt implementacji DXów będzie zależny od tych możliwości hardware'u i efektywności sterownika (który ten hardware bezpośrednio kontroluje). Do tej pory karty AMD były optymalizowane w kierunku obliczeń zmiennoprzecinkowych (na tym stoi "konwencjonalna" grafika bez RT). Pytanie, czy ta szybkość będzie wystarczająca, a jeśli nie, czy będą w stanie zejść z precyzją w dół w celu zwiększenia szybkości obliczeń. Coś kojarzę, że CU w Navi nie mają takiej rozpiętości możliwej precyzji liczb, jak aktualnie u NV.

Kolejna rzecz, to sposób implementacji wsparcia do obliczeń RT w hardwarze. Na razie w sumie nic nie wiadomo, jak to będzie wyglądać u AMD. Ogólne założenia są znane (ma być akceleracja drzewa BVH), ale szczegółów zero. Taka akceleracja to w skrócie przeszukiwanie ton danych w pamięci, jeśli coś na karcie zacznie to robić, to jak równocześnie na tej pamięci będą pracować CU robiące konwencjonalne wyliczenia? Do tej pory każde CU było w Navi niezależne, miało swój kawałek pamięci plus kilka poziomów cacheowania. Ale teraz jakoś te jednostki (dedykowane?) do akceleracji muszą być tutaj dodane (tak to przynajmniej jest u NV, może AMD zorganizuje to zupełnie inaczej i efektywność będzie lepsza?).

 

Dla porównania, Vega miała sporo większą (bodajże 2-krotnie) matematyczną moc przetwarzania od Navi (szybszą pamięć itd). AMD poukładało inaczej zależności logiki tworząc Navi, uniezależniło CU od siebie (w Vedze musiały pracować 4-kami, nawet przy obciążeniu tylko pojedynczego CU - 3 pozostałe nic nie robiły), wprowadziło ich grupowanie w większe struktury (w zależności od potrzeb przetwarzania). W efekcie tych i podobnych wielu zmian, wolniejsze Navi wystrzeliło w efektywności (jak podaje AMD, możliwe jest uzyskanie wysycenia na poziomie >90%), przeganiając Vegę która grzała się jak cholera nie potrafiąc uzyskać nawet połowy podobnej efektywności.

Na warstwie bibliotek DX11/DX12 dla obu było to samo.

Edytowane 26 Maja 2020 przez GregM00

[Jenot 262]

OK, zaczyna mi się to układać w całość. Teraz pytanie uzupełniające, po co karta ma podwyższać taktowanie pamięci, jeśli nie pracuje w 3D? Czy to jest powiązane z odczytem klatki z pamięci (żeby ją wysłać do monitora)? W sensie, zaczyna się VBlank, karta zwiększa taktowanie pamięci (w zamyśle, na bardzo krótki przedział czasu), czyta z niej dane klatki, na koniec obniża taktowanie. Jeśli VBlank jest za krótkie (kończy się zbyt szybko, przed zakończeniem tej operacji na pamięci), to taktowanie pozostaje wysokie (z przyczyn, które opisałeś). W przypadku dwóch monitorów - no tu by się ta moja teoria o odczycie nie zgadzała, bo przy dwukrotności szybszy monitor musiałby dostawać dane nowej klatki w połowie wyświetlania poprzedniego

 

Syndrom PCLaba - komputery służą tylko do gier, jak gra to fullscreen i 3D, jak pulpit to 2D i zegarami zjeżdżamy do minimum.

Pod Linuksem gry nie są priorytetem. Mnóstwo programów korzysta z jednostek obliczeniowych GPU: compositor (rysowanie okien, dekoracje, animacje elementów interfejsu, przezroczystości), renderowanie fontów, obliczenia na GPU, rendering, aplikacje korzystające z OpenGL w oknach. Nawet jeśli nie obciąża to mocno GPU, to pod uwagę trzeba wziąć "worst case scenario", czyli np. siedzę na pulpicie, zapuszczam program liczący na GPU, o niezbyt liniowej charakterystyce obciążenia, czy odpalam slicer do drukarki 3D i obracam bardziej skomplikowaną bryłkę, i mam dyskotekę na jednym z monitorów bo co parę sekund MCLK się zmienia.

Karta generalnie zmienia MCLK zgodnie z tabelą PStates, zależnie od obciążenia, przy konfiguracji dwumonitorowej MCLK jest zablokowane na najwyższym PState - tak to zrobili pod Linuksem.

 

Opis gościa, który napisał łatę do jajka:

This patch set enables mclk switching with multiple monitors when all

monitors are sync. Normally mclk switching is not available with

multiple monitors because the vblank timing does not line up. However,

if the timing is identical, the display driver can sync up the displays

in some cases. Check for these cases and allow mclk switch when

possible.

 

W wolnym tłumaczeniu - jeśli masz takie same monitory, z takimi samymi modeline'ami to możesz sobie odblokować MCLK, w przeciwnym razie taki ch...

Edytowane 26 Maja 2020 przez Jenot

[GregM00 450]

@Jenot,

z tym wszystkim jasne, tak właśnie się dzieje. Zrobiłem sobie taki komponencik na Rainmeterze, który mi wykorzystanie karty (i pamięci) w pulpicie pokazuje:

 

i widzę wzrost taktowania rdzenia, ale nie taktowania pamięci. Owszem, zdarza się, że na sekundę coś wskoczy wyżej, ale poza tym trzyma się tych 200MHz.

 

U ludzi z pojedynczym monitorem i zbyt krótkim VBlank - cały czas pamięci na max.

Przyjmuję to wyjaśnienie (logiczne), że karta może zmieniać taktowanie pamięci tylko przy VBlanku, bo potem pewnie wysyła dane obrazu z tej pamięci i nie ma możliwości przełączenia ich taktowania bez zakłócania tej czynności.

Tylko skąd ten wymóg na jakieś minimum VBlanka? Nie wiem, sam proces zmiany taktowania pamięci trwa na tyle długo, że VBlank może być na to zbyt krótki?

 

Jak patrzę u siebie w CRU (EDID) to przy 144Hz mam horizontal rate ~166kHz, to daje jakieś 6 microsekund na linię. Mało

U mnie dla tego odświeżania VBlank trwa 77 linii. To daje jakieś niecałe 0.5ms na całą przerwę VBlank (u mnie pamięci normalnie zmieniają taktowanie).

Być może to o to chodzi, jeśli tych linii VBlank jest za mało, to karta nie przełącza pamięci w dół, bo nie zdąży.

 

Pytanie, jak sobie z tym radzi NV? Nie przełącza pamięci i trzyma sztywno na jakimś średnim taktowaniu?

Edytowane 26 Maja 2020 przez GregM00

[Jenot 262]

A, bo Ty chcesz przeanalizować, dlaczego MCLK jest na full przy jednym monitorze...

Masz tyle samo linii VBlank co ja przy 144Hz. VBlank w porównaniu z całą ramką trwa raczej krótko, trzeba by sprawdzić ile trwa odczyt całej ramki z pamięci karty, ile czasu zajmuje przełączenie PState MCLK, i ile linii VBlank zostaje po przełączeniu. Może przy zbyt krótkiej przerwie VBlank zostaje za mało czasu na wczytanie następnej ramki z pamięci?

 

Z tego co czytałem to NVidia przy dwóch monitorach robi to samo. Przy jednym nie wiem.

Edytowane 26 Maja 2020 przez Jenot

[GregM00 450]

Nie jestem pewien, czy jest jakieś wczytanie. Myślę, że z tej pamięci są po prostu na bieżąco wysyłane dane do monitora tak, jak leci ramka, dlatego nie można w trakcie zmienić PState dla pamięci. Kończy się ramka, zaczyna VBlank i to jest jedyny moment, kiedy pamięć można przełączyć na inne taktowanie. Koniec VBlanka i leci z pamięci kolejna ramka do monitora.

 

Jeśli VBlank trwa za krótko w stosunku do czynności przełączenia taktowania pamięci (np. 10 linii, to daje 60 mikrosekund przy 144Hz), to nie dałoby rady wysłać kolejnej ramki i całe taktowanie monitora przez kartę by się zesrało (monitor nie będzie czekać). Na to stawiam, że tu jest pies pogrzebany.

Edytowane 26 Maja 2020 przez GregM00

[Saren7 1188]

Jestem ciekaw czy kiedyś RDR2 dostanie RT.

Nie wyobrażam sobie tego

Na ultra sprzęt ma ciężko a co dopiero z RT.

Przykład gry, która nie potrzebuje śledzenia

promieni żeby wyglądać dobrze.

[tomcug 3969]

Kolejna rzecz, to sposób implementacji wsparcia do obliczeń RT w hardwarze. Na razie w sumie nic nie wiadomo, jak to będzie wyglądać u AMD. Ogólne założenia są znane (ma być akceleracja drzewa BVH), ale szczegółów zero.

A u NV jakie informacje masz podane ? Wiesz tyle, że są mityczne "RT Cores" i szczegółów zero, żeby konkurentowi nie ułatwiać zadania.

[Lesiu1989 2]

Witam

 

Panowie taka sprawa mam od dziś u Siebie na stanie dwa monitory aorus fi27q podpięte chwilowo kablami hdmi-dp delocka.

Teoretycznie system pokazuje mi 2k 60hz a karta pamięci rozkręca na 100% przy trybie 0rpm karta po godzinie czy dwóch lapie 60 stopni na pulpicie. Jest jakaś opcja przeskoczenia tej niedogodności? Będę wdzięczny za porady.

Karta ta co w sygnaturce Msi 5700xt gaming x

[GregM00 450]

A u NV jakie informacje masz podane ? Wiesz tyle, że są mityczne "RT Cores" i szczegółów zero, żeby konkurentowi nie ułatwiać zadania.

 

Fakt.

[sideband 8791]

A u NV jakie informacje masz podane ? Wiesz tyle, że są mityczne "RT Cores" i szczegółów zero, żeby konkurentowi nie ułatwiać zadania.

Masz wszystko pięknie wyłożone na talerzu w patencie AMD. Rozwiązanie od Nv też na pewno jest opatentowane tylko trzeba mieć wgląd w patent

[Jenot 262]

Witam

 

Panowie taka sprawa mam od dziś u Siebie na stanie dwa monitory aorus fi27q podpięte chwilowo kablami hdmi-dp delocka.

Teoretycznie system pokazuje mi 2k 60hz a karta pamięci rozkręca na 100% przy trybie 0rpm karta po godzinie czy dwóch lapie 60 stopni na pulpicie. Jest jakaś opcja przeskoczenia tej niedogodności? Będę wdzięczny za porady.

Karta ta co w sygnaturce Msi 5700xt gaming x

 

@GregM00 czyli pod Windows jest to samo. Nawet z dwoma identycznymi monitorami.

@Lesiu1989 No co zrobisz? Nic nie zrobisz. Do czasu aż AMD nie doda do windowsowego sterownika funkcjonalności pozwalającej na obniżenie MCLK przy dwóch takich samych monitorach. W linuksie z odpowiednimi łatkami już się da. Piszemy o tym przez ostatnią stronę.

[GregM00 450]

Witam

 

Panowie taka sprawa mam od dziś u Siebie na stanie dwa monitory aorus fi27q podpięte chwilowo kablami hdmi-dp delocka.

Teoretycznie system pokazuje mi 2k 60hz a karta pamięci rozkręca na 100% przy trybie 0rpm karta po godzinie czy dwóch lapie 60 stopni na pulpicie. Jest jakaś opcja przeskoczenia tej niedogodności? Będę wdzięczny za porady.

Karta ta co w sygnaturce Msi 5700xt gaming x

 

Dokładnie 11 postów wcześniej masz wyjaśnienie problemu. Co do rozwiązania, cholera wie.

[Dario+ 380]

Witam

 

Panowie taka sprawa mam od dziś u Siebie na stanie dwa monitory aorus fi27q podpięte chwilowo kablami hdmi-dp delocka.

Teoretycznie system pokazuje mi 2k 60hz a karta pamięci rozkręca na 100% przy trybie 0rpm karta po godzinie czy dwóch lapie 60 stopni na pulpicie. Jest jakaś opcja przeskoczenia tej niedogodności? Będę wdzięczny za porady.

Karta ta co w sygnaturce Msi 5700xt gaming x

Ale to normalne dla tej karty że przy w trybie 0RPM będzie łapać 60c. Tak ma w trybie pół pasywnym, dochodzi do 60c i dopiero włącza wentylator. Jeśli chcesz mieć niższą temperature na pulpicie to musisz wyłączyć 0RPM

[GregM00 450]

@GregM00 czyli pod Windows jest to samo. Nawet z dwoma identycznymi monitorami.

 

Mam przez chwilę drugi monitor, podłączę go później i zobaczę co i jak u mnie wyjdzie.

 

Ale to normalne dla tej karty że przy w trybie 0RPM będzie łapać 60c. Tak ma w trybie pół pasywnym, dochodzi do 60c i dopiero włącza wentylator. Jeśli chcesz mieć niższą temperature na pulpicie to musisz wyłączyć 0RPM

 

Albo obniżyć ten próg z 60c w dół. Ja ustawiłem u siebie 45c na włączenie, a 35c na wyłączenie wiatraków. Co jakiś czas to się na chwilę załącza.

[Lesiu1989 2]

Ale to normalne dla tej karty że przy w trybie 0RPM będzie łapać 60c. Tak ma w trybie pół pasywnym, dochodzi do 60c i dopiero włącza wentylator. Jeśli chcesz mieć niższą temperature na pulpicie to musisz wyłączyć 0RPM

 

 

Wcześniej przy monitorach 2x fullhd mialem jakieś 40 stopni i taktowanie pamięci nie szlo na 1850mhz tylko 200mhz.

[Dario+ 380]

Wcześniej przy monitorach 2x fullhd mialem jakieś 40 stopni i taktowanie pamięci nie szlo na 1850mhz tylko 200mhz.

Ale mówisz o temperaturze vramu czy gpu ?

[Lesiu1989 2]

Ale mówisz o temperaturze vramu czy gpu ?

 

Temperatura gpu. Nie umiem sobie uświadomić jakie wcześniej taktowanie miał rdzeń na pulpicie w tym momecie rdzeń mi kręci się wokół 800mhz. Bardziej mnie te pamięci martwią ,że lecą na 100% no i wzrost poboru prądu z 3w do 34w na pulpicie.

[Gość]

No to jest normalne dla NAVI

[GregM00 450]

Wcześniej przy monitorach 2x fullhd mialem jakieś 40 stopni i taktowanie pamięci nie szlo na 1850mhz tylko 200mhz.

 

Wcześniej? A co się zmieniło od tamtego momentu? Monitory?

[Jenot 262]

Temperatura gpu. Nie umiem sobie uświadomić jakie wcześniej taktowanie miał rdzeń na pulpicie w tym momecie rdzeń mi kręci się wokół 800mhz. Bardziej mnie te pamięci martwią ,że lecą na 100% no i wzrost poboru prądu z 3w do 34w na pulpicie.

 

No to jest dokładnie to o czym piszemy. Ja bym na Twoim miejscu spróbował po DP. Nie wiem jakim programem pod Windows sprawdzić timingi monitorów. Powinny być identyczne, wtedy jest szansa, że MCLK spadnie. Ja się specjalnie tym nie przejmuję, po prostu to ciekawe.

[Lesiu1989 2]

Wcześniej? A co się zmieniło od tamtego momentu? Monitory?

 

Tak zmieniłem monitory z Iiyama x2483hsu na aorus fi27q.

 

 

No to jest dokładnie to o czym piszemy. Ja bym na Twoim miejscu spróbował po DP. Nie wiem jakim programem pod Windows sprawdzić timingi monitorów. Powinny być identyczne, wtedy jest szansa, że MCLK spadnie. Ja się specjalnie tym nie przejmuję, po prostu to ciekawe.

 

W ciągu tygodnia powinienem mieć u Siebie kable dp-dp zobacze czy coś to zmieni.

[novi 1463]

Gigabyte z outletu normalnie mi zarejestrowali na 4lata gwarancji : Model GV-R57XTAORUS-8GD Data wygaśnięcia gwarancji 2024-05-18 , jakby ktoś pytał . Potrzebny jest karton oryginalny, bo tam jest 4 liczbowy check number, bez kartonu nie zarejestruje raczej. Ja na szczęście dostałem karton oryginalny z naklejką .