antistress a écrit 4409 commentaires

C'était à force de traîner sur Phoronix et de rien comprendre aux articles parce que chaque paragraphe utilisait au moins 10 éléments de la stack graphique :)

pareil !

Les pilotes privateurs çaÿlemal
J'achète des IGP Intel depuis que j'utilise Linux parceque je ne suis pas maso (GMA 950, HD Graphics 4000).
Sinon faut te plaindre à NVidia, pas aux développeurs Linux et co
Heureusement il y a de gros progrès dans les cartons pour Nouveau (attends la dépêche à venir sur linux 3.7)

Bonne idée, le sondage !

La bascule entre deux processeurs graphiques distincts au sein d'un même ordinateur portable, en fonction des priorités du moment (performance ou autonomie) sera rendu possible avec X.Org grâce aux derniers développements libres réalisés par Red Hat et Texas Instruments au sein de Linux 3.5 et RandR 1.4 (inclus dans X Server 1.13) + adaptation des pilotes correspondants.
Mais il faut des pilotes libres (couple nouveau/intel par exemple)

Sinon on peut lire la dépêche jusqu’au bout :

contrairement à ce que laisse entendre le titre tapageur de la dépêche, atteindre la version 1.0 ne signifie pas que Wayland va magiquement et instantanément remplacer X.Org dans toutes les distributions.

Comme dirait Ken : X.Org est mort mais il ne le sait pas encore

Quand tu regardes Mutter, GNOME a déjà un compositeur-gestionnaire de fenêtres, ils doivent l'adapter à Wayland à mon avis ça devrait pas être trop dur car basé sur Clutter qui est en phase avec Wayland (Intel des deux côtés).
Pour KDE ça risque d'être plus compliqué :

Our current planning is to make KWin our Wayland Compositor. […] it seems to me that extending KWin with Wayland support is the only possible solution right now. Now KWin is an X11 based window manager and compositor. It’s development started in a time when nobody expected that there could be anything else than X11, so you could say that it expects that all that exists is X11. This means the difficulty in porting KWin to Wayland is not in adding Wayland support to KWin, but in making it possible to have a KWin without X11 support or at least to be able to start KWin without needing an X Server.

Cependant :

the refactoring work I recently blogged about is an important step on the road towards Wayland. Especially the splitting of the OpenGL compositor is very important. This means that the actual Compositor (SceneOpenGL) does no longer depend on X11. The dependency has been moved into an OpenGLBackend with currently an GlxBackend and EglOnXBackend. This makes it much easier to add further backends in future to e.g. support KWin on top of another Wayland compositor or KWin on top of KMS through libgbm.

Arf c'était toi ? Le monde est petit ! L'idée était bonne, j'ai saisi la balle au bond quand j'ai écrit un article similaire sur mon blogue :-)
Et dimanche dernier j'ai fait un joli schéma explicatif

Je pige pas en quoi l'installateur doit être modifié pour prendre en compte UEFI ? Si UEFI est configuré pour booter sur CD ou USB, ça change quoi par rapport au BIOS vu que rien ne se passe tant que l'un ou l'autre (l'UEFI ou le bIOS) n'a pas rendu la main ?

ETC2 Texture Compression For Intel Is Happening

Before getting too excited, however, this ETC2 support isn't a full implementation for texture compression on the hardware but rather is just immediately decoding the ETC2 data into RGBX data.

Even if these patches aren't the best, at least in time for Mesa 9.1/10.0 in early 2013 we should have proper ETC2 support for at least the open-source Intel driver. They really want OpenGL ES 3.0 in Mesa by time of the next release and with GLES 3.0 comes the hard requirement on ETC2 support.

Par contre une texture ETC1 marche avec les appareils supportant ETC1 ou ETC2 (=un appareil ETC2 peut décoder le ETC1).
Et il est possible de stocker une texture ETC1 et ETC2 dans un même fichier sans pour autant que le fichier ne prenne la place de deux textures (certaines parties, on ne sait quel pourcentage, sont partagées). Voir ce lien.

ETC2 Texture Compression Looks Good For OpenGL

Par ailleurs : ETC2 Texture Compression For Intel Is Happening

Lié ou pas : Intel Mesa To Force On S3TC, Floating-Point Textures

Comme dit vers le milieu de la dépêche, les photos mais aussi les vidéos et les sons sont gérés !

merci !

Merci pour la précision même si je conçois mal la différence

Casey Muratori dissects the consequences of Windows 8's closed distribution model. "But how realistic is the assumption that the Windows desktop will still be a usable computing platform in the future? And what would be the consequences were it to disappear, leaving Windows users with only the closed software ecosystem introduced in Windows 8? To answer these questions, this volume of Critical Detail examines the immediate and future effects of Microsoft's current certification requirements, explores in depth what history predicts for the lifespan of the classic Windows desktop, and takes a pragmatic look at whether an open or closed ecosystem would be better for Microsoft as a company." The section that details how none - none - of this year's greatest games (or last year's fantastic Skyrim) and only one of this year's Emmy-nominated TV shows pass Microsoft's rules sent chills down my spine.

http://www.osnews.com/story/26471/Windows_8_the_next_twenty_years

(je grasse)

C'est sûr que les choix par défaut (conservés par 99% des utilisateurs) sont sans incidence.
http://www.framablog.org/index.php/post/2009/09/19/parametrage-par-defaut

Source : http://www.phoronix.com/scan.php?page=news_item&px=OTkxMQ

Oui! Mais il existe quelques incompatibilitées comme signalé en commentaire par Laurent ci-dessus ou sur le rapport de bogue Ubuntu.
Si ça pouvait être réglé, S2TC serait de mon point de vue une vraie avancée pour les OS libres.

Une remarque complémentaire sur les brevets de S3TC que j'oublie de mettre depuis le début de cette dépêche : S3TC serait dans le giron de HTC si j'ai bien suivi, et Intel a émis publiquement de sérieux doute quant à la validité du brevet. Mais tant que le brevet n'est pas invalidé…

Tu veux dire que mesa rejette S3TC pour cause de brevets et pourtant met quand même les deux pieds dedans au titre de la compression ?

Arf j'ai peut-être extrapolé.

J'avais déduit de cette phrase que les puces autres que PowerVR géraient ETC mais ce n'est pas ce qui est écrit en fait :

At the same time it will be interesting to see how developers adopt ETC. Just because it’s a standard doesn’t mean it has to be used, and while we can’t imagine Android developers not using it once OpenGL ES 3.0 is the baseline for applications, Apple bears keeping an eye on. As a PowerVR-only shop they have used PVRTC since day one, and so long as they don’t change to another brand of GPUs they wouldn’t need to actually back ETC.

Apparemment Mali-400 gère ETC 1 ou 2 ?

Pire, au niveau logiciel, Wikipédia EN ne parle que de ETC1

Android version 2.2 (Froyo) includes support for ETC1

J'ai pas compris ! Mais Mesa fait comme Firefox, elle laisse faire une autre brique (la bibliothèque S3TC suscitée en l'occurrence) qui est optionnelle pour cause de brevets logiciels. Comme les codecs brevetés dans nos distributions.

La gestion du S3TC est nécessaire pour les jeux Valve, quelque soit le moyen (S3TC ou S2TC).

Source Ubuntu :

We’ve brought in a patent-free S3 texture compression library for mesa required by Valve and the Humble Indy Bundle, to be installed on user systems by default starting with quantal (and precise via PPAs). And we’re working on getting mesa 8.0.4 SRU’d into precise (not required by Valve, but brings numerous fixes other games and 3D apps need).

Matériellement ou pas, si l'on en croit un des dévs Intel :

None of our currently shipping hardware has native support for ETC2, which means we have to implement it in software. That means that textures are uploaded and stored to the GPU in an uncompressed format, which isn't terribly efficient, but there's not much else we can do. That will at least make applications using ETC2 compressed textures work.

Ce n'est pas la communauté qui dicte les formats de l'industrie sur ce coup là. Il faut donc faire en fonction.