Oui. Tous le font pour pas laisser les possesseur d'amd sur la touche. Tu peux me sortir une liste des softs ça change rien au fait que c'est la vérité. L'implementation d'openCL est une cata, ça s'améliore progressivement (heureusement) mais c'est de la merde quand on regarde la facilité avec laquelle on fait la même chose sur cuda.

Chez nv tu peux décider d'intégrer l'acceleration gpu après coup sans devoir refaire ton app, si tu veux pas trop te faire chier tu droppe des hints dans le code pour dire au gpu de faire les calculs qui font ralentir ton app et c'est transparent. OpenCL ? Recode.
Il suffirait que amd accepte de payer nv pour intégrer cuda a ses cartes (et dev le hard qui va avec) pour que toutes les apps se prennent un boost massif dans les dents.

Mais non, on préfère se la jouer "open" (ahaha y'a qu'a voir comment ça réussi bien leur approche sur leurs drivers linux, Torvalds peut bien faire des doigts tant qu'il veut, les drivers linux de nv bien que fermés sont a des kms de ceux de amd) et avoir un slip tout propre devant les gogos en étant (mollement) derrière une initiative qui de toute façon ne sera jamais un standard.

On doit rappeler leur techno qui devait contrer chez amd ? ATI Stream ? Non, ah ben oui c'est le truc qui aurait pu marcher mais comme on a pas eu le Khronos Group derrière comme toujours chez amd ça n'a pas marché,effet d'annonce comme d'hab..

Pendant ce temps là chez NV, en attendant que Freesync se pointe on avance.

Résumons :
-tout ce que fait AMD est pourri
-tout ce que fait Nvidia est génial
-tout ce qui est fermé est génial
-tout ce qui est ouvert est pourri
-le support d'OpenCL par toutes les plus grosses boites d'édition vidéo n'existe que par pure charité
-OpenCL est de toute facon pourri et ne sert à rien.

C'est bien connu. L'absence d'alternative et de concurrence est ce qui fait progresser le monde du logiciel.
Et c'est un vrain bonheur de développer dans des environnements tout verrouillés. Prenons Apple par exemple. J'adore devoir galérer avec des certificats et des provisionning profile juste pour avoir le droit de tester mon appli développée avec mon mac sur mon téléphone.

CBL a écrit :
Prenons Apple par exemple. J'adore devoir galérer avec des certificats et des provisionning profile juste pour avoir le droit de tester mon appli développée avec mon mac sur mon téléphone.

Je cite Patrick Sébastien : "c'est bien fait pour ta gueule".

Allez, en vrac, quelques autres "billets d'humeurs" sur l'état d'OpenGL (toujours en anglais) :
http://richg42.blogspot.fr/2014/05/the-truth-on-opengl-driver-quality.html
http://www.joshbarczak.com/blog/?p=154
http://aras-p.info/blog/2014/05/31/rant-about-rants-about-opengl/

J'espère sincèrement qu'OpenGL va continuer à être maintenu, ça ne me plait pas du tout cette tendance actuelle à splitter les API en autant de formats propriétaires (de fait) et verrouillé à une plateforme/constructeur/génération.
Ca change pas grand chose pour ceux qui utilisent Unity/UE/CryEngine, mais pour ceux qui développent from scratch ça va devenir un bordel ingérable dès qu'on va vouloir faire quelque chose de multi-plateforme...
De plus, je trouve que le cout des draw calls est largement surestimé, la preuve les gains de Mantle s'avèrent en pratique négligeables (c'est à dire rien sur une config équilibré, et à peine 20% sur une config avec un CPU en retrait). J'ai pas l'impression que ça vaille vraiment le coût de créer un tel bordel pour ça...
Et puis OpenGL a déjà connu des simplifications, c'est de la mauvaise foi d'écrire qu'il se traine 20 ans d'heritage: OpenGL 3.0 (ES 2.0) a justement remis pas mal de choses à plat en 2008, en virant le fixed pipeline. Maintenant c'est clair qu'il serait pas mal de passer encore un coup de balai et d'unification.

"(ils était déjà à l'origine de Mantle)"

Metal ou OpenGL, ca pique les nieux! :)

Faudrait qu'ils arrêtent d'utiliser des noms de merde par contre. Le mot clé Metal risque pas de donner grand chose sur Google.

btw, il faut un nouveau truc (un OpenGL 2 ou nouvelle implementation), mais faut un truc standard et multi plate-forme (!)

Apres je crains que les acteurs principaux ne jouent pas le jeu, chacun veut faire son API. Du coup aucun ne risque de vraiment continuer a vraiment supporter/ameliorer OpenGL, alors au final on avoir une API passe partout mais peu performante vs plein d'API performante au prix d'un effort colossal pour toute les prendre en main.

Si on en croit ces présentations : GDCVault - NVidia, il est déjà possible de réduire l'overhead en OpenGL avec des fonctions standards et certaines extensions.
Donc quel est l'intérêt de faire un fork ? Ce n'est (ne sera) pas dispo en OpenGL ES ? Ou c'est vraiment juste pour avoir une API propriétaire et se retrouver avec des portages Android nazes ?

Pour une fois je vais remercier Apple d'avoir choisi contre vents et marées de mettre 2 FirePro AMD dans son Macpro.
Si ca peut ameliorer OpenCL et me permettre d'avoir davantage de choix pour une carte graphique, c'est parfait.

CBL a écrit :
Résumons :
-tout ce que fait AMD est pourri
-tout ce que fait Nvidia est génial
-tout ce qui est fermé est génial
-tout ce qui est ouvert est pourri
-le support d'OpenCL par toutes les plus grosses boites d'édition vidéo n'existe que par pure charité
-OpenCL est de toute facon pourri et ne sert à rien.

C'est bien connu. L'absence d'alternative et de concurrence est ce qui fait progresser le monde du logiciel.
Et c'est un vrain bonheur de développer dans des environnements tout verrouillés. Prenons Apple par exemple. J'adore devoir galérer avec des certificats et des provisionning profile juste pour avoir le droit de tester mon appli développée avec mon mac sur mon téléphone.

J'ai pas mal hésité avant de répondre a ça tellement ta mauvaise foi joue a mon avantage mais bon, j'ai du mal a rester en place. Donc:

CBL a écrit :
-tout ce que fait AMD est pourri

BeatKitano a écrit :
, Freesync c'est cool j'admet reste a le voir en action (amd style)

CBL a écrit :
-tout ce que fait Nvidia est génial

BeatKitano a écrit :
Bon pis un peu hors propos,mais pour prouver ma bonne foi quand il s'agit de ce sujet: nv fait aussi de la merde, mais pas en software:

Depuis la 580 ils n'ont eu de cesse que de réduire le bus mémoire (384b>256) limitant fortement la force de traction des cuda core pour faire vendre plus de quadros. Et ça y est c'est reviendu avec la 780 ! Ouf.

CBL a écrit :
-tout ce qui est fermé est génial
-tout ce qui est ouvert est pourri

BeatKitano a écrit :

CBL a écrit :
-le support d'OpenCL par toutes les plus grosses boites d'édition vidéo n'existe que par pure charité

J'ai hésité avec l'image du désert, la charité ? Non seulement t'es de mauvaise foi mais en plus... non rien. Donc "source" ?

CBL a écrit :
-OpenCL est de toute facon pourri et ne sert à rien.

Ah fuck it... you win.


Ah et ça aussi

CBL a écrit :
C'est bien connu. L'absence d'alternative et de concurrence est ce qui fait progresser le monde du logiciel.
Et c'est un vrain bonheur de développer dans des environnements tout verrouillés. Prenons Apple par exemple. J'adore devoir galérer avec des certificats et des provisionning profile juste pour avoir le droit de tester mon appli développée avec mon mac sur mon téléphone.

Ce qui est un vrai bonheur c'est ton argumentaire qui consiste a dire que le developpement privé c'est ultra mauvais tout en tentant de faire passer l'idée qu'un standard ou personne n'innove a base d'openCl c'est mieux. On continue sur ton chemin et on dit que directX c'est la meilleure chose a jamais ou ogl si ça te fait plaisir. Ah on n'innove plus alors ?

La vérité c'est que les standards ont l'inconvénient de ralentir les développements, le temps que tout le monde se mette d'accord on créé une entente technologique, qui nuit aux idées saugrenues mais bonne qui pourraient jaïr par un développement privé. Au final on se retrouve avec des api qui moisissent, avec tous les acteurs qui font grosso merdo la même chose, et une technologie qui stagne là ou elle pourrait aller nettement plus vite avec les lois du marché... Attention je te vois venir avec tes gros sabots: OUI des standards il en faut, on est d'accord. Mais si on standardise tout dans un milieu aussi high tech on peut être sur que la stagnation va être sévère et on va se retrouver avec des cartes super chères qui ne font rien de plus que la précédente que de faire la même chose plus vite...

T'achetes une cg nvidia tu attends une plus value, tu l'as, t'achetes amd, ta plus value tu te la fous au cul (ah si, eyefinity, tu vois encore un truc génial de amd et même pas peur de le dire !) et tu pleure pour avoir le taf de la concurrence. De la cohérence bordel §% et la encore: aucun des deux constructeurs n'a créé de partenariat avec des api qui empêchaient le concurrent de faire tourner le jeu... de quoi tu te plains.

C'est un choix, les devs sont pas idiots: ils cherchent pas ta fameuse charité, ils cherchent la rentabilité et par conséquent ont TOUT INTERET a supporter les features des deux acteurs. Pas de bol si t'as choisi la mauvaise carte (et je dis ça en assumant pleinement mon propos le jour ou amd saura créé une techno que je veux et que je ne peux pas avoir sur ma carte nv, J'ai LE CHOIX)

Parce que contrairement a ce que tu t'es convaincu que je pensais: je ne hais pas amd au point de vouloir les voir disparaitre, juste que j'en ai marre de les voir se complaire dans la médiocrité sur pleins d'aspect, alors qu'ils ont les moyens de faire VACHEMENT mieux. Parce qu'on a beau dire: on subit TOUS les choix merdiques d'amd au final, vu que les dev s'adaptent.

Vous allez vous aimer les uns les autres, bordel de merde?

AMD a le mérite de brider un peu NV sur leurs tarifs, c'est leur seule utilité à mes yeux. Un peu comme Free chez les opérateurs mobiles :D

Turom_ a écrit :
Vous allez vous aimer les uns les autres, bordel de merde?

AMD a le mérite de brider un peu NV sur leurs tarifs, c'est leur seule utilité à mes yeux. Un peu comme Free chez les opérateurs mobiles :D

Ah non AMD c'est tout pourri. T'as pas le droit de dire ça.


Troll mis a part: c'est un de leur rares avantages, ça eyefinity et leur gestion hardware de la vidéo qui a toujours été meilleure que celle de nv (même si depuis que cuda existe et que les softs l'intègrent, l'écart tend a se réduire).

mustach_cuir a écrit :
Pour une fois je vais remercier Apple d'avoir choisi contre vents et marées de mettre 2 FirePro AMD dans son Macpro.
Si ca peut ameliorer OpenCL et me permettre d'avoir davantage de choix pour une carte graphique, c'est parfait.

Profite bien, dans 2 ans il n'y aura que du PowerVR dans les Mac Pros :o)

Echoes a écrit :
Donc quel est l'intérêt de faire un fork ? Ce n'est (ne sera) pas dispo en OpenGL ES ? Ou c'est vraiment juste pour avoir une API propriétaire et se retrouver avec des portages Android nazes ?

L'intérêt est à plusieurs niveaux pour Apple :
1 - leur surcouche OpenGL a toujours été à la traîne (y compris sur MacOS). Plutôt que de se mettre à fond dans OpenGL qui est coûteux à développer et à maintenir, ils préparent une API qui aura une couche de front end et de driver plus légère. Ils continueront à "supporter" OpenGL comme ils le font déjà ou réduiront encore plus leurs investissements dedans.
2 - Oui cela fait une barrière pour les gens qui veulent développer sur desktop (linux/windows), android, ios. C'est un plus pour Apple et un moins pour les concurrents. Sachant que l'éco-système iOS représente probablement toujours une majorité des revenus des gens qui écrivent des applis mobiles. Ceci dit comme on a dit, on ne sait pas dans quelle mesure cela sera vraiment un handicap pour l'écriture d'apps puisque les moteurs sont multiplateformes etc. Mais c'est de la friction supplémentaire qui s'ajoutent aux raisons de ne pas porter une appli ou à mettre du temps à la porter (certaines apps ne sont déjà pas aujourd'hui portées sur Android pour d'autres raisons, donc ils rajouteront une raison).
3 - si l'opengl de base sur Android et iOS sont peu efficient et que les extensions qui permettent une bonne utilisation du GPU ne sont pas là ou ne sont pas utilisées alors oui le CPU peut devenir le facteur limitant de certaines apps modernes. Et un facteur important aussi est la consommation qui peut-être affectée par le choix d'une API ou d'une autre. Si la même app consomme moins sur Apple que sur le concurrent c'est un bonus pour Apple. Pour avoir les vrais chiffres il faudra attendre une base d'applications suffisante..

L'un dans l'autre il y a plein d'avantages "potentiels" pour Apple. Reste à savoir si cela fera une différence sur le long terme (c'est toujours plus difficile à déterminer à l'avance).

Un des inconvénients pour Apple serait qu'ils laissent tomber OpenGL et que leur implémentation soit subpar et que de ce fait ils se trainent une mauvaise réputation chez les développeurs qui ne voudraient pas se convertir à leur nouvelle API. L'autre inconvénient c'est que si leur plan de convertir tout le monde à la nouvelle API ne marche pas, ils peuvent se retrouver le derrière entre deux chaises à devoir supporter l'une autant que l'autre et donc augmenter le nombre de ressources plutôt que de le baisser (en même temps ils n'ont pas un problème d'argent pour l'instant, mais ils ne sont pas arrivés là où ils sont en dépensant à tort et à travers :) ).

CBL a écrit :
Résumons :
-tout ce que fait AMD est pourri
-tout ce que fait Nvidia est génial
-tout ce qui est fermé est génial
-tout ce qui est ouvert est pourri
-le support d'OpenCL par toutes les plus grosses boites d'édition vidéo n'existe que par pure charité
-OpenCL est de toute facon pourri et ne sert à rien.

C'est bien connu. L'absence d'alternative et de concurrence est ce qui fait progresser le monde du logiciel.
Et c'est un vrain bonheur de développer dans des environnements tout verrouillés. Prenons Apple par exemple. J'adore devoir galérer avec des certificats et des provisionning profile juste pour avoir le droit de tester mon appli développée avec mon mac sur mon téléphone.

Rooohhh, même moi qui comprend la moitié de ce que vous dîtes, reconnait une belle grosse mauvaise foi là.

BeatKitano a écrit :

Parce que contrairement a ce que tu t'es convaincu que je pensais: je ne hais pas amd au point de vouloir les voir disparaitre, juste que j'en ai marre de les voir se complaire dans la médiocrité sur pleins d'aspect, alors qu'ils ont les moyens de faire VACHEMENT mieux. Parce qu'on a beau dire: on subit TOUS les choix merdiques d'amd au final, vu que les dev s'adaptent.

C'est marrant, tu m'as fait penser aux consoles...

Je caricature les propos de BeatKitano car c'est toujours le même refrain.
Quand ma Nvidia me balance des écrans bleus car j'ai eu le malheur de laisser mon cable HDMI branché, c'est de la faute du fabricant de mon portable. Quand Optimus déconne à plein tube et que ma sortie vidéo disparaît, c'est de la faute d'Intel. Mais quand un jeu déconne avec une AMD, c'est forcément de la faute d'AMD. Aucun des deux mondes n'est parfait. A chaque nouveau PC je passe d'AMD à Nvidia et inversement et je me cogne toujours des problèmes. Un pote qui a acheté le même portable que le mien a vu sa carte cramer au bout de 6 mois...

Si AMD était si catastrophique, ils ne domineraient pas le marché des consoles et Apple ne les aurait pas choisi pour les Mac Pro.

Quelque soit la carte, ce n'est pas normal de devoir installer des nouveaux drivers juste pour un jeu. Les nouveaux drivers devraient uniquement servir à corriger des bugs, supporter des nouvelles APIs et ajouter des fonctionnalités. Cela implique derrière de la grosse bidouille. Les programmes AMD Evolved et The Way It's Mean To Be Played ne devraient pas exister. Dans un cas ça empêche Thief de fonctionner sur ma bécane et dans l'autre ca pourrit Watch Dogs sur les AMD. Les deux constructeurs participent au développement des jeux et des moteurs non pas pour les améliorer mais uniquement pour vendre leur came. Ils devraient uniquement participer à élaboration des APIs et que le meilleur gagne par la suite. Si je devais acheter du matos spécifique pour jouer à tel ou tel jeu, je jouerais sur console.

Après il ne faut pas confondre standards/open source/ouvert/propriétaire. Le Blu-Ray est un standard mais il n'a rien d'ouvert. Windows est propriétaire mais je n'ai pas besoin de la permission de Microsoft pour utiliser leurs apis, écrire une appli et la distribuer.

OpenCL tourne (un peu) moins vite que CUDA (forcément car il y a une couche d'abstraction) mais a plein d'avantages : c'est interopérable, c'est multiplateformes et c'est hétérogène (OpenCL tourne sur CPU et GPU). Je suis bien content qu'AMD ait abandonné leur solution de GPGPU pour embrasser OpenCL. Si ca se trouve ils vont probablement aussi abandonner Mantle si les progrès faits en la matière se retrouvent dans Direct3D 12 et OpenGL 5 (soyons fous). CUDA c'est bien gentil mais tu dois régulièrement changer de matos pour supporter les dernières fonctionnalités... Tous les labos de recherche qui ont investit des fortunes en supercalculateurs à base de Tesla ont fait la gueule en découvrant qu'ils pouvaient se mettre la 2.0 où je pense.

CBL a écrit :
Je caricature les propos de BeatKitano car c'est toujours le même refrain.
Quand ma Nvidia me balance des écrans bleus car j'ai eu le malheur de laisser mon cable HDMI branché, c'est de la faute du fabricant de mon portable. Quand Optimus déconne à plein tube et que ma sortie vidéo disparaît, c'est de la faute d'Intel.

C'est toujours le même refrain parce que t'as pas l'air de vouloir accepter l'idée que les chiffres parlent d'eux même et que la proportions de bugs graphiques, de crash, de problème de lancement, de corruption de shaders, et de fonctionalité qui sont moitié opérante va a AMD...
Et que les problèmes que tu décris sont potentiellement imputables a nividia, mais sans la moindre preuve (et je rajouterais concernant optimus que l'alternative amd est nettement moins reluisante... qui utilise enduro ? Personne, et pour cause...)

Ah et tant qu'a faire on va le dire: que ce soit amd ou nv, les portables c'est de la merde. Ça c'est dit.

CBL a écrit :
Si AMD était si catastrophique, ils ne domineraient pas le marché des consoles et Apple ne les aurait pas choisi pour les Mac Pro.

Si AMD ne cassait pas ses prix en rognant sur les couts logiciels ils ne seraient pas a 50% sur le marché desktop, ils ne seraient probablement pas sur les consoles, quand a Apple, sub 2k€ leur chipset c'est du intel integrated de chiasse donc bon niveau choix hein.

CBL a écrit :
Quelque soit la carte, ce n'est pas normal de devoir installer des nouveaux drivers juste pour un jeu.

Ah on est bien d'accord, d'ailleurs c'est un peu ce que ne voulait pas amd fin 90 début 2000: on a vu le résultat dans leur déboires drivers... C'est moche mais maintenir une retrocompat et supporter les jeux suivants c'est juste un gros nid a hack divers pour "optimiser" le rendu/perf des jeux et ça c'est chez les deux constructeurs.

CBL a écrit :
Les programmes AMD Evolved et The Way It's Mean To Be Played ne devraient pas exister.

Oui. On est d'accord mais au final sans ces "fer de lance" on aurait probablement pas aussi souvent de nouvelles techno (tressfx ?) dans les jeux.

CBL a écrit :
Dans un cas ça empêche Thief de fonctionner sur ma bécane et dans l'autre ca pourrit Watch Dogs sur les AMD.

Tu t'avances beaucoup, et si c'était simplement parce que les devs avaient mal fait leur taf ? Moi quand je critique amd je regarde les chiffres, y'a quand même une tendance c'est peut-être pas de bol pour amd et il ne sont que partiellement responsables (même si sur les logiciels on voit des trucs qui sont quand même bien gras chez amd), mais ça facilite les choix.

CBL a écrit :
Les deux constructeurs participent au développement des jeux et des moteurs non pas pour les améliorer mais uniquement pour vendre leur came. Ils devraient uniquement participer à élaboration des APIs et que le meilleur gagne par la suite.

Donc tu veux des jeux avec les même features et juste du fight de performance ? Super.

CBL a écrit :CUDA c'est bien gentil mais tu dois régulièrement changer de matos pour supporter les dernières fonctionnalités... Tous les labos de recherche qui ont investit des fortunes en supercalculateurs à base de Tesla ont fait la gueule en découvrant qu'ils pouvaient se mettre la 2.0 où je pense.

L'obsolescence logicielle se trouve chez les deux acteurs, c'est parfaitement déplorable mais ça n'en réduit pas la qualité des options au moment de leur utilisation.

CBL a écrit :
Prenons Apple par exemple. J'adore devoir galérer avec des certificats et des provisionning profile juste pour avoir le droit de tester mon appli développée avec mon mac sur mon téléphone.

Gné ? A la limite en 2009 j'aurais pu comprendre cette remarque, mais maintenant ce n'est plus que l'histoire de quelques clicks.

Merci pour ta réponse LeGreg.

Je me demande si Google va créer son propre fork si Khronos ne met pas à jour OpenGL ES assez vite (ils avaient déjà fait le coup pour WebKit). Ca sera peut être plus compliqué à mettre en place vu la diversité du hardware Android.

CBL a écrit :
Quelque soit la carte, ce n'est pas normal de devoir installer des nouveaux drivers juste pour un jeu. Les nouveaux drivers devraient uniquement servir à corriger des bugs, supporter des nouvelles APIs et ajouter des fonctionnalités.

Complètement d'accord. D'ailleurs, ils modifient quoi dans leur driver pour avoir des améliorations de performances ? Dans Watch Dogs, la différence était vraiment flagrante.

CBL a écrit :
Si ca se trouve ils vont probablement aussi abandonner Mantle si les progrès faits en la matière se retrouvent dans Direct3D 12 et OpenGL 5 (soyons fous).

Comme je le disais plus haut, pour ce qui est du overhead, OpenGL sait déjà faire via des extensions ARB (donc normalement utilisables chez NVIDIA et AMD) et la plupart sont considérées pour entrer dans la version core d'OpenGL 5, donc ça n'a rien de si fou.