poniedziałek, 18 czerwca 2012

Nvidia to zło. Poważnie.

Ostatnia wypowiedź Linusa spowodowała skrajne opinie. Typowe: "Z Nvidią nigdy nie było problemów!", "U mnie działa!". Fajnie, trzeba tylko zwrócić uwagę o co Linus został zapytany.

Pytanie dotyczyło tworu o nazwie Nvidia Optimus. Optimus ma umożliwiać dynamiczne włączanie akceleratora Nvidii, gdy integra Intela okazuje się niewystarczająca. Gdyby liczyć na Nvidię do ten super/hiper Geforce zamontowany w notebooku okazałby się bezużytecznym klockiem, po prostu nigdy by się nie uruchomił. Nvidia w ogóle nie ma zamiaru wspierać Optimusa pod Linuksem

Dopiero ludzie od projektu Bumblebee, wkładając sporo wysiłku, ożywili GPU Nvidii. Co zrobili "zieloni"? Kompletnie nic. Nie dali sterownika ani dokumentacji. Społeczność znów musiała poradzić sobie samodzielnie, wykorzystując m.in. VirtualGL (nie ma fizycznego "przełącznika" między GPU Intela i Nvidii).

Przy okazji: binarne sterowniki Nvidii jak i AMD to również problem. Pewnie teraz co niektórzy się oburzą "mój Geforce działa idealnie na binarnych, wszystkie gry latają jak należy". Fajnie, tylko sterowniki Nvidii i AMD stoją na rozwoju podsystemu grafiki Linuksa. Chcecie wprowadzenia Waylanda w miejsce opasłych X-ów? Zapomnijcie, te sterowniki go nie wspierają, one nawet nie wspierają KMS.

Przyszłością jest Gallium3D i otwarte sterowniki dla AMD (R300g, R600g, RadeonSI), Nvidii (nouveau) i Intela. Małe, przejrzyste, współdzielące kod dla wielu producentów, systemów i API graficznych. AMD i Intel przykładają się do rozwoju otwartych sterowników: zatrudniają programistów, upubliczniają dokumentację. Nvidia nie robi nic. Oczywiście o ile można zrozumieć niechęć do otwarcia sterowników[1], to nieupublicznienie dokumentacji może być tylko wyrazem złej woli.

 [1] Nie jest tajemnicą, że producenci GPU oszukują by wpasować się w benchmarki. Takie "optymalizacje" trudne do wykrycia przez ludzkie oko, mogłyby znaleźć się w upublicznionych sterownikach. Tak samo jak rozwiązanie "pożyczone" od konkurencji. Petycję o otwarcie sterowników Nvidii napisano już dobrą dekadę temu, bezskutecznie.

Do kogo zwracają się użytkownicy mając problemy z kartą graficzną?  Do twórców dystrybucji. A ci, w przypadku sterowników binarnych nie mogą wiele zrobić. Potem zaczyna się płacz, a "ten Linux to zły, bo grafika mi nie działa". Nawet jeśli opiekunowie dystrybucji nie mogą nic zrobić, a za błąd odpowiedzialna jest całkowicie Nvidia.

Linus wspomniał o Tegrze. Bardzo słusznie. Nvidia nie dość, że sprzedaje Tegrę jako "czarną skrzynkę", to jeszcze próbuje przenieść swoje paskudne zagrywki z rynku PC. Znaczek "The Way it's Meant to be Played" miał sugerować, że będzie ona najlepiej działała na GPU Nvidii. I tak często było, ale nie za sprawą optymalizacji a podłożenia nogi konkurencji.
Pod Androidem Nvidia promuje Tegra Zone. Ot, żeby na układach konkurencji nie dało się pograć. 

Nvidia miała swoje 5 minut po upadku 3dfx-a, pierwszego producenta wydajnych układów wspierającego Linuksa. I jedynego, na którym Unreal Tournament wyglądał tak jak powinien:)
Jakieś 10 lat temu problem Nvidii tak opisywała dokumentacja MPlayera:
Nie podoba nam się fakt, że nVidia dostarcza wyłącznie sterowniki binarne (dla XFree86), które często zawierają błędy. Dostaliśmy wiele zgłoszeń na mplayer-users o ich błędach, marnej jakości, braku stabilności oraz słabym wsparciu dla użytkownika i eksperta. Wiele z tych problemów/kwestii pojawia się ciągle. nVidia skontaktowała się z nami ostatnio i stwierdziła, że te błędy nie istnieją, a przyczyną braku stabilności są wadliwe układy AGP, nie otrzymali również żadnych zgłoszeń o błędach w sterowniku (takich jak purpurowa linia). Jeżeli masz problem ze swoją kartą nVidia, radzimy zainstalować najnowszą wersję sterowników nVidia i/lub kupno nowej płyty głównej lub poprosić nVidię o otwarte sterowniki. W każdym razie, jeżeli używasz sterowników binarnych nVidia i stajesz przed problemami z nimi związanymi, bądź świadom, że nie otrzymasz zbyt dużej pomocy z naszej strony, ponieważ nie mamy dużej możliwości jej udzielenia. 
Owszem, od tamtej pory sporo się zmieniło, sterowniki uległy poprawie, wprowadzono vdpau. Gracze cieszyli się wsparciem S3TC (wymaganym m.in. przez UT2k3) niedostępnym przez długi czas dla otwartych sterowników (np. ATI). Nie zmieniło się jedno: polityka Nvidii.

środa, 13 czerwca 2012

FreeCAD: tworzenie przeciągnięć (sweep)

FreeCAD pozwala na tworzenie brył i powierzchni o zmiennym przekroju bez wykorzystania trajektorii prowadzącej (loft) jak i z jej wykorzystaniem (sweep). Ta druga opcja, dostępna od dawna z poziomu Pythona, została wprowadzona do GUI dopiero na przełomie ubiegłego i obecnego tygodnia.

Zasadniczo przeciągnięcie (sweep) potrzebuje otwartej krzywej wykorzystywanej jako trajektoria i przynajmniej jednego zamkniętego przekroju. Poniżej znajduje się prosty przykład wykorzystujący jeden szkic dla trajektorii i dwa dla przekrojów.


Przykład prosty - kolanko koło-prostokąt

Uwaga: potrzebny jest FreeCAD przynajmniej w wersji:
Version: 0.13.1122 (Git)
Branch: master
Hash: d331b0087aee494afcdcf67fa13f1bec64365166

Przejdźmy do warsztatu Part Design lub Sketcher i utwórzmy nowy szkic na płaszczyźnie  YZ. Łuk (jak na zrzucie poniżej) o promieniu 50 będzie naszą trajektorią.


Kolejny szkic powinien zostać narysowany na płaszczyźnie XZ. To nasz przekrój początkowy, niech nim będzie prostokąt. Ważne: środek prostokąta ustawmy na końcu trajektorii (X=0,Z=50).

W podobny sposób należy utworzyć drugi przekrój, to okrąg na płaszczyźnie XY. Również jego środek musi znajdować się na (drugim) końcu trajektorii.

Powinny powstać trzy szkice: Sketch dla trajektorii oraz Sketch001 i Sketch002 dla przekrojów. Poniższy zrzut prezentuje prawidłowe umiejscowienie szkiców.

Przechodzimy do warsztatu Part i wybieramy z menu Part-Sweep... Pola w Task view (lewy dolny narożnik) służą do wybrania przekrojów. Trajektorię należy zaznaczyć w widoku 3D. Gdyby składała się ona z wielu segmentów można je zaznaczać trzymając [Ctrl] - aktualnie zaznaczone elementy widoczne są w Selection view.

W Task view zaznaczamy opcje Solid (tworzenie pełnej bryły) i Frenet. Następnie klikamy Ok. Efekt końcowy widoczny jest poniżej.
Parametry przeciągnięcia można zmieniać w Property view-Data. Gdy trajektoria nie składa się ze stycznych krzywych warto zmienić Transition na Transformed. W naszym przykładzie taka zmiana nie jest konieczna.

Pozostaje pytanie o opcję Frenet. Według opisu klasy BRepOffsetAPI_MakePipeShell:
Sets a Frenet or a CorrectedFrenet trihedron
to perform the sweeping
If IsFrenet is false, a corrected Frenet trihedron is used.
Nie wchodząc w głębszą matematykę, opcja ta potrafi mieć znacznie przy nieprawidłowo skręconych przeciągnięciach. Ciekawostka: nazwa pochodzi od pewnego Francuza.

Przykład bardziej skomplikowany - łom

Tutaj znajdziecie plik zawierający model łomu. W jego przypadku szkice przekrojów powiązane są ze szkicem trajektorii.

Pierwszy szkic pełni rolę nie tylko trajektorii, ale też bazy dla kolejnych szkiców - po to dodałem 5 prostopadłych do trajektorii linii.


Wyciągnąłem szkic (Extrude.. z warsztatu Part) uzyskując powierzchnie na których można rysować szkice przekrojów. By zapewnić pewne umiejscowienie danego przekroju wykorzystałem narzędzie do mapowania więzów z zewnętrznych krawędzi. W szkicowniku trzeba użyć External geometry i wskazać wybraną krawędź.

 Jako trajektoria potrzebna jest tylko część pierwszego szkicu:

Nie użyłem jednocześnie całej trajektorii i wszystkich przekrojów. Pierwsze przeciągnięcie to Sketch001-003, drugie Sketch003-004 i trzecie Sketch004-005.

Oto jak zachowuje się łom podczas edycji:

niedziela, 10 czerwca 2012

Steam, Wine i Linux - to działa całkiem nieźle

Przy okazji ostatnich emocjonujących informacji na temat wydania Steama i silnika Source na GNU/Linuksa chcę wspomnieć o stanie obecnym, czyli Steamie uruchamianym przez Wine.


Produkty Valve działają całkiem dobrze pod Wine. Obecnie sama instalacja Steama to kilka kliknięć, bez uciekania się do konsoli czy grzebania w plikach konfiguracyjnych. Instrukcje można znaleźć na stronach społeczności programistów Valve.

"Natywny" Steam początkowo zaoferuje pewnie tylko gry Valve na silniku Source (Half-Life 2 (EP1, EP2), Portal (2), Left 4 Dead (2), Team Fortress 2). Okazuje się, że już teraz (z użyciem Wine) instalacja tych tytułów odbywa się dokładnie tak samo jak pod Windows. Kilka kliknięć i można zaczynać grę.
W przypadku gier innych producentów może być gorzej, tu przychodzi z pomocą baza Wine czy strona Steam Games on Linux

Ciekawostką jest, co widać na załączonym obrazku, że Steam potrafi rozpoznać, kiedy jest uruchomiony pod Wine i określić jego wersję.

Do uzyskania dobrej wydajności, zapewne porównywalnej do Windows, nadal potrzebne są binarne sterowniki. Otwarte (wykorzystujące Mesę 8.1) są wystarczająco dopracowane by bezbłędnie wyświetlać grafikę (powyższy zrzut ekranu, ustawienie silnika Source na DirectX 9.0), ale wydajność niestety kuleje i przy budżetowych kartach graficznych może być zbyt niska.

W tym momencie zacząłem się zastanawiać w czym "natywny" klient Steama i silnik Source będzie lepszy niż ten pod Wine. Pewnie będzie nieco stabilniejszy i mniej pamięciożerny. No i może prędkość renderingu gier się podniesie. Właśnie... to nic pewnego, szczególnie, że Wine to nie emulator, a implementacja API Windows i może zapewniać wydajność zbliżoną do systemu z Redmond. Tak samo nieudolny port gry pod OpenGL może być mniej wydajny niż wersja windowsowa uruchomiona pod Wine, które zajmuje się tłumaczeniem wywołań Direct3D na OpenGL (w tym shaderów HLSL na GLSL).
Korzyści będą za to widoczne w przypadku gier korzystających z Direct3D 10/11 (poziom ~ OpenGL 3.3/4.2). Wsparcie Wine dla wszystkiego ponad Direct3D 9.0 jest szczątkowe.

Wprowadzenie "natywnego" Steama nie zmieni wiele z dnia na dzień. Już teraz można go z powodzeniem używać pod Wine. Ważniejsze będą efekty długofalowe. Kto wie jaki wpływ będzie miało Valve i Steam na API i sterowniki używane pod Linuksem. Nie chcę tu wróżyć ze szklanej kuli. Poczekamy, zobaczymy.

PS W przypadku OS X i Windows, Valve wprowadziło Steam Play - grę kupuje się raz i można ją uruchamiać na obu platformach. Mam nadzieję, że docelowo Steam Play obejmie również Linuksa.