Flow Limitations des contrôles
Les instructions de contrôle de workflow de nuanceur de pixels ont des limites affectant le nombre de niveaux d’imbrication pouvant être inclus dans les instructions. En outre, il existe certaines limitations relatives à l’implémentation du contrôle de Flow par pixel avec des instructions de dégradé.
Notes
Lorsque vous utilisez les * _ _ _ _ _ profils de nuanceur HLSL de 4 niveaux 9 x, vous utilisez implicitement les profils Shader Model 2. x pour prendre en charge le matériel compatible Direct3D 9. Les profils Shader Model 2. x prennent en charge un comportement de contrôle de Flow plus limité que le modèle de nuanceur 4. x et versions ultérieures.
- Nombre de niveaux de profondeur des instructions de nuanceur de pixels
- Interaction d' Per-Pixel contrôle de Flow avec des dégradés d’écran
Nombre de niveaux de profondeur des instructions de nuanceur de pixels
PS _ 2 _ 0 ne prend pas en charge le contrôle de Flow. Les limitations pour les autres versions de nuanceur de pixels sont répertoriées ci-dessous.
Nombre de profondeur d’instruction pour PS _ 2 _ x
Chaque instruction compte sur une ou plusieurs limites de profondeur d’imbrication. Le tableau suivant répertorie le nombre de profondeur que chaque instruction ajoute ou soustrait de la profondeur existante.
| Instruction | Imbrication statique | Imbrication dynamique | imbrication de boucles/REP | appeler l’imbrication |
|---|---|---|---|---|
| Si bool-PS | 1 | 0 | 0 | 0 |
| Si _ COMP-PS | 0 | 1 | 0 | 0 |
| Si prédit-PS | 0 | 1 | 0 | 0 |
| else-PS | 0 | 0 | 0 | 0 |
| endif-PS | -1 (si bool-PS) | -1 (si prédit-PS ou si _ COMP-PS) | 0 | 0 |
| REP-PS | 0 | 0 | 1 | 0 |
| endrep-PS | 0 | 0 | -1 | 0 |
| Break-PS | 0 | 0 | 0 | 0 |
| arrêter _ COMP-PS | 0 | 1,-1 | 0 | 0 |
| breakp-PS | 0 | 0 | 0 | 0 |
| appeler-PS | 0 | 0 | 0 | 1 |
| callnz bool-PS | 0 | 0 | 0 | 1 |
| callnz prédit-PS | 0 | 1 | 0 | 1 |
| RET-PS | 0 | -1 (callnz prédit-PS) | 0 | -1 |
| SETP _ COMP-PS | 0 | 0 | 0 | 0 |
Profondeur d’imbrication
Profondeur d’imbrication définit le nombre d’instructions qui peuvent être appelées à l’intérieur les unes des autres. Chaque type d’instruction a une ou plusieurs limites d’imbrication comme indiqué dans le tableau suivant.
| Type d’instruction | Maximale |
|---|---|
| Imbrication statique | 24 si (D3DCAPS9. D3DPSHADERCAPS2 _ 0. StaticFlowControlDepth > 0); 0 sinon |
| Imbrication dynamique | de 0 à 24, consultez D3DCAPS9. D3DPSHADERCAPS2 _ 0. DynamicFlowControlDepth |
| imbrication des REP | de 0 à 4, consultez D3DCAPS9. D3DPSHADERCAPS2 _ 0. StaticFlowControlDepth |
| appeler l’imbrication | de 0 à 4, consultez D3DCAPS9. D3DPSHADERCAPS2 _ 0. StaticFlowControlDepth (indépendant de la limite du REP) |
Nombre de profondeur d’instruction pour les _ logiciels PS 2 _
Chaque instruction compte sur une ou plusieurs limites de profondeur d’imbrication. Ce tableau indique le nombre de profondeur que chaque instruction ajoute ou soustrait de la profondeur existante.
| Instruction | Imbrication statique | Imbrication dynamique | imbrication de boucles/REP | appeler l’imbrication |
|---|---|---|---|---|
| Si bool-PS | 1 | 0 | 0 | 0 |
| Si prédit-PS | 0 | 1 | 0 | 0 |
| Si _ COMP-PS | 0 | 1 | 0 | 0 |
| else-PS | 0 | 0 | 0 | 0 |
| endif-PS | -1 (si bool-PS) | -1 (si prédit-PS ou si _ COMP-PS) | 0 | 0 |
| REP-PS | 0 | 0 | 1 | 0 |
| endrep-PS | 0 | 0 | -1 | 0 |
| boucle-PS | n/a | n/a | n/a | n/a |
| ENDLOOP-PS | n/a | n/a | n/a | n/a |
| Break-PS | 0 | 0 | 0 | 0 |
| arrêter _ COMP-PS | 0 | 1,-1 | 0 | 0 |
| breakp-PS | 0 | 0 | 0 | 0 |
| appeler-PS | 0 | 0 | 0 | 1 |
| callnz bool-PS | 0 | 0 | 0 | 1 |
| callnz prédit-PS | 0 | 1 | 0 | 1 |
| RET-PS | 0 | -1 (callnz prédit-PS) | 0 | -1 |
| SETP _ COMP-PS | 0 | 0 | 0 | 0 |
Profondeur d’imbrication
Profondeur d’imbrication définit le nombre d’instructions qui peuvent être appelées de l’une à l’autre. Chaque type d’instruction a une ou plusieurs limites d’imbrication comme indiqué dans le tableau suivant.
| Type d’instruction | Maximale |
|---|---|
| Imbrication statique | 24 |
| Imbrication dynamique | 24 |
| imbrication des REP | 4 |
| appeler l’imbrication | 4 |
Nombre de profondeur d’instruction pour PS _ 3 _ 0
Chaque instruction compte sur une ou plusieurs limites de profondeur d’imbrication. Ce tableau indique le nombre de profondeur que chaque instruction ajoute ou soustrait de la profondeur existante.
| Instruction | Imbrication statique | Imbrication dynamique | imbrication de boucles/REP | appeler l’imbrication |
|---|---|---|---|---|
| Si bool-PS | 1 | 0 | 0 | 0 |
| Si prédit-PS | 0 | 1 | 0 | 0 |
| Si _ COMP-PS | 0 | 1 | 0 | 0 |
| else-PS | 0 | 0 | 0 | 0 |
| endif-PS | -1 (si bool-PS) | -1 (si prédit-PS ou si _ COMP-PS) | 0 | 0 |
| REP-PS | 0 | 0 | 1 | 0 |
| endrep-PS | 0 | 0 | -1 | 0 |
| boucle-PS | 0 | 0 | 1 | 0 |
| ENDLOOP-PS | 0 | 0 | -1 | 0 |
| Break-PS | 0 | 0 | 0 | 0 |
| arrêter _ COMP-PS | 0 | 1,-1 | 0 | 0 |
| breakp-PS | 0 | 0 | 0 | 0 |
| appeler-PS | 0 | 0 | 0 | 1 |
| callnz bool-PS | 0 | 0 | 0 | 1 |
| callnz prédit-PS | 0 | 1 | 0 | 1 |
| RET-PS | 0 | -1 (callnz prédit-PS) | 0 | -1 |
| SETP _ COMP-PS | 0 | 0 | 0 | 0 |
Profondeur d’imbrication
Profondeur d’imbrication définit le nombre d’instructions qui peuvent être appelées de l’une à l’autre. Chaque type d’instruction a une ou plusieurs limites d’imbrication comme indiqué dans le tableau suivant.
| Type d’instruction | Maximale |
|---|---|
| Imbrication statique | 24 |
| Imbrication dynamique | 24 |
| imbrication de boucles/REP | 4 |
| appeler l’imbrication | 4 |
Nombre de profondeur d’instruction pour les _ logiciels PS 3 _
Chaque instruction compte sur une ou plusieurs limites de profondeur d’imbrication. Ce tableau indique le nombre de profondeur que chaque instruction ajoute ou soustrait de la profondeur existante.
| Instruction | Imbrication statique | Imbrication dynamique | imbrication de boucles/REP | appeler l’imbrication |
|---|---|---|---|---|
| Si bool-PS | 1 | 0 | 0 | 0 |
| Si prédit-PS | 0 | 1 | 0 | 0 |
| Si _ COMP-PS | 0 | 1 | 0 | 0 |
| else-PS | 0 | 0 | 0 | 0 |
| endif-PS | -1 (si bool-PS) | -1 (si prédit-PS ou si _ COMP-PS) | 0 | 0 |
| REP-PS | 0 | 0 | 1 | 0 |
| endrep-PS | 0 | 0 | -1 | 0 |
| boucle-PS | 0 | 0 | 1 | 0 |
| ENDLOOP-PS | 0 | 0 | -1 | 0 |
| Break-PS | 0 | 0 | 0 | 0 |
| arrêter _ COMP-PS | 0 | 1,-1 | 0 | 0 |
| breakp-PS | 0 | 0 | 0 | 0 |
| appeler-PS | 0 | 0 | 0 | 1 |
| callnz bool-PS | 0 | 0 | 0 | 1 |
| callnz prédit-PS | 0 | 1 | 0 | 1 |
| RET-PS | 0 | -1 (callnz prédit-PS) | 0 | -1 |
| SETP _ COMP-PS | 0 | 0 | 0 | 0 |
Profondeur d’imbrication
Profondeur d’imbrication définit le nombre d’instructions qui peuvent être appelées de l’une à l’autre. Chaque type d’instruction a une ou plusieurs limites d’imbrication comme indiqué dans le tableau suivant.
| Type d’instruction | Maximale |
|---|---|
| Imbrication statique | 24 |
| Imbrication dynamique | 24 |
| imbrication de boucles/REP | 4 |
| appeler l’imbrication | 4 |
Interaction d' Per-Pixel contrôle de Flow avec des dégradés d’écran
Le jeu d’instructions de nuanceur de pixels comprend plusieurs instructions qui produisent ou utilisent des dégradés de quantités par rapport à l’espace d’écran x et y. L’utilisation la plus courante pour les dégradés consiste à calculer les calculs de niveau de détail pour l’échantillonnage de texture et, dans le cas du filtrage anisotrope, à sélectionner des échantillons le long de l’axe de l’anisotropie. En règle générale, les implémentations matérielles exécutent le nuanceur de pixels simultanément sur plusieurs pixels (par exemple, une grille 2x2), de sorte que les dégradés de quantités calculées dans le nuanceur peuvent être raisonnablement approchés comme des deltas des valeurs au même point d’exécution, en pixels adjacents.
Lorsque le contrôle de Flow est présent dans un nuanceur, le résultat d’un calcul de dégradé demandé dans un chemin de branche donné est ambigu quand des pixels adjacents peuvent exécuter des chemins de contrôle de Flow distincts. Par conséquent, il est jugé illégal d’utiliser toute opération de nuanceur de pixels qui demande un calcul de dégradé à un emplacement qui se trouve à l’intérieur d’une construction de contrôle de Flow qui peut varier d’un pixel à l’autre, pour une primitive donnée en cours de pixellisation.
Toutes les instructions de nuanceur de pixels sont partitionnées dans les opérations autorisées et dans celles qui ne sont pas autorisées à l’intérieur d’un contrôle de flow :
Scénario A : opérations qui ne sont pas autorisées dans un contrôle de Flow qui peut varier entre les pixels d’une primitive. Celles-ci incluent les opérations indiquées dans le tableau suivant.
Instruction est autorisé dans Flow contrôle lorsque : texld-PS _ 2 _ 0 et up, texldb-PS et texldp-PS Un registre temporaire est utilisé pour la coordonnée de texture. DSX-PS et DSY-PS Un registre temporaire est utilisé pour l’opérande. Scénario B : opérations autorisées n’importe où. Celles-ci incluent les opérations indiquées dans le tableau suivant.
Instruction Est autorisé n’importe où lorsque : texld-PS _ 2 _ 0 et up, texldb-PS et texldp-PS Une quantité en lecture seule est utilisée pour la coordonnée de texture (peut varier selon le pixel, par exemple les coordonnées de texture interpolée). DSX-PS et DSY-PS Une quantité en lecture seule est utilisée pour l’opérande d’entrée (peut varier par pixel, par exemple les coordonnées de texture interpolée). texldl-PS L’utilisateur fournit un niveau de détail comme argument, il n’y a donc pas de dégradés et donc aucun problème avec le contrôle de Flow. texldd-PS L’utilisateur fournit des dégradés comme arguments d’entrée, ce qui signifie qu’il n’y a aucun problème avec le contrôle de Flow.
Ces restrictions sont strictement appliquées dans la validation du nuanceur. Les scénarios avec une condition de branche qui ressemble à une branche est cohérente dans une primitive, bien qu’un opérande dans l’expression de condition soit une quantité calculée par nuanceur de pixels, mais toujours dans le scénario A et ne sont pas autorisés. De même, les scénarios dans lesquels des dégradés sont demandés sur certaines quantités calculées par le nuanceur x à partir de l’intérieur du contrôle de transit dynamique, mais qui semblent que x n’est pas modifié dans l’une des branches, continuent de tomber dans le scénario A et ne sont pas autorisés.
Le prédicat est inclus dans ces restrictions sur le contrôle de Flow, afin que les implémentations restent libres d’échanger de manière triviale l’implémentation des instructions de branche avec des instructions prédicats.
L’utilisateur peut utiliser les instructions des scénarios A et B ensemble. Supposons, par exemple, que l’utilisateur a besoin d’un échantillon de texture anisotrope en fonction d’une coordonnée de texture calculée de nuanceur. Toutefois, la charge de texture n’est nécessaire que pour les pixels répondant à une condition par pixel. Pour répondre à ces exigences, l’utilisateur peut calculer la coordonnée de texture pour tous les pixels, en dehors du contrôle de déroulement par pixel variable, en calculant immédiatement les dégradés à l’aide des instructions DSX-PS et DSY-PS . Ensuite, dans un pixel par pixel si bool-PS / endif-PS Block, l’utilisateur peut utiliser texldd-PS (charge de texture avec des dégradés fournis par l’utilisateur), en passant les dégradés précalculés. Une autre façon de décrire ce modèle d’utilisation est que, tandis que tous les pixels de la primitive devaient calculer les coordonnées de la texture et être impliqués dans le calcul du dégradé, seuls les pixels nécessaires à l’échantillonnage d’une texture ont fait cela.
Indépendamment de ces règles, la charge est toujours sur l’utilisateur pour s’assurer qu’avant de calculer un dégradé (ou d’effectuer un exemple de texture qui calcule implicitement un dégradé), le registre contenant les données sources doit avoir été initialisé pour tous les chemins d’exécution au préalable. L’initialisation des registres temporaires n’est pas validée ou appliquée en général.