Warp3D Radeon.
-
Alors voila depuis l’update 3 j’ai un peu , tout petit, petit peu repris un poil le code de mon moteur 3D / lecteur VRML.
Vu que la Radeon marche je me suis amusé à faire un petit monde et a me promener dedant. Attention la routine de souris à été écrite en 14 secondes montre en main on ne rigole pas.
Donc voila un brouillon sur G3/800 + Radeon 7500.
http://crisot.free.fr/bordel/engine.avi (Divx 5.2.1)
Le verdict est asser impressionant puisque c’est au bas mot 2,5 fois plus rapide qu’une Voodoo 3 3000, en mono MTU! En utilisant toutes les MTU l’écart doit encore grandir, mais mon moteur ne gère pas encore.
La Radeon 7500 mange des textures 32 bits comme des petits pains et la sortie 32 bits n’a pas de ralentissements par rapport à la sortie 16 bits.
Maintenant je suis embeté, mon moteur, écrit 80% en C, fait ramer la Radeon…. J’avais pas prévu ça… Pauvre G3.
Félicitations…
ça à l’air prometteur
Ne blame pas le C parce que ton moteur rame du cul.
Il y en a plein d’autre en C, plus joli, et plus rapide au final ;-P
Ceci dis mes connaisanse en bidule 3D approche void,
T’aurai pas un binaire ‘system friendly’ qu’on test ca sous MorphOS ?
Tout ça est à moduler selon la nature de l’algo, le cpu utilisé, les capacités d’optimisation du compilateur.
C’est sûr que par exemple, sur un dsp, pour un programme de filtrage/convolution, avec un compilo C qui n’exploite pas les instructions d’additions et multiplication en //, tu vas obtenir un bien meilleur résultat à la main.
Cela dit, les compilos font des progrès dans ce sens. Et souvent, 95% du programme ne pourrait absolument pas profiter de ce genre d’optimisations bien spécifiques.
En revanche, il est tout à fait souhaitable que les bouts de code critiques soient codés en asm bien optimisé. Ce ne sont souvent que quelques morceaux bien isolés, si le programme est bien conçu, du moins.
Le ratio asm/c de rc5 en lignes, ça représente quoi tiens ?
Le ratio asm/c de rc5 en lignes, ça représente quoi tiens ?
100% / 0%
Entièrement de l’avis de Fab, le temps de l’assembler optimisable est quasiment totalement révolu.
Un compilateur digne de ce nom maîtrise bien plus de paramètres de l’architecture qu’un très très bon coder assembler.
D’ailleurs des tests ont été faits en ce sens et sauf cas particuliers, les perfs n’étaient pas meilleures en asm.
Pour avoir désassemblé le code de moteurs 3D comme mohaa (=quake3), on retrouve plutôt du code C.
D’ailleurs le code C n’est pas si loin de l’assembleur et si on connait bien le fonctionnement du compilo, on peut rajouter facilement des instructions de debugage ou petites optimisations. Après pour migrer un code mixte, ça promet d’être rigolo…
/me vas installer sous peu GCC4
Bon puisque ça part en couille et en hors sujet (a cause des meme: Ceux qui ne savent pas de quoi ils parlent, ici la 3D, pour dériver vers un débat ASM, sujet lui aussi non maitrisé par ces personnes), ça donne quoi les drivers 3D Radeon sous MorphOs ?
oups ………. j’ai dérapé.
(à défaut d’avoir sa vocation originale constructive, il aura sa vocation humoristique). Tiens au fait SAS à pas encore fait de signature en fonction de la mienne…
(S’il te plais mon Battounet tu me met ça en gueguerre que je tire quelques cartouches?
)T’aurai pas un binaire ‘system friendly’ qu’on test ca sous MorphOS ?
Je l’avais meme pas vu celle là !
Si si, bien sur, j’ai un binaire AmigaOs friendly qui prend des textures 32 bits (non supporté par ta Voodoo), qui output en 32 bits (non supporté par ta voodoo), compilé avec newlib (gnin gnin !)
- Vous devez être connecté pour répondre à ce sujet.
