2017-02-23 3 views
2

Après avoir lu et essayé d'appliquer le conseil de How to enable Hardware Percentage Closer Filtering? dans mon pixel shader, j'ai obtenu des résultats très étranges lors du débogage - en ce que tous les pixels avaient valeurs RVB très faibles bien que le shader ait renvoyé des valeurs RGB float4 plus élevées.HLSL: La couleur finale du pixel est différente de la valeur de retour calculée du pixel shader

Ce problème s'est manifesté uniquement lors de l'utilisation du matériel (GPU) et se comportait correctement lors de l'exécution de WARP (via le Panneau de configuration DirectX). Je pensais que c'était un problème de pilote, mais testé sur deux ordinateurs différents, l'un avec un GPU nVidia mobile, l'autre avec une carte AMD de bureau, et le comportement est le même avec les deux - cela fonctionne comme prévu avec WARP.

Vérifiez les captures d'écran de débogage du pixel shader suivant que je pense sont très instructifs au sujet de mon problème rencontré:

Débogage le pixel shader avec une course matérielle régulière: enter image description here

un coup d'oeil à la retournez la valeur - et à droite - dans le "Graphics Pixel History" sur les valeurs Pixel Shader RVB et les valeurs de résultats - pourquoi sont-ils si différents? Presque division par 3 facteur.

Maintenant, jetez un oeil à la mise au point - sur un pixel grisés similaires - lors de l'exécution du même shaders - seulement en utilisant maintenant WARP au lieu de courir sur le GPU: enter image description here

Comme vous pouvez le voir, les valeurs sont presque identiques - et je pense que les petites différences sont dues au fait que la cible de rendu est de 8 bits par canal alors que la float est de 4 octets (32 bits).

Ma version précédente du shader a été inspiré par ce billet de blog et des extraits et: https://takinginitiative.wordpress.com/2011/05/25/directx10-tutorial-10-shadow-mapping-part-2/

I mis en œuvre un PCF 16-tap - prendre 16 échantillons avec la fonction Sample au lieu d'utiliser la SampleCmpLevelZero func et de faire la comparaison avec la valeur cible moi-même, dans le shader - pour décider de la mesure dans laquelle le pixel doit être ombré. En lisant la question mentionnée ci-dessus - j'ai modifié mon shader pour utiliser SampleCmpLevelZero et c'est alors que mes problèmes sont apparus et que mes shaders se sont comportés comme prévu avec WARP. Est-ce que quelqu'un peut me donner une suggestion sur quoi d'autre vérifier pour déboguer davantage cette situation?

Répondre

1

Après avoir activé le débogage D3D Device - en suivant les instructions précieuses de here - je reçu le message suivant - et donc trouvé la cause de mon problème:

D3D11 ERROR: ID3D11DeviceContext::DrawIndexed: The Shader Resource View in slot 1 of the Pixel Shader unit is using the Format (R16_FLOAT). This format does not support 'SampleCmp' or 'SampleCmpLevelZero', at least one of which is being used on the Resource by the shader. This mismatch is invalid if the shader actually uses the view (e.g. it is not skipped due to shader code branching). [ EXECUTION ERROR #372: DEVICE_DRAW_RESOURCE_FORMAT_SAMPLE_C_UNSUPPORTED]

Cela a été reffering à ma texture de profondeur, pour que j'avais défini l'option DXGI_FORMAT_R16_FLOAT. Passer à DXGI_FORMAT_R32_FLOAT a corrigé le problème et m'a permis d'activer PCF via SampleCmpLevelZero. Je pense que la morale est qu'il est très utile d'activer le débogage des périphériques DirectX pour savoir si votre exécution est dans un état corrompu ou erroné.