Niedawno na warsztacie jeden z kolegow niezadowolony
z opengl'a i sprzetowego 3d zakrzyknal ze postawi
sobie na drugim rdzeniu softwarowy rasteryzer a gpu
ciepnie w uj (jak to teraz mówią)

B ciekawy pomysł.
Czy to by mialo szanse działaś? Chodzi mi o to -
czy mialoby to szanse dzialac w ten sposob ze pierwszy
rdzen bylby calkowicie odciazony od spraw generowania
obrazu natomiast drugi by wyrobil w sporym procencie ?
(to sa dwie rozne sprawy i nawet bardziej zalezy mi
na pierwszym, tj zupelnym odciazeniu, mniej na drugim
czyle ile wyrobi softwarowa rasteryzacja (choc niestety
pewni ejest tak ze to ten drugi rdzen by sie dławił.. :/
czyli to podejscie byloby dobre tylko dla gierek z
lekką rasteryzacją - ale jest ciekawe

(fir)

do góry

W dniu 12.09.2012 o 09:46 kenobi <p...@g...com> pisze:

> Niedawno na warsztacie jeden z kolegow niezadowolony
> z opengl'a i sprzetowego 3d zakrzyknal ze postawi
> sobie na drugim rdzeniu softwarowy rasteryzer a gpu
> ciepnie w uj (jak to teraz mówią)
>
> B ciekawy pomysł.

Bardzo durny pomysł. Jego rasteryzator będzie korzystał z jednego rdzenia
procesora ogólnego przeznaczenia. Karta graficzna ma (na przykład moja)
przeszło 380 (fizycznych) rdzeni wyspecjalizowanych w operacjach
graficznych (m.in. obliczenia na macierzach i wektorach). Niby dlaczego
miałby to być ciekawy pomysł? Karty graficzne powstały właśnie dlatego, że
procesor nie wyrabiał się w czasie z tak dużą liczbą operacji graficznych.

Pozdrawiam -- Spook.

--
Używam klienta poczty Opera Mail: http://www.opera.com/mail/

do góry

On Wednesday, 12 September 2012 10:42:57 UTC+2, Wojciech Sura wrote:
> W dniu 12.09.2012 o 09:46 kenobi <p...@g...com> pisze:
>
>
>
> > Niedawno na warsztacie jeden z kolegow niezadowolony
>
> > z opengl'a i sprzetowego 3d zakrzyknal ze postawi
>
> > sobie na drugim rdzeniu softwarowy rasteryzer a gpu
>
> > ciepnie w uj (jak to teraz mówią)
>
> >
>
> > B ciekawy pomysł.
>
>
>
> Bardzo durny pomysł. Jego rasteryzator będzie korzystał z jednego rdzenia
>
> procesora ogólnego przeznaczenia. Karta graficzna ma (na przykład moja)
>
> przeszło 380 (fizycznych) rdzeni wyspecjalizowanych w operacjach
>
> graficznych (m.in. obliczenia na macierzach i wektorach). Niby dlaczego
>
> miałby to być ciekawy pomysł? Karty graficzne powstały właśnie dlatego, że
>
> procesor nie wyrabiał się w czasie z tak dużą liczbą operacji graficznych.

Jest rasteryzer Mesy, który na nowoczesnych procesorach wyciąga ok 25% mocy
nowoczesnych kart graficznych (średnio, zależy co się renderuje).

AdamK

do góry

W dniu środa, 12 września 2012 10:42:57 UTC+2 użytkownik Wojciech Sura napisał:
> W dniu 12.09.2012 o 09:46 kenobi <p...@g...com> pisze:
>
>
>
> > Niedawno na warsztacie jeden z kolegow niezadowolony
>
> > z opengl'a i sprzetowego 3d zakrzyknal ze postawi
>
> > sobie na drugim rdzeniu softwarowy rasteryzer a gpu
>
> > ciepnie w uj (jak to teraz mówią)
>
> >
>
> > B ciekawy pomysł.
>
>
>
> Bardzo durny pomysł. Jego rasteryzator będzie korzystał z jednego rdzenia
>
> procesora ogólnego przeznaczenia. Karta graficzna ma (na przykład moja)
>
> przeszło 380 (fizycznych) rdzeni wyspecjalizowanych w operacjach
>
> graficznych (m.in. obliczenia na macierzach i wektorach). Niby dlaczego
>
> miałby to być ciekawy pomysł? Karty graficzne powstały właśnie dlatego, że
>
> procesor nie wyrabiał się w czasie z tak dużą liczbą operacji graficznych.
>
>

Ciekawe jest to z kilku powodów i ciezko wymienic
dlaczego to jest ciekawe, Problemem zdaje sie
zreszta nie relacja mocy "softwarowy rasteryzer
na jednym rdzeniu" / "opengl na gpu" tylko
relacja "czas update ramki stanu gry" / "czas
renderu ramki stanu gry" gdy czas updateGame() >
czas render() to nie ma deficytu mocy rendera
wiec nie trzeba wlaczac karty (jest to szczegolny
przypadek ale godny zainteresowania)

ps - zastanowilem sie jak mozna zakodowac taka
komunikacje miedzy agentem gry a agentem renderingu
(w modelu producer o ktorym juz kiedys pisalem)
i oto co mi wyszlo


//synchronizacja agenta gry i agenta renderingu
// w modelu producer

game_loop()
{
sluza_1 = free;
sluza_2 = free;


for()
{
if(sluza_1==free)
{
sluza_1 = busy;
UpdateGame(sluza_1);
sluza_1 = done;
}

if(sluza_2==free)
{
sluza_2 = busy;
UpdateGame(sluza_2);
sluza_2 = done;
}

}

}


render_loop()
{

for()
{
if(sluza_1==done)
{
Render(sluza_1);
sluza_1 = free;
}

if(sluza_2==done)
{
Render(sluza_2);
sluza_2 = free;
}

}

}


co smieszne ten kod wyzej prawdopodobnie działał
by po prostu wprost, bez muteksow i lockow ;-)
(choc nie zastanawialem sie nad tym ale
niewykluczone)

(fir)

do góry

(pierwszy rdzen czyli UpdateGame() ma za
zadanie wygenerowac stan gry i udostepnic
ten stan (formalnie to wlasciwie jak najmniejszy
fragment tego stanu) potrzebny rendererowi do
zbudowania obrazu - tutaj sa dwa bufory, zeby
update game moglo po wypelnieniu jednego generowac
drugi podczas gdy renderer konsumuje ten wykonany

do góry

On 12.09.2012 11:19, Adam Klobukowski wrote:
> Jest rasteryzer Mesy, który na nowoczesnych procesorach wyciąga ok 25% mocy
nowoczesnych kart graficznych (średnio, zależy co się renderuje).
Chyba 2.5%. Prosty shader z jednym źródłem światła na mesie osiągnął
zadziwiające 3 klatki na sekundę. Na gpu zasuwało z vsyncem/bez vsynca
60/130fps.

--
Pozdrawiam
Michoo

do góry

On 12.09.2012 11:40, kenobi wrote:
> (pierwszy rdzen czyli UpdateGame() ma za
> zadanie wygenerowac stan gry i udostepnic
> ten stan (formalnie to wlasciwie jak najmniejszy
> fragment tego stanu) potrzebny rendererowi do
> zbudowania obrazu - tutaj sa dwa bufory, zeby
> update game moglo po wypelnieniu jednego generowac
> drugi podczas gdy renderer konsumuje ten wykonany
Tak to się właśnie robi o wielu lat.

Tylko teraz 2 rdzenie to są w telefonie.
- jeden wątek liczy AI - może to robić w miarę niezależnie bo potrzebuję
tylko z grubsza informację o geometri
- drugi wątek robi "bulk" obliczenia fizyczne na sse - takie rzeczy
ciągle są szybsze ze względu na specyfikę komunikacji karty z pamięcią
- trzeci wątek wysyła do karty graficznej kolejne sceny[*]
- czwarty wątek głównie śpi a jak się obudzi to obsługuje wejście od
gracza i dźwięk

[*] Wyświetlenie złożonej sceny (1 klatki) wymaga renderowania tego
samego wielokrotnie:
- dla każdego światła oświetlony fragment sceny jest renderowany 1 raz
bez tekstur (policzenie cieni i ewentualnie koloru światła, zapisanie do
tekstury)
- dla zapewnienia odbić scena jest renderowana dodatkowy raz na każde z
nich (każdą grupę w przypadku sprytnych cubemap)
- dla uzyskania wygładzania (antyaliasing) renderuje się całą scenę (z
odbiciami) 2/4/16 razy

--
Pozdrawiam
Michoo

do góry

On 12.09.2012 09:46, kenobi wrote:
> Niedawno na warsztacie jeden z kolegow niezadowolony
> z opengl'a i sprzetowego 3d zakrzyknal ze postawi
> sobie na drugim rdzeniu softwarowy rasteryzer a gpu
> ciepnie w uj (jak to teraz mówią)
Niech sobie postawi na GPU własny renderer. No chyba, że brzydzi się
wyższą matematyką i jedyny algorytm który zna to kolorowanie pikseli.
Tylko wtedy należy się spodziewać efektów na poziomie dooma.

--
Pozdrawiam
Michoo

do góry

On Wednesday, 12 September 2012 12:06:46 UTC+2, Michoo wrote:
> On 12.09.2012 11:19, Adam Klobukowski wrote:
>
> > Jest rasteryzer Mesy, który na nowoczesnych procesorach wyciąga ok 25% mocy
nowoczesnych kart graficznych (średnio, zależy co się renderuje).
>
> Chyba 2.5%. Prosty shader z jednym źródłem światła na mesie osiągnął
>
> zadziwiające 3 klatki na sekundę. Na gpu zasuwało z vsyncem/bez vsynca
>
> 60/130fps.
>
>
>
> --
>
> Pozdrawiam
>
> Michoo

Napisałem że średnio. Na Phoronixie robią regularne testy i tyle mniej więcej
wychodzi.

AdamK

do góry

kenobi <p...@g...com> wrote:

> co smieszne ten kod wyzej prawdopodobnie działał
> by po prostu wprost, bez muteksow i lockow ;-)

A teraz wpisz w google "memory barrier" i skończ pieprzyć bzdury.

--
Gof
http://www.chmurka.net/

do góry