Reprise du message précédent :
C'est normal, c'est une valeur que tu configure dans le bios (AGP Aperture Size, si t'as une config AGP) qui varie généralement entre 32 et 512Mo.
Bref rien à voir avec la quantité de RAM vidéo, et elle est strictement inférieur au total de ta RAM.

c'est l'équivalent de l'AGP aperture size.
swapper par l'AGP/PCIe texturing ça fait plus que dépanner : à far cry en arrivant dans la grotte, je me suis retrouvé à 1fps.. résolu en augmentant l'aperture size de 64 à 256Mo.
 
De même, UT2003 en montant trop les textures sur voodoo5.. ya pas d'AGP texturing, alors ça passe au swap en mode PCI via le driver, en slideshow. (doit yavoir le même mécanisme quand on est à court "d'aperture size", sinon farcry me mettrait probablement un message "out of video memory" dans la gueule ^)

explication de 1h44: (j'ai un peu de mal soyez indulgents)
 
oui, en fait les textures statiques sont initialement en mémoire process (visibles par le cpu), et dupliqués en ram gpu = espace mémoire atteingnable par le gpu (ram vidéo+espace système remappé grâce au gart) lors de la première utilisation.
 
le précachage consistant a "utiliser" une texture récemment crée pour la dupliquer en ram vidéo afin de réduire les saccades une fois dans le jeu dû à l'upload. (en fait y'a deux précachage: celui du "moteur" où ledit moteur précharge les textures & modèles par rapport au niveau avant qu'ils soient nécessaire, et le précachage D3D/OGL où c'est le moteur qui fait quelques commandes de traçage dans le vent ou "utilise" les ressources pour que le D3D/OGL upload les ressources en ram vidéo).
 
si tu est à court de ram vidéo+agp (visible depuis le gpu), alors il faut supprimmer des textures ou autre ressources pour recopier les textures nécessaires vers la ram vidéo ou agp (en fait vidéo puisque la texture devient un texture récemment utilisée), pour que le gpu puisse atteindre la nouvelle ressource.
 
après la répartition vidéo/système par l'agp se fait via le driver (bon y'a des système de hint pour créer justement initialement la ressource en vidéo ou agp sans backup, ou géré en auto avec backup en mémoire uniquement visible par le cpu).
 
l'astuce c'est que le gart est limité car d'une part un taille énorme fait perdre de la ram physique dû à la table, et l'espace alloué par le gart est non cachable (vis à vis du cpu). (ie l'espace par le gart est relativement redimentionnable à la volée, si on mets 256Mo dans le bios, c'est pas bloqué a vie)
 
en PCI-Express il n'y a plus de gart, l'implémentation semble plus souple, par contre je connais quelles sont les contraintes au niveau cachabilité CPU ou pagination OS.
 
quand les GPU seront passé a un management de l'espace par pagination de leur coté, et avec D3D 10 qui retourne la méthode de création de ressources pour une approche comme sur console a mémoire unifiée, cela devrait être plus souple et avoir un comportement infiniment plus coulé lorsque la scène sors largement de la ram vidéo.
 
en D3D 9 quand tu crées une ressource, l'allocation se fait via le D3D (tu dis je veux un vertex buffer de 2Mo, je veux une texture de 512x512...), en D3D 10 tu alloues comme tu le sens (classiquement, un bête malloc par exemple), et tu "mappes" l'espace mémoire (tu dis j'ai un vertex buffer de 2Mo ici, une texture là), ce qui avec un système de pagination devrait permettre une utilisation de la ram vidéo comme un cache a granularité fine (dumoins plus fin que le vertex buffer entier de 2Mo et la texture entière).
 
tiens d'ailleurs on a quoi comme rumeur au niveau assistance multitâche et pagination pour la geforce et la radeon d3d10 ?

 
Non l'allocation se fait de la même manière sous d3d9 et d3d10. à moins que tu voulais dire autre chose ?
 
L'API a des appels : createBuffer, createTexture2D, createTexture3D etc.. et au final c'est le driver qui décide (en fonction des bind flags, des cpu flags, et des usage flags) dans quel pool de mêmoire cela va atterrir.
 
Par contre il n'y a plus de notion managed/default et la surcouche DXGI permet de partager des resources entre device d3d9 et d3d10, pour le desktop compositing par exemple.
 
LeGreg

il me semblait avoir vu système de projection pour les vertex/index buffer ? (ptet pour les textures j'ai fait un raccourci)
 
attends je reregarde dans le SDK...

 
j'ai pas lu de font en comble et expérimenté avec le SDK de D3D10 (vu qu'installer Vista Beta et le refrast sur ma machine bof)
 
je reprends l'exemple du tuto2.
 
A priori cela semble plus orienté mémoire partagé a la Xbox 360 vu que l'allocation du buffer système est laissée a la charge du process (dumoins ça me parait plus flexible qu'en D3D9) ?

 
Vista sort avec D3D10 et WDDM 1.0 .. et le WDDM 2.0 nécessitera une génération ultérieure de GPU !?!

 
Mauvaise interprétation du code, initData est juste utilisé pour initialiser le contenu du vertex buffer alloué par le driver.
Ta mémoire "privée" ne survit pas au delà de l'appel de fonction.
Si tu regardes son scope (local à la fonction, alloué sur la pile), ça prend tout son sens. Ce pointeur "pour l'initialisation"
est comme un argument passé à un constructeur. C'est indispensable pour une donnée marquée comme "immutable" par  
l'application (constante durant toute la vie de l'objet).
 
Bien entendu quand je dis "alloué par le driver" c'est en fait bien plus complexe que ça puisqu'il y a encore des interactions entre l'OS et le driver après ça puisque l'OS doit être capable de commander le paging in, paging out de la mémoire utilisée par le GPU, mais ça ce n'est pas lié à d3d10.

 
En fait microsoft a prévu deux modèles pour le scheduling, basic et advanced.
 
Basic est le mode qui tourne sur n'importe quel hardware. La riva TNT pourrait probablement tourner
dans ce mode s'il y avait un driver Vista développé pour elle (mais à cause de son absence
est obligé de tourner en mode XP donc il lui manque tout ce qui suit).
Le mode basic bénéficie de tout ce qui est généralement associé à Vista à savoir virtualisation
de la mémoire video (une application gourmande ne peut pas empecher une autre application
gourmande de tourner sauf s'il y a un manque de toutes les autres ressources, RAM système et
espace disque y compris), protection des accés mémoires (une application ne peut pas meme "accidentellement"
accéder au contenu rendu par une autre application, tel un bon paranoiaque toutes les surfaces
sont remplies de zéro systématiquement avant d'être réutilisées en mode paging in/paging out),
et bien entendu scheduling des tâches avec gestion de priorités. Par ailleurs, le driver d3d résidant désormais
en mémoire utilisateur n'est plus considéré comme fiable, puisqu'une application peut se faire passer pour lui ou
simplement corrompre la mémoire du driver (volontairement ou pas). La partie dans le noyau qui elle est considérée
comme "fiable" (trusted) a donc la responsabilité  
de détecter les erreurs possibles et les suites de commandes invalides qui pourraient en résulter.  
 
On voit que même en mode basic il y a de la marge pour ce qui est du support hardware: Est-ce que le GPU
est capable comme le CPU d'avoir un mapping de la mémoire différent par contexte ? ou est-ce que le CPU
doit faire une reprogrammation du GPU entre les passages d'un contexte à l'autre ? Est-ce que le GPU est
capable de voir une page de mémoire comme "cleared" plutot que d'avoir à toucher tous les bits au préalable ?
Est-ce que le GPU intercepte les commandes douteuses et prévient le reste du système ou est-ce qu'une suite
de commande non prévue peut mettre le GPU dans un état qui nécessite un reboot système ou une réinitialisation
avec perte de données ? L'absence ou non d'une de ces features dans le hardware permet d'économiser du cout CPU et GPU
mais ne change pas "à priori" la reactivité du système (en dehors du gain de perf s'il y en a).
 
Quelle différence avec le mode advanced donc ?
Le mode advanced nécessite une coopération plus fine entre le GPU et le CPU, le CPU pouvant cette fois-ci
envoyer une commande au GPU et PENDANT l'exécution de celle-ci, lui dire : "arrête, tu as pris trop de temps
j'ai une action prioritaire qui arrive", lui demander de switcher de contexte, sauver tous les états courants  
exécuter la commande prioritaire et reprendre son exécution un peu longuette.  
On voit donc que cela nécessite un support hardware assez avancé et un peu casse-tête. Il est possible
de faire des granularités "à la commande", mais ces commandes sont en elle-meme assez complexe et peuvent
prendre trop de temps du point de vue de l'OS. Quel temps pour executer une commande drawPrimitive ?
sachant qu'il y a un nombre arbitraire de triangles, avec un nombre arbitraire d'instructions dans le vertex shader,
que le geometry shader peut générer un nombre arbitraire de triangles lui-même, et que chaque triangle peut
couvrir un nombre arbitraire de pixels avec un nombre arbitraire d'instructions de pixel shaders, on voit que le temps  
d'exécution d'une seule commande peut etre arbitrairement long (secondes ? heures ? jours ?).  
Il faut donc que soit imposée une granularité encore plus fine, qui permettrait d'interrompre à une fraction
de triangle, voire à l'intérieur de l'éxecution d'un pixel shader/vertex shader (tant que le résultat n'a pas affecté
la mémoire il est possible de tuer simplement certaines exécutions).
 
Paradoxalement, un GPU qui serait un simple CPU faisant tourner un software rasterizer n'aurait aucun problème
à fonctionner dans ce mode. Après tout c'est ce que font les CPUs tous les jours depuis des années.  
Par contre une bête massivement parallèle, avec des mégaoctets d'états internes et  
pas forcément de moyen "bon marché" de rediriger ces états vers une mémoire de masse aura sans doute
plus de difficultés.

Des GPU sur l'Hypertransport ?
http://feeds.feedburner.com/arstechnica/BAaf?m=2722

Ou un PPU

 
ok j'étais trop optimiste
 
j'aurais espérer pouvoir mapper/remapper à la volée des espaces mémoires process comme des VB par exemple.

p16 de la 7950GX2: s/tant/temp/ (ligne ATI)

16

oops
P14 c'est dans l'avant dernier § de la conclusion (mais c'est corrigé maintenant )

Les temps d'accès sur de la flash c'est pas sensé être super top ?
 
Je veux mettre l'UBCD sur une SDCard, il y a plein de fichiers de qqes octets/Ko, ça copie à une vitesse ridicule, que ce soit directement depuis le CD, ou depuis le DD (CD=>DD ça a été très rapide). Keskispas ?

L'écriture de petit fichier ca a tjs été de la merde sur flash, HDD flash inclus (ceux qui n'ont pas de cache)

OK.
 
J'ai mis une SD super fast machin de crucial, c'est à peine mieux

L'iRAM ya que ça de vrai

ya aussi tout l'overhead de l'USB qui pourrit tes perfs

A propos de l'utilisation de la mémoire Flash sous Vista
http://www.pcinpact.com/actu/news/ [...] -Flash.htm

ca me laisse un peu de marbre cette soit-disant innovation majeure de vista...
les disques dur actuels sont bien plus perfs que 3mo/s, meme en utilisation plus-qu'intensive.  
ca sent l'usine a gaz tout ca...  

je vois pas le pb, depuis des années on plombe de l'arabe (forcément terroriste dans les jeux) où de l'allemand (forcément nazi), pour un jeu developpé en Iran il faudrait que ce soit GI Joe qui lutte contre les méchants hommes de couleur ?
Franchement je vois rien de choquant, en tout cas imaginez plutôt ces pays qui depuis 10 ans n'apparaissent dans les jeux vidéos comme des dictatures soutenant les kamikazes poseurs de bombes, l'effet que ça doit avoir...

Puis c'est un jeux video pas la réalité.

glod 2 : je suis bien d'accord!
puis dje, c pas la réalité c'est certain et heureusement mais faudrait pas non plus presenter ca comme tel sous couvert d'une quelconque idéologie. fut elle aussi politiquement correcte que combattre le nazisme
 
nan parce que si ca continue on va se faire fichier par la nsa des qu'on va jouer a un terroriste/allemand/alien dans un jeu vidéo en ligne

 
oué enfin y'a une différence sur des jeux sans arrière pensée volontaire (quoique), et un truc dédié par design à la propagande.
bon bref des trucs tendancieux ça toujours existé mais c'est vrai que c'est inquiétant de voir des nations même soit-disant évoluées se servir des jeux pour faire de la "communication".
 
bref monde de merde....

 
 
faut tout faire péter
 
 
2eme degré touca...  

Pour l'histoire de la physique par le GPU : ATI semble offrir une solution intéressante en permettant de coupler des cartes différentes !
Le top ce serait de pouvoir coupler les marques ! Une CG nVidia pour l'affichage, et une ATI pour la physique

Le top ce serait qu'ils arrête d'essayer de nous refourguer deux CG dans nos PC ...

Ouais, c'est vrai. J'oubliais que je suis partisans de la physique via CPU

Répetes après moi:  
 
"Je vais faire du SLI"
"Je vais faire du Crossfire"
 
"Je vais faire du SLI"
"Je vais faire du Crossfire"
 

 
- C'est pratique votre truc, ça éclaire dans la nuit -
 

C'est pour notre bien
(fake quote, je précise)

moi, je suis sur que c'est pour le bien d'Areva, d'Enel, de Suez et de EDF

si le SLI était sortit plus tôt, Enron serait encore en vie...  

a quand les gpu dual core ?

GF7950GX2
Je préfèrerais 48 "pipelines" et un débit mémoire doublé

Avec un PCB double face 16 couches

 
c'est mal barré puisque ATI veut nous en refourguer trois
(celà dit j'en avais une pour la 2D et deux pour la 3D ya quelques temps.. )

http://www.hardware.fr/marc/theater.jpg
 
Quel est l'avantage d'une solution qui fait fermer les yeux des présentatrices

http://www.anandtech.com/tradeshow [...] spx?i=2770
 
ATI and NVIDIA have been briefing power supply manufacturers in Taiwan recently about what to expect for next year’s R600 and G80 GPUs.  Both GPUs will be introduced in late 2006 or early 2007, and while we don’t know the specifications of the new cores we do know that they will be extremely power hungry.  The new GPUs will range in power consumption from 130W up to 300W per card.
 
Formidable si en plus il y en a 3 par pc    

Marc> La pauvre elle avait l'air fatiguée. Vive le Theatre 650 Pro
 
Et puis c'est en tentant de nous en refourguer 3 voire 4, qu'ils arriveront à nous en refourguer 2 plus facilement