Który zestaw sterowników graficznych lepiej przetestować na dłuższą metę?

Mój komputer ma więc kartę mobilności Radeon, a Compiz nie chce się z nią bawić. Pozwala mi to na kompromis: mogę korzystać z zastrzeżonych sterowników i uzyskiwać zwiększoną wydajność i trafiać w kilka przedmiotów użyteczności, lub mogę korzystać ze „standardowych” sterowników i korzystać z wydajności na korzyść wszystkiego, co działa poprawnie.

Zdarza mi się również przeprowadzić wiele testów alfa na wolnej partycji na tym komputerze. To mnie zastanawia, którego sterownika powinienem używać? Czy ważniejsze jest, aby „standardowe” sterowniki faktycznie działały lepiej? A może powinienem zgłaszać błędy przeciwko Unity, ponieważ nie działa ono prawidłowo z zastrzeżonym zestawem? Lub oba.

Co sugerują programiści, że staram się przynosić korzyści projektowi w dłuższej perspektywie? Bez względu na to, jaki typ karty graficznej jest używany. Czy jest to czynnik, który zestaw należy zastosować?

Jako jeden z opiekunów Ubuntu X mogę powiedzieć: testowanie zarówno sterowników open source, jak i zastrzeżonych jest cenne; mamy wielu użytkowników obu, i ważne jest, aby Unity działało dobrze zarówno na stosie darmowym, jak i zastrzeżonym.

Jeśli jednak chcesz, aby twoje testy miały największy wpływ, najlepiej byłoby przetestować darmowy stos - przynajmniej w przypadku kart AMD.

Sterownik Radeon typu open source ma rozsądny zestaw programistów - nie jest duży i zawsze może obsłużyć więcej, ale jest obsługiwany przez AMD. Z wyjątkiem napływu setek programistów pracujących w pełnym wymiarze czasu, sterowniki te nie osiągną takiej samej wydajności jak fglrx, ale jest całkiem możliwe, że osiągną 90-95% wydajności; to ostatnie kilka procent, które są niezwykle drogie.

Są również znacznie łatwiejsze do ulepszenia - ponieważ są oprogramowaniem typu open source, mamy wgląd w poprawki i znacznie łatwiej usprawiedliwiamy naprawianie błędów w stabilnych wydaniach. Dzięki sterownikowi fglrx otrzymujemy tylko funkcje i poprawki mieszania zrzutów kodu o nieznanym potencjale regresji. Utrudnia nam to aktualizację zastrzeżonych sterowników w stabilnej wersji.

Wreszcie istnieje większa szansa na ulepszenie radeonu niż fglrx. Programiści Radeon dbają o cały stos komputerów stacjonarnych, fglrx jest w dużej mierze skierowany do użytkowników stacji roboczych.

Dla secesji odpowiedź jest nieco mętna. Nadal istnieje większa szansa na ulepszenie w nouveau niż nvidia - znowu nvidia jest w dużej mierze ukierunkowana na rynek stacji roboczych - ale nouveau ma trudniejszy czas na robienie postępów niż radeon, ponieważ dodatkowo muszą wszystko przerobić.

Wszystko to dotyczy głównie błędów, a nie wydajności. Generalnie trudniej jest wygenerować dobry błąd wydajności, niż wygenerować dobry błąd lub nieprawidłowy błąd renderowania. Błędy renderowania i awarie są na ogół izolowane do małej sekcji kodu, podczas gdy problemy z wydajnością zwykle obejmują cały stos kodu. Jeśli znajdziesz pojedyncze problemy z wydajnością, warto je zgłosić, ale nie jest to częsty przypadek.

Krótko mówiąc, problemy z wydajnością zazwyczaj wymagają aktywnego wysiłku w celu zidentyfikowania - jest mało prawdopodobne, aby natknąć się na problem z wydajnością, który można rozwiązać. Błędy - zarówno awarie, jak i błędne renderowanie - można łatwo zidentyfikować podczas normalnego użytkowania.

Jeśli chcesz pomóc przyczynić się do dalszego rozwoju i obsługi sterowników dla Ubuntu, najlepiej jest przypisać, wspierać i przyczyniać się do usuwania błędów w obu wersjach. Oba są ważne, ale musisz odróżnić to, co naprawdę jest w twoich rękach.

Zamknięty sterownik oznacza po prostu, że jest zamknięty. Można powiedzieć, że Unity jest zepsuty z powodu zamkniętego sterownika, ale ostatecznie, jeśli sterownik nie działa, nie ma wiele do zrobienia. Testy przeprowadzane są na oficjalnych wydaniach, ale to nie znaczy, że będzie działać dla wszystkich.

Muszę powiedzieć, że nie wierzę, że wydajność sterownika open source będzie zawsze tak dobra jak sterownika zamkniętego, ale mówiąc o Ubuntu i Linuksie, chcemy mieć przynajmniej alternatywę dla naszego sprzętu działającego w minimalnych warunkach z sterownik open source.

Chcemy mieć pewność, że biorąc pod uwagę tę opcję, użytkownik będzie mógł uruchomić Unity bez wielu usterek w sterowniku zamkniętego źródła, ale najważniejsze jest to, że dostępny jest dobrze zbudowany, stabilny sterownik o otwartym kodzie źródłowym.

Dzięki zamkniętemu sterownikowi możesz otwierać błędy, reklamacje, wspierać innych w zgłaszaniu danych, aby naprawić wszelkie problemy, ale ostatecznie to na konstruktorze spoczywa ścieżka rozwoju sterownika.

Z drugiej strony zamknięty sterownik jest w dużej mierze obsługiwany, błędy są traktowane bardziej bezpośrednio, prace rozwojowe są wykonywane, ale także naprawianie błędów jest wdrażane w poszczególnych przypadkach. Społeczność Open Source ciężko pracuje, aby działała jak najlepiej i przy jak najmniejszej liczbie problemów.

Twój czas jest cennym zagadnieniem związanym z raportowaniem w Unity działającym z zamkniętym sterownikiem, ale IMHO, sterownik open source zasługuje na to znacznie więcej i zyskasz więcej wartości za wysiłek wspierający go.