Sterowniki 3D

W załaczeniu ostatnie moje prace nad sterownikami 3D
Oto sterowniki dla grafiki 3D z kilku urządzeń
Sterownik EMONE - jest sterownikem dla Toshiby i Sharpa EMOne

Napisane: Sierpień 09, 2008, 13:58:33

---

Oraz program do testowania

Przydałby się jakiś pocket z prawdziwym sterownikiem do nvidii, bo ten to emulowane D3D niestety.

co daje ten sterownik?

właśnie co daje ten sterownik ?? moze uda sie uruchomic call of duty na procesorze samsunga

Tyle, że twój programik może wykorzystywać Direct3D ...

Bardziej chyba by się nam przydały jakieś stery do wbudowanego kodeka - filmiki miałyby dopalenie.

na wydajnosci w jakis grach zyskam cos?

Gry 3D potrzebują jakiegoś sposobu wyświetlania prymitywów graficznych - np trójkątów z naciąganiem tekstury, nakładaniem światła.
Można to zaimplementować w aplikacji i tak robiono kiedyś jak karty 3d nie były powszechne - przykład pierwszy quake. W komórach 3d hardwarowe cały czas nie jest standardem , więc tutaj jakby czas się (na chwile?) zatrzymał i z dopalaczy skorzystają tylko programy wykorzystujące specjalne API direct3d czy open gl. Programu. który z nich nie korzysta nie przyspieszy super karta nawet. Jednak emulowana biblioteka może często nie tylko nie przyspieszyć ale nawet zwolnić program w stosunku do wersji z wbudowanym enginem 3d. Powodem tego jest to ze ten wbudowany engine jest uproszczony w stosunku do specyfikacji np D3D...

hm, czyli prosciej mowiac momentami ten sterownik moze nawet spowolnic dzialanie?

Potestuj jak to działa na małym programiku z softwarową obsługą 3D

Nie do końca - powiedzmy mamy aplikację z wbudowanymi opcjami wyświetlania np
- Direct3D
- wbudowany engine

Jeśli wybierzemy D3D i drajwer jest autorstwa MS ( czyli emulowany ) to bedzie raczej wolniej chodzić niż gyby wybrać wbudowany.
Jeśli natomiast aplikacja/gierka była pisana tylko pod D3D to i tak nie ma wyboru
Napisane: Sierpień 09, 2008, 15:44:50

---

Ciekawe czy ten programik wykorzystuje D3D? Niestety to skompresowane PE i nie mam na kompie programu żeby wypruć prawdziwy programik z niego i oblukać listę importu PE. Tak na czuja wydaje mi się, że nie wykorzystuje.

No to może popracujesz nad driverem ?
W załączeniu driver M$

Na emulatorze odpaliłeś ten programik by uzyskać ostatni dump? Wygląda na to, że keiser ma referencyjny driver. Może tylko z niego coś wyrzucili - np jakiś format piksela dla tekstury czy powierzchni.

Można by spróbować zamienić oryginalny w tośce na ten referencyjny. Dopalenia sprzętowego nie będzie oczywiście ale ten wbudowany obsługuje tylko jeden format piksela - spakowany. To jest przekleństwo jak się na procu emuluje ten fromat. Najlepsze to 24 albo 32 bity z 8 bitami na kanał.

Tak to z emulatora

można by spróbować zamienić oryginalny w tośce na ten referencyjny. Dopalenia sprzętowego nie będzie oczywiście ale ten wbudowany obsługuje tylko jeden format piksela - spakowany. To jest przekleństwo jak się na procu emuluje ten fromat. Najlepsze to 24 albo 32 bity z 8 bitami na kanał.

Na prockach i386 owszem przeklenstwo, ale nie na RISCach takich jak XScale. Tutaj sa specjalne komendy szybko i latwo operujace na bitach i polach bitowych.

Bez używania przesunięć i masek?

Ma sie rozumiec To juz nawet 32-bitowa Motorola 68020 i pozniejsze mialy taki patent w standardzie.

Ok - mamy  x = R5G6B5, potrzebuję w xr, xg ,xb (32 bity wszystkie ) wpakować poszczególne kanały
Podrzuć asm-a w ARM  jak możesz.

Tak z marszu to Ci nie powiem, bo pod XScale nic nie robilem w ASM, ale mozesz sobie zerknac na wikipedie tam chyba byl dostepny zestaw instrukcji tej rodziny CPU.
Przede wszystkim te instrukcje zajmuja malo cykli procka.

No właśnie sobie przeglądam pdf-ik z jakiegoś uniwersytetu/szkółki amer. i w podstawowej architekturze nie widzę takich rozkazów. Zresztą całkiem zgodnie z filozofią RISC - prościutkie rozkazy, za to w zawrotnym tempie.

No właśnie sobie przeglądam pdf-ik z jakiegoś uniwersytetu/szkółki amer. i w podstawowej architekturze nie widzę takich rozkazów. Zresztą całkiem zgodnie z filozofią RISC - prościutkie rozkazy, za to w zawrotnym tempie.

Schodzimy juz nieco z glownego tematu, ale gwoli uzupelnienia - XScale czyli ARM5 nie jest bardzo typowa architektura RISC. Zreszta RISC wcale nie oznacza, ze instrukcje maja byc max proste, ale raczej maja sie przekladac na mniejsze zuzycie krzemu, czyli trazystorow. Wez pod uwage, ze w ARMach sa instrukcje typu "zaladuj rejestr wartoscia z innego rejestru jednoczesnie go przesuwajac o iles bitow", lub tez "wyczysc konkretne bity w rejestrze korzystajac z maski" -  to jest typowa implementacja pola bitowego. W i386 musialbys wykonac kilka niezaleznych instrukcji aby to osiagnac. XScale posiada tez instrukcje mnozenia, ktore w typowym RISCu sa wykonywane jako program dodajacy i przesuwajacy argumenty.

Nie traktuje tej prostoty w sposób dogmatyczny ale jak porównam do i386 to jest jednak prościej - rejestry nie są dzielone na podrejestry, nie ma operacji na pamięci tylko wszystko najpierw idzie do rejestrów przed operacją. A jeśli chodzi o operacje A= B<<c  to chyba zapomniałeś o LEA w intelu. Mam na myśli rozszerzenie LEA z ia32 oczywiście. Nie jest tak źle z intelem. Aha i porównaj sobie binarny format rozkazów - nie jest jednak prościej w ARM?

Trochę poszperałem w necie i wygląda na to, że ten referencyjny sterownik jest najwolniejszym z możliwych a ten, który mamy jest software-owy ale używa multimedialnych instrukcji procka toski - nie wszystkie ARM-y je mają.
Szkoda tylko, że nasza nvidia nie ma trybu R8G8B8.

Tutaj sa oryginalne pliki z wyputami d3dcaps:

http://66.102.9.104/translate_c?hl=en&sl=ja&tl=en&u=http://hp.vector.co.jp/authors/VA004474/wince/d3dmcapslist.html&usg=ALkJrhgsA8K3lPMG5c1SM8UbI2e_2P89cQ

Widac ze nadal tylko stary Dell Axim ma porzadne wsparcie D3D, a z nowosci jedynie Diamond.

Ja mam takie pytanie Troszku lamerskie no ale Jak to zainstalować? Rozumiem, że mam zainstalować caba, tylko jak mam te stery emone doinstalować? Przecież to zwykły tekstowy plik? Jeszcze pogrzebię, ale jak ktoś może to dajcie znać

Tu nie ma sterów tylko takie dyskusja co z czego by się dało przenieść. Na razie ze sterami do grafy po staremu.

Witam

Nie mam jeszcze toshiby, ale jest  w drodze zastanawia mnie jedna rzecz. Wiem, że XDA Flame też ma goforce 5500, ale działa na nim call of duty 2 z akceleracją sprzętową, wystarczy wywalić z katalogu z grą plik libgles_cm.dll i wtedy kożysta z libgles_cm.dll z katalogu /Windows, który w xda flame daje sprzętową akcelerację. Z tego co wiem w tośce tego pliku nie ma i dlatego nie działa
http://rapidshare.com/files/96694028/libGLES_CM.rar.html
to jest ten plik z xda flame, jakby ktoś chciał zaryzykować sam pobawię sie jak tylko listonosz przyniesie mi tośkę . Jeśli sie mylę to sprowadźcie mnie na ziemię zanim coś popsuje

Pozdrawiam

Zdaje sie, ze na myg900 juz ktos to testowal i chyba nie zadzialala podmiana tej biblioteki. Niewykluczone, ze Toshiba jakos zabezpieczyla sie sie przed tego typu patentami.

To tak nie dziala niestety. I nie chodzi tu nawet o zadne zabezpieczenia, ale o koniecznosc wiekszej ingerencji w system. Nie mozna od tak sobie wrzucic pliku i juz ma wszystko dzialac  Kazdy plik jest powiazany z innymi, z rejestrem i kupa innych rzeczy, moga tez wystepowac jakies odwolania sprzetowe w konkretnych dll'ach ktore powoduja skad inad bledy z uwagi na roznice w sprzecie... To naprawde nie jest takie latwe niestety.

Próbował ktoś z was zainstalować te sterowniki??
http://forum.xda-developers.com/showthread.php?t=416474
są to sterowniki z samsunga ominia z softwarowym D3D zoptymalizowane pox XScale. Nie mam jeszcze tośki, bede miał w weekend, ale jeden użytkownik pisał ze instalował, działają i pocketCM działało płynniej niz na oryginalnych. Na kaiserze w TCPMP wzrost wydajności ze 195% na 210%

Testy na trailerze Matrixa, tryb Direct Draw normalnie 95-100% po zainstalowaniu tych sterowników 96%. PocketCM nie używam, więc nie jestem w stanie sprawdzić czy jest poprawa.

Ja właśnie je zainstalowałem i według mnie czuć lekką poprawę przy PocketCM i odnoszę wrażenie że szybciej się obraca ekran przy rozsuwaniu klawiatury...

Sterowniki poniżej