Infos sur la Vampire

15 sujets de 136 à 150 (sur un total de 971)

lexomil
18 avril 2017 à 19h55 #283852
@sinisrus

ok, partons d’un exemple simple, je veux copier un écran de 320x200x8bits dans un buffer, j’aurais un truc du genre

[code]
move.l AdrSource,a0
move.l AdrDest,a1
move.w #199,d0
.CopyLine:
move.w #(320/4)-1,d1
.CopyFourByte:
move.l (a0)+,(a1)+
dbf d1,.CopyFourByte
dbf d0,.CopyLine
[/code]

comme nous sommes des développeurs d’asm nous sommes obsédés par la consommation des cycles machines (et un peu par la consommation de bière aussi)
simplifions l’affaire en disant que chaque instruction coûte 1 cycle machine, la boucle intérieure coute 1 cycle pour le move et 1 cycle pour le dbf, on fait 80 itérations donc on a 160 cycles pour cette boucle, que l’on répète 200 fois (pour les 200 lignes) ce qui donne 32000 cycles.

Maintenant si on déroule la boucle interne en éliminant le dbf et en répétant 80 fois l’instruction move.l (en utilisant des directives d’assemblage du genre REPT / ENDR) on diminue de suite le coût par 2, 80 cycles pour la boucle interne x 200 lignes = 16000 cycles et en plus on économise un registre.

[code]
.CopyLine:
REPT (320/4)
move.l (a0)+,(a1)+
ENDR
dbf d0,.CopyLine
[/code]

Voilà le principe pour dérouler une boucle.
lexomil
18 avril 2017 à 20h24 #283856
Hop, petite mise à jour reprenant la dernière version de flype

http://flabrador.free.fr/lexo/amiga/files/VampireDemo2D_0.6.zip

l’idée de « compresser » les sprites est intéressant, sans doute à creuser.

j’étais partis sur le principe du sprite « hard » qui consiste à générer le code de copie des pixels non transparent et donc à totalement éliminer les tests de transparence, j’essaierai de faire ça dans une prochaine version.

Bonne soirée
flype
18 avril 2017 à 21h24 #283859
Excellent merci beaucoup Lexomil.

Sinon oui en effet, çà m’a un peu échappé en réponse à Alain, toutes les instructions prennent un seul cycle (par exemple lsl, add, sub, move Dn,Dn) à l’exception des instructions arithmétiques mul et div et des accès mémoire indirects qui prendront autant de cycles que nécessaires, la prédiction des sauts est également extrêmement efficace. Enfin en effet, un certain nombre de couples d’instructions s’exécutent en un cycle, sans compter aussi le 2nd pipeline, performant. Pour finir, il y a l’AMMX, présenté ici :

http://forum.apollo-accelerators.com/viewtopic.php?f=10&t=25

et des notes d’optimisations ici :

http://forum.apollo-accelerators.com/viewtopic.php?f=10&t=1702

Ces notes proviennent du codeur de RiVA « AMMX », Henrick Richter, le développeur de EaglePlayer, membre de la team.

A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
flype
18 avril 2017 à 21h28 #283860
Jul wrote:

@Jul
Euh… la version Vampire de RIVA peut-elle jouer les épisodes de Jayce ?

Vu la qualité, compressé comme il faut, tu dois même pouvoir en regarder 2 en même temps sur le workbench 😉

A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
Discor
18 avril 2017 à 23h22 #283867
@jul

Oui, depuis le temps je me suis fait a l’idée 🙂

Et il y a une version spécifique de Riva destiné à la Vampire ? C’est cool si c est le cas j’avais complètement raté l’info. (mais j’avoue aller moins sur les forums de la team dernièrement, faute de temps)
sinisrus
18 avril 2017 à 23h48 #283868
Merci lexomil. moi qui fais du Hollywood je pensé que ça pourais me servir de savoir mais en faite je ne pense pas vu que c’est plus du basic Hollywood. Merci quand même 🙂

@flype on a une idée du prix de la vampire standalone ou c’est encore trop tôt? Sinon des specs? en terme de puissance on sera toujours en MHz pour le CPU ou alors on va passé le GHz?
flype
19 avril 2017 à 10h20 #283888
@Discor

En effet, RiVA AMMX est disponible sur Aminet depuis début février, sources assembleur inclus :
http://aminet.net/package/gfx/show/RiVA-0.52

@Sinisrus

En effet, en Assembleur c’est tout de suite plus visible, alors qu’en Basic on n’est plus à 100 cycles près, quoique,
```
N=(640-1)
For I=0 to N
  DoThat()
Next
```
```
N=(640/4)-1
For I=0 to N
  DoThat()
  DoThat()
  DoThat()
  DoThat()
Next
```
Tu gagnes quand même autant de sauts (for/next) que tu as déroulé la boucle. Dans une boucle critique, même en Basic, il y aura peut-être un gain. A ce propos, l’Apollo-Core est capable de mesurer çà en temps réel (CPUMon utilise cette fonctionnalité).

Concernant, la standalone, je ne peux rien dire pour le moment désolé 🙂 si ce n’est que non on ne dépasse pas le GHz du tout, le prix sera un prix abordable, donc specs raisonnées, tout en étant plus performante que la génération actuelle.

A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
Jul
19 avril 2017 à 10h30 #283890
Les compilateurs modernes savent dérouler les boucles. Mais ils le font intelligemment, car parfois le gain est annihilé par le fait que le code ne tient plus dans le cache du processeur (parfois, du code compact avec boucles est plus rapide que du code déroulé sans boucle à cause de ça).

Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233
flype
19 avril 2017 à 10h34 #283891
Oui tout à fait, par contre si le For I=0 to (Ici_une_formule_au_lieu_d_une_variable), je ne suis pas sûr qu’il pourra optimiser.

A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
sinisrus
19 avril 2017 à 11h33 #283900
Merci pour le retour flype 🙂

et l’exemple de boucle aussi 🙂
flype
22 avril 2017 à 20h21 #284120
sympa çà :

MUIMapparium on Vampire

A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
thellier
23 avril 2017 à 11h20 #284154
Hello

Pour revenir au sujet:

Lu sur apollo-core.com
Gunnar von Boehn:

« >Quels modes planar sont prévus dans SAGA?
SAGA offre

a) Les possibilités graphiques Amiga d’origine
Palette (registres) de 256 couleurs en 24bit+ pour Sprites / modes planar

b) un 9éme pointeur de bitsplan
ce pointeur founit un nouveau Playfield qui supporte les formats suivant.
– PLANAR MODE
– PLANAR ATARI MODE
– 8Bit Clut
– 15Bit
– 16BIT Hicolor
– 24bit Truecolor
– NEO-GEO Mode
– 32 Bit Alpha + Truecolor
– YUV Video mode

Palette (registres) de 256 couleurs de plus (NDT: soit 512 couleurs)

> Ces modes sont il dispo dans toutes les resolutions ?

Evidemmment les resolutions sont totalement programmables. On peut définir ce qu’on veut

Ce qui est important c ‘est que tout les modes sont 100% controlables au copper.
Anis on peut même les mixer…

Ainsi en théorie on pourra afficher playfield truecolor 24bit derrière et devant un Magic WB en 8 Couleurs planar….

Ou utiliser tout les 9 bitplans an mode planar et avoir (une palette) 512 registres couleur ainsi.

Un esprit créatif pourra en faire des trucs cools »
flype
23 avril 2017 à 11h25 #284155
Oui c’est en cours de développement pour le Gold3, j’ai pu tester et çà comme à être sympa.

A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
receptor
23 avril 2017 à 13h16 #284166
Neo Geo mode?
cela veux dire compatible en hard a la neo pour les jeux en couleurs nombre de sprint scroling etc?
a quand une implatation de piussance du jeux Galaxi force 2 ? en hard.
flype
23 avril 2017 à 17h06 #284180
Il s’agit de modes Video, c’est à dire du format des pixels, un mode Neo Geo apporte un support pour le format des pixels de la Neo Geo, en natif, sans avoir besoin de les convertir, il ne s’agit pas d’une émulation d’une Neo Geo, mais plutôt d’un mode s’économisant la conversion des pixels pour qui souhaite développer un vrai émulateur pour le coup.

A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.