Reprise du message précédent :
non, parceque ça paraitrait être incohérent vis à vis des unités de filtrage bili-trilinéaire....
 
pourquoi ? parceque tu as une un texture normale+une texture pour l'embm ou une autre texture d'effet, ce sont les opérateurs interne qui interprêtent les A,R,G,B, soit comme couleur R,V,B, ou tables de normales pour le dot3 ou l'embm etc etc....
 
avoir 2 textures de chaqune 1 ensemble ARGB, ou 1 texture de 2 ensembles ARGB (même si le deuxième ARGB est interprété différement par les opérateurs), ça ne change rien à rien, c même négatif pour l'étage de filtrage en amont des opérateurs, pour faire le filtrage des deux ensembles, les 2 unités devront atteindre la même ligne de cache à texture...
 
en plus MoggBomber, toi t'y verrais un avantage pratique en tant que graphiste, mais rien n'empêche de faire softs de dessin, ou tu aies l'impression que tout est réuni, et qu'ensuite ce soit éclaté... (même dans le même fichier)
 
moggbomber>> la texture normale ARGB ou la texture avec le spec..., ce sont les opérateurs qui vont faire la différence, mais en amont la carte elle s'en fout...
 
enfin ça me parait plus cohérent de monter la précision temporaire, que chercher à regrouper deux textures 32 bits ensemble.... ce qui revient à pas grand chose de nouveau...

En tout cas l'ami CARMACK ils nous prépare 2 putain de bombes là.... nos "super" PC et bah,  ils vont bien ramer, je le sent, DOOM 3 et QUAKE 4, y'a eu très peu d'infos, mais putain, la surprise va etre de taille....
vivement les GeForce 6 et les RADEON 9900 !!!  
Pleuront    tous ensemble avec nos misérables  1 et 2 GHZ... car le père CARMACK, quand il sort un jeu, faut 2 ans avant de le voir tourner dans de vraiment bonnes conditions !!!                

bin c po grave, ma geforce 3 me rapellera ma voodoo2 avec quake 3
 
en 640x480/800x600 ça sera super bien jouable

Putain moi avec ma GeForce 2 Ultra je sort les rames là....    
En tout cas j'éspère que Quake 4 sera aussi jouable que Quake 3, car niveau jouabilité y'a pas photo, c'est le meilleur !!!
Que cela n'en déplaise aux fans de UT ou CS, je m'en branle, c'est la vérité !!! Trop fluide ce moteur, et trop paramétrable ce jeu !!!  

mareek a écrit a écrit : On parle de plus en plus de couleurs 64 bits pour les futures cartes graphique (281 474 976 710 656 nuances de couleurs + 65 536 niveaux de transparence quand même  ). Je me demande à quoi ça servira si ce n'est à bouffer du temps de calcul pour le GPU et de la bande passante mémoire ? Déjà que la différence entre le 16 et le 32 bits n'est pas flagrante (excepté au niveau des dégradés évidemment), je suis dubitatif quand à l'interet des couleurs 64 bits alors que notre oeuil ne peut distinguer que quelques millions de nuances. Est-ce que quelqu'un peux m'expliquer ( autrement que par "Tu déconne, c'est 'achement plus beau !" ) l'interet des couleurs 64 bits ?   merci d'avance pour vos réponses et réactions.

 
Entre un dégradé de couleurs affiché en 16bits et le mêmes en 32bits tu voit pas que c'est flagrant ???

Quake 4 est censé être plus comme Quake 2, avec une partie solo sympa....
 
Ceci dit, les choses risquent d'évoluer....

 
tu le dis toi meme "une dégradé" en dehors de ca ??
et bon a par le ciel y en a bcp de dégradés dans un jeu.
c vrai que y a une difference bien sur mais est ce vraiment souvent utile ? nvidia a decidé de ne plus supporter le 16bits alors que sur une vielle voodoo3 par exemple la qauilité d'affichage reste tres bonne.
mais c que mon avis

 
si y manque un '?', oui il y en a beaucoup des dégradés dans un jeu, il n'y a même que ça.
 
la carte 3d passe son temps à faire des interpolations, des multiplications, des additions de valeurs interpolées...
les flitrages bilinéaire/trilinéaire/anisotropique, c'est que de l'interpolation.... donc dégradé.
 
INTERPOLATION = DEGRADE
 
donc plus les interpolations sont précises, moins y'a de bruit.
 
nvidia supporte toujours le 16bits, là je vois pas ?
 
les seuls défaults "flagrants" qu'ont les nvidias ACTUELLEMENT, c'est la décompression du S3TC (DXTC) mode 1 qui est faite en 16 bits alors que les radeons le font en 32 bits, ce qui explique pourquoi les textures S3TC sont meilleures sur radeon, et la sortie du RAMDAC qui pourrait être meilleure d'un point de vue signal analogique.
et ensuite quelques restrictions au niveau des interpolations qui sont visibles lors des resize de flux vidéo (divX) d'après ce que avais dit slyde, les geforces interpolent sur un multiple de je sais plus quelle résolution...

[edtdd]--Message édité par bjone--[/edtdd]

 
je suis d'accord avec toi en fait. c sur que c pas vraiment utile pour un graphiste. et puis meme on pourrait penser a un format de fichier regroupant ces textures et le moteur de jeu (ou meme driver) séparant les couches suivant ses besoins
 
par contre pour ameliorer la qualité d'affichage je pense que passer en 64 bit est une perte de puissance inutile. je crois qu'un meilleur design de la carte dans son affichage serait plus utile. a quoi ca sert de calculer en 64bits si c pour tout degueulasser a l'affichage ? je sais bien que c meilleur pour les rendus dans les hautes et basses couleurs (comme lightwave qui calcule en 128bits et downsample apres) c vrai l'image est meilleure mais c tres subtile au point d'etre subjectif meme !
 
en fait pour moi ca reste une perte de ressource importante alors que ca serait mieux de doubler les polygones ou les effets !! ou ajouter des voxels ou des lumieres vraiment en hard.
je pense pas que le 64bits rendra un jeu plus beau. c avant tout un histoire de direction artiste et bon la heu quake3
pour moi le plus important dans un jeu c de s'amuser et pas de tapper les fps
certains devraient s'en rappeler un peu plus !! hein john ??!

A quoi tu le vois ca ?
Moi je vois pas de difference entre ma g400 max que j' avais et ma geforce 2 gts que j' ai maintenant ..

bin c cool, enfin quelqun qui crache pas sur nvdia pour ça
tu sais t'es le premier à dire ça

MoggBomber a écrit a écrit :     je suis d'accord avec toi en fait. c sur que c pas vraiment utile pour un graphiste. et puis meme on pourrait penser a un format de fichier regroupant ces textures et le moteur de jeu (ou meme driver) séparant les couches suivant ses besoins   par contre pour ameliorer la qualité d'affichage je pense que passer en 64 bit est une perte de puissance inutile. je crois qu'un meilleur design de la carte dans son affichage serait plus utile. a quoi ca sert de calculer en 64bits si c pour tout degueulasser a l'affichage ? je sais bien que c meilleur pour les rendus dans les hautes et basses couleurs (comme lightwave qui calcule en 128bits et downsample apres) c vrai l'image est meilleure mais c tres subtile au point d'etre subjectif meme !   en fait pour moi ca reste une perte de ressource importante alors que ca serait mieux de doubler les polygones ou les effets !! ou ajouter des voxels ou des lumieres vraiment en hard. je pense pas que le 64bits rendra un jeu plus beau. c avant tout un histoire de direction artiste et bon la heu quake3 pour moi le plus important dans un jeu c de s'amuser et pas de tapper les fps certains devraient s'en rappeler un peu plus !! hein john ??!

 
bin les gouts et le couleurs....
 
en fait je pense que le 64 bits (16bits par canal ARGB) peut devenir très interressant à cause tout simplement des pixels shaders qui permettent et permetteront au fûr et à mesure de leur évolution, d'enchainer des effets chelous, sans pour autant utiliser beaucoup de textures, tu peux très bien calculer des constantes (interpolées le long du triangle) au niveau des vertexs shaders, qui sont ensuite utilisés par les pixels shaders pour perturber les textures.... (enfin contrôller les opérateurs...)
 
donc qui dit cumul de perturbations volontaires, dit cumul de distortions/bruit non désiré...
 
carmack a l'habitude de savoir ce qu'il veut et pourquoi il le veut (il fait toujours des simulations en software pour savoir ce qui est rentable graphiquement), et je doutes que microsoft et l'industrie de la 3d temps-réel ayent accepter de supporter un mode 64 bits dans un futur proche uniquement pour lui faire plaisir.
 
ça devrait permettre, je pense, de faire des pixels shaders plus subtiles....
 
par exemple on sait que la bande-passante mémoire bride les perfs de la carte (en fill-rate et en nombre et qualité de texture), mais un mode 64 bits interne(16 bits par canal), ne prendra que des transistors interne pas de bande-passante.
 
ça permetera par exemple de faire évoluer des matrices (4 constantes ARGB...) par pixel (genre faire du 16 bits flottant ou entier suivant les besoins), avec genre une texture dont le R,G,B seront interprété comme un vecteur.... etc... etc... (c que fait déjà l'embm)
 
enfin je pense que si on passe de 8bits à 16bits par canal, on doit pouvoir commencer à imaginer des opérateurs chelous et rigolos pour faire des effets rigolos...
 
les cartes 3d n'ont pas trop de mal (enfin un peu quand même ), à monter en nombre de transistors, donc le passage du 8 bits au 16 bits par canal devrait être praticable (enfin certains opérateurs, dont les multiplications vont devenir moins triviales, because tables de précalcul ou autre astuces... heu ça devrait grossir, les additions/subs y'a rien de spécial à faire)
 
enfin wait & see...
 
l'avenir semble assez drôle

[edtdd]--Message édité par bjone--[/edtdd]

Je vais dire une connerie mais:
est-ce qu'ont peut imaginer coder les propiétés lumineuses (en plus de la transparence) directement sur les textures (réflexion, émittence, etc...). Si j'ai tout compris pour le moment c'est géré au niveau des vertex (donc de façon ponctuelle) puis lisser suivant différentes méthodes.
 
Est-ce que 64bits ne pourrait pas offrir un moyen d'avoir une meilleur gestion texture/lumière....

la lumière est actuellement symbolisée apr un vecteur normal sortant du centre du polygone traité...
 
Ca aurai aucun intéret de l'intégrer a la texture : vu que la texture se tords suivant la surface ou elle est appliquée, cette donnée change tout le temps.

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
disons que les cartes 3d dans 4/5 ans auront ces specs là, donc ya de quoi voir venir

 
non, ça c'est du flat shading.
le gouraud, c du calcul par vertex.
 
l'emboss bump-mapping, le DOT3 bump-mapping, et l'environnemental bump-mapping utilisent des textures décrivant le relief de la texture ...
 
c avec ce genre d'opérateurs que la précision peut s'avérer utile..
 
un ptit lien que legreg m'avait sorti:
 
http://developer.nvidia.com/docs/I [...] ghting.pdf

c a la page 30 que l'on trouve des choses interressantes...
 
enfin pour ceux qui ont déjà regardé le sdk du dx8 / 8.1, et qui ont zieuté l'exemple du dot3 et de l'embm, y voyent ce que peut être comme l'avantage d'avoir 16 bits par canal temporairement (enfin si on veut faire des magouilles )

[edtdd]--Message édité par bjone--[/edtdd]

 
je suis d'accord mais sur un "degradé" d'environ 8 pixels on va dire (genre texture de béton sur un mur) dis moi comment tu vas placer tes 256 niveaux de degradés ?! hein ?
 
pour le 16 bits des geforce bien sur il existe mais les drivers le gèrent de moins moins bien. c surtout le bleme du zbuffer mais c clair ils en ont plus rien foutre. ils optimisent quake3 en haute resolution et 32bits pour tapper les bench c tout.

 
ben ca peut deprendre de ton ecran aussi.
je sais que ma Geforce256 avait bien du mal a pas devenir floue en 1280x1024 a 100hrz
mais je suis d'accord que pour du jeu c pas important en fait. comme ca bouge tout le temps on va pas detailler son écran non plus

bjone a écrit a écrit :     (...)donc qui dit cumul de perturbations volontaires, dit cumul de distortions/bruit non désiré...   carmack a l'habitude de savoir ce qu'il veut et pourquoi il le veut (il fait toujours des simulations en software pour savoir ce qui est rentable graphiquement), et je doutes que microsoft et l'industrie de la 3d temps-réel ayent accepter de supporter un mode 64 bits dans un futur proche uniquement pour lui faire plaisir. (...) l'avenir semble assez drôle

 
tres interessant tout ce que tu dis. je suis avant tout graphiste c vrai et donc ton point de vue m'a bien appris.  c vrai que Carmak est un visoneur d'avenir bien plus loin que pas mal de monde !
enfin j'espere surtout que le 64bits sera pas un argument marketing plus qu'autre chose. la course a l'armement de nvidia c bien mais ca leur fait oublier de réellement utiliser toutes les capacites de leur precedents produits.
 
sinon une question vu que tu gazes . est ce que les nouveaux shaders pourraient servir a generer des effets volumiques. comme de la fumée ou des explosions ? genre se debarasser des bidouilles a la polygone qui deconnent toujours aux colisions.
 
en tout ca c sympa d'argumenter sur ce sujet car je me pose plein de questions !

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 disons que les cartes 3d dans 4/5 ans auront ces specs là, donc ya de quoi voir venir

Les 3/4 des transistors son pour le cache l2 , le proces c'est plutot dans les 30 et 40 millions !

MoggBomber a écrit a écrit :     je suis d'accord mais sur un "degradé" d'environ 8 pixels on va dire (genre texture de béton sur un mur) dis moi comment tu vas placer tes 256 niveaux de degradés ?! hein ?   pour le 16 bits des geforce bien sur il existe mais les drivers le gèrent de moins moins bien. c surtout le bleme du zbuffer mais c clair ils en ont plus rien foutre. ils optimisent quake3 en haute resolution et 32bits pour tapper les bench c tout.

 
non !!!
 
il ne faut pas voir ça comme ça !!!!
 
c trompeur !!!
 
la 3d implique que la texture que tu vas plaquer sur ton polygone, va avoir ses pixels complètements non-alignés vis à vis de la "grille" pixel qu'est l'image que tu regardes...
 
on s'en fout de se concentrer sur une zone de 8 pixels de large, ou avec peu de variation, les pixels de ta texture, et les pixels "d'échantillonnage" ne vont pas correspondre les 3/4 du temps à ceux de la texture plaquée, c le but des filtrages, trouver la valeur idéale par interpolation (dans le cas des filtrages bilinéaires et trilinéaires)...
il faut de la précision, et justement si souvent le 16 bits suffit pour les murs par rapport au 32bits, c parceque justement tout est toujours fait en 32 bits en interne (dumoins 24)..
 
les seules cartes qui ont fonctionnées de manière inférieur au 32 bits en interne sont les ati rage pro (de la merde en barre pour la 3d, implémentations cheap de partout), et les renditions vérités (je suis pas sûr, mais rendition est excusé, ce sont les pionniers des pionners avant 3dfx et nvidia)...
 
le 16 bits,  c po que les drivers le gèrent de moins en moins bien, c'est que le matériel a évolué pour favoriser le 32 bits au niveau des optimisations internes, et que du coups les écarts de fillrate le 16 bpp et le 32 bpp s'estompe... (la geforce 1 ddr étaient encore favorable au 16bpp, les transparences étaient pénalisées en 32bpp, mais la gf 3 et la radeon 8500 sont assez peu pénalisées en 32 bpp vis à vis des transparences == relecture en ram vidéo)
 
c comme les cpus, bin en "16 bits" certains cpu sont plus lents qu'en "32 bits" (enfin c une autre histoire )

MoggBomber a écrit a écrit :     tres interessant tout ce que tu dis. je suis avant tout graphiste c vrai et donc ton point de vue m'a bien appris.  c vrai que Carmak est un visoneur d'avenir bien plus loin que pas mal de monde ! enfin j'espere surtout que le 64bits sera pas un argument marketing plus qu'autre chose. la course a l'armement de nvidia c bien mais ca leur fait oublier de réellement utiliser toutes les capacites de leur precedents produits.   sinon une question vu que tu gazes . est ce que les nouveaux shaders pourraient servir a generer des effets volumiques. comme de la fumée ou des explosions ? genre se debarasser des bidouilles a la polygone qui deconnent toujours aux colisions.   en tout ca c sympa d'argumenter sur ce sujet car je me pose plein de questions !

 
tu as les textures volumétriques pour ça, elle sont en 3d (donc tu fais une texture sur plusieurs plans, orientée voxel, enfin j'ai pas expérimenté encore...
 
vu que la résolution de ces textures est faible, et la consommation mémoire est monstre, on en fait qu'une et on s'en sert pour faire des ombres portées (avec le stencil buffer et des volumes d'ombres) qui s'atténuent et se diffusent avec la distance...
 
genre quand la "matière" est proche de la surface ombré, l'ombre est importante et nette, et quand la distance est grande, l'ombre est attnuée et floue, ceci de manière progressive...
 
enfin là je commençe à me paumer

[edtdd]--Message édité par bjone--[/edtdd]

 
c clair, mais y'a du monde quand même
et c plus le cache L3 qui bouffe au ratelier
(et le cache L3 doit pas tourner à 1 Ghz)...

bjone a écrit a écrit :     tu as les textures volumétriques pour ça, elle sont en 3d (donc tu fais une texture sur plusieurs plans, orientée voxel, enfin j'ai pas expérimenté encore...   vu que la résolution de ces textures est faible, et la consommation mémoire est monstre, on en fait qu'une et on s'en sert pour faire des ombres portées (avec le stencil buffer et des volumes d'ombres) qui s'atténuent et se diffusent avec la distance...   genre quand la "matière" est proche de la surface ombré, l'ombre est importante et nette, et quand la distance est grande, l'ombre est attnuée et floue, ceci de manière progressive...   enfin là je commençe à me paumer

 
ouai c clair les textures volumetriques ca bouffe enormement de RAM !!
connais tu les hypervoxels sur lightwave ? ca permet des post traitements sur l'image pour obtenir des effets de volume. ca serait possible d'apres toi en realtime ? (bien sur de bien moins bonne qualité)
sinon avec 128Mo de ram sur une geforce4 est ce que ca permettrait d'avoir une texture volu generique pour une fumée et une autre pour une explosion par ex ?
ca serait cool non ?
enfin c vrai qu'on peut avoir de bon resultats visuels au polygones....

en fait on n'est pas encore sûr que le mode 64 bits soit bien un mode interne.... je suis parti un peu en vrille là
 
je sais po pour lightwave... du tout...
 
bin l'autre problème, c'est que non seulement, ta texture volumétrique elle est grosse, mais en plus si tu veux un effet de flame, ou de fumée, fo qu'elle soit animée, alors t'a 2 possibilité, soit ta texture vol elle est animée sur plusieurs texture vols, et le jeu de texture vol est précalculé,  
ou alors avec le cpu tu génére ta texture volumétrique par un algo....
alors là ça doit être chooooooooooo a mettre en oeuvre....
remarque je suis sûr que y'a des mecs qui arriveront à nous faire l'algo de feu en asm dans une texture volumétrique...
héhé ça c'est une idée
 
enfin ça trippe dur là

[edtdd]--Message édité par bjone--[/edtdd]

bon plus ca va plus on va sortir du sujet !
 
ben ca donne ca en gros. mais bien sur c pas du temps reel et j'imagine que ca devrait etre beaucoup beacoup plus simplifié.
http://www.tvcd.com/TextTut/HVExpl [...] igure3.jpg
 
en fait je confond avec lightwave qui utilise aussi des pixel shaders mais c en fait un post traitement au niveau des pixels en utilisant le zbuffer pour obtenir des effets visuel comme les gaz ou poils par exemple...

[edtdd]--Message édité par MoggBomber--[/edtdd]

bin sinon pour les systèmes de particules, tu as les pointsprites....
c po nouveau dans le sens ou pourvait faire la même chose avant, mais chaque pointsprite compte comme 1 seul triangle... (ça a plus de rendement que les approches précédentes)

mais bon chercher à reproduire ce que font 3dsmax & lightwave en temps réel, c po trop possib
l'approche n'est po la même...

par contre j'espère que les 64bits sont bien pour les canaux ARGB interne, passke autrement je vois pas ou est-ce que cela pourrait être utile ailleurs....

 
T'es sur pour l'emboss ? parcequ'en fait c'est qu'un artefact de bumpmapping une astuce graphique qui consite a décaler une textures pour produire un effet d'ombres. Ou alors l'emboss a évolué ?

si c bien 2 textures décalées pour moduler la texture normale...
 
mais bon c'était histoire d'en parler... (ça fait style, pis j'aime bien le terme "emboss", ça me rapelle mon amiga 500+ mettais 30 secs à le faire sur une image en 320x200 )
 
alors barbarella tu nous rejoins dans le trip "keskecquece64bits"..... ?

enfin c vrai que c surtout le dot3 et l'embm quit devenir vachement utilisé je pense dans les jeux à venir....
 
je trouve que le dot3 est vraiment pas assez utilisé...

bon allez

ben,  
 
pour l'instant je lis et j'apprends mais je veille au grain

 
ben on m'a dit récement que les fonctions de BM sont chiantes car tu ne peux pas faire toutes les operations que tu veux et bcp semblent leur préférer le multi-passe car plus souple. Il y aurait aussi un prob avec les perf en rendement d'utilisation des pipelines du proc graphique. mais bon j'suis pas sur d'avoir suivi toute la discution qui se passsait entre 2 bureaux a la va vite

[edtdd]--Message édité par Barbarella--[/edtdd]

boa, à mon avis c poa moa qui vais t'apprendre des trucs
en + là, c plus un partage en couille en règle

 
C'est de là que viens ce magnique effet de scanline en 512x384 sur la voodoo1! Je l'apprécie énormément, surtout quand je joue à Need For Speed High Stakes sur mon P166 (3e PC de mon réseau)
[#0000e2]3DFX forever

Bon j'ai pas grand chose à ajouter...le 64 bits c'est de l'augmentation de précision pour le cumul d'effets,..c'est pas la mer à boire, on aura des glDouble dans le code au lieu de faire des glFloat....
 
Au niveau texture "élémentaire" (celle que le graphiste dessine avec ces ptits doigts et qu'il sauve amoureusement en TGA) elle restera probablement en 32 bits...ou plutôt 24 bits!
Ensuite la carte peut toujours calculer en interne en 64bits - ou 128, 256, etc... pendant qu'on y est - et recracher ensuite le tout "proprement" (cf NVIDIA,mais il s'améliorent) en 32bits.
 
Pour DX9, ils se sont pas foulés je pense (en ce qui concerne le support des couleurs 64 bits s'entend) puisqu'ils ont du définir simplement des types numériques 64 bits pour les couleurs genre  
#define DX9_EXCOLORREF _int64 et recompiler le tout...
 
Bon je caricature, mais basiquement ça se résume à ça: on prend les interfaces COM existentes, on remplace tous les _int32 par _int64, (je caricatue toujours) et on les rajoute aux interfaces existantes...et roulez jeunesse!
Maintenant que la carte le supporte où pas, c'est (presque) pas leur problème.
....
....
....
....
Vous noterez avec quelle habileté j'ai déguisé  ds un discours relativement vide ce qui n'est en fait qu'un banal  
UP

 
bon explication

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 , 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]