FidelityFX FSR2
v2.2.1
Copyright (c) 2023 Advanced Micro Devices, Inc. Tous droits réservés.
L'autorisation est accordée par la présente, gratuitement, à toute personne obtenant une copie de ce logiciel et des fichiers de documentation associés (le « Logiciel »), d'utiliser le Logiciel sans restriction, y compris, sans limitation, les droits d'utilisation, de copie, de modification, de fusion. , publier, distribuer, concéder en sous-licence et/ou vendre des copies du Logiciel, et permettre aux personnes à qui le Logiciel est fourni de le faire, sous réserve des conditions suivantes : L'avis de droit d'auteur ci-dessus et cet avis d'autorisation doivent être inclus dans toutes les copies. ou des parties substantielles du Logiciel.
LE LOGICIEL EST FOURNI « EN L'ÉTAT », SANS GARANTIE D'AUCUNE SORTE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS LIMITATION LES GARANTIES DE QUALITÉ MARCHANDE, D'ADAPTATION À UN USAGE PARTICULIER ET DE NON-VIOLATION. EN AUCUN CAS LES AUTEURS OU LES TITULAIRES DES DROITS D'AUTEUR NE SERONT RESPONSABLES DE TOUTE RÉCLAMATION, DOMMAGES OU AUTRE RESPONSABILITÉ, QUE CE SOIT DANS UNE ACTION CONTRACTUELLE, DÉLIT OU AUTRE, DÉCOULANT DE, DE OU EN RELATION AVEC LE LOGICIEL OU L'UTILISATION OU D'AUTRES TRANSACTIONS DANS LE LOGICIEL.
FSR2 utilise le retour temporel pour reconstruire des images haute résolution tout en conservant et même en améliorant la qualité de l'image par rapport au rendu natif.
FSR2 peut permettre des « performances pratiques » pour les opérations de rendu coûteuses, telles que le lancer de rayons matériel.
HLSL CS_6_2 CS_6_6*
* - CS_6_6 est utilisé sur certains matériels prenant en charge des fronts d'onde de 64 largeurs.
Pour utiliser FSR2, vous devez suivre les étapes ci-dessous :
Double-cliquez sur GenerateSolutions.bat dans le répertoire build .
Ouvrez la solution correspondant à votre API et créez la solution.
Copiez la bibliothèque API de bin/ffx_fsr2_api dans le dossier contenant un dossier de votre projet contenant des bibliothèques tierces.
Copiez la bibliothèque correspondant au backend FSR2 que vous souhaitez utiliser, par exemple : bin/ffx_fsr2_api/ffx_fsr2_api_dx12_x64.lib pour DirectX12.
Copiez les fichiers d'en-tête d'API de base suivants de src/ffx-fsr2-api dans votre projet : ffx_fsr2.h , ffx_types.h , ffx_error.h , ffx_fsr2_interface.h , ffx_util.h , shaders/ffx_fsr2_common.h et shaders/ffx_fsr2_resources.h . Il convient de veiller à conserver la structure de répertoire relative à la destination de la copie du fichier.
Copiez les fichiers d'en-tête pour le backend API de votre choix, par exemple pour DirectX12, vous copierez dx12/ffx_fsr2_dx12.h et dx12/shaders/ffx_fsr2_shaders_dx12.h . Il convient de veiller à conserver la structure de répertoire relative à la destination de la copie du fichier.
Incluez le fichier d'en-tête ffx_fsr2.h dans votre base de code où vous souhaitez interagir avec FSR2.
Créez un backend pour votre API cible. Par exemple, pour DirectX12, vous devez appeler ffxFsr2GetInterfaceDX12 . Un tampon de travail doit être alloué de la taille renvoyée en appelant ffxFsr2GetScratchMemorySizeDX12 et le pointeur vers ce tampon est transmis à ffxFsr2GetInterfaceDX12 .
Créez un contexte FSR2 en appelant ffxFsr2ContextCreate . La structure des paramètres doit être remplie en fonction de la configuration de votre application. Consultez la documentation de référence de l'API pour plus de détails.
Chaque image, vous devez appeler ffxFsr2ContextDispatch pour lancer les charges de travail FSR2. La structure des paramètres doit être remplie en fonction de la configuration de votre application. Consultez la documentation de référence de l'API pour plus de détails et assurez-vous que le champ frameTimeDelta est fourni en millisecondes.
Lorsque votre application se termine (ou que vous souhaitez détruire le contexte pour une autre raison), vous devez appeler ffxFsr2ContextDestroy . Le GPU doit être inactif avant d'appeler cette fonction.
La gigue sous-pixel doit être appliquée à la matrice de projection de votre application. Cela doit être fait lors de l'exécution du rendu principal de votre application. Vous devez utiliser la fonction ffxFsr2GetJitterOffset pour calculer les décalages précis de gigue. Voir la section Gigue de la caméra pour plus de détails.
Pour une qualité de mise à l'échelle optimale, il est fortement conseillé de remplir le masque réactif et le masque de transparence et de composition conformément à nos directives. Vous pouvez également utiliser ffxFsr2ContextGenerateReactiveMask comme point de départ.
Les applications doivent exposer les modes de mise à l'échelle dans leur interface utilisateur dans l'ordre suivant : Qualité, Équilibré, Performance et (éventuellement) Ultra Performance.
Les applications doivent également exposer un curseur de netteté pour permettre aux utilisateurs finaux d'obtenir une qualité supplémentaire.
Pour la commodité des utilisateurs finaux, l'API FSR2 fournit un certain nombre de rapports de mise à l'échelle prédéfinis qui sont nommés.
| Qualité | Facteur d'échelle par dimension |
|---|---|
| Qualité | 1,5x |
| Équilibré | 1,7x |
| Performance | 2,0x |
| Ultra-performantes | 3,0x |
Nous recommandons fortement aux applications d’adopter des ratios de dénomination et de mise à l’échelle cohérents dans leur interface utilisateur. Cela permet de garantir que l'expérience utilisateur est cohérente pour les utilisateurs de votre application qui peuvent avoir une expérience d'autres applications utilisant FSR2.
En fonction de votre matériel cible et de votre configuration d'exploitation, FSR2 fonctionnera à différents niveaux de performances.
Le tableau ci-dessous résume les performances mesurées de FSR2 sur une variété de matériels dans DX12.
| Résolution cible | Qualité | RX 7900 XTX | RX 6950XT | RX 6900XT | RX 6800XT | RX6800 | RX 6700XT | RX 6650XT | RX 5700XT | RX Véga 56 | RX590 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 3840x2160 | Qualité (1,5x) | 0,7 ms | 1,1 ms | 1,2 ms | 1,2 ms | 1,4 ms | 2,0 ms | 2,8 ms | 2,4 ms | 4,9 ms | 5,4 ms |
| Équilibré (1,7x) | 0,6 ms | 1,0 ms | 1,0 ms | 1,1 ms | 1,4 ms | 1,8 ms | 2,6 ms | 2,2 ms | 4,1 ms | 4,9 ms | |
| Performances (2x) | 0,6 ms | 0,9 ms | 1,0 ms | 1,0 ms | 1,3 ms | 1,7 ms | 2,3 ms | 2,0 ms | 3,6 ms | 4,4 ms | |
| Ultra perf. (3x) | 0,5 ms | 0,8 ms | 0,8 ms | 0,9 ms | 1,1 ms | 1,5 ms | 1,8 ms | 1,7 ms | 2,9 ms | 3,7 ms | |
| 2560x1440 | Qualité (1,5x) | 0,3 ms | 0,5 ms | 0,5 ms | 0,5 ms | 0,7 ms | 0,9 ms | 1,2 ms | 1,1 ms | 1,9 ms | 2,3 ms |
| Équilibré (1,7x) | 0,3 ms | 0,5 ms | 0,5 ms | 0,5 ms | 0,6 ms | 0,8 ms | 1,1 ms | 1,0 ms | 1,7 ms | 2,1 ms | |
| Performances (2x) | 0,3 ms | 0,4 ms | 0,4 ms | 0,4 ms | 0,6 ms | 0,8 ms | 0,9 ms | 0,9 ms | 1,5 ms | 1,9 ms | |
| Ultra perf. (3x) | 0,2 ms | 0,4 ms | 0,4 ms | 0,4 ms | 0,5 ms | 0,7 ms | 0,8 ms | 0,8 ms | 1,2 ms | 1,7 ms | |
| 1920x1080 | Qualité (1,5x) | 0,2 ms | 0,3 ms | 0,3 ms | 0,3 ms | 0,4 ms | 0,5 ms | 0,6 ms | 0,6 ms | 1,0 ms | 1,3 ms |
| Équilibré (1,7x) | 0,2 ms | 0,3 ms | 0,3 ms | 0,3 ms | 0,4 ms | 0,5 ms | 0,6 ms | 0,6 ms | 0,9 ms | 1,2 ms | |
| Performances (2x) | 0,2 ms | 0,2 ms | 0,2 ms | 0,3 ms | 0,3 ms | 0,5 ms | 0,5 ms | 0,5 ms | 0,8 ms | 1,1 ms | |
| Ultra perf. (3x) | 0,1 ms | 0,2 ms | 0,2 ms | 0,2 ms | 0,3 ms | 0,4 ms | 0,4 ms | 0,4 ms | 0,7 ms | 0,9 ms |
Les chiffres sont arrondis à 0,1 ms près et sont sans sharpness supplémentaire et sont susceptibles de changer.
L'utilisation de FSR2 nécessite qu'une certaine mémoire locale GPU supplémentaire soit allouée à la consommation par le GPU. Lors de l'utilisation de l'API FSR2, cette mémoire est allouée lors de la création du contexte FSR2, et ce via la série de rappels qui composent l'interface backend. Cette mémoire est utilisée pour stocker les surfaces intermédiaires calculées par l'algorithme FSR2 ainsi que les surfaces persistantes sur de nombreuses images de l'application. Le tableau ci-dessous inclut la quantité de mémoire utilisée par FSR2 dans diverses conditions de fonctionnement. La colonne « Jeu de travail » indique la quantité totale de mémoire utilisée par FSR2 pendant l'exécution de l'algorithme sur le GPU ; c'est la quantité de mémoire dont FSR2 aura besoin pour fonctionner. La colonne « Mémoire persistante » indique la quantité de la colonne « Jeu de travail » qui doit rester intacte pour les images suivantes de l'application ; cette mémoire stocke les données temporelles consommées par FSR2. La colonne « Mémoire aliasable » indique la quantité de la colonne « Jeu de travail » qui peut être aliasée par des surfaces ou d'autres ressources utilisées par l'application en dehors des limites de fonctionnement de FSR2.
Vous pouvez prendre le contrôle de la création de ressources dans FSR2 en remplaçant les parties de création et de destruction de ressources de l'interface backend de FSR2 et en transmettant les indicateurs d'alias. Cela signifie que pour une parfaite intégration de FSR2, une mémoire supplémentaire égale à la colonne "Mémoire persistante" du tableau ci-dessous est nécessaire en fonction de vos conditions de fonctionnement.
| Résolution | Qualité | Ensemble de travail (Mo) | Mémoire persistante (Mo) | Mémoire aliasable (Mo) |
|---|---|---|---|---|
| 3840x2160 | Qualité (1,5x) | 448 Mo | 354 Mo | 93 Mo |
| Équilibré (1,7x) | 407 Mo | 330 Mo | 77 Mo | |
| Performances (2x) | 376 Mo | 312 Mo | 63 Mo | |
| Ultra-performances (3x) | 323 Mo | 281 Mo | 42 Mo | |
| 2560x1440 | Qualité (1,5x) | 207 Mo | 164 Mo | 43 Mo |
| Équilibré (1,7x) | 189 Mo | 153 Mo | 36 Mo | |
| Performances (2x) | 172 Mo | 143 Mo | 29 Mo | |
| Ultra-performances (3x) | 149 Mo | 130 Mo | 19 Mo | |
| 1920x1080 | Qualité (1,5x) | 115 Mo | 90 Mo | 24 Mo |
| Équilibré (1,7x) | 105 Mo | 85 Mo | 20 Mo | |
| Performances (2x) | 101 Mo | 83 Mo | 18 Mo | |
| Ultra-performances (3x) | 84 Mo | 72 Mo | 11 Mo |
Les chiffres sont des approximations, arrondis au Mo le plus proche en utilisant un GPU RX 6700XT en DX12, et sont sujets à changement.
Pour plus de détails sur la façon de gérer les besoins en mémoire de FSR2, veuillez vous référer à la section de ce document traitant de la gestion de la mémoire.
FSR2 est un algorithme temporel et nécessite donc l'accès aux données de la trame actuelle et précédente. Le tableau suivant énumère toutes les entrées externes requises par FSR2.
La colonne de résolution indique si les données doivent être à la résolution « rendu » ou à la résolution « présentation ». La résolution « Rendu » indique que la ressource doit correspondre à la résolution à laquelle l'application effectue son rendu. À l'inverse, « présentation » indique que la résolution de la cible doit correspondre à celle qui doit être présentée à l'utilisateur. Toutes les ressources proviennent du cadre rendu actuel, pour les applications DirectX(R)12 et Vulkan(R), toutes les ressources d'entrée doivent être transférées respectivement vers
D3D12_RESOURCE_STATE_NON_PIXEL_SHADER_RESOURCEetVK_ACCESS_SHADER_READ_BITavant d'appelerffxFsr2ContextDispatch.
| Nom | Résolution | Format | Taper | Remarques |
|---|---|---|---|---|
| Tampon de couleur | Rendre | APPLICATION SPECIFIED | Texture | Tampon de couleur de résolution de rendu pour l’image actuelle fournie par l’application. Si le contenu du tampon de couleur est dans une plage dynamique élevée (HDR), alors l'indicateur FFX_FSR2_ENABLE_HIGH_DYNAMIC_RANGE doit être défini dans le champ flags de la structure FfxFsr2ContextDescription . |
| Tampon de profondeur | Rendre | APPLICATION SPECIFIED (1x FLOAT) | Texture | Tampon de profondeur de résolution de rendu pour l’image actuelle fournie par l’application. Les données doivent être fournies sous la forme d'une seule valeur à virgule flottante, dont la précision est sous le contrôle de l'application. La configuration de la profondeur doit être communiquée à FSR2 via le champ flags de la structure FfxFsr2ContextDescription lors de la création du FfxFsr2Context . Vous devez définir l'indicateur FFX_FSR2_ENABLE_DEPTH_INVERTED si votre tampon de profondeur est inversé (c'est-à-dire la plage [1..0]), et vous devez définir l'indicateur FFX_FSR2_ENABLE_DEPTH_INFINITE si votre tampon de profondeur a un plan lointain infini. Si l'application fournit le tampon de profondeur au format D32S8 , alors FSR2 ignorera le composant pochoir du tampon et créera une ressource R32_FLOAT pour adresser le tampon de profondeur. Sur le matériel GCN et RDNA, les tampons de profondeur sont stockés séparément des tampons de pochoir. |
| Vecteurs de mouvement | Rendu ou présentation | APPLICATION SPECIFIED (2x FLOAT) | Texture | Les vecteurs de mouvement 2D pour l'image actuelle fournis par l'application dans la plage [ (<-width, -height> .. <width, height> ]. Si votre application restitue les vecteurs de mouvement avec une plage différente, vous pouvez utiliser le champ motionVectorScale de la structure FfxFsr2DispatchDescription pour les ajuster afin qu'ils correspondent à la plage attendue pour FSR2. En interne, FSR2 utilise des quantités de 16 bits pour représenter les vecteurs de mouvement dans de nombreux cas, ce qui. signifie que même si des vecteurs de mouvement avec une plus grande précision peuvent être fournis, FSR2 ne bénéficiera pas de la précision accrue. La résolution du tampon de vecteurs de mouvement doit être égale à la résolution de rendu, à moins que l'indicateur FFX_FSR2_ENABLE_DISPLAY_RESOLUTION_MOTION_VECTORS ne soit défini dans le champ flags de la structure FfxFsr2ContextDescription . lors de la création du FfxFsr2Context , auquel cas il doit être égal à la résolution de la présentation. |
| Masque réactif | Rendre | R8_UNORM | Texture | Comme certaines zones d'une image rendue ne laissent pas d'empreinte dans le tampon de profondeur ou n'incluent pas de vecteurs de mouvement, FSR2 prend en charge une texture de masque réactif qui peut être utilisée pour indiquer à FSR2 où se trouvent ces zones. De bons exemples en sont les particules ou les objets à mélange alpha qui n'écrivent pas de vecteurs de profondeur ou de mouvement. Si cette ressource n'est pas définie, alors la logique de détection des changements d'ombrage de FSR2 gérera ces cas du mieux qu'elle peut, mais pour des résultats optimaux, cette ressource doit être définie. Pour plus d'informations sur le masque réactif veuillez vous référer à la section Masque réactif. |
| Exposition | 1x1 | R32_FLOAT | Texture | Une texture 1x1 contenant la valeur d'exposition calculée pour l'image actuelle. Cette ressource est facultative et peut être omise si l'indicateur FFX_FSR2_ENABLE_AUTO_EXPOSURE est défini dans le champ flags de la structure FfxFsr2ContextDescription lors de la création du FfxFsr2Context . |
Toutes les entrées fournies dans la résolution de rendu, à l'exception des vecteurs de mouvement, doivent être rendues avec une gigue. Les vecteurs de mouvement ne doivent pas avoir de gigue appliquée, à moins que l'indicateur FFX_FSR2_ENABLE_MOTION_VECTORS_JITTER_CANCELLATION ne soit présent.
Il est fortement recommandé d'utiliser un tampon de profondeur inversée et infinie avec FSR2. Toutefois, d'autres configurations de tampon de profondeur sont prises en charge. Une application doit informer l'API FSR2 de sa configuration de tampon de profondeur en définissant les indicateurs appropriés lors de la création du FfxFsr2Context . Le tableau ci-dessous contient les indicateurs appropriés.
| Drapeau FSR2 | Note |
|---|---|
FFX_FSR2_ENABLE_DEPTH_INVERTED | Un bit indiquant que les données du tampon de profondeur d'entrée fournies sont inversées [max..0]. |
FFX_FSR2_ENABLE_DEPTH_INFINITE | Un bit indiquant que les données du tampon de profondeur d'entrée fournies utilisent un plan lointain infini. |
Un élément clé d'un algorithme temporel (qu'il s'agisse d'anticrénelage ou de mise à l'échelle) est la fourniture de vecteurs de mouvement. FSR2 accepte les vecteurs de mouvement en 2D qui codent le mouvement d'un pixel de l'image actuelle à la position de ce même pixel dans l'image précédente. FSR2 s'attend à ce que les vecteurs de mouvement soient fournis par l'application dans la plage [ <-width, -height> .. <width, height> ] ; cela correspond à l'espace d'écran. Par exemple, un vecteur de mouvement pour un pixel dans le coin supérieur gauche de l'écran avec une valeur de <largeur, hauteur> représenterait un mouvement traversant toute la largeur et la hauteur des surfaces d'entrée, provenant du coin inférieur droit. .
Si votre application calcule des vecteurs de mouvement dans un autre espace - par exemple un espace de coordonnées de périphérique normalisé - vous pouvez alors utiliser le champ motionVectorScale de la structure FfxFsr2DispatchDescription pour demander à FSR2 de les ajuster pour qu'ils correspondent à la plage attendue pour FSR2. Les exemples de code ci-dessous illustrent comment les vecteurs de mouvement peuvent être adaptés à l'espace de l'écran. L'exemple de code HLSL et C++ ci-dessous illustre comment les vecteurs de mouvement de l'espace NDC peuvent être mis à l'échelle à l'aide de l'API hôte FSR2.
// GPU: Example of application NDC motion vector computation
float2 motionVector = (previousPosition.xy / previousPosition.w) - (currentPosition.xy / currentPosition.w);
// CPU: Matching FSR 2.0 motionVectorScale configuration
dispatchParameters.motionVectorScale.x = ( float )renderWidth;
dispatchParameters.motionVectorScale.y = ( float )renderHeight; En interne, FSR2 utilise des quantités de 16 bits pour représenter les vecteurs de mouvement dans de nombreux cas, ce qui signifie que même si des vecteurs de mouvement avec une plus grande précision peuvent être fournis, FSR2 ne bénéficiera pas actuellement de cette précision accrue. La résolution du tampon de vecteurs de mouvement doit être égale à la résolution de rendu, sauf si l'indicateur FFX_FSR2_ENABLE_DISPLAY_RESOLUTION_MOTION_VECTORS est défini dans le champ flags de la structure FfxFsr2ContextDescription lors de la création du FfxFsr2Context , auquel cas il doit être égal à la résolution de présentation.
FSR2 effectuera une mise à l'échelle de meilleure qualité lorsque davantage d'objets fourniront leurs vecteurs de mouvement. Il est donc conseillé que tous les objets opaques, testés alpha et mélangés alpha écrivent leurs vecteurs de mouvement pour tous les pixels couverts. Si des effets de vertex shader sont appliqués, comme le défilement des UV, ces calculs doivent également être pris en compte dans le calcul du mouvement pour obtenir les meilleurs résultats. Pour les objets alpha-blended, il est également fortement conseillé que la valeur alpha de chaque pixel couvert soit stockée dans le pixel correspondant dans le masque réactif. Cela permettra à FSR2 d'effectuer une meilleure gestion des objets alpha-blended lors de la mise à l'échelle. Le masque réactif est particulièrement important pour les objets à mélange alpha où l'écriture de vecteurs de mouvement peut être prohibitive, comme les particules.
Dans le contexte de FSR2, le terme « réactivité » désigne l'influence des échantillons rendus pour l'image actuelle sur la production de l'image finale mise à l'échelle. En règle générale, les échantillons rendus pour l'image actuelle contribuent pour une part relativement modeste au résultat calculé par FSR2 ; il existe cependant des exceptions. Pour produire les meilleurs résultats pour les objets alpha-mélangés à déplacement rapide, FSR2 nécessite que l'étape Reproject & Accumulation devienne plus réactive pour ces pixels. Comme il n'existe aucun moyen efficace de déterminer à partir des vecteurs de couleur, de profondeur ou de mouvement quels pixels ont été rendus à l'aide de la fusion alpha, FSR2 fonctionne mieux lorsque les applications marquent explicitement ces zones.
Par conséquent, il est fortement encouragé que les candidatures fournissent un masque réactif au FSR2. Le masque réactif guide FSR2 sur les domaines dans lesquels il doit réduire sa dépendance aux informations historiques lors de la composition du pixel actuel, et permettre à la place aux échantillons de l'image actuelle de contribuer davantage au résultat final. Le masque réactif permet à l'application de fournir une valeur comprise entre [0.0..1.0] où 0,0 indique que le pixel n'est pas du tout réactif (et doit utiliser la stratégie de composition FSR2 par défaut), et une valeur de 1,0 indique que le pixel doit être entièrement réactif. réactif. Il s'agit d'une plage à virgule flottante qui peut être adaptée à différentes situations.
Bien qu'il existe d'autres applications pour le masque réactif, la principale application du masque réactif est de produire de meilleurs résultats de mise à l'échelle d'images qui incluent des objets alpha-mélangés. Un bon indicateur de la réactivité est en fait la valeur alpha utilisée lors de la composition d'un objet mélangé à l'alpha dans la scène. Par conséquent, les applications doivent écrire alpha dans le masque réactif. Il convient de noter qu’il est peu probable qu’une valeur réactive proche de 1 produise de bons résultats. Nous recommandons donc de limiter la valeur réactive maximale à environ 0,9.
Si un masque réactif n'est pas fourni à FSR2 (en définissant le champ reactive de FfxFsr2DispatchDescription sur NULL ), alors une texture 1x1 générée en interne avec une valeur réactive effacée sera utilisée.
Pour aider les applications à générer le masque réactif et le masque de transparence et de composition, FSR2 fournit une API d'assistance facultative. Sous le capot, l'API lance un shader de calcul qui calcule ces valeurs pour chaque pixel à l'aide d'une heuristique basée sur la luminance.
Les applications souhaitant faire cela peuvent appeler la fonction ffxFsr2ContextGenerateReactiveMask et doivent transmettre deux versions du tampon de couleur, l'une contenant uniquement une géométrie opaque et l'autre contenant à la fois des objets opaques et alpha-mélangés.
En plus du masque réactif, FSR2 permet à l'application de désigner des zones d'autres rendus spécialisés qui doivent être prises en compte lors du processus de mise à l'échelle. Des exemples d'un tel rendu spécial incluent des zones de réflexions par lancer de rayons ou des textures animées.
Tandis que le masque Réactif ajuste l'équilibre de l'accumulation, le masque Transparence et composition ajuste les mécanismes de protection de l'historique des pixels. Le masque supprime également l'effet du facteur d'instabilité de luminance. Un pixel avec une valeur de 0 dans le masque Transparence & composition n'effectue aucune modification supplémentaire au verrouillage de ce pixel. À l’inverse, une valeur de 1 indique que le verrouillage de ce pixel doit être complètement supprimé.
Si un masque de transparence et de composition n'est pas fourni à FSR2 (en définissant le champ transparencyAndComposition de FfxFsr2DispatchDescription sur NULL ), alors une texture 1x1 générée en interne avec une valeur de transparence et de composition effacée sera utilisée.
FSR2.2 inclut une fonctionnalité expérimentale pour générer automatiquement un masque réactif et un masque de transparence et de composition. Pour activer cela, le champ enableAutoReactive de FfxFsr2DispatchDescription doit être défini sur « TRUE » et une copie des parties opaques uniquement du backbuffer doit être fournie dans « colorOpaqueOnly ». FSR2 générera et utilisera alors automatiquement le masque réactif et le masque de transparence et de composition en interne. Les masques sont générés lors d'une passe de calcul en analysant la différence du tampon de couleur avec et sans géométrie transparente, ainsi qu'en le comparant à l'image précédente. Sur la base du résultat de ces calculs, chaque pixel se voit attribuer des valeurs de masque réactif et de masque de transparence et de composition. Pour utiliser la génération automatique des masques, les 4 valeurs suivantes doivent également être fournies pour mettre à l'échelle et limiter l'intensité des masques (notez que les valeurs par défaut mentionnées sont des valeurs de départ suggérées mais doivent être ajustées par titre) :
Cette fonctionnalité est destinée à faciliter l'intégration de FSR2.2 dans un nouveau moteur ou titre. Cependant, pour une qualité optimale, nous recommandons toujours de rendre vous-même le masque réactif et le masque de transparence et de composition, car la génération de ces valeurs basées sur le matériau devrait être plus fiable que leur génération automatique à partir de l'image finale.
Veuillez noter que cette fonctionnalité est encore au stade expérimental et pourrait changer considérablement dans le futur.
FSR2 fournit deux valeurs qui contrôlent l'exposition utilisée lors de la mise à l'échelle. Ils sont les suivants :
La valeur d'exposition doit correspondre à celle utilisée par l'application lors de toutes les passes de mappage de tons ultérieures effectuées par l'application. Cela signifie que FSR2 fonctionnera de manière cohérente avec ce qui est susceptible d'être visible dans l'image tonale finale.
À différentes étapes de l'algorithme FSR2 décrit dans ce document, FSR2 calculera sa propre valeur d'exposition pour un usage interne. Il convient de noter que ce mappage de tons interne sera inversé pour toutes les sorties de FSR2 avant l'écriture de la sortie finale. Cela signifie que FSR2 renvoie des résultats dans le même domaine que le signal d'entrée d'origine.
Des valeurs d'exposition mal sélectionnées peuvent avoir un impact drastique sur la qualité finale de la mise à l'échelle de FSR2. Par conséquent, il est recommandé que FFX_FSR2_ENABLE_AUTO_EXPOSURE soit utilisé par l'application, sauf s'il existe une raison particulière de ne pas le faire. Lorsque FFX_FSR2_ENABLE_AUTO_EXPOSURE est défini dans le champ flags de la structure FfxFsr2ContextDescription , le calcul d'exposition indiqué dans le code HLSL ci-dessous est utilisé pour calculer la valeur d'exposition, qui correspond à la réponse d'exposition du film ISO 100.
float ComputeAutoExposureFromAverageLog ( float averageLogLuminance)
{
const float averageLuminance = exp (averageLogLuminance);
const float S = 100.0f ; // ISO arithmetic speed
const float K = 12.5f ;
const float exposureIso100 = log2 ((averageLuminance * S) / K);
const float q = 0.65f ;
const float luminanceMax = ( 78.0f / (q * S)) * pow ( 2.0f , exposureIso100);
return 1 / luminanceMax;
}L'objectif principal de FSR2 est d'améliorer les performances de rendu des applications en utilisant un algorithme de mise à l'échelle temporelle reposant sur un certain nombre d'entrées. Par conséquent, son placement dans le pipeline est essentiel pour garantir le bon équilibre entre la plus haute qualité visuelle et d’excellentes performances.
Avec toute approche de mise à l'échelle d'image, il est important de comprendre comment placer d'autres algorithmes d'espace image par rapport à l'algorithme de mise à l'échelle. Placer ces autres effets d'espace image avant la mise à l'échelle présente l'avantage de fonctionner à une résolution inférieure, ce qui confère bien sûr un avantage en termes de performances à l'application. Cependant, cela peut ne pas être approprié pour certaines classes de techniques d’espace image. Par exemple, de nombreuses applications peuvent introduire du bruit ou du grain dans l'image finale, peut-être pour simuler une caméra physique. Le faire avant qu'un upscaler puisse amener l'upscaler à amplifier le bruit, provoquant des artefacts indésirables dans l'image upscale résultante. Le tableau suivant divise les techniques courantes d'espace image en temps réel en deux colonnes. Le « Post-traitement A » contient toutes les techniques qui s'exécuteraient généralement avant la mise à l'échelle de FSR2, ce qui signifie qu'elles fonctionneraient toutes à la résolution de rendu. À l'inverse, la colonne « Post-traitement B » contient toutes les techniques qu'il est recommandé d'exécuter après FSR2, ce qui signifie qu'elles fonctionneraient avec une résolution de présentation plus grande.
| Post-traitement A | Post-traitement B |
|---|---|
| Réflexions de l'espace d'écran | Grain du film |
| Occlusion ambiante de l'espace d'écran | Aberration chromatique |
| Débruiteurs (ombre, reflets) | Vignette |
| Exposition (facultatif) | Mappage des tons |
| Floraison | |
| Profondeur de champ | |
| Flou de mouvement |
Veuillez noter que les recommandations présentées ici sont uniquement à titre indicatif et dépendent des caractéristiques précises de mise en œuvre de votre application.
Bien qu'il soit possible de générer les ressources intermédiaires appropriées, de compiler le code du shader, de définir les liaisons et de soumettre les répartitions, il est beaucoup plus facile d'utiliser l'API hôte FSR2 fournie.
Pour utiliser l'API, vous devez lier les bibliothèques FSR2 (plus d'informations sur celles-ci prochainement) et inclure le fichier d'en-tête ffx_fsr2.h , qui à son tour a les dépendances d'en-tête suivantes :
ffx_assert.h
ffx_error.h
ffx_fsr2_interface.h
ffx_types.h
ffx_util.h
Pour utiliser l'API FSR2, vous devez lier ffx_fsr2_api_x64.lib qui fournira les symboles pour les API orientées application. Cependant, l'API de FSR2 dispose d'un backend modulaire, ce qui signifie que différentes API et plates-formes graphiques peuvent être ciblées via l'utilisation d'un backend correspondant. Par conséquent, vous devez également inclure la bibliothèque backend correspondant à vos besoins, en faisant référence au tableau ci-dessous.
| Cible | Nom de la bibliothèque |
|---|---|
| DirectX(R)12 | ffx_fsr2_dx12_x64.lib |
| Vulkan® | ffx_fsr2_vk_x64.lib |
Veuillez noter que l'architecture modulaire de l'API FSR2 permet la mise en œuvre de backends personnalisés. Voir la section Backend modulaire pour plus de détails.
Pour commencer à utiliser l'API, l'application doit d'abord créer une structure FfxFsr2Context . Cette structure doit être située quelque part avec une durée de vie correspondant approximativement à celle de votre backbuffer ; quelque part sur le tas de l'application est généralement un bon choix. En appelant ffxFsr2ContextCreate la structure FfxFsr2Context sera remplie avec les données dont elle a besoin. De plus, un certain nombre d'appels seront effectués depuis ffxFsr2ContextCreate vers le backend qui est fourni à FfxFsr2Context dans le cadre de la structure FfxFsr2ContextDescription . Ces appels effectueront des tâches telles que la création des ressources intermédiaires requises par FSR2 et la configuration des shaders et de leur état de pipeline associé. L'API FSR2 n'effectue aucune allocation dynamique de mémoire.
Chaque image de votre application où une mise à l'échelle est requise, vous devez appeler ffxFsr2ContextDispatch . Cette fonction accepte la structure FfxFsr2Context qui a été créée plus tôt dans la vie de l'application ainsi qu'une description précise de la manière dont la mise à l'échelle doit être effectuée et sur quelles données. Cette description est fournie par l'application remplissant une structure FfxFsr2DispatchDescription .
La destruction du contexte s'effectue en appelant ffxFsr2ContextDestroy . Veuillez noter que le GPU doit être inactif avant de tenter d'appeler ffxFsr2ContextDestroy et que la fonction n'effectue pas de synchronisation implicite pour garantir que les ressources auxquelles FSR2 accède ne sont pas actuellement en vol. La raison de ce choix est d'éviter que FSR2 n'introduise des vidages GPU supplémentaires pour les applications qui effectuent déjà une synchronisation adéquate au point où elles pourraient souhaiter détruire le FfxFsr2Context , cela permet à une application d'effectuer la création et le démontage le plus efficace possible de l'API FSR2 lorsque requis.
Il existe des fonctions d'assistance supplémentaires fournies dans le cadre de l'API FSR2. Ces fonctions d'assistance effectuent des tâches telles que le calcul des décalages de gigue sous-pixel, ainsi que le calcul des résolutions de rendu basées sur les résolutions de répartition et les modes de mise à l'échelle par défaut fournis par FSR2.
Pour une documentation plus exhaustive de l'API FSR2, vous pouvez vous référer à la documentation de référence de l'API fournie.
La conception de l'API FSR2 signifie que l'implémentation principale de l'algorithme FSR2 ne sait pas sur quelle API de rendu il repose. Au lieu de cela, FSR2 appelle les fonctions qui lui sont fournies via une interface, permettant d'utiliser différents backends avec FSR2. Cette conception permet également aux applications intégrant FSR2 de fournir leur propre implémentation backend, ce qui signifie que les plates-formes que FSR2 ne prend pas actuellement en charge peuvent être ciblées en implémentant une poignée de fonctions. De plus, les applications qui disposent de leurs propres abstractions de rendu peuvent également implémenter leur propre backend, prenant le contrôle de tous les aspects de la fonction sous-jacente de FSR2, y compris la gestion de la mémoire, la création de ressources, la compilation de shaders, les liaisons de ressources de shader et la soumission des charges de travail FSR2 au périphérique graphique. .
Prête à l'emploi, l'API FSR2 sera compilée en plusieurs bibliothèques en suivant la séparation déjà décrite entre l'API principale et les backends. Cela signifie que si vous souhaitez utiliser les backends fournis avec FSR2, vous devez lier à la fois la bibliothèque principale de l'API FSR2 ainsi que le backend correspondant à vos besoins.
La version publique de FSR2 est livrée avec les backends DirectX(R)12 et Vulkan(R), mais d'autres backends sont disponibles sur demande. Discutez avec votre représentant AMD Developer Technology pour plus d'informations.
Si l'API FSR2 est utilisée avec l'un des backends fournis (par exemple : DirectX(R)12 ou Vulkan(R)), alors toutes les ressources requises par FSR2 sont créées en tant que ressources validées directement à l'aide du périphérique graphique fourni par l'application hôte. Cependant, en remplaçant la famille de fonctions de création et de destruction présentes dans l'interface backend, il est possible pour une application de contrôler plus précisément la gestion de la mémoire de FSR2.
Pour ce faire, vous pouvez soit fournir un backend personnalisé complet à FSR2 via la structure FfxFsr2ContextDescription transmise à la fonction ffxFsr2ContextCreate , soit récupérer le backend de l'API souhaitée et remplacer les fonctions de création et de destruction de ressources pour les gérer vous-même. Pour ce faire, écrasez simplement les pointeurs de fonction fpCreateResource et fpDestroyResource .
// Setup DX12 interface.
const size_t scratchBufferSize = ffxFsr2GetScratchMemorySizeDX12();
void * scratchBuffer = malloc(scratchBufferSize);
FfxErrorCode errorCode = ffxFsr2GetInterfaceDX12(&contextDescription.callbacks, m_pDevice-> GetDevice (), scratchBuffer, scratchBufferSize);
FFX_ASSERT (errorCode == FFX_OK);
// Override the resource creation and destruction.
contextDescription.callbacks.createResource = myCreateResource;
contextDescription.callbacks.destroyResource = myDestroyResource;
// Set up the context description.
contextDescription.device = ffxGetDeviceDX12(m_pDevice-> GetDevice ());
contextDescription.maxRenderSize.width = renderWidth;
contextDescription.maxRenderSize.height = renderHeight;
contextDescription.displaySize.width = displayWidth;
contextDescription.displaySize.height = displayHeight;
contextDescription.flags = FFX_FSR2_ENABLE_HIGH_DYNAMIC_RANGE
| FFX_FSR2_ENABLE_DEPTH_INVERTED
| FFX_FSR2_ENABLE_AUTO_EXPOSURE;
// Create the FSR2 context.
errorCode = ffxFsr2ContextCreate(&context, &contextDescription);
FFX_ASSERT (errorCode == FFX_OK); Un avantage intéressant pour une application prenant le contrôle de la gestion de la mémoire requise pour FSR2 est qu'un alias de ressources peut être effectué, ce qui peut générer une économie de mémoire. Le tableau présent dans Exigences en mémoire démontre les économies possibles grâce à l'utilisation de cette technique. Afin de réaliser les économies indiquées dans ce tableau, une zone de mémoire appropriée - dont le contenu n'est pas nécessaire pour survivre lors d'un appel aux répartitions FSR2 - doit être trouvée pour être partagée avec les ressources aliasables requises pour FSR2. Chaque appel FfxFsr2CreateResourceFunc effectué par l'API principale de FSR2 via l'interface backend de FSR2 contiendra un ensemble d'indicateurs dans le cadre de la structure FfxCreateResourceDescription . Si FFX_RESOURCE_FLAGS_ALIASABLE est défini dans le champ flags , cela indique que la ressource peut être alias en toute sécurité avec d'autres ressources dans le cadre de rendu.
L'anticrénelage temporel (TAA) est une technique qui utilise la sortie des images précédentes pour construire une sortie de meilleure qualité à partir de l'image actuelle. Comme FSR2 a un objectif similaire - mais avec l'objectif supplémentaire d'augmenter également la résolution de l'image rendue - il n'est plus nécessaire d'inclure une passe TAA distincte dans votre application.
FSR2 s'appuie sur l'application pour appliquer une instabilité sous-pixel lors du rendu - ceci est généralement inclus dans la matrice de projection de la caméra. Pour simplifier l'application de la gigue de la caméra, l'API FSR2 fournit un petit ensemble de fonctions utilitaires qui calculent le décalage de gigue sous-pixel pour une image particulière au sein d'une séquence de décalages de gigue séparés.
int32_t ffxFsr2GetJitterPhaseCount ( int32_t renderWidth, int32_t displayWidth);
FfxErrorCode ffxFsr2GetJitterOffset ( float * outX, float * outY, int32_t jitterPhase, int32_t sequenceLength);En interne, ces fonctions implémentent une séquence Halton[2,3] [Halton]. Le but de la séquence Halton est de fournir des points spatialement séparés, qui couvrent l'espace disponible.
Il est important de comprendre que les valeurs renvoyées par ffxFsr2GetJitterOffset sont dans l'espace de pixels unitaires, et afin de les composer correctement dans une matrice de projection, nous devons les convertir en décalages de projection. Le diagramme ci-dessus montre un seul pixel dans l’espace des pixels unitaires et dans l’espace de projection. La liste de codes ci-dessous montre comment composer correctement la valeur de décalage de gigue sous-pixel dans une matrice de projection.
const int32_t jitterPhaseCount = ffxFsr2GetJitterPhaseCount(renderWidth, displayWidth);
float jitterX = 0 ;
float jitterY = 0 ;
ffxFsr2GetJitterOffset (&jitterX, &jitterY, index, jitterPhaseCount);
// Calculate the jittered projection matrix.
const float jitterX = 2 . 0f * jitterX / ( float )renderWidth;
const float jitterY = - 2 . 0f * jitterY / ( float )renderHeight;
const Matrix4 jitterTranslationMatrix = translateMatrix(Matrix3::identity, Vector3(jitterX, jitterY, 0 ));
const Matrix4 jitteredProjectionMatrix = jitterTranslationMatrix * projectionMatrix; La gigue doit être appliquée à tous les rendus. Cela inclut les objets opaques, alpha transparents et lancés de rayons. Pour les objets rastérisés, les valeurs d'instabilité des sous-pixels calculées par la fonction ffxFsr2GetJitterOffset peuvent être appliquées à la matrice de projection de la caméra qui est finalement utilisée pour effectuer des transformations pendant l'ombrage des sommets. Pour le rendu par lancer de rayons, la gigue sous-pixel doit être appliquée à l'origine du rayon - souvent la position de la caméra.
Que vous choisissiez d'utiliser la fonction ffxFsr2GetJitterOffset recommandée ou votre propre générateur de séquence, vous devez définir le champ jitterOffset de la structure FfxFsr2DispatchDescription pour informer FSR2 du décalage de la gigue qui a été appliqué afin de rendre chaque trame. De plus, s'il n'utilise pas la fonction ffxFsr2GetJitterOffset recommandée, il faut veiller à ce que votre séquence de gigue ne génère jamais de vecteur nul; C'est une valeur de 0 dans les dimensions x et y.
Le tableau ci-dessous montre la longueur de séquence de la gigue pour chacun des modes de qualité par défaut.
| Mode de qualité | Facteur d'échelle | Longueur de séquence |
|---|---|---|
| Qualité | 1,5x (par dimension) | 18 |
| Équilibré | 1,7x (par dimension) | 23 |
| Performance | 2.0x (par dimension) | 32 |
| Ultra Performance | 3,0x (par dimension) | 72 |
| Coutume | [1..N] x (par dimension) | ceil(8 * n^2) |
La plupart des applications avec rendu en temps réel ont un grand degré de cohérence temporelle entre deux cadres consécutifs. Cependant, il y a des cas où un changement dans la transformation d'une caméra pourrait entraîner un changement brutal de ce qui est rendu. Dans de tels cas, il est peu probable que FSR2 puisse réutiliser toutes les données qu'elle a accumulées à partir des cadres précédents et devraient effacer ces données telles que les exclure de la considération dans le processus de composition. Afin d'indiquer à FSR2 qu'une coupe de saut s'est produite avec la caméra, vous devez définir le champ reset de la structure FfxFsr2DispatchDescription à true pour la première image de la transformation discontinue de la caméra.
Les performances de rendu peuvent être légèrement inférieures à l'opération de trame à trame typique lors de l'utilisation de l'indicateur de réinitialisation, car FSR2 effacera certaines ressources internes supplémentaires.
L'application d'un biais MIPMAP négatif générera généralement une image à l'échelle avec un meilleur détail de texture. Nous vous recommandons d'appliquer la formule suivante à votre biais MIPMAP:
mipBias = log2(renderResolution/displayResolution) - 1.0 ;Il est suggéré que les applications ajustent le biais MIP pour un contenu de texture à haute fréquence spécifique qui est susceptible de montrer des problèmes d'aliasage temporels.
Le tableau suivant illustre le facteur de biais MIPMAP qui résulte de l'évaluation du pseudocode ci-dessus pour les rapports de mise à l'échelle correspondant aux modes de qualité suggérés que les applications devraient exposer aux utilisateurs finaux.
| Mode de qualité | Facteur d'échelle | Biais mipmap |
|---|---|---|
| Qualité | 1,5x (par dimension) | -1,58 |
| Équilibré | 1,7x (par dimension) | -1,76 |
| Performance | 2.0x (par dimension) | -2,0 |
| Ultra Performance | 3,0x (par dimension) | -2,58 |
L'API FSR2 nécessite que frameTimeDelta soit fournie par l'application via la structure FfxFsr2DispatchDescription . Cette valeur est en millisecondes : si elle fonctionne à 60 images par seconde, la valeur transmise doit être d'environ 16,6f .
La valeur est utilisée dans le composant temporel de la fonction d'auto-exposition FSR 2. Cela permet de régler l'accumulation d'historique à des fins de qualité.
Les images de plage dynamique élevées sont prises en charge dans FSR2. Pour activer cela, vous devez définir le bit FFX_FSR2_ENABLE_HIGH_DYNAMIC_RANGE dans le champ flags de la structure FfxFsr2ContextDescription . Des images doivent être fournies à FSR2 dans l'espace colorimétrique linéaire.
La prise en charge des espaces de couleurs supplémentaires pourrait être fournie dans une future révision de FSR2.
FSR2 a été conçu pour profiter de l'accélération matérielle de la moitié de précision (FP16) pour obtenir les performances les plus élevées possibles. Cependant, pour fournir le niveau maximal de compatibilité et de flexibilité pour les applications, FSR2 comprend également la capacité de compiler les shaders en utilisant des opérations complètes de précision (FP32).
Il est recommandé d'utiliser la version FP16 de FSR2 sur tout le matériel qui le prend en charge. Vous pouvez interroger le niveau de prise en charge de votre carte graphique pour FP16 en interrogeant la capacité D3D12_FEATURE_DATA_SHADER_MIN_PRECISION_SUPPORT dans DirectX (R) 12 - Vous devez vérifier que la D3D[11/12]_SHADER_MIN_PRECISION_16_BIT FSR2. Pour Vulkan, si VkPhysicalDeviceFloat16Int8FeaturesKHR::shaderFloat16 n'est pas défini, alors vous devez se replier sur la version FP32 de FSR2. De même, si VkPhysicalDevice16BitStorageFeatures::storageBuffer16BitAccess n'est pas défini, vous devez également se replier sur la version FP32 de FSR2.
Pour activer le chemin FP32 dans le code source du shader FSR2, vous devez définir FFX_HALF à être 1 . Afin de partager la majorité du code source de l'algorithme entre FP16 et FP32 (garantissant un niveau élevé de partage de code pour prendre en charge la maintenance continue), vous remarquerez que le code source du shader FSR2 utilise un ensemble de macros de type qui facilitent la commutation facile entre les bas Types de base 16 bits et 32 bits dans la source du shader.
| Type fidelityfx | FP32 | PC16 |
|---|---|---|
FFX_MIN16_F | float | min16float |
FFX_MIN16_F2 | float2 | min16float2 |
FFX_MIN16_F3 | float3 | min16float3 |
FFX_MIN16_F4 | float4 | min16float4 |
Le tableau ci-dessus énumère les mappages entre les types de SDK FidelityFX abstraits et le type intrinsèque sous-jacent qui sera substitué en fonction de la configuration de la source du shader pendant la compilation.
Les GPU modernes exécutent des collections de fils - appelées fronts d'onde - ensemble de manière SIMT. Le nombre précis de threads qui constituent un seul front d'onde est une quantité spécifique au matériel. Certains matériels, tels que GCN et GPU basés sur l'AMD et l'ADNr prennent en charge la collecte de 64 threads en un seul front d'onde. Selon les caractéristiques précises de l'exécution d'un algorithme, il peut être plus ou moins avantageux de préférer une largeur de front d'onde spécifique. Avec l'introduction de Shader Model 6.6, Microsoft a ajouté la capacité à spécifiquement la largeur d'un front d'onde via HLSL. Pour le matériel, comme l'ADNr qui prend en charge les largeurs de front d'onde de 32 et 64 larges, il s'agit d'un outil très utile à des fins d'optimisation, car il fournit un moyen propre et portable de demander à la pile logicielle du pilote d'exécuter un front d'onde avec une largeur spécifique.
Pour les applications basées sur DirectX (R) 12 qui s'exécutent sur des GPU basés sur RDNA et RDNA2 et en utilisant le SDK Microsoft Agility, l'API hôte FSR2 sélectionnera une largeur de front d'onde de 64 larges.
La structure de description de contexte peut être fournie avec une fonction de rappel pour passer des avertissements textuels de l'exécution FSR 2 à l'application sous-jacente. Le membre fpMessage de la description est de type FfxFsr2Message qui est un pointeur de fonction pour passer des messages de chaîne de différents types. L'attribution de cette variable à une fonction appropriée et le passage de l'indicateur FFX_FSR2_ENABLE_DEBUG_CHECKING dans le membre Flags du FfxFsr2ContextDescription permettra la fonctionnalité. Il est recommandé que ce soit activé uniquement dans les builds de développement de débogage.
Un exemple du type de sortie qui peut se produire lorsque le vérificateur observe les problèmes possibles est ci-dessous:
FSR2_API_DEBUG_WARNING: FFX_FSR2_ENABLE_DEPTH_INFINITE and FFX_FSR2_ENABLE_DEPTH_INVERTED present, cameraFar value is very low which may result in depth separation artefacting
FSR2_API_DEBUG_WARNING: frameTimeDelta is less than 1.0f - this value should be milliseconds (~16.6f for 60fps)
L'algorithme FSR2 est implémenté dans une série d'étapes, qui sont les suivantes:
Chaque étape de passe de l'algorithme est disposée dans les sections suivant celle-ci, mais le flux de données pour l'algorithme FSR2 complet est indiqué dans le diagramme ci-dessous.
Le stade de la pyramide de luminance de calcul a deux responsabilités:
Le tableau suivant contient toutes les ressources consommées par l'étape de la pyramide de luminance de calcul.
La couche temporelle indique de quelle trame les données doivent provenir. «Frame actuel» signifie que les données doivent provenir des ressources créées pour le cadre qui doit être présenté ensuite. «Frame précédente» indique que les données devraient provenir de ressources qui ont été créées pour le cadre qui vient de se présenter. La colonne de résolution indique si les données doivent être en résolution «Résolution ou« présentation »rendue. La résolution «rendue» indique que la ressource doit correspondre à la résolution dans laquelle l'application effectue son rendu. Inversement, la «présentation» indique que la résolution de la cible doit correspondre à ce qui doit être présenté à l'utilisateur.
| Nom | Couche temporelle | Résolution | Format | Taper | Remarques |
|---|---|---|---|---|---|
| Tampon de couleur | Cadre actuel | Rendre | APPLICATION SPECIFIED | Texture | Le tampon de couleur de résolution de rendu pour le cadre actuel fourni par l'application. Si le contenu du tampon de couleur est dans une plage dynamique élevée (HDR), alors l'indicateur FFX_FSR2_ENABLE_HIGH_DYNAMIC_RANGE doit être défini dans le champ flags de la structure FfxFsr2ContextDescription . |
Le tableau suivant contient toutes les ressources produites ou modifiées par l'étape de la pyramide de luminance de calcul.
La couche temporelle indique de quelle trame les données doivent provenir. «Frame actuel» signifie que les données doivent provenir des ressources créées pour le cadre qui doit être présenté ensuite. «Frame précédente» indique que les données devraient provenir de ressources qui ont été créées pour le cadre qui vient de se présenter. La colonne de résolution indique si les données doivent être en résolution «Résolution ou« présentation »rendue. La résolution «rendue» indique que la ressource doit correspondre à la résolution dans laquelle l'application effectue son rendu. Inversement, la «présentation» indique que la résolution de la cible doit correspondre à ce qui doit être présenté à l'utilisateur.
| Nom | Couche temporelle | Résolution | Format | Taper | Remarques |
|---|---|---|---|---|---|
| Exposition | Cadre actuel | 1x1 | R32_FLOAT | Texture | Une texture 1x1 contenant la valeur d'exposition calculée pour le cadre actuel. Cette ressource est facultative et peut être omise si l'indicateur FFX_FSR2_ENABLE_AUTO_EXPOSURE est défini dans le champ flags de la structure FfxFsr2ContextDescription lors de la création du FfxFsr2Context . |
| Luminance actuelle | Cadre actuel | Render * 0.5 + mipchain | R16_FLOAT | Texture | Une texture à 50% de la texture de résolution de rendu qui contient la luminance du cadre actuel. Une chaîne MIP complète est allouée. |
L'étape de la pyramide de luminance de calcul est implémentée à l'aide de Passing Downs FidelityFX
