Logika gry to warstwa 'skryptowa' (chociaż nie zawsze realizowana skryptowo, ale jest to wygodne i obliczeniowo tak nieistotne, że niektóre gry używają powolnego pythona czy lua (przykładowo CryEngine) - a są one dziesiątki/setki razy wolniejsze niż kod natywny) i nie tyle musi co nie ma sensu przenosić na GPU, bo obliczeniowo jest nieistotna, a z GPU ciężko by było przykładowo karcie dźwiękowej przekazać, że ma zagrać dany dźwięk ;p (nie tyle niemożliwe, ale bezsensowne). Logika gry decyduje o tym co się dzieje - przykładowo 'jeśli jesteś w okolicy X to graj tą muzykę' czy 'jeśli zabiłeś X to niech zawali się most'... logika jest ważna, ale obliczeniowo nieistotna, w niej też często zapisuje się frontend AI i przykładowo 'jeśli masz się gdzie ukryć to się ukryj' - jednak te obliczenia nie są robione w logice, a przekazywane przez język skryptowy do mechaniki gry (a ta liczy na GPU czy jest miejsce gdzie może się ukryć, i wylicza najkrótszą ścieżkę jaką może iść i co ma robić).

AI i animacja to nie jest logika, a mechanika. Animacja na CPU już od lat jest ograniczona do minimum. Ostatnia duża gra o której pamiętam, że liczyła animacje siatki na CPU to Doom 4. Od tamtego czasu tym zajmuje się GPU w Vertex Shaderach (CPU robił kilka mnożeń macierzy na kość i tyle przy animacji liczy... ale to też niektóre silniki już przeniosły do GPGPU). AI w większości grach jest na CPU... jednak przyczyną tego jest to, że w PC mamy mocne procki... które nie wiele mają w grze do roboty, a w konsolach x360/ps3 trzeba było robić to na CPU, teraz jednak konsole wymuszą przeniesienie praktycznie całego obliczeniowo żernego balastu na GPU (wyszukiwanie najkrótszej ścieżki w grafie, przeszukiwanie siatek nawigacyjnych to dla GPU banalna zabawa, gdy CPU się mocno męczą), a po stronie CPU logika będzie tylko sterowała co ma teraz GPU jej obliczyć i wypluć gotowe dane.

@skoti48

W prezentacji SDK Sony GPGPU napisane jest, że nie mogą przerzucić obliczeń związanych z logiką gry. Jakie to są konkretnie obliczenia ( poza rzeczami które wymieniłeś wcześniej dźwięk itd. ) ? A np AI, animacje ?

Nie, że lepiej, a bardziej realistycznie... jednak ty chyba nigdy nie zrozumiesz różnicy.

Dubel......

To nie założenie, a po pierwsze oparcie się na słowach twórców, którzy mówią, że u nich w AC:U wąskim gardłem jest CPU, oraz na wynikach wydajności PS4 vs Xbox One (które mówią jasno, że CPU zabiera dużo milisekund z ramki, a obliczenia na GPU w bardzo małym stopniu wpływają na czas klatki).


Większość rzeczy dziś się robi na GPU. Od Nvidii mamy tylko PhysX (który i tak nie potrafił do niedawna liczyć na GPU RigidBody, bo na CPU było szybciej...). To jest nowy rynek który się rozwija. Jednak należy powiedzieć jasno - większość rzeczy które 7 lat temu robiło się na CPU, obecnie robi się na GPU (ofc dodatkowo już nie przetwarza się postprocess w pixel shaderach, a w compute shaderach, ale to zmiana typu RSX->SPE w PS3). Zostały nieliczne rzeczy do robienia na CPU.
Teraz dzięki Keplerowi (pełnemu więc tylko HiEnd i Maxwele)/GCN przyszła kolej na przeniesienie reszty, bo obecnie GPU to prawie zwykłe CPU, które potrafią sobie same generować zadania co sprawia, że obecnie nie ma problemu z reszty (poza komunikacją z padem, kartą dzwiękową...).

@up
Tylko wychodzisz z założenia, że GPU czeka na procesor, a co jeśli sytuacja jest odwrotna i to CPU czeka na GPU?

Hmmm.... ile CUDA jest na rynku 7 lat? i wciąż najwięcej rzeczy w grach na GPU powstało od tada ... NV. W 2 lata raczej nie przerzucą obliczeń na GPU.

CPU potrzebne jest do odczytu danych z dysku, do działania systemu operacyjnego, odczytywanie danych input (pad), system dzwięku, i do zarządzania kernelami/shaderami dla GPU.... reszta może być bardzo skutecznie przeniesiona na GPU (tak jak w PS3 na SPU). I właśnie na tym polega trick nowej generacji konsol - one upatrują swojego długiego życia w GPGPU.
Początkowo CPU jest wykorzystywane jeszcze standardowo jak w starych konsolach, ale za 2 lata CPU będzie najmniej znaczącą rzeczą w konsoli.


- W grach na PC tak jest - ale ze względu na ograniczenie DirectX'a, który generuje duży narzut na główny wątek i jeden wątek jest tam problemem. Inaczej jest w OpenGL gdzie ten narzut jest minimalny (przez co mimo, że na jednym wątku to nie przeszkadza) czy w Mantle, który jest zbudowany od podstaw wielowątkowo.

- Nowe konsole są jeszcze w powijakach - Compute shadery na PS4 zostały dopiero udostępnione (jeszcze nie ma gier ich wykorzystujących), a Xbox jeszcze w praktyce nie ma niskopoziomowego API i powoli jego API ewoluuje. Obecnie w grach wykorzystywane jest CPU tam gdzie zaraz zastąpi go GPU, ale obecnie nie brakuje wcale wydajności jednego wątku... brakuje wydajności w sumie (te 6x rdzeni w konsolach dla gier mogą mocą sumaryczną konkurować z telefonami, a nie z PC).


No pewnie, że tak - GPU to masa słabych rdzeni - nie powinno więc cię dziwić, że wielowątkowe programy działają tu szybciej, gdy wydajność GPU wynosi ponad 10x i7 Haswelli (a te mają 5x większą wydajność 8x rdzeni jaguara)?


To po raz kolejny się zaskoczysz. Gdy tylko symulacje tłumu przerzucą na GPGPU to Xbox One powinien mocno odstawać od PS4.
O jakich ty przeznaczonych 30% mówisz? To tak nie działa. Po pierwsze 5% wydajności GPU w PS4 jest wydajniejsze niż cała wydajność procesora w Xbox One już po odblokowaniu siódmego rdzenia. Po drugie obecnie problemem jest to, że GPU większość czasu w AC:U nic nie robi tylko czeka... aż CPU obliczy dane. W wypadku gdy obliczenia przeniesie się do GPU wydajność się nie obniży tylko podniesie (GPU nie będzie się opierdzielało czekając na dane). W praktyce może to oznaczać podniesienie rozdzielczości (bo gdy obliczenia na które czeka GPU zrobią się 20x szybciej to i GPU będzie miało więcej czasu na rendering).

@KazH

Na pewno nie ma różnicy dla GPGPU, że ps4 ma 8 ACE ( 64 kolejki ) a xbox one dwie ( 16 kolejek ).
Przyjmując prosto Twoje obliczeniowe porównania +300%.
Snc Ci to bardzo prosto przedstawił, ale jak widać nie rozumiesz...

Podejście drugie

Załóżmy CPU czas - 15ms
GPU - 20ms

Po wprowadzeniu GPGPU :
Część fizyki na GPU + dotychczasowa robota - 22ms ( bo gpu zrobi to w 2ms a cpu potrzebuję 6ms )
CPU - 9ms

I już masz lekko ponad 30 fps przy zachowaniu tej samej rozdzielczości..

Dalej nie rozumiesz ?

czego oczekujesz od kogoś kto nie zna realnego wykorzystanie zasobów sprzętowych tylko pisze że tyle myśli że jest a może być w błędzie. A dodatkowo ocenia gry tylko przez pryzmat grafiki i to żę są na nowym silniku który co by tu dużo nie mówiąc wygląda na skopany

Chodzi bardziej o to, że docelowo gra działa w 30 kl./s. Jak słusznie zauważyłeś, z powodu słabości CPU są spadki, nawet do 15 kl./s. Najprawdopodobniej (pewności nie mamy, ale logika na to wskazuje) w momentach tych spadków GPU się 'nudzi', musi czekać na CPU. W takim przypadku przerzucenie krytycznych obliczeń na GPU powinno dać w miarę stałe 25kl./s. Teoretycznie

Staralem sie najprosciej jak mozliwe ale widze nie skumales, przenalaizuj jeszcze raz moj wywod, a jak to nic nie da drugi i trzeci Gpu bedzie mialo wiecej do wyliczenia ale te dodatkowe kilka milisekund ktore bedzie potrzebowac zwiekszy iilosc fpsow bo cpu robilo by to kilkakrotnie razy dluzej.

Myślę że można to wyjaśnić prościej. Aktualnie gra działa w 900p z prędkością 20-25 fps. Jeżeli Ubisoft obniży rozdzielczość do 720-800p to zwolni część GPU i dzięki temu będzie mogło wspomagać tą mocą słabe CPU. Tak więc po zastosowaniu GPGPU będziesz miał 720p ale w 30fps. Nie ma czegoś takiego jak moc pobierana z kosmosu ale przyznam że mnie bardzo rozśmieszyłeś twierdząc że w przyszłości ktoś odejmie kawałek GPU i dzięki temu podniesie rozdzielczość. Nadawałbyś się na polityka bo mógłbyś wszędzie dodawać nigdzie nie odejmując

Teoretycznie naprawdę tyle ma (3,2GHz x 2 rdzenie x 32 operacje SP/cykl zegara). Problem w tym, że są to dane wyłącznie teoretyczne, zakładające optymalne wykorzystanie instrukcji FMA. Ocenianie realnej wydajności procesora na podstawie 'peak FLOPS' to ślepa uliczka.

Zrozum, jezeli obliczenie czegos na slabym cpu zajmuje powiedzmy 10ms a na szybkim gpu 3ms, to nawet jak tracisz te 3ms bo karta ma wiecej do wyliczenia to i tak zyszkujesz 4ms(10 - 3 -3), proste? A roznicze moga byc jeszcze wieksze bo wedlug benchmarka na ktory sie powolywalesz gpu potrafi niektore rzeczy obliczyc 16x szybciej niz cpu. Mam nadzieje ze zrozumiales, bo staralem sie przedstawic to mozliwie najprosciej.

Gra aktualnie działa w 900p średnio poniżej 25fps obciążając w 100% zarówno CPU jak i GPU. A ty sądzisz ze zabranie np. 20% mocy GPU podniesie rozdzielczość.... hahahahah. To jakaś nowa logika. Wyprowadzę cię z błędu. To jest obieg zamknięty. Jeżeli chcesz gdzieś dodać to gdzieś indziej musisz odjąć. Jeżeli chcesz część GPU przeznaczyć na obliczenia wspomagające CPU to będziesz musiał obniżyć rozdzielczość do 720p bo musisz zwolnić cześć mocy. Mówimy dokładnie o tym samym co MS robił w ubiegłym roku gdy część mocy GPU przeznaczał na obliczenia GPGPU by obsługiwać Kinecta. Gdy MS zrezygnował z GPGPU i zwolnił te 10% zasobów GPU to grach spowodowało to podniesienie rozdzielczości. Jeżeli chcesz by Sony poszło w odwrotnym kierunku to musisz się pogodzić z tym że gry będą w niższej rozdzielczości. Bo gdzieś trzeba odjąć. Wydajność się z kosmosu nie bierze. Jeżeli część GPU będzie pomagała wyrównać braki słabego CPU to ta część procesora nie będzie liczyć grafiki a więc moc na grafikę się zmniejsza a razem z nią rozdzielczość. Nie sądzę by Ubisoft zdecydował się zejść do 720p - to byłoby samobójstwo wizerunkowe

Ale przieciez sam mowiels ze w unity proc ogranicza, wiec przerzucenie czesci oblcizen na gpu zwiekszy ilosc fpsow a nie zmniejszy, zmiana rozdzielczosci to bedzie wtedy eweutalnie do 1080p bo bedzie wiecej klatek.

Skąd wy bierzecie takie dane ??? 200GFlops na i3? http://www.ocaholic.ch/modules/smartsectio...amp;itemid=1005

Nie widziałem slajdów ale sądzę że i tak mistrzem slajdów będzie AMD. Ja wolę się opierać na realnych testach z gier. Unity pokazało że szybsze CPU to szybciej działająca gra w otwartym świecie. I twierdzę że tak będzie do końca generacji. Bo jakoś nie chce mi się wierzyć w to żeby ktoś zdecydował się oddać powiedzmy 20-30% mocy GPU i obniżać tym samym rozdzielczość do 720p tylko po to by zaoszczędzoną w ten sposób moc przeznaczyć na wspieranie CPU. O ile grafika 900p jest spoko na telewizorze to jakiekolwiek obniżenie w kierunku 720 by użyć GPGPU od razu spotkałoby się z krytyką graczy.

Moc nie bierze się z kosmosu. Jeżeli chcesz przeznaczyć cześć mocy GPU na wspieranie CPU to tym samym musisz obniżyć rozdzielczość by nie spadła ci liczna klatek. Bo nie ma cudów z nikąd. Zawsze musisz gdzieś odjąć jeżeli chcesz gdzieś dodać.

@SunTzu
Nie do końca rozumiem twój wywód (tzn. rozumiem, ale nie za bardzo widzę jego przełożenie na omawiany problem).

Moje argumenty są proste - uważam że 8 bardzo słabych rdzeni CPU to marnowanie zasobów. Jeśli rację ma skoti i w grach wszystko da się dobrze równoleglić to zamiast 8 słabych rdzeni wystarczyłyby spokojnie 2-3 takie rdzenie do zadań związanych z obsługą OS-a (reszczę ogarnęłoby GPU). Jeśli jednak rację mam ja twierdząc, że czasami mocny wątek się przydaje to lepszym rozwiązaniem byłby procesor o bardziej wyrównanych parametrach (np. coś w stylu AMD Richland 2M/4T ~2500 MHz+).

Przyznaję, że nie wiem jak to wygląda od kuchni, ostatni raz próbowałem coś programować w czasach C64 Patrząc jednak na multiplatformowe gry to jak pokazują testy DF konsole z reguły słabiej wypadają od pecetów z Core i3, podczas gdy ten Core i3 ma do ogarnięcia więcej rzeczy (skomplikowany OS, API...) i wcale nie wyższą teoretyczną sumaryczną wydajność wszystkich rdzeni (w wyliczeniach pomijamy AVX/AVX2 , bo gry tego nie wykorzystują). Więc znowu: albo pewnych rzeczy nie da się dobrze zrównoleglić i rację mam ja, albo developerom nie chce się ich dobrze zrównoleglić, bo uważają to za zadanie zbyt trudne/czasochłonne - a więc teoretycznie rację macie wy, a w praktyce... ja ;P