 |
||
| ||
| |||||
| Dernière réponse | |
|---|---|
| Sujet : compilo C++ SSE | |
| bjone | microsoft ne peux pas développer des drivers pour des produits dont les brevets appartiennent à d'autres entreprises (ou alors ils le font avec leur accord).
c pour ça que oui, 3dfx & aureal n'ont plus de -vrais- drivers. |
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| bjone | microsoft ne peux pas développer des drivers pour des produits dont les brevets appartiennent à d'autres entreprises (ou alors ils le font avec leur accord).
c pour ça que oui, 3dfx & aureal n'ont plus de -vrais- drivers. |
| JeSuisPasUnNumero | Sinon www.codeplay.com est pas mal, il vient se greffer sur VC+... |
| wave |
|
| LeGreg | Ce sont deux problemes totalement independants:
- Oui microsoft a interet a ce que les gens developpent sous DirectX/Direct3D. - Oui La joint venture entre Microsoft et SGI pour donner Talisman a lamentablement echoue. - Non le marche d'avenir du jeu ce n'est pas Linux mais les consoles de jeu. Et les developpeurs de jeu doivent deja se coltiner toutes les plateformes possibles et imaginables (GBA, Dreamcast, PS2, GameCube, XBox). Alors la gueguerre OpenGl/DirectX doit bien les faire rigoler. - Oui 3DFX est bien morte et nVidia en la rachetant n'avait pas l'intention de la ressusciter mais d'eliminer un concurrent. - Oui tu as de la chance qu'il y ait des hobbyistes pour continuer a prendre de manierer totalement gratuite sur leur temps libre pour maintenir les drivers Glide (!), alors cesse de te plaindre et remercie les. LEGREG |
| wave | ce que je dis c'est qu'aucun driver 3dfx ne supporte pas l'opengl.
Et micro$oft en a fourni un avec XP. C'est pas 3dfx qui l'a inventé. Ca m'étonnerait que ça soit nvidia. micro$oft n'a jamais vraiment poussé à l'utilisation d'opengl, pour 2 raisons: -un jeu directX ne sera pas porté sur d'autres plateformes, donc moins de concurrence. -maintenant un jeu directX est + facilement portable sur xbox. |
| LeGreg |
|
| wave |
|
| Jar Jar | Le compilo d'intel le fait, et je crois que ça reste celui qui génère le code le plus rapide.
Sinon, curieusement, GCC 3 supporte le 3D Now! mais pas le SSE. |
| LeGreg |
|
| wave | ben c'est un bon exemple parce que justement on utilise les drivers fournis par micro$oft, avant de finir par choisir des drivers non-officiels qui font l'opengl et le glide. |
| LeGreg |
|
| wave | c'est surtout qu'ils préfèrent directX!
y'a qu'à voir les drivers voodoo sous XP, il ne connaissent QUE directX. |
| Pitounet | il se sont surement dit qu'il fallait mieux attendre directement opengl 2.0 :) |
| bjone | tsss, c de la faute au donkey, si il existerai pas, tu serais avec le debug :D |
| wave | oui mais j'ai perdu un temps fou à trouver comment on appelle une fonction qui n'est connue que par le driver.
Enfin ça couterait pas très cher de pas avoir 3 ans de retard là-dessus. S'ils faisaient ça au lieu d'inventer le C# et autres stupidités qui remplissent les 7 CD de visual.net et le disque dur! |
| bjone | bin l'opengl (full icd) y vient avec le driver de la carte 3d...
même si c'est vrai que l'opengl32.dll peut se mettre entre l'appli et la dll du driver... |
| Pitounet | normalement, opengl 1.2 devait etre dispo à partir du service pack 2 de windows 2000.... on l'attend toujours |
| wave |
|
| verdoux |
|
| wave | et VC++ tu sais s'il sait faire quelquechose avec SSE? |
| bjone | bin c'est que de l'expension en ligne, et le compilo essaye de bien "scheduler" les instructions sse.... |
| wave | mouais donc intel qui se vante d'avoir un compilo génial n'a rien fait de + que les autres!
en + le compilo intel me dit qu'il a besoin de VC++ pour s'installer alors que VC++ est installé chez moi! |
| bjone | pour le compilo intel, le sse est exposé par des fonctions C ou tu fais de l'asm au choix...
mais le compilo n'est pas capable de lui-même d'attraper n'importe quel routine est de paralléliser les données pour le sse, y'a du boulot préparatoire.... |
| wave | up! |
| wave | elle a quoi comme limitations la version d'eval. du compilo intel? |
| verdoux |
|
| ayachi |
|
| LeGreg |
|
| wave | oui mais ça oblige à faire 2 versions du code (3 si on ajoute 3dnow) et à choisir laquelle on appelle en fonction du cpu. Ca triple la taille du code, ça m'étonnerait que VC fasse ça sans possibilité de faire autrement. |
| deathsharp | ya bcp de prog qui sont optimise SSE ou des trucs comme ca qui tourne quand meme nan |
| wave | alors si ça fournit par défaut un code SSE ça plantera sur pentium2, celeron 1, thunderbird, duron < 1GHz et tous les cpu précédents.
Donc ça peut pas être le cas. |
| deathsharp |
|
| wave | comment ça peut être par défaut alors que tous les cpu ne le gèrent pas?
dans ce cas il y aurait au moins une option pour l'enlever. |
| deathsharp | c par defaut je crois, meme SSE2
a verifier tout de meme |
| wave | j'ai pas trouvé d'option pour optimiser SSE sous VC++.net.
Y a-t-il une option pour ça, où sinon y a-t-il d'autres compilos qui le font ? (intel?) Et avec un vrai gain de perfs, pas juste 1% histoire de dire que c'est géré par le compilo... [jfdsdjhfuetppo]--Message édité par wave--[/jfdsdjhfuetppo] |
