La localité de référence du GPU mérite-t-elle d'être inquiétée?

La localité de référence fait-elle autant de différence pour les performances du GPU que pour les performances du CPU?

Par exemple, si j'envoie 200 commandes de dessin au GPU, verrai-je une différence (potentiellement) notable si les données de chaque commande sont contiguës en mémoire au lieu de sauter dans les tampons / textures?

Question secondaire: je suppose que le GPU garantit contre les faux problèmes de partage en ayant la plupart des ressources immuables. Mais dans le cas où ils ne le sont pas, est-ce pour cela que les threads font toujours quatre fragments de travail?

La localité de référence est importante, mais vous n'avez pas à vous inquiéter autant ... parce que vous n'avez pas de contrôle absolu.

Lorsque vous utilisez OpenGL / DirectX, vous avez généralement un contrôle limité sur la disposition de la mémoire, le pilote fera le reste. Par exemple, vous pouvez essayer plusieurs dispositions de tampons de vertex, telles que l'utilisation de données de vertex entrelacées ou non entrelacées et en fonction de vos données / pilote / performances GPU varient. Profil et choisissez ce qui convient le mieux à votre application.

Par exemple, dans l' optimisation de GPU Gems Pipeline, la localité de référence est mentionnée deux fois , la première:

Accédez aux données de sommet d'une manière relativement séquentielle. Les GPU modernes mettent en cache les accès à la mémoire lors de la récupération des sommets. Comme dans toute hiérarchie de mémoire, la localité de référence spatiale permet de maximiser les accès dans le cache, réduisant ainsi les besoins en bande passante.

Et le deuxième

Optimiser pour le cache de vertex post-T & L. Les GPU modernes ont un petit cache premier entré, premier sorti (FIFO) qui stocke le résultat des sommets les plus récemment transformés; un hit dans ce cache enregistre tous les travaux de transformation et d'éclairage, ainsi que tous les travaux effectués plus tôt dans le pipeline. Pour tirer parti de ce cache, vous devez utiliser des primitives indexées et vous devez ordonner vos sommets pour maximiser la localité de référence sur le maillage. Il existe des outils disponibles, notamment D3DX et NVTriStrip (NVIDIA 2003), qui peuvent vous aider dans cette tâche.

À mon avis, ces recommandations suivent ce dont je parle et impliquent que vous n'avez pas un contrôle absolu sur la disposition de la mémoire, mais ce que vous avez sur, par exemple la façon dont chaque sommet VBO est disposé peut avoir un effet sur les performances.

Si votre application a un impact sur les performances, vous devez d'abord détecter le goulot d'étranglement, il ne s'agit peut-être pas d'un problème de localité de référence des données, mais cela peut être dû au fait qu'il y a énormément de données sans élimination, par exemple, vous n'effectuez pas d'élimination de troncs. etc Vous pouvez vérifier ma réponse ici sur le sujet.

Je pense que vous devriez vous soucier davantage de la localité de référence lorsque vous utilisez OpenCL / CUDA si vous avez souvent un contrôle absolu sur la disposition de la mémoire.

À l'origine, les GPU n'étaient utilisés que pour des applications multimédias qui montrent peu de réutilisation des données. Alors que les GPU sont de plus en plus utilisés pour des applications générales (d'où le terme GPGPU), ils proposent désormais des caches gérés par le matériel de grande taille, par exemple, le GPU Fermi a 768 Ko de cache de dernier niveau, le GPU Kepler a 1536 Ko de cache de dernier niveau et le GPU Maxwell dispose de 2048 Ko de cache de dernier niveau. Ceci, ainsi qu'un grand nombre de recherches sur les caches de GPU, montrent que la localisation des données est certainement importante pour les GPU. Voir mon document d'enquête pour plus de détails et référence pour ce qui précède.