Hum, je suis pas spécialiste du hardware alors je vais p'têt dire des conneries quant au nombre de thread optimum mais a priori, si tu es certain d'avoir 80 shader cores, c'est donc normalement le nombre de threads que tu peux utiliser.
De toute manière, dans un CS DX11 le nombre de threads par groupe est limité à 1024.
Tu peux les répartir comme tu veux selon les dimensions pour traiter ton problème, genre [16,16,4] ou [32, 32, 1] ou même [1024,1,1].
Dans ton cas [20,2,2], [80,1,1], etc.
Par contre, le nombre de groupe est libre ('fin, limité quand même à 65536) et c'est normal car ça correspond juste au nombre de fois où tu vas lancer ton groupe de threads pour voracement attaquer un bout de ton problème (en l'occurrence, ton buffer de particules)... Vois ça comme une découpage en tiles d'un buffer: la taille de tes tiles c'est les threads, le nombre de tiles (i.e. groupes) c'est la taille de ton buffer / nombre de threads...
L'intérêt principal d'un CS c'est surtout de faire collaborer les threads entre elles avec du groupsharedmemory et ce genre de trucs. Si tu veux simplement faire évoluer des particules sans qu'elles aient d'interaction entre elles alors il vaut mieux que tu fasses du pixel shader.
Ton tri, par contre, effectivement tu peux le faire en CS avec une routine maline genre tes threads lisent le Z de la particule dans un group shared memory, se sync entre elles, la moitié d'entre elles vont procéder à des inversions conditionnelles des Z 2 à 2, ensuite sync, ré-inversent les nouveaux groupes, etc.
Mais comme chuis nul en tri je peux pas trop t'aider, renseigne-toi sur le bitonic sort pour te faire une idée (et si t'as un code qui le fait, je suis preneur ! ^^)
