Caustic Graphics : http://anandtech.com/video/showdoc.aspx?i=3549
Caustic Graphics : http://anandtech.com/video/showdoc.aspx?i=3549
Quand je vois des speedups de 1 ou 2 ordres de grandeur j'ai tendance a crier au marketing BS. Soit ils n'optimisent pas le code au meme niveau sur les 2 plateformes, soit ils ne font pas tourner la meme chose, soit ils ont fait tourner des micro kernels de quelques instructions qui sont completement hard-wired dans leur engine et bien lentes sur les CPUs.
D'ailleurs c'est la meme chose pour GPGPU, quand on regarde des codes utiles et bien optimises sur GPU et CPU on est generalement bien loin des speedups d'un ordre de grandeur.
Ca ne reduit pas l'interet de ce type de hardware, mais j'ai du mal a croire quand quelqu'un annonce des speedups de plus que 2 a 5x (a quantite de hardware ou power equivalent). Bien entendu je peux me planter completement et peut etre qu'il y a quelque chose de particulier au coeur du RT qui aime vraiment le HW dedie, mais vu qu'ils parlent d'une machine SIMD (un peu comme les processeurs ou GPUs actuels somme toute) ca laisse planer des doutes sur l'utilisation d'une approche revolutionnaire. Bien entendu j'ai peut etre rate l'equivalent du texture sampling dans la rasterization classique qui effectivement est accelere par du hard dedie par des facteurs depassant 1 ordre de grandeur et approchant 2 (sans ca les GPUs ne seraient pas a ce point meilleurs que les CPUs a faire du raster). Je comptes sur les experts RT pour m'expliquer ce que je rate.
Je ne leur demande que de contrarier mon scepticisme...
fefe - Dillon Y'Bon
Ce qui me choque principalement, c'est qu'ils auraient trouvé un super truc pour les rayons secondaires.
Avec seulement les rayons primaires, y'a eu des articles montrant un FPGA à 66 MHz équivalent à un P4 à 2.4 GHz (http://graphics.cs.uni-sb.de/~woop/r...SIGGRAPH05.pdf) faisant tourner du soft bien optimisé (OpenRT).
Oui, bien sur, je parlais de "vrai" raytracing, pas d'approximation ou on ne rend que les rayons primaires ou il y a effectivement un parallelisme quasiment illimite (le nombre de pixels) et facile a exploiter.
Reflections et refractions sont quand meme un des interets du raytracing si je ne m'abuse.
fefe - Dillon Y'Bon
Oui 100% d'accord
Deux liens avant d'aller me coucher, il se fait tard en France
http://www.youtube.com/user/CausticGraphics
http://ompf.org/forum/viewtopic.php?f=3&t=1248
(ce forum a l'air fréquenté par des mecs qui savent de quoi ils parlent, tout du moins certains me donnent cette impression)
Et encore, si le texture sampling marche aussi bien sur GPU c'est autant grâce à leur bande passante mémoire monstueuse exploitable proche du débit crête sur des motifs d'accès pas réguliers qu'à leur unités de filtrage dédiées.
Si on suppose que leur CausticOne a de la DDR3-800 (le max supporté sur un Virtex-5) en 128-bit, ça fait léger en bande passante comparé à un GPU ou même un CPU. Même avec des structures de données optimisées et des gros caches, la recherche d'intersections en raytracing doit pas mal tirer sur la mémoire...?
Et en passant sur un ASIC, ils pourront peut-être gagner leur facteur 14 sur la puissance de calcul (et encore si leur implémentation FPGA a été conçue juste pour le prototypage et pas optimisée), mais sur la bande passante mémoire et PCIe ça sera plus dur...
S'ils gèrent les textures, ça devient encore pire. Et s'ils rajoutent des shaders, la différence avec les GPU s'estompera, voire s'inversera à prix égal...
Enfin peut-être qu'ils ont une technique révolutionnaire qui résout tous ces problèmes...
Apparemment leur FPGA ne fait que du calcul d'intersection.
Tout le reste, shader compris, est fait par le CPU et le GPU.
L'hypothèse émise par certains est que leur seul but est de se faire racheter ou de proposer leur IP pour que ce soit accolé au GPU, parce qu'ailleurs, comme tu le dis, la BP va être un vrai problème très rapidement.
Ca sent des pieds comme AGEIA, ce truc. A un moment il ne restera plus que leur API![]()
J'aurais dis, a commencer par l'avantage d'un cache de texture sur un cache normal. Tu economises une bande passante monstrueuse de cette maniere, et les acces 2D/3D a un cache classique c'est pas la joie vu son organisation.
Apres oui tu as besoin d'une grosse bande passante, mais pas direct vers ta memoire. Tu as beaucoup de localite dans tes textures qui n'est pas exploitee par ton L1 Texture cache. Tu peux songer a mettre un L2 voire un L3 pour exploiter le rendu en plusieur passes. Au final tu ne charges pas tes 500M de textures 50x par seconde dans la plupart des applis, tu t'acharnes serieusement sur un sous ensemble et un gros cache, ou de l'EDRAM comme sur la xbox est la seule memoire qui a vraiment besoin de bande passante, le reste pas vraiment besoin de tes 16 canaux de GDDR pour les transferer.
Donc il est possible de faire quelque chose pour la bande passante memoire sans avoir besoin de beaucoup de liens a haute frequence. En revanche je ne crois pas que les FPGA soient ideales pour implementer de gros caches. Donc si on revient au sujet de discussion, on dirait effectivement qu'ils veulent se faire racheter
.
fefe - Dillon Y'Bon
Sinon, la lecture de ompf.org confirme avec des details ce que je suspectais. Il y a deja des solutions a base de FPGA pour accelerer le RT. Ca accelere effectivement les calculs d'intersection d'un ordre de grandeur, mais au final ca ne donne pas plus de 2-3x sur le rendu d'une scene et c'est loin d'etre suffisament flexible pour que ca soit vraiment utilise.
A moins que caustic ait quelque chose de revolutionnaire face a ces solutions existantes, c'est juste du bruit pour essayer de se faire racheter par Intel, AMD, Nvidia (qui se livrent a des rachats a tour de bras pour eviter que les autres aient acces a l'IP)
fefe - Dillon Y'Bon
Tu aurais des refs ou des chiffres sur la taille des working sets? Ça m'intéresse.
On peut donc imaginer que les GPU intégreront bientôt tous un gros cache, quand le coût et la conso de la GDDR ne permettra plus de scaler?Au final tu ne charges pas tes 500M de textures 50x par seconde dans la plupart des applis, tu t'acharnes serieusement sur un sous ensemble et un gros cache, ou de l'EDRAM comme sur la xbox est la seule memoire qui a vraiment besoin de bande passante, le reste pas vraiment besoin de tes 16 canaux de GDDR pour les transferer.
(Ouais mais Larrabee il compte pas)
Argh, mon plan secret est découvert.![]()
Tu peux hacker le rasterizer microsoft de reference (ou Mesa si tu veux regarder des applis OpenGL) pour qu'il te donne des traces d'addresses/samples et les passer a un simulateur de GPU et de caches pour faire l'etude.
fefe - Dillon Y'Bon
J'avais déjà essayé de faire ce genre de choses avec Mesa, sauf que y'a pas des masses de benchmarks qui passent avec la pile Mesa software (juste les SPECViewPerf avec zéro shaders...)
J'avais bien tenté de faire tourner 3DMark 2001 et 2003 sous Wine, mais il aurait fallu hacker Wine aussi pour cheater la détection des shaders en hardware, j'ai vite laissé tombé.![]()
Il y a longtemps j'avais utilise un hack de GL Trace et Mesa pour faire ce genre de choses. Tu enregistres les appels de ton appli OpenGL tournant avec un driver qui va bien (sous windows), et tu replay le tout offline a travers un Mesa hacke. C'est pas bien grave si ca ne rend pas tout bien vu que tu cherches essentiellement a avoir une trace d'addresses memoire. Bien entendu ce n'est pas un hack de 5 minutes, mais ca marchait (enfin en mmm 1998).
fefe - Dillon Y'Bon
Un peu hors-sujet : un ami a moi s'est amuse a threader le driver nVidia sous Wine.
L'idee en gros est de lancer WoW en OpenGL a partir de Wine et d'utiliser un wrapper GL specifique qui est dans un thread separe. Avec cela il desynchronise les appels GL. Le resultat est tres interessant avec des perfs jusque x3 dans les parties du jeu non CPU bound, et ce avec une CG performante, gtx260+.
3x par rapport a la meme chose sous wine ou 3x par rapport a la meme chose sans emulateur ?
fefe - Dillon Y'Bon
x3 sous Wine (bencher un MMO est quasi impossible, le seul moyen est de pouvoir debrayer les optims specifiques en temps reel, ce que son wrapper permet).
Enfin a priori je pense que l'implementation OpenGL de WoW n'est pas pourrie (MacOS oblige) et le cout du wrapper GL de Wine est negligeable (il a mesure).
En revanche certains appels system Windows sont tres mal implementes avec l'utilisation abusive de trucs du genre gettimeofday...
Oui, ça s'est certainement amélioré. Faudra que j'essaie de faire tourner un UT2004 ou un Quake 4 à l'occasion...
Après ça reste de l'émulation. Les shaders ne sont pas optimisés, donc on fait des calculs pas très représentatifs de ceux qu'un vrai GPU ferait. La partie SIMD et MIMD saute complètement, et va t'amuser après à rejouer les traces en essayant de reconstituer une exécution en parallèle, avec les branchements en SIMD...
Encore faut-il avoir le driver qui va bien sous Windows... Bon, je sais que ça existe, et même pas loin de chez moi, mais effectivement c'est pas un hack de 5 minutes.
Ca a du s'améliorer aussi avec Gallium, même si je ne sais pas trop où ça en est...
En plus je ne sais pas trop ce que tu vas en tirer niveau trace mémoire, parce que j'imagine que chaque driver, Mesa inclus, adresse les textures et le reste de ce qui est en mémoire, de manières très différentes non ?Encore faut-il avoir le driver qui va bien sous Windows... Bon, je sais que ça existe, et même pas loin de chez moi, mais effectivement c'est pas un hack de 5 minutes.
Oui et non, les addresses physiques seront differentes, mais une fois tes mimaps alignees correctement tes patterns d'acces aux textures restent les memes (meme ordre, memes offsets), ce qui te permet de passer tes traces d'addresse a travers un simulateur de cache. Tu n'auras pas exactement les memes taux de succes (surtout sur des caches a faible associativite) mais si tu cherches a savoir si le hit rate est 20-30 50 70 ou 90% c'est tres efficace.
fefe - Dillon Y'Bon
Je pensais que la facon d'acceder a la texture serait tres dependante de chaque implementation. Quoique en y reflechissant c'est peut-etre idiot, puisque le pattern d'acces a la texture est dicte par l'ordre d'acces au pixel (vs texel) qui doit etre de gauche a droite, puis de haut en bas, c'est ca ?
Oui si tu restes au niveau d'abstraction d'OpenGL et que tu traces les coordonnées (u,v) et gardes tous les paramètres du sampler (taille, mode de filtrage, mipmaps...).
Après tu peux simuler le mode d'adressage que tu veux (linéaire, tilé, courbe de Peano...), en considérant que ça fait partie des paramètres de la simulation.
Ce qui va être dépendant, c'est l'ordre dans lequel tu fais tes accès. Mesa va traiter les pixels séquentiellement au lieu de les traiter par paquets, et l'ordre de rasterization sera certainement très différent.
Donc il faut en plus un scheduler pour trier les traces...
(En relisant ce que tu as écrit je me rends compte que tu parlais bien de l'ordre de rasterization. Non il n'est pas évident du tout, par exemple pour le G80 : http://www.icare3d.org/GPU/CN08.)
Bon entre ce que tu dis et ce que Fefe raconte, moi j'y comprends plus rien, je retourne a mes benchmarks bien connus![]()
Si tu captures le comportement du traffic lie aux textures tu as entre 50 et 90% de tes acces memoires. Ajoute 10 a 30% pour tes vertice, jusqu'a 10% pour Z, et il te reste 5 a 30% pour la rasterization. Ces derniers seront dependants de ta methode de fragmentation/binning mais justement le fait que tu puisses bloquer la rasterization pour qu'elle tienne dans de petites memoires locales (ou caches) te permet assez rapidement de determiner le hit rate sur ceux-ci sans avoir vraiment a simuler un ordre exact. Bien entendu quand tu as un simulateur capable de les scheduler correctement tu gagnes en precision, mais vu la part de la rasterization dans le traffic memoire l'erreur n'est pas enorme.
fefe - Dillon Y'Bon
TS et JC
http://graphics.cs.williams.edu/arch...TimHPG2009.pdf
http://www.cdaction.pl/news-7673/joh...--pol-godziny- (videos youtube)
fefe - Dillon Y'Bon
Pas encore vu la vidéo de Carmack, mais dans les slides de Sweeney le Cell s'en prend plein la gueule. Et Larrabee c'est le futur ça va résoudre tous les problèmes toussa...
Par "current GPGPU", je suppose qu'il parle du DX9 du 2004. Parce que sinon CUDA offre la plupart de ce qu'il demande (pour le code data-parallel), à part les instructions scalaire-SIMD (réduction), et la mémoire totalement cohérente avec le CPU. Bien sûr c'est pas encore portable...
Mouai, ils me font rire les mecs qui croient que la cohérence va tout résoudre (je parle pas de TS là). La cohérence simplifie surement grandement certains problèmes, mais je me marre à l'idée de la tête que va faire le premier naïf venu qui se dit que LRB va lui fournir un bon speedup magiquement. Le pauvre risque de se retrouver avec son ring bus engorgé de requêtes L2 allant d'un coeur à l'autre.
Donc ouai la cohérence c'est bien, mais ça ne suffira largement pas.
Et puis le Cell, c'est bien, nah![]()
Sweeney est ultra pro-LRB, Carmak nettement moins et ca se voit dans les articles en question.
En revanche quand ils parlent de coherence, ils ne pensent pas performance, c'est toi qui te trompe la. La coherence n'a que tres rarement apporte de la performance et n'est generalement pas la pour ca. La coherence est la pour simplifier l'ecriture de code et la reduction des couts, chose pour laquelle on est generalement pret a sacrifier de la performance.
La coherence reduit la performance des architectures, augmente leur cout, et un programmeur intelligent a qui on fournit les bons outils de communication entre plusieurs unites de calcul fera nettement mieux dans la majorite des cas (quand il pourra predire les communications necessaires de maniere statique. En theorie dans la majorite des problemes un programmeur pourra eliminer l'essentiel des snoop qui "miss".
Le seul cas ou tu gagnes est le cas ou les dependances sont resolues dynamiquement a l'execution, et la sans coherence il faut faire du code auto modifiant pour obtenir la meme chose sans et ca devient inefficace, lent, inmaintenable... Donc oui il y a des cas ou la coherence sera plus rapide que du soft, mais ce n'est pas le cas de l'essentiel du code graphique dont Sweeney parle.
De ce que je comprends, la seule raison pour laquelle il veut la coherence, c'est pour reduire ses couts de developement d'applis paralleles.
fefe - Dillon Y'Bon
Je ne me suis pas trompé : je crains juste que des gens croient que juste parce que ça fonctionne tout seul correctement, ça suffit. Avec 4 coeurs OK, avec 16 ou 32, ça m'étonnerait. Du coup, je ne suis pas 100% convaincu que ça soit vraiment un facteur permettant de baisser les coûts, parce que de toute façon, l'efficacité mémoire il va falloir se la palucher à la main, et avec plein de coeurs ça ne va pas être facile.
C'était tout ce que je voulais dire, faut pas chercher plus loin, je suis en vacances, j'ai débranché le cerveau![]()