🚀 go-pugleaf

> Humm... je ne suis pas s�r d'avoir bien saisi le but g�n�ral de tes
> questions. Es-tu vraiment limit� par le d�bit vid�o --> system ? Mais dans
> le moindre ordinateur ultra bouseux, on fr�le les 100 Mo/s, ce qui me parait
> bazookesque pour une simple capture d'�cran. As-tu vraiment besoin d'�tre
> tribazookesque ?

J'ai besoin d'�tre quadribazookesque si je puis me permettre...
Je dois capturer des �crans pouvant aller jusqu'a 1600x1200 en 32Bits
et des videos en qualit� broadcast. Et mon moniteur rafraich�t cette r�solution
� 85 Hertz.

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

Bien sur des ecrans windows n'ont pas besoin d'une capture a cette fr�quence.
Et les vid�os sont en g�n�ral enregistr� � 25-30 fps. (max en 800x600).
Cela dit la vitesse maximale du bus est une vitesse th�orique.....


> Sache ensuite que le concept de blit est obsol�te dans DirectX. Il faut
> maintenant passer par GDI (qui l� encore est largement suffisant pour une
> capture video. T'es-tu renseign� sur le taux de rafraichissement de ton
> �cran ? J'ai du mal � croire que de simples appels GDI ne suffisent pas �
> suivre les 80 ou 85 Hz d'un �cran normal). Depuis le 10 Novembre, on ne peut
> plus faire de blit et en m�me temps utiliser la derni�re version de DirectX,
> car les objets de DX8 ne fournissent m�me pas les interfaces DX7 donnant
> acc�s aux blits.

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

> C'est une d�cision d�lib�r�e et tr�s sage de la part de
> Microsoft (a�e, �a me gratte de dire �a), car pour un fabricant de carte
> graphique, donner acc�s � la zone m�moire de l'�cran � l'utilisateur peut
> �tre extr�mement p�nalisant pour ses propres impl�mentations de fonctions
> avanc�es (FSAA, flou, ou m�me simplement gestion des caches internes), et
> forcer � mettre des garde-fou qui p�naliseraient tout le reste.

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 te sugg�re de suivre microsoft.public.win32.programmer.directx pendant
> quelque temps. En ce moment, beaucoup de monde expose des probl�mes dus � la
> disparition des blits, avec � chaque fois jusqu'� maintenant des r�ponses
> tr�s sens�es qui montrent que le blit n'�tait utilis� que par mauvaise
> habitude.

Merci pour le newsgroup.
Je suis d'accord avec toi cependant 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...



> A part ces g�n�ralit�s, voici les r�ponses que je peux donner � tes
> questions :
>
> > 1- Quelles cartes du commerce supportent en hardware la copie System -
> > Video et vice-versa ?
>
> �a n'a pas beaucoup de sens : par d�finition, la m�moire "System" transite
> par le bus, contrairement � la m�moire "Non local" (qui peut �tre
> physiquement au m�me endroit que la m�moire "System"), qui passe par AGP.
> Donc parler de m�moire "System" fait r�f�rence non pas � un type de m�moire,
> mais � une mani�re d'acc�der la m�moire, qui justement fait entrer en jeu le
> processeur.

Oui, mais en nonlocal les infos transitent aussi par le bus (le bus AGP).
Ou alors je n'est pas compris le terme 'System' et 'Non-Local'.

Cette question provient d'un test qui montre bien que le blit de m�moire vid�o
� vid�o est bien plus rapide que le blit de m�moire vid�o vers la m�moire
syst�me
( la RAM du PC  j'entend )
Mais si je veux transf�rer les �crans aux autres machines, je dois forc�ment les
r�cup�rer
en m�moire centrale.

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.



> > 2- Pourquoi si des cartes AGP supportent la copie NonLocal - Video,
> > il n'a  pas  �t� pr�vu dans DirectX, visiblement, d'implentation dans le
> > sens Video - Nonlocal ?
>
> C'est rigoureusement inutile pour ton application, mais c'est tout � fait
> courant de le faire. Si tu souhaites transf�rer vers la m�moire "Non local"
> depuis la m�moire vid�o, tu ne pourras y acc�der par la suite que par le
> bus, ce qui fait que tu y aura acc�s finalement � la vitesse du bus, comme
> si tu avais utilis� de la m�m�oire "System". En fait, la m�moire "Nonlocal"
> sert uniquement de "disque dur" rapide pour le processeur vid�o, de mani�re
> � g�rer des donn�es d�passant sa m�moire sans �tre p�nalis� par la vitesse
> du bus ni utiliser le processeur. L� encore, la d�nomination "Non local"
> fait plut�t r�f�rence � une mani�re d'acc�der � de la m�moire. Si par la
> suite tu l'utilise comme de la m�moire "System", cela se transforme en
> m�moire "System" par l'op�ration de la f�e Carabosse.

(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)


> > 3- Existe t'il des cartes qui r�alise la compression/decompression de
> > donn�es en hardware ?
>
> De quel format parles-tu ? En ce qui concerne les transferts de m�moire dont
> tu parles, les donn�es les plus utilis�es sont les textures, qui sont
> maintenant compress�es/d�compress�es au vol dans pratiquement toutes les
> cartes.

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�)
Tu dois penser au DXTC (alias S3TC) mais je ne sais pas si toutes les cartes
peuvent faire la d�compression.

Et je pense que les cartes 2D (only) n'en sont purement et simplement pas
capables
du tout.


> > 4- Et enfin, pensez vous qu'il existe une autre technique plus rapide
> > pour r�aliser cette capture ?
>
> cf. le d�but de mon message.

Si j'ai bien compris avec le GDI donc.
Que j'ai abandonn� pour DirectX soit disant plus rapide.
Comme quoi....

Bref comme tu le vois, le but est d'essayer de monopoliser le moins de ressource

(CPU) possible.

> Cordialement,
>
> Andr�-Luc

Merci � toi.

Cordialement
Nicolas



> PS : le crucipostage m�ne � une mort horrible et certaine, dans les plus
> atroces souffrances. Je ne te r�ponds que sur 2 des groupes, les plus
> appropri�s.

Ok message compris.