Czytam różne mądre rzeczy, ale jakoś nie mogę dojść do ładu z taką kwestią: Jak wygląda wsparcie różnych używanych obecnie procesorów (na pecetach) dla instrukcji SIMD, takich jak MMX, 3DNow!, SSE, SSE2, SSE3, SSE4? Których z nich mogę swobodnie używać i założyć że każdy je ma, które muszę sprawdzać przez cpuid czy procesor je wspiera, a których w ogóle nie opłaca się stosować? Ciekaw jestem również jak to wygląda na procesorach 64-bitowych z kodem skompilowanym jako 32 bit a 64 bit.

Programuję w Visual C++ 2005/2008 dla platformy PC i na Windows XP.

żeby wiedzieć jaki procesor co wspiera, to zrób sobie takie porównanie np jak to http://www.komputronik.pl/porownanie,k_id,4819/ dla procesorów intela i amd i w odpowiedniej linijce zobaczysz jaki procesor jakie wspiera. Ale chyba można założyć Ze MMX SSE i SSE2 ma już każdy...


//EDIT o tak chyba wygląda pełne porównanie http://www.komputronik.pl/porownanie,k_id,46/ SSE3 i SSE4 to juz chyba tez prawie standard

Na wikipedii przy hasałach SSE2, SSE3 itp. jest podane jakie procesory mają obsługę tych technologii. SSE2 wydaje się już wystarczająco powszechne ;) (chociaż brak go w Athlonach z czasów przed 64-bit)

To zależy do czego chcesz użyć SSE :) Są 3 stopnie twojego kodu:
1. Jest tak szybki i mało wymagający że nie potrzebuje SSE i pójdzie na wszystkim.
2. Jest średnio szybki/wolny, proste 3D, większość procesorów mu da rade. Wystarczy mu PIV oraz AMD Athlon. Możesz użyć SSE/SSE2.
3. Jest bardzo wolny. Zaawansowane 3D z dużą ilością obliczeń 3D (cienie, kolizje itd). Wymaga co najmniej Core2, Phenom, Athlon X2. Możesz użyć SSE4.

Ogólnie SSE4 jest najbardziej porzytecznym zestawem. Ma dot, blend. 2 rzeczy o których można powiedzieć "about f... time".
Dot się przydaje przy mnożeniu macierzy, iloczynów wektorowych, liczeniu odległości itd. Blend jest przydatny przy operacjach na AABB, wyznaczaniu widoczności, kolizji itd. Wcześniej trzeba to było robić na około, kilkoma instrukcjami.

Cytat:

3. Jest bardzo wolny. Zaawansowane 3D z dużą ilością obliczeń 3D (cienie, kolizje itd). Wymaga co najmniej Core2, Phenom, Athlon X2. Możesz użyć SSE4.

Nie do końca zgadza się Core 2 ;] - procesory na jądrach Allendale (Core 2 Duo E4x00), Conroe (Core 2 Duo E6xx0), Conroe XE (Core 2 Extreme X6800), Kentsfield (Core 2 Quad Q6x00), Kentsfield XE (Core 2 Extreme QX6xx0), Merom* (większość mobilnych core 2) obsługują sse w wersji max 3. Z athlon x2 to chyba jeszcze gorzej trafiłeś (jeśli się mylę proszę o poprawienie), bo z tego co mi wiadomo to tylko Regor i Kuma (czyli tak naprawdę to nie seria Athlon 64 x2 tylko Phenom) i procesorów na tych jądrach jest 3.
Na rynku jest jeszcze za mało procesorów z obsługą sse4 (core i7, mała część z core2 (te droższe, a intele się kupuje tanie i kręci), phenom).

Większość C2D ma SSE3 i SSSE3. SSE4 i SSE4.1 brak.
Jeśli chodzi o starsze to niektóre Semprony nie miały jeszcze SSE2.
CPUID prawdę Ci powie...  ;D

Cytat:

Z athlon x2 to chyba jeszcze gorzej trafiłeś (jeśli się mylę proszę o poprawienie), bo z tego co mi wiadomo to tylko Regor i Kuma (czyli tak naprawdę to nie seria Athlon 64 x2 tylko Phenom) i procesorów na tych jądrach jest 3.
Na rynku jest jeszcze za mało procesorów z obsługą sse4 (core i7, mała część z core2 (te droższe, a intele się kupuje tanie i kręci), phenom).

Co do AMD: Nieprawda ;) SSE3 jest w Athlonach64 od rdzenia Venice/San Diego ( czyli jednordzeniowe )
http://en.wikipedia.org/wiki/List_of_AMD_Athlon_64_microprocessors#.22Venice.22_.28E3_.26_E6.2C_90_nm.29

Niestety SSE2 w Athlonach XP ( sprzed 64bit ) nie ma.

No tak, SSE4 jest dopiero od penryna... Generalnie chodziło mi o to że nie ma sensu robić kod dla kilku wersji SSE. Do prostych gierek można się obyć bez SSE. W bardziej zaawansowanych obliczeniach SSE wystarczy. SSE2/SSE3 mają zestawy instrukcji zupełnie od czapy i nie warte zachodu/ryzykowania że gdzieś nie pójdzie.

Esidar i inni: Dzięki za odpowiedzi.

Czy mogę założyć, że MMX, SSE, SSE2 ma każdy współczesny gracz?

MSDN wspomina, że MMX i wszystkie instrukcje SSE które używają typu __m64 nie są wspierane na procesorach x64. Jak to rozumieć? One mi się nie skompilują jeśli będę chciał pisać 64-bitowy kod, czy te nowe 64-bitowe procesory w ogóle nie wspierają MMX?

Cytat:

Czy mogę założyć, że MMX, SSE, SSE2 ma każdy współczesny gracz?

Tak. Możesz założyć, bo dośc spora liczba gier wykorzystuje te technologie. Możesz jednak napisać także kod, który nie będzie wykorzystywał tych intrukcji. Pisanie czegoś 2 razy to podwójna ilośc roboty, jednak masz pewność, że więcej osób zobaczy Twój program u siebie. Polecam funkcję IsProcessorFeaturePresent z Winapi. Ona wykrywa obecność różnych ficzerów CPU.

Cytat:

MSDN wspomina, że MMX i wszystkie instrukcje SSE które używają typu __m64 nie są wspierane na procesorach x64. Jak to rozumieć? One mi się nie skompilują jeśli będę chciał pisać 64-bitowy kod, czy te nowe 64-bitowe procesory w ogóle nie wspierają MMX?

Hmm... Nowe procesory na pewno wspierają SSE, a co za tym idzie MMX. Przyznam, mając procesor 64 bitowy (system jednak 32) nie miałem probmlemów z danymi wyrównanymi do 8 bajtów.
Ogólnie, polecam zamówić materiały od intela, które sa dostępne za darmo.
[spam]http://bsmechanik.blogspot.com/2008/08/tajemnica-intela.html[/spam]
:)

Cytat:

Czy mogę założyć, że MMX, SSE, SSE2 ma każdy współczesny gracz?

Jeśli procek nie będzie obciążany jakoś nadmiernie lepiej użyć sse bo np. athlony xp (w polsce nadal spotkać takiego to nie problem) nie mają sse2 - jak gra wyrobi się na takich prockach to szkoda podwyższać wymagania niepotrzebnie ;].

@vashpan: a w którym miejscu napisałem coś o sse3?

Poza tym, nie polecam MMX. Instrukcje SIMD dla MMX nie wykorzystauja oddzielnych rejestrów (tak jak w przypadku SSE - xmm0...xmm7), tylko operuja na 64 bitowych aliasach rejestrów... FPU. Więc za każdym razem, trzeba przełączyć kontekst FPU, co jak wiadomo jest operacja dość kosztowną.
SSE jest krokiem na przód, zas od SSE2 mamy możliwośc operacji na intach.
Trudnością, moga być operacje "w poziomie" (nie ma bezpośredniej możliwości dodania wszystkich danych w jednym rejstrze) jednak i na to są sposoby ;)

//EDIT:
Mam pytanie:
czy to, ze dana operacja jest wykonywana w jedej instrukcji (np. dot w nowych SSE), oznacza, ze jest na nia przeznaczony jeden cykl? Czy jakas operacja moze wykonywac sie dluzej, niz jeden cykl?

Cytat:

Mam pytanie:
czy to, ze dana operacja jest wykonywana w jedej instrukcji (np. dot w nowych SSE), oznacza, ze jest na nia przeznaczony jeden cykl? Czy jakas operacja moze wykonywac sie dluzej, niz jeden cykl?

Niektóre operacje wykonują się kilka inne kilkanaście cykli i to jest też jeszcze zależne od procesora, na jednych instrukcja wykonuje się krócej na innych dłużej i odwrotnie.
Tak było na przykład w procesorach P4, gdzie wiele instrukcji wykonywało się znacznie dłużej niż na PIII i mimo znacznie wyższego taktowania w wielu zastosowaniach były dużo wolniejsze (np. łamanie haseł).
Współczesne procki wykonują większość instrukcji w jednym cyklu.

Bardzo fajny temat, więc od razu rzucę pytaniem i moim wnioskiem.

Otóż czy funkcje macierzowe i wektorowe biblioteki D3DX9 są zoptymalizowane pod tym względem?
Z tego co ja wyczytałem to nie, ponieważ funkcja (D3DXCpuOptimizations)  która uruchamia te optymalizacje jest pod DX10.

Inne pytanie:
Jak zaimplementować coś takiego na wektorach, czy podejmować decyzję podczas kompilacji, czy w czasie działania programu?
W tym ostatnim najprawdopodobniej by to wykorzystywało wskaźniki na funkcje, co daje najprawdopodobniej narzut dereferencji wskaźnika.

Cytat:

Cytat:

Czy mogę założyć, że MMX, SSE, SSE2 ma każdy współczesny gracz?

Jeśli procek nie będzie obciążany jakoś nadmiernie lepiej użyć sse bo np. athlony xp (w polsce nadal spotkać takiego to nie problem) nie mają sse2 - jak gra wyrobi się na takich prockach to szkoda podwyższać wymagania niepotrzebnie ;].

@vashpan: a w którym miejscu napisałem coś o sse3?

Hmm

Cytat:

Nie do końca zgadza się Core 2 ;] - procesory na jądrach Allendale (Core 2 Duo E4x00), Conroe (Core 2 Duo E6xx0), Conroe XE (Core 2 Extreme X6800), Kentsfield (Core 2 Quad Q6x00), Kentsfield XE (Core 2 Extreme QX6xx0), Merom* (większość mobilnych core 2) obsługują sse w wersji max 3. Z athlon x2 to chyba jeszcze gorzej trafiłeś (jeśli się mylę proszę o poprawienie), bo z tego co mi wiadomo to tylko Regor i Kuma (czyli tak naprawdę to nie seria Athlon 64 x2 tylko Phenom) i procesorów na tych jądrach jest 3.

Ale cos mi sie wydaje ze jednak nie bardzo zrozumialem to co napisales... Troche to chaotyczne napisane musisz przyznac ;)

Też myślę, że nie ma sensu wstawiać do każdej funkcji if-a, który sprawdza, czy procesor zwróćił że ma wsparcie dla SSE czy nie i wykonuje jedną lub drugą wersję. Ja bym raczej użył na stałe MMX+SSE1, ewentulnie SSE2.

Natomiast naszła mnie teraz taka refleksja, czy można bibliotekę matematyczną (klasa wektor, macierz itd.) przerobić na SSE. Problematyczne wydaje mi się wymagane dla typów __m64 i __m128 wyrównanie odpowiednio do 8 i do 16 bajtów. O ile zmienne tych typów definiowane na stosie albo alokowane na stercie same się wyrównują, o tyle zastanawiam się co będzie na przykład podczas odczytywania i zapisywania takich wektorów jako części strumienia danych binarnych gdzieś do pliku.