Reprise du message précédent :

 
Euh, ben non. CUDA, c'est propriétaire nVidia, personne d'autre n'a le droit de supporter ca.
Ceux qui développent des applications avec CUDA sont (j'espère) bien conscients qu'il faudra tout réécrire pour OpenCL le jour où ils voudront changer de crémerie.

 
C'était un peu mon espoir pour ce soir, voir une offre qui fonctionne mieux que le RIS (qui est certes bienvenu, mais n'offre pas quelque chose d'aussi bon que DLSS)

 
Il parle du point de vue des devs / applications. Nv a fait chié d’outreach et bâti de l’infra et des projets dessus, donc plus ou moins tout ce qui fait du gpgpu supporte cuda, et si t’as du bol ça gère aussi opencl.
 
Afaik l’outillage est aussi bien meilleur pour cuda.

Je pense que tu confonds standard interopérable et API de référence supportée par tout le monde
 
 
Rédigé depuis le standard ISO/IEC 26300 avec LibreOffice

https://retrocomputing.stackexchange.com/a/16680
 
Real programmers

?

Dans les settings des jeux ça s'appelle "RTX" pour activer le ray-tracing. Peu de jeux proposent de custom tous les "X".

yep. Le RTX seul plombe les perf. RTX + DLSS, ça sauve pas mal.

oui c'est pas une API, ce que je voulais dire c'est que les libs utilisant de l'accélération matérielle proposent souvent différentes implémentations (Intel MKL, nvidia CUDA). nvidia est le choix super recommandé ici (pour le moment) du fait du support, de la doc, etc...
 

this
Mieux expliqué que ce que j'ai dit : https://timdettmers.com/2020/09/07/ [...] _GPUs_CUDA

 
RTX, c'est une appellation nVidia pour leurs cartes.
Pour DX12, le raytracing passe par DXR. Pour Vulkan, y'a pas de standard pour l'instant.
 

A nouveau, tu mélanges RTX et ray tracing, mais c'est effecitvement le cas que DLSS aide énormément (avec un bon denoiser) à rendre le raytracing utilisable à hautes résolutions présentées.

Attention Jubi, vous allez bientôt racheter AMD pour continuer à avancer sur les TPU

 
Cette partie tient toujours :

Le fait que des devs se soient engoufrés dans une techno propriétaire pour développer un écosystème est une erreur, et il faudra bien qu'éventuellement, soit la techno s'ouvre, soit que les pots cassés soient payés par les devs en question. Continuer à construire dessus "parce que c'est établi", pour moi, ca sonne plus comme un "sunk cost fallacy" qu'autre chose.

 
Y'a pas que moi qui "confond". Absolument tlm appelle ça RTX. Suffit de regarder tous les tests des CG.    
Abus de langage certes, mais bon.

Cette partie là est un potentiel problème éventuel, c'est pas dit que AMD puisse rattraper leur retard, et en attendant les gens peuvent bosser avec du bon support & des bons outils.

D'autant plus que pour 95% des cas, le support est dans le package (c'est ton pytorch ou autre lib de compute / ML).

C'est une erreur théorique, mais en pratique quand t'as le choix entre une techno propriétaire et rien, bah tu prends la techno propriétaire.

Ce serait du sunk cost fallacy s'il y avait un intérêt à switcher mais que tu voulais pas pour cause d'investissement. Tu perds plein de trucs (y compris mais pas uniquement ton investissement) et tu gagnes rien, parce-que le seul intérêt de OpenCL sur CUDA c'est de pouvoir tourner sur de l'AMD ou Intel, ce dont tout le monde se fout parce-que les perfs de nv sont supérieures.

Bah écoute ça fait 50 ans qu'IBM continue de faire grandir ses revenus mainframes et 25 ans que Microsoft fait de même avec Office, ça a pas l'air d'être la priorité de beaucoup boites.

En pratique, ils auraient pas eu beaucoup à attendre pour passer sur OpenCL, et créer une demande plus forte sur cette API aurait forcé un peu la main à nVidia pour la supporter plus correctement et à développer un écosystème qui n'est pas lié à un monopole.
Prendre une industrie complète pour des consommateurs idiots qui ne comprennent pas que leur investissement a des conséquences, ca va vite atteindre ses limites  

pas sur que l'api opencl aurait muri aussi vite sans avoir un fabriquant qui traçe une voie
 
et prendre les consomateur pour des idiots n'est pas vraiment un problème, demande à Apple

30+ mois Ça prend moins de temps d'ajouter OpenCL à un produit qui supporte CUDA.

C'est une situation déplorable mais d'un autre côté l'utilisateur moyen il en a comme d'habitude rien à foutre, il veut réaliser son machin. Ça a pas commencé avec CUDA, et ça s'arrêtera pas là.

T'as pas l'air de te rendre compte que t'es complètement à l'ouest en fait. Ça fait des siècles que les industries se basent sur des solutions propriétaires.

premier merge request passée (de l'optimisation d'un process existant)
 
jusqu'ici tout va bien

La règle #1 du compute c'est que t'as jamais assez de puissance. Donc si t'as une techno qui offre x% de gains pour un coût raisonnable, tu prends.
Si AMD amène de la puissance de calcul avec un rapport perf/coût par watt supérieur (ce qui n'a jamais été le cas jusque ici), alors les gens adopteront leurs API, eu si ça se tire la bourre , alors les gens adopteront des API / standards ouverts pour garder le choix à chaque génération.
C'est pas que les gens sont cons ou fainéants, c'est juste que depuis la résurgence du machine learning, AMD n'a jamais été compétitif. Si ils le redeviennent, le jeu va s'ouvrir.
Vive la concurrence, quoi.

source

lol, on reconnait un vrai barbu

D'une part, sauter sur CUDA, ca n'a pas été Day1, d'autre part, AMD avait ouvert leur assembleur sur leurs cartes avant CUDA, donc il fallait pas une vaste étendue de neurones pour réaliser qu'une solution propriétaire serait éventuellement un facteur limitant, mais certes, j'admets que les outils étaient là avant et que, pendant deux ans, c'était plus tentant. Note que quand OpenCL a été standardisé comme ca aurait du être raisonnablement attendu, ils auraient pu sauter sur l'occasion.
 

Wokay, donc tout ce qu'on a fait par le passé, par définition, on ne peut pas appeler ça une erreur. J'imagine que ca simplifie les choses, mais je suis pas sur que j'adhère à cette définition.
Note que je ne dis pas que les résultats sont nécessairement catastophiques à cause d'une erreur. On peut admettre une erreur sans devoir considérer un project comme un échec ?

Pour l'instant.
Ca a été aussi le cas avec Intel. Imagine si tout avait été "optimisé pour Intel".

 
C'est là qu'est la grosse question : comment tu maintiens ce coût raisonnable si tu te lies pieds et poings à un monopole ?
Et honnêtement, une API qui est faite pour une machine donnée a nécessairement plus de facilité à extraire plus de performance qu'une API qui est faite pour être cross-platform. Toutes les abstractions ont un coût.
Ici, le coût que je veux souligner, c'est celui qui est moins évident, qui est, à nouveau, de s'attacher à un monopole plutôt que de prendre une solution où tu as un marché ouvert.
Bref. C'est l'heure d'aller regarder des séries  

Bah oui pour l'instant, le sunk cost fallacy c'est quand tu veux pas passer à mieux, pas quand tu veux pas passer à moins bien

Et à noter: tu regardes les commentaires des gens qui font du ML, ils te disent que AMD est littéralement pas une option, il y a aucun support, pas assez de RAM, etc...

Ça a pas mal été le cas avec leur compilo qui générait de la merde quand tu targetais pas du Intel, ou la majorité de la doc d'optimisation (genre les infos de timings) qui étaient en Intel. Après la majorité du travail d'intel ça a été leurs pratiques anti-compétitives.

On remarque d'ailleurs que beaucoup ont pas plus de mal que ça à regarder du côté d'ARM, donc ce genre de switch est pas gratuit mais c'est pas non plus la mort, et pendant ce temps ils se sont gavés sur x86, parce-qu'il y a 10 ou 15 ans c'est pas chez ARM que t'allais chercher tes perfs.

mask, je suis curieux de savoir ce que tu as trouvé pour ta fenêtre

Vous avez un bon lien pas trop long qui explique le smart access memory d'AMD ?

J'ai joué avec l'écrou du bas pour le mettre à fond et je me suis retrouvé dans la situation "la fenêtre est trop basse", le pêne bloquait contre les rebords de la gâche, ça savait pas rentrer dedans mais ça savait plus glisser en dessous.
 
Il commençait à faire du vent & à pleuvoir donc j'ai remis de travers. Samedi il est censé faire beau, ou vendredi s'il y a pas trop de vent, je regarderais si je peux jouer avec l'écrou de la paumelle haute pour tirer vers le montant et redresser un peu plus au cas où ça passe, sinon il faut que je regarde comment remonter tout l'ouvrant plus haut au cas où ça passe (genre en espérant que a distance entre les gâches n'est pas trop grande et que mon idée est possible).
 
Après ça montre quand même a que point je suis pas observateur, ou alors c’est bizarrement récent (genre ça a joué tout seul ou bien parce-que ça a pris des coups de vent cet été), parce que j’ai rien remarqué l’hiver dernier alors que quand il vente ça s’entend quand même bien.  

Et puis désormais tu vas pouvoir tester l'orga en full remote

Bon, ben c'est chaud, et je suis pas sûr que ça va avoir bcp d'effet vu que les écoles sont ouvertes.
Sauf si les profs refusent d'y aller parce qu'ils ont pas envie de choper la maladie.

(mais télétravail "généralisé" )

AMD qui revient à fond dans le segment HDG des GPU

Je devais avoir encore une semaine avec pas mal de présentiel mais après je devais passer a 4 jours de tt
Perso je suis pas inquiet (mais content d'avoir quitter le tourisme)

Bwalé je télécharge TousAntiCovid
Les serveurs sont sous l'eau j'ai l'impression

Ce qui est intéressant c'est de voir la différence de perf sous DXR. J'ai trouvé d'infos qui montrent si les RT cores permettent de traiter les frames DXR.

Et toute la suite logiciel qui est largement supérieure à celle d'AMD

Dans le cas des jeux sponsorisés RTX oui. Dans le cas de modern warfare par exemple c'est écrit: DirectX Raytracing même si y'a une prise en charge spécifique par les RT cores.

Et pourtant le RTX c'est effectivement un produit Nvidia avec une prise en charge spécifique par des cores dédiés. Comme dis plus haut le RTX et son implémentation impliquent Nvidia et le Dev, alors qu'on parle d'API ouvertes dans le cas de DXR ou de RTRT.

Pour me donner du courage je regarde un docu sur la construction de l'aéroport de Berlin.
9 ans de retard.
Deutsche qualität

Pas possible c’est du cloud souverain de France avec les meilleurs architectes de capge

c'est moi ou http://reho.st est HS ?

 
Marche ici. Tu as sans doute été banni.    
 

 
 
 
De mémoire l'hébergeur bénévole a eut affaire à la police pour du pédo et du coup a shutdown le serveur.
 
La solution aurait été de delete tout contenu non référencé par le forum. Sauf qu'il avait plus le temps de s'en occuper.