Autor: Vindex (Vindex_at_friko.onet.pl)
Data: Fri 11 Sep 1998 - 12:17:12 MET DST
Krzysztof Goworek napisał(a) w wiadomości:
<6taqdc$fuf$1_at_zeus.polsl.gliwice.pl>...
<ciach>
>>Wszelkiego typu transformacje wierzcholkow, przeliczenia bryl itp. Do
>>tego akurat SIMD nadaje sie bardzo dobrze.
>To jest geometria i tym powinno zajmowac sie API (i sie zajmuje).
Problem w tym ze tym akurat zajmuje sie czesc API wykonywana przez procesor.
A ona jest zoptymalizowana na konkretny typ procesora - tylko jeden albo
wogole nie jest optymalizowana. Dopoki procesory nie beda mialy wlasnych
niskopoziomowych driverow to i tak zadna optymalizacja nic tu nie da - a i
tak zawsze bedzie sie dalo zoptymalizowac lepiej kod programu (np. pod
wzgledem kolejnosci wykonywanych instrukcji). Optymalizacja API
dostosowanego do calosci sprzetu nigdy nie bedzie naprawde dobra
<ciach>
>Napisalem: zda to egzamin, jezeli bedzie dobre i optymalne API.
Ni ma mozliwosci stworzenia _naprawde_ optymalnego API dla tak szerokiej
gamy sprzetu.
Cos za cos - albo caly sprzet albo optymalnosc
<ciach>
>>Kompilator nigdy nie zapewni odpowiedniego poziomu optymalizacji -
>>chyba ze bedzie napisany pod konkretny typ aplikacji. Skoro
>>optymalizuje sie oprogramowanie pod konkretny procesor to widac warta
>>skorka wyprawki - efekty nie sa widac tak mizerne jak twierdzisz
>Zapewni - na najnizszym poziomie.
Nie zapewni - zaden kompilator ogolnego zastosowania nie jest w stanie
zapewnic _dobrej_ optymalizacji dla wszystkich zastosowan
> Dla programisty pozostaje napisac
>optymalnie na wyzszym poziomie. I Nie pisze tu o instrukcjach specjalnych -
3d.
>To nalezy do biblioteki.
Niespecjalnie - to zalezy od calosci. Kod wynikowy moze byc _w_miare_
optymalny
>>Owszem - tylko ze wtedy to API stanie sie nieoptymalne z zalozenia.
>>Sam wiesz ze im program wiekszy tym trudniej go dostosowac do
>>nietypowych zastosowan
>Ale jest jedno zastosowanie: grafika 3d.
Ale podejscie do tematu jest rozne - gdybys mial jeden procesor i jedna
karte graficzna to moglbys miec optymalne API. Teraz mamy tzw. zloty
srodek - sprzet dziala troche wolniej zle za to wygodniej sie go
oprogramowuje. Rozwiazania natywne beda zawsze szybsze od tych ogolnych
>>Zakladajac ze cos takiego da sie osiagnac - w wypadku innej filozofii
>>dzialania zastosowanej w procesorach moze to byc bardzo trudne. A
>>takie API nie bedzie w tym momencie optymalne dla zadnego procesora -
>>bedzie _dosc_ optymalne na obu
>Nie mowie o jednym kodzie dla kazdego procesora. Kazdy procesor powinien
miec
>swoj kod, wybierany na etapie instalacji.
A czemu instalacji a nie wykonania? Przy podejsciu modulowym nie osiagniesz
takiej optymalizacji kodu jak przy rozwiazaniach kompleksowych. Jak narazie
nie ma zadnego API umozliwiajacego to co chcialbys osiagnac. Niestety ...
>>Ano wlasnie - nieoptymalne. Trudno jest dostosowac API do wymagan
>>wszystkich programistow
>Mowimy o podstawowych operacjach. Na wektorach duzo sie wymyslic nie da.
Podstawowe
>przeksztalcenia (zoptymalizowane) + operacje na macierzach.
Zakladajac ze gra operuje wektorami - a niekoniecznie tak jest. Wymyslic
rowniez da sie duzo - chocby np. polaczyc wykonywanie pewnych operacji.
Nawet algebra potrafi sie zmienic
>>Troche pewnie by dalo - ale na zadne cuda bym nie liczyl. Sam widzisz
>>ze optymalizacja kodu a nie API daje wieksze mozliwosci. Nie jest to
>>moze najwygodniejsze dla programistow ale cos za cos ...
>Eehh.. Ty ciagle swoje... Wszystko zalezy od tego, czy program korzysta ze
wszystkich
>mozliwosci API, czy tylko na ostatnim, akcelerowanym etapie. Do tej pory
nie bylo sensu,
>jednak moze sie to zmieni.
OK - to pokaz mi w takim razie jakiekolwiek API _ogolnego_ zastosowania
ktore jest w stanie wykorzystac mozliwosci K6 2 - bo od niego ta rozmowa sie
zaczela. To wlasnie etap obrobki geometrii jest nieoptymalny - dopoki kazdy
procesor nie bedzie mial swojego sterownika niskopoziomowego to nie bedziesz
w stanie tego osiagnac
<ciach>
>He, znowu zero konkretow. Przygotowanie danych... Ladowanie z dysku ?
Juz o tym wczesniej pisalem - obrobka geometrii
>To co pisales wczesniej (przeksztalcenia bryl, itp.) powinno byc oparte o
API
>(znowu ten akronim, czy jak to sie tam zwie...).
Nie dogadamy sie - API nie ma tu zadnego znaczenia. Ten fragment ma byc
oparty na mozliwosciach procesora obrabiajacego dane - dopoki kazdy procesor
robi to w inny sposob to optymalizacja nie jest mozliwa na poziomie API
>>To nie jest kwestia napisania - skoro tak jest to znaczy ze lepsze
>>efekty uzyskali poprzez optymalizacje kodu niz przez optymalizacje
>>API/sterownikow.
>To wszystko, to tylko domysly. Poczekajmy az opublikuja zrodla Quaka1/2, to
sie
>przekonamy, jak jest naprawde... ;-)
Zrodla Quake'a sa juz od dawna dostepne (przynajmniej Q1) - nie wiem jak Ty
ale ja nie mam zdrowia zeby je analizowac :)
>Dodam tylko jedno: nie mowie, ze tak jest. Ale tak powinno byc, ze
programista
>aplikacji nie powinien optymalizowac kodu do procesora.
Owszem - dlatego napisalem ze to jest teoria. Do tego zeby powstalo
porzadne, spojne i dosc optymalne API wymagana jest wspolpraca wszystkich -
od programistow do projektantow sprzetu. Dopoki sprzet bedzie tworzony wg
wlasnego widzimisie to ogolne API nigdy nie dobrych wynikow
> To powinien zapewniac
>kompilator, biblioteki, system i Bog (wybacz) wie jeszcze co...
Ano wlasnie - mysle ze w koncu doszlismy do jakiegos konkretnego wniosku:
tak powinno byc :)
Mysle ze warto zakonczyc ten watek - teraz pozostaje nam tylko czysta
sofistyka
>| full name: Krzysztof Goworek, sex: male, occupation: developer |
Pozdrowienia
Vindex
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 17:36:10 MET DST