LMP3D , une nouvelle lib 3D pour PS1,PS2,Dreamcast,PC et bientot GC/Wii

[Invité]

Je comptais présentais ma lib quand j'aurais au moins une release stable , mais vu le temps que je met pour ça

J'avais bossé sur la SNES , mais disons que ma curiosité a pris le dessus pour ces machines plus 'récente' , et puis cela m'a permis de mieux comprendre comment fonctionne les processeurs moderne ^^
Donc le but de la lib  est d'avoir le même code (portabilité) et que ceci soit optimisé pour chaque plateforme , niveau chiffre ça donne ceci :
PS2 : 110 000 à 130 000 triangles/frame
Dreamcast : 30 000 triangles/frame
PS1 : 2000-3000 triangles (sur émulateur)
J'ai mis un "Backface culling" sur PS1 et DC mais pas sur PS2 (disons qu'elle fonctionne un peu différemment et c'est pas les bons triangles qui sont enlevé )

D'ailleurs je compte ne plus avancer la version PS1 , pour la bonne raison que la console est très chiante à programmer pour la 3D , (des matrices 3x3 , des nombres a virgule fixe , pas de Zbuffer etc etc).
Et donc consacrer mon temps sur des consoles plus intéressant comme la GC/Wii (si je les met ensemble c'est que la Wii a le même hardware que la GC mais en plus puissant :p ).

Pour la Saturn et la N64 je ne compte pas m'y atteler avant un moment , pour la Saturn parce que j'aurais les même soucis que la PS1 mais en pire
Et la N64 parce que ben il manque encore des outils pour que je code dessus , donc ça sera sûrement la PSP qui sera en ligne de mire
(Après ça marche aussi sur Windows et Linux , mais c'est pas forcément le plus compliqué ça )
Niveau code , c'est du C et de l'assembleur ,je trouve l'asm sur 8/16 bits gentillet a coter de ce genre de monstre surtout pour la PS2 , faire tout les calcul 3D en asm 128 bits et superscalaire , quel pied 

Pour les démo les voici :


La version PS1 :


De la 2D:


PS: ah oui comme je le vois souvent ici , Code::Block permet de lancer un émulateur aussi
Et bien sur le Github du projet : https://github.com/Kannagi/LMP3D

[Urbinou]

Bravo, impressionnant !

[troudki]

WAou.. C'est très prometteur Kannagi.. Bravo 
Attaquer un lib 3D sur autant de consoles en même temps c'est peu crazy   
du coup, il faut coder sur PC et à la fin on compile sur la console cible ?

[Invité]

Merci pour vos commentaires, vu que c'est au moins plusieurs mois (voir plus d'une année) de boulot en R&D que j'ai du fournir !

Les performances que j'ai obtenu sont du a pas mal de boulot derrière , mes premières version n'affichait pas autant de triangle (pour la PS2 je n'affichait a peine plus de 30 000) , la version PS2 est assez autonome (je crois que j'utilise que la lib C et joypad ) , pareil pour la Dreamcast qui est assez indépendante de la lib kos , et je n'utilise pas la libpvr , j'en utilise une modifier (par mes soins) pour l'initialisation de la DC, pour le rendu c'est fait maison par contre

du coup, il faut coder sur PC et à la fin on compile sur la console cible ?

C'est cela , ben comme sur les consoles 8/16 bits , (pour ceux qui utilise la langage C).
D'ailleurs je compte mettre tout les compilateurs dans un dossier sur GitHub (ça sera pour Linux x86-64 bits par contre) ^^'

Mes test pour les vrai machines sur PS2 via free MC boot , sur dreamcast et GC via un adapteur sur card SD , pour la Wii , elle a un port SD donc pas besoin de matos en plus (de même que pour la PSP , un simple câble suffit)

Attaquer un lib 3D sur autant de consoles en même temps c'est peu crazy  

Totalement , mais d'un coté je pense que cela aurait du être fait depuis des années , le souci c'est que c'est assez rare ceux qui ont des connaissances bas niveau , assembleur et de la 3D , donc je me colle a cette tache :)

[Orion_]

le problème d'une lib 3D multiplateforme, surtout sur des anciennes plateformes, c'est qu'elles ont des hardware tellement spécifique que c'est difficile de trouver un dénominateur commun pour que la lib tourne bien sur toute.
En tout cas, je suis admiratif, surtout concernant la PS1, j'ai toujours été une bille en 3D surtout dès qu'on attaque le clipping Z négatif et les virgules fixes, pourtant je rêve de pouvoir faire un jeu 3D, et j’espère pouvoir enfin comprendre le mystère des commandes GTE de ma console favorite un jour
tes sources me seront d'un grand secours ! quand j'aurais le courage de m'y mettre ...
(en attendant je fait mumuse avec Yeti 3D sur Dreamcast)

[Invité]

Effectivement , du coup même si ma lib était unifié sur les grande lignes , la version PS1 n'est pas à 100% compatible avec une version PS2/DC/PC ou Wii.
Le dénominateur commun , c'est simple , c'est l'affichage d'un model 3D
Mais vraiment c'est cela , vu que je gérais le loader et le rendu de A à Z , ça me permettais d'optimiser pour chaque plateforme cible :p
Je ne l'ai pas détaillais mais ma lib permet de convertir a la volé les textures (si vous charger un png sur une console sony , je la convertirais si possible en RGB 16 bits ou on 8 bits avec palette) , elle convertit aussi a la volée aussi les vertex pour les model3D (par exempel sur PS2 , elle aime bien les nombre fixe pour les transfert et la DC gère un peu les float16 bits).
Bien sur si tu veux faire une API 'bas niveau' comme OpenGL, tu aura de gros souci de perf , d'ailleurs vouloir porter OpenGL est une idée stupide la Dreamcast et la PS2 sont trop exotique pour OpenGL , a la limite la seule console qui prend bien OpenGL sans trop de perte de perf c'est la GC/Wii.

Si le code source te sert , tant mieux , c'est le but aussi de cette lib , éviter de réinventer la roue pour les autres (sauf pour moi ) , si je devais dire ce qui reste à faire sur la PS1  :
-une fonction LookAt et des fonctions de caméra plus avancé (comme ViewSub et ViewObj)
-optimiser le bouzin
-l'animation par keyframe et/ou par animation par squelette
-tester sur une vrai machine
Ensuite t'aurais une version utilisable pour la 3D ^^'
On plus j'avais fait une super gestion de la vram , on peut mettre 16 texture de 128x256 + gui + Background pre-calculer, on gros faire un FF ou un RE c'est largement possible xD

Connaissait pas Yeti3D , mais je pense que ma lib est la plus optimisé en homebrew actuellement sur DC (et PS2 aussi lol) , je pense tenter d'avoir un truc 'utilisable' parce que a la base je voulais faire un super jeux 3D

D'ailleurs en terme de code ça ressemble a ça :

Code:


#include <stdio.h>
#include <stdlib.h>

#include "LMP3D/LMP3D.h"

void game(LMP3D_Buffer *buffer)
{
 LMP3D_TAR tar;

 LMP3D_Event event;
 LMP3D_Camera camera;
 camera = LMP3D_Camera_Init();

 LMP3D_Event_Init(&event);
 LMP3D_Model *model;

 unsigned int vram = LMP3D_VRAM_Get();

 LMP3D_Tar(&tar,"DATA","zack.bcm",LMP3D_TAR_OFFSET,NULL,0);

 model = LMP3D_Load_Model("DATA",tar.offset,NULL,0);


 int i,number = 1,tmpx,tmpy;


 //un calcul pour que le model soit toujours au centre
 float mid = model->Ymax/2;
 mid = mid*model->scale.x;
 model->position = LMP3D_Type_Vector3(0,-mid,-400);
 Vector3 position = model->position;
 position.y = 0;

 int mode = 0;
 while(event.exit == 0)
        {
     //model->rotate.y += 0.01;
 LMP3D_Event_Update(&event);

 camera.key[0] = event.key[Button_Left];
 camera.key[1] = event.key[Button_Right];
 camera.key[2] = event.key[Button_Down];
 camera.key[3] = event.key[Button_Up];

 camera.key[4] = event.key[Button_A];
 camera.key[5] = event.key[Button_B];

 if(event.key[Button_Start] == LMP3D_KEY_DOWN)
 {
 printf("ok\n");
 mode = !mode;
 }

 //camera
 if(mode == 0)
 LMP3D_Camera_ViewSub(&camera);
 else
 LMP3D_Camera_ViewObj(&camera,&position);

 if(event.key[Button_R2] == LMP3D_KEY_DOWN) number +=10;
 if(event.key[Button_L2] == LMP3D_KEY_DOWN) number -=10;
 if(event.key[Button_R1] == LMP3D_KEY_DOWN) number++;
 if(event.key[Button_L1] == LMP3D_KEY_DOWN) number--;

 LMP3D_Camera_Perspective(camera);

 LMP3D_Clear();

 for(i = 0;i < number;i++)
 {
 tmpx = (i&0x7)<<5;
 tmpy = (i&0xF8)<<4;

 model->position.x = tmpx;
 model->position.y = tmpy-100;
 model->position.z = -400;

 LMP3D_Model_Draw(model);
 }

 //obligatoire pour la DC , permet d'afficher de la 2D
 LMP3D_Camera_Ortho2D();
 
 LMP3D_FlipBuffer(buffer);
 LMP3D_VBlank();

 }

 LMP3D_VRAM_Set(vram);
}


[Stef]

Beau travail Kannagi !! Ca doit être sacrément compliqué de faire une API compatible pour toute ces machines ! Je te conseille effectivement d'oublier la Saturn et la N64 ^^
J'avais une question concernant la manière dont tu fais les calculs sur les différentes machine (je connais un peu le hardware de la DC et de la PS2). La PS2 est assez complexe à programmer, du coup tu dis que tu as fait tes propres routines, ça signifie que tu as écrit ton propre code pour les VU0 / VU1 ? Si c'est le cas chapeau, c'est un sacré travail ! Pour la DC idem, j'imagine que tu utilises l'unité vectorielles du SH-4 pour les calculs 3D vu les chiffres que tu obtiens :)
J'aime beaucoup le hardware de la Dreamcast, il est "très propre" en comparaison de celui de la PS2 (qui me fait un peu penser à la Saturn sur certains aspects :p) et son GPU était très avancé pour l'époque (compression de texture, rendu 32 bits interne, modifier volume etc..) avec un excellent rendu.

J'ai un peu codé sur Dreamcast il y a quelques années mais à l'inverse de toi, j'ai voulu revenir sur des choses plus simplistes on va dire ^^

[Invité]

Merci beaucoup, ben oui complexe et assez chiant sur pas mal de point de gérer autant de machine:D
Pour la N64 elle me semble pas complexe , si l'affichage 3D est pas exotique eu qu'elle travaille avec des matrices 4x4 en float , ça me va ^^
C'est surtout la PS1/saturn qu'il leur faudrait une lib spécifique (mais je pense qu'on peut mettre pas mal de chose en commun)

Ah ben la PS2 sans VU , je crois que tu peux esperer que 10-15 k triangles max xD
Donc oui j'ai écrit mon propre code du VU ,  et ça m'a pris énormément de temps pour l'utiliser , j'ai du écrire je ne sais combien de version pour l’optimiser ! :/
Si tu veux voir a quoi ça ressemble : https://github.com/Kannagi/LMP3D/blob/master/VU/vu1Triangle.vcm
Après le VU pour être bien utiliser dépend aussi de comment tu communique avec lui notamment pour réduire les transferts (en gros faire des transferts parallèle a exécution du VU).
Ah oui , je n'utilise que le VU1 et encore le code peut encore être améliorer , imagine donc les perf max de la PS2

Pour la DC oui j'utilise les instructions vectoriels , mais elle est un peu 'faiblard' niveau instruction 3D :p
https://github.com/Kannagi/LMP3D/blob/master/LMP3D/DC/Graphics/DC_DrawModel.c
D'ailleurs j'ai vraiment plus aucune optimisation a faire cote calcul 3D , si on exclut l'animation par squelette (j'ai du bosser dessus 1 ou 2 semaine a fond).
Je pourrais expliquer cette dif de perf entre DC et la PS2 en détails , mais les explications serait un peu complexe , disons que Sony a résolu le soucis des processeurs moderne , en offrant en contrepartie une complexité a utiliser le cpu (mais la PS3 c'est le même topo hein ! ).
Mais oui l'avantage de la DC c'est d'avoir un rendu 3D assez agréable a regarder , gérer des texture 512x512 et une plus grande VRAM pour les textures et une meilleur compression (VQ Compressed).

La PS2 est concentré sur le nombre de poly , elle gère principalement des textures 256x256 avec palette un vram trop petite , et le rendu est un peu 'saccadé' mais ça peut être atténué (dans certain jeux cela se voit moins).

Niveau hard , je trouve pas forcément la PS2 plus complexe que la DC , le plus complexe c'est quand on veut faire de la 3D (donc utiliser le VU0 et VU1) , la oui ça devient d'une complexité sans nom ! xD
Je dirais même que la PS2 est assez classique sur son fonctionnement , la DC possède un buffer de vertex , c'est vraiment pas courant comme technique de rendu 3D ! (mais ça permet justement d'avoir le rendu en parallèle a l’exécution).

Disons que pour les consoles 8/16 bits j'ai fait le tour (Nes,SNES,Master Sytem,Mega Drive, Neo Geo , Taito F3, PC engine) , sur SNES je l'ai bien exploité pas mal de perso affichable a l'écran , palette exploité , transparence , mode 7 , grosse map etc etc
Mais je compte finir un jour mon driver sonore tout de même

[Invité]

Coucou Kannagi,

Comme toujours tu gères.
Dire qu'on trouve la SNES chiante à programmer, et toi tu t'attaques aux monts himalayens des machines rétros. 
Qu'en est il de ton RPG sur SNES au fait ?
Sinon bon courage en espérant que tes Libs serviront pour de futures Prod' Homebrew.

[Stef]

Merci beaucoup, ben oui complexe et assez chiant sur pas mal de point de gérer autant de machine:D
Pour la N64 elle me semble pas complexe , si l'affichage 3D est pas exotique eu qu'elle travaille avec des matrices 4x4 en float , ça me va ^^
C'est surtout la PS1/saturn qu'il leur faudrait une lib spécifique (mais je pense qu'on peut mettre pas mal de chose en commun)

Ah ben la PS2 sans VU , je crois que tu peux esperer que 10-15 k triangles max xD
Donc oui j'ai écrit mon propre code du VU ,  et ça m'a pris énormément de temps pour l'utiliser , j'ai du écrire je ne sais combien de version pour l’optimiser ! :/
Si tu veux voir a quoi ça ressemble : https://github.com/Kannagi/LMP3D/blob/master/VU/vu1Triangle.vcm
Après le VU pour être bien utiliser dépend aussi de comment tu communique avec lui notamment pour réduire les transferts (en gros faire des transferts parallèle a exécution du VU).
Ah oui , je n'utilise que le VU1 et encore le code peut encore être améliorer , imagine donc les perf max de la PS2

Pour la DC oui j'utilise les instructions vectoriels , mais elle est un peu 'faiblard' niveau instruction 3D :p
https://github.com/Kannagi/LMP3D/blob/master/LMP3D/DC/Graphics/DC_DrawModel.c
D'ailleurs j'ai vraiment plus aucune optimisation a faire cote calcul 3D , si on exclut l'animation par squelette (j'ai du bosser dessus 1 ou 2 semaine a fond).
Je pourrais expliquer cette dif de perf entre DC et la PS2 en détails , mais les explications serait un peu complexe , disons que Sony a résolu le soucis des processeurs moderne , en offrant en contrepartie une complexité a utiliser le cpu (mais la PS3 c'est le même topo hein ! ).
Mais oui l'avantage de la DC c'est d'avoir un rendu 3D assez agréable a regarder , gérer des texture 512x512 et une plus grande VRAM pour les textures et une meilleur compression (VQ Compressed).

La PS2 est concentré sur le nombre de poly , elle gère principalement des textures 256x256 avec palette un vram trop petite , et le rendu est un peu 'saccadé' mais ça peut être atténué (dans certain jeux cela se voit moins).

Niveau hard , je trouve pas forcément la PS2 plus complexe que la DC , le plus complexe c'est quand on veut faire de la 3D (donc utiliser le VU0 et VU1) , la oui ça devient d'une complexité sans nom ! xD
Je dirais même que la PS2 est assez classique sur son fonctionnement , la DC possède un buffer de vertex , c'est vraiment pas courant comme technique de rendu 3D ! (mais ça permet justement d'avoir le rendu en parallèle a l’exécution).

Disons que pour les consoles 8/16 bits j'ai fait le tour (Nes,SNES,Master Sytem,Mega Drive, Neo Geo , Taito F3, PC engine) , sur SNES je l'ai bien exploité pas mal de perso affichable a l'écran , palette exploité , transparence , mode 7 , grosse map etc etc
Mais je compte finir un jour mon driver sonore tout de même

Quand tu cumules V01 et VU1 tu peux effectivement obtenir des perfs impressionnantes mais de mémoire les 2 VUs n'ont pas les mêmes capacités donc tu ne peux pas tout faire avec (VU0 est plus limité je crois). Comme tu dis le plus complexe est la maximisation de l'utilisation des différentes unités en parallèle, enfin perso j'ai pas codé sur cette machine mais j'ai fait un mémoire sur son architecture pendant mes études, je l'avais donc bien décortiquée ^^ A côté de ça la dreamcast m'avait semblé bien plus classique et facile à appréhender. Et au contraire j'avais été assez surpris des performances de l'unité vecteur du SH-4 (qui fait partie intégrante du chip), bien sur elle est bien moins puissante que les VUS de la PS2 (surtout en terme d'instruction si c'est ça que tu voulais dire ^^) mais je trouve qu'en parallélisant bien le code et en jouant habilement avec le cache tu pouvais quand même faire pas mal (j'avais fait des benchmarks où j'étais pas loin de 6 millions de triangles transformés par seconde il me semble).

Sinon pour moi le buffer de vertex n'était pas très surprenant, beaucoup de carte vidéo fonctionnaient ainsi à l'époque (en tout cas j'avais cette impression ^^), et le système de rendu du PVR le nécessitait de toute manière (tile rendering).

Je me demande comment tu fais pour aller si vite pour "parcourir" les différentes machines, je trouve que ça prend énormément de temps pour être familier d'un système (plusieurs années perso), en plus j'ai tendance à bien creuser quand une machine me plait :p

[Invité]

@StudioVetea
Merci de ton soutiens !
La SNES est en pause , le RPG était quand même bien entamer (en terme de fonctionnalité) faudrait en faite que je finisse le driver audio , pour que je puisse enfin terminer ce foutu RPG :p


@Stef
C'est bien tu as bien compris la PS2 rien a rajouté , le VU0 n'est pas aussi puissant que la VU1 , mais si j’arrive a le faire en parallèle certain calcul , je peux peut être gagner 20-30% de perf , c'est pas négligeable (ça fait quand même 20-30k triangle ne plus ) ^^

en parallélisant bien le code et en jouant habilement avec le cache tu pouvais quand même faire pas mal (j'avais fait des benchmarks où j'étais pas loin de 6 millions de triangles transformés par seconde il me semble).

parallélisant , y'a rien a parallélisé sur le SH4 xD
Mais j’optimise deja la pipeline , et j'utilise au mieux les instructions superscalaire pour exécuter deux instruction en même temps
La mémoire cache pour les données sont deja optimisé , vu que mes données sont contigu , donc ça limite les caches miss.
Mais 6 millions de triangles par seconde sur DC ? si c'est sur un émulateur il faut faire gaffe, il émule ni la mémoire cache , ni la pipeline.
Actuellement je suis sur 2 millions et avec les tri strip ça doit monté à 3 millions...
Du coup je reste sceptique ,a 6 millions/seconde ça te fait 33 cycle par triangle dans le monde idéale sans cache miss !
La raison qui me laisse vraiment sceptique est que la division fait 18 cycle (et que t'arrive sur ces 18 cycles mettre tous les autre calcul de pespective 3D ce que tu appelle suremment 'en parallèle') , ben avec 3 vertex ça te fait 18*3 = 54 cycle par triangle ,
et même avec les index , ça serait pas possible , je suis actuellement à 40-50 cycle pour un index.
Et la je parle de chiffre théorique , surtout que le souci de cette division sur le SH4, c'est qu'elle ce pipeline très mal , vu qu'elle prend une grosse partie de la pipeline , du coup la plupart des autres instructions doivent attendre que la div se finissent ^^'
Pourtant j'ai du faire une cinquantaine de test sur ma dreamcast pour pipeline tout ça , et c'est le résultat que j'ai actuellement.

Pour "parcourir" les différentes machines ben je suis étonné que tu aurais ce souci ,j'y arrive rapidement parce que quand on fait du bas niveau on comprend facilement comment fonctionne les autres machines , et on comprend encore plus ces choses si on comprend aussi les contraintes qui ont permis de faire leur choix niveau architecture , après c'est de l'algo et une compréhension fine du matériel pour l'optimisation .
Mais après j'ai jamais dit que je connaissais a fond toutes ces machines , disons que en général, je me concentre principalement sur le rendu (2D ou 3D) , le reste je connais assez peu comment ça fonctionne dans les détails

[Invité]

Je comptais présentais ma lib quand j'aurais au moins une release stable , mais vu le temps que je met pour ça

J'avais bossé sur la SNES , mais disons que ma curiosité a pris le dessus pour ces machines plus 'récente' , et puis cela m'a permis de mieux comprendre comment fonctionne les processeurs moderne ^^
Donc le but de la lib  est d'avoir le même code (portabilité) et que ceci soit optimisé pour chaque plateforme , niveau chiffre ça donne ceci :
PS2 : 110 000 à 130 000 triangles/frame
Dreamcast : 30 000 triangles/frame
PS1 : 2000-3000 triangles (sur émulateur)
J'ai mis un "Backface culling" sur PS1 et DC mais pas sur PS2 (disons qu'elle fonctionne un peu différemment et c'est pas les bons triangles qui sont enlevé )

D'ailleurs je compte ne plus avancer la version PS1 , pour la bonne raison que la console est très chiante à programmer pour la 3D , (des matrices 3x3 , des nombres a virgule fixe , pas de Zbuffer etc etc).
Et donc consacrer mon temps sur des consoles plus intéressant comme la GC/Wii (si je les met ensemble c'est que la Wii a le même hardware que la GC mais en plus puissant :p ).

Pour la Saturn et la N64 je ne compte pas m'y atteler avant un moment , pour la Saturn parce que j'aurais les même soucis que la PS1 mais en pire
Et la N64 parce que ben il manque encore des outils pour que je code dessus , donc ça sera sûrement la PSP qui sera en ligne de mire
(Après ça marche aussi sur Windows et Linux , mais c'est pas forcément le plus compliqué ça )
Niveau code , c'est du C et de l'assembleur ,je trouve l'asm sur 8/16 bits gentillet a coter de ce genre de monstre surtout pour la PS2 , faire tout les calcul 3D en asm 128 bits et superscalaire , quel pied 

PS: ah oui comme je le vois souvent ici , Code::Block permet de lancer un émulateur aussi
Et bien sur le Github du projet : https://github.com/Kannagi/LMP3D

Wahou, le boulot de malade, chapeau mec, faire ça avec des machines 2D c'est déjà pas la joie, alors en 3D 
Par contre je n'aurai pas imaginé un tel écart de puissance entre la DC et la PS2 .

[Stef]

@Stef
C'est bien tu as bien compris la PS2 rien a rajouté , le VU0 n'est pas aussi puissant que la VU1 , mais si j’arrive a le faire en parallèle certain calcul , je peux peut être gagner 20-30% de perf , c'est pas négligeable (ça fait quand même 20-30k triangle ne plus ) ^^

Ce n'est pas négligeable en effet

en parallélisant bien le code et en jouant habilement avec le cache tu pouvais quand même faire pas mal (j'avais fait des benchmarks où j'étais pas loin de 6 millions de triangles transformés par seconde il me semble).

parallélisant , y'a rien a parallélisé sur le SH4 xD

Mais j’optimise deja la pipeline , et j'utilise au mieux les instructions superscalaire pour exécuter deux instruction en même temps

Quand je dis paralléliser, je parlais juste de l'architecture super scalaire du pipeline en effet :p Mais e mémoire il me semblait que le SH-4 pouvait executer une instruction ALU / transfert / FPU en // (soit 3 instructions en //) mais au final je me rends compte que c'est juste 2 instructions en // (mais avec beaucoup plus de flexibilité sur les groupes).
Enfin déjà le fait de pouvoir faire une multiplication d'une matrix[4,4] * vector[4] en une seule instruction (de mémoire elle prend 4 cycles ou un truc dans le genre) moi je trouvais ça dingue (sur MD ça me prend environ 500 cycles pour faire la même chose en précision bien moindre ^^). J'étais déjà fou avec les instructions MAC mais là on passait encore un cap :)

La mémoire cache pour les données sont deja optimisé , vu que mes données sont contigu , donc ça limite les caches miss.
Mais 6 millions de triangles par seconde sur DC ? si c'est sur un émulateur il faut faire gaffe, il émule ni la mémoire cache , ni la pipeline.
Actuellement je suis sur 2 millions et avec les tri strip ça doit monté à 3 millions...
Du coup je reste sceptique ,a 6 millions/seconde ça te fait 33 cycle par triangle dans le monde idéale sans cache miss !
La raison qui me laisse vraiment sceptique est que la division fait 18 cycle (et que t'arrive sur ces 18 cycles mettre tous les autre calcul de pespective 3D ce que tu appelle suremment 'en parallèle') , ben avec 3 vertex ça te fait 18*3 = 54 cycle par triangle ,
et même avec les index , ça serait pas possible , je suis actuellement à 40-50 cycle pour un index.

J'étais en strip, j'utilisais bien sur le simple précision et il me semble que la division ne faisait pas autant de cycles que ce que tu décris... 19 cycles ? c'est en single précision ça ?? ce me parait vraiment beaucoup  
Mais attention j'ai dit 6 millions de triangles mais c'était un peu un abus de langage dans le sens où c'était du triangle strip et donc le nombre de vertex était plus ou moins équivalent (comprendre donc ~6 millions de vertices transformés / secondes). Aussi il me semble que je pouvais diminuer le nombre de division en utilisant une multiplication par l'inverse (mais je crois que le gain était faible car 1div + 2 mul à la place de 2 div).
Je dis ça de mémoire mais je suis presque sur de ce chiffre (environ 6 millions de vertices transformés / seconde, mais seuls, sans rien à côté car c'était juste un benchmark ^^)... faudrait que je retrouve mon code.

Pour "parcourir" les différentes machines ben je suis étonné que tu aurais ce souci ,j'y arrive rapidement parce que quand on fait du bas niveau on comprend facilement comment fonctionne les autres machines , et on comprend encore plus ces choses si on comprend aussi les contraintes qui ont permis de faire leur choix niveau architecture , après c'est de l'algo et une compréhension fine du matériel pour l'optimisation .
Mais après j'ai jamais dit que je connaissais a fond toutes ces machines , disons que en général, je me concentre principalement sur le rendu (2D ou 3D) , le reste je connais assez peu comment ça fonctionne dans les détails

J'aime bien chercher les petites astuces sur chaque machine pour en sortir le meilleur, mais ça demande vraiment beaucoup de temps. La DC je l'ai juste effleuré, la MD je pense que je commence à la connaitre par contre

[Invité]

Quand je dis paralléliser, je parlais juste de l'architecture super scalaire du pipeline en effet :p Mais e mémoire il me semblait que le SH-4 pouvait executer une instruction ALU / transfert / FPU en // (soit 3 instructions en //) mais au final je me rends compte que c'est juste 2 instructions en // (mais avec beaucoup plus de flexibilité sur les groupes).
Enfin déjà le fait de pouvoir faire une multiplication d'une matrix[4,4] * vector[4] en une seule instruction (de mémoire elle prend 4 cycles ou un truc dans le genre) moi je trouvais ça dingue (sur MD ça me prend environ 500 cycles pour faire la même chose en précision bien moindre ^^). J'étais déjà fou avec les instructions MAC mais là on passait encore un cap :)

Oui je comprend , malheureusement c'est assez courant de nos jours et, toutes les consoles de cette gen ont des instruction SIMD , la PS2 permet aussi de faire une multiplication de matrice sur 4 cycles pour être précis elle n'a pas exactement ce genre d'instruction mais elle permet de faire une multiplication d'un vector (4x1) en un 1 cycle donc pour une 4x4 il faut le faire 4 fois (pour la GC et la Xbox leur CPU ne leur permet pas de faire cela sur 4 cycles, mais eux c'est le GPU qui fait ce genre de calcul).

Sinon non le SH4 n'est pas 'spécifique' niveau groupe , ni plus propre que les autres sur ce point la, il est comme tout les autres processeur moderne , tu ne peux pas faire 2 mul en même temps , mais logique il utilise la même pipeline  , donc tu peux faire un autre qui n'utilise pas la meme pipeline (comme le move ou un add ) et c'est le cas pour tout les processeurs , ARM, X86, MIPS Power PC etc etc

J'étais en strip, j'utilisais bien sur le simple précision et il me semble que la division ne faisait pas autant de cycles que ce que tu décris... 19 cycles ? c'est en single précision ça ?? ce me parait vraiment beaucoup  
Mais attention j'ai dit 6 millions de triangles mais c'était un peu un abus de langage dans le sens où c'était du triangle strip et donc le nombre de vertex était plus ou moins équivalent (comprendre donc ~6 millions de vertices transformés / secondes). Aussi il me semble que je pouvais diminuer le nombre de division en utilisant une multiplication par l'inverse (mais je crois que le gain était faible car 1div + 2 mul à la place de 2 div).
Je dis ça de mémoire mais je suis presque sur de ce chiffre (environ 6 millions de vertices transformés / seconde, mais seuls, sans rien à côté car c'était juste un benchmark ^^)... faudrait que je retrouve mon code.

Effectivement c'est en double  , en single c'est 14 cycle mais bon pas ouf non plus :p
Par contre en vertices ton calcul me semble plus correct donc tu as 2 millions de triangles en normal et 3M en strip donc ce que j'ai actuellement quoi , de plus c'est sur émulateur que tu avais testé ? Si c'est sur la DC réel c'est pas mal pour un premier test , la pipeline/superscalaire est pas évident a optimiser manuellement :)
Mais ton chiffre reste théorique parce que si tu fait juste les calculs , envoyer les données prend un peu plus de cycle !

@Touko Merci , oui c'est loin d’être évident
Étonnant au premier abord c'est vrai  , dans les détails ce n'est pas si étonnant ^^'

[Invité]

oui c'est loin d’être évident

en tout cas tes explications sont très intéressantes à lire   

Étonnant au premier abord c'est vrai  , dans les détails ce n'est pas si étonnant ^^'

Je me doutais que la PS2 était plus puissante, mais pas avec un tel écart .

[Invité]

Au fait Kannagi, je voulais te poser une question !

Dans ton premier message, tu parlais de Code::Blocks ( que j'utilise ) et de la possiblité de lancer un émulateur à l'issue de la compilation de ton code.
Pourrais tu me ( nous ) dire comment tu t'y prends ?
Merci !

[Stef]

Oui je comprend , malheureusement c'est assez courant de nos jours et, toutes les consoles de cette gen ont des instruction SIMD , la PS2 permet aussi de faire une multiplication de matrice sur 4 cycles pour être précis elle n'a pas exactement ce genre d'instruction mais elle permet de faire une multiplication d'un vector (4x1) en un 1 cycle donc pour une 4x4 il faut le faire 4 fois (pour la GC et la Xbox leur CPU ne leur permet pas de faire cela sur 4 cycles, mais eux c'est le GPU qui fait ce genre de calcul).

A l'époque je dirais pas que c'était si courant... le SIMD était quand même relativement nouveau, il a été introduit par le MMX sur les pentium MMX donc (x86), d'ailleurs à l'époque je codais surtout en assembleur sur x86. AMD l'avait introduit sur les flottants avec le 3DNow! mais on était encore à 2 instructions // (2x32 bits en une seule instruction). Là clairement cette unité vectorielle sur le SH-4 était quand même très performante comparé à ce qu'on trouvait du côté des x86 à la même époque (PII), le SSE est arrivé plus tard avec les P3... Aussi la Dreamcast sort en novembre 1998 quand la PS2 sort en mars 2000, ça fait 1 an et demi, c'est un écart important à prendre en compte.

Il est vrai qu'on avait déjà le T&L sur certaines cartes graphiques mais l'unité vectorielle du SH-4 était plus flexible. A 200Mhz le CPU te crachait 1.4 GFLops, c'etait quand même énorme pour cette époque.

Sinon non le SH4 n'est pas 'spécifique' niveau groupe , ni plus propre que les autres sur ce point la, il est comme tout les autres processeur moderne , tu ne peux pas faire 2 mul en même temps , mais logique il utilise la même pipeline  , donc tu peux faire un autre qui n'utilise pas la meme pipeline (comme le move ou un add ) et c'est le cas pour tout les processeurs , ARM, X86, MIPS Power PC etc etc

Oui mais justement, c'est pour ça que de mémoire et au début je pensais à ça : ALU / IO / FPU
alors qu'en fait ici il y a un peu plus de groupe que ça, car il n'y a pas que 3 unités en interne (c'est un peu plus découpé).

Dans le paragraphe 10 de cette doc :
https://www.st.com/content/ccc/resource/technical/document/user_manual/69/23/ed/be/9b/ed/44/da/CD00147165.pdf/files/CD00147165.pdf/jcr:content/translations/en.CD00147165.pdf
On voit que tu as 6 groupes d'instructions et certains groupes comme le groupe MT (comparaison) peuvent être executés en // (donc il doit y avoir 2 unités internes pour ce groupe), à l'inverse les groupes FE et CO sont inter-dépendants. Enfin bref, c'est juste qu'il y a une granularité un peu plus fine dans le découpage que sur un Pentium par exemple (où en gros tu avais juste 3 groupes : ALU / IO / FPU).

Effectivement c'est en double  , en single c'est 14 cycle mais bon pas ouf non plus :p

J'ai vu 10 cycles en single précision dans la doc pointée plus haut, peut être tu parles de la latence complète de l'instruction ? Enfin ça reste assez lent quand même, c'est pour ça qu'on essai toujours de les éviter ^^

Par contre en vertices ton calcul me semble plus correct donc tu as 2 millions de triangles en normal et 3M en strip donc ce que j'ai actuellement quoi , de plus c'est sur émulateur que tu avais testé ? Si c'est sur la DC réel c'est pas mal pour un premier test , la pipeline/superscalaire est pas évident a optimiser manuellement :)
Mais ton chiffre reste théorique parce que si tu fait juste les calculs , envoyer les données prend un peu plus de cycle !

C'était sur une DC mais il me semble que NullDC me donnait des résultats assez proche de mémoire (un peu plus haut du fait de la mauvaise  / non gestion du cache miss). Tu dis 3M de triangles en strip ?! avec 6M de vertex, tu peux avoir ~6M de triangles en strip, enfin bien sur tout dépend comment tu designes ton objet mais on est pas forcément à la moitié.

Je me doutais que la PS2 était plus puissante, mais pas avec un tel écart .

La PS2 était vraiment taillée pour te sortir de gros chiffres :p
Je dirais qu'en puissance géométrique / FPU elle état vraiment costaud avec ses VU mais c'était très compliqué à exploiter l'ensemble au max. A côté de ça, son CPU central n'était pas particulièrement balaise (un peu plus que celui de la Dreamcast mais pas beaucoup).
Aussi son GPU était lui aussi taillé pour cracher du pixel, avec un BUS interne de 512 bits tu pouvais débiter 16 pixels par cycle si mes souvenirs sont bons (dans le cas idéal)... le fill rate s'effondrait quand tu avais beaucoup de petits polygones (ce qui fut de plus en plus le cas quand les devs ont commencé à bien gérer la géométrie via les VU). Mais à côté de ça son GPU était relativement simple pour l'époque, avec seulement 4 Mo VRAM (vu le BUS 512 interne on peut comprendre que ça devait être onéreux) et sans compression de texture (juste du mode palette) ce qui accentuait encore le problème :-/ En plus la bande passante VRAM <--> RAM n'était pas phénoménale donc c'était pas non plus très facile de streamer les textures à la volée...
Au finale pour moi l'architecture de cette machine était un peu bancale (c'était d'ailleurs la conclusion de mon mémoire ), très orientée  pour le marketing et sortir de gros chiffres mais qui en pratique ne le montrait pas forcément.
D'ailleurs pour moi la PS2 a toujours eu un rendu un peu terne et en retrait des autres machines de l'époque. Autant effectivement elle pouvait cracher pas mal de polygones et elle aura tenue le coup face à la XBox et la GC sur ce point, autant son rendu final était souvent assez moche à cause de la qualité des textures et de l'utilisation d'une basse resolution (entrelacée) pour grapiller un peu de VRAM.

[Invité]

D'ailleurs pour moi la PS2 a toujours eu un rendu un peu terne et en retrait des autres machines de l'époque. Autant effectivement elle pouvait cracher pas mal de polygones et elle aura tenue le coup face à la XBox et la GC sur ce point, autant son rendu final était souvent assez moche à cause de la qualité des textures et de l'utilisation d'une basse resolution (entrelacée) pour grapiller un peu de VRAM.

Sur ça effectivement, j'ai toujours trouvé le rendu de la PS2 granuleux et sale visuellement .

[Stef]

Au fait Kannagi, je voulais te poser une question !

Dans ton premier message, tu parlais de Code::Blocks ( que j'utilise ) et de la possiblité de lancer un émulateur à l'issue de la compilation de ton code.
Pourrais tu me ( nous ) dire comment tu t'y prends ?
Merci !

Ca je peux te répondre, moi perso j'utilise les "tools+" :
http://wiki.codeblocks.org/index.php/Tools%2B_reference

Ca te permet d'appeler un outil (un émulateur) depuis code::blocks... c'est pas directement intégré dans la compilation mais c'est rapide quand même. Dans mon cas j'ai même fait un petit batch pour bien lancer la ROM depuis out/rom.bin comme il faut.

[Invité]

@Stef : Merci !!

[drludos]

Woaw, hyper impressionné par ta lib Kannagi!

Comme le dit Vétéa, on est plusieurs à galérer déjà à arriver à faire des petits jeux sur MD/SNES/GB..., toi tu fait carrément une lib multiplateformes pour des consoles bien plus complexes, ça fait rêver !

Il me tarde de voir un jeu (ou démo de jeu) tourner avec ta lib :) !

[Invité]

Oui tu as bien résumé Stef

Par contre je ne suis pas d'accord avec ça :

Au finale pour moi l'architecture de cette machine était un peu bancale (c'était d'ailleurs la conclusion de mon mémoire ), très orientée  pour le marketing et sortir de gros chiffres mais qui en pratique ne le montrait pas forcément.

Ils ont pas fait 2 VU pour le marketing lol, pour moi Sony a réussir a résoudre le souci des processeurs moderne (et de la latence du a la mémoire RAM ) , seul la PS2 et la PS3 ont réussi a résoudre ces probleme :)
C'est les seules consoles qui arrive a réussir l'exploit du 1 cycle/instructions , c'est assez rare pour le noter

Sinon oui le gros souci de la PS2 est son rendu 3D , très basique , alors que la plupart faisait de leur mieux pour rendre un rendu 3D assez beau (et puis la PS2 était limité a 256x256 niveau texture ça limité pas mal).
Les autres machines faisait souvent du 512x512 :)

Pour Vetea , il y'a dans code block , Project-> Set program arguments
ensuite tu met ta command alors je connais malheureusement pas les commandes sur Windows , mais je ferais un "& gens rom.bin" si je devais le faire pour la MD
(Normalement c'est pour mettre des arguments sur les programmes , mais tu peux faire exécuter un programme en même temps , genre un émulateur).

@drludos
Merci , content que la démo est impressionnant , j'espere faire plus dans l'avenir ^^
Moi aussi j'ai hâte de faire mon survival horror (genre un parasite eve 3) sur DC/PS2/GC

[Invité]

Merci Kannagi, j'ai crée un sujet concernant ce truc pour éviter de polluer ton topic.
EDIT : Trouvé. 

[Stef]

:

Au finale pour moi l'architecture de cette machine était un peu bancale (c'était d'ailleurs la conclusion de mon mémoire ), très orientée  pour le marketing et sortir de gros chiffres mais qui en pratique ne le montrait pas forcément.

Ils ont pas fait 2 VU pour le marketing lol, pour moi Sony a réussir a résoudre le souci des processeurs moderne (et de la latence du a la mémoire RAM ) , seul la PS2 et la PS3 ont réussi a résoudre ces probleme :)
C'est les seules consoles qui arrive a réussir l'exploit du 1 cycle/instructions , c'est assez rare pour le noter

J'ai du mal à comprendre pourquoi tu penses ça
Beaucoup de machine avant ont déjà fait ça, le tout est d'utiliser efficacement le cache.
Après peut être que sur les VUs toutes les instructions font 1 cycle, mais bon même ça tu avais déjà des DSP spécialisés (ce que sont les VUs) qui le faisaient déjà (je me demande si c'est pas le cas du SCU DSP de la Saturn ^^)

Enfin bon je ne veux pas pourrir ton topic avec des détails techniques dont 95% des gens se fichent ^^
En tout cas je pense que ta lib sera super utile, pouvoir faire un moteur 3D en utilisant le même code sur ces machines c'est quand même extra !