Przed dwoma tygodniami informowaliśmy, że firma S3 reklamuje swoje układy Delta Chrome z serii 500 jako w pełni działające w systemie Linux – jednocześnie nie zapewniając do nich sterownika. Producent GPU w końcu spełnił jednak swoje obietnice.
Początkowo sterownik miał być dostarczony do końca grudnia, lecz firmie nie udało się dotrzymać tego terminu. Nie pojawiały się też żadne nowe informacje odnośnie prac nad sterownikiem. Po nagłośnieniu całej sprawy S3 poinformowała, że częściowe wsparcie zapewniają drivery do wcześniejszej serii, Chrome 400. Rozwiązanie takie było niestety zaledwie prowizorką, gdyż nie oferowało żadnej akceleracji.
Okazuje się jednak, że S3 stanęła w końcu na wysokości zadania i wydała sterownik z prawdziwego zdarzenia. Nowe drivery oferują wsparcie dla OpenGL 3.0 oraz dla sprzętowej akceleracji odtwarzania wideo – w tym najbardziej popularnych dziś formatów H.264, VC-1 i MPEG2. Poza tym wspierane jest rysowanie w trybie 2D, zarówno poprzez EXA, jak i XAA. Poza najnowszymi kartami z serii 500 obsługiwanych jest wiele starszych produktów. Po dokładną listę odsyłamy na stronę S3.
Sterownik do akceleracji wideo wykorzystuje interfejs VA-API, co, o ile nie jest rozwiązaniem złym, jest z pewnością wyborem nietypowym. Jak dotąd jedynym producentem, korzystającym z tego rozwiązania, był Intel, który jednak zastanawia się, czy nie przepisać sterownika, by używał wprowadzonego przez nVidię interfejs VDPAU. W tej chwili, aby skorzystać z przyśpieszania, należy użyć specjalnej wersji MPlayera, z poprawkami, które na razie znajdują się w drzewie SVN i jeszcze nie zostały wprowadzone do stabilnego wydania.
Niestety i tym razem nie obyło się bez przysłowiowej łyżki dziegciu, gdyż producent nie udostępnia źródeł sterownika. Nie byłoby w tym zresztą niczego nadzwyczajnego, gdyby nie fakt, że sterownik ów wydany został rzekomo na licencji GPL. Miejmy nadzieję, że i ta sprawa z czasem się wyjaśni. Firmie S3 gratulujemy jednak wykazania dobrej woli i pokrycia swoich obietnic.
Jeśli ktoś ma przypadkiem kartę z układem S3 i zechciałby sprawdzić, czy sterownik ten faktycznie działa, proszę o informację. Chętnie dopiszę coś na ten temat. Niestety nie mam pod ręką, ba prawdopodobnie nigdy nawet w ręku nie miałem, sprzętu z taką grafiką.
Hmm, z tego co kojarzę, to mój kumpel miał właśnie taką kartę. Nie wiem jaki model, ale Worms Armageddon na tym chodziło. Na mojej 2mb również i do tego płynnie, a przecież ta gra wygląda bardzo ładnie. Fizykę też ma świetną i do tego starczył procek Pentium 166mhz. 🙂 A teraz? Teraz do byle dupnej gry musisz mieć 1Ghz, choć jest na poziomie gier z z lat 9x. Takie mamy czas, nikt się teraz nie stara, żeby gra żarła jak najmniej zasobów. Teraz mam wrażenie, że robi się je tak by żarły jak najwięcej, by napędzać sprzedaż nowych podzespołów…
@Bananikus, bo tak się je robi 🙂 Myślisz, że logo "nVidia – the way it's meant do be played" nic nie oznacza? Dla mnie oznacza tyle samo co "nVidia – the way it's meant to make business" ;]
Mój pierwszy układ graficzny to podobnie jak u Mario : Vic z C64, potem ECS z A500 i przejście w AGA w A1200 🙂 Pecetów nie liczę, bo jak przechodziłem na PC to nie było się czym podniecać..
@Bananikus: jak wejdziesz na jakieś forum gamedev, i powiesz, że chcesz pisać gry w Javie albo Pythonie, to Cie wyśmieją, że Java jest za wolna do pisania gier, bo w grach to trzeba wycisnąć wszystkie możliwości ze sprzętu. I faktycznie taki Crisis wyciska. Tylko zastanawiam się po co, skoro to się nie przekłada na grywalność (choć ładniej wygląda).
Ostatnio z kumplem (zapalonym graczem) oglądaliśmy demko jakiejś nowej gry, nie wiem co to było – gdzieś pod koniec gdy kumpel zobaczył animacje płomienia, to stwierdził, że z takim ogniem to słabe i że nie będzie grał. WTF?
@królik: java prędkością obliczeniową dorównuje C/C++. Wadą Javy w stosunku do kompilatorów jest duża zajętość RAMu, nie prędkość. Faktem jest, że język ma coraz mniejsze znaczenie, bo cały balast obliczeniowy zrzuca się na kartę grafiki, która ma moc obliczeniową przy niektórych algorytmach nawet kilkaset razy większą od nowych x86.
Pisanie engineu do gry w C++ tak, ale już pisanie samej gry nie koniecznie. Przykładem jest Unreal, gdzie sama gra jest napisana w UnrealScript, dedykowanym języku.
@Bananikus: a to że te nowe "zasobożerne" gry chodzą w rozdzielczościach oraz głębii kolorów rzędy wielkości więszych niż to co oferowały maszyny z tego okresu oraz stosowane efekty graficzne (na akceleratorze 3D praktycznie za darmo) to już drobny szczegół, prawda ?
Tylko czy ja porównywałem Worms Armageddon do Crysisa?
Miałem głównie na myśli to, że teraz wiele podobnych małych gierek ma wymagania 10x większe, choć od strony gameplayu nie różnią się niczym, albo nawet są gorsze.
Do tego wiele nowych gier na moim starym 7300GT działa tragicznie, a znowu inna gra z podobną lub nawet lepszą grafiką działa dobrze. Kiedyś nie było miejsca na źle zoptymalizowane gry.
Głębia kolorów czy rozdzielczość to akurat żaden argument. W te wormsy możesz zagrać w rozdzielczości 1280×1024 na takim sprzęcie. 🙂 Mój monitor nawet większej nie obsługuje, więc w crysisy gram na takiej rozdziałce i dobrze mi z tym. Głębia kolorów nie robi akurat żadnej różnicy. 🙂
Więc jak widać da się zrobić ładną grę nie zużywając wielu zasobów.
@vampire: np. to: http://www.freewebs.com/godaves/javabench_revisit…
Sam robiłem testy i w typowych obliczeniach matematycznych (np. silnia rekurencyjna, mnożenie macierzy), java 1.5 uruchomiona w trybie -server zawsze była szybsza od GCC =4.2 z -O2. Od GCC 4.2 jest optymalizacja PGO. Java jest szybka, ale program długo się uruchamia, bo VM kompiluje bytecode do kodu natywnego, co nazwane jest kompilacją JIT. Jak program się już uruchomi to jest szybki, ale sam proces uruchamiania może sprawiać wrażenie powolności. Ponadto wiele programów Javy startuje w trybie -client a nie -server, a w tym trybie VM kompiluje o wiele mniej bytecodeu do kodu natywnego.
Kiedys zrobilem niewielki test numeryczny i java przegrywala z kretesem. Ale to bylo dawno temu. Zobatrzmy jak to dzisiaj wyglada:
Kod benchmarkow: http://cryomicroscopy.org/java-test
Java (-Xms4G -server)
Exec time: 31.225 s
GCC (-O3 -mtune=native -march=native -msse2)
Exec time: 20.650 s
Test na notebooku Dell XPS M1330 z T9300 i 4 GB RAM
$ java -version
java version "1.6.0_0"
IcedTea6 1.4 (fedora-9.b14.fc10-x86_64) Runtime Environment (build 1.6.0_0-b14)
OpenJDK 64-Bit Server VM (build 14.0-b08, mixed mode)
$ gcc –version
gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Z gory mowie, ze nie programuje w Javie, wiec byc moze cos powinno byc zakodowane czy uruchamiane inaczej. Wszelkie poprawki mile widziane.
31s i 20s to nie jest jakaś ogromna różnica, porównaj to z językami interpretowanymi, typu python czy ruby, które są ponad 100 razy wolniejsze od GCC. To się nazywa powoli. Zresztą w GCC w wersji poniżej 4 dostał byś wynik gorszy niż Java, więc pomyśleć, że kiedyś wszystkie programy natywne były skompilowane w GCC gorzej niż w Javie to nie jest tak źle.
30 i 20 sec. to jest duza roznica. Oznacza to nic innego jak o polowe dluzszy czas wykonywania sie programu.
Co do starego GCC to latwo to mozna sprawdzic. Mam na tej maszynie i GCC z serii 3, ze wzgledu na stary kompilator fortrana (g77). Wersja z 2006 roku chyba jest dostatecznie stara?
Tak wiec nie jest problem zrobic test. Optymalizacje jak dla PentiumIV, poniewaz GCC 3 nie wie nic o Core2 Duo.
@Mieszko: to kompilator C++ napisany jest w assemblerze i dlatego generuje szybki kod? Java ma kompilator JIT i nawet gdyby ten kompilator był napisany w basicu, to mógłby generować kod, którego prędkość jest kompletnie niezależna od języka w jakim jest napisany.
@vampire: u mnie Twój test daje takie wyniki (zmniejszyłem ilość danych o rząd wielkości, bo nie mam 4GB RAMu):
java -server: 3,7
gxx -O3 -msse2: 3,1
Odpalone na OSX 10.4:
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin8
gcc version 4.0.1 (Apple Computer, Inc. build 5367)
o$ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-275)
Java HotSpot(TM) Client VM (build 1.5.0_16-132, mixed mode, sharing)
W tym teście gcc jest szybszy. Ale jak widać w linku jaki podesłałem nie zawsze gcc daje lepszy wynik niż skompilowana java w runtime przez JIT compiler.
A ja miałem S3 Trio/2D – 4MB – co ciekawe pod Windą 98 nie mogłem odpalić 1024x768x24bit bo wyświetlałą siłę kaszana po pierwszym przesunięcia okna. Za to pod Linuxem biegało OK.
tak, i zrazić firmę do linuksa…
głupio zrobili, że nie przemyśleli (pewnie marketingowcy) licencji, ale póki coś robią i nie wykorzystują cudzego kodu na gpl to przymknąłbym oko na tą ich pomyłkę
Żeby nam się rewolucja zrobiła i S3 wróciło do formy sprzed 10 lat. Przydałaby się jakaś konkurencja (choćby malutka) dla Nvidi/Amd, bo sytuacja teraz z kartami grafiki jest syfiasta.
Tak właśnie sobie patrzę na stronę S3 i widzę, że sterowniki dla Linuxa są tylko 32 bitowe. WTF?
Czyli rozumiem, że na 64 bitowych Linuxach możemy zapomnieć o sterach do kart S3 póki co?
S3 dało radę to niech teraz Ati się postara i wyda sterownik z prawdziwego zdarzenia z obsługą EXA, akceleracja video itd bo zaraz się okaże, że wszyscy już to mają w sterownikach tylko Ati nie… 😉
I bardzo dobrze, że wydało dokumentację, dzięki temu istnieje alternatywa w postaci sterowników open source, które w moim odczuciu działają lepiej niz Fglrx (używam KDE4). Niestety jest jedno ale.. obsluga TV-Out niespecjalnie chce działać, przynajmniej u mnie i tylko przez to korzystam dalej z Fglrx. A sam sterownika nie napiszę więc nie ma co narzekać tylko cieszyć się z tego co jest 😉 Pozdrawiam.
Brak sterownika dla architektury x86_64, OpenGL właściwie nie wiadomo czy 3.0 czy 2.1, współpraca z przerobionymi MPlayerem i ffmpeg, łatki do nałożenia na wersję MPlayera z 23 września 2008 i nie wysłane na listy developerskie projektów.
Dodatkowo przy opóźnieniach które już widzieliśmy należy zastanowić się jak szybko będą wydawać poprawione wersje współpracujące z najnowszym jądrem czy serwerem X.
Już odstawiając marzenia o otwartości kodu i dokumentacji oczywiście 🙂
Ehh, chciałem o tym napisać przy newsie p.t. "S3 Graphics kłamie w sprawie sterowników dla Linuksa". Dwa miesiące opóźnienia to nic przy takim projecie. Przykra sprawa, ponieważ S3 chce wydać driver na Linuksa, a w zamian jest kopany przez "społeczność". Miło by było gdyby autor notki na OS News zobaczył kto napisał na Phoronixie newsa i dla kogo ta osoba pracowała i pomyślał jaki to może miec wpływ na treść i obiektywizm newsów Phoronixa 🙂
@[r4]: Pewnie o to, ze w srodowiskach okololinuksowych sa firmy, ktore sie lubi, i sa firmy, ktorych sie nie lubi. I jest to kompletnie niezalezne od tego, co te firmy robia. Przykladowo – IBM pozywa kogos o lamanie patentow – srodowisko mowi "nudne, nastepny nius poprosze". Microsoft pozywa kogos o lamanie patentow – srodowisko mowi "AAA! RATUNKU, BIJA MNIE NIEMCY!!!". IBM oddaje spolecznosci troche bezuzytecznych, bo w wiekszosci nie dotyczacych oprogramowania, patentow – srodowisko mowi 'Alleluja!'. Sun oddaje spolecznosci troche istotnych patentow – srodowisko mowi 'e, co tak malo?'. IBM mowi, ze ma patent na RCU – srodowisko mowi 'meh'. Apple mowi, ze ma patent na multitouch – srodowisko wznosi larum. Intel zatrudnia dwoch doswiadczonych gosci do pisania sterownikow pod Linuksa, ktore zaczna sensownie dzialac moze w 2012 – srodowisko cieszy sie jak dzieci. nVidia konsekwentnie wypuszcza kolejny dzialajacy sterownik – srodowisko narzeka, ze zamkniety. I tak dalej, i tak dalej.
Obawiam sie, ze na tej wersji sterownika moze sie skonczyc, albo przynajmniej zagosci ona na stronie S3 przez nastepne pol roku. Szkoda bo nikt nie kupi karty co do ktorej wydawanie sterownikow jest bardzo watpliwe, poza tym dostepnosc nowych kart S3 w Polsce jest zerowa, szybko przeszukujac google nie znalazlem zadnego sklepu, ktory by ja sprzedawal. Szkoda podwojnie bo karty chyba godne uwagi, poprzednia wersja 440 wydajnosciowo byla niezla, przyklad tu.
![Awatar [r4]](https://secure.gravatar.com/avatar/9e0aad6a20465de5082ae0124e65c7c7?s=40&d=mm&r=g){kind=avatar}
Dodaj komentarz