De memory bandbreedte is de beperking. De ARM kan sneller lezen en schrijven dan de blitter omdat er sneller geheugen in de Arhcimedes zat.
Dat is een onzin-argument natuurlijk. De blitter in een A1200 was ook sneller dan die in de A500/1000/2000, omdat er sneller geheugen in zat.
Je ontwerpt natuurlijk je systeem dusdanig dat alles op elkaar aansluit qua performance.
Jij kent de ARM instructie set niet. Just dingen als schuiven + optellen en mask is een enkele ARM instrucktie.
Die ken ik wel. En *binnen een register* kun je dat leuk doen ja. Maar als je een hele bitmap een paar bits moet verplaatsen, moet je dus meerdere registers shiften en met elkaar combineren.
Je hebt dus, zoals ik al zei, *meer* instructies nodig dan alleen load/store. Dus gaat je efficientie omlaag.
Bij de blitter is dit niet het geval, het doorschuiven van bits is 'gratis'.
Dat heet clipping en dat kan de VIDC1a binnen de Archimedes.
Nee, dat heet geen clipping, dat betekent dat een hele loop van:
for (y = lowy; y < highy; y++)
{
for (x = lowx; x < highx; x++)
{
ProcessPixel(x, y);
}
UpdatePointersToNextScanline();
}
1 blitter-operatie is. Geen instructies, geen loops, niks. Dit hele gebeuren doet de blitter als 1 operatie. Alle pointer-updates, het masken van bits aan de randen, het verschuiven van bits om de juiste pixels van source naar destination te kopieren, wordt allemaal automatisch door de blitter gedaan, zonder dat het tijd kost.
Is nl handig voor je window manager. RISCOS was nl het eerste OS dat real time solid windows kon verslepen met een framerate van 25 frames/s Amiga en Atari en Apple versleepten enkel wire frames in die tijd.
De Amiga kon het wel (in games wordt het wel gedaan, en dan wel op 50 fps natuurlijk, ipv 25 fps), maar dat zou het systeem trager maken. Itt RISCOS was AmigaOS namelijk multitasking, en al je bandbreedte verstoken aan het verplaatsen van windows, zodat achtergrondtaken stil komen te liggen, is niet wat je wil.
Exact. De blitter heeft dus veel toegevoegde waarde als het gaat om memory fils en de commodore ontwerpers hebben dit prima uitgevoerd. Een 8 Mhz ARM heeft in tegenstelling van de 68000 wel de capaciteit om full speed het geheugen te vullen en wordt geholpen door de geheugen indeling die geconfigureerd wordt door Memc en IOC (cam mapping). Door de geheugen indeling kan de ARM sequentieel doorschrijven.
Dit is dus een drogreden. Maargoed, je zult het nooit toegeven, hoe vaak ik ook aantoon dat:
1) Een general purpose CPU NOOIT zo efficient is als een blitter (zie nogmaals hierboven).
2) Je dit probleem niet hebt met chip-mem en fast-mem naast elkaar.
3) Dat sequentieel doorschrijven is natuurlijk maar beperkt. Als je echt sprites/karakters/etc op het scherm gaat kopieren en bewegen, dan heb je te maken met de grootte van die sprites/karakters/etc, en de positie waarop ze moeten komen te staan. En dan is je leuke swizzled memory layout ineens niet zo handig.
De blitter is hier al op voorbereid, je kunt per channel aangeven wat de modulo is voor iedere scanline, dus zoals ik al zeg, het kopieren van een 2d-blok naar een willekeurig ander 2d-blok, met verschillende indeling qua scanline-lengte, is geen probleem. Allemaal 1 operatie.
Commodore heeft hier goed over nagedacht maar het blijft een slimme memory fill chip die de 68000 versterkt op de punten waar hij zwak is en dus geen waarde heeft in een RISC architectuur
Nee, want zoals zo vaak aangetoond, ook met een RISC-architectuur, zelfs als die zo slim is als de ARM, zit je meerdere instructies te verstoken om een enkel word met pixels te processen.
Je verbruikt dus WEL de maximale bandbreedte, maar die wordt NIET compleet gebruikt om de daadwerkelijke operaties uit te voeren, maar ook door inefficientie van de general purpose CPU.
Een blitter heeft deze beperking niet.
Een GPU heeft een totaal andere architectuur waarbij je twee hoofd onderdelen moet onderscheiden NL heel veel paralelle data processors en paralelle pixel shaders. (De Voodoo1, de eerste echte GPU werkte al zo) Bijde zijn zelstandige cores die instructies kunnen uitvoeren en dat heel snel doen.
En hoe is dat anders dan de copper+blitter in de Amiga?
De copper en blitter zijn namelijk ook zelfstandig, zoals ik al eerder uitlegde.
Ik kan niet anders doen dan steeds maar weer de conclusie trekken dat je gewoon uit je nek kletst. Zelfs van de kant van ARM/Archimedes klopt je verhaal voor geen meter (de 'code' die je aangeeft voor een blit bv is niet eens een blit, en ook over pixel-adresseren heb ik je nog niet gehoord).
Daarnaast snap je al HELEMAAL niet hoe een Amiga werkt met z'n copper, blitter en fastmem, gezien je uitlatingen over polygons tekenen etc.
Wat doe je eigenlijk in deze discussie?
En hoe lang denk je dit vol te kunnen houden?
Heb je me al gegoogled? Misschien moet je dat eens doen, dan kun je zien wat ik zoal zelf gecode heb op oa de Amiga, en ook op de GP2X, welke twee ARM SoCs gebruikt.
Je denkt toch niet dat je mij kunt overbluffen? Ik weet wel waar ik het over heb.
(De Voodoo1, de eerste echte GPU werkte al zo)
Nee, de Voodoo1 had helemaal geen vertex-processing, en 'pixel shaders' waren niet veel meer dan wat hardwired texturing en gouraud interpolators en een saturated multiply (het is dan ook niet de eerste echte GPU, die kwam pas veel later in de vorm van de GeForce256).
Eigenlijk niet heel anders dan een blitter dus. Behalve dat er geen copper bij zat om hem aan te sturen, dus de CPU dat moest doen, met screen-space paralellograms, stuk voor stuk.
Pas later kon je lijsten van geometrie tegelijk pushen.
[Reactie gewijzigd door Verwijderd op 23 juli 2024 10:11]