Parhaat Amiga AGA-demot!

Vuonna 1992 Intelin paras prosessori oli 486/66 MHz, ja Motorolalla oli paras 68040/40 MHz, jotka olivat molemmat suunnilleen yhtä tehokkaita kokonaislukulaskennassa. 68040 oli huomattavasti suorituskykyisempi kuin 486, varsinkin moninkertainen teho liukulukulaskennassa. Tämä siis tilanne vuoden 1992 loppupuolella.

AGA-Amigat julkaistiin loppuvuonna 1992 myös, joten joo, rautaa oli olemassa vuonna 1992 sekä Intelillä että Commodorella/Motorolalla pyörittää näitä demoja, mutta mitä sitten? Se, että jotain on mahdollista tehdä, ei tarkoita sitä että asia tehdään. Kyllähän siinä aikaa meni että opittiin ohjelmoimaan ja että prosessorien hinta tuli alas.

Anonyymi kirjoitti:

Vuonna 1992 Intelin paras prosessori oli 486/66 MHz, ja Motorolalla oli paras 68040/40 MHz, jotka olivat molemmat suunnilleen yhtä tehokkaita kokonaislukulaskennassa. 68040 oli huomattavasti suorituskykyisempi kuin 486, varsinkin moninkertainen teho liukulukulaskennassa. Tämä siis tilanne vuoden 1992 loppupuolella.

AGA-Amigat julkaistiin loppuvuonna 1992 myös, joten joo, rautaa oli olemassa vuonna 1992 sekä Intelillä että Commodorella/Motorolalla pyörittää näitä demoja, mutta mitä sitten? Se, että jotain on mahdollista tehdä, ei tarkoita sitä että asia tehdään. Kyllähän siinä aikaa meni että opittiin ohjelmoimaan ja että prosessorien hinta tuli alas.

Lue lisää

68040:ssä oli yksi merkittävä heikkous: Siinä oli vain 4kt cache. Tuo rajoitti toistuvan tekstuurin koon 32x32 pikselin kokoiseksi.

486:ssa oli avainjuttuna 8kt cache, että saatiin 64x64 pikselin kokoista tekstuuria käytettyä toistuvasti, tai vaikka 64x64 pikselin kokoinen billboard mitä monistaa. Sopi kivasti L1 cacheen palette lookupin kanssa.

486:lle kyllä tehtiin sitten sitä tekstuurimapattua 3D-grafiikkaa silloin 90-luvun alkupuolella peleissä, ei vain demoissa.

Anonyymi kirjoitti:

68040:ssä oli yksi merkittävä heikkous: Siinä oli vain 4kt cache. Tuo rajoitti toistuvan tekstuurin koon 32x32 pikselin kokoiseksi.

486:ssa oli avainjuttuna 8kt cache, että saatiin 64x64 pikselin kokoista tekstuuria käytettyä toistuvasti, tai vaikka 64x64 pikselin kokoinen billboard mitä monistaa. Sopi kivasti L1 cacheen palette lookupin kanssa.

486:lle kyllä tehtiin sitten sitä tekstuurimapattua 3D-grafiikkaa silloin 90-luvun alkupuolella peleissä, ei vain demoissa.

Lue lisää

Ei pidä paikkaansa. 68040:ssa on myös 8 kt cache, mutta siinä on erikseen 4 kt muistia datalle, ja 4 kt käskyille. Voit unohtaa sen että 486:n välimuistiin mahtuu 2x enemmän dataa, koska koodia menee myös cacheen. Yleensä tällainen jaettu välimuisti on tehokkaampi kuten 68040:ssa on, koska mm dataa ja käskyjä voi käsitellä rinnakkain, mutta on toki tilanteita, jossa 486:n cache toimii nopeammin.

Isompi ongelma on kuitenkin 486:n rekisterien vähyys, 68040:ssa on 16 kpl 32-bittisiä rekistereitä, joista 8 kpl on datarekistereitä, ja 8 kpl osoiterekistereitä.

Anonyymi kirjoitti:

Ei pidä paikkaansa. 68040:ssa on myös 8 kt cache, mutta siinä on erikseen 4 kt muistia datalle, ja 4 kt käskyille. Voit unohtaa sen että 486:n välimuistiin mahtuu 2x enemmän dataa, koska koodia menee myös cacheen. Yleensä tällainen jaettu välimuisti on tehokkaampi kuten 68040:ssa on, koska mm dataa ja käskyjä voi käsitellä rinnakkain, mutta on toki tilanteita, jossa 486:n cache toimii nopeammin.

Isompi ongelma on kuitenkin 486:n rekisterien vähyys, 68040:ssa on 16 kpl 32-bittisiä rekistereitä, joista 8 kpl on datarekistereitä, ja 8 kpl osoiterekistereitä.

Lue lisää

Tuossa 3D-grafiikassa se koodi optimointiin assemblerilla niin, että suurin osa ajasta menee pienessä silmukassa. Kriittinen kohta oli rasterointi. Siinä tosiaankin pyöri pieni optimoitu silmukka kossa koodia oli vähän. Sen sijaan dataa oli yli 4kt kun se pelkkä 64x64 tekstuuri vei tasan 4kt, mutta lisäksi sitten oli paletti lookup, että riippuen varjostuksesta tai etäisyydestä kameraan, napattiin eri paletista väriä ja ne piti saada myös sopimaan data cacheen.

486:ssa 3D-grafiikan piirrossa rekisterien vähyys todellakin oli ongelma.

Noin perstuntumalla 68040 ja 486 olivat varmaan jokseenkin samantasoisia mutta piirrettäviä asioita optimoitiin eri tavalla.

68040:lla jos oli 64x64 pikselin tekstuuri, siinä ei oikein voinut olla varjostusta mikä oli oikeastaan aika huono juttu piirrettäessä isoja varjostettuja polygoneja joissa toistuva kuvio.

486:lla taas mieluusti välteltiin tekstuureja ja samanaikaisia tekstuuri gouraudin jos jostain sai huomaamatta pois esimerkiksi LOD:ia käyttämällä koska rekisterien vähyys hyydytti rasteroinnin sisäsilmukkaa.

Anonyymi kirjoitti:

Tuossa 3D-grafiikassa se koodi optimointiin assemblerilla niin, että suurin osa ajasta menee pienessä silmukassa. Kriittinen kohta oli rasterointi. Siinä tosiaankin pyöri pieni optimoitu silmukka kossa koodia oli vähän. Sen sijaan dataa oli yli 4kt kun se pelkkä 64x64 tekstuuri vei tasan 4kt, mutta lisäksi sitten oli paletti lookup, että riippuen varjostuksesta tai etäisyydestä kameraan, napattiin eri paletista väriä ja ne piti saada myös sopimaan data cacheen.

486:ssa 3D-grafiikan piirrossa rekisterien vähyys todellakin oli ongelma.

Noin perstuntumalla 68040 ja 486 olivat varmaan jokseenkin samantasoisia mutta piirrettäviä asioita optimoitiin eri tavalla.

68040:lla jos oli 64x64 pikselin tekstuuri, siinä ei oikein voinut olla varjostusta mikä oli oikeastaan aika huono juttu piirrettäessä isoja varjostettuja polygoneja joissa toistuva kuvio.

486:lla taas mieluusti välteltiin tekstuureja ja samanaikaisia tekstuuri gouraudin jos jostain sai huomaamatta pois esimerkiksi LOD:ia käyttämällä koska rekisterien vähyys hyydytti rasteroinnin sisäsilmukkaa.

Lue lisää

Nyrkkisääntö on että 68040 on noin 4 kertaa nopeampi kuin samalla kellotaajuudella pyörivä 68030. Mutta 486 on vain noin 2 kertaa nopeampi kuin samalla kellotaajuudella pyörivä 68030. Lopputulos on että 68040 on lähes 2 kertaa nopeampi kuin samalla kellotaajuudella pyörivä 486 kokonaislukutoiminnoissa. Ja liukuluvuissa moninkertainen nopeus.

Amigalla tyypillinen innerloop, jossa piirettiin yksi teksturoitu pikseli kerrallaan vei 5 käskyä.

Ongelmana Amigoissa on taas pieni muistinopeus, ei ole VLB-tasoista grafiikkamuistin nopeus, ja prosessorikortit oli osa huonosti tehty, niin että prosessorin FAST-muistikin oli aika hidasta. Nykyiset kortit ovat nopeampia, esim. 68060/100 MHz pääsee lähes 100 MB/s muistinopeuteen FAST-muistissa, vanhoissa korteissa oli 40-60 MB/s maksimi (toki myös alhaisemmat kellotaajuudet). Lopuksi vielä c2p-käännös päälle, koska Amigoissa ei ole 8-bit chunky pixel-moodia.

Onneksi 68020 alkaen on sellainen feature että jos kirjoittaa prosessorilla muistiin, niin prosessori voi jatkaa käskyjen suoritusta, kunhan ei koske muistiin uudestaan, kunnes edellinen muistikirjoitus on suoritettu. On meinaan elintärkeä, jos on latenssia hitaassa grafiikkamuistissa, ettei prosessori pysähdy siihen täysin. Siinä saa sitten keksiä järkevää työkuormaa, onneksi m68k:ssa on paljon rekistereitä jolloin muistiin ei tarvitse koskea.

Sanoisin että 68030/50 MHz on optimaalinen prosessori AGA-koneille, 68040 tai 68060 ovat liian nopeita ja menettävät osan tehostaan hitaaseen grafiikkamuistiin kaikesta huolimatta, mikä on harmi.

Anonyymi kirjoitti:

Nyrkkisääntö on että 68040 on noin 4 kertaa nopeampi kuin samalla kellotaajuudella pyörivä 68030. Mutta 486 on vain noin 2 kertaa nopeampi kuin samalla kellotaajuudella pyörivä 68030. Lopputulos on että 68040 on lähes 2 kertaa nopeampi kuin samalla kellotaajuudella pyörivä 486 kokonaislukutoiminnoissa. Ja liukuluvuissa moninkertainen nopeus.

Amigalla tyypillinen innerloop, jossa piirettiin yksi teksturoitu pikseli kerrallaan vei 5 käskyä.

Ongelmana Amigoissa on taas pieni muistinopeus, ei ole VLB-tasoista grafiikkamuistin nopeus, ja prosessorikortit oli osa huonosti tehty, niin että prosessorin FAST-muistikin oli aika hidasta. Nykyiset kortit ovat nopeampia, esim. 68060/100 MHz pääsee lähes 100 MB/s muistinopeuteen FAST-muistissa, vanhoissa korteissa oli 40-60 MB/s maksimi (toki myös alhaisemmat kellotaajuudet). Lopuksi vielä c2p-käännös päälle, koska Amigoissa ei ole 8-bit chunky pixel-moodia.

Onneksi 68020 alkaen on sellainen feature että jos kirjoittaa prosessorilla muistiin, niin prosessori voi jatkaa käskyjen suoritusta, kunhan ei koske muistiin uudestaan, kunnes edellinen muistikirjoitus on suoritettu. On meinaan elintärkeä, jos on latenssia hitaassa grafiikkamuistissa, ettei prosessori pysähdy siihen täysin. Siinä saa sitten keksiä järkevää työkuormaa, onneksi m68k:ssa on paljon rekistereitä jolloin muistiin ei tarvitse koskea.

Sanoisin että 68030/50 MHz on optimaalinen prosessori AGA-koneille, 68040 tai 68060 ovat liian nopeita ja menettävät osan tehostaan hitaaseen grafiikkamuistiin kaikesta huolimatta, mikä on harmi.

Lue lisää

"Lopputulos on että 68040 on lähes 2 kertaa nopeampi kuin samalla kellotaajuudella pyörivä 486 kokonaislukutoiminnoissa. Ja liukuluvuissa moninkertainen nopeus."

Niin mutta kyseessähän ei ole pelkät kellojaksot kun lasketaan asioita. Commodore 64:llä se oli suunnilleen näin.

Uudemmilla koneilla prosessorin rekisterien ja muistijärjestelmän välinen kaista on kokoajan ratkaisevampi. Amiga 500:lla käytännössä laskettiin mikä kaista on ja paljon tarvitsee sekunnissa piirtää kun blitterillä tekee operaatioita. Viimeiset 20v tuskin on missään saatu olennaisesti eroa assemblerilla hinkkaamalla missään kun yhdessä kääntäjien kehittymisen kanssa, marginaalisesti vähemmän kellojaksoja käyttävä ei merkitse mitään kun jarru on muistikaistassa.

Piirrettäessä GPU:lla, koko piirron kuormittavuus menee käytännössä muistikaistan mukaan. Cachet ovat lähinnä sitä varten, että nopeuttavat hakuja kun shaderit laskevat asioita.

Softarenderöinnissä oli ensisijaisen tärkeää saada rasteroinnin silmukat toimimaan L1 cachessa. Muistikaista oli niin tiukassa, että esimerkiksi Z-bufferia ei kannattanut käyttää. Oli paljon tehokkaampaa pitää polygonimäärä rajallisena ja käyttää z-sorttia. Näin siis jo sillä VLB väylällä.

"Ongelmana Amigoissa on taas pieni muistinopeus, ei ole VLB-tasoista"

Niin. Eli turha toivo 64x64 pikselin tekstuureilla fillata kuvaa kun tulisi cachemissiä koko aika.

68040/40MHz käytännössä vastasi 486DX2/66MHz
68030/50MHz vastasi 486DX/25MHz

Anonyymi kirjoitti:

"Lopputulos on että 68040 on lähes 2 kertaa nopeampi kuin samalla kellotaajuudella pyörivä 486 kokonaislukutoiminnoissa. Ja liukuluvuissa moninkertainen nopeus."

Niin mutta kyseessähän ei ole pelkät kellojaksot kun lasketaan asioita. Commodore 64:llä se oli suunnilleen näin.

Uudemmilla koneilla prosessorin rekisterien ja muistijärjestelmän välinen kaista on kokoajan ratkaisevampi. Amiga 500:lla käytännössä laskettiin mikä kaista on ja paljon tarvitsee sekunnissa piirtää kun blitterillä tekee operaatioita. Viimeiset 20v tuskin on missään saatu olennaisesti eroa assemblerilla hinkkaamalla missään kun yhdessä kääntäjien kehittymisen kanssa, marginaalisesti vähemmän kellojaksoja käyttävä ei merkitse mitään kun jarru on muistikaistassa.

Piirrettäessä GPU:lla, koko piirron kuormittavuus menee käytännössä muistikaistan mukaan. Cachet ovat lähinnä sitä varten, että nopeuttavat hakuja kun shaderit laskevat asioita.

Softarenderöinnissä oli ensisijaisen tärkeää saada rasteroinnin silmukat toimimaan L1 cachessa. Muistikaista oli niin tiukassa, että esimerkiksi Z-bufferia ei kannattanut käyttää. Oli paljon tehokkaampaa pitää polygonimäärä rajallisena ja käyttää z-sorttia. Näin siis jo sillä VLB väylällä.

"Ongelmana Amigoissa on taas pieni muistinopeus, ei ole VLB-tasoista"

Niin. Eli turha toivo 64x64 pikselin tekstuureilla fillata kuvaa kun tulisi cachemissiä koko aika.

68040/40MHz käytännössä vastasi 486DX2/66MHz
68030/50MHz vastasi 486DX/25MHz

Lue lisää

"Niin. Eli turha toivo 64x64 pikselin tekstuureilla fillata kuvaa kun tulisi cachemissiä koko aika."

Ei se näinkään mene, koska koko kuvaruutu renderöidään ensin FAST-muistissa, ennenkuin kopioidaan kuvaruutu kokonaisuudessaan CHIP-muistiin. FAST-muistissa on cachemuisti normaalisti käytössä.

Onneksi Amiga on kuitenkin joustava kone, eli pystytään nopeuttamaan c2p prosessia pudottamalla värimäärää (esim 256 värin sijaan 64 väriä, 32, tai 16 väriä), ja/tai jättämällä pois osan c2p-rutiinista, jolloin itse renderöinnistä tulee hankalampaa, koska framebufferista tulee epälineaarinen ,eli pikselit tulevat epäjärjestyksessä. Pystyykö tällä sitten nopeuttamaan renderöintiä, riippuu siitä että miten paljon ekstraa työtä joutuu tekemään sen vuoksi että framebuffer on epälineaarinen.

"68040/40MHz käytännössä vastasi 486DX2/66MHz
68030/50MHz vastasi 486DX/25MHz"

Näin se menee suunnilleen.

Anonyymi kirjoitti:

"Niin. Eli turha toivo 64x64 pikselin tekstuureilla fillata kuvaa kun tulisi cachemissiä koko aika."

Ei se näinkään mene, koska koko kuvaruutu renderöidään ensin FAST-muistissa, ennenkuin kopioidaan kuvaruutu kokonaisuudessaan CHIP-muistiin. FAST-muistissa on cachemuisti normaalisti käytössä.

Onneksi Amiga on kuitenkin joustava kone, eli pystytään nopeuttamaan c2p prosessia pudottamalla värimäärää (esim 256 värin sijaan 64 väriä, 32, tai 16 väriä), ja/tai jättämällä pois osan c2p-rutiinista, jolloin itse renderöinnistä tulee hankalampaa, koska framebufferista tulee epälineaarinen ,eli pikselit tulevat epäjärjestyksessä. Pystyykö tällä sitten nopeuttamaan renderöintiä, riippuu siitä että miten paljon ekstraa työtä joutuu tekemään sen vuoksi että framebuffer on epälineaarinen.

"68040/40MHz käytännössä vastasi 486DX2/66MHz
68030/50MHz vastasi 486DX/25MHz"

Näin se menee suunnilleen.

Lue lisää

"Ei se näinkään mene, koska koko kuvaruutu renderöidään ensin FAST-muistissa, ennenkuin kopioidaan kuvaruutu kokonaisuudessaan CHIP-muistiin. FAST-muistissa on cachemuisti normaalisti käytössä."

Niin mutta kun se FAST-muistikin on tässä liian hidas, että tarkoitus on että ei tule mitään muistihakuja tekstuuria luettaessa kun on ensimmäisen kerran luettu tekstuuri L1 cacheen.

Sellainen temppu voi toimia, että 64x64 tekstuuri onkin tallennettu 4-bit/pikseli jolloin se sopisi L1 cacheen.