Warp3D Radeon.
-
C’est de ça dont Krabob parle à la base.
non non, il parle bien de la convertion C -> instructions ASM.
Et il explique que 2 écritures différentes en C peuvent avoir la même écriture en ASM. C’est justement le rôle du compilateur de détecter cela.
Pour finir: mon cher Crisot, plutôt que de râler sur les compilos, pourrais-tu plutôt utiliser ton expérience dont tu fais ta fierté pour les améliorer? après tout GCC est OpenSource non?
Bon je sais qu’après tu ne pourrais plus avoir le plaisir de râler dessus… vu que tu en serras l’auteur
@tous:
à propos de la « vitesse » d’instruction sur un PPC:
il y a des mélanges, abus et autres qui trainent dans les posts:
– on peut très facilement quantifié la vitesse d’une instruction prise seule.
– on ne peut plus la déterminer facilement quand on la reprend au milieux d’autres instructions
Pour reprendre l’exemple de Crisot sur les instructions de multiplications et décalage (rotation):
1) les faits:
– la multiplication ce fait sur une unité de calcul d’entier donnée alors que celle de rotation ce fait sur une autre.
– la multiplication a une latence de 4 (où moin, où plus suivant le modele en faite). Alors que la rotation a une latence de 1.
2) le résultat:
La multiplication est à priorie plus lente que la rotation.
Sauf qu’elle ne se font pas sur les mêmes unitées.
Cela implique que dans un traitement de plusieurs instructions utilisant pas mal d’unités de calcul entier, il se peut que l’unité pour la rotation soit plus occupée que celle pour la rotation. Cela implique donc que le résultat de la rotation peut-être disponible avant celui de la rotation, dans une certaine configuration.
Mais bon en général la rotation va plus vite pour pas mal de configurations du flôt d’instructions.
C’est cela que sait un compilo, donc si il a le choix entre une multiplication ou bien une rotation/décalage, il choisira la deuxième solution.
Bien-sûr nos problème de calcul de vitesse ne font que commencer… car on a pas encore parler de la mémoire cache impliquant plus de complexité encore pour les instructions qui accéde à la mémoire (pour le cache de données), où a l’exécution du code (pour le cache d’instructions).
Donc on peut conclure qu’il est difficile d’optimiser son code à la main. Mais c’est faisable.
Par contre il faut d’un autre côté balancer le coté recherche de vitesse avec l’aspect temps de développement. Le premier peut vous faire explosé le second
Si l’on fait donc un rapport temps de dev/vitesse, l’optimisation du code à la main n’est pas forcement très bon.
Les compilo savent de plus en plus de choses à propos des CPU, mais c’est pas toujours évident car les constructeurs sortent pas mal de modèles, ce qui alourdis le travail de recherche d’optimisation pour les compilos. En régle général il vaut mieux lui limité les possibilitées avec par exemple des options comme -mcpu=xxx sous GCC.
Si vous lui dite -mcpu=ppc, vous risquez certainement de passer à côté des optimisations d’unités de calcul. Vu que le code doit satisfaire tous le monde
On aurait dû ouvrir un thread dédié à la compilation C et au code assembleur généré, à la comparaison avec de l’asm réalisé à la main, etc. Ca serait super intéressant en tout cas ! Autant que les remarques sur l’article de Krabob !
Quoiqu’il en soit, bien sûr, passer en asm de mauvais algos, c’est de la pseudo-optimisation. Mais je suis certain que Crisot ne tombe pas dans le piège du « je me jette sur l’asm sans penser aux algos ».
Après, je m’étonne qu’on accuse les compilos actuels de tant de faiblesses … Crisot : je veux bien des articles sur le sujet. Et comme je n’aime pas le travail inutile, peut-être que des choses pourraient être soumises à Frank Wille pour faire évoluer VBCC
A propos des compilos C, je ne suis pas sûr que ceux qui les utilisent au quotidien prennent la peine de regarder de près les options !
Ca me rappelle qu’un lien d’OSNews pointe sur un article d’IBM sur la récursivité. C’est un exemple de cas, où, quand on comprend comment ça marche dans le compilo, on doit pouvoir aménager son code C pour en bénéficier.
Quand à TinyGL, pas de problème sous OS4. Si ça n’a pas déjà été adapté, la version soft que j’avais porté sur Amiga et MorphOS compile également sous Linux … avec un GLUT SDL. Ce dernier a été écrit après une première tentative de portage sous OS4 mais … j’utilisais CGFX.
Voila : bravo à ceux qui se défoncent pour pondre des choses pour notre plateforme !
Tu dis quelques postes plus haut que tu ne sais pas ce que tu pourais faire de ton moteur 3D.
Cela me rappelle une ébauche de jeux à la wipeout que tu nous avais fait voir à l’equinoxe sur ton A4000. Ca m’avait vachement impréssionné et je n’ai jamais compri pourquoi un projet aussi prométeur et aussi avancé n’a jamais vu le jour ne serait ce qu’en petite démo jouable pour tater le terrain et voir si un projet plus ambitieux pourait être réalisable.
Est ce que le moteur 3D était à toi?
Est ce que les autres membres de l’équipe t’autoriseraient a faire quelque chose là dessus?
Tu parle de SXRally, la version qui avait été présentée à l’equinoxe avait été présentée par OneVision et la moteur était se Stan.
A la base ce projet avait été commencé à très peu de monde et c’était basé sur mon moteur de softrender, on avait fait un projet relativement sympa avec une mailing list et quelques personnes dessus pour papoter et faire le point.
J’ai claqué la porte du bordel le jour où la mailing s’est mise à trop grossir et surtout qu’on m’a mis trop d’autres codeurs sur le dos, en gros, et c’est la que Stan à très bien repris la chose à zero.
Et puis après avoir torché l’inimitable WipeOut Fusion dans tous les sens, je suis asser peu motivé pour parioder un tel chef d’oeuvre avec une création asmatique car je n’aurais ni le talent, et nos hardware ne sont pas asser puissants pour rivaliser. Donc le trip WipeOut m’est passé
Salut !
Tout d’abord félicitations à Crisot, voici un petit début de demo prometteur.
Sinon quand je vois ce qu’il y a dans l’avi, j’avoue que je suis moi aussi surpris que ca soit écrit en ASM car objectivement ca reste quand même assez basique (c’est pas une critique) ?
Tu parles de « moteur 3D » et en entrée tu dis que tu lis du VRML. Peut on en savoir un peu plus ?
Qu’est ce que tu gères / va gérer exactement (gouraud, phong, BRDF, ombres, éclairement évolué, collisions… ?). Est-ce que tu es parti from scratch ou bien a tu repris de l’existant avec des adaptations en ASM PPC.
Sinon pour ceux qui (comme moi) on un Pegasos/MorphOS, et bien la version MOS alpha vous l’avez : c’est l’avi
(ceci étant si il y a moyen d’avoir un exe MOS je ne t’en voudrait pas crisot )Le fait d’écrire un programme en ASM ne permet pas de faire un programme « moins basique » mais juste de le faire tourner plus vite. De plus dans le code de ce moteur y’a pas plus de 30% d’ASM (je suis devenu fénéant).
Actuellement ça lit des objets VRML 1 ascii j’ai galéré pour faire un lecteur potable sans auccune doc capable de lire les objets sans pleurer meme si l’ASCII est un peu niqué.
Pour le moment du VRML ça ne lit que les formes et les UV map, pour les lights sources le rendu de polygon le gère mais moi par contre je n’ai pas encore ajouté de lights à la main dans le monde.
Y’a du plane cutting et pour le moment mon objectif c’est de gérer des sous objets et surtout des Octrees afin de gérer des collisions et le clipping à moindre coup CPU. C’est la priorité sur la liste: Je veux pouvoir me promener dans mon monde!
C’est écrit 100% from scratch selon mon idéologie.
A savoir que j’ai fais tout ça sur une pèriode de 6 mois mais avec ma fleme, tout bout à bout doit représenter 2 semaines de code (dont 75% pour l’écriture des versions ASM des functions() sinon ça serait déjà beaucoup plus évolué que ça. )Actuellement je m’interdit l’assembleur d’ailleur mon but est maintenant juste d’évoluer vite, et de tout porter en ASM une fois la chose « finie ».
(mon dieu je viens de relire mon post, c’est totalement incompréhensible, je suis très fatigué là ! )
Si j’exagère, c’est peut-être en disant que ces énormes ralentissements détruisent le jeu. Car j’imagine que certaines personnes peuvent passer outre et supporter 2 secondes d’injouabilité absolue 4 fois par tour de piste. J’imagine que c’est ton cas. Tant mieux car cela te permet d’apprécier le tout.
Sinon, ton post mélange (volontairement ?) le bug d’affichage (que je n’ai pas vu mais je n’ai pas joué plus de 20 ou 30 minutes) et les fabuleux ralentissements intempestifs dont souffre Wipeout Fusion.
Ceux ci semblent se produirent chaque fois que le peloton est regroupé et que plusieurs vaisseaux utilisent leur attaque.
Je n’aurais jamais cru qu’il faudrait aussi se « battre » à propos d’un simple jeu vidéo… C’est incroyable
Si tu veux essayer de te rattraper (ou ne pas passer pour un menteur auprès des autres possesseurs du titre qui pourraient fréquenter AmigaImpact), je te tend une perche en disant que je n’ai joué que les deux premiers circuits. Comme cela, tu peux dire « ah mais c’est pour cela, moi je n’y joue jamais et les autres ne rament pas » si tu veux. Comme je n’irais jamais vérifier, je ne viendrais pas te contredire et ton honneur sera sauf :-p
Tu peux aussi dire que tu maîtrises tellement ce jeu que tu es toujours devant et que tu n’as donc aucun visuel sur les attaques lancées derrière toi. Ainsi, tu ne souffres pas de ces fameux ralentissements
Avec toutes ces portes de sortie, avoue que je suis gentil
- Vous devez être connecté pour répondre à ce sujet.
