Prise en charge de l’analyse des ressources inter-adaptateurs (CASO)

Performances pré-CASO (chemin d’accès à deux copies)

À partir de Windows 8.1 (WDDM 1.3), les applications D3D9 et DXGI ont pu utiliser la prise en charge des présentations inter-adaptateurs sur les configurations multi-adaptateurs telles que les systèmes hybrides. Avec cette prise en charge, le rendu est effectué sur un adaptateur de rendu (généralement le GPU discret), puis deux copies sont effectuées pour obtenir le contenu de la carte graphique (généralement le GPU intégré) pour l’analyse sur l’affichage.

• La copie 1 est de la ressource d’adaptateur de rendu vers une ressource inter-adaptateurs.
• La copie 2 est à partir de la ressource inter-adaptateurs vers la ressource d’adaptateur d’affichage.

Ces copies peuvent limiter les performances des applications, en particulier pour les applications optimisées pour une faible latence.

Utilisation de CASO pour optimiser le modèle de présentation inversée (chemin d’accès à une copie)

Les pilotes Windows Server 2022 (WDDM 2.9) et versions ultérieures peuvent déclarer la prise en charge d’un niveau de ressource inter-adaptateur approprié, ce qui permet à la pile de présentation du système d’optimiser les présentations inter-adaptateurs. Les pilotes doivent déclarer la prise en charge de cette fonctionnalité en fonction de leur propre capacité d’adaptateur, quelle que soit la configuration de l’appareil, de sorte que la valeur de la fonctionnalité soit mise à l’échelle sur toutes les configurations matérielles applicables. Cette mise à l’échelle inclut, sans s’y limiter, un seul appareil GPU avec attachement dynamique d’autres GPU externes.

Si l’adaptateur d’affichage prend en charge caso, le système effectue uniquement la première copie de la surface de l’adaptateur de rendu vers la surface de l’adaptateur croisé, puis analyse directement à partir de la surface de l’adaptateur croisé. Cette fonctionnalité entraîne une réduction du traitement, de la bande passante, de la puissance et de la latence.

La fonctionnalité CASO est implémentée pour le runtime DXGI pour le modèle de présentation flip.

Modifications et ajouts DDI pour CASO

Indication de la prise en charge des niveaux pour les ressources inter-adaptateurs

DXGI implémente trois niveaux de prise en charge des ressources inter-adaptateurs :

1. Copie vers et depuis des ressources inter-adaptateurs (niveau le plus bas)
2. Texturation à partir de ressources inter-adaptateurs
3. Analyse des ressources inter-adaptateurs (niveau le plus élevé)

Chaque niveau de support supérieur doit garantir la prise en charge du ou des niveaux inférieurs. Par exemple, pour revendiquer la prise en charge de l’analyse des ressources inter-adaptateurs, le pilote doit également prendre en charge la texturation et la copie.

Les pilotes déclarent la prise en charge de chaque niveau en définissant les valeurs de champ de bits DXGK_VIDMMCAPS suivantes dans DXGK_DRIVERCAPS. MemoryManagementCaps :

Niveau	Signification du niveau	valeur DXGK_VIDMMCAPS
Niveau 1	Prise en charge de la copie : copier vers et à partir de ressources inter-adaptateurs	CrossAdapterResource (exposé en mode utilisateur par le noyau graphique via le bit SupportCrossAdapterResource dans D3DKMT_WDDM_1_3_CAPS
Niveau 2	Prise en charge des textures : Texture provenant de ressources inter-adaptateurs)	CrossAdapterResourceTexture (inclut la prise en charge de l’affichage des ressources du nuanceur, de l’affichage d’accès non ordonné et de la cible de rendu)
Niveau 3	Prise en charge de CASO : Analyse à partir de ressources inter-adaptateurs	CrossAdapterResourceScanout

Le noyau graphique échoue au démarrage de l’adaptateur s’il n’indique pas la prise en charge d’une manière sur-ensemble pour les trois niveaux. Par exemple, CrossAdapterResource doit être défini si CrossAdapterResourceTexture est défini.

Conditions de prise en charge de niveau 1

Les ressources inter-adaptateurs sont toujours définies de la même façon qu’elles sont utilisées pour la prise en charge de la copie de niveau 1 WDDM 1.3.

Exigences de support de niveau 2

Les exigences sont similaires à la fonctionnalité CrossAdapterRowMajorTextureSupported du pilote en mode utilisateur D3D12 (cap) ; autrement dit, l’appareil prend en charge les vues de ressources du nuanceur, les vues d’accès non ordonnées et le rendu des vues cibles des textures principales de ligne inter-adaptateurs. Toutefois, alors que CrossAdapterRowMajorTextureSupported de D3D12 nécessite la prise en charge de tous les formats de texture appropriés, cette limite de niveau 2 nécessite uniquement la prise en charge des formats DisplayScanOut répertoriés dans exigences de prise en charge de niveau 3, au minimum.

Étant donné que la limite de D3D12 est un sur-ensemble de cette limite de niveau 2, D3D12CreateDevice vérifie également que la limite CrossAdapterResourceTexture du pilote du noyau est définie si sa limite CrossAdapterRowMajorTextureSupported est définie et échoue à la création de l’appareil si ce n’est pas le cas.

Exigences de support de niveau 3

Le système doit être en mesure d’effectuer les fonctionnalités de basculement prises en charge, telles que déclarées par le pilote dans DXGK_FLIPCAPS, pour les ressources inter-adaptateurs des spécifications minimales suivantes :

• Une taille de mémoire tampon principale inter-adaptateurs de 1920 x 1080 ou moins
• Format de pixel de mémoire tampon de l’un des formats DisplayScanOut pris en charge. Depuis Windows 10 version 20H1, les formats suivants sont les suivants :
  • DXGI_FORMAT_R16G16B16A16_FLOAT
  • DXGI_FORMAT_R10G10B10A2_UNORM
  • DXGI_FORMAT_R8G8B8A8_UNORM
  • DXGI_FORMAT_R8G8B8A8_UNORM_SRGB
  • DXGI_FORMAT_B8G8R8A8_UNORM
  • DXGI_FORMAT_B8G8R8A8_UNORM_SRGB

Si le pilote prend en charge l’analyse des ressources d’adaptateurs croisés d’un plus grand nombre de formats de texture, il doit également prendre en charge la texturation à partir de ces formats, conformément aux exigences de prise en charge du niveau.

Notes

Le runtime DXGI interroge le pilote pour sa prise en charge de CrossAdapterResourceScanout . Si elle est prise en charge, la pile de présentation descend du chemin d’accès d’une copie. Par conséquent, les pilotes qui déclarent la prise en charge de CrossAdapterResourceScanout sont requis pour prendre en charge le DXGKDDI_CHECKMULTIPLANEOVERLAYSUPPORT3 DDI. En outre, il doit également prendre en charge tous les DDIS liés à la présentation pertinents pour les primaires d’adaptateurs croisés des spécifications minimales ci-dessus. En voici quelques exemples : pfnCreateResource, pfnCheckMultiplaneOverlaySupport et pfnPresentMultiplaneOverlay/pfnPresent1. Pour plus d’informations, consultez Prise en charge de la superposition multiplane. Pour plus d’informations sur l’abandon de CASO, consultez DDIs de pilotes pour l’optimisation de la présentation.

Ces deux niveaux ont des tests HLK pour la vérification.

Indicateur StaticCheck de prise en charge pour DXGKDDI_CHECKMULTIPLANEOVERLAYSUPPORT3

L’indicateur StaticCheck a été ajouté à DXGK_MULTIPLANE_OVERLAY_FLAGS dans WDDM 3.0. Cet indicateur étend l’utilisation de l’DXGKDDI_CHECKMULTIPLANEOVERLAYSUPPORT3 DDI pour la prise en charge de CASO. Cet indicateur permet DXGKDDI_CHECKMULTIPLANEOVERLAYSUPPORT3 d’interroger un pilote pour déterminer si le plan marqué avec l’indicateur StaticCheck est capable d’effectuer une analyse. Cet appel est un appel unique et ne doit pas affecter le comportement réel de la présentation. Par conséquent, les pilotes qui effectuent une mise en cache des informations présentes à partir de DXGKDDI_CHECKMULTIPLANEOVERLAYSUPPORT3 ne doivent pas inclure les informations des appels DDI avec un plan StaticCheck . Ils doivent simplement effectuer la détermination de la prise en charge de manière autonome ou statique.

DXGKDDI_CHECKMULTIPLANEOVERLAYSUPPORT3 avec l’indicateur StaticCheck défini est garanti :

• Avoir exactement un plan marqué avec l’indicateur
• Ne pas contenir d’informations de plan PostComposition

Un appel à DXGKDDI_CHECKMULTIPLANEOVERLAYSUPPORT3 avec l’ensemble d’indicateurs StaticCheck est utilisé à partir du processus d’application de DXGI lors de la création de la mémoire tampon, par exemple lors de la création de la chaîne d’échange ou de ResizeBuffers, afin de tenter de déterminer si l’authentification caso est prise en charge pour la configuration matérielle actuelle.

Cas spécial HybridIntegrated

Il est important de noter que les pilotes HybridIntegrated sont conçus pour avoir une prise en charge de l’analyse de niveau 3. À compter de WDDM 3.0, les pilotes HybridIntegrated doivent déclarer la prise en charge de CrossAdapterResourceScanout. Un test HLK vérifie cette exigence.

Les bouchons hybrides existants pourraient être dépréciés à l’avenir. Par conséquent, il est essentiel que la limite CrossAdapterResourceScanout soit découplée pour permettre une plus grande flexibilité pour évoluer dans cet espace à l’avenir. Par conséquent, même les pilotes qui ne sont pas HybridIntegrated peuvent définir le niveau de prise en charge inter-adaptateurs comme il convient.

Modifications du noyau graphique

À compter de WDDM 2.9, les ajouts/modifications suivants ont été apportés à la prise en charge des ressources inter-adaptateurs :

• La valeur KMTQAITYPE_CROSSADAPTERRESOURCE_SUPPORT a été ajoutée à l’énumération KMTQUERYADAPTERINFOTYPE existante

• La structure D3DKMT_CROSSADAPTERRESOURCE_SUPPORT et l’énumération D3DKMT_CROSSADAPTERRESOURCE_SUPPORT_TIER ont été ajoutées

Exemple d’utilisation :

D3DKMT_CROSSADAPTERRESOURCE_SUPPORT KernelSupport = {};
D3DKMT_QUERYADAPTERINFO QueryAdapterInfo;
QueryAdapterInfo.hAdapter = m_hAdapter;
QueryAdapterInfo.Type = KMTQAITYPE_CROSSADAPTERRESOURCE_SUPPORT;
QueryAdapterInfo.pPrivateDriverData = &KernelSupport;
QueryAdapterInfo.PrivateDriverDataSize = sizeof( KernelSupport );
VERIFY_SUCCEEDED(D3DKMTQueryAdapterInfo(&QueryAdapterInfo));

// Use KernelSupport.SupportTier as appropriate

DDIs de pilote pour l’optimisation de la présentation

Les pilotes utilisent les DDIs suivants pour indiquer si l’analyse croisée des adaptateurs est prise en charge :

• DXGK_VIDMMCAPS ::CrossAdapterResourceScanout

  Le système interroge cette limite tôt pour déterminer si le pilote prend en charge la fonctionnalité CASO.

  Si le pilote prend en charge CASO, DXGI continue avec le chemin CASO à une copie ; sinon, DXGI revient au chemin d’accès à deux copies.

• pfnCreateResource DDI

  Sur le chemin d’accès CASO à une copie, DXGI crée la ressource inter-adaptateurs en tant que principal sur la carte graphique, via pfnCreateResource. Le pilote doit évaluer en fonction des propriétés de la ressource s’il peut analyser à partir de cette ressource.

  Si le pilote prend en charge l’analyse en fonction des propriétés de la ressource, DXGI continue avec le chemin d’accès CASO à une copie. Sinon, le pilote doit refuser les analyses en retournant DXGI_DDI_PRIMARY_DRIVER_FLAG_NO_SCANOUT. Dans ce cas, DXGI revient au chemin d’accès à deux copies. Ce secours ne doit se produire que si les propriétés de ressource dépassent les exigences minimales répertoriées dans Exigences de support de niveau 3.

• pfnCheckMultiplaneOverlaySupport DDI

  En fonction du comportement actuel, le Gestionnaire Windows de bureau (DWM) appelle le DDI pfnCheckMultiplaneOverlaySupport du pilote d’affichage pour déterminer avec précision si la surface principale peut être analysée. Si le pilote prend en charge, l’analyse se produit. Sinon, DWM revient au mode de composition DWM.

  Notez que les cadeaux composés par DWM sont susceptibles d’être moins souhaitables que le flip indépendant (iFlip) via le chemin d’accès à deux copies ou iFlip via le chemin CASO à une copie. Par conséquent, il peut y avoir des scénarios d’affichage courants où la bande passante de présentation est limitée, comme les affichages pivotés ou les affichages multiples, où les pilotes peuvent échouer constamment à la prise en charge de pfnCheckMultiplaneOverlaySupport dans DWM, ce qui entraîne probablement une expérience plus médiocre que le chemin à deux copies.

  Pour atténuer l’expérience de secours négative, DXGI appelle pfnCheckMultiplaneOverlaySupport lors de la création de la mémoire tampon avec la ressource inter-adaptateurs en tant que plan marqué avec l’indicateur StaticCheck , pour vérifier avec une grande précision si le pilote peut effectuer une analyse en fonction des caractéristiques de bande passante connues existantes. S’il est pris en charge, DXGI continue avec le chemin d’accès CASO à une copie ; sinon, il revient au chemin à deux copies.

Test HLK

Une exigence et une fonctionnalité WDDM 3.0 HLK, avec ses tests HLK correspondants, ont été ajoutées. Cette exigence est liée à la prise en charge DXGK_VIDMMCAPS que les pilotes peuvent déclarer ; plus précisément, CrossAdapterResourceTexture et CrossAdapterResourceScanout.

CrossAdapterResourceTexture

Un test HLK a été ajouté pour vérifier les opérations d’affichage des ressources du nuanceur (SRV) sur les ressources inter-adaptateurs.

• Pour D3D12, le test HLK « D3D12 - Cross Adapter Resource DX12 » existant pour Device.Graphics.AdapterRender.D3D12Core.CoreRequirement a été ajouté ; plus précisément, le cas de test CrossAdapterResource ::CrossAdapterTextureSRV.

  À ce cas de test HLK s’ajoute la vérification de la relation superset entre le capuchon KMD CrossAdapterResourceTexture et le capuchon UMD CrossAdapterRowMajorTextureSupported D3D12. De même, la logique a été ajoutée dans D3D12CreateDevice pour garantir que si sa limite UMD est définie, la limite de pilote de niveau 2 du noyau doit également être définie et la création de l’appareil échoue si ce n’est pas le cas.

• Pour D3D11, le cas de test ci-dessus a été ajouté au test HLK pour Device.Graphics.WDDM30.Render.CrossAdapterScanOut ; plus précisément, D3DConf_11_CrossAdapterResource ::CrossAdapterResourceSRV.

Analyse des ressources inter-adaptateurs

Les tests HLK suivants ont été ajoutés :

• Device.Graphics.WDDM30.Render.CrossAdapterScanOut

  • Un test HLK pour vérifier que les pilotes peuvent créer correctement des ressources primaires inter-adaptateurs sans désactiver le comportement d’analyse par le biais de l’indicateur DXGI_DDI_PRIMARY_DRIVER_FLAG_NO_SCANOUT .
  • Un test HLK pour vérifier que ces pilotes prennent en charge les DXGKDDI_CHECKMULTIPLANEOVERLAYSUPPORT3 DDI.
  • Test HLK manuel pour qu’un testeur vérifie manuellement que :
    • La surface de l’adaptateur croisé analysée est exempte d’altération visuelle ou d’artefacts ou de déchirures inattendues
    • La surface de l’adaptateur croisé est analysée directement sans transformations ou copies internes préalables.

  Ces tests de bout en bout vérifient également naturellement que les DDIs CheckMultiplaneOverlaySupport et Present sont pris en charge pour les ressources inter-adaptateurs. L’application de test manuel a certaines exigences matérielles spécifiques, telles qu’un moniteur à haute résolution et à taux d’actualisation élevé. Pour plus d’informations, consultez le document de référence qui accompagne le test.

• Device.Graphics.WDDM30.Render.CoreRequirement

  • Un test HLK pour vérifier que les pilotes qui déclarent le capuchon HybridIntegrated déclarent également la limite CrossAdapterResourceScanout .

• System.Fundamentals.Graphics.HybridGraphics.MultiGPU

  • Un test HLK basé sur le système pour permettre aux oem d’exécuter ces tests sur leurs appareils hybrides capables d’exercer le chemin d’accès à une copie de DXGI dans le cadre de la validation du système de bout en bout.