Konsola nowej generacji Microsoft’u dostanie APU II?

1. napewno (autor: robgrab | data: 6/12/10 | godz.: 07:39)
   dostanie apu, napewno tez bedzie to architektura ppc a nie x86. Tak na oko grafika powinna byc okolo 100-200x wydajniesza niz ta z x360 zeby uzyskac w fhd z aax4 w 3d okolo 30-40 wieksza wydajnosc niz poprzednik. Patrzac na obecne gpu nie bedzie z tym problemu za 2-3lata. Gorzej z czescia cpu. Tu powinien byc skok jak z ps2>ps3 lub x>x360 czyli okolo 10-20. Skoro to jest 3x3,2ghz to powinni dac z 12-16rdzeni i wyzsze taktowanie. Czy to jest realne w takim czasie?
   
   
2. ... (autor: xlg | data: 6/12/10 | godz.: 07:49)
   fajne wyliczenia. tam 10-20x lepsze, tu 30-40x wydajniejsze tylko jest jedna kwestia ... co na to barbara streisand
   
   
3. ... (autor: Aamitoza | data: 6/12/10 | godz.: 07:52)
   Konsola jest ograniczona TDP. X360 miał je na poziomie poniżej 200W i był już głośny - tutaj na pewno na większym poziomie nie będzie. Sprawa 2 - jak zwrócili się do AMD, to PPC całkowicie odpada z 2 powodów - gdyby chcieli PPC to nie zwrócili by się do AMD tylko IBM, a po 2 dlatego, że ta rodzina nie jest już rozwijana - power7 to nie powerPC. A 2 generacja APU = bulldozer.
   
   Poza tym wzrost mocy układu graficznego o 100-200x? najzabawniejszy tekst dzisiejszego dnia. Obecnie najszybsze karty nie są nawet tyle szybsze od tego co siedzi w X360, a fakt jest taki, że Xbox będzie miał ograniczone TDP, więc i wydajność GPU. Na PC do fullHD z AAx4 w 90% gier wystarczy HD6850/GTX460, więc nie spodziewał bym się mocniejszego układu, szczególnie, że w konsolach wszystko jest mocno optymalizowane i nie ma odzwierciedlenia w przypadku PC.
   
   
4. ... (autor: Wujofefer | data: 6/12/10 | godz.: 08:54)
   Obecne konsole cierpią przede wszystkim ze względu na GPU, które bardzo szybko się zestarzały, znacznie szybciej niż ich procesory, które mimo upływu czasu dalej są na dość dobrym poziomie wydajności.
   To właśnie GPU powinno być super wydajne, nie zdziwiłbym się jakby APU 2 miało 100x mocniejsza grafe od tej z X360. W końcu w momencie premiery tzw. X720 będzie między nimi prawie 10 lat różnicy (M$ podczas premiery mówił o 5-7 latach żywotności X360 jednak teraz mówi się o 8-10 latach).
   100 krotny wzrost wydajności na GPU i kilkudziesięciokrotny na CPU... te liczby są nawet realne.
   
   ps. a jakby ktoś nie wierzył, porównajcie poczciwe PS2 z PS3 :)
   
   
5. @Wujofefer (autor: Promilus | data: 6/12/10 | godz.: 10:02)
   Tyle, że moc obliczeniowa Xenosa to ok 250GFLOPS a top AMD obecnie 2.7TRFLOPS to niby gdzie ten super extra 100x wzrost? Teraz gdyby zawęzić to do TEGO SAMEGO TDP to nagle okazuje się, że wzrost wydajności SP jest tylko 4 krotny! Jasne, przy okazji zwiększyła się kilkukrotnie wydajność ROP i TMU, ale bez przesady. To czego next gen potrzebuje to GPU z max 60-70W, dobrą teselacją. Do tego jakieś 1,5TFLOPS-2TFLOPS mocy obliczeniowej i elastyczne jednostki programowalne zgodne w pełni z OCL1.1+
   A dlaczego właśnie tak? Ano to proste. MSAA się kończy, jest coraz trudniej w nowych produkcjach z deferred rendering załatwić AA dla każdej krawędzi. Bardzo duże nadzieje niesie MLAA, raz że jest mniej czasochłonne (obliczeniowo), dwa że przy odpowiednej implementacji wygląda lepiej niż jakiekolwiek MSAA z obecnej generacji konsol (tj. 4x max). W końcu pierwotnie intel to do larrabee chciał wsadzić więc musiało być dobre. I jest, widać to na PS3 i na większości gier DX9 odpalanych na HD5k/6k z MLAA (+adaptive aa). Niemniej gry potrzebują implementacji w środku, a nie z poziomu sterownika, bo jednak rozwiązanie AMD boryka się też z problemami (rozmazywanie czcionek, hud, bodajże brak uwzględnienia kanału alpha). Zatem fizyka, AA, a kto wie, może i AI lecące na GPU. To wymaga odpowiedniej mocy obliczeniowej i odpowiedniego wykorzystania zasobów (concurrent threads execution). Dlatego proc w next gen będzie miał stosunkowo mało do roboty jeśli chodzi o intensywne obliczenia, a jedynie będzie kontrolował przepływ danych itp. Nie wiem jak wygląda w praktyce nowa generacja AMD jeśli chodzi o obliczenia dlatego trudno wyrokować, ale NV ma dość dobre możliwości by sprzedać swoje rozwiązania do konsoli nowej generacji.
   
   
6. @ Aamitoza (autor: robgrab | data: 6/12/10 | godz.: 10:02)
   x86 odpada bo : 1 - powinien byc zgodny przynajmniej na poczatku z xbox360 zeby odpalac czesc gier z niego. 2 - w konsoli najwazniejsza jest moc i ekonomia, nie potrzeba marnowac krzemu na dekoder instrukcji cisc x86 na wewnetrzne risc, tak samo jak nie potrzebne jest wykonywanie poza kolejnoscia bo to nie system wielozadaniowy.
   A gpu 100-200x ? mozliwe jak najbardziej. Xbox 360 ma 48 rdzeni w konfigu 2+1 podczas gdy radek 5870 ma 320 rdzeni w konfigu 4+1,do tego zegar 500mhz vs 850mhz, a co bedzie za 2-3 lata?. Piszesz ze do fhd wystarczy w 90% 6850/gtx460. Czlowieku ty myslisz kategoriami pc. Konsola to nie pc, gdzie co roku wymieniasz sobie hardware. Ten sprzet ma pozwalac na zabawe i produkcje nowych aktrakcyjnych gier przez kolejne 7-10lat. Wyobrazasz sobie pc z 6850, ktory za 10lat odpala jaka kolwiek gre?
   
   
7. Wątpię aby Microsoft dał się nabrać na APU (autor: pomidor | data: 6/12/10 | godz.: 10:04)
   W Fusion II będą relatywnie słabe rdzenie Buldozera i jakiś obcięty GPU, który nadaje się do paroletnich gierek w low-res. Poza tym MS zależy na kompatybilności z XBX360, więc raczej nie wejdzie w x86. Pewnie dalej będzie tam PPC i odpowiednio wydajnym osobnym GPU.
   
   
8. bardzo słuszne podejście zaprezentował Microsoft (autor: Qjanusz | data: 6/12/10 | godz.: 10:11)
   CPU + GPU od AMD, produkcja krzemu w Globalu - gwarant bezpieczeństwa i braku jakichkolwiek problemów technicznych i strzelania fochów przez partnerów (nVidia, Intel).
   
   Fusion II będzie wyposażony w Bulldozera, więc instrukcje x86 będą umożliwiały niemal natywne porty z konsolki na piece. Poza tym mocy aż nadto do emulacji otoczenia do starego x360 bazującego na PPC os IBMa, o pierwszych Xach nie wspominając.
   
   Część graficzna to murowany hit. AMD jako producent najwydajniejszych grafik do kompów, oraz największy i najmniej konfliktowy producent GPU do konsol (M$, Nintendo), ma prosta i przetartą ścieżkę do nowych kontraktów na takie projekty, jako najbardziej profesjonalny kontrahent, ze wszystkich dostępnych na rynku.
   
   Ostatnią kwestią jest prostota płytki i konstrukcji samej konsolki. CPU+GPU+kontroler pamięci w jednej kostce krzemu produkowanej w 28nm, może być gwarancją nieskomplikowanej płytki głównej, co automatycznie przekłada się zmniejszone koszty serwisu, czyli prostego przełożenia na wizerunek firmy.
   
   
9. grafika wzrost 100X (autor: Qjanusz | data: 6/12/10 | godz.: 10:17)
   niemożliwe!
   
   nawet mimo tego, że produkcja Fusion będzie odbywała się w 28nm
   Nie wiadomo też, jaką różnice w wydajności (nawet teoretyczną) zaprezentuje nam NI od AMD. Bo można spokojnie założyć, że to on (bądź poprawiona jego wersja) będzie robił za rdzeń GPU w Fusion II
   
   
10. @Qjanusz (autor: pomidor | data: 6/12/10 | godz.: 10:22)
    Jaki piękny tekst wypisałeś. Nawet marketingowcy z AMD znaleźli by tu wiele inspiracji. Nie ma to jak rasowy fanboj :)
    
    
11. @pomidorek (autor: Qjanusz | data: 6/12/10 | godz.: 10:33)
    Tobie go dedykuję ;-)
    
    
12. @pomidor (autor: stud3nt | data: 6/12/10 | godz.: 10:39)
    Przyganiał kocioł garnkowi :P
    
    
13. @pomidor (autor: emuZ | data: 6/12/10 | godz.: 10:39)
    Bo Qjanusz to fanboj z klasą. A ty jesteś bez klasy. ;)
    
    
14. @emuZ (autor: Promilus | data: 6/12/10 | godz.: 11:11)
    bez klasy, bez szkoły... ale ma internet ;)
    
    
15. pomidorek to... (autor: Qjanusz | data: 6/12/10 | godz.: 11:11)
    fanbój co najwyżej z "Naszą klasą"
    
    ;-)
    
    
16. @Promilus (autor: Mariosti | data: 6/12/10 | godz.: 11:18)
    Sensownej wydajności gpu z ograniczony tdp nvidia nie ma, a w mocno zoptymalizowanych względem sprzętu środowiskach architektura radeonów jest bez porównania bardziej wydajna od gf'ów (słabo zoptymalizowany kod mało traci na skalarnych gpu w porównaniu do wektorowych).
    
    
17. @Promilus (autor: Wujofefer | data: 6/12/10 | godz.: 11:27)
    Dobra ale to jest teraz. Mają jeszcze parę lat, przed nimi jeszcze ze 2, 3 generacje grafik (jak nie więcej), podobnie z CPU.
    Nie porównuj Xenosa do obecnych grafik, bo z pewnością żaden radeon serii 5xxx/6xxx nie będzie tam siedzieć.
    AMD będzie miało masę czasu na opracowanie specjalnej odmiany APU dla M$ i X720, z pewnością będzie to w swoim czasie niedostępna dla PC super konfiguracja (podobnie jak to było przy premierze X360).
    Konsola w momencie premiery musi przewyższać wszystko co jest dostępne na rynku i ma wystarczyć na lata, to nie może być średniej klasy sprzęt.
    Po za tym M$ zdecydował się na AMD bo Intel i Nvidia nie chciały sprzedać licencji na swoje chipy, IBM i ATI zgodziły się na to, teraz pewnie będzie podobnie.
    AMD zaprojektuje i odsprzeda licencje, GF będzie produkować układy a AMD zajmie się poprawianiem za kase z M$ układu i zmniejszaniem procesu technologicznego wraz z GF.
    
    ps. zgadzam się z robgrab. :)
    
    ps2. Nie zdziwiłbym się jakby sam chip pobierał jakieś 200-300W mocy i miał wielkie chłodzenie, równie duże jak to co znamy z topowych grafik. W końcu w konsolach nie obowiązuje już ograniczenie ok 125-135W na jednostkę centralną, aby tylko była cicha i wydajna :)
    
    
18. @Mariosti (autor: Promilus | data: 6/12/10 | godz.: 11:29)
    Chyba nie widziałeś Fermi mobile... inaczej byś gadał...
    [quote]a w mocno zoptymalizowanych względem sprzętu środowiskach[/quote]
    To nie o środowisko chodzi, nie ze środowiskiem jest problem. W OpenCL AMd może być również szybsze od NV ale w rozwiązaniu określonych problemów gdzie nie trzeba super dostępu do lokalnej pamięci, nie ma dużo równolegle wykonywanych kerneli, a dane wejściowe pięknie wypełniają jednostki VLIW. Ale tak jest niezbyt często dlatego nawet 2.72TFLOPS w typowych aplikacjach GPGPU bywa wolniejsze od ~1.2-1.4TFLOPS Fermi. Rozumiesz? VLIW4 trochę zmieni, lepszy LDS, L1 cache, L2 cache również. Ale nadal peak flops nie znajdzie bezpośredniego przełożenia na wyniki radeonów.
    
    
19. @qjanusz (autor: robgrab | data: 6/12/10 | godz.: 11:43)
    ty serio mowisz o x86? Ze niby bulldozer nawet 8-12rdzeniowy jest w stanie zaemulowac software'owo 3 dwuwatkowe rdzenie ppc dzialajace z zegarem 3,2ghz??? Procek z xbox przy operacjach pojedynczej precyzji simd ma peakpower ponad 100gflops. Pomysl jak dobrze dzisiejszym procka x86 idzie emulacja ps2(300mhz, 6,3gflopsa) i zastanow sie jakie bzdury piszesz.
    
    
20. @robgrab (autor: Qjanusz | data: 6/12/10 | godz.: 12:08)
    dlaczego uważasz że emulacja musiałaby przechodzić przez dekoder x86? Przecież ten kanał to największa kula u nogi i źródełko kiepskiej emulacji na platformie x86 jako całości.
    
    AMD może nawet stworzyć niewielką warstwę do natywnego wykonywania instrukcji Xenona.
    
    "PC programs are written using x86 instructions, but nowadays the CPU Execution unit only understands proprietary RISC-like instructions. So the Decode unit is in charge of converting the x86 instructions provided by the program running into these RISC-like microinstructions, which are the kind of instruction understood by the Execution unit of the CPU"
    http://www.hardwaresecrets.com/...rchitecture/1078
    
    resztą polecam linka w całości .
    
    
21. @Promilus (autor: Mariosti | data: 6/12/10 | godz.: 12:20)
    No widzisz, o to chodzi że sam piszę w ocl'u i wiem że zasadniczo jeśli coś da się zrównoleglić na tyle aby chodziło wydajnie na skalarnych gf'ach, nie ma problemu aby choćby porollować pętle do typów wektorowych co automatycznie powoduje wypełnienie VLIV5. Dokładnie o to chodzi że w konsolach jest jedno gpu i wszystko pisze się dokładnie pod nie. Gry muszą chodzić i na gf'ach i na radeonach, a jak wiadomo radeony nawet wykonując same skalarne opy są porównywalne wydajnościowo z gf'ami.
    
    
22. @ad (autor: Mariosti | data: 6/12/10 | godz.: 12:21)
    *gry na pc'ty muszą chodzić...
    
    
23. @Qjanusz (autor: Promilus | data: 6/12/10 | godz.: 12:29)
    Bo musiałaby. Na nóżki procesora mają wchodzić sygnały reprezentujące rozkazy x86 i dane... i to dalej wchodzi do dekodera, koniec kropka. Co prawda są tryby diagnostyczne do debugowania procka (jak np. dostęp przez odpowiedni interfejs do rejestrów wewnętrznych jak to bywa np. przez JTAG u TI) ale tego się NIE stosuje w normalnym użytkowaniu! Poza tym wewnątrz buldożerka jest pewnie z 3x mniej rejestrów niż u Xenona, inny endian (choć ppc chyba akceptuje oba), inna konstrukcja VMX w stosunku do AVX/SSE. (np. 128 rejestrów VMX kontra ledwie 16 w AVX). Nie oszukuj się! RISC like nie oznacza RISC. Power6 już miał rozkazy RISC tłumaczone na 2-3 mikroinstrukcje, a myślę że i wcześniejsze również (choć najwięcej było 1:1). Obecne proce mają problem w JIT zaemulować 68060@100MHz z AGA a ty byś chciał 100x bardziej zaawansowanego proca emulować...
    
    
24. qjanusz (autor: robgrab | data: 6/12/10 | godz.: 12:31)
    To to ja wiem, tylko pozbawienie decodera x86 da prockowi duzego przyspieszenia(ale to juz nie bedzie x86). Zreszta po co wogole w konsoli ktora nie musi byc z niczym kompatybilna(no moze ze swoja poprzedniczka na poczatku) 25architektura x86? MS juz probowal tego w xbox1 i nie wypalilo dlatego w 360 jest ppc
    
    
25. tyle że ja wcale nie piszę o wykastrowaniu tego Fusion z dekodera (autor: Qjanusz | data: 6/12/10 | godz.: 12:56)
    w ogóle nie zakładam że taka wersja Fusion II jaka będzie dostępna w XBox, będzie dostępna na rynku.
    
    historia pokazała, że chyba poza Cellem, nie ma przypadku sprzedaży konkretnego klocka z konsolki rzuconego na rynek konsumencki.
    
    x86 może działać równolegle. I Raczej będzie, bo jak ktoś chyba napisał, x86 jest głównym targetem Microsoftu.
    
    @Promilus - jak wyżej. Nie wiadomo co w tej wersji AMD może dorzucić. To duży projekt i wielka sprawa. Zakładam że nie będą marudzić że się nie da. Wg mnie udostępnienie rejestrów przez specjalnie do tego celu zaprojektowaną warstwę, jest jak najbardziej techniczne możliwe. Ot dodanie trybu, który mógłby być wspomagany kilkukrotnie potężniejszym GPU (DirectCompute???), który w trybie x360 zanudziłby się na śmierć.
    
    I nie pisz mi że Xenon to 100X 68060.
    AGA z kolei to wysiłek na miarę zbuczka graficznego sprzed ery HD. Nawet ze sporym zapasem.
    
    
26. @up/edit (autor: Qjanusz | data: 6/12/10 | godz.: 13:05)
    może to nie najlepszy przelicznik, ale 68060 to 1.33 instrukcji na cyknięcie, a Xenon robi tylko 6.
    
    Z kolei AMD Phenom II X4 to 14.3.
    
    
27. @robgrab (autor: Qjanusz | data: 6/12/10 | godz.: 13:10)
    "25architektura x86? MS juz probowal tego w xbox1 i nie wypalilo dlatego w 360 jest ppc"
    
    w pierwszym xboxie tak na prawdę nie wypaliła grafika od nieVidii. xbox2 to era kiepskich x86, dlatego były zastosowane o wiele wydajniejsze PPC. Ale coś za coś. Sony przekombinował i przypłacił długotrwałym szkoleniem programistów, a M$ (również i Sony) kiepskimi portami na pieca.
    
    
28. @Qjanusz (autor: Promilus | data: 6/12/10 | godz.: 13:11)
    Weź sobie ściagnij WinUAE, odpal, skonfiguruj i zobacz jak wymagające appsy lecą na emulacji. Tak, emulacji starego zbuka z mniejszymi możliwościami niż S3 Trio 64 + Pentium 75! Żeby emulacja miała sens musiałaby być JIT i 100% czyli ABSOLUTNIE WSZYSTKO musiałoby być tak samo... czas wykonania konkretnych rozkazów również. Ani szybciej, ani wolniej. Czas reakcji na dane przerwanie. Czas dostępu do pamięci. Itp. Itd. I to pochłania OGROM MOCY OBLICZENIOWEJ. To nie jest sama prosta translacja rozkazów!! Można napisać program, który przetłumaczy szybko rozkazy PPC i dopasuje x86, ale to GÓWNO DA, bo wykonanie danej części programu PPC będzie miało zupełnie różny czas na x86. Nie rozumiesz? Trudno.
    
    
29. i jeszcze dodam (nazbierało się tego) (autor: Qjanusz | data: 6/12/10 | godz.: 13:14)
    że Fusion będzie musiał być przekonstruowany w stosunku do tego dostępnego na rynku,
    chociażby z racji tego, że nie wyobrażam sobie w kolejnym next-genie DDR3 jako podstawowego interfejsu do pamięci.
    To jest stanowczo za mało.
    
    
30. @robgrab (autor: Aamitoza | data: 6/12/10 | godz.: 13:16)
    Czy mamy obecnie układ który jest przynajmniej20x mocniejszy od xenosa? Nie widziałem takiego.
    
    HD5870 ma 11x wększa moc shadeów (2.7Tflops vs 250Gflops) wydajnośc ROP 6x większa (przy tych samych zegarach 4x większa) a teksturowania 8 razy.
    
    W grach różnica miedzy kartami ze średniego segmentu z przed 5 lat, a HD5870 nie jest nawet 10cio krotna.
    
    
31. @Promilus (autor: Qjanusz | data: 6/12/10 | godz.: 13:24)
    nie czytałeś tego co napisałem.
    
    Znam WinUAE. WinUAE to czyste x86 (swoja drogą kiepsko zoptymalizowane przy całym swoim bagażu wprowadzania kolejnych wersji), które dekoduje na wejściu motorolkę do x86, które dekodowane jest dalej do wew. rejestrów. Jest zagmatwanie i kiszka? Jest. Cudów z tego nie będzie.
    
    Pisałem o tym że jest szansa na udostępnieniu dodatkowej warstwy/trybu CPU, która co prawda nie musiałaby wykonywać instrukcji PPC 1:1 na wejściu, ale mogłaby być wykonywana z o wiele mniejszymi opóźnieniami i większą efektywnością na rdzeniu, niż typowa aplikacyjna odpalana na wejściu uniwersalego dekodera x86.
    
    właśnie w tym może być rozwiązanie. Microsoft nie musi ładował kolejnego, typowego x86 od tym razem AMD. Ten Fusion może być (i obstawiam że będzie) robótką szytą dokładnie na miarę kolejnej konsolki.
    AMD rdzenie ma. Doda do tego hardware layer + kontroler pamięci z wymogami dobrej konsolki i wuala...
    
    
32. Prawdopodobnie (autor: emuZ | data: 6/12/10 | godz.: 13:52)
    procesor PowerPC będzie dodany w krzem Fusion 2 tylko i wyłącznie w celach kompatybilności wstecznej. Sam fusion będzie rozwiązaniem x86 aby wykorzystać jądro windowsa 7 w dashboardzie konsoli. Jedno jest pewne konsola będzie miała czytnik blue ray. ;)
    
    
33. @Qjanusz (autor: Promilus | data: 6/12/10 | godz.: 13:54)
    Taaa... nie ma to jak tworzyć kolejne narzędzia dla kolejnej listy rozkazów proca... to już równie dobrze mogą sobie kupić licencję na power isa i zmienić dekoder. Tylko nadal oznacza to zmiany w architekturze układu, czyt. kolejny projekt, kolejne testy, kolejna linia produkcyjna... myślisz, że oni mają na to czas i środki? Bo ja sądzę, że nie.
    WinUAE jest dobrze zoptymalizowany, nie wiem czemu sądzisz że jest inaczej. Że działa wolno a kiedyś działał szybciej? No kur... to weź zobacz ile obsługuje teraz softu a ile obsługiwał wcześniej! Wszystkie błędy, nieoficjalne instrukcje, specyficzne właściwości układów Amigi MUSZĄ być również emulowane dla zapewnienia 100% kompatybilności, bo tak się składa, że twórcy softu często z owych nieoficjalnych ficzerów korzystali (zresztą w C64 również i dlatego z tym też emulatory muszą sobie radzić... nieoficjalne instrukcje 6510, nieoficjalne tryby VIC - to wszystko trzeba zaimplementować). I teraz pomyśl, że jeśli w takim 6510 jakiś rozkaz trwał 2 cykle a inny 3 to takie same proporcje emulator MUSI zapewnić. Mogę podać prosty przykład gównianej kompatybilności. AT89S51 kontra ADuC841. en pierwszy jak i intelowski '51 ma zegar /12, djnz zajmuje 2 cykle. Ten drugi ma zegar/1 i djnz zajmuje 4(!!) cykle. Większość instrukcji się pokrywa, inne są z dupy. I wiesz co się dzieje, jak się przenosi kod z jednego proca na drugi? Robi się jeden wielki bajzel. A ty proponujesz właśnie taki bajzel.
    
    
34. @Promilus (autor: Qjanusz | data: 6/12/10 | godz.: 14:37)
    co do zapewnienia kompatybilności z PPC, to można gdybać sobie w nieskończoność. Jedno jest pewne, M$ stawia wysoko priorytet kompatybilności wstecz. Ja obstawiam że będzie tak, jak napisałem. Co najwyżej, jak wyjdzie next gen, będziesz mógł napisać "a nie mówiłem"
    
    Co do WinUAE, to może źle to zabrzmiało. Nie jest to raczej kwestią kiepskiej umiejętności programistów nim się zajmujących. Aczkolwiek projekt komercyjny byłby na pewno lepszej jakości.
    Cały kwas z WinUAE związany jest z haosem w konstrukcji Ami Classic. To co stworzyło Commodore, a co gorsza, to co wyprawiali koderzy woła o pomstę do nieba. Inna ścieżka wykonywania instrukcji z podpiętym FAST Ramem, inny z samym CHIP i SLOW (<A1200). Masa niepublikowanych instrukcji motorolki były tam na porządku dziennym. Do tego dolicz sobie cuda wyprawiane z blitterem. Przecież on był używany do celów o którym nawet konstruktorzy Amigi nie myśleli. Sam HAM był wałkiem samym w sobie. Tak samo demka. Rzeźna rastrem na ekranie, zmiana palety kolorów w locie. Nawet stacja dysków robiła za głośniczek. Po co to przypominam? A no po to, żebyś zrozumiał to co sam napisałeś. Amiga Classic to masa niestandardowego, niepisanego i oficjalnie niepublikowanego kodu.
    
    Największa zmora do emulacji. Wyobrażasz sobie jak trzeba spartolić kod, aby takie kwiatuszki poprawnie obsłużyć? I dokładnie to jest powodem nieoptymalnego i marnego działania wszelakich WinUAE. Rozkazy motorolki to pikuś. Masa krytyczna jest obsługa całego bajzlu związanego z konstrukcją wew. Amigi i sposobem, w jaki to wykorzystywano.
    
    Z innej bajki. 10 lat temu na lapie z intel Pentium 200MMX spokojnie odpalałem emulator MACa. Chodził bardzo dobrze. Wiedz dlaczego? Bo emulacja RISC nie jest kłopotem, a Mac nie miał chaosu ani bzdurnie wykorzystywanych układów specjalizowanych jak Ami Classic.
    
    Wracając do x360. Jak wg Ciebie tam się koduje? Robi się bajzel jak w Ami, czy wszystko ładnie jest udokumentowane i zakodowane z przykazaniami?
    Widzisz już do czego zmierzam?
    
    Chcesz zobaczyć bak bardzo "problematyczne" jest emulowanie PPC bez udziwnień? Poczytaj sobie o STEEM albo o Hatari.
    
    
35. @Qjanusz (autor: Promilus | data: 6/12/10 | godz.: 15:50)
    Projekt komercyjny to Amiga Forever - pakiet skonfiguroowanego WinUAE (i winfellow) z kickstartami odpowiednich typów Amigi i systemem....Sprzedawany przez Cloanto. Przy czym winfellow coś już nie jest rozwijany, a winuae wręcz przeciwnie, jakiś czas temu dodali 060 do emulacji (cudów to nie zdziałało, ale troszkę więcej softu jest).
    Teraz dla ciebie zagadka... wiesz ile razy szybsze jest 040 emulowane przez K8 2.8GHz od 060@50MHz z karty 3060? 24 razy. Łaaaa...pałer! 56x więcej MHz, kilka razy większe IPC, szybsza pamięć i więcej cache. I jedyne 24x szybsze w low level test syspeed. Brawo! To teraz zagadka... jaki musiałby być szybki bulldozer by móc emulować 3 rdzenie 2 wątkowego procesora PowerPC z VMX128 taktowanego częstotliwością 3.2GHz? mmmm...tyle co dzisiejsze kręcone deneby i thubany? 6.5-7.2GHz? :>
    "Inna ścieżka wykonywania instrukcji z podpiętym FAST Ramem, inny z samym CHIP i SLOW"
    Mało wiesz. CHIP RAM to jedyna pamięć do której dostęp mają układy specjalizowane... to bufor ramki, to pamięć operacyjna, to bufor dla urządzen I/O. Jego fizyczne ograniczenie to 2MB, zatem konieczne było przerzucanie danych do fastu by zwolnić CHIP dla choćby sampli muzycznych czy też danych graficznych. I nie chodziło o różne ścieżki wykonywania, a właśnie określenie CZY FAST JEST, oraz ILE JEST CHIP.
    "Masa krytyczna jest obsługa całego bajzlu związanego z konstrukcją wew. Amigi i sposobem, w jaki to wykorzystywano"
    I tam gdzie ledwo wyrabia 1.5GHz procesor układzik FPGA za 80zł robi za całą elektronikę oprócz proca...
    "10 lat temu na lapie z intel Pentium 200MMX spokojnie odpalałem emulator MACa"
    10 lat temu widziałem Amigę z 060 odpalającą win 95, a co to zmienia? Amiga z shapeshifterem niemal tak samo szybko obsługiwała soft makówkowy, wątpię by było podobnie z Pentium ^^
    "Bo emulacja RISC nie jest kłopotem"
    Nie jest kłopotem tłumaczenie rozkazów, jest kłopotem zapewnienie odpowiedniego czasu ich wykonania, obsługi przerwań i nie wiadomo czego jeszcze.
    "Jak wg Ciebie tam się koduje"
    Pisze się korzystając z SDK dość przypominającego DirectX, kompiluje do binarki dla pałerki, nie x86. Teraz pytanie - jak szybka jest Rosetta w wymagających obliczeniowo aplikacjach. Szybsza z C2D od G5 zegar w zegar? Bo tak się składa, że Xenon własnie z tej samej paki się wywodzi co G5, tylko osiąga wyższe taktowanie i zużywa mniej energii. Dobrze wykręcony SB może i by się wyrobił, ale po co! PS3 też nie odpala w większości obecnie sprzedawanych modeli gierek z PS2, a jak odpala to wyglądają gorzej... to po ch*** komuś taka kompatybilność wsteczna?
    
    
36. @Qjanusz (autor: Promilus | data: 6/12/10 | godz.: 15:53)
    BTW Atari to motorynka 68k ewentualnie coldfire w fanowskich rozszerzeniach, o PPC w tym nic nie wiem.
    
    
37. DirectX 12 (autor: mcz | data: 6/12/10 | godz.: 16:17)
    wydaje sie ze nowe konsole beda w stanie wykorzystac najnowszy standart M$ directx 12, co bedzie zawierał? pewnie to co jest w directx11 + ulepszenia aby skorzystac z ray tracing czy udoskonalonej techniki dajacych realistyczna grafike.
    
    Świat bedzie darzył w tym kierunku.
    
    A czy CPU bedzie x86 czy ARM czy PPC to chyba mało znaczące, główny nacisk bedzie na GPU, aby był w stanie full HD wyświetlac wszystkie linie (nie sądze aby pokusili sie wysiskac wieksza rozdzielczosc, ewentualnie zaimplementuja 3D)
    
    
38. @Promilus (autor: Qjanusz | data: 6/12/10 | godz.: 16:44)
    ciągle piszesz o emulacji PPC przez standardowe wąskie gardło x86 i do tego się odnosisz. Błąd od samego początku. Ewentualna kompatybilność xboxa 720 z 360 na pewno nie będzie w ten sposób realizowana.
    Napisałem już z resztą jak ja to widzę.
    
    Co do Ami i jej organizacji pamięci, to mało wiesz. Były pisane programiki, które odpalały inne pliki wykonawcze np na samym MC68K, a inne na MC68K20 + Fast.
    
    ChipRAM miał ograniczenie do 512kb/1BM/2MB w zależności od wersji Agnusa , a cała zabawa polegała na tym że średnio było istotne to, że chipsety miały dostęp do chip, a ważne było to że CPU miał bezpośredni dostęp do FAST.
    Dlaczego A1200 po podpięciu FASTa dostawała kopa do 2x stock bez ruszania zegarka i chip-ramu? Właśnie o FAST chodziło i o to ile można do niego dopchać - oczywiście patrząc z punktu widzenia wydajności.
    
    Co do Atari, to może i motorynka, ale jej emulatory tak samo muszą wykonywać kod motorolki jak te od Amigi. A że w ST wykonują to o wiele efektywniej, świadczy tylko o tym, że ciężar emulacji idzie nie w "tłumaczenie" rozkazów CPU a właśnie w Amigową otoczkę z OCS/ECS/AGA na czele.
    
    xbox tej otoczki jest pozbawiony. Jest przejrzysta architektura, którą łatwo jest przełożyć/zdekodować na jednostki wykonawcze. Bez wyjątków, ślepych zaułków i innego marnotrawstwa w kodzie i wydajności otoczenia.
    
    
39. @mcz (autor: Qjanusz | data: 6/12/10 | godz.: 16:51)
    z tym ray tracingiem to jeszcze sporo wody upłynie.
    
    Lab intela udowodnił, że na dzień dzisiejszy ledwie chmura może to łyknąć, a nie małe urządzenie:
    http://www.benchmark.pl/...bliczeniowej-30992.html
    
    
40. jeszcze co do WinUAE (autor: Qjanusz | data: 6/12/10 | godz.: 17:01)
    http://www.simon.mooli.org.uk/AF/1.html
    
    co nieco napisane o emulacji.
    Zresztą UAE to skrót od Unusable Amiga Emulator.
    
    Unusable!!!
    Dlaczego Unusable?
    
    :-)
    
    
41. @Qjanusz (autor: Promilus | data: 6/12/10 | godz.: 17:23)
    "Co do Ami i jej organizacji pamięci, to mało wiesz. Były pisane programiki, które odpalały inne pliki wykonawcze np na samym MC68K, a inne na MC68K20 + Fast"
    Tak jak NWN2 odpala jedną aplikację dla Athlonów XP/Pentium III, a drugą dla P4, K8, Core 2... Niemniej normalnie się tak nie pisze bo i po co skoro można wykrywanie zrobić od razu w app?
    "a cała zabawa polegała na tym że średnio było istotne to, że chipsety miały dostęp do chip"
    Ależ to było najbardziej istotne! Pomyśl... zamiast bufora dźwięku na SB, zamiast bufora ramki na GF, zamiast bufora RS232 w chipsecie każdą tą rolę spełniał CHIP RAM. I do tego jako pamięć operacyjna. Jego ZAWSZE było za mało, a powiększyć się nie dało. FAST miał za zadanie głównie właśnie ODCIĄŻYĆ CHIP, a szybki dostęp CPU do tej pamięci to zupełnie inna sprawa. FAST miał większą rolę tylko w systemach z GFX pokroju Retina Z2 albo Cybervision... Bo tam CHIP nie miał aż tak dużo do roboty. Natomiast na AGAtkach, ECSach i OCSach każdy KB CHIP był na miarę złota.
    "Dlaczego A1200 po podpięciu FASTa dostawała kopa do 2x stock bez ruszania zegarka i chip-ramu"
    Bo chip był zarządzany przez AGNUSa/Alice, a nie bezpośrednio przez CPU. Za to do FAST jedynie CPU miał bezpośredni dostęp. I jak widać nie było tych durnych programistów o których pisałeś, że robili 2 binarki, jedną dla amigi z fastem, a drugą bez. Inna sprawa że pierwszą rzeczą jaką się robiło przy faście to blizkick, programik który mapował do FASTu biblioteki z ROMu, które normalnie siedziały w CHIP RAM. Poza tym najmniejsze fasty miały 4MB, a największy chip 2MB ^^
    "Jest przejrzysta architektura"
    Tak, i 100GFLOPS SP CPU które chyba tylko Thubany kręcone osiągają albo kulfony od intela dzisiaj...CZYM TY CHCESZ TO EMULOWAĆ?
    
    
42. @Promilus (autor: Qjanusz | data: 6/12/10 | godz.: 17:43)
    "CZYM TY CHCESZ TO EMULOWAĆ?"
    
    a tym co napisałem w #25
    
    :-)
    
    
43. @Qjanusz (autor: mcz | data: 6/12/10 | godz.: 18:30)
    karty klasy direct11 zmierzają w kirunku RAY
    a co bedzie za 2 lata? bedzie dzialac w full HD w 3D
    
    poczytaj:
    
    http://www.maximumpc.com/..._still_be_polygonbased
    
    http://www.pcper.com/article.php?aid=532
    
    
44. to samo uwazam (autor: robgrab | data: 6/12/10 | godz.: 19:19)
    nowe apu dla xbox bedzie musialo obslugiwac Raytracing z prostej przyczyny, konsole maja 5-7lat zycia. Czyli next gen bedzie zyl do okolo 2020roku. Jesli nie bedzie raytracing to konsole strasznie zatrzymaja grafike gier bo za 5lat na pc na 100% beda juz karty obslugujace raytracing jako podstawowa metode generowania grafiki wraz z nastepnymi directx. I co, firmy beda robic 2 calkiem rozne wersje gier? Albo sztucznie beda hamowac rozwoj technologi realtime raytracing?
    
    
45. Robgrab (autor: Aamitoza | data: 6/12/10 | godz.: 19:43)
    To nie rynek PC, a konsol się głównie liczy i od niego zależy to co zobaczymy w grach. Układy w konsolach będą najprawdopodobniej za słabe na RT, a nawet jak nie będą, to na taki który przebije jakością gry robione obecnie w oparciu o grafikę wektorową/resteryzację (jak zwał, tak zwał).
    
    Nvidia już zapowiedziała, że przez najbliższą dekadę będą trzymać się obecnej technologii. Więc najbliższych konsolach nawet bym się tej technologii nie spodziewał.
    
    
46. ***** (autor: Aamitoza | data: 6/12/10 | godz.: 19:50)
    ***a nawet jak nie będą, to na taki który przebije jakością gry robione obecnie w oparciu o grafikę wektorową/resteryzację (jak zwał, tak zwał) nie będą gotowe. Jest też wiele efektów których nie da rady wykonać w czasie rzeczywistym za pomocą RT, a w przypadku grafiki rastrowej jak najbardziej.
    
    
47. x86 w konsoli (autor: scoobydoo19911 | data: 6/12/10 | godz.: 20:14)
    fajne to konwersje gier w jedną i drugą stronę były by robione praktyczie rzecz biorąc w locie a nawet jeśli nie tak łatwo to i tak znacznie łatiej niż z ppc.
    
    
48. @Qjanusz w #42 (autor: Promilus | data: 6/12/10 | godz.: 20:28)
    Zrozum. Konsole idą w GPU. Tak, moc GPU ma coraz większe znaczenie. W czasach PS2 czy Dreamcasta dużo roboty odwalały specjalizowane CPU, właściwie koprocesory. W PS3 dużo roboty odwala Cell, w xklocku to na głowie xenona jest AI czy fizyka. Ale... widać wyraźny trend zrzucania tych obliczeń na GPU. I wydaje mi się, że kolejna generacja to będzie mega GPU z wysoką mocą obliczeniową i dość przeciętny CPU. Ale tak jak na GPU nie emuluje się x86, tak i nie ma sensu PPC emulować. Mogę się mylić, ale nie sądzę by AMD zrobiło coś WŁASNEGO zapewniającego zgodność z X360.
    
    
49. nie bedzie kompatybilnosci wstecz (autor: RusH | data: 7/12/10 | godz.: 03:16)
    juz sony przetarlo drokge zabierajac kompatyilnosc w slimach
    
    
50. mi sie wydaje ze jednak bedzie (autor: robgrab | data: 7/12/10 | godz.: 06:29)
    jakas kompatybilnosc z x360, sony to nie najlepszy przyklad bo oni zawsze zabieraja kompatybilnosc w wersji slim gdy juz jest duzo tytulow na obecna generacje, tak samo bylo z ps2 slim gdzie usunieta sprzetowa kompatybilnosc z ps1.
    
    
51. Ja tam obstawiam że kompatybilność z x360 zostanie zachowana (autor: Qjanusz | data: 7/12/10 | godz.: 10:45)
    http://www.shacknews.com/onearticle.x/55347
    http://n4g.com/...ense-for-backwards-compatibility
    
    jak ja widzę możliwość emulacji otoczenia Xenona, już napisałem. Kod dla Xenosa to pikuś. Resztę zweryfikuje przyszłość.
    
    @Promilus - mega wydajny GPU + marne CPU. Może i masz rację.
    Ale... zawsze GPU w konsolkach było na miarę możliwości TOPu grafik do PCtów. Myślisz że Fusion II zapewni GPU na miarę TOPU grafik do PCtów? Nie sądzę. Myślę że GPU z Fusion będzie na miarę LOW, lub MIDDLE w najlepszym przypadku dostępnych na rynku grafik. Co prawda AMD może podrasować wydajność GPU specjalnie dla konsoletki, ale na pewno nie będzie to wydajność TOPowej, dostępnej (lub projektowanej) karty graficznej.
    
    Natomiast zupełnie absurdalnym pomysłem jest wg mnie twierdzenie, że w następnych konsolach może być dostępny tryb RT. Za 10 lat - i to może.
    Najbliżej RT jest chyba nVidia, czyli efekciki z Optix ray tracing engine odpalanymi na Quadro, oraz żadnych planów jak na razie przeniesienia tego na masowy rynek.
    O chmurze RT intela lepiej nie wspominać w kontekście masowego odbiorcy.
    
    
52. @Qjanusz (autor: Promilus | data: 7/12/10 | godz.: 11:19)
    Nie. Nie zawsze było top. Wyraźnie pamiętam PS, SNES, N64 - akurat w tych przypadkach bywały lepsze układy w komputerach. Wiązało się to przede wszystkim z faktem, iż w tamtych czasach układy graficzne miały głównie wyświetlać obraz, z drobnymi transformacjami, natomiast samo generowanie ruchu, kalkulacja świateł i cienie - to wszystko siedziało na CPU. PSX - specjalna jednostka wektorowa w CPU MIPS, SNES - i super fx RISC upgrade dla gier z konkretniejszą grafiką 3D. Zresztą to samo jeśli chodzi o N64 czy nawet PS2. Ale... tak jak mamy coraz nowsze API w PC oraz dopasowane do niego GPU, tak i ewoluują konsole. Moc obliczeniowa GPU wzrasta szybciej niż CPU i tego nie da się zmienić. Przy intensywnym korzystaniu z ficzerów nowych kart graficznych oraz API okazuje się, że zaangażowanie CPU w proces generowania obrazu można znacząco zredukować. Wiadomo, że znacząco szybsze GPU będzie potrzebowało też znacząco szybszego CPU w nowej konsoli, ale myślę, że wzrost wydajności będzie głównie po stronie GPU. Dzielenie wielokątów i obliczanie pozycji nowych wierzchołków przy teselacji? Na samym GPU. Obliczenia fizyki - GPU. Transformacje obiektów i przemieszczenia wierzchołków - na samym GPU. Geometry instancing - GPU. Na GPU można kopiować, niszczyć, zmieniać obiekty. Bez zmuszania CPU do ciężkiej i czasochłonnej roboty. I wystarczy tylko z tego korzystać. DirectCompute, Teselacja, VBO, PBO, FBO...to wszystko wspomaga generowanie grafiki, ale coraz większym kosztem mocy GPU względem CPU. Taki jest trend na PC, wątpię by był inny w konsolach