|
Sujet : Intéret des couleurs 64 bits ? |
| Rayaki |
bjone a écrit a écrit :
Enfin, quand on voit les 221 millions de transistors du McKinley à 1 Ghz, et les 60 millions des gf3/radeon 8500 à 300 mhz, y'a de la marge :D
disons que les cartes 3d dans 4/5 ans auront ces specs là, donc ya de quoi voir venir :ouch: :crazy:
|
=> tu enleves les caches L2 et L3, et tu vois qu'il reste pas grand chose... en plus, dans les GPU, il y a un nombre TRES importants de fonctions cablés... je serai curieux de voir les indics de perfs sur des calculs identiques entre un proc comme le mc Kinley et un gpu, mais à mon avis ça ne fait aucun doute... |
| bjone |
non, à mon avis y'a rien à changer dans le code....
que tu soit en opengl ou en direct3d, tu vois pas la différence entre une vielle carte pourrie qui fait du 16bits en interne et du 32 bits en interne...
si le 64bits est bien interne, soit idem on verra rien, et elle fera ses opérations en 64bits, même avec les vieux moteurs direct3d 3 :D, ou y'aura un flag à changer quelque part.
mais si y'a un flag, c'est que le 64bits sera un peu pénalisant en temps par rapport à un 32bits interne. si la carte est cablée et optimisée à mort pour le 64bits, y'a po de flag et elle sera alors tout le temps en 64 bits.
au pire les drivers offiront ptet une checkbox pour forcer le 64bits.
enfin si le 64bits sera bien un 64bits interne pour la couleur des pixel en ARGB....
un autre truc qui pourrait arriver, et ça irait de pair avec une haute précision interne (le 64 bits): re-répartir les 32bits de chaque pixel pour le framebuffer. sur les 32bits, seul 24 sont utilisés, avec 8 bits juste pour l'alignement bus/mémoire sur DWORD, mais il serait profitable de faire un mode de framebuffer en RGB genre 10:12:10 (plus de précision sur le vert, comme le 16bpp), et de ramener ce pixel en 8:8:8 pour le ramdac.
idem ça permetterai de réduire les défauts en cas de transparences cumulées.....
la carte pourrait traiter en interne en 64bits (16 bits par canal ARGB), réduire en 32 bits 10:12:10 dans le framebuffer, dans le cas de transparence (relecture en ram), remonter le 10:12:10 en 16:16:16:16 afin de faire le blending.
ça -pourrait- être interressant d'un point de vue qualité sans pénaliser la bande passante. le blem c qu'il faut donc faire une unité qui fasse le (16: )16:16:16 vers du 10:12:10 pour les pipelines->framebuffer, une unité 10:12:10 vers (16: )16:16:16 pour le framebuffer->pipelines, une unité 10:12:10 vers 8:8:8 pour le ramdac et pour les accès au framebuffer par le cpu.
enfin là ça de la spéculation puissance 2 car le 64bits interne, c po clairement annoncé, et ce genre de magouille encore pire donc... (mais ça pourrait venir un jour ou l'autre) [edtdd]--Message édité par bjone--[/edtdd] |
