Gestion de la mémoire Multiple-Head

La définition du bit de capacité DDSCAPS2_ADDITIONALPRIMARY dans le membre dwCaps2 de la structure DDSCAPS2 pour chaque surface de la tête subordonnée avertit cette tête que ces surfaces sont les dernières surfaces allouées à partir de la mémoire vidéo affectée à cette tête. La tête subordonnée doit ensuite abandonner le contrôle de l’allocation de sa mémoire vidéo à la tête master, car la tête subordonnée est garantie qu’elle ne reçoit pas d’appels DdCreateSurface suivants pendant la durée de vie de l’application.

Le pilote doit s’assurer que la tête master est en mesure d’allouer la mémoire associée aux têtes subordonnées.

Lorsque le runtime appelle la fonction DdDestroySurface du pilote pour détruire les surfaces sur la tête subordonnée dans laquelle le bit de capacité DDSCAPS2_ADDITIONALPRIMARY est défini, le pilote est averti que la tête subordonnée contrôle à nouveau sa gestion de la mémoire vidéo.

Dans la plupart des cas, ce choix de la tête propriétaire de la mémoire vidéo est inhérent au processus DirectDraw existant. Plus précisément :

• Le runtime garantit qu’aucune demande d’allocation ultérieure n’est effectuée sur les têtes subordonnées après que les appels DdCreateSurface sont effectués à l’aide du bit DDSCAPS2_ADDITIONALPRIMARY. Par conséquent, le pilote n’est pas tenu de restreindre les allocations de son propre pool de mémoire vidéo à tout moment.

• Lorsque l’application est terminée ou réduite, toutes les surfaces sont détruites. Par conséquent, toutes les textures créées par le master tête du pool du responsable subordonné sont nettoyées.

• Si le bit DDSCAPS2_ADDITIONALPRIMARY n’est pas défini pour les surfaces sur les têtes subordonnées, ces têtes continuent d’allouer de la mémoire vidéo comme s’il s’agissait de têtes autonomes. En fait, ces têtes subordonnées sont fonctionnellement identiques à n’importe quel autre adaptateur à plusieurs moniteurs.

• Le pilote est requis pour fournir une implémentation dans laquelle le master head alloue de la mémoire à partir du pool d’un responsable subordonné, y compris la détermination du moment où une ressource particulière peut être allouée à partir du pool d’un responsable subordonné. Notez que le master-tête ne dispose pas d’informations sur la participation ou non à un scénario à plusieurs têtes. Lorsque la tête master manque de sa propre mémoire vidéo, elle doit parcourir toutes les têtes subordonnées de son groupe pour déterminer si l’une de ces têtes a des pools qui peuvent être utilisés par le master (en d’autres termes, pour déterminer si l’une des têtes subordonnées a reçu des appels DdCreateSurface avec le DDSCAPS2_ADDITIONALPRIMARY bit défini).

• Enfin, notez que le runtime garantit que toutes les têtes du groupe participent au scénario à têtes multiples. Par conséquent, le pilote ne doit conserver qu’un seul bit d’état indiquant s’il est actuellement en mode à plusieurs têtes.