Reprise du message précédent :
Non, mais là, tous les types, primitives, et compagnie, ont changé, hein.
 
le code d'origine encore je comprends, mais la version DX10, va falloir potasser les tutorials :

Ah voui plus dans ce sens là...

Gaffe, ça peut arriver à tout le monde ...
http://www.clubic.com/internet/fac [...] coder.html

J'ai eu une bonne idée pour l'avenir d'OCCT Stay tuned, on va voir si ca peut se faire...
 
Le projet est loin d'être mort

Caÿ possible d'avoir un peu plus d'info sur cet avant goût? faut attirer le chalant.

je plante ma tente dans le coin juste en cas

Tout ce que je peux dire, c'est que je reviens à certaines idées abandonnées.
 
Remarquez, ca veut trop rien dire, car j'ai mis pas mal d'idées ici qui n'ont rien donné, mais bon.
 
Je vous en dirai pas plus pour le moment

ca vas etre forcement une bonne idee

Ben au début ca a toujours l'air bien; Après, ca l'est moins.
 
Boah, on verra.

sur le papier ca parais super ... puis quand il faut le coder ..... d'un coup c'est moins bon

version bootable sur usb ?

Peut-être. Ou pas.

OCCT GPU:3D + Nvidia + GPU-Z pour désactiver la limitation =
http://www.overclock.net/nvidia/92 [...] d-gtx.html
 
Wow

putain oui deux vrm qui sautent, et du PCB brulé jusqu'aux nodes mémoires

 Il manquerait plus qu'il te demande un remboursement
 
Sévère quand même

ma chere et tendre suggere de mettre les photos sur ta page dans une galerie des "morts pour la cause"  
 
perso je mettrai le lien vers le cimetiere dans le disclaimer " power tool for power user use @ your own risks "

on est 7, là !  
Ta légende nous a tous fait crever de rire

Je vote pour la galerie mort pour la cause.

merki

Je vote non
Ce n'est pas bon pour une réputation (ou la descendre en flêche) de montrer le côté négatif

pas tout a fait d'accord dans des conditions normales d'utilisation il n'y a que tres peu de risque. le gars a voulu jouer au dessus des limites.

c'est pas faux  
donc non t'as raison  
 
a moins que le iench la fasse en access restreint dans un coin

Bon, je viens de faire un test avec la v4 mais il ne détecte pas mon OC. La v3, par contre, le détecte...
 
Je ne sais pas si c'est mon pc ou OS ou la v4 mais bon, je vais faire d'autres tests pour voir si le soucis persiste

drapal

AAAAAAAaaaaaaaaah mais putain quelle idée d'avoir enlevé toute fonction du pipeline fixe dans D3D10 et d'avoir tout foutu en vertex/pixel shader
 
Putain la complexité que cela engendre mais ils sont fouuuuuuuuuuuuuuuuus
 
Putain faut que je refasse tout là, pas de portage possible, à part les modèles/textures que j'utilise, me vla à recoder entièrement GPU:3D

Et moi qui pensais que cette "unification" était là pour simplifier la vie des développeurs
Bon courage

arf ... courage

Dans tous les cas tu lacheras la version stable de la 4.0 avant la refonte non ? (et la 4.1 pour la suite avec DX10 ?)
 
Bon courrage !

Ouaip Le nouveau GPU:3D sera pour la 4.1.0.
 
C'est clairement bien plus complexe coté dev. Enormément plus.

Bienvenue.
 
Je connais bien ça avec java et la disparition de "hol" avec comme solution downgradé à java 1.6.23, mais bien sûr... Casser la compatibilité c'est cool...

C'est une autre API donc y'a pas a avoir de rétrocompatibilité à supporter... Sinon ça serait la même API...  

elle roule super la beta 16 chez moi.
 
apparemment l'algo de occt cpu change après 4 minutes, non ?
je passe de coeff x51 sur mon i5 2500k à 42x pour rester dans le tpd 120 watts (que je mets dans le bios de mon asrock fatal1ty pro p67).

Ça alterne les passes "small/large data set"
C'est le "small" qui fait le + chauffer/consommer et donc provoque la chute du coeff. chez toi ...

ok bah je trouve ça cool, vais tester ça avec le forçage du mode

occt cpu small test: x41 300 Watts watt mètre (pc complet - écran), 95 W (throttlestop 3.00)
occt cpu medium test: x44 309 Watts watt mètre (pc complet - écran), 95 W (throttlestop 3.00)
occt cpu largetest: x44 309 Watts watt mètre (pc complet - écran), 95 W (throttlestop 3.00)

Leiench, serait-il possible de rajouter le monitoring realtime du multiplier ? Pour le moment dans le gui au niveau monitoring car ca reste sur x51
dans mon cas, qui est la valeur max, mais qui diminue en fonction de la puissance a dissiper (38x sur l image).

cpuz sait le faire.

il attends justrment le nouveau moteur de detection de cpu id avant la version final (une autre beta peut etre entre temps)

sinon il y a aussi un manquement du chiffre 0 dans le graph core numero 1 2 3 ...:
 
2011-10-02-13h51-Core #.png
ca devrait être 2011-10-02-13h51-Core #0.png
 
les autres sont ok (2011-10-02-13h51-Core #1.png, 2011-10-02-13h51-Core #2.png, 2011-10-02-13h51-Core #3.png)

xixou2 : fixed pour le n° du core. La fréquence dépend effectivement de la MAJ du SDK (la v4 actuelle aime pas sandy bridge).

GPU:3D DX10 avance doucement, j'ai porté la génération des textures (ca a l'air de rien mais c'est déjà pas mal).

Evidemment, j'ai pas encore porté le shader, donc je peux pas voir le résultat final

mais bon, c'est un bon début

le SDK arrive, mais les petits gars de CPU-Z sont débordés, donc patience... Comme il a surement des clients bien plus important que moi, je lui ai dit de faire passer tout le reste avant. Ca retarde la v4, mais bon, c'est pas dramatique.

Stay tuned !

Vous emballez pas en tout cas, y en a encore pour quelques mois de taff sur GPU:3D pour le coder propre, hein

J'en suis loin

Mais la génération de la texture était un des trucs sur lesquels j'étais le moins confiant... le truc sur lequel je suis le moins confiant étant la détection d'erreurs. Tout se passe sur le GPU donc y a pas de raison, m'enfin...

Te bille pas, Émile ça va le faire !
je te soutien

Avec un peu de chance le SDK que tu attends sera compatible buldo et ca te fera d'une paire de couille pierre deux coup.
 

si c'est basé sur cpu-z, la dernière version est compatible avec
 
- AMD FX "Bulldozer" processors family (K15).
- AMD Llano processors family (K12).
- Intel Sandy Bridge-EP processors preliminary support.
 
juste le SE qui ne doit pas être à jour