Reprise du message précédent :

 
Pour passer du D3D10 ou au 11, à part le contexte de rendu qui est découplé du device pour pouvoir faire plus facilement du multithreading, ça reste une refactorisation légère.

 
De ce que j'en ai vu, c'est un refactor de fond au contraire. Le fait qu'ils passent les effets "à part" signifie clairement qu'ils vont se diriger vers un abandon total du truc. Ils ont abandonné les paramètres de shader basés sur le nom, pour passer sur du cbuffer only, augmentant grandement la complexité du bazar. Bref, franchement, ca m'a pas l'air d'être un switch très simple à faire.
 
Je l'estime limite du même niveau de complexité que le switch DX9 => DX10 d'après ce que j'ai vu.

 
Les Effets ont -toujours- été une surcouche, c'est juste qu'ils le sortent car tout le monde ne l'utilise pas, ils le rendent open-source parceque ceux qui ne l'utilisent pas ont leur propre solution mais aimeraient quand même voir la tronche de l'implémentation, et structurellement ce n'est pas le D3D en soit, c'est déjà un toolkit.
 
La philosophie du D3D a été depuis le 8, d'essayer d'être le plus pertinent/minimaliste.
Maintenant que ça deviens une API de fondation de Windows, (on pourrait dire qu'il est appelé à benner le GDI à terme), ce qu'ils sortent ils le mettent en open-source.
Après on verra comme ça évolue, mais c'est pas bien dramatique.
 

En tout cas, pour aller vite, j'ai réussi à compiler et à faire tourner GPU:3D avec le SDK de juin 2010, le problème étant que pas mal de couleurs sont "délavées" en sortie, et je n'arrive pas à voir d'où ca vient. Ca m'énerve. Même en faisant un output de couleur brut en HLSL, j'obtiens en rendu une couleur différente. Etrange quand même. Je vais finir par trouver

au hasard l'index des couleurs ? mal traduit ou alors mal compris

 
Nan, c'est pas grave, je sais pas trop d'où ca vient, je vais bidouiller et finir par trouver

 
sRGB ou pas ?
t'as une capture ?

 
J'ai exploré plusieurs pistes en fait (oublie pas que je suis pas un dieu de DirectX). La 1ère, prendre mon projet fait avec le SDK de Décembre 2006, updater DXUT10, linker avec Juin 2010, tenter la recompil : ca tourne, avec couleurs débiles.
 
Je suis en train de tenter le DXUT11 pour le coup, ca va ptêt me simplifier énormément la vie.

Sinon pour t'aider: dans VS2012 tu as PIX d'intégré, tu peux faire une capture de frame et parcourir l'historique de rendu d'un pixel.
Et ça c'est de la bombe de balle bébé.

 
Je connais absolument pas, faudra vraiment que je regarde

@Greg_kunn ton test Linpack tu l'avais fais avec quoi? LinX ou OCCT?
 
Sinon, j'ai mis 4x4Go sur mon PC là (4x2Go avant), et j'ai des erreurs OCCT en Large Data?
Ca pourrai venir de quoi? VCCSA? Vcore?
 
Plateforme LGA2011
 
Merci

 
J'ai fini par trouver : problème de correction Gamma

bjone doit petre promu programmer assistant moi je dis

bjone en vaut une dizaine comme moi de programmeurs, c'est un fait
 
Yna plein de fois où je décroche sur ses posts

C'est bon, toutes les fonctions sont de retour sous GPU:3D DX10, ca devrait fonctionner sous Windows 8 (je peux tester que ce soir sur Windows 8 par contre).
 
Stay tuned

Validé vite fait en mode "sans error check" pour le moment (je suis au taff) sur un Windows 8 en plein écran, réso full HD 1920x1080, ras.
 
Hell yeah, la béta approche les gô.

Je suis de plus en plus sceptique sur l' utilisation d' occt pour tester la stabilité de mon Oc .
Pour passer le test il me demande un voltage de 1.36v alors que j' utilise mon pc depuis 15 jours à 1.32v ( jeux , encodage vidéo ,...) sans aucun plantage .
A 1.32v tout est parfaitement stable et le  stress test d' aida 64 (recommandé par asus entre autre) passe sans soucis.

Je pense que si tu tiens ce raisonnement, tu as un problème avec la définition de stabilité. Un outil de test de stabilité se doit d'être exigeant. Son diagnostic "pas d'erreurs détectée" doit être fiable. OCCT demande 1.36V pour que son algorithme passe, ce qui signifie que à 1.32V, il détecte un truc qui foire.

Maintenant, cela veut dire quoi ? Que à 1.32V, tu as une instabilité. Aida64 le voit pas, OCCT le voit (la preuve étant que le test passe en changeant juste la tension du proco). OCCT est donc un outil bien plus précis et fin pour détecter l'instabilité potentielle.

Car on parle de certitude en termes d'instabilité. Le jour où ton PC crashera à la fin de 6h d'encodage, te fera un artefact en plein milieu, car pas de bol, tu regretteras de pas avoir suivi le diagnostic d'OCCT. Tout est une question de "chance" dans l'affaire. Et quelle inconnue veux-tu induire dans le fonctionnement de ta bécane ?

A 1.32V, tu as, admettons, 7% de chances sur un gros traitement d'avoir une erreur.

A 1.36V, 2% de chance (OCCT n'est et ne sera jamais parfait).

Tant que tes encodages se passent bien, tu préféreras Aida64, qui t'as mis une config stable à 93%. OCCT, lui, t'as prouvé que tu étais instable, tu ne l'as pas suivi, et pour l'instant, tu n'en vois pas l'intérêt (ton PC n'a pas planté).

Mais le jour où il plantera, tu regretteras. On est habitué, on impute les crash aux drivers, aux bugs, et co. N'empêche qu'en suivant le diagnostic d'OCCT, tu avais encore moins de chances d'avoir le plantage. Voire, t'en aurais pas eu du tout.

Des analogies, on peut en faire plein. N'empêche que le diagnostic d'OCCT est plus fin, et de meilleure qualité dans ton cas. Pourquoi ne pas le suivre ? Quel intérêt ?

A mon sens, plutôt qu'augmenter la tension, tu ferais mieux de baisser un peu ton overclock. Tu serais alors stable à 1.32V sous OCCT. Tu perdras 0.01% de perfs. Et tout le monde sera gagnant.

L'analogie la plus démonstrative est celle-ci : tu vas voir un médecin pour un problème, il te dit "oh, ca va, c'est juste une grosse angine". Tu vas voir un second médecin, il te demande de faire des examens complémentaires car "il y a de grandes chances que ce soit une grosse angine, mais ca peut être aussi un cancer de la gorge, vérifions". Tu choisis le 1er avis, si tu as effectivement une angine, tout va bien. Si tu tombes dans le cas 2, tu regretteras amèrement.

C'est exactement la même chose.

Avoir OCCT le plus exhaustif possible, pour donner une confiance supérieure dans le résultat, a et sera toujours mon but. Je suis pas un vendeur de "bonne nouvelle !" parce que "j'ai vu un truc qui déconne mais boah c'est pas grave". Nan, stable, c'est stable, point. Ca fait plaisir de se dire "on CPU est stable à 6Ghz avec 1.32V". Sauf que dans ton cas, ce n'est pas vrai.

Après, si avoir une config instable te dérange pas, libre à toi. Mais le problème n'est pas l'outil (il te détecte une instabilité), mais toi (tu veux un PC qui tient "grosso merdo" ). Prends des gens qui font du calcul scientifique : peuvent'ils se satisfaire du diagnostic d'Aida64 ?

Souviens-toi aussi du tollé du bug de la FPU du pentium 1. Une connerie d'arrondi sur le 14ème chiffre de la mantisse, un truc du genre. Toi, tu prends sciemment un risque bien plus grand.

OCCT PT 4.3.3.b01 OUT !
 
Changelog :
 

• GPU:3D updated : should now work on Windows 8 (Damn Microsoft)
• You can now specify how many threads CPU:OCCT will use
• OCCT should start normally in Failsafe mode (without monitoring)
• Some minor bugfixes

Enjoy !
 
http://www.ocbase.com/download.php?fileext=beta
 
Tests à faire :

• GPU:3D à triturer sous 7 et 8 (ca m'a l'air correct)
• OCCT en mode sans échec (me dire si ca tourne, etc)

Merci

Dites moi si ca tourne bien sous 8 pitié pitié pitié

Mon Dieu, une nouvelle version, je vais encore devoir rajouter du vcore lol...
 
Déjà le 4.3.2 m'a demandé un bon cran de vcore en plus par rapport à la 4.3.1

Laisse nous le temps de DL iench', tu crois qu'on a tous du 20MB ?
Je te dis ce que donne GPU:3D sous Windows 8 dans quelques minutes.

EDIT : le test se lance pas et me dit : arrêté par l'utilisateur. J'ai réglé en réso native, et coché plein écran + détection d'erreurs. J'ai une GTX 670, mode DirectX 10.

 

 
Je suis assez impatient j'avoue (et mes collègues qui ont testé et qui ont vu ce que j'ai pondu m'ont regardé bizarre, ils me prenaient pour un pur chef de projet/fonctionnel, et ben finalement... nan).

Ah, j'avais pas vu que tu avais répondu. J'ai édité mon message.

Le test se lance pas et me dit : arrêté par l'utilisateur. J'ai réglé en réso native, et coché plein écran + détection d'erreurs. J'ai une GTX 670, mode DirectX 10. J'ai mis la taille des shaders à 3 comme le conseille le logiciel.

EDIT : en mode fenêtré ça se lance mais la fenêtre est minuscule et illisible alors qu'elle devrait être en 1680*1050.

 
Alors là, c'est bien étrange. Je pensais que les changements en termes de mémoire partagées sous 8 étaient liés à metro, pas à winforms
 
Tu peux essayer de lancer dxwebsetup avant pour être sur, en le prenant par là ? http://www.microsoft.com/en-us/dow [...] aspx?id=35
 
Je pourrais pas débugguer plus en avant avant ce soir, quand j'aurais accès à mon Windows 8

J'ai déjà fait une màj DirectX, mais je vais la refaire si tu veux, j'ai le setup complet sur le HDD (t'inquiète pas, il est à jour, j'ai une petit connexion alors les websetup ne sont pas mes amis).

EDIT : DirectX à jour, ça ne change rien. Les mêmes symptomes, et j'ai essayé d'autres résolutions pour le plein écran ou le fenêtré : aucun changement. J'ai les pilotes GeForce 310.74 pour info. Y'a peut-être un souci avec ma config, d'autres retours seraient les bienvenus !

Testé sur un PC sous 8 au boulot, avec une quadro, ca tourne.

J'ai la même CG que toi moonly, je teste ce soir @home.

Une option : edite le fichier GPU3DName.txt dans le dossier OCCT et mets un nom d'executable bidon dedans, par exemple moonly.exe

En tout cas réso native + dx10, ne plante plus avec le message "Crysis2.exe" à cessé de fonctionner

 
Sous quel OS ? Et quelle carte ?

Seven 64, GTX 570 (310.70).
 
J'ai bien dis que ça ne plante plus ^^
 
Car ça plantais avec l'ancienne release.

C'est déjà ça
 
Reste à comprendre pourquoi ca foire chez moonly. Je vais esasyer de reproduire, dommage, j'étais sûr de mon coup.

C'est surement moonly le problème

Sous Win8: (mon avis ça doit être pareil sous Win7)
 
DX10 fenêtré + Détection d'erreurs, après un redimensionnement (histoire de changer de resize), le viewport (ou autre) de rendu est à la ramasse, le nombre détectées d'erreurs s'envole.
Le process crashe de manière sporadique au déplacement/redimensionnement.
 
DX10 plein écran: crash au alt-tab.

DX9 plein écran: écran noir au alt-tab, vol de focus (état plein écran foireux).
Mais au moins le process réponds aux messages.
 
edit: a mon avis ce sont de bugs qui sont présents depuis des lustres.

 
Oui. Le resize est très complexe à gérer, cela m'impose de tout recommencer à 0.... je ne le supporte pas du tout pour le moment. Le Alt-Tab est plus surprenant par contre.
 
L'important, c'est que ca tourne sur Windows 8. Tu as une AMD/Nvidia? Avec quels pilotes stp ?

Même résultat. Juste pour clarifier : OCCT est lancé en admin et mes jeux tournent très bien. Donc soit y'a quelque chose chez moi qui l'embête, soit ton code a un souci.

J'ai pensé à un truc, j'ai forcé la VSync adaptative dans les pilotes, ça pourrait être le problème, je vais tester sans.

EDIT : même résultat. En mode fenêtré, si je veux redimensionner la fenêtre, j'ai "Crys2.exe a cessé de fonctionner". J'ai remis le nom de l'exe par défaut, mais j'ai les mêmes résultats en le changeant à nouveau. J'ai tout essayé : différentes tailles de shaders, différentes résolutions, le resizing de la fenêtre, avec ou sans détection d'erreurs, mode plein écran/fenêtré etc. mais ça ne marche pas chez moi.

Je veux bien croire qu'il reste quelque chose qui le gêne. Il faudrait que j'essaye en fermant le plus de processus possibles dès que j'en ai l'occasion.

 
Ca m'étonnerais... Je vais regarder si je reproduis...

Arf, encore une fois, j'ai édité après que tu ais répondu. Dès que j'ai le temps j'essaye le plus d'autres scénarios possibles. J'espère qu'on trouvera (pour toi surtout, de mon côté c'est pas grave du tout).

Ca DOIT marcher, c'est aussi simple que ça.

Sur ma config, drivers Nvidia relativement récents (faudrait que je regarde lesquels exactement, mais ils ont deux semaines), GTX670, ca tourne. Par contre :

• Au 1er lancement, smartscreen m'a bloqué machin. Saleté.
• 3 lancements successifs de GPU:3D ont fail, en fullscreen. Plusieurs lancements plus tard, c'est tombé en marche, et depuis, no soucÿ.

==> Un test antivirus/sécurité qui bloque ? J'en sais rien. C'est étrange. Impossible à reproduire depuis. Je me demande si ce n'est pas smartscreen qui bloque le test 3d qui, lancé par OCCT, n'affiche pas de warning du coup (OCCT tourne en admin).

Si c'est ça, franchement...

Moonly, tu peux désactiver smartscreen ? http://techmell.com/how-to/turn-sm [...] windows-8/

Tetedeiench> 2 bug avec la dernière beta, test 3D en DX10 :
1) quand je déplace la fenêtre, sans détection d'erreur j'ai un "Crysis2.exe a cessé de fonctionner", avec détection d'erreur l'image passe au noir mais pas de plantage.
2) difficilement reproductible mais j'ai eu une exception du module ZedGraph au moment de quitter OCCT à la fin d'un test 3D. Je pense que j'ai quitté au moment où les graphes étaient générés.

Shaders à 1
Win7 64bit
ATI Radeon 5k
Catalyst 11.12 beta8