Les GPUs, et leurs unités de texture en hardware. Même Larrabee n’a pas pu s’en passer, Intel avait des performances désastreuses sans elles au début (voir le blog de TomF). On peut afficher des textures différemment, mais pas avec la même vitesse. Et pour certaines méthodes : pas avec le même contrôle par les artistes, ce qui n’est pas acceptable dans une production commerciale.
Mais de toute façon : Bresencham, c’est pour approximer le mieux possible une ligne (et étendu à un cercle) sur une grille de pixel. Pas pour afficher une texture.
Donc pour revenir au point de départ : non les moteurs 3D modernes n’utilisent pas Bresencham pour l’affichage de texture.
Le PDF :
Our approach in implementing the 3D-Bresenham algorithm is performed by line segmentation and procedure parallelization. The line is divided into equal-length segments using the ARM A9 Cortex or the processor system (PS) available on the Zynq chip followed by sending them to the FPGA located on the same chip.
Ce n’est pas vraiment Bresencham qui est parallélisé, mais le segment de ligne coupé en n sous-segments, chacun rendu par un core différent. Oui il y a parallélisation, mais ce n’est pas exactement la ligne qu’aurait afficher un seul calcul de Bresencham (car les erreurs pour savoir quand incrémenter sur X ou Y ou Z retombent à zéro à chaque début de sous-segment).
Les GPUs ne font pas de rendu itératif d’un pixel à l’autre, ou d’une ligne après une autre. Ils fonctionnent en exécutant un même pixel shader sur tous les pixels d’un quad, qu’ils soient couvert ou non par un triangle (chacun des shaders units utilisées dans ce quad détermine si le triangle le couvre, puis exécute le pixel shader dessus au besoin). Les PS ou CS tournent indépendamment les uns des autres, en parallèle.
On peut faire du rendu d’une autre façon en utilisant des compute shaders; et il y a déjà de la recherche pour afficher différemment la géométrie (les geometry textures de l’UE4 par ex, les SVO, les shaders générant de la géométrie par CSG, parcourant des SDF etc.) faudrait arrêter de prendre les dévs de moteur 3D pour des idiots. 
Mais pour encore une fois revenir au point de départ : non, pas de Bresenham dans les moteurs modernes 
Les deux sont souvent combinés : la rasterisation est bien plus rapide aujourd’hui pour calculer les premiers rayons (depuis la caméra).
Ça pourrait changer le jour où l’on aura une structure d’accélération de traversée de scène par les rayons plus rapide (ce qui permettrait aussi d’enlever les Z prepass et/ou les Gbuffers pour ceux qui les utilisent encore).
en effet
Beaucoup de dévs 3D du jeu vidéos viennent de la demoscene. Ou de la recherche universitaire dans ce domaine; ou des deux en même temps.
Mais c’est un monde qui tend à se spécialiser de plus en plus. Auparavant une personne pouvait écrire un moteur 3D entier tout seul (j’en ai écrit, rendu raster soft, raytracing temps-réel, puis utilisant un GPU, renderer de niveaux de Quake à Doom3, soft shadows sur les premières GeForce en 2003 etc.). De nos jours rien que l’éclairage physiquement réaliste ou les ombres demandent énormément de connaissance et R&D personnelle pour être au top.