Discussion :

[Dams333]

Bonjour!

Dans la cadre d'une application graphique qui affiche des grosses animations, je cherche à afficher un "gros" polygone (genre rectangle 1000x1000) texturé "proprement" (ie avec au moins du linear et de la correction de perspective), le tout sans carte 3D (donc purement au CPU)... et à mon grand étonnement je me suis rendu compte que cela n'était quasiment pas possible en temps réel, en tout cas pas dans des délais d'affichage corrects (= que l'on puisse faire autre chose à côté).

En effet après une journée de tests des différentes possibilités (Direct 3D, OpenGL, divers moteurs 3D open source...), j'en suis arrivé à la conclusion désabusée que -même avec un PC dernier cri- l'affichage d'un rectangle texturé de 1000x1000 en rotation sur un axe mettait le CPU à genou.

Il me semblait pourtant qu'il y a 10 ans de cela, quand les jeux 3D n'utilisaient pas exclusivement les cartes 3D, on arrivait à des résultats très honorables en software rendering, dans des résolutions plus basses certes, mais pas tant que ça.

Le but de mon post est donc double:

1. Peut-être ai-je mal cherché? Connaitriez-vous une bibliothèque graphique capable d'effectuer un tel rendu sans saturer le processeur? (je rappelle que j'ai besoin d'un rendu "propre" )

2. Qu'est-ce qui peut expliquer une telle limitation? Peut-être que le problème se situe au niveau des lectures/écritures mémoires qui n'ont pas tant progressé que cela en 10 ans?

Un grand merci par avance à tous vos avis ou réflexions sur le sujet

[loufoque]

Cherche un renderer logiciel rapide, tout simplement.
Les implémentations logicielles de OpenGL & co ne sont pas réputées pour être performantes.

[Laurent Gomila]

Aucun des moteurs / API que tu cites ne fait de rendu software, je ne sais pas comment tu t'es débrouillé pour tes tests.

Il existe par contre de vraies implémentations de renderer software très performantes ; je n'en ai pas en tête là mais tu devrais les trouver assez facilement. En tout cas, afficher un rectangle avec les CPU actuels c'est tout sauf lourd.

[unmanos]

Il me semblait pourtant qu'il y a 10 ans de cela, quand les jeux 3D n'utilisaient pas exclusivement les cartes 3D, on arrivait à des résultats très honorables en software rendering, dans des résolutions plus basses certes, mais pas tant que ça.

1. Peut-être ai-je mal cherché? Connaitriez-vous une bibliothèque graphique capable d'effectuer un tel rendu sans saturer le processeur? (je rappelle que j'ai besoin d'un rendu "propre" )

Le seul qui je connais c'est pixomatic de rad, mais c'est commercial (et je sais pas combien il coute). J'ai un ami qui l'a utiliser et il est clairement tres efficace (enfin bien sur infiniement moins que les cartes 3d).

2. Qu'est-ce qui peut expliquer une telle limitation? Peut-être que le problème se situe au niveau des lectures/écritures mémoires qui n'ont pas tant progressé que cela en 10 ans?

Je me rapelle que en 1996 on faisait pas de rendu propre
- pas de ZBuffer (on triait les polygones back to front).
- pas de filtrage sur les texture (bilinear ou autres).
- pas de correction de perspective sur les textures.
- textures palette en 256 couleurs avec les lookups de partout pour l'eclairage et les effets (genre une table de 256 par 16 pour calculer 16 niveaux d'eclairage sur une texture 256 couleurs).
- les routines de rasterization (clairement le bottleneck) etait faites 100% assembleur avec des psykopathes qui comptait les cycles pour chaque pixels.
- tout etait fait en fixed point.
- comme tu le dis on etait en mode en 320 par 240, soit 17 fois moins de pixel a remplir que en 1280 par 1024.

N'importe qui arravait avec un moteur 3D qui faisait de l'alpha ou avec un ZBuffer et tout le monde se prosternait devant lui ^^

Apres est arrive la 3DFX et petit a petit tout le monde est passe a autre chose.

Nostalgie...

[LeGreg]

En 1996 on avait enfin une accélération 3D qui était plus performante qu'un CPU pour le grand public (3DFX). Quant à la qualité elle était incomparable (correction de perspective, bilinear filtering). Mais bon. (c'était en 640x480 uniquement certes).

Pour ton problème de rendu software, c'est assez vague en fait. Si tu as utilisé le Reference rasterizer (vu que tu cites Direct3D) alors c'est normal. Refrast même s'il est très rapide pour ce qu'il fait (je connais des émulations soft plus lentes..) n'est pas optimisé pour la vitesse (je me souviens de quelques frames rendues en heures par frame).

On a cité Pixiomatic de Rad Tools en renderer software optimisé qui a l'inconvénient d'être limité à un niveau de features dx7.
Il y a aussi SwiftShader de Transgaming, qui lui offre des fonctionalités dx9 a une vitesse honorable (pour du rendu purement software).

Si tu as programmé ton software rasterizer toi-même il y a des chances pour qu'il soit moins optimisé que ces alternatives. De plus chaque nouveau niveau de feature ajoute de la complexité et réduit la vitesse (les renderers software de la belle époque étaient très simples et partiellement incorrects).

LeGreg

[Dams333]

Aucun des moteurs / API que tu cites ne fait de rendu software, je ne sais pas comment tu t'es débrouillé pour tes tests.

Direct3D certes, la sortie software n'existe qu'en debug, et de toutes façon est inutilisable. J'avais bêtement pensé que OpenGL était relativement optimisé en software, ce qui n'est pas le cas (en passant il est tout à fait possible de faire un rendu software en OpenGL, suffit de donner le bon PixelFormat).

Niveau moteurs, irrlicht par exemple se dit être très optimisé en software n'est pas si convainquant et de toutes façons ne gère pas d'option avancée sur la mapping (c'est horriblement moche^^).

Cherche un renderer logiciel rapide, tout simplement.

Voilà c'est l'objet de mon post

Je me rapelle que en 1996 on faisait pas de rendu propre

tu n'as pas tord même si je pense quand même que deux ans après on arrivait à des rendus software 640x480 relativement fluides et plus avancés (zbuffer, correction de persp...). Il faudrait que je retrouve des exemples mais ayant acheter une carte graphique sur le tard je me souviens clairement que beaucoup jeux tournaient correctement sans ça.

Il faut que je teste pixomatic et SwiftShader, même s'ils sont commerciaux. Je vous tiens au courant

Merci en tout cas!

edit: bon finalement ni pixomatic ni SwiftShader ne permettent de faire des tests intéressants sans achats ou inscriptions complète, pour finalement me retrouver avec un truc qui va pas me convenir. J'ai juste besoin d'afficher quelques gros polygones mappés, je pense pas avoir besoin d'un moteur qui émule tout direct 3D9 pour faire ça...

[Laurent Gomila]

en passant il est tout à fait possible de faire un rendu software en OpenGL, suffit de donner le bon PixelFormat

Si tu parles de faire du rendu en mémoire plutôt qu'à l'écran, ça ne change rien au reste du pipeline. Si par contre tu parles d'une option spécifique pour activer un rendu software (qui serait implémenté je ne sais où), tu peux développer

Sinon récemment j'ai vu passer une implémentation minimale d'OpenGL 1.1 en software nommée TinyGL ; cependant ça a l'air plus une bibliothèque pratique qu'un truc super performant.

[Dams333]

J'admet ne pas être un expert en OpenGL, j'ai juste suivi les instructions sur la page suivante:

http://www.opengl.org/resources/faq/.../mswindows.htm

(à partir de "To force software rendering from your application...")

Mais c'est possible qu'en effet ce ne soit plus en rendu en memoire systeme qu'un vrai rendu software...

[Mat.M]

2. Qu'est-ce qui peut expliquer une telle limitation? Peut-être que le problème se situe au niveau des lectures/écritures mémoires qui n'ont pas tant progressé que cela en 10 ans?

euhh 1000*1000 c'est 1000*1000 pixels ?
Les jeux d'avant ils tournaient souvent dans des résolutions plus petites en mode X ou en 400*300 quelque chose dans le genre.
Doom et Quake c'était de la pseudo 3d.

Le problème c'est qu'avec les OS actuels ils sont trop gourmands en ressources , le CPU est obligé de commuter sans arrêts entre les différentes taches lancées ( l'antivirus, les ma j autos ).
Sous ms-dos de jadis il n'y avait rien d'autre qui tournait en tâche de fond.
Essaye un rendu avec Linux en ligne de commande

[Dams333]

Oui 1 millions de pixels.

Il faudrait vérifier, mais il y a ~10 ans, il me semble bien que je jouais à des jeux genre Quake 3, GTA 2 ou Tomb Raider en 640x480 (=300000 pixels) sans carte 3D et c'était assez fluide, le tout sous Win95/98. Ça reste subjectif, mais si on prend la lois de Moore on devrait avoir des machines 100 fois plus puissantes aujourd'hui... [mouais, un dual core 2x3000 est-il 100 fois plus puissant qu'un Pentium 166? peut-être pas mais pas si loin...] En revanche je ne pense pas que la Ram d'aujourd'hui soit 100 fois plus rapide...

Pas faux pour l'OS. Faudrait essayer sous Linux, mais dans mon cas précis j'ai besoin d'une appli Windows...

[SoniX]

Je pense qu'il faut prendre plusieurs facteurs en compte qui risque fort de mettre à bas le *100 de monsieur Moor :

1 - les jeux dont tu parles utilisaient des moteurs 3D issues de nombreuses années de travaille sur l'optimisation de la rasterisation. Faire du rendu soft avec un programme 'neuf' fait maison en appliquant simplement les algos théoriques, c'est sans espoir (en terme de performance),
2 - le plus souvent, les textures utilisées étaient très petites,
3 - c'était très moche (par rapport aux standards actuels), je suis très branché 'rétrogamming', et j'ai souvent un choc violent lorsque je relance des vieux jeux 3D 'soft' (souvent, le choc est même plus brutal que sur les jeux 2D).

[shenron666]

Oui 1 millions de pixels.

Il faudrait vérifier, mais il y a ~10 ans, il me semble bien que je jouais à des jeux genre Quake 3, GTA 2 ou Tomb Raider en 640x480 (=300000 pixels) sans carte 3D et c'était assez fluide, le tout sous Win95/98.

pas en 640x480 mais en 320x200 256 couleurs
quelques jeux permettaient de monter la résolution sous dos en 640x480 mais on était pas à 15fps avec un Pentium90 (souvenir de magic carpet)
sous win95/98 il y avait de l'accélération 3D hardware (au moins la raterisation)

tomb raider n'utilisait pas de Z Buffer
GTA 2 était en 2D avec des batiments en 3D mais aucune rotation, pas de zbuffer non plus
quand à quake 3... en software ? le 2 je veux bien mais encore une fois pas de zbuffer en software et on jouait pas en 640x480, injouable

640x480 = 300 000 pixels sans zbuffer ni correction de perspective (ou imprécise) en 256 couleurs (8 bits)
1000x1000 = 1 000 000 pixels avec zbuffer + correction de perspective ? et 32 bits de couleurs ?


n'empêche que j'ai testé swiftshader et il est très performant
pas besoin de la version commerciale pour l'utiliser avec un programme DX9
afficher 1 seul polygone texturé en 1000 x 1000 en temps réel je ne vois pas de problème avec un bon cpu

au final, si tu veux afficher ce simple polygone avec ton propre renderer, il va faloir faire des concessoins mais c'est largement faisable, surtout si tu programmes multithreads avec un dual core ou +

[deadalnix]

pas en 640x480 mais en 320x200 256 couleurs
quelques jeux permettaient de monter la résolution sous dos en 640x480 mais on était pas à 15fps avec un Pentium90 (souvenir de magic carpet)

La même config donne de bons résultats sous tomb rider (en soft, 640x480). Magic carpet a des contraites plus dures que tomb rider cela dit.

sous win95/98 il y avait de l'accélération 3D hardware (au moins la raterisation)

Oui, mais très peu de gens étaient équipés.

GTA 2 était en 2D avec des batiments en 3D mais aucune rotation, pas de zbuffer non plus

C'est le cas de GTA premier du nom aussi Tournais bien en 640x480 sur une bon vieux pentium 90.

quand à quake 3... en software ? le 2 je veux bien mais encore une fois pas de zbuffer en software et on jouait pas en 640x480, injouable

Il n'est pas possible de jouer a quake 3 en software. Quake I existe en software et tourne encore une fois pas mal sur un pentium 90.

Bref c'est amplement faisable, faut juste dessiner en mémoire et pas avec des commandes de la SDL pour afficher des points.

[bafman]

quake 2 en software sur un core de processeur actuel et en resolution "correcte" (1280*1024 ou un truc du genre je ne me souvient plus) tourne a près de 2000 fps en mode time demo

donc c'est tout a fait faisable de faire du raster rapide sur les proc actuels

[DzzDDzzD]

Je me rapelle que en 1996 on faisait pas de rendu propre
- pas de ZBuffer (on triait les polygones back to front).
- pas de filtrage sur les texture (bilinear ou autres).
- pas de correction de perspective sur les textures.
- textures palette en 256 couleurs avec les lookups de partout pour l'eclairage et les effets (genre une table de 256 par 16 pour calculer 16 niveaux d'eclairage sur une texture 256 couleurs).
- les routines de rasterization (clairement le bottleneck) etait faites 100% assembleur avec des psykopathes qui comptait les cycles pour chaque pixels.
- tout etait fait en fixed point.
- comme tu le dis on etait en mode en 320 par 240, soit 17 fois moins de pixel a remplir que en 1280 par 1024.

N'importe qui arravait avec un moteur 3D qui faisait de l'alpha ou avec un ZBuffer et tout le monde se prosternait devant lui ^^

Apres est arrive la 3DFX et petit a petit tout le monde est passe a autre chose.

hehe ca je connais bien et effectivement apres la 3dfx je suis passé à autre chose et j'ai arreté (vers 1995), j'ai encore les sources de qq demos et d'un moteur 3D pas finit mais assez complet et ca compile toujours !! même sous un emulateur de dos (dosbox) ca fonctionne du feu de dieu, je vais de ce pas mettre tout ca en ligne y'a des partie en ASM interressantes.

quake 2 en software sur un core de processeur actuel et en resolution "correcte" (1280*1024 ou un truc du genre je ne me souvient plus) tourne a près de 2000 fps en mode time demo

heu y'a une erreur de typo la ? 2000 fps ? ca fait 2621440000 pixels à la secondes, soit un fillrate de 2GO/S ca fait un peu beaucoup, sans parler de la frequences de la RAM/BUS sur la carte mère ...

Dans la cadre d'une application graphique qui affiche des grosses animations, je cherche à afficher un "gros" polygone (genre rectangle 1000x1000) texturé "proprement" (ie avec au moins du linear et de la correction de perspective), le tout sans carte 3D (donc purement au CPU)... et à mon grand étonnement je me suis rendu compte que cela n'était quasiment pas possible en temps réel, en tout cas pas dans des délais d'affichage corrects (= que l'on puisse faire autre chose à côté).

tu entend quoi exactement par delais d'affichage correcte ?
combien de FPS avec quel CPU et quelle CG (même sans l'utiliser la CG est importante parceque le "blitting" vers l'ecran varie enormement, >10ms pour certaines CG) ? à priori ca me parait tout a fait faisable sur un config tres moyenne, le plus performant et leger serait de produire ton propre code, afficher un polygone qui tourne meme avec correction de perspective c'est pas aussi compliqué qu'il y parait, si besoin je peu te donner un coup de main au niveau des algos.

[bafman]

heu y'a une erreur de typo la ? 2000 fps ? ca fait 2621440000 pixels à la secondes, soit un fillrate de 2GO/S ca fait un peu beaucoup, sans parler de la frequences de la RAM/BUS sur la carte mère ...

non non, je confirme la valeur. le truc, c'est que le mode time demo de quake 2 fait faire un tour à la camera et calcule l'affichage dans un buffer mémoire sans l'envoyer à la carte graphique

[DzzDDzzD]

non non, je confirme la valeur. le truc, c'est que le mode time demo de quake 2 fait faire un tour à la camera et calcule l'affichage dans un buffer mémoire sans l'envoyer à la carte graphique

arf, dsl, je saisie pas tout , il affiche rien ou tout reste sur la carte graphique ?


NB: ca y'est j'ai uploader les sources dont je parlais plus hauts incluant mon premier moteur 3D tout en assembleur 80x86, certaines demos requierent un emulateur DOS car utilisation du mode protegé (DOSBox par exemple). didonc je redecouvre même certaine fonctions : comme la rotation 3D d'un tableau de points (".\ASM\3D\TABP3D.FNC" en entier ou en floatant avec le copro) qui pourraient peutetre encore me servire !

http://demo.dzzd.net/PROG.ZIP