kategorie:
Amiga Classic, Efika, eMac, iMac G5, Mac mini, MorphOS 1.4.x, MorphOS 2.x, MorphOS 3.x, Pegasos, Pegasos II, PowerBook, PowerMac, Programy
24.06.2020 18:23
[#63]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@tom256, post #62
To jakiemu procesorowi POWER odpowiadają procesory PowerPC na rdzeniu e5500? :)
Teraz @mufa - jak chcesz się zasłaniać wikipedią, to za wikipedią
link BOOK I.
QorIQ nigdzie nie określa nawet, że jest PowerPC, a jedynie Power architecture (nie POWER, Power), ale NXP nie utrzymuje już nawet więzi z marką dla produktów będący ewidentnie PowerPC (G3, G4). W zasadzie nie znajdziesz terminu PowerPC nigdzie w dokumentacji poza preambułą określającą znaki zastrzeżone.
QorIQ to produkty embedded, POWER to produkty serwerowe. Używają (w dużej mierze) tego samego ISA. Przy czym zgodność z daną wersją PowerISA nie oznacza, że jest to zgodność WSZYSTKIEGO co zawiera (a e5500 nie obsługuje nawet pewnych rdzennych instrukcji z PowerISA v2.06, a e500v2 to już wiadomo jak mocno pocięte - patrz P1022 i FPU).
Teraz @mufa - jak chcesz się zasłaniać wikipedią, to za wikipedią
Power ISA is an evolution of the PowerPC ISA, created by the mergers of the core PowerPC ISA and the optional Book E for embedded applications(czyli już nie ma PowerPC ISA) POWER4 zrywa z ISA POWER i konsoliduje PowerPC ISA i book E (embedded) - ostatecznie i tak praojcem PPC jest POWER. Polecam zapoznać się z
link BOOK I.
QorIQ nigdzie nie określa nawet, że jest PowerPC, a jedynie Power architecture (nie POWER, Power), ale NXP nie utrzymuje już nawet więzi z marką dla produktów będący ewidentnie PowerPC (G3, G4). W zasadzie nie znajdziesz terminu PowerPC nigdzie w dokumentacji poza preambułą określającą znaki zastrzeżone.
The ISA is divided into several categories and every component is defined as a part of a category; each category resides within a certain Book. Processors implement a set of these categories. Different classes of processors are required to implement certain categories, for example a server class processor includes the categories Base, Server, Floating-Point, 64-Bit, etc.
QorIQ to produkty embedded, POWER to produkty serwerowe. Używają (w dużej mierze) tego samego ISA. Przy czym zgodność z daną wersją PowerISA nie oznacza, że jest to zgodność WSZYSTKIEGO co zawiera (a e5500 nie obsługuje nawet pewnych rdzennych instrukcji z PowerISA v2.06, a e500v2 to już wiadomo jak mocno pocięte - patrz P1022 i FPU).
25.06.2020 02:45
[#64]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@abcdef, post #63
Czy jednak nie jest tak, że jeśli procesor jest zdolny do wykonywania natywnie kodu innego procesora, to możemy go traktować jako jego alternatywę?
Pytanie (nie znam odpowiedzi, pytam :) ), czy nowsze procesy POWER wykonują kod PowerPC? Bo jeśli tak, to można je rozpatrywać jako możliwą drogę rozwoju systemów AmigaNG. Oczywiście następnie należy przeanalizować wydajność, dostępność, cenę, ilość generowanego ciepła....
Jeśli nie potrafią wykonywać kodu PowerPC, to nie co sobie nimi zaprzątać głowy.
Analogia ze świata PC - mimo że 12 wątkowy i7 architektonicznie nie ma nic wspólnego z 8088, to przez fakt, że potrafi natywnie wykonać napisane dla niego programy może być traktowany jako jego dalekie rozwinięcie i zamiennik (oczywiście nie na zasadzie fizycznej podmiany na płycie, tylko jako zdolny do użycia gotowej już biblioteki oprogramowania).
Pytanie (nie znam odpowiedzi, pytam :) ), czy nowsze procesy POWER wykonują kod PowerPC? Bo jeśli tak, to można je rozpatrywać jako możliwą drogę rozwoju systemów AmigaNG. Oczywiście następnie należy przeanalizować wydajność, dostępność, cenę, ilość generowanego ciepła....
Jeśli nie potrafią wykonywać kodu PowerPC, to nie co sobie nimi zaprzątać głowy.
Analogia ze świata PC - mimo że 12 wątkowy i7 architektonicznie nie ma nic wspólnego z 8088, to przez fakt, że potrafi natywnie wykonać napisane dla niego programy może być traktowany jako jego dalekie rozwinięcie i zamiennik (oczywiście nie na zasadzie fizycznej podmiany na płycie, tylko jako zdolny do użycia gotowej już biblioteki oprogramowania).
25.06.2020 06:15
[#66]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@wali7, post #64
Od początku zmiany były dość niewielkie (tj pierwsza wersja PowerPC ISA względem POWER ISA, różnice w którymś z w/w linków)
PowerPC ISA rozwijało się jednak dynamicznie gdy POWER ISA skończyło się wraz z rodziną POWER3 (ta obsługiwała PowerPC ISA i POWER ISA). Od POWER4 nie było jednak PowerPC ISA tylko Power ISA. I kolejne produkty, czy IBM, czy Freescale, czy PA Semi, czy AMCC używały "Power Architecture". Nie "POWER", nie "PowerPC". Dlaczego? Bo specyfikacja uciekała poza kontrolę i takie Freescale (dawniej dział CPU motoroli) szło w embedded tworząc niekompatybilne rozszerzenia które MOGŁY ostatecznie zajmować grupy opcode należące do innych instrukcji. Żeby ogarnąć burdel i ustandaryzować powołano Power.org
Ale tak jak wyżej pisałem to, że coś jest "zgodne" z daną wersją PowerISA nie oznacza automatycznie, że POWER zgodny z tą wersją PowerISA ma IDENTYCZNĄ listę rozkazów jak jakiś procesor sieciowy zgodny z tą wersją. Bo nadal jest podział na instrukcje bazowe i swoiste rozszerzenia, a firmy mają pewną dowolność w ich stosowaniu. To co jest opcjonalne jako BOOK III a będzie użyteczne w każdym zastosowaniu trafia do BOOK I czyli w większości bazowych/rdzennych instrukcji w nowej wersji ISA. Czyli rozwój trochę jak OpenGL. Mamy profil rdzenny i rozszerzenia opcjonalne (pod nadzorem grupy, ale pełna dowolność w stosowaniu) oraz vendor-specific (dające dostęp do rozwiązań specyficznych danego producenta, np. s3tc swego czasu czy ati truform). W następnych wersjach jak coś jest fajnego to wciągamy do core.
Teraz jeśli pytanie brzmi czy można by było odpalić AOS4 na POWER9 - krótka odpowiedź tak. Jeśli by się ogarnęło firmware. Czy ktoś to może rozpatrywać jako możliwą drogę rozwoju dla AmigaNG? Jasne, prawdę mówiąc można to było rozpatrywać już w czasach POWER8 bo i tak nie ma ANI JEDNEGO DESKTOPOWEGO PowerPC od tamtego czasu. To co jest to rozwiązania EMBEDDED i skończyły się na core e6500 (taki ulepszony e5500 z SMT i AltiVec) z 2012r (!!!)
A z tą zgodnością binarek... no to weź i spróbuj ile ci się odpali na i7 softu z 8086/8088 :) Kompatybilność wsteczna też ma granice.
PowerPC ISA rozwijało się jednak dynamicznie gdy POWER ISA skończyło się wraz z rodziną POWER3 (ta obsługiwała PowerPC ISA i POWER ISA). Od POWER4 nie było jednak PowerPC ISA tylko Power ISA. I kolejne produkty, czy IBM, czy Freescale, czy PA Semi, czy AMCC używały "Power Architecture". Nie "POWER", nie "PowerPC". Dlaczego? Bo specyfikacja uciekała poza kontrolę i takie Freescale (dawniej dział CPU motoroli) szło w embedded tworząc niekompatybilne rozszerzenia które MOGŁY ostatecznie zajmować grupy opcode należące do innych instrukcji. Żeby ogarnąć burdel i ustandaryzować powołano Power.org
Ale tak jak wyżej pisałem to, że coś jest "zgodne" z daną wersją PowerISA nie oznacza automatycznie, że POWER zgodny z tą wersją PowerISA ma IDENTYCZNĄ listę rozkazów jak jakiś procesor sieciowy zgodny z tą wersją. Bo nadal jest podział na instrukcje bazowe i swoiste rozszerzenia, a firmy mają pewną dowolność w ich stosowaniu. To co jest opcjonalne jako BOOK III a będzie użyteczne w każdym zastosowaniu trafia do BOOK I czyli w większości bazowych/rdzennych instrukcji w nowej wersji ISA. Czyli rozwój trochę jak OpenGL. Mamy profil rdzenny i rozszerzenia opcjonalne (pod nadzorem grupy, ale pełna dowolność w stosowaniu) oraz vendor-specific (dające dostęp do rozwiązań specyficznych danego producenta, np. s3tc swego czasu czy ati truform). W następnych wersjach jak coś jest fajnego to wciągamy do core.
Teraz jeśli pytanie brzmi czy można by było odpalić AOS4 na POWER9 - krótka odpowiedź tak. Jeśli by się ogarnęło firmware. Czy ktoś to może rozpatrywać jako możliwą drogę rozwoju dla AmigaNG? Jasne, prawdę mówiąc można to było rozpatrywać już w czasach POWER8 bo i tak nie ma ANI JEDNEGO DESKTOPOWEGO PowerPC od tamtego czasu. To co jest to rozwiązania EMBEDDED i skończyły się na core e6500 (taki ulepszony e5500 z SMT i AltiVec) z 2012r (!!!)
A z tą zgodnością binarek... no to weź i spróbuj ile ci się odpali na i7 softu z 8086/8088 :) Kompatybilność wsteczna też ma granice.
25.06.2020 07:47
[#67]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@abcdef, post #66
W retro PC masz podział na 3 grupy:
1. 8088 i 8086 - MGA/Hercules/CGA/EGA
2. 80286 - CGA/EGA/VGA
3. 386 w górę - raczej już VGA
Każdy kolejny PC jest w 99.9% zgodny z 386 i kartą VGA. Jedynie prędkość może być problemem choć w czasach gdy to miało jeszcze znaczenie (nie było dobrze działającego DosBox-a - tak gdzieś trochę po 2000 roku) to praktycznie każdy procesor po wyłączeniu L1/L2 cache miał wydajność własnie ~386 więc nie było to problemem. Były dostępne programiki do spowalniania procesora - choć tutaj nie każdy działał dobrze więc trzeba pewnie trochę się naszukać aby znaleźć dobry. I też problemy ze zbyt dużą wydajnością to problem raczej programów na 86/286 a nie typowo dla 386 czyli 32-bitowych.
Działanie programów z 88/86/286 jest różne choć i tak kompatybilność jest dość dobra. Główne problemy to zmiany niektórych rozkazów przy przejściach na kolejne architektury. Potem rozkazy już się nie zmieniały a gwałtownie idąca w górę wydajność wymuszała poprawne pisanie programów.
Na i7 zatem masz kompatybilność z wszystkim aż do 386 z VGA (tj. działa to tak jakbyś miał 386 z VGA tylko trochę szybszy) pomijając może programy Turbo Pascalowe które trzeba było patchować już na Pentium 200MHz.
EDIT://
Kompatybilność wsteczna w zarówno rodzinie 68K jak i PowerPC była znacznie mniej konsystentna. W x86 i tak każdy procesor ma w front-endzie specjalny dekoder instrukcji emulujący stare rozkazy i tryby więc obsługa wszystkich instrukcji nie jest problemem.
Swoją drogą taka ciekawostka: gdyby złamać kod tego mikrokodu na jakimś nowym procesorze to teoretycznie możliwe by było napisanie emulatora innego ISA np. 68K
Nikomu się to jednak do dzisiaj nie udało
Ostatnia aktualizacja: 25.06.2020 07:53:05 przez XoR
1. 8088 i 8086 - MGA/Hercules/CGA/EGA
2. 80286 - CGA/EGA/VGA
3. 386 w górę - raczej już VGA
Każdy kolejny PC jest w 99.9% zgodny z 386 i kartą VGA. Jedynie prędkość może być problemem choć w czasach gdy to miało jeszcze znaczenie (nie było dobrze działającego DosBox-a - tak gdzieś trochę po 2000 roku) to praktycznie każdy procesor po wyłączeniu L1/L2 cache miał wydajność własnie ~386 więc nie było to problemem. Były dostępne programiki do spowalniania procesora - choć tutaj nie każdy działał dobrze więc trzeba pewnie trochę się naszukać aby znaleźć dobry. I też problemy ze zbyt dużą wydajnością to problem raczej programów na 86/286 a nie typowo dla 386 czyli 32-bitowych.
Działanie programów z 88/86/286 jest różne choć i tak kompatybilność jest dość dobra. Główne problemy to zmiany niektórych rozkazów przy przejściach na kolejne architektury. Potem rozkazy już się nie zmieniały a gwałtownie idąca w górę wydajność wymuszała poprawne pisanie programów.
Na i7 zatem masz kompatybilność z wszystkim aż do 386 z VGA (tj. działa to tak jakbyś miał 386 z VGA tylko trochę szybszy) pomijając może programy Turbo Pascalowe które trzeba było patchować już na Pentium 200MHz.
EDIT://
Kompatybilność wsteczna w zarówno rodzinie 68K jak i PowerPC była znacznie mniej konsystentna. W x86 i tak każdy procesor ma w front-endzie specjalny dekoder instrukcji emulujący stare rozkazy i tryby więc obsługa wszystkich instrukcji nie jest problemem.
Swoją drogą taka ciekawostka: gdyby złamać kod tego mikrokodu na jakimś nowym procesorze to teoretycznie możliwe by było napisanie emulatora innego ISA np. 68K
Nikomu się to jednak do dzisiaj nie udało
Ostatnia aktualizacja: 25.06.2020 07:53:05 przez XoR
25.06.2020 08:20
[#68]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@XoR, post #67
Oh, ale nie tylko o to chodzi. Teoretycznie i7 czy ryzen obsługują wszystkie tryby i rozkazy jakie miał 8086. I tak pewnie jest. Jedne szybciej, lepiej, inne wolniej. Implementowane są jednak one w nieco odmienny sposób. Bardzo długich instrukcji dekodery nie są w stanie obsłużyć. Complex decoder z core generuje max 4uops a rozkazy x86 mogą generować więcej. Dlatego stosuje się microcode sequencing, u AMD było to vector path, nie wiem jak w zenach. Zmianą mikrokodu można łatać też niektóre błędy. To nie jest "hardwired rom decoder" i z reguły właśnie zarządza takimi przypadkami, których szybki sprzętowy dekoder nie ogarnia (czyli długie instrukcje, ale też rzadko używane tryby i instrukcje)
Sprawa jest prosta - jeśli był magiczny guzik turbo do spowalniania CPU by stare aplikacje działały poprawnie na nieco szybszych i nowszych CPU to czy na i7 który ma ograniczone możliwości zbijania mnożnika i zegara bazowego taka aplikacja będzie działać prawidłowo? No nie. Dlatego piszę - kompatybilność wsteczna ma swoje granice. Dodatkowo sprawę komplikuje fakt, że już czasem SuperIO (floppy, com i lpt) nie ma co oznacza crash aplikacji próbującej się z nim komunikować.
Sprawa jest prosta - jeśli był magiczny guzik turbo do spowalniania CPU by stare aplikacje działały poprawnie na nieco szybszych i nowszych CPU to czy na i7 który ma ograniczone możliwości zbijania mnożnika i zegara bazowego taka aplikacja będzie działać prawidłowo? No nie. Dlatego piszę - kompatybilność wsteczna ma swoje granice. Dodatkowo sprawę komplikuje fakt, że już czasem SuperIO (floppy, com i lpt) nie ma co oznacza crash aplikacji próbującej się z nim komunikować.
25.06.2020 09:18
[#69]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@] SKOLMAN_MWS ˇ agrEssOr [, post #65
Fajne !, tylko ten Cyclone II to chyba za mało, minimum III gdyby był.
No ale tak mniej-więcej mógłby wyglądać Vampire2+PPC, a żeby to spiąć to już dużo mniej roboty niż tworzenie od podstaw 68080 i reszty chipsetu Amigi w FPGA.
Na tym PPC poza AO 3.x pewnie nie byłoby dużym problemem MorphOS-a odpalić ( toż to prawie Efika ), a i z portem AO 4.1 pewnie nie byłoby problemu, tylko musiałoby się tego sprzedać na poziomie kilkudziesięciu tyś sztuk przynajmniej.
No ale tak mniej-więcej mógłby wyglądać Vampire2+PPC, a żeby to spiąć to już dużo mniej roboty niż tworzenie od podstaw 68080 i reszty chipsetu Amigi w FPGA.
Na tym PPC poza AO 3.x pewnie nie byłoby dużym problemem MorphOS-a odpalić ( toż to prawie Efika ), a i z portem AO 4.1 pewnie nie byłoby problemu, tylko musiałoby się tego sprzedać na poziomie kilkudziesięciu tyś sztuk przynajmniej.
25.06.2020 09:31
[#70]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@abcdef, post #66
Czy ktoś to może rozpatrywać jako możliwą drogę rozwoju dla AmigaNG? Jasne, prawdę mówiąc można to było rozpatrywać już w czasach POWER8 bo i tak nie ma ANI JEDNEGO DESKTOPOWEGO PowerPC od tamtego czasu. To co jest to rozwiązania EMBEDDED i skończyły się na core e6500 (taki ulepszony e5500 z SMT i AltiVec) z 2012r (!!!)
Talos II i Blackbird. Tanio nie jest ale spoko desktop na Power9 można zbudować.
Koledzy sobie chwalą.
25.06.2020 09:54
[#71]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@hrw, post #70
Można, ale za tą kwotę masz ryzena czy i7 roznoszącego to w strzępy z kartą graficzną wypierdzielającą z fotela i z goglami vr ... I jeszcze zostanie na lodówkę pełną szampana. Jak G4 i nawet G5 było jakąś konkurencją w desktopie tak nie ma od dawna żadnego takiego produktu. I nic, włącznie z inicjatywą OpenPOWER nie wskazuje by to się miało zmienić.
25.06.2020 13:17
[#72]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@ingenic, post #3
Jeśli chodzi o Linuxa na PS3 to Sony bodajże zblokowało jego możliwości (przy oficjalnej instalacji). Ale i tak w pewnym okresie chyba był nawet projekt wykorzystania dużej ilości PS3 do obliczeń naukowych i tak zamawiano komputery.
Ogólnie sprawa była trochę dziwna, bo dzięki temu, że można było zainstalować Linuxa to bodajże PS3 miało jakieś preferencje podatkowe w niektórych krajach bo było traktowane jako komputer do pracy, a nie urządzenie do rozrywki. Potem skasowali możliwość instalacji Linuxa łamiąc prawo i przegrywając co najmniej w jednym kraju. Oczywiście na sprawie skasowania instalacji Linuxa najwięcej zarobili prawnicy, a zwykli użytkownicy stracili, mimo, że mogli dostać jakieś drobne za to.
Biorąc pod uwagę, że PS3 było bardzo drogie w momencie premiery, to instalacja Linuxa miała duży sens - tak kupowało się komputer, który można było wykorzystać do pracy/nauki, a w wolnym czasie do gier.
Ogólnie sprawa była trochę dziwna, bo dzięki temu, że można było zainstalować Linuxa to bodajże PS3 miało jakieś preferencje podatkowe w niektórych krajach bo było traktowane jako komputer do pracy, a nie urządzenie do rozrywki. Potem skasowali możliwość instalacji Linuxa łamiąc prawo i przegrywając co najmniej w jednym kraju. Oczywiście na sprawie skasowania instalacji Linuxa najwięcej zarobili prawnicy, a zwykli użytkownicy stracili, mimo, że mogli dostać jakieś drobne za to.
Biorąc pod uwagę, że PS3 było bardzo drogie w momencie premiery, to instalacja Linuxa miała duży sens - tak kupowało się komputer, który można było wykorzystać do pracy/nauki, a w wolnym czasie do gier.
25.06.2020 13:49
[#73]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@pgru2, post #72
Korzystałem z opcji Linuxa na PS3 i nawet wyszła specjalna dystrybucja YelloDog dla PS3. Istniało również polskojęzyczne forum na ten temat, ale korzystanie z tego systemu było bardzo uciążliwe z powodu małej ilości RAMu, a także nie wszystkie SPU były aktywne w tym systemie. Działało to bardzo powoli, dysk rzęził niemiłosiernie, a sam system potrafił się zawiesić i już nie podnieść.
25.06.2020 15:29
[#75]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@KM_Ender, post #74
X360 miał 3 takie same rdzenie i prędzej gry używały ich niż na PS3 gdzie własnie problemem było to że część multi platformowych gier nie używała więcej niż 1 głównego rdzenia. SPE w PS3 wymagały nietypowego programowania a chyba też SONY nie postarało się specjalnie z oprogramowaniem. W teorii SPE programuje się podobnie do GP-GPU dzisiaj. Dzsiaj to by OpenCL wystarczyło dać developerom i sprawa załatwiona.
X360 miał też lepiej zorganizowaną pamięć bo można było dowolnie dzielić pamięć pomiędzy CPU i GPU tak więc nic nie stało by na przeszkodzie aby do takiego Linuxa (tak, był dostępny, nieoficjalnie oczywiście) dać bardzo małą ilość pamięci dla GPU a resztę dać do CPU.
Poza tym X360 miał lepsze GPU bazujące na Radeonie x1900xt z 48 shaderami vs bazującego na 7900gtx GPU z PS3. Różnica w ilości shaderów nie powodowała 2x większej prędkości pixel shaderów bo Nvidia miała wydajniejsze shadery w tamtym czasie ale jednak X360 miał wydajniejszy GPU, i jeszcze pamięć eDRAM.
Ogólnie pod względem hardware X360 był lepiej przemyślany i bardziej spełniał oczekiwania developerów. To powiedziawszy dodam jeszcze że x pudło było strasznie badziewne i chyba już wszystkie X360 się do tej pory zepsuły i jedynie te które jeszcze się udało wygrzać w ręczniku są dostępne do zakupu
Ostatnia aktualizacja: 25.06.2020 15:30:42 przez XoR
X360 miał też lepiej zorganizowaną pamięć bo można było dowolnie dzielić pamięć pomiędzy CPU i GPU tak więc nic nie stało by na przeszkodzie aby do takiego Linuxa (tak, był dostępny, nieoficjalnie oczywiście) dać bardzo małą ilość pamięci dla GPU a resztę dać do CPU.
Poza tym X360 miał lepsze GPU bazujące na Radeonie x1900xt z 48 shaderami vs bazującego na 7900gtx GPU z PS3. Różnica w ilości shaderów nie powodowała 2x większej prędkości pixel shaderów bo Nvidia miała wydajniejsze shadery w tamtym czasie ale jednak X360 miał wydajniejszy GPU, i jeszcze pamięć eDRAM.
Ogólnie pod względem hardware X360 był lepiej przemyślany i bardziej spełniał oczekiwania developerów. To powiedziawszy dodam jeszcze że x pudło było strasznie badziewne i chyba już wszystkie X360 się do tej pory zepsuły i jedynie te które jeszcze się udało wygrzać w ręczniku są dostępne do zakupu
Ostatnia aktualizacja: 25.06.2020 15:30:42 przez XoR
25.06.2020 15:35
[#76]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@ingenic, post #73
Pomysł dodania opcji Other OS w PS3 był całkowicie bez sensu.
Gdyby konsola miała więcej pamięci albo możliwość jej rozszerzenia to jeszcze jak cię mogę ale tak to byłą to tylko ciekawostka. Poza tym wydajność tego jednego rdzenia PPU nie powalała w normalnych aplikacjach.
Gdyby konsola miała więcej pamięci albo możliwość jej rozszerzenia to jeszcze jak cię mogę ale tak to byłą to tylko ciekawostka. Poza tym wydajność tego jednego rdzenia PPU nie powalała w normalnych aplikacjach.
25.06.2020 15:46
[#77]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@hrw, post #70
Wygląda to fajnie.
MorphOS team jeśli nic nie wyjdzie z całego tego śmieszkowania o przejściu na x86 mógłby rozważyć port.
Zyskano by teoretyczną bo teoretyczną ale za to wydajną platformę a co najważniejsze mUFOludzki przestałyby szpanować najdroższym komputerem Power na dzielni
MorphOS team jeśli nic nie wyjdzie z całego tego śmieszkowania o przejściu na x86 mógłby rozważyć port.
Zyskano by teoretyczną bo teoretyczną ale za to wydajną platformę a co najważniejsze mUFOludzki przestałyby szpanować najdroższym komputerem Power na dzielni
25.06.2020 15:47
[#78]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@XoR, post #75
Yhm, nie do końca. Xbox miał lepsze GPU bo choć to był design z X19xx to ALU już były zunifikowane (a w zasadzie zostawiono same pixel shadery robiące jako zunifikowane). Dzięki temu obciążenie lepiej się dopasowywało do sceny. A CPU był bardzo potężny. Potężniejszy niż PPE Cella. Ale... no właśnie. RSX i SPE. Cell miał bezpośredni dostęp do RSX, efekt był taki, że tam gdzie RSX nie wyrabiał to Sony wspierało się SPE z Cella. To rozwiązanie też było bardzo sprytne, bo wydajność SPE do takich graficznych zastosowań była bliska teoretycznej maksymalnej i zdecydowanie podbijała możliwości RSX. Więc od strony samego CPU (czyli rdzeni Power) Xbox był lepszy. Jeśli chodzi o sam układ graficzny - tu znów Xbox był lepszy. Jeśli chodzi o całość - tutaj lepsze było PS3. SPE Cella łatało braki CPU lub GPU wedle potrzeb. Xbox szybko musiał wdrażać upscaling. Ciekawe by było ile można by wykrzesać z Xenona połączonego z wyżej taktowanym i większym SpursEngine i Xenosem. Mogłoby się okazać, że przejście na Jaguara było zupełnie niepotrzebne. Nie wydaje mi się by rynek konsolowy wiele zyskał dzięki wprowadzeniu x86 do nich.
25.06.2020 16:27
[#81]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@WojtekX, post #79
PS3 nie miał żadnego 6800 w SLI tylko GPU bazujący na NV47/G70 czyli 7900GTX.
Całe te 6800 w SLI to był cytat jakiegoś developera który tak porównał moc graficzną Playstation 3. Zostało to dawno dawno wyjaśnione i jedyne słuszne źródło wiedzy ludzkosci czyli ciocia Wikia nic o żadnym 6800 SLI nie wspomina a właśnie o NV47/G70
Ostatnia aktualizacja: 25.06.2020 16:27:58 przez XoR
Całe te 6800 w SLI to był cytat jakiegoś developera który tak porównał moc graficzną Playstation 3. Zostało to dawno dawno wyjaśnione i jedyne słuszne źródło wiedzy ludzkosci czyli ciocia Wikia nic o żadnym 6800 SLI nie wspomina a właśnie o NV47/G70
Ostatnia aktualizacja: 25.06.2020 16:27:58 przez XoR
25.06.2020 16:34
[#82]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@XoR, post #81
Nigdy Wikipedii nie uważam za źródło wiedzy.
Bo przyjdzie ten lub tamten i może zmienić bo tak uważa.
Model konsoli oznaczony jako CEB 1020, zawieral 2x 6800 GTX.
Ale był to model przedprodukcyjny.
Potem był 7800 GTX. Nie dam się pokroić.
Ostatnia aktualizacja: 25.06.2020 16:41:20 przez WojtekX
Bo przyjdzie ten lub tamten i może zmienić bo tak uważa.
Model konsoli oznaczony jako CEB 1020, zawieral 2x 6800 GTX.
Ale był to model przedprodukcyjny.
Potem był 7800 GTX. Nie dam się pokroić.
Ostatnia aktualizacja: 25.06.2020 16:41:20 przez WojtekX
25.06.2020 16:43
[#83]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@WojtekX, post #79
Prototypowy pierwszy model PS3 o nazwie kodowej "Shreck" owszem posiadał 6800 w SLI, ale konsumencki model posiada GPU RSX zbliżony do pecetowego GTX7800, ale RSX ma 128bitową szynę pamięci, natomiast GTX7800 256bit i tylko 8 jednostek renderujących, a GTX 7800 drugie tyle.
Ostatecznie RSX to słabe GPU.
A inny "kwiatek" w PS3 jest taki, że odczyt z pamięci graficznej przez procesor CELL wynosi marne 16MB/s. Podczas gdy zapis to 16.8GB/s
Chyba siakiś błąd konstrukcyjny :)
Ostatecznie RSX to słabe GPU.
A inny "kwiatek" w PS3 jest taki, że odczyt z pamięci graficznej przez procesor CELL wynosi marne 16MB/s. Podczas gdy zapis to 16.8GB/s
Chyba siakiś błąd konstrukcyjny :)
25.06.2020 16:48
[#84]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@abcdef, post #78
W późniejszych latach jak już był dostępny MLAA to X360 obliczał go na GPU a PS3 na SPE odciążając trochę układ graficzny. Podobnie mogło być było z innymi efektami post processingu jak SSAO.
Czy PS3 był faktycznie wydajniejszy to ciężko powiedzieć. Multiplatformy sugerują że X360 był wydajniejszy a gry od SONY to żaden wyznacznik bo nie wiemy co SONY by pokazało na hardware X360...
Największą zaletą PS3 był Blu-ray i dysk twardy montowany w każdej konsoli. No i mała awaryjność. Nawet pierwsze faty które niby się psuły raczej to robiły po ponad 2-3 latach a X360 potrafił się jeszcze na gwarancji zepsuć 2-3 razy
Czy PS3 był faktycznie wydajniejszy to ciężko powiedzieć. Multiplatformy sugerują że X360 był wydajniejszy a gry od SONY to żaden wyznacznik bo nie wiemy co SONY by pokazało na hardware X360...
Największą zaletą PS3 był Blu-ray i dysk twardy montowany w każdej konsoli. No i mała awaryjność. Nawet pierwsze faty które niby się psuły raczej to robiły po ponad 2-3 latach a X360 potrafił się jeszcze na gwarancji zepsuć 2-3 razy
25.06.2020 16:52
[#85]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@ingenic, post #83
Chyba to było tak że wydajność tego mostu pomiędzy CELL a GPU była inna w zależności które urządzenie requestowało dostęp. Raczej chyba było to przewidziane aby GPU czytało i pisało do pamięci CELL-a a nie w drugą stronę. Wtedy mogło by to mieć sens, GPU generuje klatkę, wysyła do CELL-a, on przerabia i wysyła do GPU do wyświetlenia.
25.06.2020 17:10
[#86]
Re: Procesor PPC, szybkość, wady, zalety, różnice do x86, ARM
@XoR, post #84
Biorąc pod uwagę, że więcej tytułów skalował xbox do fhd niż ps3 to śmiem wątpić by xbox był wydajniejszy.
Szczytowa wydajność prezentowała się mniej więcej tak:
Xenon 115GFLOPS, Xenos 240GFLOPS -> razem 355GFLOPS
PS3: Cell 230GFLOPS, RSX 250GFLOPS -> razem 480GFLOPS
rzecz w tym, że niezależnie od sceny Xenos mógł cały czas utrzymywać taką wydajność, a RSX miał ~210GFLOPS pixel shaderów i ~40GFLOPS vertex shaderów więc jak scena była z bogatą geometrią to mógł się zadławić. Poza tym albo mi się zdaje, albo Xenos miał teselator? To jeszcze podbijało jego wydajność w scenach ze złożoną geometrią (bo mniej dławiła się pamięć). Było parę sprytnych rozwiązań jak eDRAM z dodatkową logiką robiący aa, alpha blending itp. ale ogółem PS3 było mocniejszą konsolą. Xbox360 z kolei mniej kompromisów. Procki się programowało jak normalne procki, a nie pół procesor, pół simd (a w zasadzie 1/8 procesor, 6/8 simd - 1/8 zarezerwowana dla systemu), a grafika to był swoisty prototyp DirectX 10. Cała realna wydajność PS3 to właśnie SPE Cella. On tym dużo nadrabiał. Ale nie wydaje mi się by to się dobrze programowało.
Szczytowa wydajność prezentowała się mniej więcej tak:
Xenon 115GFLOPS, Xenos 240GFLOPS -> razem 355GFLOPS
PS3: Cell 230GFLOPS, RSX 250GFLOPS -> razem 480GFLOPS
rzecz w tym, że niezależnie od sceny Xenos mógł cały czas utrzymywać taką wydajność, a RSX miał ~210GFLOPS pixel shaderów i ~40GFLOPS vertex shaderów więc jak scena była z bogatą geometrią to mógł się zadławić. Poza tym albo mi się zdaje, albo Xenos miał teselator? To jeszcze podbijało jego wydajność w scenach ze złożoną geometrią (bo mniej dławiła się pamięć). Było parę sprytnych rozwiązań jak eDRAM z dodatkową logiką robiący aa, alpha blending itp. ale ogółem PS3 było mocniejszą konsolą. Xbox360 z kolei mniej kompromisów. Procki się programowało jak normalne procki, a nie pół procesor, pół simd (a w zasadzie 1/8 procesor, 6/8 simd - 1/8 zarezerwowana dla systemu), a grafika to był swoisty prototyp DirectX 10. Cała realna wydajność PS3 to właśnie SPE Cella. On tym dużo nadrabiał. Ale nie wydaje mi się by to się dobrze programowało.
