🚀 go-pugleaf

> Ceci repr�sente un d�bit de :
> 1600*1200*4 *85 (Hz) = 652,8 Mo/s

OK d'accord. Bon, l�, d'accord. C'est totalement monstrueux. Urg. Crise
cardiaque. Je me couche, tiens.

Mais comment tu passes �a dans un r�seau ? A ma connaissance, ce genre de
d�bit n'est utilisable aujourd'hui qu'� l'int�rieur d'une puce 3D et au
travers de AGP (et encore, en super pleine forme).

> Les appels au GDI couvrent bien 80 Hz mais...........
> en 640x480 max  :
> 640*480*4*80 = 98,3.. Mo/s
> Soit la limite proche des cartes sur les ordi bouzeux ;-)

...soit tout de m�me plusieurs fois mieux que les meilleurs disques durs ou
r�seaux.

> Le Blit obsol�te avec DX8 : ce choix me surprend beaucoup.
> Microsoft privil�gie le pipe 3D � la 2D parce qu'il faut montrer
> des chiffres percutant pour les tests (....face � OpenGl ?!?).
...
> je pense que le blit est un outil tr�s utile
> car il d�charge, en asynchrone, la CPU du transfert m�moire.
> Si je monopolise tout le proc. pour capturer les �crans
> ceux sont les applis qui vont ramer...

Je sais pas, il y a quand m�me pas mal d'excellentes raisons. N'ayant jamais
personnellement eu massivement besoin des blits, je suis pas choqu�, mais je
dois admettre que �a remue dur chez les fanas de DX7, et m�me MS conseille
de rester en DX7 pour les applis 2D.

....
> Oui, mais en nonlocal les infos transitent aussi par le bus (le bus AGP).

La grosse diff�rence entre "le bus" et "le bus AGP" (c'est vrai que je ne
l'ai pas pr�cis� dans mon message), c'est que le bus AGP ne rentre pas en
conflit avec le bus du processeur. D'o� :
- la puce 3D a acc�s priv� � 500+ Mo/s sur la m�moire, sans faire chier ni
�tre emmerd�e. AGP est au d�part un simple acc�s DMA ayant un nom marketing.
En fait, le bus AGP dispose en plus de possibilit�s (si la puce 3D
l'impl�mente) pour faire mieux qu'un simple DMA, avec par exemple de la
transformation matricielle parall�le de coordonn�es par la puce 3D au
travers d'AGP, comme si elle faisait r�ellement partie de sa m�moire
embarqu�e. Je ne crois pas par contre que cela aille jusqu'� autoriser le
pointage du RAMDAC. Dans tous les cas, un bus AGP digne de ce nom est
capable de stocker des textures fonctionnellement de la m�me mani�re que la
m�moire embarqu�e, m�me s'il va en r�alit� nettement moins vite.
- le processeur n'est m�me pas pr�venu, donc il freine pas ce qu'il fait en
parall�le.
- le bus processeur est beaucoup plus lent que l'AGP (en th�orie, avec les
modes rafale et les m�moire r�centes, j'ai l'impression qu'il pourrait
taquiner l'AGP, mais le processeur est beaucoup plus g�n�raliste, et fait
souvent des acc�s courts et non cons�cutifs, qui cassent le d�bit, sans
parler des conflits)

La m�moire "System" est la m�moire centrale acc�d�e par le processeur (ou la
carte 3D) au travers du "bus" (du processeur), donc lentement et avec des
conflits, et la m�moire "Nonlocal" est la m�me m�moire centrale, mais
acc�d�e par la puce 3D au travers de son bus priv� AGP.

Pour ton application, comme tu dois traiter l'�cran une fois captur�, tu
devra y acc�der par le bus du processeur, donc une capture par ce bus se
r�v�lerait peu p�nalisante, sauf que bien s�r la capture serait un poil plus
instantan�e et plus indolore par AGP.

> Donc naturellement, j'ai essay� de 'blitter' de la surface primaire vers
une
> surface offscreen
> en m�moire syst�me. Mais voila cette op�ration n'est pas support� en
hardware
> par les cartes
> graphiques (que j'ai pu tester du moins). C'est la couche HEL (�mulation
donc)
> qui prend cette
> op�ration en charge. Et donc le processeur...
>
> D'ailleurs j'ai refais le test en faisant une copie avec CopyMemory() et
> memcpy().
> R�sultat : effectivement la vitesse est identique

Je me permet d'insister : capturer en m�moire "System" est par d�finition
utiliser le bus du processeur, et donc brider la puce 3D au niveau du bus du
processeur, il est donc normal d'avoir la bande passante du bus du
processeur, comme dans memcpy. Je pense que la d�nomination de m�moire
"System" utilis�e par DX est source de confusion : cela ne concerne pas son
emplacement, mais la mani�re d'y acc�der.


> (1) Je capture sur un poste :
> Mem video --> Bus AGP --> Mem centrale --> Reseau
>
> (2) Je restitue sur un autre poste :
> Reseau --> Mem Centrale --> Bus AGP --> Mem Video
>
> Voila, ce qui me surprend :
> C'est le fait que dans le cas (2) l'op�ration de copie s'effectue
> tr�s vite (ca r�pond aux performances d�sir�es)
> alors que dans le cas (1) c'est beaucoup plus lent.
> Pourtant, dans les deux cas on transite par le bus (d'ou ma question)

Peut-�tre que c'est le Lock qui rentre en conflit avec l'appli qui tourne
d�j�, et qui bloque ? As-tu bien pr�cis� DDLOCK_READONLY dans l'appel �
IDirectDrawSurface7::Lock ? Sinon, je comprends pas du tout, c'est pas
logique. Comment sont d�finies tes surfaces ? Tu pourrais peut-�tre poster
le code ? C'est peut-�tre carr�ment autre chose qui coince.


> Peut importe le format du moment que la compression ET la d�compression
sont
> effectu�es en hardware. (Et que le d�bit r�seau en soit diminu�)

Pour obtenir une texture compress�e, il faut copier (...blitter sous DX7) la
surface non compress�e (pour toi la surface primaire) vers une
IDirectDrawSurface7 (sous DX7) d�clar�e comme une texture (DDSCAPS_TEXTURE
dans DDSCAPS) et ayant DDPF_FOURCC lev� dans le dwFlags du DDPIXELFORMAT.
Fastoche. Le probl�me est qu'il faut alors choisir une valeur pour dwFourCC
entre DXT1 et DXT5, et je comprends pas tout aux diff�rences concernant les
alpha. Taka essaie les 5. Moi je n'en ai utilis� que pour r�cup�rer des
textures ayant d�j� un alpha pr�cod� mais ind�pendant de la sc�ne, donc j'ai
utilis� DXT3. Quand ya pas d'alpha, je sais pas.

Pour r�cup�rer ensuite les donn�es compress�es, il faut comme d'habitude
utiliser Lock, et tu dois alors r�cup�rer DDSD_LINEARSIZE dans le dwFlags du
DDSURFACEDESC. dwLinearSize te donne la taille finale compress�e, et c'est
juste ce nombre d'octets qu'il te faut charger.

Enfin, pour les remonter dans une surface, d�clare la surface cible finale
comme tu veux, mais cr�e une texture compress�e (comme ci-dessus), charge
les donn�es compress�es dedans, et copie vers ta surface cible. Comme �a, au
final, tu auras bien r�duit le trafic r�seau, en effectuant les compressions
/ d�compressions par le mat�riel. Toute carte d�cente supporte les
compressions DXT par mat�riel. Les autres sont ind�centes. Je ne les citerai
pas. Je ne les connais plus. Je ne suis plus de cette pl�be, moi, j'ai un
Pentium 3, non mais alors, nanan�re.