Test wydajności grafiki dla siedmiu wersji WINE
- Dodano: 9 December 2007
- Wprowadził: michuk
- Komentarze: 23
Serwis Phoronix przeprowadził testy wydajnościowe siedmiu wersji WINE — implementacji API Windows dla systemów uniksowych. Przetestowano wersje 0.9.44, 0.9.45, 0.9.46, 0.9.47, 0.9.48 0.9.49 i 0.9.50 programu koncentrując się na wydajności grafiki na kartach 3DMark 2001 SE i 3DMark 2003.
Co ciekawe, mimo wielu ulepszeń dodanych do WINE między wersję 0.9.44 a 0.9.50 (w tym m.in. do obsługu OpenGL, Direct3D), testy nie wykazały progresu — wręcz przeciwnie, w niektórych testach (vertex shader, pixel shader) można zauważyć duży regres wydajności.
Zapraszam do zapoznania się z wynikami wszystkich testów (przedstawione są one za pomocą łatwych do odczytania wykresów). Zainteresowanym rozojem WINE polecam też śledzić RSS serwisu Phoronix, ponieważ w najbliższym czasie mają ukazać się kolejne testy wydajnościowe, koncentrujące się na innych aspektach działania tego nie-emulatora.
Więcej informacji: http://www.phoronix.com/scan.php?page=ar...=938&num=1
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
23 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Na wyniki trzeba patrzeć z przymrużeniem oka. Nie chciało mi się tego czytać i być może jest tam o tym wspomniane, ale jest taka drobnostka o której trzeba pamiętać.
Jeśli coś nie jest zaimplementowane to albo:
1)prog się nie odpala
2)wszystko działa i to znacznie szybciej bo shadery, albo kilka MB tekstur po prostu nie jest przesyłanych do GPU i nie trzeba tak dużo liczyć.(co najwyżej rzuci jakimś wyjątkiem, ale jeszcze nikt szczególnie nie cierpiał z tego powodu [chyba że to był windows i musiał klikać "nie wysyłaj"] ;p)
Dlatego starsze wersje wychodzą czasem lepiej w porównaniu.
Dokładnie… jak się Kozacy uruchamiali ileś wersji temu, tak teraz mamy do wyboru czarny albo biały ekran (zależnie od wybranego renderera DirectDraw). Ale w Crysisa pograć można…
1. Zgłosiłeś błąd do bugzilli Wine?
2. Dołączyłeś do niego wynik git-bisect (ze względu na liniowe repo Wine to jest bardzo proste) z łatką która psuje Kozaków?
Nie? Co czemu marudzisz, autorzy Wine mogą nie wiedzieć, że coś popsuli.
O ile mnie pamięć nie myli, błąd jest znany (przeczytałem o czarnym ekranie na appDB, miałem biały z racji innego renderera). Sprawdzenie kiedy to zepsuli może być dość ciężkie (brak wyświetlania to nie był jedyny problem tej gry). Teraz ta gra działa najlepiej, wcześniej były z nią dużo ciekawsze przepadki
Trzeba męczyć deweloperów, szczególnie jeśli chodzi o mniej popularny program. Nie ma letko.
Heh, niestety wine tak działa. Koncentrują się na tym żeby odpalać jak najnowsze gry i pochwalić się że "bajery 3D" działają na wine. Spróbujcie sobie na nowej wersji odpalić klasycznego StarCrafta – porażka. Moje dwa rdzenie nie wyrabiają z renderowaniem tej gry, jak by nie było 2D.
Twórcy tłumaczą się, że trzeba iść do przodu i z jakichś względów nie mogli zachować kompatybilności z DirectDraw, ale bez przesady… nie oszukujmy się, przecież to kwestia kilku if'ów…
Na bardzo starych wersjach wine gra śmigała, jednak żeby skompilować takie wine to i system (gcc, biblioteki…) trzeba mieć sprzed 2000 roku. A może wsadzić to w kolejny emulator?
Mogliby np. dodać pliki ze starszym kodem do najnowszych zródeł i podczas odpalania Wine dopisywało by się switch np: "-legacy" i wtedy WINE przeszukiwałby swoją lokalną baze bibliotek w celu odnalezenia najbardziej wydajnych/optymalnych/kompatybilnych z podanym *.exe. Po tej operacji odpalał by biblioteki *.so odpowiedzialne te starsze wersje dla zachowania lepszej wydajności.
Tak to widzę choć przyznaję, że nie jestem zaawansowanym koderem i mogę się mylić co do kwestii projektowych.
szczerze powiedziawszy dwa tyg. temu jak miałem jeszcze ubuntu 7.04 to miałem starcrafta i wszystko chodziło tylko kurcze wersji nie pamiętam ale to nie było zbyt stare. A mam semprona 2800 i wszystko płynnie chodziło
Dobrze, że moje wine (0.9.50) nie wie że starcraft powinien sie na nim ciąć i że twórcy nie zachowali kompatybilności z DDraw
Ale coś z tym zacinaniem się starszych, zdałoby się graficznie niewymagających wiele, gierek zacina się w winku, jak Settlers III, przez wiele, wiele wersji. Paradoksalnie u mnie z pomocą nie przyszło "nowe wine" a nowy scheduler – cfs, gra stała się grywalna, choć dalej zajmował 100% procka
A u mnie nie da się pograć ani w Starcrafta (grywalny ale "tnie"), ani w Warcraft II BNE (chyba ten sam silnik graficzny – podobne problemy), ani w (o zgrozo!) Fallouta 2 (który na Windos jest grywalny przy P90 i 16 MB ram). Powiecie "masz starego kompa"… prawda – ale bez przesady mój Duron 1200 + GeForce 5200 powinien w/w gry łykać… jak na ironię wiekszośc z tych gier była grywalna w pełnej predkości dopuki istniało wsparcie dla DGA (tanatos.pl – to własnie to odrzucono a nie DDraw). Teoretycznie teraz zamiast DGA można uzywać opengl (jak pogrzebie się w wirtualnym rejestrze) ale działą ono tylko z konkretnymi tytułami… i najczęściej nie daje tak dobrych efektów…
Na opisane powyżej kłopoty powinien pomóc nice: nice -+19 wine starcraft.exe itp.
to spróbuj sobie odpalić Alien vs Predator na DirectX 9. kiedyś się zagrywałem w to na celeronie 300 128MB i zintegrowanej 4megowej grafie ati, a teraz na 2.5GHz, radeonie i gigabajtach ramu mi się tnie. możeby panowe z redmond na początku trzymali kompatybilność wsteczną
Emulowane to emulowane. Kiedy ktoś wyjdzie z incjatywą implementacji natywnego linuxowego odpowiednika/zamiennika DirectX ? Nie byłoby lepiej ?
"odpowiednik/zamiennik" hmm… OpenGL ?
Yyyy, raczej SDL + OpenGL.
SDL jest taki wydajny i szybki ze ledwo co 2D daje sie z niego uzywalne wyciagnac.
Przynajmniej KVM z SDL chodzi koszmarnie w porownaniu z KVM + Rdesktop.
WINE to nie jest emulator. A implementacją DX zajmuje się Cedega.
Implementacją DX zajmuje się również WINE… podobnie jak Crossover… bo to wszystko służy z grubsza do tego samego…
DirectX to z grubsza rzecz biorąc zbiór bibliotek. A jako takie można spróbować zainstalować je pod Wine. I tu dochodzimy do:
Wine Review: DirectX 9.0c on Linux with Wine
Przyznam, że sam nie próbowałem ale pomysł ciekawy.
Eee, przecież Wine to właśnie natywny DX na Linuksie.
Bingo!