mateusz.semegen::devblog

OpenGL + Shadery

noreply@blogger.com (msemegen) — Mon, 15 Jul 2013 08:42:00 +0000

W tej części kursu dotyczącego malowania w OpenGL , dodamy nieco życia do naszej nudnej sceny a także zapoznamy się z programowalnym potokiem renderowania. Zatem do dzieła.

Shadery!

Shader to niewielki program uruchamiany na karcie graficznej. W naszym przypadku (staramy się trzymać kompatybilność z OpenGL ES 2.0) rozróżniamy dwa rodzaje shaderów: Vertex i Fragment.

Vertex shader jest wykonywany dla każdego wierzchołka przekazywanej geometrii. Odpowiada on za liczenie pozycji wierzchołka, najczęściej na podstawie macierzy (projekcji, modelu lub widoku) oraz jego początkowej pozycji. Może on wykonać także dodatkowe operacje, których wyniki mogą być używane w późniejszych fazach potoku renderowania. Zadaniem fragment shadera zaś, jest obliczenie końcowego koloru piksela. To w nim implementowane jest teksturowanie lub oświetlenie per-pixel.

Do pisania shaderów będziemy używać języka GLSL. Jest on bardzo podobny do C, pomijając kilka różnic. Przede wszystkim mamy do dyspozycji nowe typy: wektory i macierze wraz z pełną paletą wbudowanych funkcji. Dodatkowo, dodanych zostało kilka modyfikatorów, które zostaną omówione w dalszej części kursu.

Z poziomu GLSL nie mamy dostępu do wskaźników. Pętle muszą być rozwijalne na etapie kompilacji a długość programu jest ograniczona dostępnymi zasobami sprzętowymi. Widać zatem, że mamy do czynienia z językiem bardziej restrykcyjnym i przeznaczonym dla wyspecjalizowanych celów.

Modyfikatory

Nowe typy modyfikatorów to uniform, attribute oraz varying. Uniform jest to globalna (dla pojedynczego shadera) stała, której wartość została przekazana z zewnątrz. Dzięki tego typu konstrukcji, możemy przekazywać do shadera wcześniej wyliczone wartości dotyczące położenia kamery czy transformacji widoku. Atrybut (attribute) bezpośrednio odnosi się do wierzchołka. Jest to przekazywana dla każdego wierzchołka właściwość, np. położenie, kolor, normalna czy pozycja tekstury. Na samym końcu mamy varying. Tym modyfikatorem oznaczamy zmienne, które chcemy przekazać z Vertex shadera do Fragment shadera.

Hello world

Czas więc osobiście zapoznać się z naszymi shaderami. Na pierwszy ogień pójdzie Vertex shader:

attribute vec4 attrPosition;
attribute vec4 attrColor;
 
uniform mat4 unfModel;
uniform mat4 unfProjection;
 
varying vec3 vygColor;
 
void main()

{
 gl_Position = unfProjection * unfModel * attrPosition;
 vygColor = attrColor.rgb;
}

Jak więc widać, jest to niewielki program, wykonujący podstawowe opracje. Pierwsza rzaczą, która z pewnością rzuca się w oczy to obecność funkcji main. Jej przeznaczenie jest oczywiste - punkt wejściowy shadera. Kolejnym interesującym zjawiskiem jest gl_Position. Jak widać, jest to zmienna. Nie jest jednak nigdzie zadeklarowana a mimo wszystko jest używana. GLSL posiada zestaw wbudowanych zmiennych, do których można zapisywać dane będące użyte w kolejnych etapach renderowania. Jedną z nich jest właśnie gl_Position. Mamy do niej dostęp tylko z poziomu Vertex shadera.

Uniformami są tutaj macierze 4x4 (mat4) unfModel raz unfProjection. Wartości ich zostały wyliczone w programie głównym, zaś tu zostały tylko przekazane i wykorzystane do wyliczenia końcowej pozycji wierzchołka. Warto tutaj zaznaczyć, że nie możemy tworzyć uniformów zaczynających się prefiksem gl_.

Jako, że na nasz wierzchołek składa się tylko pozycja i kolor, takie też atrybuty przekazujemy do shadera (attrPosition oraz attrColor). Tutaj jednak pojawia się problem. Dostęp do atrybutów mamy tylko z poziomu vertex shadera, zaś w nim nie możemy pomalować piksela, przekazanym w atrybucie kolorem. Musimy zatem przekazać kolor do fragment shadera, w którym to zostanie on odpowiednio wykorzystany. Z pomocą przychodzi tu zmienna vygColor, która została oznaczona wcześniej wspomnianym modyfikatorem varying.

Na sam koniec zostało wyliczenie końcowej pozycji wierzchołka na ekranie. Jak widać jest to iloczyn macierzy projekcji, modelu (macierz będąca wynikiem wszystkich podstawowych transformacji na obiekcie) oraz początkowego położenia wierzchołka. Jak pamiętamy z podstawówki, lub co ambitniejszych przedszkoli, mnożenie macierzy nie jest przemienne, więc musimy zachować prezentowaną tu kolejność.

Fragment shader jest znacznie krótszy:

varying vec3 vygColor;
 
void main()
{
 gl_FragColor = vec4(vygColor.r, vygColor.g, vygColor.b, 1.0);
}

Mamy tu tylko przekazany z poprzedniego shadera kolor wierzchołka oraz przypisanie go do wyjściowej zmiennej gl_FragColor.

Tymczasem w C++...

Mając gotowe shadery, możemy zająć się ich kompilacją. Ciekawostką jest to, że będziemy to robić z poziomu naszego programu głównego, w trakcie inizjalizacji. Wykorzystamy do tego niewielką funkcję:

bool compileShader(GLuint *pOutShader, const char *szSource, ShaderType type)
{
 *pOutShader = glCreateShader(type);
 
 glShaderSource(*pOutShader, 1, &szSource, NULL);
 glCompileShader(*pOutShader);
 
 GLint iCompileStatus = GL_FALSE;
 glGetShaderiv(*pOutShader, GL_COMPILE_STATUS, &iCompileStatus);
 return iCompileStatus == GL_TRUE;

}

Skupimy się tu przede wszystkim na API OpenGL. Na początek tworzymy obiekt shadera, za pomocą funkcji glCreateShader. Przyjmuje ona typ shadera: GL_VERTEX_SHADER lub GL_FRAGMENT_SHADER. Następnie kojarzymy dany obiekt z konkretnym kodem źródłowym za pomocą glShaderSource. Funkcja ta przyjmuje tablicę cstringów, której rozmiar określa drugi parametr (w naszym przypadku 1) . Jeśli każdy przekazany tekst kończy się zerem (czyli jest standardowym cstringiem), możemy ustawić ostatni parametr na NULL.W przeciwnym razie, musimy przekazać długość każdego z podczepianych źródeł. Jesteśmy zatem gotowi do kompilacji, która następuje po wywołaniu glCompileShader. Status kompilacji możemy pobrać korzystając z funkcji glGetShaderiv do której przekazać trzeba obiekt właśnie kompilowanego shadera (*pOutShader), oraz wskaźnik na zmienną która przechowa sam status (iCompileStatus - GL_TRUE dla sukcesu oraz GL_FALSE dla porażki).

Mając skompilowane shadery, możemy je zlinkować w jeden program:

bool linkProgram(GLuint *pOutProgram, GLuint uVertexShader, GLuint uFragmentShader)
{
 *pOutProgram = glCreateProgram();
 glAttachShader(*pOutProgram, uVertexShader);
 glAttachShader(*pOutProgram, uFragmentShader);
 
 glLinkProgram(*pOutProgram);
 
 GLint iLinkStatus = GL_FALSE;
 glGetProgramiv(*pOutProgram, GL_LINK_STATUS, &iLinkStatus);
 
 return iLinkStatus == GL_TRUE;
}

Po stworzeniu obiektu programu za pomocą glCreateProgram dołączamy za pomocą glAttachShader wcześniej skompilowane shadery. Teraz zostaje nam już tylko zlinkować program (glLinkProgram) oraz sprawdzić za pomocą glGetProgramiv wynik owej operacji.

Jesteśmy już o krok od namalowania naszego upragnionego kwadracika. Zostało nam jeszcze tylko pobranie informacji o położeniu atrybutów oraz uniformów. Zrobi to dla nas poniższy kod:

glBindAttribLocation(uProgram, 0, "attrPosition");
glBindAttribLocation(uProgram, 1, "attrColor");
 
iProjectionUniform = glGetUniformLocation(uProgram, "unfProjection");
iModelUniform = glGetUniformLocation(uProgram, "unfModel");

Warto zwrócić uwagę, że atrybutowi przypisujemy ID po jego nazwie w shaderze (glBindAttribLocation), zaś ID uniformu jest pobierane (glGetUniformLocation), także na podstawie nazwy, którą nadaliśmy mu w kodzie shadera. Tym akcentem kończymy incjalizację aplikacji. Możemy zająć się pętlą główną.

Malowanie

W pętli głównej możemy zobaczyć taki oto kawałek kodu:

glUseProgram(uProgram);
glUniformMatrix4fv(iProjectionUniform, 1, GL_FALSE, (float*)&(projection[0]));
glUniformMatrix4fv(iModelUniform, 1, GL_FALSE, (float*)&(model[0]));
 
glEnableVertexAttribArray(0);
glEnableVertexAttribArray(1);
 
glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, sizeof(Vertex), vertices);
glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (float*)(vertices) + 4);
 
glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_SHORT, faces);
 
glDisableVertexAttribArray(0);
glDisableVertexAttribArray(1);
 
glUseProgram(0);

Pierwszą funkcją, na którą powinniśmy zwrócić uwagę to glUseProgram. Jako parametr podajemy jej obiekt wcześniej zlinkowanego programu. Od tej chwili wszystkie operacje, dotyczące shadera, będą dokonywały się właśnie na owym programie.

Mając ustawiony program, możemy przekazać shaderowi macierze projekcji oraz modelu. Robimy to za pomocą funkcji glUniformMatrix4fv. Warto zaznaczyć, że jest to tylko jeden z wielu członków rodziny funkcji glUniform*. W zależności od typu przyjmowanych parametrów, przesyłają one do shadera różne typy danych. W naszym przypadku, dla uniformu o ID iProjectionUniform, przekazujemy jedną (parametr drugi określa ilość), nietransponowaną (GL_FALSE) macierz 4x4 - projection. Analogicznie wygląda to dla macierzy modelu.

Następnie informujemy OpenGL z jakich atrybutów wierzchołka będziemy korzystać (glEnableVertexAttribArray). Będzie to oczywiście pozycja (0) oraz kolor (1), których odpowiednie ID zostały przypisane za pomocą glBindAttribLocation.

Przyjrzyjmy się jeszcze, jak wygląda nasz wierzchołek:

struct ColorRGB
{
 float r, g, b;
};
 
struct Vertex
{
 vec4 position;
 ColorRGB color;
};

Jak widać składa się on z pozycji, która jest czteroelementowym wektorem oraz koloru, który jest wyrażonymi składowymi R, G i B. Podstawowy typ danych to float. Informacje te, są niezbędne w następnym kroku:

glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, sizeof(Vertex), vertices);
glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (float*)(vertices) + 4);

Przekazujemy tutaj informacje o dokładnym położeniu każdego atrybutu w naszej strukturze wierzchołka. Idąc od lewej pierwszy parametr to ID atrybutu. Drugi określa liczbę komponentów, z jakich składa się atrybut. Pozycja jest przedstawiana za pomocą współrzędnych X, Y, Z oraz W (4), zaś kolor ma składowe R, G, B (3). Kolejny parametr to typ danych - w naszym przypadku to float. Przekazywane dane nie są znormalizowane, więc czwarty parametr ustawiany jest na wartość GL_FALSE. Jako, że wierzchołki wraz z atrybutami będą składowane w tablicy, musimy określić odległość (w bajtach) od odpowiadających sobie atrybutów - będzie to po prostu rozmiar struktury wierzchołka. Ostatni parametr to wskaźnik na pierwszy atrybut. W przypadku pozycji, będzie to po prostu adres pierwszego elementu tablicy, zaś pozycja koloru jest przesunięta o cztery zmienne typu float, ponieważ znajduje się za pozycją. Myślę, że na poniższym rysunku obok jest to przedstawione w bardziej czytelny sposób. Zostało zatem zawołanie funkcji glDrawElements, ale nie różni się ona niczym w porównaniu do poprzedniej części kursu.

Został nam do omówienia jeszcze jeden aspekt - samo budowanie macierzy widoku i modelu. Wykorzystałem do tego bibliotekę GLM. Jest ona bardzo prosta i przyjemna w użyciu, także myślę, że nie istnieje tutaj potrzeba dokładnego omawiania kilku operacji które zostały wykonane za jej pomocą.

Źródła można pobrać tu.

Macalna sciana

noreply@blogger.com (msemegen) — Fri, 12 Jul 2013 14:42:00 +0000

Dziś czas na kolejną, małą prezentację. Jak zwykle będzie ona związana z technologiami około Kinectowymi, które wypełniają aktualnie cały mój czas. Tym razem jednak, nie będzie ona dotyczyła typowego rozwiązania, opartego na gestach i machaniu rękami. Będzie to coś bardziej tradycyjnego - powierzchnia dotykowa, a dokładniej rzecz ujmując: zwykła ściana.

Jak zatem zmienić ścianę w obiekt reagujący na macanie? Wystarczy w zasadzie sensor głębi (zalecany jest tu jednak Asus Xtion Pro) oraz odrobinę softu. Samo stworzenie tej wersji oprogramowania zajęło miesiąc i jest to jego dość wczesna wersja, co doskonale widać na poniższym filmie. Po zapewnieniu odpowiednich warunków, możemy delektować się jednak nieograniczoną radością z zabijania świń wypuszczanymi z procy ptakami, na każdej ścianie przed którą możemy postawić Kinecta.

Nowy Kinect

noreply@blogger.com (msemegen) — Wed, 22 May 2013 20:32:00 +0000

Jest! W końcu! Po trzech latach od prezentacji pierwszej generacji czujnika głębi sygnowanego logiem Microsoftu, wczoraj mieliśmy okazję zobaczyć jego następcę. Podczas trwania konferencji nie usłyszeliśmy o nim zbyt wiele, pomijając niewielki fragment podczas którego podziwialiśmy czułość na gesty oraz możliwości rozpoznawania mowy. O ile ta ostatnia funkcjonalność nie robi już dziś dużego wrażenia (mamy przecież Google Now czy Siri od Apple) to rozpoznawanie ruchów ręki czy dłoni, ciągle wydaje się możliwością zakrawającą of Science Fiction.

Dziś w sieci ukazał się krótki film, na którym mogliśmy trochę bliżej poznać nowy kontroler do nadchodzącej konsoli Xbox. Zostało ujawnionych znacznie więcej szczegółów dotyczących działania urządzenia. Przede wszystkim została zmieniona technologia "widzenia" głębi. W aktualnej generacji wykorzystywany jest promiennik podczerwieni rzucający siatkę punktów, która po odpowiedniej analizie daje nam stosunkowo dokładne informacje o położeniu w przestrzeni trójwymiarowej. Jak już wspominałem we wcześniejszej notce zostało to opracowane przez PrimeSense. Tym razem Microsoft postanowił uniezależnić się od zewnętrznych instytucji i... przejął dwie mniejsze firmy zajmujące się tworzeniem sensorów 3D. W tym wypadku postawiono na technologię o nazwie Time of Light. W wielkim skrócie i uproszczeniu, mamy tutaj do czynienia z kamerą która potrafi mierzyć prędkość odbitego światła od poszczególnych obiektów sceny. Brzmi niesamowicie, ale jest to stosunkowo stara metoda wykorzystywana w dalmierzach laserowych. Tutaj jednak równocześnie dokonujemy pomiaru dla całej macierzy punktów. Warto zaznaczyć, że pierwsze tego typu kamery pojawiły na rynku się już w 2006 roku. Gdzie jest zatem postęp, którym tak bardzo chwali się Microsoft? Rozdzielczość. Nie ujawniono jeszcze dokładnej ilości odczytywanych pikseli, jednak już na pierwszej prezentacji można zauważyć, że poczyniono w tym zakresie znaczny progres. Przedstawiciel korporacji mówił o rozdzielczości HD, jednak myślę, że podobnie jak w pierwszej wersji sensora, siatka punktów została reskalowana by dopasować się do kamery RGB. Dodatkowo dzięki tej technologii kamera znacznie lepiej radzi sobie z obiektami położonymi blisko - nie ma już efektu "oślepienia" czujnika podczerwieni.

Rendering głębi

Z interesujących rzeczy, to w zasadzie tyle. Pewnie wiele osób zauważyło, że zostało zaprezentowanych jeszcze kilka innych możliwości: badanie obciążenia poszczególnych kości szkieletu czy mierzenie siły uderzenia. Przyznam jednak, że (o ile nie dostaliśmy tego w zestawie z API) jesteśmy w stanie to osiągnąć korzystając z obecnej generacji sprzętu. Jedynym usprawnieniem na jakie zwróciłem uwagę to zwiększona ilość kości, dla wykrywanego szkieletu. Dalej jendak nie ma tu rewolucji - ręka zyskała drugi palec, zaś barki dodatkowe jointy. Obsługa gestów także nie została specjalnie usprawniona. "Pinch to zoom" w wersji dla XBoksa jest wykonalny (dość łatwo) już dziś, zaś "Swipe left / right" działa tak samo, jak dla aktualnej generacji (swoją drogą, reimplementując obsługę tego gestu można uzyskać znacznie lepsze wyniki, czego prototyp pokazałem tu). Zaprezentowane na koniec wykrywanie tętna gracza wydaje mi się mocno naciągane, jednak będę musiał dokładniej poznać temat by wyrobić sobie o nim zdanie. Czy to koniec narzekania? Jeszcze nie. Rzeczą która najbardziej mnie zawiodła, to ciągle słaba dokładność śledzenia szkieletu. Nie uczyniono tutaj zbyt dużego postępu, zaś demko pokazywane przez PrimeSense ponad dwa lata temu, prezentuje się w tej materii znacznie lepiej (swoja drogą nigdy nie udało mi się uzyskać tak rewelacyjnych wyników jak na owym filmiku).

Czy jest zatem na co czekać? Moim zdaniem tak. Myślę, że do końca roku Microsoft dopracuje API oraz sterownik i część przedstawionych tu bolączek zostanie zlikwidowana. Liczę także, że konkurencja pokaże nowe wersje swoich rozwiązań. O ile PrimeSense dość mocno interesuje się rynkiem mobilnym (kto nie chciałby Kinecta w telefonie?) to zwiększenie dokładności stacjonarnych wersji urządzeń, też powinno leżeć w ich interesie. Zagadką pozostaje także dostępność nowego Kinecta w wersji dla PC. Na kompatybilność z OpenNI, chyba nie mamy co liczyć.

COTW - Pola i flagi bitowe w C++

noreply@blogger.com (Unknown) — Wed, 24 Apr 2013 11:37:00 +0000

Każdy pewnie korzystał z flag bitowych w C/C++. Wygodne i zgrabne narzędzie do przekazywania parametrów, które szczególnie ukochali sobie programiści Microsoftu projektujący WinApi.
Czasem zdarza się jednak, że przekazane kombinacje mogą być bardzo finezyjne, a parametry dla instrukcji warunkowych niekoniecznie muszą mieścić się na jednym ekranie (nazwy flag często są dość długie). W takiej sytuacji idealnym wyjściem byłoby przypisanie wyniku sumy bitowej każdej flagi do osobnej zmiennej typu bool i na niej wykonywać operacje warunkowe. Nie ma jednak nic za darmo. W najbardziej pesymistycznym przypadku będziemy musieli stworzyć 32 lub 64 takie zmienne i dla każdej z nich dokonać przypisania. Narzut jest dość spory. Można to rozwiązać lepiej? Można. Z pomocą przychodzą pola bitowe.

#include 
 
struct Data
{
 bool a : 1;
 bool b : 1;
 bool c : 1;
};
 
enum Flags
{
 FLAG_1 = 0x1,
 FLAG_2 = 0x2,
 FLAG_3 = 0x4
};
 
int main()
{
 unsigned int uFlags = FLAG_1 | FLAG_3;
 Data f;
 
 f = *((Data*)&uFlags);
 
 printf("%s\n", f.a == true ? "a == true" : "a == false");
 printf("%s\n", f.b == true ? "b == true" : "b == false");
 printf("%s\n", f.c == true ? "c == true" : "c == false");
 
 return 0;
}

Struktura Data przechowuje pola bitowe. Każde pole zajmuje jeden bit. Ich kolejność jest zgodna z flagami enuma Flags. Dzięki przypisaniu zmiennej przechowującej flagi (uFlags) do owej struktury typu Data (f = *((Data*)&uFlags);), możemy w szybki sposób zacząć pracować z flagami bitowymi, tak samo jak ze zwykłymi zmiennymi typu logicznego.

Kinect dev diary - part 2

noreply@blogger.com (Unknown) — Thu, 28 Feb 2013 15:27:00 +0000

Tak jak obiecałem na facebooku, dziś kolejne dev diary, tym razem Kinectowe. Od pewnego czasu pracujemy nad rozwiązaniami dotyczącymi interfejsów użytkownika, dla urządzeń użytku publicznego. Podejść było bardzo dużo. Głównie chodziło o intuicyjność oraz stabilność śledzenia. Niżej możemy zobaczyć końcowy efekt. Jest jeszcze kilka rzeczy do poprawienia, jednak całość zachowuje się już dość stabilnie.
Warto zaznaczyć, że warstwa prezentacji jest stworzona we Flashu. Grafiki są jak najbardziej testowe - chodzi tylko o pogląd na ogólne rozwiązanie. Gest machnięcia w prawo (swipe right) został zaimplementowany przez nas. NITE udostępnia jego rozpoznawanie, jednak działało to dość losowo.

Klienta Flashowego stworzył Michał Prażuch.

C++ COTW - Placement new jako memcpy

noreply@blogger.com (Unknown) — Mon, 25 Feb 2013 13:36:00 +0000

#include <stdio.h>
#include <new>
 
struct Vec3d
{
    float x,y,z;
 
    Vec3d()
    {

        x = y = z = 0.0f;
    }
 
    Vec3d(float x, float y, float z)
    {
        this->x = x;
        this->y = y;
        this->z = z;
    }
 
};
 
int main()
{
 
    Vec3d v1(1.0f, 2.0f, 3.0);
    Vec3d v2;
 
    v2 = (*new(&v2)Vec3d(v1));
 
    printf("%f, %f, %f\n", v2.x, v2.y, v2.z);
}

Kolejna część z serii Coś Of The Week, dla C++. Tym razem został pokazany dość oryginalny sposób kopiowania danych, beż użycia bibliotecznej funkcji memcpy. Wykorzystać możemy do tego operator placement new i konstruktor kopiujący obiektu. Czy jest to wydajniejsze? Mówiąc szczerze, pomiarów nie dokonywałem, ale na pierwszy rzut oka, raczej nie. Poza tym, kod jest bardziej zagmatwany. Przydaje się to jednak wtedy, gdy nie mamy dostępu lub nie chcemy załączać nagłówków gdzie znajdują się funkcje operujące na pamięci.
.

Obsługa bramki SMS Orange w.. C++

noreply@blogger.com (Unknown) — Thu, 21 Feb 2013 12:59:00 +0000

Ostatnio postanowiłem się pobawić nieco socketami i obsługą protokołu HTTP. Przeglądarki własnej pisać nie będę (przynajmniej nie w przeciągu najbliższych kilku dni), chciałem jednak nieco podglądnąć jak wygląda komunikacja serwerem a klientem z wykorzystaniem HTTP. Tak oto powstał ten niewielki programik. Możemy za jego pomocą wysłać SMSa na dowolny numer w Orange (jeśli jego właściciel aktywował możliwość otrzymywania wiadomości z internetu). Nie jest tu potrzebna znajomość obsługi web-service'ów czy innych baz danych. Po prostu, ściągamy stronkę gdzie znajduje się obrazek CAPTCHA, wpisujemy jego zawartość i wysyłamy odpowiednio spreparowane zapytanie metodą POST. Nie odbyło się bez zabawy w "reverse engineering" - na początek trzeba podglądnąć jakie informacje wysyła przeglądarka internetowa.

Program miał być miał i lekki, dlatego GUI pisane w czystym WinApi (o zgrozo!). Cała część "internetowa" znajduje się w plikach HTTPDriver oraz HTMLParser. Cały chaos związany z interfejsem użytkownika, znajduje się w pliku main.cpp.

Oczywiście brakuje kilka podstawowych ficzerów - mieszkanie w tray'u oraz książka adresowa. To może jednak, innym razem.

Wszelakie uwagi mile widziane.

Link do źródeł.

C++ COTW (Coś Of The Week)

noreply@blogger.com (Unknown) — Sat, 16 Feb 2013 00:34:00 +0000

class A

{

public:

A(const char *sz)

{

printf("%s ", sz);

}

~A()

{

printf("~A ");

}

};

class B

{

public:

B(const char *sz)

{

printf("%s ", sz);

}

~B()

{

printf("~B ");

}

};

class C

{

public:

C(const char *sz)

{

printf("%s ", sz);

}

~C()

{

printf("~C ");

}

};

class App

{

public:

App() : a("A"), b("B"), c("C") {printf("App");}

private:

C c;

B b;

A a;

};

int main()

{

App m;

printf("\n");

}

printf("\n");

}

Ktoś wie co pojawi się na wyjściu? Wbrew pozorom poprawną odpowiedzią będzie:

C B A App

~A ~B ~C

Nie wierzycie? Sprawdźcie sami. Co zatem z tego wynika? Elementy na liście inicjalizacyjnej konstruktora inicjowane są przed wywołaniem samego konstruktora (co jest dość oczywiste). Dodatkowo kolejność inicjalizacji jest zgodna z kolejnością deklaracji pól w klasie. Destrukcja zaś odbywa się od ostatniego pola.

Kinect - początek

noreply@blogger.com (Unknown) — Thu, 14 Feb 2013 13:55:00 +0000

Tak jak obiecałem, przyszedł ten czas by zająć się Kinectem. Zainstalujemy sterowniki, zapoznamy się z ogólna architekturą API oraz napiszemy prosty programik do szpiegowania ludzi. Na wstępie jednak, kilka uwag. Nie będzie tu omawiane API od Microsoftu. Nie chodzi tu o moją niechęć do monopolistów, tylko względy praktyczne. OpenNI ma lepszą licencję, daje wsparcie dla sensorów konkurencji (ktoś ma Asusa XTion lub PrimeSense Carmine?) i działa na Linuksie. Korzystać będziemy z wersji 1.5.4, a nie z wydanej ostatnio 2.1. Nowa wersja jest wciąż w fazie beta, poza tym wprowadza bardzo duże zmiany w samej organizacji kodu i po prostu nie miałem czasu by dokładniej się nimi zająć. Dodatkowo będziemy używać interfejsu napisanego w C a nie w C++. Jakiejś specjalnej awersji do klas nie czuję, ale w tym przypadku wersja strukturalna przedstawia się znacznie czytelniej.
Zatem do dzieła.

Sterowniki i architektura systemu

Architektura aplikacji zbudowanej w oparciu o OpenNI

Wszystko składa się w zasadzie z dwóch komponentów - NITE i OpenNI. Jak widać na obrazku obok, są one ze sobą dość ściśle powiązane i szczerze mówiąc, nie mam zielonego pojęcia czym kierowali się projektanci tego systemu, tworząc go właśnie w taki sposób. Na szczęście, nigdy nie będziemy musieli się nad tym zastanawiać. Opiszmy może elementy tego diagramu. Na samym dole mamy oczywiście sprzęt wyposażony w SoC od PrimeSense. Wyżej (w kształcie litery C) jest OpenNI. Biblioteka ta dostarcza interfejsy komunikacyjne dla sterowników oraz middleware, zajmującego się analizą obrazu i głębi. W środku znajdują się dwa komponenty: NITE Algorithms oraz Sensor Data Acquisition. Pierwszy z nich odpowiada za analizę danych odbieranych z czujników, zaś Sensor Data Acquisition, wykonuje całą robotę związaną z bezpośrednią komunikacją komputera z sensorami. Wyżej już mamy tylko NITE Controls, czyli framework odpowiedzialny za rozpoznawanie i obsługę gestów oraz aplikację końcową - to czym będziemy zajmować się my.
Mając omówione podstawowe elementy, możemy zająć się praktyką. Przede wszystkim potrzebujemy sterowników i SDK. Ściągniemy je klikając tu i tu. Na początku instalujemy OpenNI SDK, zaś później pozostałe komponenty. Jeśli nie posiadamy Kinecta (lub mamy inny sprzęt) nie potrzebujemy pakietu z GitHuba.
Gdy wszystko przebiegnie pomyślnie, Kinect powinien zamrugać do nas zieloną diodą. Jesteśmy zatem gotowi, by okiełznać tego potwora!

Hello world

Stwórzmy zatem program do lokalizowania ludzi. Gdybyśmy chcieli wykorzystać do tego kamerę i zestaw bibliotek do analizy obrazu (np. OpenCV) z pewnością byłby to bardzo dobry temat na pracę magisterską. Pomijając fakt, że musielibyśmy zadbać o odpowiednie warunki oświetleniowe oraz jakość dostarczanych danych (rozdzielczość, FPS), nadal byłaby przed nami setki linii kodu wraz z opasłymi tomiskami opisującymi różne algorytmy analizujące obraz. Tutaj zaś, mamy bezpośredni dostęp do interesujących nas danych, zaś dzięki technologii zastosowanej w Kinectcie, nie musimy martwić się o oświetlenie.
Na początek więc, po instalacji całego pakietu, kopiujemy SDK (folder Include oraz Lib z katalogu OpenNI) do lokalizacji z komponentami zewnętrznymi (u nas jest to Externals). Ustawiamy ścieżki i robimy resztę magii związanej z IDE. Do main.cpp kopiujemy coś takiego:

bool bContextReady = false;
bool bDepthSensorReady = false;
 
XnContext *pContext;
XnNodeHandle depthHandle;
 
bContextReady = xnInit(&pContext) == XN_STATUS_OK;
 
if(bContextReady == true)
{
 bDepthSensorReady = xnCreateDepthGenerator(pContext, &depthHandle, NULL, NULL) == XN_STATUS_OK;
}
 
if(bContextReady == true && bDepthSensorReady == true)
{
 xnStartGeneratingAll(pContext);
 
 printf("Sensor started...\n");
 
 int iRet = 0;
 while(iRet == 0)
 {
  xnWaitAnyUpdateAll(pContext);
  iRet = _kbhit(); 
 }
 xnProductionNodeRelease(depthHandle);
 xnContextRelease(pContext);

Ogólna zasada działania programu jest prosta - inicjalizujemy wszystkie niezbędne zabawki, startujemy je, a później w pętli sprawdzamy stan sensorów, do których się wcześniej podłączyliśmy (w naszym przypadku jest to detektor głębi). W oczy rzucają się dwa typy: XnContext oraz XnNodeHandle. Kontekst to podstawowy obiekt OpenNI. Zawiera on stan całej aplikacji oraz wszystkich sensorów, do jakich podpięliśmy się podczas startu programu. XnNodeHandle to uchwyt do obiektu, dzięki któremu uzyskujemy interesujące nas dane. Aby uzyskać dostęp do dowolnego generatora musimy zawołać funkcję xnCreateXXX, gdzie pod XXX możemy wstawić:

AudioGenerator
DepthGenerator
GestureGenerator
HandsGenerator
ImageGenerator
IRGenerator
Player
Recorder
SceneAnalizer
UserGenerator

Dziś oczywiście nie będziemy zajmować się wszystkimi wyżej przedstawionymi generatorami - skorzystamy tylko z ostatniego. Daje on możliwość detekcji i lokalizowania ludzi. Jego tworzenie, zgodnie z wyżej przedstawionym schematem wygląda następująco:

XnNodeHandle usersHandle;
xnCreateUserGenerator(pContext, &usersHandle, NULL, NULL);

Dzięki niemu będziemy mogli dowiedzieć się ile osób stoi w polu widzenia Kinecta, pobrać położenie ich geometrycznego środka lub dowiedzieć się, czy dany piksel transmitowanego obrazu należy do określonej osoby (choć można to zrobić również za pomocą analizatora sceny).

Każdy aktor (bądź użytkownik, wedle nomenklatury OpenNI) posiada własny ID. Maksymalnie możemy wykryć do piętnastu osób. Wejście aktora na scenę (obszar widoczny przez Kinecta) wiąże się z automatycznym powiązaniem go z konkretnym numerem. ID jest zwalnianie wtedy gdy aktor zniknie ze sceny na dłużej niż pięć sekund. Jest to bardzo przydatne, bo chwilowe utracenie osoby nie oznacza wykrycia jej jako nowego użytkownika. Bardzo ładnie to widać na tym video. Przypatrzmy się zatem w jaki sposób możemy zaimplementować proste liczenie ludzi:

const unsigned int USERS_BUFFER_LENGTH = 15;
XnUserID users[USERS_BUFFER_LENGTH];

int iRet = 0;
while(iRet == 0)
{

 unsigned short int uUsersCount  = USERS_BUFFER_LENGTH;
 unsigned short int uVisibleUsersCount = 0;
 
 xnWaitAnyUpdateAll(pContext);
 
 memset(users, 0x0, sizeof(users));
 xnGetUsers(usersHandle, users, &uUsersCount);
 
 for(unsigned int i = 0; i < uUsersCount; i++)
 {
  XnPoint3D com;
  xnGetUserCoM(usersHandle, users[i], &com);
 
  if(com.Z > 0.0f)
  {
   uVisibleUsersCount++;
  }
 }
 
 printf("Users count: %d\r", uVisibleUsersCount);
 
 iRet = _kbhit();
}

Co my tu mamy. Przede wszystkim tworzymy bufor, w którym możemy przechować identyfikatory. Kluczową jest tutaj funkcja xnGetUsers. Przyjmuje ona uchwyt do generatora, wskaźnik na bufor oraz maksymalną liczbę elementów które mogą zostać zapisane. Przekazujemy tą zmienna przez wskaźnik, bo zwracana jest w niej rzeczywista ilość wykrytych ludzi. W pętli iterującej przez wszystkie elementy bufora users pobieramy pozycję każdej wykrytej osoby (xnGetUserCoM - Get User Center Of Mass). Zastanawiający jest tylko warunek, sprawdzający, czy współrzędna z jest większa od zera. Jak już wspominałem wcześniej, OpenNI przechowuje ID aktora, do pięciu sekund od jego zniknięcia ze sceny. Po tym, gdy aktor zejdzie ze sceny i jest ciągle w buforze jego pozycja z jest właśnie ustawiana na zero.

Ostatnią rzeczą o której chciałbym opowiedzieć to magiczna metoda xnWaitAnyUpdateAll. Jak sama nazwa wskazuje, służy ona do aktualizacji danych, pochodzących z interesujących nas sensorów. Jest jednak cała rodzina tego typu funkcji:

xnWaitAnyUpdateAll - czeka aż dowolny z detektorów zgłosi, że ma nowe dane. Jeśli tak, reszta detektorów jest automatycznie aktualizowana
xnWaitOneUpdateAll - czeka aż jeden detektor (którego uchwyt przekazany jest w argumencie) zgłosi, że ma nowe dane. Jeśli tak, reszta detektorów jest automatycznie aktualizowana
xnWaitAndUpdateAll - czeka aż wszystkie detektory będą miały nowe dane i dopiero wtedy je aktualizuje
xnNoneUpdateAll - nie czeka na żaden z detektorów, tylko automatycznie aktualizuje wszystkie dostępne

To w zasadzie tyle. Wyświetlanie dokładnej pozycji przechodzących ludzi zostawiam na zadanie domowe. Nie będzie to trudne, tym bardziej, że mamy już wszystkie potrzebne informacje. Solucje można pobrać tu.

STM'owe pamiętniki

noreply@blogger.com (Unknown) — Wed, 06 Feb 2013 10:19:00 +0000

Dziś będzie krótko, jak zwykle mało efektownie, ale treściwie. Ostatnio, mając chwilkę wolnego czasu, usiadłem do STM'a i udało się machnąć niewielkie demko. Pokazana jest tam komunikacja evala z komputerem PC, za pomocą portu COM. Za pomocą klawiatury możemy sterować czterema diodami, umieszczonymi na płytce. Do komunikacji po stronie PC potrzebny jest terminal dający możliwość połączenia po porcie RS232 (np. Tera Term). Któregoś wieczora machnę jeszcze jakiś niewielki dedykowany program do obsługi ledów, zaś za jakiś czas uwolnimy tkwiący w płytce port USB. W drodze są już kolejne odcinki kursu kodowania na tego zwierzaka.

Źródła dostępne są tu. Wszystkie najważniejsze pliki są w katalogu głównym projektu. Na koniec krótka demonstracja:

OpenGL, część druga

noreply@blogger.com (Unknown) — Sun, 03 Feb 2013 02:13:00 +0000

Dziś będziemy kontynuować naszą przygodę z malowaniem, tudzież rysowaniem. Po ostatnich wywodach pewnie każdy wie jak poprawnie trzymać pędzel w ręku. Dziś w końcu będziemy mogli uwolnić nasz talent i stworzyć nasze pierwsze, wielkie dzieło - "Hello world".

Wierzchołki i indeksy

W świecie OpenGL'a podstawowym budulcem wyświetlanych obiektów są wierzchołki. Za ich pomocą możemy namalować pojedynczy punkt, linię oraz trójkąt. W naszym przypadku nawet koło będzie składać się ze skończonej liczby elementów, choć w grafice dwuwymiarowej niekoniecznie musi to być prawdą. Jak było wspomniane w poprzedniej notce, wierzchołek składa się z atrybutów. Podstawowym atrybutem jaki musi mieć każdy wierzchołek to jego pozycja, w lokalnym układzie współrzędnych modelu. Zazwyczaj jest to wektor czterowymiarowy (x, y, z, w). Ostatnia współrzędna nie jest jawnie używana. Potrzebna jest ona do przekształceń macierzowych i koniec końców, ustawiamy jej wartość na jeden. Dodatkowo wierzchołek może mieć kolor (np. r, g, b, a) lub informacje o położeniu tekstury - texcoord, przekazywane jako wektor dwuwymiarowy.

Wszystko co będziemy renderować, będzie stworzone z trójkątów - jednego z trzech wyżej wymienionych prymitywów. Każdy model, we współczesnych grach trójwymiarowych, jest obiektem stworzonym z dużej liczby trójboków. Dzieje się tak dlatego, że dostępne dziś na rynku układy graficzne, zoptymalizowane są właśnie do pracy z trójkątami. Nawet gdy będziemy operować na zwykłych sprite'ach, znanych choćby z biblioteki SDL, to dalej dla nas będą to wieloboki - choć znacznie prostsze.

Kolejność przeciwna do ruchu wskazówek
zegara (counterclockwise direction; CCW)

Tutaj przechodzimy do kilku podstawowych kwestii technicznych. Przede wszystkim kolejność ułożenia wierzchołków: zgodna lub przeciwna z ruchem wskazówek zegara. Dlaczego ma to znaczenie? W grę wchodzą zagadnienia optymalizacyjne. Mając konkretnie zdefiniowaną kolejność, możemy określić przednią oraz tylną stronę wielokąta i renderować tylko jedną z nich (zazwyczaj przednią). Domyślnym trybem jest ten pokazany na rysunku obok - przeciwny do ruchów wskazówek zegara. Oczywiście możemy go zmienić.

Indeksowanie wierzchołków

Pozostaje jeszcze jedna wątpliwość - sam proces budowania prymitywów z wierzchołków. Rozważmy prosty przykład - prostokąt. Jest to wielokąt składający się z czterech wierzchołków. Aby go wyświetlić jednak potrzebujemy dwóch trójkątów, czyli o dwa wierzchołki więcej. Dla małych modeli taka nadmiarowość ma niewielkie znaczenie, jednak dla wirtualnych środowisk składających się z milionów wielokątów, może być to poważny narzut danych. Jak sobie z tym poradzić? Stosując indeksację. Wystarczy, że do funkcji renderującej przekażemy dwie informacje: samą listę wierzchołków oraz trójki indeksów wierzchołków, budujących trójkąty. Brzmi lekko skomplikowanie, ale w rzeczywistości jest to bardzo proste. Popatrzmy na rysunek obok. Mamy tam przedstawiony kwadrat składający się z dwóch trójkątów i czterech wierzchołków. Wierzchołki dwa i cztery są wspólne dla obu prymitywów. Pierwszy trójkąt zatem będzie się składał z wierzchołków o numerach: zero, jeden i dwa, zaś drugi budują wierzchołki dwa, trzy i zero. To w zasadzie wszystko. Mając te informacje, możemy budować geometrię dla naszych lokacji.

Tablice wierzchołków i indeksów

Pokodujmy więc chwilę. Na początek zdefiniujmy wszystkie niezbędne typy:

struct Vec4d

{

float x, y, z, w;

};

struct ColorRGB

{

float r, g, b;

};

struct Vertex

{

Vec4d position;

ColorRGB color;

};

struct Face

{

unsigned short int v0, v1, v2;

};

Jak widać, nasz wierzchołek posiada dwa atrybuty: czterowymiarową pozycję i kolor. Dodatkowym typem jest Face. Struktura ta będzie odpowiedzialna za przechowywanie indeksów wielokąta (jak to bywa w C, indeksujemy od zera). Możemy zatem zająć się tworzeniem i ładowaniem geometrii. Przykładem niech będzie wspomniany wcześniej kwadrat. Tablica wierzchołków i indeksów, może być dla niego zdefiniowana następująco:

Vertex vertices[] =
{
/* x, y, z, w, r, g, b */

{0.5f, 0.5f, 1.0f, 1.0f, 0.0f, 0.0f, 1.0f},

{-0.5f, 0.5f, 1.0f, 1.0f, 0.0f, 1.0f, 0.0f},

{-0.5f, -0.5f, 1.0f, 1.0f, 1.0f, 0.0f, 0.0f},

{0.5f, -0.5f, 1.0f, 1.0f, 0.0f, 0.0f, 0.0f}

};

Face faces[] =

{

{0, 1, 2},

{2, 3, 0}

};

Myślę, że przedstawiony wyżej kod jest w miarę oczywisty. Współrzędne wierzchołków podajemy w lokalnym dla modelu, układzie współrzędnych.

Malujemy!

Czas na główny gwóźdź programu, czyli renderowanie. Malować będziemy w pętli głównej przed podmianą buforów. Jak to zwykle bywa, wyświetlanie składać się będzie z kilku krótkich kroków.

glEnableClientState(GL_VERTEX_ARRAY);

glEnableClientState(GL_COLOR_ARRAY);

glVertexPointer(4, GL_FLOAT, sizeof(Vertex), vertices);

glColorPointer(3, GL_FLOAT, sizeof(Vertex), (float*)(vertices) + 4);

glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_SHORT, faces);

glDisableClientState(GL_VERTEX_ARRAY);

glDisableClientState(GL_COLOR_ARRAY);

Wynik działania programu

Funkcja glEnableClientState informuje maszynę stanów OpenGL, z jakiego typu tablic będziemy korzystać. Stała GL_VERTEX_ARRAY może być nieco myląca, bo nie odnosi się do wierzchołka jako takiego, lecz tylko do jego pozycji. Przekazując GL_COLOR_ARRAY odblokowujemy możliwość renderowania kolorowych vertexów. Następne dwie funkcje (glVertexPointer oraz glColorPointer) pokazują lokalizacje tablic z pozycją i kolorem wierzchołka. Dlaczego mówię tu o tablicach? Bo dla OpenGL'a są to w zasadzie dwie tablice. Nic nie stoi na przeszkodzie, by także z naszego punktu widzenia były to dwie oddzielne zmienne, jednak z powodów edukacyjnych zostaniemy przy tym rozwiązaniu. Także w przyszłości, gdy poznamy już bufory wierzchołków i indeksów, będziemy stosować takie podejście. Parametry przyjmowane przez obie funkcje są takie same. Na początek podajemy liczbę komponentów składających się na pozycję (x, y, z, w - 4) i kolor (r, g, b - 3). Następnie przekazujemy typ użyty do ich reprezentacji. W naszym przypadku jest to float (stała GL_FLOAT). Inne możliwe to: GL_SHORT, GL_INT oraz GL_DOUBLE. Kolejny parametr pokazuje jak daleko (w bajtach) oddalone są od siebie analogiczne parametry, w określonej tablicy. Jeśli dla pozycji i kolorów chcielibyśmy użyć dwóch oddzielnych tablic, parametr ten miałby wartość zero. Dane byłby wówczas upakowane ściśle obok siebie. Gdy jednak, tablica zawiera więcej informacji, przekazujemy wielkość wierzchołka w bajtach. Ostatni parametr to wskaźnik na zerowy element danej tablicy.

Doszliśmy w końcu do malowania - funkcja glDrawElements. Wyrenderuje ona dla nas indeksowaną geometrię. Na wstępie przekazujemy typ rysowanych prymitywów - trójkąty. Jeśli chcielibyśmy zobaczyć punkty przekazalibyśmy GL_POINTS, zaś dla linii GL_LINES. Kolejny parametr to liczba wierzchołków do wyświetlenia, zaś GL_UNSIGNED_SHORT to typ danych użytych jako nasze indeksy wierzchołków (unsigned char - GL_UNSIGNED_BYTE, unsigned int - GL_UNSIGNED_INT). Ostatni parametr to wskaźnik na indeksy. Jeszcze tylko blokujemy (glDisableClientState) możliwość używania tablic pozycji i koloru wierzchołka.
I to tyle. Naszym oczom powinien ukazać się piękny, wielokolorowy kwadrat (a w zasadzie prostokąt, ale o tym następnym razem).

Solucja do pobrania tu.

Hello STM32

noreply@blogger.com (Unknown) — Wed, 30 Jan 2013 21:48:00 +0000

Tym razem opuścimy luksusowy świat systemów operacyjnych, grafiki wspomaganej sprzętowo i nieograniczonej, chronionej pamięci. Pożegnamy wygodę oferowaną przez szybkie wielordzeniowe procesory i znaną każdemu architekturę x86 lub x64. Dziś będzie mowa o STM32F4 i w najbliższych notkach pokażę, jak wykorzystać go do kilku niecnych rzeczy.

Z czym to się je ?

Właśnie, czym jest to magiczne urządzenie? W zasadzie jest to w pełni wyposażony komputer, uzupełniony o kilka dodatkowych peryferiów. Przede wszystkim na pokładzie znajdziemy procesor ARM (Cortex M4) pracujący z częstotliwością 168 MHz. Dodatkowym atutem jest tutaj także jednostka FPU, sprzętowo wspomagająca obliczenia na liczbach zmiennoprzecinkowych. Pamięci RAM nie mamy dużo - do 192 kB (zależnie od wersji urządzenia). Na pokładzie znajdziemy jeszcze DSP, akcelerometr, mikrofon, wyjście audio, SDIO (Secure Digital Card Input/Output), USB, UART, cztery programowalne diody led i przycisk. Dodatkowo masa złącz GPIO (General Purpose Input/Output). Całość w bardzo przystępnej cenie. Nic tylko brać i programować!

Narzędzia

Żeby móc komunikować się z evalem (i jednocześnie go zasilić), potrzebujemy kabla mini USB (nie mylić z mikro). Niestety, nie jest on dołączany do zestawu. Na szczęście płytka wyposażona jest w programator (ST-LINK/V2), więc nie jesteśmy narażeni na dodatkowe koszta. Sterowniki do niego, można ściągnąć tu.

Zostało zatem wybranie IDE. Wybór mamy bardzo szeroki, ja jednak skupię się tylko na jednym - CooCox. Jest to darmowe, oparte na Eclipsie środowisko, z wbudowanym debugerem i bezpośrednią możliwością programowania płytki. Do naszych celów wystarczy w zupełności. Musimy także zaopatrzyć się w dedykowane GCC. Pozostaje nam więc tylko instalacja i krótki kurs pilotażu.

Pierwsze kroki

Mając wszystko przygotowane, możemy wnieść trochę więcej życia, w ten skostniały sprzęt. Po instalacji wszystkich wyżej wymienionych programów, uruchamiamy CoIDE. Naszym oczom ukaże się znana sylwetka Eclipsowego środowiska. Przechodzimy do menu Project. Wybieramy Select Toolchain Path i tam wklejamy ścieżkę do folderu bin, pakietu GCC (domyślnie jest to C:\Program Files\GNU Tools ARM Embedded\4.7 2012q4\bin). Następnie tworzymy nowy projekt, korzystając z przycisku na ekranie powitalnym. Podajemy nazwę projektu a później chip na którym bazowany jest eval - STM32F4x (gdzie x oznacza konkretną rewizję urządzenia, opisaną na procesorze). Kolejnym krokiem będzie wybranie komponentów. Z dostępnej listy zaznaczamy RCC. Automatycznie powinny dodać się CMSIS BOOT oraz M4 CMSIS Core. Do tego dodajemy jeszcze GPIO i jesteśmy gotowi by uruchomić pierwszy program. W liście plików (dodanych automatycznie podczas wyboru komponentów) znajdujemy main.cpp i wklejamy poniższy kod:

#include "stm32f4xx.h"
#include "stm32f4xx_gpio.h"
#include "stm32f4xx_rcc.h"

GPIO_InitTypeDef  GPIO_InitStructure;

void delay(volatile unsigned int uTime)
{
    while((uTime--) > 0)
    {
    }
}

void main(void)
{

    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);

    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12 | GPIO_Pin_13| GPIO_Pin_14| GPIO_Pin_15;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
    GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
    GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
    GPIO_Init(GPIOD, &GPIO_InitStructure);

    while(1)
    {
        GPIO_ToggleBits(GPIOD, GPIO_Pin_12);
        delay(100000);

        GPIO_ToggleBits(GPIOD, GPIO_Pin_13);
        delay(100000);

        GPIO_ToggleBits(GPIOD, GPIO_Pin_14);
        delay(100000);

       GPIO_ToggleBits(GPIOD, GPIO_Pin_15);
       delay(100000);
    }
}

Po kompilacji (Project -> Build albo F7) i wlaniu softu na płytkę (Flash -> Program Download), nasz STM powinien pociesznie zamrugać do nas swoimi wszystkimi kolorowymi diodami.
Następnym razem zajmiemy się dokładną analizą powyższego przykładu. Tymczasem to tyle.
Solucja, a właściwie workspace, do pobrania tu.

Kinect dev diary - part 1

noreply@blogger.com (Unknown) — Tue, 29 Jan 2013 11:30:00 +0000

Od dziś, co jakiś czas będę zamieszczał krótkie demka, z postępów prac nad kilkoma aplikacjami, które mam przyjemność tworzyć. Jako, że większość czasu spędzam walcząc z Kinectem, więc zamieszczane tu materiały będą w znacznym procencie dotyczyć właśnie tej technologii.

Na pierwszy ogień poszła segmentacja aktorów widocznych na scenie oraz wyświetlenie ich bez tła. Jak widać na poniższym filmiku, jest tam jeszcze kilka niedokładności. Wystarczy jednak końcowy efekt poddać obróbce (np. w OpenCV) by całość wyglądała bardziej znośnie. Działanie programu jest nieczułe na warunki oświetleniowe, więc sylwetka człowieka byłaby dalej widoczna w warunkach całkowitej ciemności. Z tyłu nie ma żadnego blue box'a czy innego screena. Po prostu, aplikacja potrafi odróżnić człowieka od otaczających go obiektów. Oczywiście za jakiś czas opiszę, jak samemu coś takiego stworzyć.

Pędzle w dłoń!

noreply@blogger.com (Unknown) — Sun, 27 Jan 2013 01:00:00 +0000

Dziś będzie o malowaniu. Robić to będziemy w OpenGL'u do spółki z GLSL'em.

Pierwszą rzeczą o jaką musimy zadbać, to zaopatrzyć się w dwie biblioteki: GLFW i GLEW. Pierwsza z nich będzie odpowiadać za tworzenie okna, kontekstu oraz obsługę wejścia. Robi to ona dla trzech wiodących systemów operacyjnych, więc gdy będziemy chcieli nasz kod opublikować w wersji dla Linuxa czy OS X'a, nie będziemy musieli zbyt wiele grzebać w kodzie (przynajmniej teoretycznie). GLEW zaś, ma za zadanie ułatwić pracę z rozszerzeniami, z którymi jak wiadomo, jest mały problem na platformie Microsoftu.

Rozkładamy sztalugi

Mając przygotowane wszystkie narzędzia bierzemy się do pracy. Jako, że wspominanie wcześniej biblioteki są niewielkich rozmiarów możemy ich źródła dodać do solucji. Pierwszą rzeczą jaką będziemy musieli wykonać to utworzenie okna, po którym będziemy mogli machać pędzlem. Zrobi to za nas funkcja glfwOpenWindow. Przyjmuje ona kilka parametrów. Pierwsze dwa określają rozmiary okna. Następnie przekazujemy liczbę bitów na każdy kanał koloru (red, green, blue) i przezroczystości (alpha). Kolejnymi parametrami jest liczba bitów jakie chcemy przeznaczyć na bufor głębi oraz szablonu (stencil buffer). Na końcu przekazujemy informacje o trybie pracy okna - pełnoekranowym lub okienkowym. Zanim jednak utworzymy okno, będziemy musieli zainicjować cały subsystem, wołając bezargumentową funkcję glfwInit.

Po wykonaniu powyższych operacji możemy przejść do pętli głównej, która jest sercem naszej aplikacji. W niej będzie wykonywało się wyświetlanie, odczytywanie stanu wejścia a także cała logika gry lub symulacji. Jak to zwykle bywa w tego typu aplikacjach, będzie to pętla nieskończona, przerywana na życzenie użytkownika. Tym życzeniem będzie po prostu wyjście z programu.

bool bRun = true;
while(bRun == true)
{
    glfwSwapBuffers();
    bRun = (glfwGetWindowParam(GLFW_OPENED) == GL_TRUE) && (glfwGetKey(GLFW_KEY_ESC) == GLFW_RELEASE);
}

Mamy więc kilka tajemniczych linii kodu. Pierwsza z wywoływanych funkcji (glfwSwapBuffers) odpowiada za podmianę buforów (podwójne buforowanie) i obsługę zdarzeń związanych z działaniem naszego okna. Linijkę niżej jest podejmowana decyzja o dalszym życiu naszej aplikacji. W pierwszej części wyrażenia sprawdzamy czy okno nadal jest widoczne, zaś w drugiej czy klawisz Escape jest puszczony. Jeśli oba te warunki są spełnione, możemy działać dalej. Jeśli zmienna bRun przyjmie wartość false, będzie to oznaczać, że czas życia naszego programu dobiegł końca. Żeby poprawnie zakończyć pracę i pozbierać za sobą wszystkie zabawki musimy wywołać funkcję glfwTerminate. Uprzątnie ona za nas cały bałagan który przed chwilą stworzyliśmy. Całość prezentuje się następująco:

int main()
{
    bool bReady = false;
    bReady = (glfwInit() == GL_TRUE);
 
    if(bReady == true)
    {
        glfwOpenWindow(800, 600, 8, 8, 8, 8, 32, 32, GLFW_WINDOW);
 
        bool bRun = true;
        while(bRun == true)
        {
            glfwSwapBuffers();
            bRun = (glfwGetWindowParam(GLFW_OPENED) == GL_TRUE) && (glfwGetKey(GLFW_KEY_ESC) == GLFW_RELEASE);
        }
 
        glfwTerminate();
    }
    return 0;
}

Dobieramy farby

Mając gotową obsługę okna, możemy zająć się malowaniem. Tutaj warto zatrzymać się nad kilkoma aspektami technicznymi. Przede wszystkim nie będą opisane tu przestarzałe funkcje z rodziny fixed pipeline. Po drugie, wersja OpenGL'a, którą będziemy używać to 2.0. Dlaczego nie nowsza? Końcowy plan jest taki, by kod renderujący, który tutaj stworzymy, przenieść na platformę mobilną (jak będę bogaty będzie to iOS, jeśli spłacę długi będzie to Android, a jeśli żadna z tych rzeczy się nie wydarzy - bada), gdzie niepodzielnie rządzi OpenGL ES 2.0, który jest kompatybilny (pomijając pewne niuanse) z omawianą tu wersją desktopową.
Skoro mamy to już wyjaśnione, porozmawiajmy trochę o shaderach. Ten magiczny stwór, to nic innego jak program uruchamiany na karcie graficznej. Jego nazwa (program cieniujący) może być nieco myląca, ponieważ nie odpowiada on tylko za cieniowanie i oświetlenie. Język GLSL jest na tyle elastyczny, że możemy w nim stworzyć praktycznie dowolny efekt.

Źródło

Podstawowym kryterium podziału shaderów jest ich przeznaczenie - wierzchołki (vertex shaders) i fragmenty (fragment shaders). Fragmenty, to nic innego jak piksele. Możemy zatem wykonywać operacje na wierzchołkach jak i na pojedynczych pikselach. Kolejność wykonywania shaderów, wraz z resztą funkcji potoku renderowania zastała przedstawiona na obrazku obok.
Zobaczmy zatem jak wygląda GLSL. Jest on bardzo zbliżony do C. Posiada trochę więcej typów oraz kilka wbudowanych zmiennych (prefiks gl_).
Jak na porządny język programowania przystało, całość zaczyna się od funkcji main. Jest bezargumentowa i nie zwraca nic. Wynik działania shadera zapisywany jest w zmiennych wyjściowych. W naszym przypadku dla wierzchołków ich obliczoną pozycję będziemy przekazywać do gl_Position, zaś ostateczny kolor piksela zapisywać w gl_FragColor. Obie zmienne są typu vec4 (x,y,z,w). Komunikacja na linii aplikacja - shader odbywa się za pomocą uniformów. Są to specjalne zmienne, których adres możemy pobrać za pomocą funkcji udostępnianych przez API OpenGL'a, a następnie ustawić je na konkretne wartości. Dodatkowo do dyspozycji mamy także atrybuty wierzchołków. Są to dane, które opisują wierzchołek (kolor, pozycja w układzie współrzędnych modelu, texcoord) i nie zmieniają się zbyt często. Możliwa jest także rozmowa pomiędzy vertex i fragment shaderem. Wystarczy, że w obu źródłach stworzymy zmienną, o tej samej nazwie oraz typie i dodamy jej modyfikator varying. Wówczas wartość przypisana do tej zmiennej w shaderze wierzchołków, będzie widoczna w shaderze fragmentów.
Pozostała jeszcze ostatnia rzecz - kompilacja i linkowanie. Każdy program, nawet ten uruchamiany na GPU, musi zostać skompilowany. Będziemy to robić w czasie działania aplikacji, za pomocą odpowiednich funkcji OpenGL. Vertex oraz fragment shadery kompilowane są osobno, jednak ostatecznie linkowane są w jeden program.
To tyle na dziś. Znów było teoretyczne przynudzanie. Następnym razem przedstawię bufory wierzchołków, wspólnie popełnimy pierwszy shader i wspomnę coś o matmie.
Tradycyjnie, solucja do pobrania tu.

Kinect - wprowadzenie

noreply@blogger.com (Unknown) — Tue, 22 Jan 2013 19:51:00 +0000

Dziś o programowaniu będzie niewiele. Za to będziemy skakać, biegać, machać rękami i robić masę różnych, nieprzyjemnych rzeczy. Będziemy zatem gadać o Kinect'cie.

Microsoft przedstawił swój kontroler w 2010 roku, na targach E3. Początkowo miał on służyć tylko do grania i sterowania konsolą Xbox 360, jednak zorganizowana grupa ciekawskich internautów dobrała się do intymnych części urządzenia. Niedługo później światło dzienne ujrzały filmiki prezentujące lepiej lub gorzej zrealizowane aplikacje, wykorzystujące ukryty potencjał owej zabawki. Microsoft jednak nie reagował zbytnio na te rewelacje. Być może dlatego, że urządzenie do końca nie jest to ich wynalazkiem tylko izraelskiej firmy PrimeSense, o której będę wspominał pewnie nie raz. Koniec końców mały/miękki wypuścił SDK pracujące z systemem Windows, drugą wersję kontrolera, przeznaczoną tylko dla PC, oraz niezwykle poruszającą reklamówkę.
Co na to PrimeSense? Nie próżnowali i wypuścili swoją wersję SDK. Nazwali ją OpenNI (NI - natural interaction), zbudowali aktywną społeczność i sprawili, że Kinect zaczął rozmawiać z Linuxem i Mac OS'em. Dodatkowo OpenNI działa nie tylko z urządzeniem Microsoftu. Jeśli nie lubimy monopolistów możemy zaopatrzyć się w odpowiedni sensor bezpośrednio u PrimeSense lub u Asusa (XTion).
Czymże zatem jest Kinect? Prawdę mówiąc jest to skaner 3D, wyposażony w dodatkową logikę i SDK. W zastawie znajdziemy również kamerkę RGB, kilka mikrofonów, akcelerometr (!) oraz silniczek krokowy. Wszystko po to, by móc poskakać na wirtualnym pontonie.
Trójwymiarowe widzenie zapewnia Kinectowi promiennik podczerwieni, który rzuca siatkę punktów na obiekty znajdujące się w zasięgu jego widzenia. Dodatkowa kamera, widząca tylko w wąskim zakresie podczerwieni, analizuje ich pozycje i na tej podstawie określany jest przybliżony model 3D środowiska. Dlaczego przybliżony? Głównie przez rozdzielczość głębi - tylko 320x200. Ostatecznie jest to reskalowane do 640x480 (w takiej rozdzielczości widzi kamera RGB), jednak ciągle musimy walczyć z masą szumów, które zostają w końcowym sygnale. Spora część magii wykonuje się po stronie sterownika i samego OpenNI. Niesamowite algorytmy, których tajników pewnie nigdy nie poznam, dokonują takich operacji jak wykrywanie ludzi, gestów czy tworzenie wirtualnych szkieletów. W naszej gestii zostaje tylko wykorzystanie tego potencjału. Nie ma jednak nic za darmo. Operowanie na chmurze punktów jest dość kosztowne obliczeniowo. Oczywiście bardzo wiele zależy od aplikacji, ale absolutnym minimum jest procesor dwurdzeniowy - cztery rdzenie mile widziane.
Zastosowanie podczerwieni ma też wady. Pierwszą z nich, jest ślepota sensora głębi w jasno oświetlonych pomieszczeniach. Wyprowadzanie Kinecta na spacer w słoneczne dni, nic nie da - nie zobaczy zbyt dużo. Urządzenie ma także problem z widzeniem czarnych rzeczy lub ciemnoskórych osób, choć to zależy także od panujących wokoło warunków oświetleniowych.
Najbardziej interesującą zaletą Kinecta jest jego sprawne działanie w całkowitej ciemności. Co prawda, w tym przypadku kamera RGB zda się na niewiele, jednak widzenie możemy przełączyć na podczerwień, która jest pięknie oświetlona przez promiennik. Sprawność pozostałych możliwości związanych z wykrywaniem ludzi i gestów zostaje zachowana.
Rzeczą która niezwykle ułatwia testowanie aplikacji, jest możliwość wykorzystania nagrań imitujących sygnał z sensorów kontrolera. Wstawanie od biurka i gimnastykowanie się przed urządzeniem z logiem Microsoftu, dla wielu programistów może być mało komfortowe. Możemy zatem uniknąć dziwnych spojrzeń kolegów z pracy, nagrywając wcześniej kilka sekund, za pomocą wcześniej przygotowanej aplikacji.
No cóż, to w zasadzie tyle. Dokładniejszą specyfikację techniczną Kinecta znajdą Państwo w internecie. Następnym razem może coś pokodujemy, choć nie obiecuję - sama instalacja sterowników, to niezły temat na notkę. Serio.

Box2D - czyli pierwsze starcie z fizyką

noreply@blogger.com (Unknown) — Sat, 19 Jan 2013 17:09:00 +0000

Wymagania:

SVN
Visual C++ 2010

Dziś nikt nie będzie rozmawiał o wzorach, równaniach i innych wyprowadzeniach. Tym zajęli się inni, a my skorzystamy z ich ciężkiej pracy.
Tytułowy Box2D, to silnik fizyczny autorstwa Erina Catto, przeznaczony do symulowania fizyki ciał sztywnych w świecie dwuwymiarowym. Aktualnie jest on najlepszym tego typu narzędziem. Możemy także wykorzystać bardziej zaawansowane rozwiązania typu Havok czy PhysX, jednak przekonanie ich do współpracy z naszą dwuwymiarową rzeczywistością wymaga trochę pracy. Poza tym, omawiana tu biblioteka jest najczęściej wykorzystywanym rozwiązaniem problemu symulacji w grach 2D. Na zachętę dodam, że samo Angry Birds zostało napisane w oparciu o Boxa2D.

Przygotowanie środowiska

Jak nieśmiało wspomniałem na początku, korzystać będziemy z Visual Studio 2010 (link do wersji Express). Samą bibliotekę checkout'ujemy korzystając z repozytorium na serwerach Google (http://box2d.googlecode.com/svn/trunk/). Gdy źródła będą już na naszym dysku (w tym tutorialu wykorzystuję rewizję nr 251) możemy przekopiować je do naszej solucji i zacząć tworzenie pierwszej, prostej symulacji.

Tworzymy świat

Każda symulacja fizyczna składa się z dwóch podstawowych elementów - świata oraz ciał, których ruch modelowany jest w jego obrębie. Elementy takie jak jointy, sensory czy motory są elementami działającymi bezpośrednio na ciała i służą do określonej zmiany zachowań obiektów. Ich użycie pokazane będzie w następnych częściach kursu.

Pierwszą rzeczą którą musimy stworzyć jest więc świat. Jedyną informacją którą będziemy przekazywać podczas jego konstrukcji jest grawitacja wyrażona jako wektor siły.

b2World *pWorld = new b2World(b2Vec2(0.0f, -9.8f));

Warto zaznaczyć, że typ przekazanego wektora to b2Vec2. Jak nazwa wskazuje, jest to wektor dwuwymiarowy, zawierający pola x oraz y. Istnieje kilka wariantów jego konstrukcji, posiada także szereg przydatnych metod - ciekawskich odsyłam do pliku b2Math.h. Stworzyliśmy zatem świat, którego grawitacja jest analogiczna do naszej ziemskiej.

Niech się stanie ruch

Plac zabaw został zatem zbudowany. Czas zainwestować w zabawki. Pierwszą rzeczą jaką musimy zrobić to odpowiednie wypełnienie struktury b2BodyDef. Zawiera ona wszystkie niezbędne informacje, które musi znać silniki fizyki przed stworzeniem nowego obiektu. Oto kilka podstawowych:

b2BodyType type

b2Vec2 position

float32 angle

b2Vec2 linearVelocity

float32 angularVelocity

Tworzone ciało może być dynamiczne (b2_dynamicBody), kinematyczne (b2_kinematicBody) lub statyczne (b2_staticBody).

Obiekty dynamiczne będą najczęściej przez nas wykorzystywane. Poddają się one każdym aspektom symulacji oraz kolidują ze wszystkimi fizycznymi elementami świata. Mają niezerową masę.

Obiekty kinematyczne nie są poddawane efektom działających na nie sił, mogą się jednak poruszać poprzez przyłożenie im prędkości. Nie kolidują z innymi ciałami kinematycznymi lub statycznymi. Mają nieskończoną masę (~0).

Ciała statyczne nie podlegają symulacji ruchu. Można je przesuwać, poprzez manualną zmianę ich pozycji, ale z wielu względów nie jest to zalecane. Podobnie jak obiekty kinematyczne mają nieskończoną masę oraz nie kolidują ze sobą.

Początkowa pozycja i kąt (w radianach) to następne elementy struktury. Podajemy je we współrzędnych świata. Warto zaznaczyć tu, że jak na porządny silnik fizyki przystało, Box2D operuje jednostkami systemu MKS. Każdy kto miał fizykę w podstawówce pewnie wie jak rozwinąć ten skrót. Dlatego, jeśli projektujemy naszą grę i zdecydujemy się na wykorzystanie fizyki, podstawową jednostkę gry nie mogą być piksele (200 pikselowy obiekt będzie mieć 200 metrów).

Jeśli chcemy by po stworzeniu obiekt poruszał się ustawiamy wektor prędkości liniowej lub kątowej.

Bardziej ciekawskie osoby, zapoznają się pewnie z całością struktury b2BodyDef, której pełną definicję można znaleźć w pliku b2Body.h. Mając wyjaśnione wszystkie podstawowe zagadnienia, możemy w końcu dodać ciało do świata:

b2BodyDef bodyDefinition;
 
bodyDefinition.type            = b2_dynamicBody;
bodyDefinition.position        = b2Vec2(0.0f, 3.0f);
bodyDefinition.angle           = 0.0f;
bodyDefinition.linearVelocity  = b2Vec2_zero;
bodyDefinition.angularVelocity = 0.1f;
 
b2Body *pFirstBody = pWorld->CreateBody(&bodyDefinition);

I cóż my tu mamy. Na samym początku wypełnianie wyjaśnionych wcześniej elementów struktury. Następnie zaś obiekt dodawany jest do świata. Gdy operacja zakończy się powodzeniem, otrzymujemy wskaźnik na ciało.

Let's play

Czas wiec uruchomić machinę i wystartować animację. Obliczanie równań ruchu będziemy przeprowadzać co klatkę, dla ustalonego kroku czasowego, który powinien być stały (Fix your timestep!). Musimy podać też liczbę iteracji dla solvera, którego działanie podzielone jest na dwie fazy: wyliczania prędkości i pozycji. Więcej informacji o jego działaniu możemy znaleźć w manualu. Z naszego punktu widzenia istotna jest informacja, że im większa liczba iteracji, tym symulacja jest dokładniejsza, jednak tracimy na wydajności. Trzeba zatem wypracować złoty środek, który zależy jednak od konkretnego projektu.

unsigned int uVelocityIterations = 8;
unsigned int uPositionIterations = 6;
 
pWorld->Step(1.0f / 60.0f, uVelocityIterations, uPositionIterations);

Uruchamiamy zatem naszą symulację z prędkością sześćdziesięciu klatek na sekundę (na razie czysto teoretycznie) z odpowiednią liczbą iteracji dla poszczególnych faz. Teraz przydałaby się informacja na temat położenia naszego ciała. Uzyskujemy ją wołając metodę GetPosition() dla utworzonego ciała. Zwraca ona wektor dwuwymiarowy. Metoda GetAngle() zwraca aktualny kąt w radianach. I to w zasadzie wszystko. Całość prezentuje się następująco:

unsigned int uVelocityIterations = 8;
unsigned int uPositionIterations = 6;
 
const unsigned int uFramesCount = 60;
for(unsigned int i = 0; i < uFramesCount; i++)
{
    pWorld->Step(1.0f / 60.0f, uVelocityIterations, uPositionIterations);
 
    b2Vec2 position = pFirstBody->GetPosition();
    float fAngle    = pFirstBody->GetAngle();
 
    printf("Position x: %.3f, y: %.3f\n", position.x, position.y);
    printf("Angle: %.3f\n", fAngle);
}

Na sam koniec traktujemy wskaźnik pWorld operatorem delete.

No cóż, efekt na razie mizerny, ale nikt cudów nie obiecywał. W następnych częściach pogadam trochę o integracji fizyki z OpenGLem. Mam nadzieję, że nikt po drodze nie zasnął.
Solucję do tej części można pobrać tu.

I'm back

noreply@blogger.com (Unknown) — Fri, 18 Jan 2013 14:58:00 +0000

Minęło sporo czasu od ostatniego wpisu. Krótka przerwa przerodziła się w długą nieobecność. Jestem jednak z powrotem w wielkim świecie blogerów i wiele wskazuje na to, że następne wpisy będą ukazywać się w miarę regularnie. O czym zatem będę zrzędzić? Pogadam trochę o dwuwymiarowej fizyce w wykonaniu biblioteki Box2D. Napomknę pewnie o OpenGL w zastosowaniu nie tylko na desktopy. Sporo miejsca poświęcę Kinectowi, z którym od pewnego czasu nie mogę się rozstać. Zdarzy się pewnie, że opowiem coś o embedded biorąc sobie za platformę STM32F4 a całość okraszę niezwykle przydatnymi radami początkującego programisty C++.
Jeśli starczy mi młodzieńczego zapału poświęcę kilka notek muzyce, filmom na nawet książkom, które (wbrew obiegowej opinii) zdarza mi się przeczytać. No cóż, to na razie tyle. Nie liczcie na wiele, choć czegokolwiek możecie się spodziewać.

Tymczasem, do następnej notki.

Krótka przerwa

noreply@blogger.com (Unknown) — Fri, 16 Oct 2009 23:12:00 +0000

Chciałbym z przykrością poinformować, że na okres kilku najbliższych miesięcy będę musiał wstrzymać to niezwykłe i interesujące zajęcie jakim jest blogowanie (sam proces nic nierobienia w tym względzie, praktykuję już od jakiegoś czasu). Powody jako takie są. Studia (ok, tu żartuję) a także kilka innych pomniejszych / powiększych spraw, które mimo wszystko są ważniejsze i bardziej czasochłonne. Myślę, że nikt się wiec nie obrazi. Obiecuję, że za jakiś czas pojawi się coś ciekawego, tak w ramach rekompensaty. Nie będę bawił się w ceregiele związane z usuwaniem bloga - niech sobie wisi w czeluściach internetu. A nuż/widelec coś/komuś się przyda - no w końcu kilka notek napisałem na trzeźwo. Na serio, to szkoda mi tych 1,22 z VAT, które wydałem na domenę. No koniec tego bezwładnego sypania literkami po ekranie. Do zobaczenia :)

SSE w klasie - #2

noreply@blogger.com (Unknown) — Tue, 11 Aug 2009 10:08:00 +0000

Po omówieniu podstaw związanych z programowaniem przy użyciu instrukcji SIMD, czas przedstawić nieco bardziej użyteczne informacje. Dzisiejszym daniem głównym więc, będzie niewielka (rozwijana w kolejnych częściach mini kursu) klasa czterowymiarowego wektora. Życzę smacznego i zapraszam do lektury :).

Na początku zaczniemy od przygotowania składników. Dziś zamiast wyrównanej do szesnastu bajtów tablicy typu float, skorzystamy ze struktury:

__declspec(align(16))
struct VectorData{
    float x,y,z,w;
};

Dla instrukcji SSE liczy się tak naprawdę odpowiednio przygotowany skrawek pamięci – w jaki sposób zostanie on zaalokowany (czy to będzie tablica czy struktura) zależy tylko od preferencji programisty.

Mając wszystko przygotowane, możemy przejść do przyrządzania dania głównego. Na pierwszy ogień pójdzie więc konstruktor domyślny, w którym to będziemy zerować współrzędne wektora.
Samo zerowanie jest oczywiście sprawą trywialną, choć początkowo może przysporzyć nieco problemów. Tradycyjnie, można to zrobić na dwa sposoby:

```
“manualne” przypisanie zer
```
skorzystanie z instrukcji memset (nagłówek cstring lub string.h)

Skorzystanie z memset powinno nieco przyśpieszyć tą prostą operację, ponieważ nie odwołujemy się do koprocesora, tylko operujemy danymi bezpośrednio w pamięci. Mimo iż w konstruktorze nie potrzebujemy wyjątkowej wydajności (jest on wykonywany zazwyczaj tylko raz), to jednak wykorzystamy trochę mocy :).

Otóż i niezwykle wyrafinowana treść naszej funkcji:

_asm{
    mov esi,this
    movaps xmm0,[esi]
    xorps xmm0,xmm0
    movaps [esi],xmm0
}

Jak widzimy, są tu dwie nowe rzeczy. Pojawił się wskaźnik this oraz instrukcja xorps.
Wskaźnik this używany jest by dostać się to struktury przechowującej wektor. Zadziała to jednak tylko wtedy gdy zmienna ta będzie pierwszym polem klasy. Wówczas adres na który wskazuje this jest równoznaczny z adresem owego pola.
W przeciwnym wypadku, pobranie adresu trzeba będzie wykonać “ręcznie”:

void *p = &m_vecData

_asm{
    mov esi,p
    //...
}

Cóż takiego robi instrukcja xorps? Jest to nic innego jak zwykły xor, w wersji dla SSE, działający na poszczególnych elementach naszego wektora. Wykonując tą operację na dwóch takich samych wektorach, zerujemy je. Jest to znacznie szybsze, niż “statyczne” przypisanie wartości zero do każdej ze współrzędnych. Mając konstruktor domyślny, możemy stworzyć konstruktor kopiujący oraz operator przypisania. Praktycznie rzecz ujmując będą to dwie identyczne funkcje. Ich działanie będzie się tylko ograniczać do kopiowania wartości pomiędzy rejestrami xmm. Spójrzmy więc jak to wygląda:

_asm{
    mov edi,vec
    mov esi,this

    movaps xmm0,[esi]
    movaps xmm1,[edi]

    movaps xmm0,xmm1

    movaps [esi],xmm0
}

Zakładam, że vec, to stała referencja na obiekt naszej klasy, przekazana do konstruktora kopiującego bądź operatora przypisania.
Działanie, jak już wspominałem, jest bardzo proste. Rejestry edi i esi przechowują wskaźniki na nasze obiekty, które następnie (za pomocą movaps) kopiowane są do odpowiednich rejestrów SSE – xmm0 dla naszego wektora oraz xmm1 dla wektora przekazanego w parametrze. Przypisanie wektorów to po prostu skopiowanie zawartości xmm1 do xmm0. Ostatnia instrukcja zapisuje wynik w this.

Na koniec omówimy sobie operator new i delete, ponieważ jak się okazuje, domyślne operatory nie będą kompatybilne z naszą klasą wektora.
W podstawowym ujęciu, instrukcje SSE dzielimy na dwie kategorie: operujące na wyrównanych i niewyrównanych danych. Gdy operujemy na danych niewyrównanych, działanie SSE jest nieco wolniejsze, ponieważ potrzeba więcej cykli by dostać się do odpowiedniej komórki pamięci. Przykładem tego typu instrukcji może być movups – jest to odpowiednik movaps (u – unaligned, a - aligned), tylko, że tablica lub struktura, do której chcemy uzyskać dostęp, nie musi być wyrównana do granicy szesnastu bajtów.

Cóż więc wspólnego mają z tym operatory new i delete? To, że przydzielają one niewyrównane do odpowiadającej nam wartości, kawałki pamięci. Należy zatem operatory te przeciążyć. Na szczęście jest to operacja równie trywialna, jak te, które zaprezentowałem powyżej. Jeden ze sposobów zrobienia tego, opisał Netrix, mi jednak udało się, znaleźć znacznie prostsze rozwiązanie. Okazuje się bowiem, że istnieją funkcje które robią to za nas: _aligned_malloc i _aligned_free. Zewnętrznie działają tak samo jak standardowe wersje malloc i free, więc ich użytkowanie nie powinno sprawiać większego problemu.

Implementację dodawania i odejmowania zostawiam jako zadanie domowe :). Instrukcje, które je wykonują omówiłem w poprzedniej części kursiku więc nie powinno to stanowić większego problemu.

W załączniku znajduje się kod do dzisiejszego kursiku. Dodałem także metodę zerującą wektor.

Samsung yp-u1

noreply@blogger.com (Unknown) — Sat, 23 May 2009 14:55:00 +0000

Dziś będzie trochę inna notka, nie nawiązująca zbyt wiele do programowania. Jak widać, znajduje się w kategorii krótka recenzja, lecz nie będę tu opisywał kolejnej, niezwykle fascynującej książki, z wciągającą fabułą i akcją. Chciałbym opisać niewielkie urządzenie, z którym miałem przyjemność spędzić ostatnie 3 lata. Nie jest to już więc sprzęt najnowszy, raczej ciężko go dziś kupić, jednak po tylu latach użytkowania chciałbym napisać kilka spostrzeżeń na temat tego niewielkiego odtwarzacza mp3.

Na początek kilka podstawowych danych technicznych:

wymiary: 25.6 x 87.4 x 13.6 mm
waga: 33g
zakres częstotliwości: 20Hz~20KHz
czas odtwarzania: 13h (wbudowany akumulator litowo-polimerowy)

Jak więc widać, jest to dość zgrabne i lekkie urządzenie. Dodatkowo bez problemów radzi sobie z formatami mp3 (także ze zmiennym bitrate) ogg, wma czy wav. Raz tylko zdarzył mi się plik, który podczas odtwarzania zawiesił odtwarzacz. Komunikacja z komputerem została rozwiązana standardowo: port USB 2.0, choć sposób chowania konektora jest nieco oryginalny (o tym później). Wyświetlacz jest cztero linijkowy, podświetlany w razie potrzeby na biało. Prezentowany tekst jest wyraźny i ostry. Nawet podczas przesuwania nie miga ani nie smuży, co często się zdarza w odtwarzaczach tego typu. Podświetlenie także nie pozostawia nic do życzenia – równomiernie rozłożone na całość ekranu.

Posiadana przeze mnie wersja miała 512MB (YP-U1X), lecz dostępna ilość miejsca do zapisu to 496MB.
Nawigacja po menu zostało zrobiona w sposób bardzo intuicyjny, szczególnie, że całość została przetłumaczona na język polski. Co ciekawe, “nieprzetłumaczalne” jest tylko “Settings” i “Language”, by po zmianie języka na koreański, bez problemów można było przywrócić stare ustawienia.
Główny ekran odtwarzania jest mocno konfigurowalny. Bez problemów można wyświetlić informacje na temat trybu odtwarzania, włączonego efektu dźwiękowego, bitrate (pliki ze zmiennym są oznaczane jako VBR), numeru pliku i poziomu baterii. Ciekawą opcją są dwa sposoby przewijania nazw utworów: poziomy i pionowy. Ten ostatni jest szczególnie przydatny, gdy nazwa piosenki jest dość długa by w krótkim czasie mogła zostać zaprezentowana w całości.
Nawigacja po drzewie plików też nie przysporzyła mi nigdy problemów – całość rozwiązana standardowo i intuicyjnie. Niektórym osobom nie podobał się sposób włączania i wyłączania odtwarzacza: kilku sekundowe przytrzymanie przycisku Play. Przyznam, że nigdy nie miałem problemów z przypadkowym wyłączeniem playera, tym bardziej, że czas reakcji jest dość szybki, a dodatkowo jest możliwość włączenia “brzęczyka” – dźwiękowe informowanie o wciśniętych przyciskach. Odtwarzacz obsługuje także własny typ playlist. Nie korzystałem z nich jednak nigdy; wolałem standardową, “folderową” kolejność utworów.
Dodatkową opcją jest nagrywanie dźwięku, lecz należy traktować to jako dodatek. Jakość nagrań jest bardzo zła, poza tym, zapisywane sa tylko w formacie wav.

Zewnętrznie urządzenie zostało wykonane dość estetycznie. Warto zauważyć, że, wbrew pozorom, jest to bardzo mocna konstrukcja. Nie raz zdarzyło mi się, że podczas wyciągania telefonu z kieszeni, wypadł mi także player – działa do dziś.

Wyżej wspominałem o ciekawym rozwiązaniu dotyczącym chowania wtyczki USB. Pierwszy raz spotkałem się z takim podejściem do problemu, by zamiast wysuwania, zastosować składanie – jest to ostatni (jeśli nie jedyny) model odtwarzacza mp3 Samsunga, który stosuje taki sposób. Niestety, po 3 latach intensywnego użytkowania (także często jako przenośna pamięć) rozwiązanie takie nie sprawdziło się. Jeśli przez pierwszy okres używania Yeepa nie było żadnych problemów, to teraz (zauważyłem to kilka miesięcy temu) urządzenie nie łączy się z komputerem w kilku warunkach. Przede wszystkim wejście USB nie może być zamontowane poziomo. Wówczas odtwarzacz opada (konektor się składa) i traci kontakt z komputerem – widać jakieś ruchome części odpowiedzialne za łączenie zostały uszkodzone.
Warto także zaznaczyć, że nie należy doprowadzać do zerowego stanu baterii. Często jest tak, że mimo informacji o niskim stanie akumulatora, po kilku chwilach odtwarzacz może zagrać jeszcze jeden, czy dwa utwory. Jest to jednak nie zalecane postępowanie. Ogólnie bateria sprawuje się dość dobrze – aktualnie trzyma od 6 do 8 godzin ciągłego odtwarzania muzyki. Warto zaznaczyć, że podświetlanie jest dość mocno “proądożerne” :)

Dołączone w zestawie słuchawki są wykonane solidnie i charakteryzują się dobrą jakością dźwięku podobnie jak sam odtwarzacz – nie jestem jednak znawcą i audiofilem, więc opinie będą na ten temat różne.

Podsumowując: YP-U1 to solidnie, proste w obsłudze, dobrze wykonane urządzenie nie pozbawione jednak kilku wad. Bez problemu zmieści sie w kieszeni i pozwoli posłuchać ulubionej muzyki w prawie każdych warunkach.

SSE w praktyce - #1

noreply@blogger.com (Unknown) — Wed, 20 May 2009 07:57:00 +0000

Dziś postaram się przedstawić podstawowe operacje jakie możemy wykonać przy użyciu multimedialnych rozszerzeń procesora. Pokażę możliwość bezpośredniego wykorzystania assemblera, zaś w następnych notkach skupię się na wewnętrznych poleceniach kompilatora, specjalnie przygotowanych do obsługi SSE. Aby prezentowany kod mógł zostać uruchomiony potrzebny jest procesor klasy Intel Pentium III lub lepszy.
Więc do dzieła ;)

Jednak, jak to zwykle bywa, na początek jeszcze trochę teorii.
Programując przy użyciu SSE mamy do dyspozycji 8 dodatkowych, 128 bitowych rejestrów (w przypadku kodu dla procesorów 64 bitowych, liczba ta zwiększa sie do 16) - od xmm0 do xmm7. Wszystkie operacje, jakie będziemy chcieli wykonać przy użyciu omawianych tu instrukcji multimedialnych, będą operować właśnie na tych rejestrach. Jak już wiadomo, każdy z nich może przechować 4 wartości zmiennoprzecinkowe pojedynczej precyzji (float).

Na początek przygotujmy dane na których będziemy pracować: czteroelementowa, jednowymiarowa, wyrównana do 128 bitów tablica typu float – czyli nasz wektor.

__declspec(align(16)) float gVector4[4];

Zobaczmy na początek, w jaki sposób możemy dostać się do danych naszego wektora. Nie będziemy tego robić standardowo,
za pomocą operatora [ ] – posłużymy się do tego odpowiednimi instrukcjami SSE.
Pierwszą podstawową rzeczą, będzie skopiowanie zawartości komórki pamięci, gdzie znajduje się nasz wektor, do rejestru xmm.

_asm{
    lea esi,gVector4
    movaps xmm0,[esi]
    //wykonaj operacje...
    movaps [esi],xmm0
}

Pierwsza linijka odpowiada za pobranie adresu zmiennej gVector4 (dokładny opis działania instrukcji lea można znaleźć tu)
i skopiowanie go do rejestru esi (wskaźnik danych).
Następnie możemy zobaczyć już instrukcję z rodziny SSE – movaps. Odpowiada ona za kopiowanie zawartości rejestrów xmm
między sobą, a także pamięcią. W tym przypadku, zawartość komórki pamięci na który wskazuje rejestr esi, zostanie przesłana do rejestru xmm0.
Ostatnia instrukcja kopiuje zawartość rejestru xmm0 pod adres wskazywany przez esi – czyli do naszej zmiennej. Jak widać, mimo że jest to assembler, nie jest to takie trudne. Wygenerujmy więc nieco więcej bardziej praktycznego kodu.
Jak pewnie zważyliście, deklarowanie za każdym razem owej specyficznej tablicy z pewnością nie należy do specjalnie wygodnych.
Uprośćmy więc nieco ten proces:

typedef __declspec(align(16)) float AlignedVector4D[4];

Ten niewielki kawałek kodu, z pewnością pozytywnie wpłynie na czytelność kodu.
Poznajmy więc kilka podstawowych operacji: dodawanie, odejmowanie, mnożenie i dzielenie.
Na początek zdefiniujmy dwa wektory, na których będziemy wykonywać nasze operacje:

AlignedVector4D vec1 = {5.0,6.0,3.0,1.0};
AlignedVector4D vec2 = {2.5,3.0,1.5,0.5};

Za dodawanie odpowiada instrukcja addps. Przykład użycia:

_asm{
    lea esi,[vec1];
    lea edi,[vec2];

    movaps xmm0,[esi];
    movaps xmm1,[edi];

    addps xmm0,xmm1;

    movaps [esi],xmm0
}

Jak widać kod jest bardzo prosty. Dwie początkowe instrukcje odpowiadają za pobranie adresu zmiennych, następnie kopiujemy je
do rejestrów xmm0 oraz xmm1 by dodać je do siebie w następnej instrukcji. Wynik zapisywany jest do xmm0 które jest kopiowane
pod adres jaki wskazuje esi, czyli do zmiennej vec1.
Zauważmy, że obecność kopiowania do rejestru xmm1 nie jest konieczna – addps, podobnie jak movaps może pracować na jednym
operandzie znajdującym sie w pamięci operacyjnej:

_asm{
    lea esi,[vec1];
    lea edi,[vec2];

    movaps xmm0,[esi];
    addps xmm0,[edi];
    movaps [esi],xmm0
}

Pozostałe operacje wykonuje się analogicznie:
subps – odejmowanie
mulps – mnożenie
divps – dzielenie To byłoby na tyle. W kolejnych częściach poznamy trochę więcej interesujących rzeczy ;)

Polimorfizm statyczny

noreply@blogger.com (Unknown) — Thu, 23 Apr 2009 00:52:00 +0000

Główna metodą, dzięki której możemy zastosować polimorfizm to dziedziczenie, wraz z funkcjami (czysto) wirtualnymi. Jest to najbardziej intuicyjny sposób znany większości programistów. O tym, jak wygląda to od strony kompilatora, napisał swego czasu Xion w jednej ze swoich notek. Dziś jednak chciałbym się skupić na innej, rzadziej stosowanej, implementacji owej techniki.

Główną wadą polimorfizmu jest jego wydajność. Dziś, w czasach rozkwitu języków zarządzanych, nie jest to problem wyjątkowo dotkliwy, jednak w pewnych zastosowaniach, nawet tak niewielkie narzuty muszą być brane pod uwagę. Mowa tu oczywiście o dynamicznym wiązaniu metod, których klasa zostaje ustalona dopiero podczas wykonywania programu. Jak można obejść ten problem? Stosując szablony.

Przeanalizujmy prosty przykład: rysowanie i zarządzanie obiektami geometrycznymi.
Załóżmy, że chcemy przygotować klasę, która rysowałaby różnego rodzaju obiekty geometryczne: od punktów po wielokąty zdefiniowane przez użytkownika. Logicznym rozwiązaniem problemu, jest zastosowanie polimorfizmu.

Na początek, stwórzmy więc interfejs definiujący operacje jakie ma wykonywać owy obiekt:

class IGeometryObject{

    public:
        virtual void draw(void) = 0; //rysowanie obiektu na plotnie
        virtual void setColor(unsigned uColorType); //ustawia kolor obiektu

        virtual void create(void) = 0; //przydzielenie pamieci dla obiektu
        virtual void release(void) = 0; //zwolnienie zasobow obiektu
};

Jak widać, nie ma tu nic szczególnego – klika metod czysto wirtualnych. Stwórzmy teraz metody innej klasy, których zadaniem jest rysowanie takich obiektów:

class CGeometryDrawer{

    public:

        void drawObjectsList(const std::vector<IGeometryObject*> &vElems){
            for(unsigned i=0;i<vElems.size();i++)vElems[i]->draw();
        }

        void drawObject(IGeometryObject *pObject){pObject->draw();}
};

Główną zaletą takiego podejścia jest to, że kolekcja vElems może być heterogeniczna, czyli zawierać elementy różnych klas. Wystarczy tylko, że każda z nich będzie implementować interfejs IGeometryObject.

Był to więc przykład standardowego podejścia do problemu. Jak już wcześniej wspominałem, dla każdego wywołania jednej z wirtualnych metod interfejsu IGeometryObject musimy się liczyć z niewielkim narzutem, związanym z dynamicznym powiązaniem metody.

Czas na prezentację tytułowego sposobu. Podstawową różnicą będzie tu brak klasy, po której będzie obowiązek dziedziczenia – dzięki szablonom narzucimy odpowiedni interfejs wewnątrz metod:

class CGeometryDrawer{

    public:

        template <typename GeometryObject>
        void drawObjectsList(const std::vector<GeometryObject> &vElems){
            for(unsigned i=0;i<vElems.size();i++)vElems[i].draw();
        }

        template <typename GeometryObject>
        void drawObject(GeometryObject &object){object.draw();}
};

Jak widać, nowa wersja klasy rysującej korzysta z metod szablonowych. Metody te, definiując typ GeometryObject, narzucają dla niego obecność funkcji składowej draw. Dzięki temu, możemy przekazać obiekty dowolnych klas – istotne jest tylko to, by miały definicje draw. Ważne, by to metody były szablonowe, nie zaś cała klasa. W przeciwnym wypadku bylibyśmy ograniczeni tylko do obsługi typu przekazanego podczas definiowania obiektu klasy CGeometryDrawer.
Warto także zaznaczyć, że kolekcja vElems musi zawierać obiekty tego samego typu (homogeniczne). W przypadku polimorfizmu dynamicznego, dzięki zastosowaniu dziedziczenia, mogliśmy dodać do kolekcji, klasy różnych typów, w tym przypadku nie jest to jednak możliwe. Można co prawda, przekazać do metody drawObjectsList wektor wskaźników, ale wtedy funkcje składowe byłby wiązane dynamicznie, więc tracimy zyski związane ze statycznym wiązaniem.

Ogólnie rzecz ujmując polimorfizm dynamiczny można określić jako: powiązany i dynamiczny.

powiązany, ponieważ typy obiektów są zależne od innego typu (dziedziczenie po klasie bazowej, w tym przypadku interfejsie)
dynamiczny, bo klasa wywoływanej metody jest ustalana podczas działania programu.

Do jego podstawowych zalet można zaliczyć:

możliwość działania na kolekcjach heterogenicznych obiektów
metody korzystające z polimorfizmu mogą być dostarczane w postaci skompilowanej (lib lub dll)

Polimorfizm statyczny jest zaś niepowiązany i statyczny:

niepowiązany, bo klasy konkretne (niewirtualne) nie muszą być dziedziczone po określonym interfejsie lub innej klasie
statyczny – klasy metod są ustalane już na etapie kompilacji

Zalety:

większa wydajność
klasy konkretne nie muszą implementować całości określonego interfejsu, ponieważ wymagana jest znajomość tylko tych operacji które są rzeczywiście wywoływane w programie
istnieje możliwość stosowania typów podstawowych

CPUID, czyli procesorze przedstaw się

noreply@blogger.com (Unknown) — Fri, 13 Mar 2009 01:42:00 +0000

We wcześniejszych notkach pisałem o technologii SSE. Krótki opis, wsparcie ze strony kompilatora – czas więc na bardziej praktyczne podejście do tematu. W artykule tym skupię się jednak na działaniu instrukcji, która nie jest związana bezpośrednio z technologią SSE, a mianowicie na CPUID - proste, bezargumentowe polecenie, pozwalające uzyskać wiele przydatnych informacji na temat procesora.

Pisząc program korzystający z zestawu instrukcji SIMD, chcemy czasem zachować zgodność ze starszymi modelami procesorów, które nie wspomagają konkretnej wersji SSE lub 3DNow!. Wykorzystując także najnowsze wersje rozszerzeń multimedialnych (aktualnie jest to 4.1), musimy mieć na uwadze to, że wielu użytkowników nie posiada jeszcze procesorów, które je potrafią obsłużyć. Aby nie ograniczać liczby potencjalnych odbiorców, musimy więc zaopatrzyć się w metody, które wykonają stosowne obliczenia w sposób tradycyjny, lub za pomocą niższych wersji SSE. Problemem pozostaje oczywiście pobranie informacji o tym, jaki typ funkcji możemy wykonać na procesorze użytkownika. Rozwiązanie jest wbrew pozorom dość proste. Przyjrzyjmy się kilku z nich.

Jeśli interesuje nas lista podstawowych możliwości, możemy skorzystać z funkcji udostępnianych przez Windows Api: IsProcessorFeaturePresent i GetSystemInfo. Pierwsza z nich zwraca informacje o wersji obsługiwanych SSE (niestety, tylko do wersji trzeciej), MMX, 3DNow! a także garść innych danych (choćby dostępność Physical Address Extension). Kolejna z wymienionych funkcji, może być szczególnie przydatna, bo za jej pomocą można dowiedzieć się, ile fizycznych procesorów jest aktualnie zainstalowanych w systemie. Pobiera także dane dotyczące m.in. rozmiaru strony w pamięci operacyjnej.
Skorzystanie z powyższej funkcjonalności jest bardzo proste, zaś przykłady są na stronach ich dokumentacji, więc nie będę prezentował ich użycia.

Sprawdzanie jednak, czy procesor posiada obsługę MMX, w dzisiejszych czasach, nie jest już koniecznie wymagane – od ładnych kilku lat, należy to do standardowej funkcjonalności procesorów rodziny x86. Co jednak, gdy chcemy skorzystać z udogodnień SSE 4.1? Jego obsługa dziś nie jest jeszcze tak oczywista, podobnie jak SSSE 3. Tu z pomocą przychodzi nam assembler.
Instrukcja CPUID dostępna jest od rodziny procesorów Pentium i późniejszych Intel486. Nie wszystkie funkcje były wspomagane od razu, jednak od czasów Pentium 4, sytuacja nie zmieniła się zbyt mocno.
Ogólna idea działania jest bardzo prosta: do rejestru EAX przekazujemy numer funkcji (operacje jaką chcemy wykonać), wywołujemy instrukcję CPUID i dostajemy interesujące nas informacje w odpowiednich rejestrach. Na początek pobierzmy nazwę producenta – jest to 12 znakowy łańcuch, zapisany w 3 rejestrach:

 char szName[13];

_asm{
    mov eax,0x00000000;
    cpuid;
 
    mov DWORD PTR szName,ebx 
    mov DWORD PTR szName+4,edx 
    mov DWORD PTR szName+8,ecx
}

szName[12] = 0;
printf("%s\n",szName);

Na procesorach Intela zostanie wyświetlone: GenuineIntel, zaś AMD: AuthenticAMD.
Jak to działa? Bardzo prosto.
Pierwsza instrukcja mov zapisuje do rejestru EAX numer funkcji (w tym przypadku jest to funkcja o numerze 0). Następnie wywołujemy CPUID, które pobiera numer funkcji z rejestru EAX i wykonuje odpowiednią operacje. Funkcja, którą przekazaliśmy, zwraca wspomniany już identyfikator producenta procesora, w porcjach czterobajtowych, w rejestrach EBX, EDX, ECX. Aby dostać się do niego, przekazujemy do instrukcji mov wskaźnik na tablicę szName (warto przypomnieć, że nazwa tablicy jest jednocześnie wskaźnikiem jej początku) i nazwę konkretnego rejestru – ważne aby zastosować zaprezentowaną kolejność by dostać prawidłowo “poskładany” łańcuch. Pod przekazany adres tablicy kopiowana jest zawartość czterobajtowych rejestrów, więc, żeby uzupełnić tablicę, zwiększamy wskaźnik o ilość skopiowanych dotychczas danych (czyli właśnie 4 bajty) dla rejestrów EDX i ECX. Nie było to więc zbyt trudne zadanie. Dowiedzmy się więc, coś na temat SSE. Numer funkcji, za pomocą której dowiemy się o wspieranych przez procesor wersjach SSE, to 0x0000001, zaś interesujące nas informacje (czyli Standard Feature Flags) będą się znajdować w rejestrach EDX i ECX.

 unsigned s1, s2;

_asm{
    mov eax,0x00000001;
    cpuid;

    mov s1,edx;
    mov s2,ecx;
}

Zmienne s1 i s2 zostały wykorzystane tu jako wektory bitowe – każdy z 32 bitów przechowuje wartość 0 lub 1 (właściwość jest lub nie jest dostępna). W rejestrze EDX (więc u nas w zmiennej s1) przechowywane są informacje na temat dostępności MMX (bit 23), SSE (bit 25), SSE2 (bit 26). Czy jest obsługiwane SSE w wersji trzeciej dowiemy się sprawdzając bit zerowy zmiennej s2, SSSE3 bit 9 a SSE4.1 bit 19. Jak to zrobimy? Oczywiście posługując się operatorem >> (jego działanie i typowe zastosowanie opisał Xion, w swoim megatutorialu).
Ogólny schemat wygląda następująco:

((zmienna >> numer_bitu) & 1) ? printf("jest") : printf("nie ma");

Czyli, jeśli chcemy sprawdzić dostępność SSE2, piszemy:

((s1 >> 26) & 1 )? printf("jest\n") : printf("nie ma\n");

Dla bitu zerowego (SSE3), nie musimy wywoływać operatora >>.

Możemy także ubezpieczyć się, przed (czysto teoretyczną) sytuacją braku wsparcia dla CPUID. W takim przypadku, gdy spróbujemy wykonać tą instrukcję, wyrzucany jest wyjątek, zaś naszym zadaniem jest przechwycenie go.

__try{

    _asm{
        //...
        cpuid
        //...
    }

}
__except(EXCEPTION_EXECUTE_HANDLER) { 
    if (_exception_code() == STATUS_ILLEGAL_INSTRUCTION){
        printf("Instrukcja nie jest wspierana przez procesor. ");
    }
}

W tym przypadku mamy możliwość złapania wyjątku systemowego, a taki zostanie wyrzucony, jeśli spróbujemy użyć instrukcji nie wspieranej przez nasz procesor. Tak samo można zrobić dla instrukcji SIMD, jednak moim zdaniem nie jest to eleganckie. W przypadku CPUID, taki kod “opakowujący” jest użyty na wszelki wypadek i jego wykonanie jest praktycznie znikome, zaś dla SSE szanse te znacznie rosną i powinniśmy wykryć odpowiednie właściwości znacznie wcześniej.

Dokładny opis CPUID znajdziemy oczywiście w podręcznikach Intela, szczególnie w IA-32 Intel Architecture Software Developer’s Manual VOLUME 2A: Instruction Set Reference, A-M, stronach 3-179 do 3-208. Warto wspomnieć, że za pomocą tej instrukcji, możemy dowiedzieć się bardzo wielu niskopoziomowych szczegółów na temat procesora.

Istotna kolejność

noreply@blogger.com (Unknown) — Wed, 25 Feb 2009 22:22:00 +0000

Dzięki operatorowi sizeof() możemy dowiedzieć się jaki jest rozmiar danego typu w bajtach. Standard świadomie nie określa odgórnych rozmiarów typów podstawowych, zostawiając to zależnym od platformy sprzętowej (opisane są tylko relacje wielkości pomiędzy typami). Mimo, że wszystkie produkowane dziś procesory operują na słowach 64 bitowych, to jednak znaczna większość użytkowników posiada 32 bitowe systemy operacyjne, dla których tworzony jest kod aplikacji.

Przypatrzmy się więc dwóm z pozoru identycznym strukturom:

struct A{
    short a1;
    int b1;
    short a2;
};
struct B{
    short a1
    short a2;
    int b1;
};

Mają służyć tylko jako przykład, więc nie są to wyjątkowo praktyczne typy. Jak widzimy obydwie struktury mają po dwa pola typu short i jedno typu int. Zróbmy teraz mały eksperyment i wyświetlmy rozmiary obu tych typów:

printf("%d %d\n",sizeof(A), sizeof(B));

Naszym oczom ukaże się dość zadziwiający widok, bo rozmiary typów A i B są różne, i wynoszą odpowiednio 12 i 8 bajtów (na procesorze z rodziny IA-32). Dość zaskakujące, nieprawdaż? Tylko z pozoru.
Zacznijmy więc od początku. Z prostego dodawania wynika, że obie te struktury powinny zajmować 8 bajtów (2+2+4). Pierwsza z nich jednak, zajmuje o 4 bajty więcej. W tym momencie przyda się podstawowa wiedza na temat działania procesora. Danymi, na których procesory 32 bitowe, pracują z największą wydajnością to właśnie 32 bity. Tyle wynosi rozmiar słowa i rejestrów ogólnego przeznaczenia. Wysłanie większej, lub mniejszej, ilości danych, jest realizowane wolniej, dlatego nie zawsze zaleca się ich używanie. Spójrzmy teraz na strukturę A. Aby efektywnie móc przesłać wartość jej pól do rejestrów, najlepiej zrobić to 32 bitowymi paczkami. Napotykamy jednak na problem. Wedle tej idei, zmienną b1 trzeba wysyłać 2 razy (po 16 bitów wraz z a1 i a2). Nie jest bezpieczne i poprawne rozwiązanie. W takim przypadku kompilatory stosują bardzo prostą sztuczkę: wyrównują zmienne do 32 bitów, co w tym przypadku oznacza, że a1 oraz a2 będą zajmować po 4 bajty. Na każdej z tych zmiennych zyskujemy dodatkowo po 2 bajty, więc zagadka została wyjaśniona. Dlaczego więc struktura B, zajmuje 8 bajtów? Decyduje o tym właśnie ułożenie zmiennych. W tym przypadku zmienne a1 i a2 można wysłać za pomocą jednego wywołania instrukcji mov, więc wyrównanie ich nie jest potrzebne.
Obrazowo można przedstawić to tak, że struktura (a zarazem i klasa) to pojemnik z 32 bitowymi (lub 64, w przypadku procesorów i systemów operacyjnych 64 bitowych) pudełkami, do których są kolejno dodawane zmienne. Jeśli dana zmienna nie zajmuje całego pudełka, a kolejna zmienna już nie mieści się do niego, wolne miejsce zostaje zapełnione – natura nie lubi próżni. :)

Kompilator vs. inline assembler

noreply@blogger.com (Unknown) — Mon, 05 Jan 2009 23:05:00 +0000

Optymalizacje niskopoziomowe, mimo że stosowane coraz rzadziej, nadal w wielu przypadkach, są jedynym wyjściem by przyśpieszyć działanie aplikacji. Z roku na rok jednak, kompilatory czynią dość znaczące postępy w automatycznym optymalizowaniu kodu i nie zawsze musimy uciekać się do drastycznych metod wstawek asemblerowych, które wbrew powszechnej opinii, nie są już zalecane. Przyjrzyjmy się jednak jednemu, specyficznemu przypadkowi: użycie SSE.
Mamy trzy możliwości do wyboru:

Optymalizacje stosowane przez kompilator (w opisywanym przypadku Visual Studio 2008).
Użycie wewnętrznych poleceń, tzw. intrinsic.
Bezpośrednie zastosowanie instrukcji SSE procesora.

Będziemy wykonywać operacje na wektorach, które będą reprezentowane przez zwykłą, wyrównaną do 16 bajtów (128 bitów) tablicą 4 wartości float:

__declspec(align(16)) float vector[4];

Pewnie wiele osób zastanawia się, skąd ta dziwna składnia tworzenia tablicy. Wyrównanie danych narzuca restrykcje dotyczące rozmiaru. Wyrównanie do 16 bajtów (czyli polecenie __declspec(align(16) ) informuje nas, że określona zmienna będzie zajmować dokładnie tyle. Przypomnijmy, że rejestry SSE są 128 bitowe i aby optymalnie wykonywać operacje musimy wysyłać dane do nich właśnie takimi, 128 bitowymi, paczkami. Aby porównać ze sobą wymienione wyżej trzy sposoby optymalizacji, zajrzymy do kodu wynikowego generowanego przez kompilator. Można to zrobić wchodząc we właściwości projektu (Project->Properties), następnie w zakładkę C++, Output Files i tam ustawić Aseembler Output na Assembly With Source Code. Będziemy porównywać podstawowe operacje typu przy zastosowaniu pierwszej wersji SSE, wektorem zaś będzie struktura:

struct Vector{
__declspec(align(16)) float data[4];
};

1. Optymalizacje kompilatora.

Jest to najprostszy sposób by użyć dodatkowej mocy procesora. Zaznaczamy kilka checkbox’ów, rekompilujemy projekt i dostajemy szybszy (przynajmniej w teorii) program. Zobaczmy jak sytuacja przedstawia się, gdy chcemy użyć SSE. Na początek przejdźmy do opcji projektu i tam C++ -> Code Generation -> Enable Enhanced Instruction Set ustawiamy na Streaming SIMD Extensions. Mając wszystko przygotowane, możemy przystąpić do pracy.

Posłużmy się prostą funkcją dodającą wektory:

void addVectors(Vector &v1,Vector &v2, Vector *pOut){
	pOut->data[0] = v1.data[0] + v2.data[0];
	pOut->data[1] = v1.data[1] + v2.data[1];
	pOut->data[2] = v1.data[2] + v2.data[2];
	pOut->data[3] = 1.0f;
}

Warto zauważyć, że element w, czyli ostatni, powinien być ustawiany na wartość 1.0f. Nie zastosowałem tutaj pętli, choć kompilator przy tak niewielkiej ilości iteracji i tak zastosowałby rozwinięcie.

Spójrzmy teraz na kod, który został wyprodukowany:

//; 8    :     pOut->data[0] = v1.data[0] + v2.data[0];
    mov    eax, DWORD PTR _v1$[ebp]
    fld    DWORD PTR [eax]
    mov    ecx, DWORD PTR _v2$[ebp]
    fadd    DWORD PTR [ecx]
    mov    edx, DWORD PTR _pOut$[ebp]
    fstp    DWORD PTR [edx]
//; 9    :     pOut->data[1] = v1.data[1] + v2.data[1];
    //dodawanie wartosci y
//; 10   :     pOut->data[2] = v1.data[2] + v2.data[2];
    //dodawanie wartosci z
//; 12   :     pOut->data[3] = 1.0f;
    mov    eax, DWORD PTR _pOut$[ebp]
    movss    xmm0, DWORD PTR __real@3f800000
    movss    DWORD PTR [eax+12], xmm0

Pominąłem tu prolog i epilog funkcji, bo nie są w tym momencie istotne. Nie ma także dodawania elementów y i z, ponieważ jest to realizowane w taki sam sposób jak dla elementu x. Zmieniane są tylko wartości rejestrów ecx dla instrukcji fadd (która odpowiada za dodawanie przez koprocesor FPU), oraz rejestru edx dla funkcji fstp odpowiednio o 4 (współrzędna x) i 8 (współrzędna y). Jak widać, samo dodawanie jest realizowane standardowo. Pierwszy raz instrukcja SSE jest użyta podczas przypisania elementu w (data[3]) – movss odpowiedzialna za ustawienie najniższej wartości rejestru na odpowiednią wartość.

Wnioski są bardzo proste: korzystanie z optymalizacji dostarczanych przez kompilator (w kontekście korzystania z SSE) nie dają zbyt wiele korzyści, a czasem nawet mogą zaszkodzić – powyższy kod nie uruchomi się na procesorach niższej klasy niż pentuim III – wszystko przez jedną instrukcję movss, która de facto, nie przyśpieszyła zauważalnie naszego kodu.

2. Wewnętrzne polecenia kompilatora.

Są to instrukcje, dzięki którym kompilator wie jak poprawnie użyć poleceń asemblera. By móc z nich skorzystać musimy dołączyć do projektu nagłówek xmmintrin.h, gdzie znajdują się wszystkie deklaracje funkcji i typów. Także i w tym przypadku wykorzystamy prostą funkcję dodającą dwa wektory:

void addVectors(Vector &v1,Vector &v2, Vector *pOut){
     _mm_store_ps(pOut->data,_mm_add_ps(*(__m128*)&v1.data,*(__m128*)&v2.data));
     pOut->data[3] = 1.0f;
}

Tak. Oto cała funkcja. Dodaje ona dwa wektory, więc funkcjonalnością jest ona identyczna z tą zaprezentowaną wcześniej. Na tym jednak kończą się podobieństwa. Jak widać sposób dodawania jest tutaj inny. Jest on wykonywany za pomocą funkcji _mm_add_ps, przyjmującej zmienne typu __m128 – by przekazać wyrównaną tablicę trzeba użyć rzutowania. Za pomocą _mm_store_ps zapisujemy wartość typu __m128, zwracaną przez _mm_add_ps, do tablicy. Zostaje jeszcze przypisanie wartości dla w. Tworząc własną klasę do zarządzania wektorami, można pominąć tę operację, dodając metodę dostępową zwracającą dla w zawsze 1.0f – wartość zapisana w ostatniej komórce będzie więc bez znaczenia.

Zobaczmy więc, co zostało ostatecznie wygenerowane:

    mov    eax, DWORD PTR _v2$[ebx]
    movaps    xmm0, XMMWORD PTR [eax]
    mov    ecx, DWORD PTR _v1$[ebx]
    movaps    xmm1, XMMWORD PTR [ecx]
    addps    xmm1, xmm0
    movaps    XMMWORD PTR $T20497[ebp], xmm1
    movaps    xmm0, XMMWORD PTR $T20497[ebp]
    mov    edx, DWORD PTR _pOut$[ebx]
    movaps    XMMWORD PTR [edx], xmm0
    mov    eax, DWORD PTR _pOut$[ebx]
    fld1
    fstp    DWORD PTR [eax+12]

Jak widać, kompilator utworzył znacznie mniej kodu. Pierwsze cztery linijki zapisują przekazane wektory do odpowiednich rejestrów SSE (xmm0, xmm1). Następnie addps dodaje te wektory (zwróćmy uwagę – jedno polecenie dodaje po cztery wartości dla każdego rejestru). Kolejne operacje dotyczą zapisania wyniku w przekazanej zmiennej, zaś trzy ostatnie przypisania wartości 1.0 dla ostatniej komórki tablicy. Tak utworzony kod jest zdecydowanie bardziej wydajny od poprzedniego. Widzimy tu zgodne z oczekiwaniami wykorzystanie instrukcji SSE (movaps, addps). Można zapisać to jeszcze lepiej?

3. Inline asembler

Została nam ostatnia opcja: bezpośrednia wstawka asemblerowa. Wbrew pozorom nie będzie to trudne zadanie – jak już wyżej było pokazane, dodawanie to zaledwie jedna instrukcja.

void addVectors(Vector &v1,Vector &v2, Vector *pOut){
    _asm{
        mov eax,v1;
        mov ecx,v2;
        movaps xmm0, [eax];
        addps xmm0,[ecx];

        mov eax, pOut;
        movaps [eax],xmm0;
    }
     pOut->data[3] = 1.0f;
}

Pierwsze dwie instrukcje przenoszą adresy (warto zauważyć, że wejściowe wektory przekazywane są przez referencje) danych na do odpowiednich rejestrów. Następnie movaps przenosi do rejestru xmm0, to co znajduje się pod adresem wskazywanym przez rejestr eax. Instrukcja addps dodaje zawartość rejestru xmm0 oraz miejsca w pamięci wskazywanego przez ecx. Ostatnie instrukcje zapisują wynik w wyjściowej zmiennej pOut.

Kod, który da nam kompilator, będzie praktycznie identyczny z tym znajdującym się wewnątrz bloku _asm{}. Dodatkowo dojdzie jeszcze ostatnie przypisanie dla data[3].

Jak widać okazaliśmy się lepsi od kompilatora. ;)

Co więc wybrać?

Pytanie nie jest taki proste. Nie zawsze bowiem, mamy chęć i czas by pisać kod w asemblerze – funkcje operujące na macierzach są zdecydowanie bardziej skomplikowane. Wyniki jakie dają metody z rodziny _mm* są wystarczająco zadawalające, jednak czasem można zaoszczędzić kilka instrukcji, pisząc niskopoziomowo. Dodatkowo funkcję lub metodę można oznaczyć jako inline lub __forceinline, dzięki temu ciało funkcji będzie wstawiane bezpośrednio w miejsce wywołania. Dzięki temu można uniknąć dodatkowego narzutu. Korzystanie z asemblera ma jednak jedną zasadniczą wadę. Funkcje napisane w taki sposób nie są w żadne sposób optymalizowane. Kompilator grzecznie wklei kod, który wcale nie będzie musiał być wykonywany. W takich przypadkach zdecydowanie bezpieczniej jest użyć intrinsic.

Ostatnim dylematem, może okazać sie potrzeba pisania własnych metod obsługi wektorów i macierzy. Jeśli korzystamy z DirectX, mamy tam do dyspozycji funkcje z rodziny D3DX, które (choć nie wszystkie) zostały odpowiednio już przygotowane – optymalizacja normalizacji wektorów lub mnożenia macierzy jest na prawdę dobrze wykonana.