Adramel i dalej nie rozumiesz
TCPMP nie jest zadnym miarodajnym testem !!!! Tu nie chodzi o to ze PXA sa wydajniejsze tylko o to ze znaczna czesc programow (starszych) jest cholernie mocno optymalizowana pod te procesory.
Naprawde przegladnij sobie kody zrodlowe to zrozumiesz o czym mowie ile tam jest kodu pod xscale pisane stricte w assemblerze aby dopalic program. Zapewne nie dotyczy to tylko TCPMP, wiec branie tego testu do porownywania procesorow jest po prostu smieszne...
Kiedys wlasnie o tym dyskutowalismy i nie wierzylem ze procesor moze byc az o tyle szybszy przy podobnym zegarze (bez optymalizacji pod dany procesor), padly testy w stylu TCPMP itd. jako dowody... no i to co juz tutaj powtarzam chyba setny raz sie potwierdzilo. Nie chodzi tez o driver do wyboru dla Xscale - bo poza nim jest optymalizacja w innych miejscach gdzie z automatu jest robiona detekcja procesora... Miedzy innymi wiele procedur ffmpeg jest przepisanych w assemblerze pod Xscale... No i na koniec dochodzi jeszcze samo ustawienie optymalizacji w kompilatorze, to juz takie na zakonczenie
Zreszta sam zauwazyles ile sam program wplywa na test (np. CorePlayer) - Samsung 800MHz bedzie szybszy od Qualcomma 528MHz nie ma tutaj sily bo to przewaga 270MHz (a to jest w cholere)... chodzi o to ze mowi sie o jakiejs cudownej nadprzyrodzonej wlasciwosci niektorych procesorow. A ta nadprzyrodzona super wydajnosc to wlasnie optymalizacja kodu pod dany procek i uzywanie specyficznych dla danego rdzenia instrukcji.
Co do wydajnosci obliczeniowej Qualcomm-a to skad masz informacje ze nie wyrobi, bo ja widze ze wyrabia z dekodowaniem po lekkiej optymalizacji, problem jest gdzie indziej - a konkretnie szybkie wyswietlenie duzego bufora (tutaj jest zaleta xcale czyli posiadanie instrukcji mmx sluzacych do szybkiego przesylania duzych blokow danych). Samsung narobi to troche zegarem czyli cyklami ktore mozna zmarnowac na wyswietlenie (ale i tak w wyzszych rozdzialkach nie starczy cykli aby pobic wolniejsze PXA ktora w jednym cyklu przesyla znacznie wiecej bajtow za pomaca mmx)... Do tego utrudnieniem sa wolno dzialajace w oryginale HTC sterowniki, o ile 3D zostalo jakos alternatywnie poprawione to DirectDraw jest dalej wolny jak mul...
Ale to mozna rozwiazac troche inaczej, znacznie wydajniej niz to w TCPMP zostalo zrobione dla innych procesorow (ot chocby uzywajac niektorych wlasciwosci ARMv6). Wiec jeszcze raz ta optymalizacja nie sprawi ze on pobije nagle procek 800MHz czy 1GHz
, ale bedzie dzialac znacznie szybciej niz do tej pory.
Odnosnie co potrafi naprawde QTV to trudno powiedziec bo qualcomm tego nie udostepnia i chce za to kupe kasy (za licencje), z tego co wiem nawet w HTC Album nie jest wykorzystane wszystko, narazie troche wiem ale jeszcze malo bo kodu do analizy jest sporo, czasu malo do tego z wieloma funkcjami trzeba eksperymentowac piszac kody testowy w C++ i patrzac co sie dzieje (w dodatku nie zawsze idzie odrazu wylapac zmiany).
Odnosnie ES2.0 to chodzulo mi o gierke "Electopia" ktora napisana jest pod OpenGL ES 2.0... (jako prezentacja mozliwosci Snapdragona)
Odnosnie testu d3dm to w zalczniku ot zwykle uzycie kilku funkcji (textura, swiatla, mgla) nic specjalnego - uzywalem do testowania zachowan sterownikow na HTC... Calosc napisana w C++ bez jakiejkolwiek optymalizacji.
P.S.
na koniec co do linku i testu "Również instalacja sterowników NeoS2007 Driver pack 3 nie poprawiła wydajności." - to zabija i swiadczy o pelnym profesjonalizmie... na stronach XDA wyraznie pisze co ten PACK robi i ze nie ma wplywu na 2D