Uwalił, nie uwalił....

http://pl.wikipedia.org/wiki/Nautilus_% ... omputer%29
http://pl.wikipedia.org/wiki/Roadrunner

i jeszcze cytat z http://en.wikipedia.org/wiki/Cell_%28microprocessor%29

"PowerXCell 8i-based supercomputer, the IBM Roadrunner system, became the world's first system to achieve one petaFLOPS, and was the fastest computer in the world until third quarter 2009. The world's three most energy efficient supercomputers, as represented by the Green500 list, are similarly based on the PowerXCell 8i."

"In November 2009, an IBM representative said that it has discontinued the development of a Cell processor with 32 SPUs[14][15] but they have not halted development of other future products in the Cell family.[16]"

Także jak widać sprzęt wyprzedził swoje czasy, a że prezentuje inne podejście niż preferuje "game-dev" któremu łatwiej/szybciej/taniej pisać na platformy właściwie zbieżne z PeCe, no cóż.

To jeszcze sobie ponarzekam ;) Kto jeszcze pamięta czasy takich gier jak Metal-Slug (http://en.wikipedia.org/wiki/Metal_Slug), masa pracy włożona w grafikę... a efekt jak dla mnie powalający. Mimo iż gra jest 2D, to ma w sobie to coś czego do dziś nie znalazłem w innych grach.

@As: pozostaje pytanie czy ten tajemniczy produkt rosyjskich laboratoriów wojskowych to tylko czysty marketing? ;)

@sqward: wydaje mi się iż nie doceniasz cell-a i bebechów PS3, trzeba po prostu umieć na to pisać. Niestety wielcy developerzy i super programiści chyba z upływem czasu głupieją i dziwią się że port jakiegoś engine z peceta lub Xbox wolno chodzi na PS3... już widzę to jęczenie developerów gdyby Sony nie zdecydowało się włożenie GPU od NV do konsoli co pozwoliło na w miarę podobne podejście do projektowania engine-ów jak w przypadku innych platform. Wtedy byłby lamenty że ta konsola do niczego się nie nadaje... i tylko Japończycy potrafili by pisać na swoją konsolę. Podobnie było z PS2, tylko determinacja i upór japońskich developerów pozwoliło tej konsoli wyprzedzić czas w którym się znalazła.

Twój dowcip od dev-kit do PS3 tylko potwierdza teorię jak trudno obecnym programistom zrozumieć i wykorzystać moc drzemiącą w tym hardware. A już programowanie współbieżne i rozłożenie danego problemu na kilka niezależnych ultra wydajnych rdzeni to problem dla większości obecnych "programistów" staje się nie do przeskoczenia.

Intel ze swoim super X86 zabrnął już dawno w ślepą uliczkę... skąd nagle zmiana polityki w stajni intela i od sporego kawałka czasu ich X86 to de facto w środku typowy RISC emulujący zestaw instrukcji X86 ;)

Do kompletu brak konkurencji na polu CPU do pecetów, nawet ze strony AMD które idzie inną drogą i Intel który stoi w miejscu od paru(nastu) dobrych miesięcy. Z jednej strony niby w Intel-u zauważyli że rozwijanie x86 do niczego nie prowadzi, z drugiej strony uśmiercają IA64.

Żebyś mnie źle nie zrozumiał, nie czepiam się Ciebie... po prostu napisałem jak ja to widzę patrząc mocno z boku i od czasu do czasu zaglądając do miejsc gdzie się męczą przy game-dev i portowaniu gier z różnych platform na inne platformy.

Wracając jeszcze na chwilę do PS3... przypomniała mi się akcja gdy chłopaki port-owali engine z PS3 na PC. Tutaj również okazało się że port w tę stronę spowodował iż gra mająca niesamowity engine brykający jak wściekły na PS3 na PeCe wymagał przepisania właściwie od nowa, gdyż samo przeniesienie go na platformę X86 spowodowało że działał on z oszałamiającą prędkością 12FPS :P

To co robiło PS3 w tamtym okresie z trudem zostało przeniesione na PeCe, w dodatku hardware którego to wymagało kosztował tyle że mało kto mógł sobie na niego pozwolić. Port przeleżał chyba ponad 1,5roku aby możliwe było wydanie gry na platformę PC.

ps1) nie jestem zwolennikiem ani fanatykiem firmy Sony, przytoczyłem tylko przykłady z podwórka ludzi którzy się zajmują takimi sprawami codziennie.

ps2) reasumując pisanie na X86 jest po prostu łatwiejsze i prostsze, co nie oznacza iż wydajne. Pisanie na PS3 wymaga totalnej zmiany w sposobie myślenia, i od początku trzeba założyć z jak odmiennym hardware ma się styczność. SPE dają możliwość/narzucają zmianę sposoby myślenia (np. stream processing) W przypadku Cell-a... power dawały mega wydajne jednostki SPE, tam każdym SPE masz do dyspozycji chyba 256k ultra szybkiej pamięci... reszta pamięci jest współdzielona pomiędzy rdzeniami i komunikacja główną pamięcią musi odbyć się poprzez DMA I/O. Nad całością mamy zarządzające tym Power-PC (PPE), to on się zajmuje przydzieleniem task-ów dla poszczególnych SPE. Na nim można odpalić cały os lub eko-system, ale całość operacji złożonych obliczeniowo musi zostać oddana w ręce SPE.

Cell Inside:

SPE:

ps3) gdyby nie rozwój GPU to X86 nijak nie obrobiło by się z tym co robi GPU. Możemy zobaczyć więc że w przypadku PeCe obecnie mamy taki sam trend jaki został wymyślony przez twórców PS3. Wydaje mi się że obecnie X86 staje się powoli zarządzającym PPE dla tego co potrafi liczyć GPU :)

ps4) Od parunastu lat czekam na rewolucję w podejściu do generowania grafiki... z utęsknieniem czekam na real-time ray-traceing ;) Do dziś widać tylko nieśmiałe próby. Nie wiem czy brakuje wydajności, czy chęci... miałem nadzieję że ludki szalejące na PS3 szybko zrezygnują z renderowania na RSX-a i zaczną sobie próbować tworzyć real-time raytracery ale niestety się przeliczyłem :)

I tak na koniec, przypomniało mi się... takie real-time tech demo na PS3...

http://youtu.be/j-pF56-ZYkY?hd=1

przecież to nie żaden commodore OS tylko linux + compiz,  http://pl.wikipedia.org/wiki/Compiz

@Fox:

ad1) a to już Electron chyba dobrze wie, nie wiem czy dobrze pamiętam ale chyba kiedyś analizował. Ja mogę bredzić ale chyba lecą sekwencyjnie adresy wszystkich kolumn. Nie pamiętam czy nie było to $00xx,$01xx,$02xx,$03xx,$04xx, itd. aż do $FFxx. Ale nie bierz tej informacji zbyt dosłownie, ja tego nie sprawdzałem.

ad2) nigdy się nad tym nie zastanawiałem i również nie bardzo wiem :( Teraz nawet nie mam możliwości sprawdzenia.  Ale wydaje mi się że leci wszystko to co normalnie robi Antic, tylko CPU nie ma szans dostać się do szyny bo ma ustawiony HALT.

Hej!

Ależ oczywiście że S4 lub S5 mogą zostać uaktywnione z przez ANTIC.

Refresh jest brany pod uwagę przez MMU i wtedy sygnały S4 oraz S5 są nieaktywne:

S4      = !A13 & !A14 & A15 & RD4 & REF;/* RD4 and addresses $8000-$9FFF */
S5      = A13 & !A14 & A15 & RD5 & REF;    /* RD5 and addresses $A000-$BFFF */

W każdym innym przypadku gdy RD4 lub RD5 będą aktywne i na szynie adresowej pojawi się odpowiedni adres, to MMU wygeneruje S4 lub S5. Jak widać MMU nie patrzy czy szynę adresuje CPU czy ANTIC, dla niego jest to nie istotne. Ważne że na szynie pojawił się odpowiedni adres i spełniony został warunek z równania powyżej. (legenda: ! - NOT, & AND, # OR )

W żadnym wypadku nie możesz założyć że ANTIC takiego adresy nie wygeneruje. Może stać się to nawet przez przypadek jak komputer się zawiesi, jakiś program popsuje się tak iż zapisze losowe śmieci do rej. ANTIC-a, sam sobie wyobraź co się stanie jak adres DLIST wpiszą się jakieś dowolne wartości. Często można to zaobserwować w przypadku niektórych programów, np. po wciśnięciu RESET. Program leci w krzaki na ekranie również śmieci, ANTIC wyświetla co chce i jak che :)

Wystarczą również niefortunne zapisy do HSCROLL i mamy piękny bug ANTIC-a, który doskonale widać na logach od electrona i candle. Na ekranie dzieją się wtedy różne ciekawe rzeczy a co się dzieje na magistrali? ;) Myślę iż wszystko co można sobie wyobrazić ;P

Hej!

ad 2) tzw. "FI2" dostępne w porcie karta to 1.77MHz. Taką częstotliwością jest taktowany CPU (tylko Fi2 jest generowane przez 6502 z FI0, sygnały są przesunięte w fazie ale mają tę samą częstotliwość)

ad 4) musisz założyć że w każdym cyklu będzie możliwy dostęp do pamięci która znajduje się carcie. Nie koniecznie CPU może się do tej pamięci dobierać, przecież masz również ANTIC który właściwie w dowolnym wybranym przez siebie momencie może sobie pobrać dane z dowolnego miejsca pamięci Atari.

a pisałeś coś do nich może jeszcze? Czy się obraziłem i masz ich w "dup#(**#", i teraz się denerwujesz że kasy Ci nie oddali. Jak im odpuściłem to oni się cieszą z Twoich pieniędzy. Ja wiem że uczciwe to nie jest z ich strony, ale wydaje mi się AS-ie że Ty się wkur*#(# i z lekka im odpuściłeś. Ja bym takiej kasy nie darował. Nie ważna suma, ważne są zasady. Skoro nie złamałeś regulaminu i dopełniłeś wszelakie formalności to walcz dalej o swoje. Kasę w zębach Ci powinni przynieść.

proponuję chwilę relaksu: http://youtu.be/bIN4ZL9U7Z4

Hej!

Nie zakończyła się niestety nijak. Zamówiłem te wtyczki w dwóch sklepach internetowych w PL, żaden mi nie wysłał do dziś ( "chwilowy" brak towaru). Potem o tym zapomniałem i zasilacze do Lynx leży obecnie w szufladzie :( Muszę zobaczyć czy wtyczki się pojawiły może i dam znać.

pozdr
Seban

aaaa.... czyli ja nie załapałem jednak ;-) Bo już w tym wątku występuje tak duże stężenie oparów absurdu że sam się zakręciłem :)

@dracon: tutaj można by dyskutować o celowości i sensowności takiego działania. Mamy wolny rynek jeżeli mają popyt na tego typu twory to już ich sprawa czy wydadzą książkę o tym czy nie. Równie dobrze mogą się cieszyć miłośnicy NV. Ale sprawa ma jeszcze drugie dno... nie wiem co NV i komu robi dobrze, ale różni wykładowcy którzy pracują ze studentami opowiadają im takie głupoty że szok.

Z ust wykładowcy padają stwierdzenia godne rasowego Fan-Boya firmy NV, oczywiście nie mające żadnego związku z rzeczywistością. Rozumiem że gość miał doświadczenie jakieś z pracą przy kartach od NV wspomagających CUDA. Ale gość się pieni i pluje że OpenCL i ATi/AMD do niczego się nie nadają :) Tego typu relacje słyszę od czasu do czasu od osób które muszą sobie dokupić kartę firmy NV bo tego wykładowca im powiedział że nie będą mogli wykonać prac zaliczeniowych ;)