Discussion :

[DjiZ]

Salut,
J'essaye d'uploader toutes les sub reources d'une texture 2D en usage "staging", non compressée R8G8B8A8.

Les premieres subresources marchent bien, mais pour le niveau de mipmap de 8x8 texels, la fonction Map() me renvoi un pitch de 64 octets, là où j'en attendrai 32 (ce que la documentation me confirme puisqu'ils disent que pour les formats non compressés le champs de sortie RowPitch est la width de la subresource).

Quelqu'un saurait m'expliquer ce qu'il se passe ?
ça m'empêche de setter correctement les data.
Merci.

[ac_wingless]

Un petit effort sur le langage? Merci!

Si Map renvoie 64, c'est que Map renvoie 64, même si on attend 32 ou 27: c'est à cela que sert la fonction, elle vous transmet ce que lui indique le pilote à propos de la largeur des lignes de votre sous ressource lorsque le GPU (et non le CPU) veut y accéder. Staging n'indique pas que la texture doit être privilégiée pour être facilement accessible par le CPU: après tout elle réside dans la carte après vos accès en écriture depuis le CPU, et donc le GPU a toute légitimité pour vous imposer une largeur de mot qui lui va bien. Ne faites pas de supposition à ce stade, peut-être que dans 5 ans l'alignement optimal sera 128 octets... ou pas.
Il faut donc toujours tenir compte de la valeur dynamique renvoyée par Map (il faut setter les data accordinguely pendant l'uplodage des sub reources ).

Petite astuce: lorsque c'est possible (c'est-à-dire si vous ne changez pas la texture trop souvent depuis le CPU), préférez faire une texture staging temporaire que vous recopiez par CopyResource dans une non-staging juste après son remplissage par le CPU, et que vous détruisez immédiatement après. De cette manière, vous gagnez on the two tableaux.

[DjiZ]

Merci pour la réponse tout d'abord.
Ensuite,

Petite astuce: lorsque c'est possible (c'est-à-dire si vous ne changez pas la texture trop souvent depuis le CPU), préférez faire une texture staging temporaire que vous recopiez par CopyResource dans une non-staging juste après son remplissage par le CPU, et que vous détruisez immédiatement après. De cette manière, vous gagnez on the two tableaux.

C'est justement ce que je cherche à faire. Je suis d'accord avec vous quand vous dîtes qu'il faut plus faire confiance à ce que renvoi l'API qu'à une quelconque présomption. En revanche j'en viens à la question : comment interpréter ce résultat correctement ?

Est-ce que je dois quand même uploader 8 lignes de 32 octets, en ne mettant rien dans les octets liés au padding (32 à 63) et donc en gérant correctement les offset pour chaque ligne ?

C'est ce que j'ai ténté au tout début mais en sortie une capture PIX me montre que mon niveau de mipmap est corrompu (la première moitié des pixels est bien là, l'autre moitié est noir).

Faire une copie directe de mon buffer de données d'origine (prévu pour un pitch de 32) ma paraitrait moins logique, mais peut-être me trompes-je ?

Merci d'avance.

PS : désolé si mon language vous a choqué outre mesure dans mon premier message, j'ai pas l'habitude de traduire tous les termes techniques ou qui font référence à une utilisation propre d'une API. Je vais faire plus attention.


EDIT : finalement mon implémentation fonctionnait bien, j'avais une erreur ailleurs dans mon code qui me donnait ces fameux pixels noirs.