AMD poprawia sterowniki dla Linuksa

1. Szkoda... (autor: Kenjiro | data: 7/07/16 | godz.: 08:36)
   że mają problem, aby uwolnić ten kod, by mógł być zintegrowany z wolnymi sterownikami.
   
   PS. Konkurencja jest w tej kwestii jeszcze gorsza, ale chyba nic nie stoi na przeszkodzie, aby wystąpić przed szereg.
   
   
2. Za pozno, NVidia juz wygrala... (autor: pandy | data: 7/07/16 | godz.: 10:56)
   Nie rozumiem jak majac niezla baze mozna to wszystko tak sp.... a nie, wlascwie to rozumiem - pracuje w korporacji i widze jak banda dyletantow na codzien probuje udawac ze nie ma problemow i ze wszystko OK i ze jestesmy najlepsi na swiecie...
   
   
3. pandy no wlasnie (autor: pawel1207 | data: 7/07/16 | godz.: 11:07)
   w wiekszych firmach niestety najwyzej siedza najczesciej dupowlazy przynajmniej tam gdzie pracowalem nie majacy pojecia o swojej pracy ale calujacy po mistrzowsku dupe szefa/managera /team lidera/ takze koniec koncow jak konczysz majac szefa idiote, managera kretyna, teamlidera ktory zamiast wspierac grupe zajmuje sie lataniem z managerem na papieroska i lizaniem dupy a puzniej sie wlasciciel dziwi ze straty przynosimy :D .. niestety ale prawdopodobnie tak wyglada to w amd teraz..
   
   
4. nie, koledzy... (autor: Duke Nukem PL | data: 7/07/16 | godz.: 20:14)
   to jest megakorporacyjna rzeczywistość.
   Kasa na idzie na decydentów a nie na fachowców.
   
   
5. ... (autor: Pet | data: 7/07/16 | godz.: 20:26)
   Zaraz zaraz, przecież AMD nie rozwija już od dawna zamkniętych sterowników. Teraz pracują wyłącznie nad nową gałęzią, która jest cała otwarta i to jest właśnie to GPU-PRO. Do tej pory można było ściągać i sobie samemu kompilować bo codziennie sterownik się zmienia a teraz po prostu przygotowali też paczki. Na Phoronix są testy tej gałęzi co jakiś czas. Wszelkie opinie jakie czytam są takie, że ten sterownik jest o wiele bardziej zaawansowany niż cokolwiek open source do Nvidii i obsługuje wszystkie najnowsze technologie linuksowe oraz pozwala na całkowity dostęp do kart i np. dynamiczne sterowanie zegarami w zależności od obciążenia GPU(co nie działa na NV).
   
   
6. ... (autor: Pet | data: 7/07/16 | godz.: 20:45)
   Poczytałem i GPU-PRO jest jakąś hybrydą nie całkiem chyba otwartą. Natomiast w teście RX 480 na Phoronix bardzo ciekawie porównali stan sterowników open source do kart AMD i Nvidii:
   "But if you are after a modern GPU that works today with a fully open driver (sans the firmware blobs), the Radeon RX 480 will fit your needs. On the open-source NVIDIA (Nouveau) side, the GeForce GTX 900 Maxwell support only began offering 3D acceleration a few months ago but the lack of power management / re-clocking leads to pathetic performance, there isn't any GeForce GTX 1000 Pascal support until NVIDIA again releases their signed firmware images, and only now the GeForce GTX 600/700 Kepler GPUs are starting to run nicely with the open-source code when enabling the non-default boost / re-clocking capabilities.".
   Ostatnie zdanie, że niby AMD jest w tyle za Nvidią, moim zdaniem mocno przekłamuje rzeczywistość.
   
   
7. @Pet (autor: daver | data: 7/07/16 | godz.: 21:32)
   >> Ostatnie zdanie, że niby AMD jest w tyle za Nvidią, moim zdaniem mocno przekłamuje rzeczywistość.
   
   Przeciwnie. Jest napisane, że otwarte sterowniki AMD są znacznie lepsze od otwartych dla kart NV, a nawet całkowitym braku supportu dla pascali.
   
   Krótko mówiąc, jeśli ktoś jest freetardem hipokrytą i chce pograć w steamowe gierki, powinien wybrać AMD. Reszta (graczy/dualbooterów) nadal powinna wybrać NV i zainstalować bloba.
   
   
8. daver (autor: pawel1207 | data: 8/07/16 | godz.: 01:49)
   to porownaj te hybrydy do zamknietych nvidi :DDD a noveau ma po prostu wyswietlac grafike na disteo ktore zamknietych nie toleruja a potzebny jest jakis w miare dzialajacy sterownik sa operacje gdzie wyniki z zamknietego nv so 200 razy lepsze od otwartego czy zamknietego amd i to jest problem w zasadzie jak ktos nie ma oporow i nie musi miec wszystkiego open w dystrybucji to soory ale wole 660 gtx + zamkniete stery niz 480 na jakichkolwiek otwartych hybrydowych zamknietych od amd ... 660 i tak wi wiekszosci wypadkow zje to 480 na sniadanie :D jak masz linuksa too sorry ale albo stare amd albo nvidia..
   
   
9. @daver (autor: Pet | data: 8/07/16 | godz.: 08:56)
   Ja miałem na myśli ostatnie zdanie z tego newsa :)
   @pawel1207
   Problem w tym, że nawet zamknięte stery NV wcale nie są lepsze od AMD. I tak samo można zrobić wyniki znacznie lepsze na AMD niż na NV. Największym problemem zamkniętych sterów NV zawsze była stabilność bo co z tego, że nawet jeśli coś zrobi szybciej to się to ciągle wiesza albo jakieś cuda się dzieją z ekranem...
   
   
10. @8. (autor: daver | data: 8/07/16 | godz.: 10:21)
    Paweł, ja rozumiem, że była druga nad ranem...
    
    
    @9 Ach, więc wszystko się zgadza. Zamknięte stery NV dla Linuksa nie mają sobie równych pod żadnym względem.
    
    
11. daver (autor: pawel1207 | data: 8/07/16 | godz.: 11:47)
    o 2 to ja w pracy jeszcze jestem ..
    
    
12. oj, to niedobrze ;p (autor: daver | data: 8/07/16 | godz.: 17:47)
    Chodzi o to, że nie wiem do czego piłeś w poście #8
    
    BTW. Nie jest tak, że nouveau nie ma aspiracji do bycia czymś więcej niż prostym DDX'em. Oni po prostu nie mają środków, a nawet możliwości (patrz np.: brak firmware'u do pascala), by być pełnoprawnym, otwartym zamiennikiem bloba.
    
    
13. daver (autor: pawel1207 | data: 11/07/16 | godz.: 08:25)
    nigdy nie beda tak samo jak przy amd oraz czesc kodu jest zastrzezona roznymi umowami z microsoftem i dx12 rownierz producent stosuje rozne sztuczki i kruczki :D powszechnie podane jako optymalizacje sterownika np. narzut sterownika itd.. wiec otwarte nigdy nie beda tak dobre jak zamkniete w tym wypadku . A pije do tego ze w przypadku amd otwarte sa lepsze od zamknietych i byly koniecznoscia aby z radkow dalo sie normalnie korzystac pod linuxem powiem tak byly wrecz niezbedne dlatego amd slynace z lenistwa otwozylo czesc specyfikacji a nawet kodu bo sami nie byli w stanie napisac wydajnych a przede wszystkim dzialajacych poprawnie sterownikow dlatego zwrocili sie do spolecznosci . w przypadku nv w wiekszosci sterowniki owszem nie tak dobre jak pod winda ale jednak bijace pod karzdym wzgledem te od amd czasem z bledami ale bijaca wydajnoscia sterowniki od amd wielokrotnie wystarczy porownac wydajnosc pod opengl niektore operacje sa wielokrotnie szybsze niz u amd jakosc sterownikow rownierz o wiele wyzsza w zasadzie sterowniki open jak noveau nie byly niezbedne powstaly dlatego aby aby dystrybucje zgodne gpl 2.0 3.0 itd :D obslugiwaly z tzw. startu jaks tam akceleracje na kartach nv . Pet w wypadku linuxa stabilnosc sterownikow u obu producentow nie jest tak oczywista bo mocno zalerzy co jest nawyczyniane w kernelach oraz dystrybucji i pomimo iz jestem fanem linuxa to windowsy zapewniaja w tym wypadku stabilniejsza strukture microkernel nawet hybrydowy ma wiele zalet i to jest jedna z nich oczywiscie ma rownierz wady :D ale nie otym tutaj hmm.. powiem tak na vaniliowym kernelu zazwyczaj udawalo mi sie znalezc kombinacje jadro sterownik + X aby bylo stabilne i co zaskoczenie rownierz u amd problem w tym stery amd same z siebie sa koszmarnie powolne i mocno wybrakowane czesc funkcji nie jest nawet obsugiwana oraz amd potrafilo poscic userow linuxa przez pol roku aby w koncu wypuscic jako tako dzialajacy sterownik :D co przy nv nigdy mi sie nie zdarzylo... tak ze amd i open = smiech na sali ..
    
    
14. ... (autor: Pet | data: 11/07/16 | godz.: 09:17)
    A ja tam nie miałem żadnych problemów z wydajnością AMD czy brakiem jakichś funkcji. Tak jak pisałem - równie dobrze można znaleźć test gdzie AMD jest wielokrotnie szybsze od NV. Używałem R9700, HD5850 oraz Fury pod linuksami. Fury krótko ale wszystko śmigało. Znajomy ma farmę do kopania kryptowalut na linuksach i ma tam tylko Radeony bo wydajność NV była żałosna.
    Co do otwartości to nie chodzi o to, że nie umieją bo mieli bardzo dobre zamknięte sterowniki. To jest po prostu obecna strategia całej korporacji. Nawet gdzieś obiło mi się o uszy, że ma powstać otwarty sterownik dla Windows.
    
    
15. Kuźwa, Paweł! Weź się wyśpij. (autor: daver | data: 12/07/16 | godz.: 00:04)
    Tego się czytać nie da. Pomijam, że dyskutujesz sam ze sobą.
    
    @Pet, zaklinasz rzeczywistość. Pierwszy z brzegu test wydajności http://www.phoronix.com/...dgpu-gtx-1080&num=3 + cała masa innych do przejrzenia na tym vortalu. W kwestii jakości sterowników: http://richg42.blogspot.com/...driver-quality.html
    
    
16. Nvidia i fps (autor: Pet | data: 12/07/16 | godz.: 01:46)
    Na Phoronix znalazłem, że Radeony są np. szybsze w Furmark albo działa na nich BioShock Infinite który crashuje się na Nvidii, więc jak pisałem - AMD bywa lepsze i stabilniejsze: http://www.phoronix.com/...d-april-amdnv&num=2
    
    Natomiast co do FPS to jest tutaj szeroki problem nierzetelności recenzentów na portalach oraz ich zależności od Nvidii(darmowe próbki, prawie gotowe artykuły, opłacone wyjazdy) bo karty nie są testowane w równych warunkach i ustawieniach sterowników. Nvidia osiąga bardzo dobre wyniki w DX11 dzięki pre-renderowaniu ramek. Domyślnie także w Windowsie do 3 ramek jest renderowanych z opóźnieniem. Dzięki temu jest duży boost w fps ale kosztem input-laga. Żaden portal nie ma odwagi tego wyłączyć do testów i dlatego dopóki nie będzie mierzonego input-lag to ja nie uwierzę w żaden wynik Nvidii. Szerzej o problemie tutaj: https://www.youtube.com/watch?v=AWH4r-KQEF8
    Powtrzam - aktualnie do 3 ramek jest renderowanych z opóźnieniem domyślnie także w benchmarkach. Po wyłączeniu tego wydajność potrafi spaść na pysk ale przynajmniej nie ma już laga z drivera. AMD tego nie stosuje w interaktywnych aplikacjach ale NV nie ma skrupułów. Ale w DX12 i Vulkanie się kończy taka możliwość optymalizacji - na szczęście bo widziałem jak ludzie GTXy wymieniali na Radeony bo nie było jeszcze wtedy wiadomo skąd ten input lag.
    
    
17. I piszę to z własnego doświadczenia (autor: Pet | data: 12/07/16 | godz.: 02:05)
    Pracowałem nad optymalizacją silnika gry, który przez głupi błąd - za długo był zamapowany bufor do którego pisał CPU i z którego czytał GPU jednocześnie - na Radeonach działał nawet 4x wolniej niż na Nvidii. Gra developowana była na kartach Nvidii wyłącznie. Po premierze się okazało, że za wolne Radeonach i ja to poprawiałem. Okazało się, że to nie ma prawa działać bo GPU ciągle musi się zatrzymywać bo dojechał do kawałka bufora zalockowanego przez CPU. Ale działało jednak na NV bo dzięki pre-renderowaniu tak naprawdę jeszcze przez 3 ramki to wszystko się działo tylko wirtualnie i nie ma żadnego GPU. GPU dostanie to wszystko dopiero 3 ramki później odpowiednio uporządkowane i bez opóźnień. Nawet profilery nie pokazywały niczego złego na NV.
    Niby fajna rzecz i dobrze, że jest ale to nie powinno być włączone domyślnie bo:
    - gracze mają dodatkowego input-laga ze sterownika
    - programiści nie są świadomi błędów
    - no i decyzje o zakupie nie są podejmowane z pełną świadomością bo może się okazać, że po zlikwidowaniu laga Radeon byłby szybszy.
    
    
18. wyjątek potwierdza... (autor: daver | data: 12/07/16 | godz.: 02:11)
    Serio, nie śledzę sytuacji, bo nie używam już kart nv (uzywałem 8 lat na Linuksie), więc nie wiem co tam się wydarzyło, ale zacytuję Michaela: "[...]there was an ODD situation[...]", bo to nie było normalne. Normalne są takie obserwacje: http://www.phoronix.com/...nvamd-preview&num=1
    
    Pod Linuksem nie ma DX11. Test, który zalinkowałeś przeczy temu co napisałeś. Różnice są niewielkie, niemal w granicach błędu pomiarowego, gdy my rozmawiamy o sytuacjach gdy Fury pod Linuksem dostaje lanie od GTX 950 i nikogo to nie dziwi.
    
    
19. PS: (autor: Pet | data: 12/07/16 | godz.: 02:13)
    W OpenGL tez jest prerenderowanie 3 ramek domyślnie włączone i nawet np. Cinebench ma gorszy wynik po wyłączeniu tego.
    
    
20. jak grochem... (autor: daver | data: 12/07/16 | godz.: 02:32)
    To jest udokumentowana funkcja, która może mieć korzystny lub niekorzystny wpływ na wydajność.
    
    "Maximum Pre-Rendered Frames: If available, this option - previously known as 'Max Frames to Render Ahead' - controls the number of frames the CPU prepares in advanced of being rendered by the GPU. The default value is 3 - higher values tend to result in smoother but more laggy gameplay, while lower values can help reduce mouse and keyboard lag. However extremely low values such as 0 may hurt performance, so I recommend this option be kept at its default of 3 globally, and only adjusted downwards in specific game profiles. Remember, in most cases mouse lag is due to low framerates, so adjusting this option is not an automatic cure to lag issues, nor should it be the first thing you try. Finally, it only works in DirectX games, not OpenGL games."
    
    Przykłady: https://steamcommunity.com/.../365163686080707830/ lub https://www.reddit.com/..._nvidia_max_prerendered/
    
    Powtarzam. Nie rozmawiamy tu o średniej, kilkuprocentowej różnicy. Mówimy tu o "normalnych" sytuacjach, w których pod Linuksem lowendowa karta NV bije hi-end od AMD.
    
    
21. ... (autor: Pet | data: 12/07/16 | godz.: 09:02)
    Funkcja jest udokumentowana ale portale nie chcą jej wyłączyć do benchmarków pomimo iż gracze muszą to robić jak chcą pograć a daje ona czasem - w zależności od tytułu i kombinacji z procem - nawet bardzo duże przyspieszenie. Sterownik sobie wtedy nawet na kilku wątkach wykonuje obliczenia do tych opóźnionych ramek ale niestety czuję się laga a gry są niegrywalne:
    https://hardforum.com/...ag-nvidia-vs-amd.1861533/
    input lag na Nvidia w Dark Souls 3:
    https://youtu.be/TZsITS8_JAY?t=2m21s