Je pense que le bus AGP n'est pas pertinent. A moins d'avoir une pénurie de RAM sur la carte vidéo, ou une carte vidéo sans RAM, beaucoup de jeux en 3D et en particulier les anciens sont capables de stocker l'intégralité des textures nécessaires dans la RAM vidéo.
Si on part de l'hypothèse que toutes les textures sont déjà dans la carte vidéo, le fait de travailler en 16 bits joue:
- Sur la RAM vidéo occupée par les textures
- Sur la RAM occupée par le buffer de rendu
- Sur la bande passante occupée par les lectures de texture
- Sur la bande passante occupée par les écritures dans le buffer
- Sur la bande passante occupée par les lectures du RAMDAC
A moins que les cartes, pour une raison de simplification, fasse une conversion transparente 16bits -> 32bits, on peut donc effectivement s'attendre à une grosse amélioration de vitesse de rendu pour les scènes ayant un lourd rendu en textures.
Pour ce qui est de la complexité, en particulier le nombre de polygones, je pense que ça ne change pas grand chose aux calculs qui doivent être fait, et donc à la vitesse de rendu.
[^] # Re: Euh...
Posté par Sébastien Koechlin . En réponse au journal Pilote propriétaire ATI : pas de mode 16 bits!. Évalué à 2.
Si on part de l'hypothèse que toutes les textures sont déjà dans la carte vidéo, le fait de travailler en 16 bits joue:
- Sur la RAM vidéo occupée par les textures
- Sur la RAM occupée par le buffer de rendu
- Sur la bande passante occupée par les lectures de texture
- Sur la bande passante occupée par les écritures dans le buffer
- Sur la bande passante occupée par les lectures du RAMDAC
A moins que les cartes, pour une raison de simplification, fasse une conversion transparente 16bits -> 32bits, on peut donc effectivement s'attendre à une grosse amélioration de vitesse de rendu pour les scènes ayant un lourd rendu en textures.
Pour ce qui est de la complexité, en particulier le nombre de polygones, je pense que ça ne change pas grand chose aux calculs qui doivent être fait, et donc à la vitesse de rendu.