Warp3D Radeon.

15 sujets de 61 à 75 (sur un total de 82)

  • crisot

      #41556

      Il parle d’assembleur, pas de C, meme si il a mi du code C pour la compréhension.

      Evidement que le compilo converti la multiplication en décalage.

      MAIS, contrairement à ce qui est écrit, une VRAI multiplication n’est PAS aussi rapide qu’un décalage car la multiplication du powerPC prend beaucoup plus d’un cycle.

      mullw rD,rA,rB

      est beaucoup plus lent que

      rotlwi rD, rA, 8

      C’est de ça dont Krabob parle à la base.

      Yomgui

        #41557

        @crisot:

        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 X-D

        Nicholas

          #41558

          Yomgui a écrit :

          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.


          @Yomgui
          : T’en qu’on est dans les compilos: Tu conseillerai quoi comme arguements pour nos gcc 2.95.3 pour générer du code PPC ‘correct’ pour G3, G4 et evéntuellement 604e ?

          Bye

          corto

            #41559

            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 !

            corto

              #41560

              Pour infos, VBCC génère du code PPC identique, même compilé sans optimisation, pour a<<=8 ou a*=256, à savoir : slwi r14,r14,8

              crisot

                #41561

                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é ;-)

                M_o_Illusion

                  #41562

                  Et un mmorpg ?

                  […….]

                  enfin un shoot spacial par exemple ? un Elite like ?

                  […………………]

                  /me retourne se coucher ^^

                  lugduweb

                    #41563

                    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 :D (ceci étant si il y a moyen d’avoir un exe MOS je ne t’en voudrait pas crisot ;) )

                    crisot

                      #41564

                      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à ! )

                      Yomgui

                        #41565

                        @Yomgui: T’en qu’on est dans les compilos: Tu conseillerai quoi comme arguements pour nos gcc 2.95.3 pour générer du code PPC ‘correct’ pour G3, G4 et evéntuellement 604e ?

                        -mcpu=750

                        tout le pb étant la notion de ‘correct’ dont le débattement doit être très large suivant les personnes…

                        mais y a pas que cet argument là… entre les -fbidule et les -mmachine, plus les -Ox cela devrait le faire.

                        Faut tester… désolé, mais y a pas de solutions miracle!

                        sauf ça: http://www.poudreverte.com

                        henes

                          #41566

                          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é

                          Oui euh… non. Tu avais l’habitude d’en dire tellement de bien depuis des années que j’ai cherché à me le procurer.

                          Résultat, le framerate s’effondre à 5 FPS dès qu’il y a plusieurs attaques simultanées. Et puisque cela se produit toutes les 30 secondes, cela détruit tout.

                          Alors désolé, mais ce jeu est un désastre et c’est bien triste car il avait l’air effectivement vraiment bien sympa à première vue.

                          crisot

                            #41567

                            Henes: il y a un espece de bugg dans le moteur qui fait que le framerate s’éffondre effectivement à un truc comme 5 fps pendant 2 à 3 secondes. Bugg ? En tout cas ce n’est pas lié à la quantité de polygon à l’écran puisque ça peut se produire meme quand y’a “rien”. (c’est le cas chez moi en tout cas: D’ailleur un passage de 50 à 5 fps avec le double buffer qui part en couille et le traçage sur le buffer affiché, moi j’apelle ça un bugg).

                            J’ai ce jeu depuis sa sortie, j’y ai joué 60 heures, j’ai vu le bugg pas plus de 10 fois. Soit 3 secondes toutes les 6 heures.

                            Tu exagères tout de meme… Sèrieux on peut jouer des soirées entières sans jamais voir ce ralentissement.

                            WipeOut Fusion, c’est du 50 fps constant, 10 vaisseaux à l’écran, 5 attaques en meme temps, et c’est une pure bombe vidéo ludique avec un grand A++. Navré

                            henes

                              #41568

                              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 :-D

                              Avec toutes ces portes de sortie, avoue que je suis gentil ;-)

                              crisot

                                #41569

                                Non, en ce cas c’est toi le menteur: Le ralentissement, c’est 4 fois par 50 heures de jeu, pas 4 fois par tour de piste… J’en ai plein le cul de toi et de tes manières de faire passer les autres pour des cons et de faire le grand seigneur en les “laissant se rattraper”. Tu es en menteur, tu n’a jamais rien fait d’autre ni su faire de ta vie. Ta passion est de tenter d’humilier les gens en leur tapant dessus avec ta canne blanche. Tu as un problème, tu complexes mon grand, mais tu as besoin d’aides.

                                Je t’invite à venir jouer à WipeOut Fusion chez moi si cela est nécessaire pour te prouver à quel point tu te goures (mais tu le sais, vu que tu mens).

                                jah

                                  #41570

                                  peut etre il y a plusieurs versions du jeux ou plusieurs versions de

                                  la ps2 ou un 3eme joueur qui a un avis…

                                15 sujets de 61 à 75 (sur un total de 82)

                                • Vous devez être connecté pour répondre à ce sujet.

                                Forums AmigaOS, MorphOS et AROS Général Warp3D Radeon.

                                Amiga Impact