Mais je ne sais pas si c'est le programmeur, le compilateur glsl/cuda/open cl > langage machine ou directement le matériel (probablement pas le matériel d’ailleurs) qui se charge de garder son pipeline bien remplit.
Pour moi, c'est le problème principal. On a vraiment l'habotude d'avoir le même genre de performance entre un modèle amd et un modèle Intel. C'est rare d'avoir un bench 50% plus rapide pour un processeur et 50% plus lent sur un autre bench.
Le compilateur opencl fait au mieux, mais selon les contraintes internes par rapport au code, les performances ne seront pas du tout les mêmes, ce qui demande un gros boulot d'optimisation pour les jeux. De mémoire, ati gère les flottant 16 bits et pas nvidia, sur un code qui n'a pas besoin de mieux, il sera 2x plus rapide qu'un code utilisant du 32 bits classique. C'est pareil, si le hardware interne gère des vecteurs de taille 2, sur une machine ayant une telle largeur, l'efficacité sera plus grande que sur un gpu scalaire.
Je sais qu'augmenter de manière énorme le nombre de registre augmente le temps de changement de tâche. Mais si il s'agit d'un banc de registres spécial, peut être que l'ancienne astuce, de sauver/restaurer le registre uniquement sur demande peut être appliqué.
Il faudrait un banc de registre par exemple 1 000 registres 256 bits. On pourrait faire des lecture mémoire de 256 à 8 bits, et ensuite faire des transferts de la taille que l'on veut vers les registres classiques. Si le core "out of order" est bien fait, il pourrait détecter ces transferts entre registres et seulement faire un "alias".
Avoir autant de registre peut permettre d'éviter un gros besoin de transfert vers la mémoire forcément plus lent que le cpu.
[^] # Re: Pas sûr qu'il y ai un remplacement
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 2.
Mais je ne sais pas si c'est le programmeur, le compilateur glsl/cuda/open cl > langage machine ou directement le matériel (probablement pas le matériel d’ailleurs) qui se charge de garder son pipeline bien remplit.
Pour moi, c'est le problème principal. On a vraiment l'habotude d'avoir le même genre de performance entre un modèle amd et un modèle Intel. C'est rare d'avoir un bench 50% plus rapide pour un processeur et 50% plus lent sur un autre bench.
Le compilateur opencl fait au mieux, mais selon les contraintes internes par rapport au code, les performances ne seront pas du tout les mêmes, ce qui demande un gros boulot d'optimisation pour les jeux. De mémoire, ati gère les flottant 16 bits et pas nvidia, sur un code qui n'a pas besoin de mieux, il sera 2x plus rapide qu'un code utilisant du 32 bits classique. C'est pareil, si le hardware interne gère des vecteurs de taille 2, sur une machine ayant une telle largeur, l'efficacité sera plus grande que sur un gpu scalaire.
Je sais qu'augmenter de manière énorme le nombre de registre augmente le temps de changement de tâche. Mais si il s'agit d'un banc de registres spécial, peut être que l'ancienne astuce, de sauver/restaurer le registre uniquement sur demande peut être appliqué.
Il faudrait un banc de registre par exemple 1 000 registres 256 bits. On pourrait faire des lecture mémoire de 256 à 8 bits, et ensuite faire des transferts de la taille que l'on veut vers les registres classiques. Si le core "out of order" est bien fait, il pourrait détecter ces transferts entre registres et seulement faire un "alias".
Avoir autant de registre peut permettre d'éviter un gros besoin de transfert vers la mémoire forcément plus lent que le cpu.
"La première sécurité est la liberté"