Le 26/06/2015 à 15h 31

C’est déjà en train d’arriver.
Valve finance le développement des drivers libres Vulkan à destination des chips Intel.
De plus en plus de jeux sont annoncés sur Linux, le nouveau Batman, le prochain X-com 2, Project Cars, etc …

Le 29/04/2015 à 17h 35

ça ne casse pas des briques leur VS code.
Je viens de le tester à l’instant, et pour le moment ce n’est même pas au niveau d’un IDE de base livré dans un environnement Linux standard.
On ne peut même pas afficher la liste des symboles dans la barre latérale… Et le menu “Preferences” qui nous ouvre un fichier .json à éditer (autant utiliser Emacs).

S’ils veulent convaincre des gens d’utiliser ça en dehors de Windows, il va falloir qu’ils revoient sérieusement leur copie.

Le 10/12/2014 à 10h 13

La fluidité de l’interface graphique dépend trés peu de la rapidité du processeur principal. Elle a plus à voir avec le processeur graphique et les pilotes qui lui sont associés.

Le 24/10/2014 à 09h 23

Le PAD filaire XBOX360 est géré depuis le début.
ça marche parfaitement avec le client Steam sous Linux ;)

Le 18/03/2013 à 18h 06

L’omniprésence d’Ubuntu est logique puisque c’est la distribution qui est officiellement supportée par Valves.
De plus Steam est directement disponible dans les dépôts de paquets de la distribution.
Steam est moins accessible sur les autres distributions, ce qui en limite d’autant la diffusion.

Le 07/03/2013 à 08h 56

“Microsot” " />

Le 22/01/2013 à 13h 16

freefree33 a écrit :

qui va aller payer une licence a windows quand tu as une plétore de distribution linux libres et gratuites à coté?


C’est vrai que l’écosystème de RIM est en tout point comparable à celui de Windows… Oh wait.
Non mais franchement, d’un côté t’as le choix d’Android supporté par tous les constructeurs ou presque, présent sur des millions de machines avec je ne sais combien d’activations par jour, c’est gratuit, libre… et de l’autre tu as RIM, payant et propriétaire avec un écosystème quasi-inexistant.
Lequel tu vas choisir en tant que constructeur ? Le choix s’annonce difficile :)

Le 22/01/2013 à 12h 53

Qui va aller payer une licence à RIM quand tu as une plétore d’OS libres et gratuits à côté, avec un support matériel encore plus important ?

Le 18/01/2013 à 15h 22

floop a écrit :

sur quel support ? parce que je trouve la version ios tres correcte
bon c’est sur y’a 3 features sur google+ donc le portage est facile " /> et puis si tu te loupes tu leses juste 30 personnes à tout casser.



Sur Android l’application Google+ permet d’en faire autant (voir plus) que l’application Facebook, mais avec une bien meilleure interface et une synchro qui ne bug pas…

Le 18/01/2013 à 13h 34

Il peut aussi parler de l’application Mobile de Facebook qui est assez mal conçue comparée à celle de Google+.

Le 16/01/2013 à 16h 37

IAmNotANumber a écrit :

J’ai tenté ma chance sur Fedora à plusieurs reprises et j’ai pas vraiment accroché… J’ai trouvé ça pauvre en outils d’administration ; de plus, je suis un adepte du duo Xfce + Compiz, et aux dernières nouvelles Compiz n’était plus maintenu dans Fedora ! Vous savez ce qu’il en est aujourd’hui SVP ?


Malheureusement Compiz est en mode maintenance depuis un moment.
De l’aveu de son développeur principal, Compiz n’a plus trop de raison d’être aujourd’hui que tous les environnements majeurs possèdent leur propre compositeur. C’est probablement la raison pour laquelle Fedora ne l’empaquette plus.
Ce que je trouve dommage malgré tout, c’est qu’aucun des Compositeurs actuel n’est aussi complet que Compiz en terme de plugin et de customisation (Kwin sur KDE étant celui qui s’en rapproche le plus).

Le 30/11/2012 à 10h 08

sxpert a écrit :

ils prennent les gens pour des billes ??
https://lh6.googleusercontent.com/-8SgI6dgHjx4/ULeMBpnPChI/AAAAAAAAE4I/0OolzMqXR…


Tu as des abonnements aux services de cloud de canonical en plus sur la version Ubuntu, ça doit justifier les 50$ de plus.

Le 28/11/2012 à 14h 50

yvan78 a écrit :

Ce qui explique sans doute que Red-Hat, principal bailleur de Fedora qui se sert de cette dernière pour tester/debugger les nouveautés, prépare des options pour ses clients entreprises que Gnome3 ne fait pas rêver?

En tout cas c’est de bon augure pour Mate… Moins pour Gnome…" />



ça n’a rien à voir, car le portage de Mate est effectué par un contributeur et n’est pas bloquant pour la distribution (il ne passe pas par le QA comme Gnome ou KDE). C’est à dire que si Mate est cassé dans le repo, Fedora s’en fiche, ce sera de la responsabilité du mainteneur des paquets.
De plus Red Hat laisse carte blanche à ses employés travaillant sur les projets upstream et présents dans Fedora.
Il y a une véritable différence entre les employés qui travaillent pour les projets uspstream et ceux qui travaillent pour les clients de Red Hat au sein même de Red Hat.

Le 28/11/2012 à 12h 48

GoldenTribal a écrit :

Sans troll aucun, je ne comprend pas l’utilité de Mate tellement Gnome 3 Classique et Xfce se rapprochent de Gnome 2 " />



Gnome 3 “Classique” va disparaitre dans la prochaine version de Gnome 3 (3.8).
Et XFCE n’est pas assez proche de Gnome 2 pour le remplacer vraiment.

Le 17/11/2012 à 12h 38

charon.G a écrit :

On est pas totalement d’accord mais je voulais quand même te remercier de ne pas partir en vrille comme ça peut se passer habituellement " />


Je suis trop vieux pour ça, et ça n’en vaut pas la peine :)

Le 17/11/2012 à 12h 35

charon.G a écrit :

Javascript et l’accélération graphique le danger est minimal.
Pour flash au départ ça venait du retard du W3C à appliquer les normes.
Tu remarqueras que IE Metro ne supporte plus les ActiveX et donc flash(a part une white liste pour la transition)
La les dangers qui sont présentés ne sont pas du tout dans la même catégorie. (attaques systèmes)


Il y a dejà eu des failles Javascripts aux conséquences bien plus grave qu’un problème de TDR..

Le 17/11/2012 à 12h 21

Si Microsoft avait appliqué le même principe de précaution aux autres technologies du Web… Tu aurais un IE qui ne gère ni javascript, ni l’accélération graphique, et ne supporte pas le Flash.

Le 17/11/2012 à 12h 18

charon.G a écrit :

Dans un monde idéal il faudrait que tout le monde possede au minimum Windows 8 avec une carte graphique DX11. Mais j’ai vu hier que la part de marché de win8 vient d’atteindre seulement celle de linux. Parmis ceux la tous n’ont pas une cg dx11. pour les smartphones ils utilisent tjs des dx9. Vu la lenteur de progression du marché on ne sera pas dans une bonne situation avant dix ans et je suis peut être optimiste.



Je pense que tu sur-éxagères le problème, comme Microsoft le fait pour éviter d’implémenter une technologie qui s’appuie sur une API concurrente à la leur.
Heureusement qu’il n’y a pas que Windows 8 et directx…

Le 17/11/2012 à 12h 09

charon.G a écrit :

Ils le font déjà et ca ne marche pas tu lis ce que j’ecris ou quoi.


ça règle une partie des problèmes, je n’ai jamais dit que tous les problèmes étaient résolus par le browser lui même (relis mon tout premier message).

Le 17/11/2012 à 12h 08

charon.G a écrit :

Ces pistes c’est de découper les appels en plus petits appels ce que fait deja Windows. Si tu lis ils disent qu’ils ne sont pas capable de regler le probleme reellement mais ils essayent de le le limiter.
Ensuite les watchdogs comme je l’ai dis avant tu ne peux pas interrompre une tache une fois execute sur le gpu.
Enfin ils demandent de gerer le rendu dans un process à part pour gérer le cas dont je parlais ou le gpu sera resetté entrainant la fermeture de l’application.
Ils disent clairement qu’ils peuvent pas corriger complètement le problème. reconnais le.



Oui ils disent que la spec de WebGL ne peut pas fournir de mécanisme général pour résoudre tous les cas pouvant poser problème. ça ne veut pas dire qu’il n’existe pas de solution à chaque problème dans l’absolue.
Chaque solution dépendra de la pile graphique de chaque OS, des pilotes 3D et du travail fait par “l’implémenteur” de WebGL dans chaque navigateur.

Le 17/11/2012 à 12h 03

charon.G a écrit :

WebGL est juste un wrapper amélioré d’OpenGL. Les Shaders sont gérés au niveau système c’est pas dur à comprendre pourtant.
Je n’ai pas d’exemples pour le moment mais t’inquiète ca viendra on en reparlera dans une future news. je t’invite à regarder ce que met chronos dans la spec WebGL ils admettent le problème



Au final c’est le browser qui va générer le code qui sera compilé par les drivers 3D.
Entre temps il peut faire un travail de pré-compilation, détecter des problèmes éventuels, et splitter le travail que doit faire le shader en plusieurs bout si possible.
Bref il y a beaucoup de chose ;que le browser peut faire avant qu’un shader ne soit réellement exécuté par le GPU.

Le 17/11/2012 à 11h 58

charon.G a écrit :

J’ai trouvé quelque chose qui devrait clore le débat définitivement (sauf mauvaise foi bien sur):
Spec WebGL
Chronos reconnait le problème dans sa spécification WebGL:


Chronos reconnait le problème et explique que les devs doivent s’arranger pour découper les appels en plus petites requêtes. Ils disent bien que c’est impossible de régler totalement ce problème.


Il disent que c’est impossible de le régler dans le cas général, cependant ils donnent des pistes de solution, et certaines d’entre elles sont déjà mises en œuvre dans les browsers :

User agents should implement safeguards to prevent excessively long rendering times and associated loss of interactivity. Suggested safeguards include:

Splitting up draw calls with large numbers of elements into smaller draw calls.
Timing individual draw calls and forbidding further rendering from a page if a certain timeout is exceeded.
Using any watchdog facilities available at the user level, graphics API level, or operating system level to limit the duration of draw calls.
Separating the graphics rendering of the user agent into a distinct operating system process which can be terminated and restarted without losing application state.
The supporting infrastructure at the OS and graphics API layer is expected to improve over time, which is why the exact nature of these safeguards is not specified.

Le 17/11/2012 à 11h 51

charon.G a écrit :

Tu réclamais un exemple. je te l’ai donnéplus haut
C’est pour OpenGL mais ça s’applique très bien à WebGL arrête d’être de mauvaise foi.
Comme je l’ai expliqué au dessus ça s’applique pour toutes les technologies qui utilisent les Shaders. Pourquoi WebGL y réchapperait? . Si c’était possible Microsoft l’aurait modifié au niveau du système.
De plus sachant qu’ils se basent sur DirectX pour les shaders, ça risque d’être dur de le gérer.


Qu’est ce que tu en sais ? Tu as vu le source pour l’affirmer ? Les shaders WebGL ne sont pas compilés tels quels, et encore moins quand ils doivent être traduit vers une autre API. Je ne suis pas de mauvaise foi, je demande juste un exemple concret du problème en WebGL qui démontre une bonne fois pour toute l’importance du problème que tu décris.
Un truc qui serait tellement grave qu’il justifie la décision de Microsoft de ne pas vouloir l’implémenter.

Le 17/11/2012 à 11h 44

charon.G a écrit :

Encore un exemple avec un shader gourmandaprès on me dit que le problème n’existe pas



Montre moi un exemple en WebGL, tous les exemples que tu as montré jusqu’à présent ne sont pas en WebGL, et aucun ne donne le source du shader en question, donc on ne peut pas en déduire que c’est généralisable en WebGL.

Le 17/11/2012 à 11h 42

charon.G a écrit :

Ce que tu expliques c’est le fonctionnement actuel du multitache GPU cooperatif. où l’os et le constructeur essayent de diviser les paquets trop gros avant de les envoyer au GPU . Ce mécanisme est imparfait.
Sur un même execution context(le GPU en gère tout un tas ce qui garantit le parallélisme) le GPU ne sait pas interrompre la tache et redonner la main au noyau graphique. les documents que j’ai donné l’expliquent bien. c’est la raison même du dévelpppement du TDR. Tout comme les nombreuses applications qui provoquent des TDR à cause d’un shader trop lourd.
Pour faire le rapprochement avec le processeur, les premiers processeurs ne géraient pas les context switch et donc les premiers systèmes de l’époque utilisaient un multitache coopératif.
Le principe du multitache preemptif c’est que c’est géré directement par le matériel.
Pour WDDM 1.2 une carte graphique DirectX11 est obligatoire.
Je finirai en disant que ce mécanisme avait étéannonce par Microsoft dès 2006. Microsoft connaissait le problème depuis le début.



Le TDR, c’est juste un mécanisme de watchdog qui réinitialise l’affichage. Microsoft décrit simplement un mécanisme (qui doit être supporté par les pilotes), pour faire de l’ordonnancement. Ce n’est pas Microsoft tout seul qui peut mettre ça en place. Si le hardware et les pilotes ne le gèrent pas ça ne fonctionne pas. Les éditeurs de navigateur travaillent également avec les constructeurs de hardware pour trouver des solutions aux différents bug et problèmes qu’ils rencontrent.

Le 16/11/2012 à 20h 29

charon.G a écrit :

Je viens de tomber sur cet article


Apparemment vu le support restreint des drivers OpenGL Firefox et Chrome convertissent les GLSL shader code en directX9 HLSL. Du coup ta théorie sur un OpenGL tuné pour WebGL ne tient pas debout ça passe par DirectX.



C’est encore mieux, l’API bas niveau est donc complètement décorellée de celle qui est utilisée dans la page, ce qui signifie qu’il y a forcément un travail d’analyse et de conversion. Bonne chance pour tenter d’exploiter une hypothétique faille dans le driver DirectX au travers d’un shader GLSL…

Le 16/11/2012 à 18h 43

charon.G a écrit :

Le flash ne donne pas accès aux shaders. Ce probleme existe aussi avec toute application openGL,DirectX et le dernier silverlight.


C’est faux, la dernière version de flash possède une API Stage 3D qui permet d’utiliser les shaders :
http://www.adobe.com/devnet/flashplayer/stage3d.html

Le 16/11/2012 à 18h 32

charon.G a écrit :

Tu as tord Microsoft n’aurait pas sorti le multitache GPU preemptif si c’était le cas.

Voilà ce qui mette sur une doc Microsoft



Sur Vista et 7 le multitache GPU était coopératif. Ils tentaient de diviser les taches GPU invoqués par les applications mais c’est loin d’être parfait. Ils expliquent clairement qu’ils ne peuvent pas assurer de rendre la main dans les temps si une tache GPU est trop longue.

Je pense qu’on ne peut pas faire plus clair comme explication. Du coup j’arrête la je n’ai pas que ça a faire de tenter d’expliquer des trucs à des gens obstinés. " />



Je crois que tu n’as pas compris pourquoi Microsoft a fait ça en fait.
Ils ne l’ont pas fait parce que les marchands de GPU ne peuvent pas le faire à leur place (ce qui serait complètement ridicule puisque ce sont eux qui font les pilotes de leur matériel quand même).
Ils ont fait ça parce qu’ils ne contrôlent pas ce que font les marchands de GPU, et qu’ils voulaient une solution qui garantisse à windows d’avoir des ressources dans tous les cas.
Il est tout à fait naturel pour Microsoft de prévoir un système qui puisse redonner la main à windows (qui utilise le GPU pour la composition de la GUI), au cas où une application trop gourmande viendrait à le monopoliser.
Ils font aussi ça pour faciliter le boulot des développeurs d’applications sous Windows.
Maintenant le constructeur du GPU peut trés bien implémenter des mécanismes bas-niveau pour faire la même chose dans le driver. Le pilote sait de quel contexte viennent les instructions qu’il doit exécuter (sans quoi il ne pourrait pas y avoir d’utilisation concurrente du GPU), il peut donc trés bien partager le temps d’exécution en fonction des contextes et éviter les problèmes de déni de service. Ce n’est pas quelque chose de facile à faire, car il est trés difficile d’arbitrer l’utilisation des ressources de façon “équitable”. Mais ce n’est pas impossible, et la solution de Microsoft dans ce domaine n’est pas universelle.

Et désolé d’être obstiné, mais je ne peux pas te laisser dire n’importe quoi sur WebGL. Tu t’appuies certes sur des articles de Microsoft parlant des problèmes de TDR, mais tu oublies de dire (un peu comme eux), que ce type de problème survient sans même utiliser WebGL. L’utilisation par Microsoft de l’accélération matérielle dans le navigateur peut également provoqué ce type de problème, tout comme des programmes Flash qui permettent également d’utiliser les shaders.
Étrangement ça n’empêche pas Microsoft d’autoriser ces technologies dans leur navigateur…

Le 16/11/2012 à 13h 18

charon.G a écrit :

NVidia ne peut pas corriger les problèmes de TDR. Ils n’ont aucun contrôle sur l’execution d’un program shader. Tu as lu le lien ou quoi? Le mec a juste créer un program shader très gourmand pour provoquer le TDR.
Il arrive régulièrement que des utilisateurs se tapent le message d’avertissement du TDR comme quoi le driver graphique ne répondait plus. Mais même avec ça ces problèmes n’existent pas d’après toi :(

Enfin bref là j’ai tout dis j’arrête là. J’ai des problèmes personnels bien plus importants à résoudre " />



Comment ça ils n’ont aucun contrôle sur l’exécution des shaders ?!
Les shaders s’exécutent sur le GPU, bien sur que si qu’ils peuvent contrôler ce qui s’y passe. C’est justement ce que Microsoft leur demande explicitement (cf. ta citation)
To prevent timeout detection from occurring, hardware vendors should ensure that graphics operations (that is, direct memory access (DMA) buffer completion) take no more than 2 seconds in end-user scenarios such as productivity and game play.

Bref c’est bien à Nvidia et consort de mettre en place les watchdogs (ou de scheduler) en amont, avant que la couche de Microsoft ne s’en occupe.
Pour le reste tu continues à brasser du vent, moi je n’ai toujours pas vu de sample code WebGL qui plante mon système.

Le 16/11/2012 à 12h 24

charon.G a écrit :

GPU reset


C’est vieux ça, Nvidia a déjà mis en place des corrections pour les problèmes de TDR dans ses pilotes… L’an dernier.
J’attends encore de voir un sample code WebGL qui produit ce genre de problème sur un système avec un navigateur récent.

Le 16/11/2012 à 10h 58

charon.G a écrit :

Si tu trouves une faille sur un pilote récent nvidia et puis Ati. Généralement les failles existent depuis longtemps. Je t’ai expliqué avant que les drivers graphiques sont de vrais passoires. Donc tu crois que WebGL va bloquer ces pilotes. Ca signifierait que quasiment plus personne puisse accéder à WebGL. Sur le coup je doute que les devs de WebGL fassent le blacklist nécessaire.

Pour le GLSL comment ils gèrent l’attaque DDOS qui consiste à envoyer un program shader très lent. Je doute fort qu’ils vont s’amuser à mesurer le temps d’éxecution du code. Ca ressemble plus à une heuristique qu’autre chose.



Le blacklistage n’est pas fait par celui qui écrit le code WebGL, mais par l’éditeur du navigateur. Ce n’est pas “je crois”, c’est déjà en place chez Mozilla et Google dans leur navigateur respectif, et ça marche trés bien.
ça veut dire quoi “envoyer un programme shader trés lent” ? Depuis tout à l’heure tu parles dans le vide, donne un exemple concret.
J’ai déjà fait des shaders qui “rament” sur un GPU faible, au pire j’arrive à faire ramer le navigateur, jamais je n’ai réussi à faire planter l’affichage du PC via WebGL.

Le 16/11/2012 à 10h 31

charon.G a écrit :

Je doute fort qu’il soit possible de voir si le code d’un program shader soit mauvais ou pas. Pour donner un exemple c’est comme si tu racontais qu’on pouvait écrire un programme qui empêche de faire bugger d’autres programmes.
Pour le blacklistage donc si on trouve une faille sur un pilote qui existe depuis le début on bloque l’accès à WebGL sur toutes les machines. Ca aussi c’est très foireux.



Détrompe toi.
Le GLSL que permet OpenGL ES 2.0, est beaucoup plus limité que ce qu’un langage classique comme le C permet de faire. De ce fait il est bien plus simple de détecter une anomalie dans le code.
Et je ne vois pas ce que le blacklistage a de foireux, puisqu’il ne bloque WebGL que si la version des pilotes est trop ancienne et comporte une faille. C’est une saine façon d’alerter les gens sur la nécessiter de mettre à jour leur pilote.

Le 16/11/2012 à 09h 22

charon.G a écrit :

Demande à un programmeur de jeux vidéo. C’est arrivé plusieurs fois à des programmeurs DirectX de faire planter la pile graphique pendant le développement d’un jeu.
.
Sinon certains vieux jeux conçus sous XP font planter la couche graphique car le program shader rend pas la main assez tôt
Dans cette histoire il y a deux choses:
L’attaque DDOS c’est le plus simple à faire

*Mais tu as aussi tous les bugs dans les drivers graphiques et même les cartes graphiques. Par mon boulot je peux te dire que les drivers graphiques sont les drivers les plus buggés qu’on peut trouver. Tu devrais demander à Jean Baptiste de VLC ce qu’il en pense il a déja approuver ce post dans un de mes anciens commentaires.



Je suis déjà développeur 3D, donc je connais la problématique.
Si je demande un exemple concret c’est parce que la situation a pas mal évoluée depuis le début de WebGL. Contrairement à un programme natif, les applications WebGL passent par le parser du navigateur qui peut autoriser ou pas certaines choses, voir même modifier les shaders avant de les compiler. De même certains pilotes 3D peuvent être “blacklistés” s’ils possèdent un problème connu, empêchant toute application WebGL de tourner.
Bref les problèmes de sécurité ne sont pas plus élevés que ceux qui concernent les API 3D de Flash par exemple. Tant qu’il n’y a pas d’exemple récent démontrant une réelle faille de sécurité, ça relève du FUD.

Le 16/11/2012 à 08h 38

charon.G a écrit :

C’est faux il suffit de faire un shader programme un peu long et tu fais une DDOS sur le sous système graphique. Il n’y a aucun moyen de l’éviter. Et quand tu rends ce genre de possibilité disponible à n’importe quelle page web , ça fait peur.


Je suis curieux d’avoir un exemple concret dans ce cas… Pour le moment ce n’est que du FUD.

Le 15/11/2012 à 17h 37

charon.G a écrit :

Je t’invite à lire ceci
C’est la raison pour laquelle Microsoft ne gère pas WebGL ils se sont déjà exprimés la dessus.



L’eau a coulée sous les ponts depuis… Les failles ont été corrigées et la sécurité a été renforcée à la fois du côté des navigateurs et des pilotes 3D.
Ces craintes là n’ont plus lieu d’être, et l’excuse de Microsoft ne tient plus.

Le 25/10/2012 à 13h 47

mirandir a écrit :

Peut-être parce que leur pilote Windows n’est pas sous licence libre, tout simplement ?
Et qu’ils ne peuvent / veulent pas le changer de licence ?



Et bien c’est justement le pourquoi de ma question… Ce serait bien qu’un officiel d’Intel statue là-dessus, qu’on sache à quoi s’en tenir.

Le 25/10/2012 à 08h 11

brazomyna a écrit :

Leurs PDM respectives ?

Moi je dis ça, je dis rien, hein … " />


Rien à voir… Le driver ils l’ont, et à côté ils font du dev spécifique pour Linux où ils ré-inventent la roue. Pourquoi tout refaire sous Linux au lieu de porter le pilote OpenGL 4.0 dont ils se servent sous Windows ?
Pour ceux qui ne le sauraient pas, je précise que le pilote OpenGL tourne en “user space”, et n’est pas vraiment dépendant de l’OS.

Le 24/10/2012 à 13h 53

liukahr a écrit :

Ils t’attendent.
(si on en vient à critiquer Intel sur ses drivers Linux, on est pas sorti …)


ça veut dire quoi cette réflexion ?
Ma question est tout à fait légitime. J’aimerai bien savoir pourquoi le pilote OpenGL 4.0 qu’ils ont ne peut pas être porté dans Mesa.
D’où vient cette différence de traitement entre les plateformes ?
Ce n’est pas parce qu’Intel fait de l’open source sur Linux qu’ils sont exempts de critiques.

Le 24/10/2012 à 12h 20

Et pour OpenGL 4.0 sous Linux monsieur Intel c’est pour quand ?
Pourquoi le code OpenGL de votre pilote Windows ne peut-il pas être fondu dans Mesa ?

Le 22/10/2012 à 11h 43

indyiv a écrit :

ok …
je suppose que cette fonction n’existe pas sur la version JB presente sur le Galaxy Note II ?



Si elle y est, toutes les nouvelles fonctions du GS3 sous JB sont déjà présentes dans la version livrée avec le Galaxy Note 2.

Le 20/09/2012 à 12h 13

L’auteur de la news n’a pas de sens de l’humour, ou alors il doit se sentir visé… ;)
Je trouve ça au contraire trés drôle et parfaitement avisé de se moquer des fanboys.

Le 14/09/2012 à 12h 46

à partir du moment ou on admet qu’un ultrabook n’est pas un PC de gamer l’argument d’Intel est parfaitement valable.

Personnellement je serais client d’un ultrabook puissant, sans carte graphique dédiée, et disposant d’une meilleure autonomie.

Le 11/09/2012 à 19h 02

ldesnogu a écrit :

Donc oui Intel est un bon client, mais certainement pas le plus gros.


C’est exactement ce que j’ai dis, je n’ai jamais dis que c’était LE plus gros client.


Certes, mais c’est moins la merde que ce qu’Intel en a fait.
C’est exactement pareil, si tu n’as pas le bon kernel pour tes modules binaires t’es sur le carreau de la même manière. Ce n’est pas parce que Ti a fait un peu plus de build qu’Intel que la situation est meilleure. Tant qu’IMGTech n’ouvrira pas ses pilotes ce sera le même merdier.


Sans vouloir te vexer, je crois que tu ne sais pas de quoi tu parles :) Les contrats entre ImgTech et leurs clients contiennent des clauses concernant la diffusion des drivers ; par exemple TI est capable de délivrer des drivers, qu’ils compilent eux-mêmes pour une cible donnée. Et Intel ne saurait pas faire ? Ouai, disons plutôt qu’ils ont fait preuve d’incompétence comme bien souvent pour tout ce qui concerne le graphique.

Sans vouloir te vexer je pense que c’est toi qui ne sais pas de quoi tu parles ;)
Tu sembles confondre 2 choses. Je sais très bien qu’ImgTech permet à ces clients OEM (comme Intel) d’avoir accès aux sources (je le sais car j’ai bossé avec eux), seulement c’est sous NDA uniquement. Sous aucun prétexte un client d’ImgTech n’a le droit de diffuser les sources du pilote.
Du coup pour les clients finaux ça ne change rien, le pilote est toujours fermé, et le suivi du kernel Linux comme de Xorg est laissé au bon vouloir du constructeur.


Parce qu’ouvrir un pilote signifie qualité ? Oui oui bien sûr " />

J’adore les gens qui ré-interprètent ce que je dis pour inventer des choses que je n’ai pas dit." />
Ouvrir le pilote ça permet simplement le suivi des sorties du noyaux et de Xorg, bref ça permet d’avoir un vrai support “out of the box” sans dépendre du bon vouloir du constructeur.

Le 11/09/2012 à 08h 47

ldesnogu a écrit :

Par ailleurs, il existe pas mal de plateformes a base d’ARM ou les chips PowerVR sont bien supportes y compris sous Linux. Ce n’est pas ImgTecg qui est responsable du fiasco sur Atom, mais bien Intel " />


Intel était quand même un gros client, il n’y a pas qu’Apple dans la vie…
Très peu le sont en réalité, et elles nécessitent des versions du noyaux bien spécifiques avec lesquels les pilotes sont compatibles.
l’IP appartient à ImgTech, c’est eux qui fournissent les pilotes pour leur chip, donc le fiasco sur atom c’est bien de LEUR faute… Intel ne peut pas ouvrir les pilotes d’un matériel qui ne leur appartient pas.

Le 11/09/2012 à 07h 25

Drepanocytose a écrit :

C’est justement un peu ce que Quiproquo dit.
C’est selon le bon vouloir d’Intel, selon le sens du vent, et surtout selon l’endroit d’où vient l’odeur des profits futurs…
Bref, on est en droit d’avoir 2 ou 3 craintes….


Heu non, ce n’est pas selon le sens du vent. Intel n’avait pas de technologie prête pour l’embarqué avant, c’est pourquoi ils ont utilisé un GPU sous licence.
Avec Haswell ils vont avoir un GPU compétitif et surtout des drivers libres “à la page”.

Le 10/09/2012 à 21h 15

Quiproquo a écrit :

Donc si Intel décide, pour des raison de pragmatisme, d’intégrer des technologies propriétaires dans ses prochaines générations de CPU, et de ne pas proposer de drivers pour Linux, tu sera « plutôt content de ce genre d’évolution » ?

Pour mémoire, c’est exatement ce qui s’est produit pour l’Atom Cedarview. Sous prétexte (parfaitement louable) de proposer des modèles performants, Intel n’a pas utilisé sa technologie pour laquelle il existe un driver libre, mais a acheté une license à un partenaire pour une puce qui n’a ni driver libre ni driver propriétaire.


Je suis parfaitement au courant de ça, et je n’ai pas apprécié non plus cette décision.
Mais justement avec Haswell, Intel revient sur cette décision et va intégrer sa propre technologie supportée par des pilotes libres. Imagination Technology va donc perdre un gros client.

Le 10/09/2012 à 21h 09

Drepanocytose a écrit :

C’est un point de vue.
On pourrait aussi dire que moins d’intégration = + de possibilités pour y mettre ce qu’on veut = + de concurrence = + de choix = mieux


En temps normal je serais d’accord avec ça, mais le problème c’est que les constructeurs tiers ne font pas tous autant d’effort qu’Intel en terme d’ouverture…


Quant aux “composants exotiques” qui coutent cher pour marger à mort : comment dire…. Ca donne un peu l’impression que Intel c’est le bien et le reste c’est le mal. Ce qui est loin d’être le cas.
Ce n’est pas le prix que j’attaquais, mais le fait qu’on propose des composants de mauvaise qualité, pour que le constructeur conserve sa marge dessus (voir l’augmente).

Quant au “non-respect des standards” : je ne suis pas assez calé, donne nous des exemples. A moins que tu ne parles du standard imposé de facto par Intel. Auquel cas je dirais que je préfère moins de standard qu’un standard unilateral et intéressé.

Des exemples il y en a pleins, comme les ACPI buggés conçus pour ne fonctionner que sous Windows…

Le 10/09/2012 à 15h 18

En tant qu’utilisateur de Linux, je suis plutôt content de ce genre d’évolution chez Intel, car plus d’intégration signifie aussi plus de standardisation.
Outre les économies d’énergie, ça permettra aussi de mieux supporter les plateformes Intel.
Et tant pis si ça ne fait pas plaisir aux OEM, eux qui emploient souvent des composants exotiques ne respectant pas les standards, afin d’augmenter leurs marges au mépris du client.

Le 05/09/2012 à 22h 31

Tolor a écrit :

Ni Samsung, ni Nokia, ni HTC ne va donner une date de sortie ou un prix, il y a apparemment un embargo (par MS) sur tous ces détails jusqu’au 30 septembre. Donc c’est pas “on sait pas quel prix on va le vendre”, mais “on peut pas dire quel prix on va le vendre”. Et Samsung avec son Ativ S est dans le même cas.



Microsoft n’a pas encore envoyé la facture de l’OS aux constructeurs, alors ils ne peuvent pas encore fixer le prix ? " />