Forum Debian Users Gang

Intel na pewno dobrze chodzi, nouveau to lepiej z daleko omijać.

Jak wiecie - ja mam 2 karty (Optimus), jako że przeszedłem na Debiana postanowiłem sobie zostać na Nouveau, którzy działa dobrze w porównaniu do Nvidii (nie wiem, czy Bumblebee pod Debianem aż tak się różni [a może nie mam Shadera 3.0, bo gry się burały]

W każdym razie
Intel mój ma nie najgorszą wydajność - 40FPS w ETracer
Na Nvidii nie najlepsza jakość :P - 50FPS (w rzadkich porywach do 60)

Pytanie jest inne - czy grasz w gry :P

Jeśli mówimy o czymś takim, by odpalić sobie OpenArena, Counter-Strike, Heroes3-VCMI - nada się

Nie wiem ogólnie czy to hiper-bug, ale pod Wine nie mogę odpalać aplikacji napisanych pod DirectX'a (OpenGL chodzą normalnie)

Fervi

http://nouveau.freedesktop.org/wiki/FeatureMatrix/

Ostatnio edytowany przez fervi (2013-07-31 12:14:57)

113

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:37:41)

uzytkownikubunt napisał(-a):

Wnioski bardziej z phoroniksa niż z własnego doświadczenia. Nie chce mi się bawić w ogóle z Geforcem, wszystko co chcę na Linuksie odpalić działa na GPU w Intelu. Mam małe wymagania ;)
Od co najmniej Sandy Bridge Intel publikuje pierwsze fragmenty kodu dotyczącego GPU w nadchodzących generacjach procesorów blisko rok przed premierą procesorów. Jednak ten kod jeszcze nie pozwala normalnie używać GPU, ale już ok. 3 miesiące przed premierą to zawsze sterownik jest już w używalnej formie. Ma również najnowszą, jaka jest dostępna w Mesie czyli obecnie 3.1 i większość rozszerzeń potrzebnych do OpenGL 3.2 i 3.3, wersję OpenGL. Nie wspiera Intel QuickSync.
AMD jak dobrze pójdzie to w dniu premiery, czyli do dystrybucji obsługa zostanie dodana po premierze. Co więcej ten kod jest wtedy z 10x razy wolniejszy niż kod zamkniętych sterowników. Najnowsze wersje kart AMD są używalne w zasadzie tylko z zamkniętymi sterownikami. Trochę lepiej ma się ma sprawa ze starszymi kartami. Warto jednak zauważyć, że AMD już teraz nie obsługuje w zamkniętym sterowniku kart z serii HD 4000 i wcześniejszych, czyli całkiem nowych kart. Do tych starszych kart publikują dokumentację, chociaż nie zawsze kompletną, od czasu do czasu publikują kod źródłowy. Nie mam pojęcia jak działa technologia AMD Enduro (technologia konkurencyjna do Optimusa Nvidii, wcześniej AMD miało inaczej nazwaną technologię, ale od serii HD 7000 w niektórych kartach i serii HD 8000, tutaj już chyba wszystkich, wprowadzili Enduro. Od tej porty karty AMD mogą, przynajmniej na Windowsie, zastępować iGPU w CPU, i to nie ważne czy CPU jest Intela czy AMD. Wcześniej tylko CPU AMD współdziałały).
Nvidia w ogóle nie wspiera ani kodem, ani dokumentacją otwartych sterowników, a obsługa Optimusa będzie zaimplementowana, jeśli w końcu będzie, dopiero teraz gdy w jądrze Linuksa są przez społeczność zaimplementowane mechanizmy PRIME. Plusem jest jednak to, że zamknięte sterowniki wspierają karty, które są już dosyć wiekowe. Ogromnym minusem jest ciągły brak wsparcia Optimusa. Większość obecnie sprzedawanych komputerów PC to laptopy, podejrzewam że wśród użytkowników Linuksa odsetek jest jeszcze większy, a mimo wszystko brak Optimusa.

Szkoda, że cały ten wywód opiera się na materiałach z Pudelka Phoroniksa.

Nie wiem skąd masz te 10x wolniejsze wyniki. Moja siostra ma kartę AMD i raczej to wygląda na 70% osiągów sterów zamkniętych. Przy czym jest nieporównywalnie mniej problemów ze sterownikami otwartymi. Się je instaluje i używa.
Właśnie jest wprowadzane vdpau i zarządzanie energią. Praktycznie ostatnie istotne brakujące rzeczy.

Co do starszych kart to tez pudło.
Nie są wspierane, ale w chyba Ubuntu.
W Debianie są dostępne w repozytorium sterowniki dla starszych Radeonów HD.
fglrx-legacy-driver
Oczywiście pochodzą od AMD, więc są jeszcze wspierane.

Odpowiednik Optimusa (który do dziś nie działa mimo ton marketingowego bełkotu i ogłoszenia jego wspierania) działał już w czasach, gdy dopiero raczkował Bumblebee.

Przy sensownym działaniu sterowników otwartych nie trzeba się tak przejmować jakością zamkniętych i ich funkcjami.

Ostatnio edytowany przez yossarian (2013-07-31 21:02:42)

uzytkownikubunt napisał(-a):

W każdym bądź razie bez magicznych hacków użytkowników (które mogą być niebezpieczne dla bezpieczeństwa), na pewno dla tych kart od AMD dla nowych kerneli nie będzie sterownika.

Są dystrybucje, których deweloperzy nie zajmują się unitami, mirami i innymi pierdołami, ale rozwojem dystrybucji i obsługą jak największej ilości sprzętu, a użytkownicy nie muszą sobie zaprzątać tym głowy.

fglrx-legacy-driver (8.97.100.7-4) unstable; urgency=low

  * Add patches 07-change-create_proc-to-proc_create-for-kernel-3.10.X and
    08-add-linux-seq_file.h-for-kernel-3.10.X from Krzysztof Kolasa to restore
    compatibility with to Linux 3.10.  (Closes: #717556)

— Andreas Beckmann <anbe@debian.org>  Tue, 23 Jul 2013 13:01:30 +0200

Nie podejrzewałbym DD o wprowadzanie potencjalnie niebezpiecznych dla bezpieczeństwa łatek.

PS Wsparcie dla Windowsa 8 chyba nie jest najbardziej kluczowe na forum Debiana ;)

Ostatnio edytowany przez yossarian (2013-07-31 22:20:38)

uzytkownikubunt napisał(-a):

Wsparcie dla Windowsa 8 chyba nie jest najbardziej kluczowe na forum Debiana ;)

Jesteśmy w dziale luźne rozmówki, a to co AMD odwaliło zaprzestając wsparcia dla kart, zarówno na Linuksie i Windowsie, które miały premierę niecałe 5 lat temu myślę, że jest warte przypomnienia. A takimi rzeczami jak obsługa zamkniętych sterowników do karty graficznej to jednak AMD powinno się zajmować. Tym bardziej, że nie tylko zostaje zerwana kompatybilność z nowymi kernelami, ale też nowymi wersjami X serwera. Doceniam wkład deweloperów Debiana, ale na razie rozwiązali problem niekompatybilności sterownika zamkniętego z nowym kernelem, ale niestety nie wiem czy uda im się zgrać ten sterownik z nowymi wersjami X Serwera. Najnowszy obsługiwany przez sterownik legacy to 1.12 i takowy znajduje się w debianie unstable. Obecnie najnowszy X serwer to 1.14 z 5 marca 2013 (po drodze 1.13 wnosił sporo udoskonaleń, akurat 1.14 niewiele), we wrześniu lub październiku wyjdzie 1.15. Debian sid jest już sporo do tyłu i być może tylko dlatego wciąż jeszcze na nim działają te sterowniki.

Z tym ATI niestety jesteś troszkę nieprecyzyjny.
ATI nie zaprzestało robić sterowników, tylko zbankrutował, a kiedy AMD przejął firmę ATI, to cały jej "ogon" odciął, podobnie, jak Oracle OOffice.

Dla nowych kart AMD stara się dostarczać sterowniki, teraz bidulki zwijają się jak w ukropie, bo zawsze "nie opłacało się robić sterów dla kilku użytkowników Linuxa", a teraz, gdy Android wszedł do urządzeń mobilnych, Steam robi konsolę na Linuxie, a Windows już nie jest "jedynym normalnym systemem" to AMD (podobnie jak np Broadcom) dostali sraczki w momencie, kiedy takie firmy jak Nvidia czy Atheros spokojnie liczą, ile wpływa na konto dzięki popularności rozwiązań unixopodobnych.

Nouveau?
Blob Nvdiii nie dość, że jest wielką tajemnicą Nvidii, to w dodatku ma chronione prawe technologie innych firm i krajów, miedzy innymi API DRM od M$ i wstawki od Amerykańskiego NSA (Snowden ostatnio o nich puścił farbę).
Nouveau powstaje poprzez cleanroom, ale muszę uczciwie przyznać,
że Nvidia nie przeszkadza w rozwoju Nouveau, co już jest jakimś tam osiągnięciem.

W dodatku Nvidia bardzo potrzebuje Nouveau, bo skąd inaczej Aaron P. ma wiedzieć, jak z blobie Nvidii na Linuxa zamontować płynne przełączanie  kart graficznych, jak zrobić EGL na Linuxa, czy jak w Linuxie odpalić DX11.

A jak sobie zajrzy do Galium3D i Nouveau, to życie staje się prostsze. :D

Także Nouveau i Nvidia, to jest pełna symbnioza, Nouveau jest swoistym "joystickiem" który razem z paluchami Linusa pozwala całkiem skutecznie sterować rozwojem binarnego blobu Nvidii.

Identyczna sytuacja jest ze sterami do Radeonów i  ATI/AMD, gdzie też,żeby szybko dopasować ster do nowego jajka, to się patrzy w źródła steru Radeon, który jest w tym jaju.

Ja natomiast polubiłem Nouveau nie dlatego,  że ma mega wydajność, bo jego całe OpenGL , EGL i DX11 wisi u mnie na procku, a nie na Nvidii, ale dlatego, ze mam po prostu 2 działające sterowniki do mojej karty, co ma swoje znaczenie w momencie, jakby Nvidia przypadkowo  dostała "kataru".
Na Nouveau u mnie nawet Compiz,  Openarena i Yamagi-Quake2  już śmiga płynnie, co mnie niezmiernie (ale bardzo pozytywnie) zdziwiło. ;)

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2014-02-02 17:12:44)

@uzytkownikubunt:
Pewnie będzie trzeba wtedy cofać xorga.
To akurat doskonały przykład na to, że sensownie działające otwarte sterowniki są czasem ważniejsze, niż stan tych zamkniętych.
Trzeba pamiętać jeszcze o zamieszaniu z Wyalandem/Mirem i ewentualnych problemach ze sterownikami zamkniętymi. Przynajmniej na początku.

@Huk:
Zasady są jednakowe dla każdego. Nie ma tak, że sobie przychodzi nvidia i chce zamykać i przywłaszczać kawałki kodu Linuksa.
IMHO byłby to bardzo zły precedens.

Są firmy, które inwestują więcej w kod i jakoś lamentu nie ma z powodu jego otwartości.

Ta „wstępna” obsługa Optimusa, którą już zdążyła się pochwalić Nvidia to akurat zasługa deweloperów kernela. Skopiowali tylko rozwiązanie ze sterowników otwartych (PRIME) i zażądali zmiany kodu dla swoich celów. 

Gdyby było tak różowo to nie padały by takie słowa ze słów kluczowych deweloperów:

Linus Torvalds napisał(-a):

Nvidia has been one of the worst trouble spots we’ve had with hardware manufacturers. And that’s really sad because Nvidia tries to sell chips, a lot of chips, into the Android market. And Nvidia has been the single worst company we’ve ever dealt with.

Huk napisał(-a):

a jak Nvidia chciała wykorzystać PRIME do IMPLEMENTACJI (nie skopiowanie - WŁASNEJ IMPLEMENTACJI, przy wykorzystaniu jego interfejsów) Optimusa to zobaczyła wielkiego fuckera za strony twórców jajka.

To jeszcze było przed PRIME. I jakąkolwiek chęcią ze strony Nvidii, żeby obsługiwać Optimusa pod jakimkolwiek systemem poza Windows (a właściwie: stanowczą niechęcią wobec wszystkiego innego).

117

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:37:46)

z mojej perspektywy niestety bez blob'a nvidi rownież nie da rady. przy steam próbowałem noveau ale niestety jest kicha. Pytanie teraz takie czy jesteśmy w stanie w jakikolwiek sposób kontrolować/ograniczyć blob'y w systemie tak aby nie miały możliwości łączenia się z wielkim bratem? Pytam na poważnie.

152

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:38:31)