Nehalem et innovations

[fefe]

Je suis d'accord avec toi que la 3D a besoin d'un retour vers un model de programmation plus souple. J'ai eu l'impression que les GPUs essayaient d'aller dans cette direction mais ils ne semblent pas encore tres pres. Le probleme est qu'il y aura forcement de la performance sacrifiee sur l'autel de la simplicite de programmation, et jusqu'a maintenant la performance etait ce qui faisait vendre des GPUs.

Le jour ou un CPU a assez de puissance pour permettre un rendu soft des applications du jour avec une penalite de performance raisonable pour un cout comparable, il est possible de voir la tendance s'inverser (le graphique revenir vers le CPU). En revanche le predire pour demain c'est etre un peu presomptueux quant au succes de Larrabee (puisque c'est a priori de ca dont il parlait sans le dire).

[newbie06]

Mouai... La roue de la metempsychose : le dédié c'est le mal, utilisons des trucs plus standard ; et dans 10 ans (voire moins), ralala il faut spécialiser ce machin, c'est pas assez efficace sur du standard

Mon point de vue sur le parallèle qui commence à devenir massif (OK, on est loin d'une Connection Machine, mais 80 coeurs ça peut se qualifier de massif) je l'ai déjà exprimé : il nous manque un langage adapté. Et il faut aussi rééduquer les programmeurs, moi le premier.

Si les CG font plein de trucs en parallèle c'est qu'intrinsèquement le problème est parallèle, même si les API ne le montrent pas forcément.

Quant à DX/OpenGL, j'ai l'impression que c'est le concept de la rasterization qui a été tellement poussé dans ses limites qu'on en est arrivé là. Et que je te rajoute un bidule parce que la CG elle sait faire du cube mapping, et que je te rajoute un truc parce que le mec de ma R&D il m'a fait voir un truc qui déchire sa race et qu'il le faut absolument sinon on va se faire bouffer par la concurrence.

Et qui va standardiser le nouveau langage et/ou API graphique pour les coeurs plus ou moins généralistes ? Parce que je ne pense pas que qui que ce soit veuille revenir à l'époque pré DX/OpenGL et tout se palucher à la main.

Il y a un autre aspect qui plaide en faveur du processeur dédié : le rendement énergétique. On peut dire ce que l'on veut un dédié est toujours plus efficace, sauf si on commence à l'utiliser pour autre chose que ce pour quoi il a été conçu

[Alice]

Je suis d'accord avec toi que la 3D a besoin d'un retour vers un model de programmation plus souple. J'ai eu l'impression que les GPUs essayaient d'aller dans cette direction mais ils ne semblent pas encore tres pres. Le probleme est qu'il y aura forcement de la performance sacrifiee sur l'autel de la simplicite de programmation, et jusqu'a maintenant la performance etait ce qui faisait vendre des GPUs.

Oui. Il faudra sans doute sacrifier les performances, car le matériel deviendra moins spécifique (sauf pour quelques unités) mais cette perte de performance pourra être sans doute compensée (toute proportions gardées) par un accès au hard moins masqué (ce qui se fait par exemple sur PS3). Par exemple, outre la facilité de manipulation, ne serais ce que considérer un color buffer comme un void* permet pas mal d'optimisations comparé à un buffer formaté (RGB, RGB1, RGBA16F, RGBA32F... etc).

En revanche le predire pour demain c'est etre un peu presomptueux quant au succes de Larrabee (puisque c'est a priori de ca dont il parlait sans le dire).

Là c'est de la propagande marketing. Mais au moins ça a le mérite d'interroger les gens

Mon point de vue sur le parallèle qui commence à devenir massif (OK, on est loin d'une Connection Machine, mais 80 coeurs ça peut se qualifier de massif) je l'ai déjà exprimé : il nous manque un langage adapté. Et il faut aussi rééduquer les programmeurs, moi le premier.

Sans doute qu'un langage plus adapté permettra de faciliter la tâche du codeur. Ceci dit la programmation massivement parallèle existe depuis des années sans que ces fameux langages prophétiques n'émergent. Bref, ce n'est pas une condition absolu pour que les gens s'intéresse a la programmation parallèle. Mais il est vrai que ce qui a fait le succès du [GP]GPU c'est le fait que les gens programmaient // sans le voir.

Quant à DX/OpenGL, j'ai l'impression que c'est le concept de la rasterization qui a été tellement poussé dans ses limites qu'on en est arrivé là.

Un algorithme de rendu ne peut justifier le foutoir d'une API! De plus le rasterization n'est qu'une technique de rendu qui permet de faire des choses de plus en plus puissante. Il y a encore plein de chose à tirer encore d'un rendu par rasterization. Bref la rastérization n'est sans doute pas arriver à ses limites... Loin de là!

Et qui va standardiser le nouveau langage et/ou API graphique pour les coeurs plus ou moins généralistes ? Parce que je ne pense pas que qui que ce soit veuille revenir à l'époque pré DX/OpenGL et tout se palucher à la main.

Il y aura peut être des libraire optimisées et des middleware. Mais il est fort probable que contrairement à ce que tu dis ceux qui veulent du lourd coderont tout à la paluche. Les programmeurs de console (surtout sur Playstation) le font déjà et je ne crois pas avoir entendu un Carmack ou un Sweeney se plaindre d'avoir du coder un raster soft bien au contraire. Ils se sont surtout plein quand les API ne se programmaient pas ou peu et que tout était formaté (époque T&L).

il y a un autre aspect qui plaide en faveur du processeur dédié : le rendement énergétique. On peut dire ce que l'on veut un dédié est toujours plus efficace, sauf si on commence à l'utiliser pour autre chose que ce pour quoi il a été conçu

Je ne suis pas contre le dédié! Les GPU ressemblent justement de moins à moins à un processeur dédié. Tout devient de plus en plus programmable ce qui le rend de moins en moins spécialisé. CUDA, Tesla & co illustre le fait qu'NVidia considère justement leur proc comme de plus en plus généraliste. Bref à l'avenir il est probable que les CPU auront quelques unités dédiées (au filtrage par exemple comme larabee) mais bien plus limitées que ce que l'on a aujourd'hui.

[Foudge]

Et qui va standardiser le nouveau langage et/ou API graphique pour les coeurs plus ou moins généralistes ? Parce que je ne pense pas que qui que ce soit veuille revenir à l'époque pré DX/OpenGL et tout se palucher à la main.

Effectivement, si on revient à l'époque du "on se retape tout à la main", je vois plus bien où est la meilleur facilité de programmation.
Il y aura donc bien une API/Middleware qui remplacera OpenGL/D3D tout en bénéficiant de la souplesse du matériel qui le fera tourner.
Mais si ce jour arrive, il y aura à tous les coups nVidia et AMD qui sortiront une puce dédié qui "accélèrera" cette API et on reviendra à la même situation qu'avant.

Il y aura peut être des libraire optimisées et des middleware. Mais il est fort probable que contrairement à ce que tu dis ceux qui veulent du lourd coderont tout à la paluche. Les programmeurs de console (surtout sur Playstation) le font déjà et je ne crois pas avoir entendu un Carmack ou un Sweeney se plaindre d'avoir du coder un raster soft bien au contraire. Ils se sont surtout plein quand les API ne se programmaient pas ou peu et que tout était formaté (époque T&L).

Les programmeurs de consoles se paluchent tout à la main ? Il me semble bien qu'ils passent eux-aussi par des middleware et qu'il s'en plaignent quand celui-ci est pourri (perf, bug, fonctionnalité). C'est ce que j'avais cru comprendre avec la PS2 par ex.
Et encore, avec les Wii/XBOX/PS3 ce sont des GPU ATI/nVidia donc même problème que sur PC. La théorie du "je me paluche la 3D à la main" ne me semble plus d'actualité sur console.

[Alice]

Foudge, bien sur que certains développeurs de console utilisent des middleware. Ceci dit pas tous... Loin de là!!! Et je te parle justement de ceux là... ceux qui s'intéresse dans le développement de techno. Un IdSoftware ne se code t'il pas tout? (jusqu'a la compression décompression du format JPEG pourtant bien connu/optimisé!). Un EPIC Software ne se fait pas son propre middleware? Sans parler de ces 2 monstres, les dévelopeurs d'Uncharted aussi ont tout balayer de la main en disant que tout ce qui était proposé était trop compliqué/usine à gaz. Bref ils se sont dit que vu qu'ils avaient de bon codeurs ils allaient tout se faire sur mesure à la paluche donc!!!!!. Bref on pourrait continuer la liste pendant des plombes. Qt aux consoles et aux GPU effectivement ce sont quasi les même que sur PC. Sauf que sur PS3 l'API n'en est pas vraiment une et que tu peux passer à coder pour coder le GPU sans la lourdeur de son API. Bref coder ce que l'on veut à la paluche n'a jamais autant été à l'ordre de jour... Le Lancer de Rayon temps réel dont tout le monde parle s'il arrive un jour, est fait actuellement à la main justement et tous les codeurs qui s'intéressent vraiment au lancer de rayon veulent avoir la main mise sur le tout ou presque. Bref une petite API qui facilite la vie oui... une API monstrueuse à la DX/OGL peut être que non!

[newbie06]

Ceci dit la programmation massivement parallèle existe depuis des années sans que ces fameux langages prophétiques n'émergent.

Parce que, comme tu le dis, ils sont protégés par une *API* qui fait le boulot pour eux. Interroge autour de toi pour savoir si les programmeurs connaissent les différents types de locks qui existent et leurs avantages et inconvénients suivant l'OS et la hiérarchie mémoire derrière. Si un langage ne nous abstrait pas de ça, la moyenne des programmeurs (dont je parle ci-dessous) va nous pondre des merdes absolues.

Un algorithme de rendu ne peut justifier le foutoir d'une API! De plus le rasterization n'est qu'une technique de rendu qui permet de faire des choses de plus en plus puissante. Il y a encore plein de chose à tirer encore d'un rendu par rasterization. Bref la rastérization n'est sans doute pas arriver à ses limites... Loin de là!

(Warning: point de vue hyper perso, non forcément argumenté...) La rasterization n'est pas un algorithme de rendu. Il s'agit plus d'un empilage de bidouilles pour que ça fasse joli. Et là on est au taquet, et tu l'as dit toi-même : DX/OpenGL sont devenus des empilages d'astuces pour faire des trucs qui en mettent plein la vue, sans avoir forcément derrière une volonté de cohérence, et voire même sans derrière une justification théorique. Je ne fais pas de programmation graphique, mais j'ai lu pas mal de trucs dessus ; autant je percute sur les algos genre ray tracing et illumination globale, autant les astuces de je te mets dans le pipeline une texture pour le lighting qui viendra par-dessus le reste sauf si j'ai des transparences, j'ai vachement plus de mal.

Il y aura peut être des libraire optimisées et des middleware. Mais il est fort probable que contrairement à ce que tu dis ceux qui veulent du lourd coderont tout à la paluche. Les programmeurs de console (surtout sur Playstation) le font déjà et je ne crois pas avoir entendu un Carmack ou un Sweeney se plaindre d'avoir du coder un raster soft bien au contraire. Ils se sont surtout plein quand les API ne se programmaient pas ou peu et que tout était formaté (époque T&L).

Tu as tout dit : tu parles d'un Carmack ou d'un Sweeney, et pas de Durand de chez Ubi. Le problème n'est pas chez les bons, le problème est dans la moyenne des développeurs. Ces gens-là sont des exceptions. J'ai discuté avec des très bons dévs PS2 ; eux leurs problèmes c'était leurs collègues qui n'avaient pas le niveau, pas les middlewares.

Oui, il y aura toujours des kadors. Oui, y'aura toujours des programmeurs incroyables (par exemple, les demo makers). Mais ces gens-là seront toujours des exceptions.

Je ne suis pas contre le dédié! Les GPU ressemblent justement de moins à moins à un processeur dédié. Tout devient de plus en plus programmable ce qui le rend de moins en moins spécialisé. CUDA, Tesla & co illustre le fait qu'NVidia considère justement leur proc comme de plus en plus généraliste. Bref à l'avenir il est probable que les CPU auront quelques unités dédiées (au filtrage par exemple comme larabee) mais bien plus limitées que ce que l'on a aujourd'hui.

Je voudrais bien que ce soit comme ça. Mais ce que je voulais dire, c'est qu'un jour le dédié reviendra en force pour de bonnes raisons, le rendement en étant une qui est imparable.

Je vais prendre un exemple : de plus en plus tu trouves des instructions multimedia sur les procs généralistes (SSEn sur x86, NEON sur ARM, etc.). Ensuite tu regardes ton domaine d'application ; ARM disons que ce sont des téléphones haut de gamme ; tu crois qu'il vaut mieux que ton processeur principal avec son jeu d'instructions tip-top multimedia fasse le décodage de ton prOn ou bien vaut-il mieux que ce soit un processeur dédié qui le fasse ? C'est ta batterie qui va dicter le choix, et le choix est clair.

On pourra toujours dire que je parle d'un domaine particulier, l'ultra-portable. Mais ce genre de considération arrive jusque dans les fermes de calcul où l'on commence à se dire que la note d'électricité dépasse le coût du matos...

[Alice]

Newbie06 je ne suis pas d'accord avec toi .

Parce que, comme tu le dis, ils sont protégés par une *API* qui fait le boulot pour eux

Non! Je ne parlais pas de prog graphique ou autre de même nature qui sont parallélisé automatiquement à travers leurs API. Les gens programment en // avec des langages en C/C++, Java etc. depuis longtemps sans passer par des API qui leur mâchent le travail. Depuis que le // est devenu grand public, il semblerait que ce soit les gens crois (je ne te vise pas hein ) que c'est le truc tout neuf inconnu des développeurs! Lancer de Rayons, Traitement d'image, Décodage vidéo/Audio, Base de données etc. n'ont pas attendu l'émergence d'un langage particulier pour se paralléliser. Ceci dit un langage qui simplifierait la tâche du développeur tendrait à démocratiser d'avantage ce type de programmation.

Interroge autour de toi pour savoir si les programmeurs connaissent les différents types de locks qui existent

Justement, les programmeurs autour de moi ont tous appris la programmation // (cursus général universitaire). mutex, semaphore, lock free (Plus difficle de trouver des gens qui connaissent) etc. toutes ces notions sont connues. L'influence du sous système mémoire, l'OS & co est sans doute moins connues par contre

Si un langage ne nous abstrait pas de ça, la moyenne des programmeurs (dont je parle ci-dessous) va nous pondre des merdes absolues.

Sauf qu'on ne parle justement pas de la moyenne des développeurs mais de ceux qui vont pondre des techno de rendu . Et on en arrive à la partie que je préfère (J'ai noté ton Warning mais je vais faire comme s'il n'y était pas )

La rasterization n'est pas un algorithme de rendu. Il s'agit plus d'un empilage de bidouilles pour que ça fasse joli.

Si... c'est un algorithme de rendu très efficace pour régler le problème de "rayons" primaires! L'empilage dont tu parles n'est pas foncièrement lié à la rasterization. Enfin effectivement un raster est présenté sous forme de pipeline et donc par un enchaînement d'étapes successives qui peuvent faire penser à un empilement d'opération mais l'empilage dont tu parles semblait plus faire référence à un amas de techniques foireuses et là ce n'est pas lié à la rastererization

tu l'as dit toi-même : DX/OpenGL sont devenus des empilages d'astuces pour faire des trucs qui en mettent plein la vue, sans avoir forcément derrière une volonté de cohérence, et voire même sans derrière une justification théorique

Oui et j'ai dit aussi qu'un algorithme de rendu ne peut justifier l'aspect obèse pas propre de ces API. Qt aux justifications théoriques je ne vois pas trop ce que tu entends par là mais d'un point de vue purement conceptuel le pipeline est assez bien passé. C'est juste les API qui le spécifie qui devienne trop monstrueusement complexes et pas toujours cohérente.

Je ne fais pas de programmation graphique, mais j'ai lu pas mal de trucs dessus ; autant je percute sur les algos genre ray tracing et illumination globale, autant les astuces de je te mets dans le pipeline une texture pour le lighting qui viendra par-dessus le reste sauf si j'ai des transparences, j'ai vachement plus de mal.

Le ray-tracing est conceptuellement plus simple à comprendre. Par contre ce dont tu parles à propos des lightmaps etc. n'ets pas lié exclusivement au Raster! Tu peux faire des light-maps (baking) en lancer de rayons! On fait souvent l'amalgame dégueulasse = raster sauf que c'est faux. Le raster est utilisé dans les jeux qui sont gourmands de performances et donc des astuces (des hacks) sont utilisés pour simuler certains effets et ce rapidement. D'où cet amalgame douteux (qui n'a pas vraiment lieu d'être vu que même une lightmap simule un éclairage [indirect] impossible en rendre dynamiquement en temps réel!). Le raster a ses limitations (Transparences, reflets...Etc) mais peut faire rapidement des choses propres (Je peux linker des articles sur la tesselation, les ombres etc. qui illustre tout ça). Le Lancer de rayons a aussi ses techniques que tu pourrais considérer comme douteuse. Et pour conclure là dessus, un path-tracing avec intégration de Monte-Carlo est propres dans son concept (Non biaisé, résout tout etc.) mais a aussi ses limitations (variance, flickering, temps de calcul prohibitif etc.)

Tu as tout dit : tu parles d'un Carmack ou d'un Sweeney, et pas de Durand de chez Ubi. Le problème n'est pas chez les bons, le problème est dans la moyenne des développeurs. Ces gens-là sont des exceptions. J'ai discuté avec des très bons dévs PS2 ; eux leurs problèmes c'était leurs collègues qui n'avaient pas le niveau, pas les middlewares.

Oui, il y aura toujours des kadors. Oui, y'aura toujours des programmeurs incroyables (par exemple, les demo makers). Mais ces gens-là seront toujours des exceptions.

On ne parles justement pas du développeur moyen. Pour lui rien ne changera puisqu'il aura un middleware qui lui fera le travail (que ce soit du soft // ou accéléré par OpenGL ou du CUDA pouet pouet il ne le saura même pas ou il s'en foutra). Les technos du renderer en lui même intéresse une poignet de développeurs, un noyau dur près à développer du neuf et là c'est de quelques dev chez ID, Epic, Naughty Dog, Gamebryo etc. dont on parle. Ce qui sont pret a se retrousser les manches pour bosser sur du neuf pour faire du neuf. Ubisoft ou EA c'est un peu particulier (contrainte bien plus forte d'un éditeur/développeur avec N titres sur X plateformes). A noter qu'Epic a proposé pendant très longtemps un raster soft avec leur Unreal engine. Bref on peut toujours considérer ces devs comme des exceptions mais c'est justement ces exceptiosn qui guident/popularisent des technologies de rendu (qui avait entendu parler des "mega textures" avant l'id-tech4/5?).

Pour finir sur le dédié je suis d'accord avec toi sur quasi tout. (rendement & co). Ceci dit, un GPU (qui se dit dédié au rendu graphique) consomme énormément car justement il est de moins en moins dédié (et simple). bref si tu vires le GPU et que tu gardes que ton octo coeur la consommation va chuter brutalement . Ce que j'essaie de te faire voir c'est qu'un GPU n'est plus un processeur dédié à quoique ce soit (sauf certaine petites parties qui se disent vouer à devenir programmable (sic!)). Certes c'est une archi spécialisé pour la programmation par flux mais il est bien loin le temps ou il ne faisait que transformer, éclairer des sommets et interpolés des attributs. Bref pour un GPU l'argument de la consommation ne tient plus vraiment. Celui des perfs par contre oui (cf le post de fefe)

[Foudge]

Pour finir sur le dédié je suis d'accord avec toi sur quasi tout. (rendement & co). Ceci dit, un GPU (qui se dit dédié au rendu graphique) consomme énormément car justement il est de moins en moins dédié (et simple). bref si tu vires le GPU et que tu gardes que ton octo coeur la consommation va chuter brutalement . Ce que j'essaie de te faire voir c'est qu'un GPU n'est plus un processeur dédié à quoique ce soit (sauf certaine petites parties qui se disent vouer à devenir programmable (sic!)). Certes c'est une archi spécialisé pour la programmation par flux mais il est bien loin le temps ou il ne faisait que transformer, éclairer des sommets et interpolés des attributs. Bref pour un GPU l'argument de la consommation ne tient plus vraiment. Celui des perfs par contre oui (cf le post de fefe)

C'est un peu contradictoire ce paragraphe. Tu dis que le rendement est meilleur mais que l'argument de la conso ne tient pas ?
nVidia&ATI ne vendent pas que des GPU qui consomment plus de 100W. Je dirais même qu'en terme de vente ça doit pas représenter grand chose.
Je suis persuadé qu'un dualcore + un petit GPU serait plus perf qu'un octocore tout en consommant moins.

[fefe]

Tu peux aussi avoir qq CPUs et qq texture samplers sur un meme die. Cote power ca n'a aucun sens de dupliquer les fonctionnalites parce que tout ce qui est generique leakera que ce soit cote CPU ou GPU...

[Alice]

C'est un peu contradictoire ce paragraphe. Tu dis que le rendement est meilleur mais que l'argument de la conso ne tient pas ?

Oui enfin je dis pas exactement ça hein ? ... Dire qu'il faut garder les GPU parce que c'est dédié et que ça consomme moins n'est plus vraiment d'actualité car ce n'est plus vraiment dédié et qu'ont ne peut pas dire que ça ne consomme pas (ou peu).

nVidia&ATI ne vendent pas que des GPU qui consomment plus de 100W. Je dirais même qu'en terme de vente ça doit pas représenter grand chose.

Effectivement mais c'est justement ces GPU qui nous intéressent vu que l'on parle des techniques de rendu à venir! Bref en se détachant de ce modèle CPU + GPU, un développeur remarque que bcp de machines disposent d'un CPU correct épaulé par un GPU cramoisi. Virer ce GPU et penser un rendu soft n'est vraiment pas idiot surtout si tu ajoutes quelques fonctionnalié au dit CPU.

Je suis persuadé qu'un dualcore + un petit GPU serait plus perf qu'un octocore tout en consommant moins.

Tient ça serait intéressant de bencher tout ça. Une config à prix égal sur unreal 2004. L'un bourré au taqué côté CPU l'autre moins bourré au taqué mais avec un GPU. On teste en rendu GPU et en raster soft (avec les même paramètres de rendu). Il est plus que sur que le GPU va défoncer la config CPU mais il serait intéressant de connaître dans quelle proportion. Il serait intéressant aussi de savoir quelle serait la perte de perf sur une config donnée, avec puis sans GPU. Ca permettrait de mettre en perspectives ces résultats avec la consommation de la configuration.

[fefe]

Cf le compte rendu de Sam sur l'IDF et la demo de Quake en RT.

[Alice]

90 fps c'est pas mal pour une scène de jeu (dynamique donc), même si Quake IV n'est pas très chargé en polygones. Par contre:

Benefit of ray tracing:
[...] per pixel exact shadows [...]

C'est plutôt marrant qd on sait que l'ID-tech4 derrière quakeIV (l'original) est justement l'un des rares moteurs qui utilisent les shadow volumes; shadow volumes qui ont pour principal avantage de générer des ombres exactes au pixel près <_<. Le bénéfice du RT sur ce point est donc nul (sic!).

[newbie06]

D'après ce que j'en sais la démo de Quake RT de chez Intel n'est pas un jeu complet, juste un viewer. On m'aurait menti ?
En plus à une époque il me semble qu'il n'y avait même pas de rayons secondaires hormis l'ombrage.
J'avais montré une capture à une connaissance développeur chez IO (Hitman) et en deux secondes il m'a prouvé à quel point les ombres n'étaient pas si réalistes en me montrant une scène issue de rasterization classique.

Pour ceux que ça intéresse un mec a posté des patches sur la ML ioquake3 pour faire du RT.

On a encore dérivé, non ?

EDIT: pour le truc ioq3 http://www.youtube.com/user/Stereo1984

[Alice]

D'un point de vue théorique les ombres d'un Lancer de rayons ou d'un volume d'ombre sont en fait plus réaliste que les "ombres douces" utilisées actuellement en raster. En raster, ce ne sont rien de plus que des filtrages qui ne veulent pas dire grand chose. Un volume d'ombre ou un Lancer de Rayon sont eux corrects si l'on considère que la source lumineuse n'est pas surfacique mais s'assimile à un point. Même d'un point de vu pragmatique les ombres actuelles des raster ne sont pas super soignées car soumis à bcp d'artefacts (ombrage d'une surface par elle même, biais en Z trop important pour justement éviter l'artefact précédent etc...), trop d'aliasing... Pourtant il y a bien des algo puissant pour arriver à faire du propre mais il semblerait que ça ne soit aujourd'hui pas suffisant

[newbie06]

Un volume d'ombre ou un Lancer de Rayon sont eux corrects si l'on considère que la source lumineuse n'est pas surfacique mais s'assimile à un point.

Si tu considères ta source lumineuse comme ponctuelle, n'obtiens-tu pas une ombre au bord trop franc avec du RT ? J'avais cru comprendre qu'il fallait justement prendre une source lumineuse comme un disque et envoyer plusieurs rayons depuis une même intersection.

(Je suis novice, pas taper )

[Yasko]

Si tu considères ta source lumineuse comme ponctuelle, n'obtiens-tu pas une ombre au bord trop franc avec du RT ? J'avais cru comprendre qu'il fallait justement prendre une source lumineuse comme un disque et envoyer plusieurs rayons depuis une même intersection.

(Je suis novice, pas taper )

Peut-être qu'ils modélisent aussi la diffraction en RT ?

[Alice]

Effectivement si tu assimiles ta source à un point le problème de l'ombre est binaire: un pixel voit la lumière ou non (=> contour franc). Le RT et les volumes d'ombres permettent de résoudre cette problématique au pixel près. Les shadow map non (problème de discrétisation). Avec une source étendu le problème est plus complexe puisque chaque pixel peut ne pas voir la lumière (ombre) la voir en totalité (lumière) où la voir en partie (pénombre).

Pour simuler cette pénombre les jeux d'aujourd'hui filtrent le conteur des ombres franches (généralement calculé par shadow-map) ce qui n'a aucune signification d'un point de vue "physique". Avec un lancer de rayons, on ne filtre pas mais on lance plusieurs rayon vers des échantillons de la source lumineuse afin d'intégrer numériquement l'éclairage direct: chaque échantillon peut alors soit apporter de la lumière (le rayon n'intersecte pas de géométrie ) soit non (la rayon est bloqué par une géométrie). En raster il existe un algorithme basé sur les volumes d'ombre qui permet de calculer ce type de résultat en temps réel/interactif.

EDIT: faut que j'arrête le hors sujet!

[fefe]

Non on n'arrete pas le hors sujet !, c'est interressant et on peut toujours deplacer ces qq posts vers le topic Larrabee .

Je me demandais aussi si on avait des models de rendu qui modelisaient la diffraction et si la refraction/reflexion/absorbtion etait modelisee de maniere apropriee: toute surface a ces 3 proprietes (en fait l'air aussi) et ce sont les principales contributions aux ombres douces de notre monde reel si je ne suis pas completement a l'ouest en optique.

Mais bon dans mes souvenirs le raytracing employe pour faire les designs optique et en infographie sont sensiblement differents.

[Alice]

Paf encore du hors sujet!

L'équation de rendu (qui est encore loin d'être résolue en temps réel) est basée sur une approximation des équations de transfert radiatif de Maxwell. Comme elle est basée uniquement sur l'optique géométrique (principe du lancer de rayons) elle ne peut donc pas simuler la diffraction. Par contre la réflection et la réfraction oui.

(Très?) Grossièrement,en infographie les ombres ne sont rien de plus que le résultat de requêtes de visibilité entre 2 points A et B. Si A voit B alors A éclaire B (pas d'ombre) sinon B n'est pas éclairé par A (ombre). Considérons maintenant le cas ou A éclaire B. Si A est un échantillon sur une source lumineuse alors A contribue à l'éclairage direct de B (éclairage reçu directement de la source de lumière). Si A est une surface alors A contribue à l'éclairage indirect de B (éclairage reçu indirectement de la source lumineuse: ie après qu'un rayon lumineux ai rebondi sur A).

[fefe]

L'indice de refraction de l'air est employe, ou tout est traite comme etant dans le vide ? (de maniere generale)

en fait je vais essayer repondre un peu tout seul: vu que je suppose que la refraction est geree lorsqu'un rayon rencontre une surface, je doute que l'air soit gere comme un volume ayant un indice de refraction donne. Right ?

[Alice]

Ben en fait ça dépend . L'air est généralement considéré comme du vide. Par contre la fumé, le brouillard...etc bref tous les milieux participants peuvent être traités. Ceci dit, rien n'empêche a priori de traiter l'air comme un milieu participant (perf--!). A noter cependant que l'équation de rendu est souvent utilisée dans sa formulation surfacique. Hors les milieux participants ne sont pas surfaciques et nécessitent donc des algorithmes/traitements spécifiques.

[newbie06]

Et voila, je suis largue, on peut pas revenir au sujet histoire que j'ai l'air moins ridicule

Sans rire, je trouve tout ca interessant. Cependant a priori tout ce qui se fait en RT temps reel (RTRT quoi ) n'utilise pas de formules d'eclairage avancees. Comme je le disais precedemment, la plupart des trucs qu'on nous montre n'utilisent pas de rayon secondaire, c'est du pipotage ala Intel Atom benchmark en somme.

[Alice]

C'est vrai que le RTRT ala Intel n'utilise pas pour le moment d'éclairage avancé. Par contre ils ont bien des rayons secondaires (reflets+ombres). Cependant, à l'avenir (proche l'avenir) des algorithmes comme le Metropolis Instant Radiosity (paf...) ne semblent pas impossibles. Bref pour l'heure on voit 3/4 effets rigolos comme les reflets et des ombres franches ala doom3 mais ce n'est pas ça qui va démocratiser le RT c'est sur. Ce qu'il faut c'est du mega lourd comme de l'illumination globale en temps réel (laissez moi rêver) et là tout le monde sera vite d'accord... Sauf bien sur si le raster propose d'ici là de la GI en temps réel sur scène dynamiques <_<

[fefe]

Je ne pense pas qu'on puisse dire que les demos sont du pipotage a partir du moment ou on les interprete comme une preuve du concept qu'on commence a s'approcher du RTRT de qualite raisonable avec du hardware generique.
Il n'y a pas de comparaison entre des pommes et des oranges dans ce cas la (contrairement au cas atom) ou alors tous les tests d'appli 3D qui n'emploient pas la qualite maximum disponible sont sans interret. J'ai peut etre mal lu mais je n'ai pas vu de claim pretentieux/douteux disant que un DP Nehalem allait remplacer les GPUs.
Je serais plutot interresse par des commentaires qualitatifs sur la demo. Si la qualite du rendu est jugee mauvaise alors effectivement on en a rien a f. que ca soit du RTRT, mais si ca rend bien ca devient interressant. Sam m'a dit impressionnant, je n'ai pas vu je ne peux pas juger et je suis interresse par des avis experts, mais j'ai tendance a faire confiance a Sam.

[newbie06]

Bon OK, j'ai ete sans doute excessif en disant que c'etait du niveau de l'atom

Ce qui serait interessant, ce serait de coller deux machines cote a cote, faire du RTRT sur l'une, de la rasterization sur l'autre et observer ce que les gens en pensent.

Si j'arrive a me bouger ce WE, je testerai sur ioq3, mais en screenshots, mon 3500+ va pas pouvoir faire du RT

[Franck@x86]

Ah Nehalem fusionne aussi en mode 64-bit. Pkoi c'était pas le cas avec les Conroe ?

[DaP]

C'est seulement la macro-op fusion qui est désactivée en mode 64 bits non ? Il y a un semblant de justification ici à la page 2-8 :

Intel Core microarchitecture is capable of one macro-fusion per cycle in 32-bit operation (including compatibility sub-mode of the Intel 64 architecture), but not in 64-bit mode because code that uses longer instructions (length in bytes) more often is less likely to take advantage of hardware support for macro-fusion.

Qu'est-ce que ça leur coûtait d'ajouter le support en 64 bits en fait ?

[fefe]

Au hasard, on peut essayer:
-des transistors, donc du power et des $
-du temps de design donc des $
-du timing dans les decoders qui est un endroit difficile du design, donc de l'effort, du power et du $
Tout ca pour faire de la macro fusion qui a une probabilite plus faible de se produire en 64 bits qu'en 32 (les instructions sont plus longues donc moins de chances qu'on ait ce qu'il faut dans les 16 bytes), et surtout sachant que la machine a une probabilite tres importante de ne jamais voir l'ombre d'un code 64 bits.

Donc la version courte de la reponse est probablement "$".

[Foudge]

POV-Ray Real-Time Raytracing sur des machines contenant 2 à 8 cores :
http://www.legitreviews.com/article/690/10/

[newbie06]

Au hasard, on peut essayer:
-des transistors, donc du power et des $
-du temps de design donc des $
-du timing dans les decoders qui est un endroit difficile du design, donc de l'effort, du power et du $
Tout ca pour faire de la macro fusion qui a une probabilite plus faible de se produire en 64 bits qu'en 32 (les instructions sont plus longues donc moins de chances qu'on ait ce qu'il faut dans les 16 bytes), et surtout sachant que la machine a une probabilite tres importante de ne jamais voir l'ombre d'un code 64 bits.

Donc la version courte de la reponse est probablement "$".

Ca me fait penser : quelqu'un a-t-il des liens présentants des benchmarks 64 bits à la fois sur des Intel récents et des AMD récents ?

J'ai bien ça http://gmplib.org/gmpbench.html, mais c'est quand même spécialisé (enfin pour le multi-précision Intel ça pue trop )

PS - Ouai je sais le multi-précision c'est un marché si étroit que ça vaut pas les $ investis