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.