Reprise du message précédent :

 
Mon souci, c'est que l'executable sera lié à quoi, si j'utilise le SDK DX11 ? à la DLL D3Dx11.dll (et consorts), non ? Donc du coup, ca va obliger de faire des déploiement. Enfin, faut que j'étudie la chose, mais c'est comme ça que je le comprends. Dx11 tourne sur des cartes Directx9... mais doit être installé. Donc si tu as vista, tu dois installer DirectX 11. Si tu as XP, tu peux même pas le lancer.
 

j'y réfléchis, mais bon, si je peux avoir un truc qui marche out of the box, ce serait mieux

J'avoue avoir eu un doute. Si c'est le cas, t'es de toute façon obligé de te taper 2 SDK, un peu lourd

Je pensais surtout à la version DX9 qui ne fonctionne pas chez certains utilisateurs d'XP (dont DirectX n'est pas à jour, faute à MS qui n'inclut pas les MAJ de DX dans Windows Update, bien que s'agissant d'un module intégré de base dans leur OS). T'aurais moins d'ennuis avec ces utilisateurs.

Exactement C'est ce que je veux éviter dans l'avenir.

Pour DX11, il semblerait que je puisse m'en sortir via du dynamic linking, mais faut que je creuse. En gros, faire le boulot du linker à sa place, quoi, en code.

Ah putain, ca m'aura causé énormément de soucis, cette histoire

KB971512 est nécessaire sous Vista
Bon, on doit pas être nombreux à tourner sous cet OS

A priori je peux m'en sortir assez facilement. Au début, j'avais peur de devoir faire du getprocaddress pour chaque fonction. A priori, je peux m'en sortir avec un seul getprocaddress
 
On verra bien ce que ca donne

J'suis en train de télécharger le SDK DX11 (Juin 2010), et je vais vérifier qu'un projet qui target DX9 fonctionne bien sous XP (j'suis au taf ). J''étais convaincu jusqu'ici que cela pouvait fonctionner, et avoir 1 seul projet et 1 seul SDK ça serait quand même bien mieux.

 
Rah, le pied.
 
Par contre, tu vas devoir fournir un rendering path DirectX9 pour que ca fonctionne...

C'est ce que je voulais dire par "qui target DX9".
Si ça fonctionne sous XP, il n'y aurait pas de raison que ça fonctionne pas en DX10 sur un Vista n'ayant pas DX11.
-> 1 seul SDK, 1 seul projet, 2 rendering path (DX9&10).

Je vais paraitre catégorique, mais je pense que pour ceux qui on XP faut proposer le test DX9 actuel (p'tet adapté a la v4 sans plus), et pour les autres on propose un DX11 up to date qui va stresser plus les GPU (à priori) dans leur OS.
 
Pour DXWEBSETUP, au pire si on a XP SP0 et qu'on DL le dernier SDK on a meme pas 100Mo de DL... et comme beaucoup de monde à déjà des update DX, on va pas DL plus qu'une poignée de Mo.
 

J'suis encore sous Vista, mais de toutes façons y'a belle lurettes que cette update est fetch via Windows Update en MAJ critique.

Tant que ça fait chauffer
 

Ah, cheusavépo
J'avais installé mon Vista 1 mois après la sortie de ce kb

je l'ai encore sur mon portable en quadriboot vista integrale

J'ai envie de crier ma colère, même si c'est la faute à personne.
J'ai lancé un occt en large data set, durée infini.
Erreur détectée sur le cœur 5... à 1h00 et 17 secondes.

fail  

Sans rien changer ça fait déjà 1h20 qu'il tient pour l'instant. Je crois que c'est quand j'ai lancé evga eleet (dérivé de cpuz mais qui permet de modifier des paramètres d'OC) pour voir le vcore que ça a fait l'erreur.

Bon, je vais devoir me trimballer avec deux portables demain, je suis super heureux Tout ca pour GPU:3D

a cause de quoi ??

Bha si ça plante, c'est que ce n'est pas stable. Donc faut modifier quelque chose à tes paramètres d'OC et non aux logiciels que tu serais susceptible d'exécuter pendant que OCCT tourne. ^^

il n'y avait pas une histoire avec cpu-z qui provoquait un bug avec occt lancé ou quelques choses comme ça?

Ouai, mais alors, vla le merdier à gérer. j'ai enfin pu tester ce matin (grâce au second portable), et ce que je peux dire est assez simple

J'ai pris le dernier SDK DirectX11. J'ai pris un sample relativement basique, qui propose, via DXUT, un rendering path DX9 et un DX10.

J'ai remplacé la création du device D3D par un loadLibrary et un getProcaddress. Je lui file à bouffer le device DirectX9 qui va bien.

RAS, ca fonctionne, je suis plutot content.

je vire la librairie D3D9.lib dans les propriétés du projet.

Et là PAF, impossible de passer le linkage, car il manque des fonctions de D3Dx9_43.dll . ben ouai, autant le D3DCreate gère les fonctions de D3D9.dll (tout seul comme un grand), autant il ne fait pas la même chose avec d3dx9_machin.dll. Donc faut faire un getProcAddress d'une vingtaine de fonctions.

Et je me retrouverai aussi linké avec D3Dx9_43.dll, alors que je peux tourner avec des versions bien antérieures... à moins que je fasse un loadlibrary d'une version antérieure avec le SDK DX11, mais à mon avis, ca risque de foirer

Bref, c'est pas gagné. je pense franchement que deux exécutable, deux projets, deux SDK resteraient limite plus simple.

Ou alors, je vire DXUT Et je fais mon propre truc. A voir. Ca prendra plus de temps, mais au moins, ca sera propre.

Est ce Occt bugue?
Il m'indique que le 12V fait 12.94V!

C'est pas un bug, c'est une interprétation d'une des valeurs renvoyées par les sondes de ta carte mère Si plusieurs logiciels de monitoring te disent la même chose, c'est bien que ton 12V est à 12,94V.

Du coup, faut'il vraiment se prendre la tête avec tout ce bordel D3D, pour gérer un seul exécutable ? Je pense pas.
 
A la rigueur, en faisant une bête classe "interface" qui fait le passe-plat entre DirectX 9 et/ou 10 et mon code (j'ai pas non plus un nombre énormes d'appel, contrairement au framework), les fonctions du framework étant identiques, cela ne devrait poser aucun souci.
 
Va pour deux framework distincts, donc je framework DX10 out of the box et le DX9, pour pas avoir d'emmerdes

Hardware monitor me dis 11.82V, et Speedfan 12,25V.

Aucun n'est buggué, ils ont tous des interprétations différentes

Euh oui mais 12.94V avec Occt ça fait peur.
J'ai mis aida pour le monitoring à la place.
Comme ça le graph ressemble plus à quelque chose en 12V.

Tu peux faire confiance aux valeurs renvoyées par ton bios

Moi j'utilise un multimètre, au moins je suis sûr du résultat c'est vrai que le bios est généralement juste

Pareil j'avais des soft qui déliraient total sur le 12 et 5 V de mon alim (Seasonic S12 II 620W)
 
Selon les softs c'était entre 8.8 et 10 pour le 12 V et 1.5 a 3.3 pour le 5V
Du coup multimètre:12V=12V et 5V=5V

Juste comme ça. Comment peut-on faire pour afficher les infos d'un CPU que OCCT n'arrive pas à reconnaître ? (si c'est possible).

Tu prends le cpu a obi-wan
 

 
 
 Toshop    
 
..............

http://www.pcinpact.com/actu/news/ [...] tm?vc=1#vc

Je viens de voir ça! Cool!  

ca cest la reconnaissance  
on prend les paris ? moi je vote pour une news sur ananda et tom's le jour de la sortie officiel

 Tetedeiench  
 
désolé je prends le topic en cours et y'a une fonction que j'aimerais bien voir sur la version 4 et que je trouverais pas mal (je suis peut être le seul mais je propose).
 
Ce qui serait chouette c'est une fonction similaire à l'overdrive de chez AMD. Je m'explique : OCCT lance un test de 30 minutes, si c'est stable il sauvegarde les graphiques puis augmente le FSB de x MHz (fonction réglable par l'utilisateur) et recommence le test pendant 30 minutes, ect ...... en cas d'erreur ben le test s'arrête !  
 
Perso je trouve que ce serait chouette comme solution !  

Ben c'est trop spécifique comme fonction.
Les CM ont tous des chipsets, PLL différents.
C'est impossible de rassembler toutes les données.

oui effectivement j'avais pas vu plus loin (réveil difficile)

 
Effectivement, on me l'avait demandé, et cela avait été ma réponse à l'époque

Petites infos :

• Je vais sortir l'alpha de la v4 sans le test GPU:3D en DX10 (chaque chose en son temps)
• j'ai reçu des demandes pas trop idiotes : générer un log de toutes les caractéristiques techniques du PC lors du test (je sais pas encore quelle forme cela prendra, soit un fichier log, soit une image avec du texte dedans... à voir).
• Pouvoir "programmer" et enchainer les tests. Pourquoi pas

bref, ca avance encore et toujours