komentarze
o1838213Zobacz profil
Poziom ostrzeżenia: 0%
o18382132013.01.22, 00:13
-3#61
Amitoza @ 2013.01.21 23:36  Post: 630699
Hamil_Hamster @ 2013.01.21 23:20  Post: 630690
(...)

Dokładnie! Nawet ilość cache się zgadza :D

A w ogóle jakiś znudzony pseudodziennikarzyna zrobił sobie diagram, zaraz kilka kolejnych znudzonych pseudodziennikarzyn podchwyciło i już miliony fanbojów mają mokro w gaciach, z przodu jak i z tyłu.

niby z której strony? w atomie masz na 2 rdzenie 1MBL2, nie na 4 rdzenie współdzielone 2MBL2. Nie wiem jak L1, ale aktualnie atomy mają 32+24, a nie 32+32.


Co do L1 to nigdzie nie znalazłem informacji jak ma być w nowej wersji.

2rdzenie z 1MB to prawie jak 4 z 2MB. Ten nowy Atom ma mieć 2 kanały pamięci na układ a z tej specyfikacji wynika, że będą 4, więc może zamiast jednego 8 rdzeniowego Atoma będą 2 4rdzeniowe w MCP, zresztą z uwagi na dzielenie pamięci z GPU i brak integry atomowej to będzie raczej układ zrobiony na zamówienie na bazie Atoma, o ile oczywiście to będzie Atom co jest tylko moim gdybaniem.
sonioZobacz profil
Poziom ostrzeżenia: 0%
sonio2013.01.22, 00:13
nirvan @ 2013.01.22 00:02  Post: 630708

Pierwszy xbox miał Celerona Coppermine bez żadnych modyfikacji samego rdzenia - różnił się jedynie obudową od wersji dla PC.

ogólnie wszystkie źródła mówią o wersji pentium 3 - z lekka nietypowej. Ale możesz mieć rację że jest to jakiś wyjątek. Z tym że to był KLOC, a nie konsola :P
skoti48Zobacz profil
Poziom ostrzeżenia: 0%
skoti482013.01.22, 00:14
-1#63
nadro-linux @ 2013.01.21 23:56  Post: 630705
Wystarczy sobie poczytać ile np. draw call'i jest ok dla PC, a ile dla konsoli, wtedy część osób uświadomi sobie gdzie tkwi problem tych portów. Komunikacja na poziomie CPU<->GPU jest największym killer'em wydajności aplikacji na PC

Zupełnie nie tam gdzie ją widzisz. DrawCalle głównie cierpią przez narzut na funkcje działające na CPU - żadną komunikacje CPU->GPU. bo drawcalle są wykonywane jak już wszystko ma w pamięci i nic się nie przesyła poza 'narysuj to co masz tu'.
Problem z DrawCallami pod PC jak to nazywasz to problem DX. DX10 przytył mocno i ma ogromne narzuty funkcji, przez co znacznie mniej drawcalli przetrawić potrafi, na tym samym sprzęcie w DX11 jest już lepiej bo to co robi CPU można rozrzucić na wątki (komunikacja z GPU jest dalej taka sama, ale CPU szybciej wykonuje tą pracę), jeszcze lepiej jest na DX9, bo ten nie przetwarzał zbyt wiele danych i narzut funkcji był mały, ale i tak DX9 nie dorównuje w tym względzie OpenGL, który jest tylko API i całą implementacje robi producent karty tworząc znikomy narzut funkcji... ale to i tak nie granice możliwości, bo u Nvidii można zastosować bindless graphics potrafiący przyspieszyć nawet do 7x.
Konsole mają niskie narzuty, bo korzystają z OpenGL lub DX9 - jednak akurat DrawCalle na konsolach działają identycznie jak na PC... co innego przykładowo dynamiczna edycja siatki czy tekstur bo tu się przydaje współdzielona pamięć, i tu konsole mają przewagę nad kartami pod PCI-E.

arval @ 2013.01.22 00:12  Post: 630710
Xbox360 ma pamięć RAM szyfrowaną
http://www.youtube.com/watch?v=uxjpmc8ZIxM
Nie chce mi się marketingowego bełkotu słuchać - jeśli chcesz coś wartościowego podesłać to papierki techniczne możesz podawać, a nie bzdurne filmiki (które znając ostatnie Twoje wywody, źle zrozumiałeś).
Jeśli ma szyfrowaną pamięć (byłaby to niesamowita głupota, pod względem wydajnościowym, bo szybka pamięć gówno całe daje kiedy trzeba czekać na sprzętowy dekoder). Jednak akurat sprzętowo nic nie stoi na przeszkodzie, bo sprzętowe wsparcie dla AES w locie mają zarówno AMD jak i Intel.
AmitozaZobacz profil
Poziom ostrzeżenia: 0%
Amitoza2013.01.22, 00:16
o1838213 @ 2013.01.22 00:13  Post: 630711
Amitoza @ 2013.01.21 23:36  Post: 630699
(...)

niby z której strony? w atomie masz na 2 rdzenie 1MBL2, nie na 4 rdzenie współdzielone 2MBL2. Nie wiem jak L1, ale aktualnie atomy mają 32+24, a nie 32+32.


Co do L1 to nigdzie nie znalazłem informacji jak ma być w nowej wersji.

2rdzenie z 1MB to prawie jak 4 z 2MB. Ten nowy Atom ma mieć 2 kanały pamięci na układ a z tej specyfikacji wynika, że będą 4, więc może zamiast jednego 8 rdzeniowego Atoma będą 2 4rdzeniowe w MCP, zresztą z uwagi na dzielenie pamięci z GPU i brak integry atomowej to będzie raczej układ zrobiony na zamówienie na bazie Atoma, o ile oczywiście to będzie Atom co jest tylko moim gdybaniem.

nadal masz napisane o 2MB współdzielonych na 4 rdzenie, a nie 1MB na 2 rdznie 4 razy.
nirvanZobacz profil
Poziom ostrzeżenia: 0%
nirvan2013.01.22, 00:21
sonio @ 2013.01.22 00:13  Post: 630712
nirvan @ 2013.01.22 00:02  Post: 630708

Pierwszy xbox miał Celerona Coppermine bez żadnych modyfikacji samego rdzenia - różnił się jedynie obudową od wersji dla PC.

ogólnie wszystkie źródła mówią o wersji pentium 3 - z lekka nietypowej. Ale możesz mieć rację że jest to jakiś wyjątek. Z tym że to był KLOC, a nie konsola :P


P3 od Celerona różnił się fizycznie jedynie wielkością pamięci cache (256kb vs 128kb). Dodatkowo miał on wyżej taktowane FSB ale to już jest kwestia ustawień a nie samego rdzenia.

CPU w Xboxie miał 128kb cache więc jest to typowy celeron z podbitym FSB do 133mhz w obudowie micro-pga2 (takiej samej jak wersje mobilne tych procesorów).

Po prostu 'Zmodyfikowany Pentium 3' lepiej brzmiało w specyfikacji niż 'Celeron z podniesionym FSB'. :D

Dodatkowo pewna firma bodajże z USA oferowała przerobione xboxy ze zmienionymi cpu - była nawet wersja z Celeronem Tualatin 1,4ghz (256kb cache) -> http://www.gamestron.com/enhancedxbox.html i wszystko działało jak trzeba co tylko potwierdza to, że sam rdzeń w procku x'a nie został w żaden sposób zmieniony. :)
o1838213Zobacz profil
Poziom ostrzeżenia: 0%
o18382132013.01.22, 00:23
-3#66
nadro-linux @ 2013.01.21 23:56  Post: 630705
A wg mnie specyfikacja ta prezentuje się naprawdę fajnie. Widać, że główną siłą napędową ma być GPU, dla CPU pozostaną tylko te zadania, z którymi faktycznie GPU sobie nie radzi, ew bardzo słabo (w przypadku gier nie jest ich jednak wiele). Wiele osób tutaj ocenia sprzęt na podstawie PC. Kurczę, ile razy można powtarzać, że konsole to nie PC, tam nie ma narzutu sterownika jak w przypadku PC'tów. Pamięć jest współdzielona. Jest sporo sporo wyspecjalizowanych jednostek dla danych zadań. Wygląda na to, że nowa generacja konsol odeśle do lamusa mocne CPU jeśli chodzi o gry. Era kodowania w oparciu o standard DX9.0 (model ten jest bardzo prosty w implementacji, na dodatek zapewnia dużą kompatybilność pomiędzy platformami, stąd też cały czas ma niesamowite udziały na scenie GameDev'u, minus jego jest taki, że wydajność jest tandetna, ale który producent się tym teraz przejmuje...) wreszcie się skończy, dodam tylko, że model ten wymaga mocnej jednostki CPU. Jeśli chodzi o wysokie wymagania portów gier z obecnej generacji konsol na PC, to wypadałoby wziąć pod uwagę, że głównym problemem jest właśnie narzut sterownika. Wystarczy sobie poczytać ile np. draw call'i jest ok dla PC, a ile dla konsoli, wtedy część osób uświadomi sobie gdzie tkwi problem tych portów. Komunikacja na poziomie CPU<->GPU jest największym killer'em wydajności aplikacji na PC. Im więcej rzeczy przerzuci się na GPU tym większe będą z tego korzyści, tak więc model programowania dla przyszłych konsol, które nie będą posiadały mega mocnego CPU powinien sprawić, że porty tych gier na PC nie będą tak bardzo zarzynały stacjonarki.

Kto straci najwięcej? Wygląda na to, że Intel (na scenie gier ich układy nie miałyby już takiego znaczenia jak teraz). Sporo osób wrzuca na architekturę modułową, ale być może AMD liczyło na zgarnięcie rynku konsol (sporo na to wskazuje, że niemal cały rynek będzie ich jeśli chodzi o sprzęt) i tym samym spopularyzowanie pisania gier w oparciu o GPU, przy czym CPU będzie tylko jednostką czysto pomocniczą (do tego mocny pojedynczy wątek nie jest potrzebny). Jeśli chodzi o popularyzację jakiegoś modelu programowania to w walce z Intelem AMD nie ma szans w pojedynkę, ale jeśli po ich stronie znajdą się konsole to sytuacja wygląda już zupełnie inaczej, zwłaszcza na rynku gier wideo. Oczywiście, czy tak będzie, czas pokaże. Aczkolwiek takie można odnieść wrażenie po analizie całej sytuacji.


Ale tu jest mowa o GPU porównywalnym do współczesnych mainstreamowych a mówimy o konsoli, która ma być na rynku przez kilka lat.
Jasne, że konsola ma mniejszy narzut... ale topowy PC będzie miał GPU kilka razy wydajniejsze w chwili premiery konsoli, więc za 5 lat to i 20 razy wydajniesze.
sonioZobacz profil
Poziom ostrzeżenia: 0%
sonio2013.01.22, 00:27
nirvan @ 2013.01.22 00:21  Post: 630717

Po prostu 'Zmodyfikowany Pentium 3' lepiej brzmiało w specyfikacji niż 'Celeron z podniesionym FSB'. :D

zresztą co za różnica - przecież dziś pomiędzy i7 a celeronem na jednej podstawce też nie ma zbytnich różnic w budowie pojedynczego rdzenia - a wtedy? był to procek wypośrodkowany - pewnie kolejny odpad po P3 jak celerony
sevaeZobacz profil
Poziom ostrzeżenia: 0%
sevae2013.01.22, 00:32
Jak przewidujecie kwestie portów z tego na Power w Wii U (albo może odwrotnie będzie trzeba robić :P )?

Jeżeli będą to procki AMD/Intel to myślicie, że będą to czyste x86 czy może trochę namieszają w tej kwestii?

Kwestia silników w które zainwestował Epic i CryTec. Miały być potrzebne bo inaczej inwestycje własne studiów zbyt dużo by pochłonęły, mnie się wydaje że chyba w takiej konfiguracji to obecne silniki ładnie i tanio można dostosować do takiego sprzętu, a takie Epic raczej zadowolone nie będzie.
nirvanZobacz profil
Poziom ostrzeżenia: 0%
nirvan2013.01.22, 00:35
sevae @ 2013.01.22 00:32  Post: 630722
Jak przewidujecie kwestie portów z tego na Power w Wii?


Ciężko cokolwiek powiedzieć bo tak na prawdę to nie wiadomo co w tym WiiU siedzi - wiadomo tylko, że jest to PowerPC ale całej reszty Nintendo strzeże jakby to były numery kart kredytowych kadry kierowniczej...
sevaeZobacz profil
Poziom ostrzeżenia: 0%
sevae2013.01.22, 00:38
nirvan @ 2013.01.22 00:35  Post: 630723
sevae @ 2013.01.22 00:32  Post: 630722
Jak przewidujecie kwestie portów z tego na Power w Wii?


Ciężko cokolwiek powiedzieć bo tak na prawdę to nie wiadomo co w tym WiiU siedzi - wiadomo tylko, że jest to PowerPC ale całej reszty Nintendo strzeże jakby to były numery kart kredytowych kadry kierowniczej...

Chyba jest chociaż jeden osobnik na tym forum co pracuje gdzieś gdzie przysłali im to Wii U i może iść z ciekawości zapoznać się z tym i podać tu jakieś bardziej oficjalne dane. Czy zakaz jest... czy może programiści nie wiedzą co mają???
sesefZobacz profil
Poziom ostrzeżenia: 0%
sesef2013.01.22, 00:38
sevae @ 2013.01.21 22:51  Post: 630673
To na pewno nie są dwa moduły Power7? (no wiem że info pewnie z (_!_) ale i tak większość lubi ploty).


Ja bym powiedział ze to sklejka z dwóch 4 rdzeniowych Jaguarów.
skoti48Zobacz profil
Poziom ostrzeżenia: 0%
skoti482013.01.22, 00:45
nirvan @ 2013.01.22 00:35  Post: 630723
Ciężko cokolwiek powiedzieć bo tak na prawdę to nie wiadomo co w tym WiiU siedzi - wiadomo tylko, że jest to PowerPC ale całej reszty Nintendo strzeże jakby to były numery kart kredytowych kadry kierowniczej...

Z tego co wiem jest to procesor wspólnie opracowany przez Nintendo i IBM o nazwie kodowej 'Espresso' - oparty o PowerPC 750 tak jak poprzedni (Broadway), ale ma 3x rdzenie, zamiast jednego jak w Wii i ma 1.24GHz zamiast 0.73GHz + AMD Radeon 550MHz o nazwie kodowej 'Latte', ale o niej prawie nic nie wiadomo. Podsumowując projektanci musieli dużo kawy wypić, że takie nazwy wybrali ;p.
sevaeZobacz profil
Poziom ostrzeżenia: 0%
sevae2013.01.22, 00:50
skoti48 @ 2013.01.22 00:45  Post: 630727
nirvan @ 2013.01.22 00:35  Post: 630723
Ciężko cokolwiek powiedzieć bo tak na prawdę to nie wiadomo co w tym WiiU siedzi - wiadomo tylko, że jest to PowerPC ale całej reszty Nintendo strzeże jakby to były numery kart kredytowych kadry kierowniczej...

Z tego co wiem jest to procesor wspólnie opracowany przez Nintendo i IBM o nazwie kodowej 'Espresso' - oparty o PowerPC 750 tak jak poprzedni (Broadway), ale ma 3x rdzenie, zamiast jednego jak w Wii i ma 1.24GHz zamiast 0.73GHz + AMD Radeon 550MHz o nazwie kodowej 'Latte', ale o niej prawie nic nie wiadomo. Podsumowując projektanci musieli dużo kawy wypić, że takie nazwy wybrali ;p.

Tylko to nic pewnego jest (poza nazwami z cafe i trzech rdzeni PowerPC). Jedyne pewne ponad te szczątkowe dane to to że CPU i GPU mają eDRAM własny i to że CPU to ~33mm2 w 45nm a GPU to ~180mm2 od AMD w 40nm. I że na płytce są razem plus jakaś mała dodatkowa kostka.
nadro-linuxZobacz profil
Poziom ostrzeżenia: 0%
nadro-linux2013.01.22, 00:51
skoti48 @ 2013.01.22 00:14  Post: 630713
nadro-linux @ 2013.01.21 23:56  Post: 630705
Wystarczy sobie poczytać ile np. draw call'i jest ok dla PC, a ile dla konsoli, wtedy część osób uświadomi sobie gdzie tkwi problem tych portów. Komunikacja na poziomie CPU<->GPU jest największym killer'em wydajności aplikacji na PC

Zupełnie nie tam gdzie ją widzisz. DrawCalle głównie cierpią przez narzut na funkcje działające na CPU - żadną komunikacje CPU->GPU. bo drawcalle są wykonywane jak już wszystko ma w pamięci i nic się nie przesyła poza 'narysuj to co masz tu'.
Problem z DrawCallami pod PC jak to nazywasz to problem DX. DX10 przytył mocno i ma ogromne narzuty funkcji, przez co znacznie mniej drawcalli przetrawić potrafi, na tym samym sprzęcie w DX11 jest już lepiej bo to co robi CPU można rozrzucić na wątki (komunikacja z GPU jest dalej taka sama, ale CPU szybciej wykonuje tą pracę), jeszcze lepiej jest na DX9, bo ten nie przetwarzał zbyt wiele danych i narzut funkcji był mały, ale i tak DX9 nie dorównuje w tym względzie OpenGL, który jest tylko API i całą implementacje robi producent karty tworząc znikomy narzut funkcji... ale to i tak nie granice możliwości, bo u Nvidii można zastosować bindless graphics potrafiący przyspieszyć nawet do 7x.
Konsole mają niskie narzuty, bo korzystają z OpenGL lub DX9 - jednak akurat DrawCalle na konsolach działają identycznie jak na PC... co innego przykładowo dynamiczna edycja siatki czy tekstur bo tu się przydaje współdzielona pamięć, i tu konsole mają przewagę nad kartami pod PCI-E.

Właśnie tam. Jeśli chodzi np. o drawCall (oczywiście nie tyczy się to tylko drawcall'i lecz ogólnie wszystkich funkcji zmiany stanu GPU, oczywiście jedne są tańsze, drugie droższe) to, czy ja pisałem o przesyłaniu dużych bloków danych do pamięci GPU? Bez urazy, ale czytaj dokładnie, a nie przeinaczasz moje słowa :) CPU za pośrednictwem sterownika wywołuje dane polecenie GPU. Jak dla Ciebie nie jest to komunikacja CPU->GPU to nie mam dalszych pytań... Obojętnie jaki by nie był narzut (fakt DX10 ma ogromny narzut, ale cały przebieg generowania obrazu można w większym stopniu przerzucić na GPU, niż w przypadku DX9, a to jest ogromna zaleta; OGL wypada tutaj zdecydowanie najlepiej stąd też programuję właśnie w oparciu o to API, a nie DX, na dodatek liczy się dla mnie przenośność między platformami, ale to tak na marginesie) to wydajniej zwykle jest puścić większość na GPU (wliczając w to zarządzanie sceną, czyli np. frustum na geometry shader, czy poziom LOD przy użyciu tesselatorów w przypadku układów DX11/OGL4), niż bawić się w przełączanie stanów karty, bo jak już pisałem to zabija niesamowicie wydajność (oczywiście nie tyczy się to 100% przypadków, bo czasami przełączanie stanów karty jest nieuniknione).

Jeśli chodzi o bindless to faktycznie fajna sprawa, zwłaszcza dla platform ze słabym CPU i mocnym GPU, ale 7x to przypadki bardzo niszowe. Tutaj bardzo dużo zależy od struktury danej produkcji, jedna zyska więcej, a druga bardzo mało (aczkolwiek zysk zawsze powinien być, więc rozszerzenie jest jak najbardziej na plus z mojej perspektywy, problem taki, że jest NV only, w przyszłości jednak rozwiązanie tego typu działające zarówno na układach NV/AMD powinno się pojawić, aczkolwiek wiadomo, że to co jest uniwersalne z reguły bywa mniej wydajne od rozwiązań dedykowanych).

BTW. Konsole z OpenGL/DX nie korzystają jako takiego. PS3 to libGCM, XBox 360 to bardzo zmodyfikowany DX9, a Wii to GX, który faktycznie przypomina OGL'a, ale do końca nie można tego nim nazwać. Z tego co pamiętam to w jakiejś prezentacji Guerilla Games był fajnie przedstawiony narzut sterownika na wywoływanie poleceń GPU w przypadku PC'ta i porównany do sytuacji z konsoli PS3. Różnica była ogromna i chodziło tam właśnie o sam narzut sterów.

BTW2. Nawet w przypadku OpenGL jak już pisałem narzut jest problemem bardzo dużym. Świetnie widać to na przykładzie instancing'u, który ma za zadanie właśnie zredukować zbędne drawCall'e. W necie jest masa wyników ukazująca korzyści z redukcji wywołań poleceń GPU.
skoti48Zobacz profil
Poziom ostrzeżenia: 0%
skoti482013.01.22, 01:13
-4#75
nadro-linux @ 2013.01.22 00:51  Post: 630729
Właśnie tam. Jeśli chodzi np. o drawCall (i nie chodzi tylko o drawcall'e tylko ogólnie o wszystkie funkcje zmiany stanu GPU) to, czy ja pisałem o przesyłaniu dużych bloków danych do pamięci GPU? Bez urazy, ale czytaj dokładnie, a nie przeinaczasz moje słowa :) CPU za pośrednictwem sterownika wywołuje dane polecenie GPU. Jak dla Ciebie nie jest to komunikacja CPU->GPU to nie mam dalszych pytań...

Mylisz komunikacja CPU->GPU, z przetwarzaniem danych na CPU przez bibliotekę, przed komunikacja z GPU ;p.

nadro-linux @ 2013.01.22 00:51  Post: 630729
fakt DX10 ma ogromny narzut, ale cały przebieg generowania obrazu można w większym stopniu przerzucić na GPU, niż w przypadku DX9, a to jest ogromna zaleta

Nic podobnego nie robi. Czy to DX9 czy to DX10 cały przebieg generowania obrazu jest tylko i wyłącznie na GPU. Jedynie może lepiej przetworzyć dane, aby to GPU miało dane lepiej dla siebie przystosowane (czyli wręcz przeciwnie zabrać trochę pracy z GPU na CPU, przez co więcej czasu na CPU spędza).

nadro-linux @ 2013.01.22 00:51  Post: 630729
niż bawić się w przełączanie stanów karty, bo jak już pisałem to zabija niesamowicie wydajność (oczywiście nie tyczy się to 100% przypadków, bo czasami przełączanie stanów karty jest nieuniknione).

Niestety to w równym stopniu dotyka też konsol. Jedynie jest mniejszy narzut niż w takim DX10/11 przez co wydaje się, że różnica jest ogromna (a to nie wina PC tylko API, że na CPU spędzają tyle czasu zanim zaborą się do przekazania karcie danych, podczas gdy w konsolach czy OpenGL jest to robione prawie natychmiast).

nadro-linux @ 2013.01.22 00:51  Post: 630729
BTW. Konsole z OpenGL/DX nie korzystają jako takiego. PS3 to libGCM, XBox 360 to bardzo zmodyfikowany DX9, a Wii to GX, który faktycznie przypomina OGL'a, ale do końca nie można tego nim nazwać.

W PS3 masz tak zwany PSGL czyli GLES1.1 z wyciętym fixed pipeline językiem Cg i kilkoma zmianami. To, że masz libGCM nic nie zmienia - z nim komunikuje się PSGL i masz jak na PC - podobnie masz w PC - przykładowo program komunikuje się z opengl32.dll ten z atioglxx.dll lub nvoglv32.dll a te dopiero z najniższą warstwą czyli sterownikiem do karty graficznej zarządzającym command bufforem. To wszystko jest tożsame. Jednak w PS3 możesz mieć mniejszy narzut poprzez pominięcie zupełne OpenGL i manipulowanie na Command Bufforze (pominięcie narzutu na CPU, zaraz przed komunikacją z GPU i wrzucanie na GPU bezpośrednio - nie może się to równać z bindless graphics, które zmniejsza samą wymaganą komunikacje i bindowanie siatek/tekstur/itp).
W Xbox360 API wiele się nie zmieniło - trochę implementacja jest okrojona przez co jest mniejszy narzut na CPU (ale jeszcze przed komunikacją z GPU).
TrepciaZobacz profil
Poziom ostrzeżenia: 0%
Trepcia2013.01.22, 01:18
Przecież procesor to wypisz wymaluj - sklejka dwóch Jaguarów 4 rdzeniowych.
SNC2013.01.22, 01:22
-3#77
Skoro jest taki mniejszy narzut wywolywania funkcji w OpenGlu to dlaczego wiekszosc benchmarkow (przynajmniej ja tak kojarze) ktore wyszly zarowno pod Dx jak i Ogl chodzi lepiej na Dx?
nadro-linuxZobacz profil
Poziom ostrzeżenia: 0%
nadro-linux2013.01.22, 01:44
@Skoti
Z Tobą czasem strasznie ciężko się dyskutuje :P Na dodatek wmawiasz mi, mylenie pojęć... Naprawdę sprawę trzeba rozpisywać krok po kroku? A więc tak:
Dajmy na to OpenGL'a... Tutaj nic nie jest przetwarzane przez CPU (w DX faktycznie dochodzi jeszcze durny narzut, o którym wspominasz) wszystko leci bezpośrednio do sterownika a ten zarządza stanem GPU (jest to w pełni komunikacja na linii CPU->GPU i o tym piszę od samego początku). W tym miejscu wydajność drastycznie spada (przełączanie stanów GPU jest bardzo kosztowne o czym też gadam od pierwszego postu). Jak duża jest skala problemu dobrze widać np. na przykładzie instancing'u (tak, więc nie pisz, że na OGL wywoływania są tanie bo tak nie jest, aczkolwiek są tańsze niż na DX), który jak zapewne większość osób wie służy do redukcji niepotrzebnych drawCall'i... Jakie korzyści to przynosi jeśli chodzi o wydajność? W sieci jest masa wyników, ale różnica jest ogromna. Z mojej strony to tyle, na dłuższe pogawędki po prostu nie mam czasu :)

PS. Nie musisz mi tłumaczyć struktury API (jak tym razem w przypadku z PSGL), temat GD od dłuższego czasu nie jest mi obcy (swoją drogą ostatnio nawet optymalizowałem pewien silnik graficzny jeśli chodzi o narzut wywołań OGL'a), tym się zajmuję na co dzień podobnie chyba jak zresztą Ty :P Aha co do PS3... PSGL nikt nie używa, właśnie libGCM jest warstwą niższego poziomu z której masz dostęp właśnie do command buffor'a :P Stąd też można powiedzieć, że na PS3 OGL'a nie ma (niby jest, ale bezużyteczny).
Eryk PiastZobacz profil
Poziom ostrzeżenia: 0%
Eryk Piast2013.01.22, 02:06
Cztery moduły 'Piledriver' to chyba jednak bardziej prawdopodobny scenariusz od Jaguara. Ale co ja tam wiem...
hajapackageZobacz profil
Poziom ostrzeżenia: 0%
hajapackage2013.01.22, 02:22
-5#80
Bzdura, nowy Xbox nie będzie wiele wydajniejszy od poprzednika. Prawdopodobnie APU od AMD. To ma być tanie w produkcji i ma dobrze sie sprzedawać. Miniaturyzacja wymiarów i odrobinę większa wydajność wystarczą by podbić rynek znaną już marką..
Zaloguj się, by móc komentować