J'ai un seul fragment shader qui effectue un traitement sur un imageBuffer en utilisant des opérations de chargement/stockage d'image. Je suis exclusivement préoccupé par le scénario suivant:GLSL cohérent imageBuffer access dans un scénario en un seul passage (fragment shader), en un seul passage
- J'ai un seul fragment shader (pas de considérations en plusieurs étapes (par exemple vertex puis fragment shaders), et pas de rendu multipass.)
- variables imageBuffer sont déclarées comme cohérentes. Exclusivement intéressé par les imagesBuffers cohérentes.
Pour rendre les choses parfaitement claires, mon scénario est le suivant:
// Source code of my sole and unique fragment shader:
coherent layout(1x32) uniform uimageBuffer data;
void main()
{
...
various calls to imageLoad(data, ..., ...);
...
various calls to imageStore(data, ..., ...);
...
}
J'ai largement regardé les spécifications
surtout ce très paragraphe:
"Utilisation de variables déclarées comme "cohérent" garantit que les résultats de magasins seront immédiatement visibles aux appels de shaders en utilisant des variables déclarées de façon similaire; L'appel MemoryBarrier doit veiller à ce que les magasins sont visibles à d'autres opérations «
Note: mon « données imageBuffer uniforme cohérente; » déclaration est précisément une « variable de la même déclarée » Mon scénario est une seule passe.. ., une seule étape (fragment shader)
maintenant, je l'ai regardé divers sites Web et trébuché (comme la plupart des gens, je pense) sur ce fil sur stackoverflow.com:
et plus sp ecifically, ce paragraphe:
« Votre shader ne peut même pas faire l'hypothèse que l'émission d'une charge juste après un magasin aura la mémoire qui vient d'être stockée dans ce très shader (oui vraiment. Vous devez mettre un memoryBarrier pour tirer que l'on off) «
Ma question est la suivante:.
Avec le qualificatif cohérent spécifié, dans mon unique shaders, un seul passage scénario de traitement, Est-ce que je peux oui ou non être sûr que imageStore() sera immédiatement visible à TOUTES les invocations de mon fragment shader (par exemple l'invocation actuelle ainsi que d'autres invocations concurrentes)?
En lisant la spécification ARB_shader_image_load_store, il semble que à moi que:
- la réponse à cette question est oui,
- Je ne ai pas besoin de tout type de memoryBarrier(),
- la phrase citée dans le fil mentionné ci-dessus dans stackoverflow peut en effet induire en erreur et le mal.
Merci de votre compréhension.
Vous êtes dans des casse-tête majeurs si vous n'utilisez pas de barrière de mémoire dans ce shader *** qui les charge et les stocke ensuite. Vous pourriez *** être en mesure de retirer cela en toute sécurité si votre tirage ne donne qu'un seul fragment. Mais pour tout ce qui est plus important, vous avez besoin d'une synchronisation entre les invocations simultanées de shader de fragments, sinon les autres peuvent se charger avant les autres. Les shaders de fragmentation peuvent être planifiés dans n'importe quel ordre que le conducteur pense produire des résultats sensés, imageLoad/Store est effectivement ignoré à cet égard parce qu'il est supposé que vous savez ce que vous faites. –
@ AndonM.Coleman vous ne répondez pas à ma question. Cette question est: ** Est-ce que je peux oui ou non être sûr que imageStore() sera immédiatement visible pour TOUTES les invocations de mon fragment shader (par exemple l'invocation actuelle ainsi que d'autres invocations simultanées)? ** En d'autres termes, sont chargés/stockés sur des variables cohérentes et déclarées de façon similaire dans une étape de shader UNIQUE ** garantie ** à exécuter dans l'ordre? La spécification semble dire oui, certains membres du forum disent non. Vous venez de mentionner des problèmes généraux avec la programmation simultanée. Je sais que je n'ai aucun contrôle sur la programmation des invocations de shaders. – fred54
C'est votre question, alors non. –