Le support de la lecture des mp3 est un problème lié à des brevets, d'une part, et des brevets qui sont géographiquement limités d'autre part. Je voit donc pas le rapport avec la liberté, sauf à considerer que la loi US s'applique partout ( et c'est pas le cas ).
Les données statistiques sur les études psycho-accoustiques
a) Ne sont pas un logiciel
b) sont protégées par Fraunhofer (standard) ou Thomson (MP3 ISO) au titre du droit d'auteur (comme souvent pour les études et les statistiques)
c) Sont nécessaires à la compression ou à la décompression de tout contenu Mpeg-Layer3
De même, la partie sur les exportations rends peut être la copie illégale dans certains pays vers d'autres pays, mais ça ne veut pas dire non libre. Sinon, y a plein de soft qui sont illégaux parce que l'allemagne les interdit ( genre les softs de secu ).
En ce qui concerne l'implémentation de base du système Kerberos, tu n'as pas le droit de la faire sortir des US. Donc si tu l'installes sur un poste qui n'est pas aux US, ou qui est ammené à sortir des US, le gouvernement Américain a le droit de demander ton extradition pour te poursuivre sur le sol américain suivant la loi des US.
On va dire que ca compte comme "distribution/reproduction pas libre"
La probléme des noms de marques est différent des problèmes de restrictions sur les 4 libertés. Jamais il n'a été dit qu'un soft libre implique de pouvoir garder le nom original, même si il y a des problémes pratiques à ce genre de choses.
Il y a, par exemple, une pléthore de versions d'Emacs qui ne sont pas officiellement sanctionnée par RMS lui même. Ca ne veut pas dire que RMS va toutes les attaquer demain, mais ca veut dire qu'elles sont dans l'illégalité vis à vis des lois sur le copyright. De fait les distribuer constitue un délit de contrefaçon. Donc distribution non libre.
Idem le kernel de gNewSense avait été amputé de pas mal de fonctionnalités (notamment les wrappers et GLX). Je doute fortement que celà ait été cautionné officiellement par Linus Torvalds...
Enfin les drivers obsfusqués dont tu parles, c'est sur nvidia
Non, non c'est sur Intel. Notamment les puces graphiques GMA dont le code est cryptique à plusieurs endroit pour éviter les ennuis avec certains brevets sur la 3D et les puces Wifi, dont les pilotes sont écrits pour rendre complexe l'utilisation des ondes en dehors des normes américaines. Et commencer à glisser des considérations de facilité de lecture dans une définition de la liberté, c'est la porte ouverte aux discussions sans fin et au troll infini.
Quand la boite elle même dit "vous aurez pas les specs et le code sera en hexa brut pour pas que vous puissiez contourner" c'est pas une considération, c'est un fait.
De plus, la fsf reconnait que la license d'apache 2 est libre et compatible avec la GPL v3
cf http://www.fsf.org/licensing/essays/apsl.html :
# It is not a true copyleft, because it allows linking with other files which may be entirely proprietary.
It is incompatible with the GPL.
cf http://www.apache.org/licenses/LICENSE-2.0.html
4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
1. You must give any other recipients of the Work or Derivative Works a copy of this License; and
2. You must cause any modified files to carry prominent notices stating that You changed the files; and
3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
4. If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
Après la FSF peut dire que c'est libre suivant sa définition à elle... Mais honnêtement faut le dire vite.
Donc je trouve que la dispute en question a permis à beaucoup de personnes ayant des conceptions encore plus approximatives que les miennes de donner un avis que j'estime erroné, juste pour contredire RMS. Bien sur, c'est pas du tout le caractére de certaines personnes, c'est un hasard.
Je pense juste que tes conceptions aproximatives, sont un peu plus approximatives que tu ne le penses.
Tout ce qui est sous une licence quelconque, BSD, GPL, proprio ou qu'importe est couvert par le droit d'auteur (copyright). Donc arrêtez de balancer des absurdités sur les "noms copyrightés".
La question n'est pas là. La question est :
"Est-ce que tu peux faire un fork d'OpenBSD et appeler ce fork OpenBSD" : Réponse OUI
"Est-ce que tu peux faire un fork de Linux (ou Apache) et appeler ce fork Linux" : Réponse NON
Par fork j'entends démarrer un projet complet qui n'aurais pas pour vocation de rejoindre le tronc principal, mais de créer un tronc totalement distinct.
Si on ne fait des distros qu'avec ce qui est dans le domaine public, on ne fera même pas une calculatrice.
Entièrement d'accord. C'est d'ailleurs pour celà qu'il n'existe AUCUNE distribution complètement libre. Même pas au sens de la FSF... D'ou le qualificatif "hypocrite".
La FSF est cohérente, elle ne va pas dire que Fedora ou autre est 100 % libre si selon les critères de la FSF ce n'est pas le cas.
Au moins avec la liste que dresse la FSF, on sait où on met ses pieds.
On va juste dire que les critères de la FSF en matière de 100% libres sont étrangement élastiques.
Lors de l'incartade entre RMS et de Raadt il y a eu plusieurs remarques qui ont été assez sanglantes contre les distribs 100% :
Certaines incluaient le support de la lecture MP3 (corrigé depuis)
Certaines incluent des éléments non libres à l'exportation US comme le Kerberos (contre argument : c'est pas grave il y a Heidmal qui fait la même chose chez ceux qui sont pas aux US)
Certaines incluent le support fat, y compris avec les noms long (Position officielle de gnewsense par exemple : on ne reconnait pas les brevets logiciels, donc on ne retire pas exprès des fonctionnalités à cause des brevets)
Toutes incluent des noms copyrightés (Linux, Emacs, Apache etc.)
Certains pilotes libres sont volontairement illisibles (obsfucated) et masquent des fonctionnalités du hard (pilotes intel notamment)
Quasiment toutes les distribs incluent apache2 (dont la licence est pas vraiment libre même pour un gpliste)
etc.
Donc quand la FSF déclare que certaines distribs sont 100% libres, elle est hypocrite. C'est le point de vue de Theo de Raadt, et c'est aussi le mien.
Et pour les autres trucs sous copyright, comme le nom "Linux" ou le nom "Emacs" on fait quoi ?
On enlève aussi les produits des distribs qui se veulent 100% libres ?
Des clients mécontents ? Allô Microsoft ? J'ai acheté Hyper-V parce que j'avais lu dans les journaux, et que vous m'avez dit que c'était pris en charge par le noyau Linux, et ça ne marche pas !
La c'est vrai. Ca va avoir un impact au moins aussi grand que quand ATI avait annoncé que les prochaines cartes radeon serait livrées avec un pilote Linux complet.
Ca va saigner.
Tres bon post, mais tu n'as pas mentionné ce qui est pour moi l'inconvennient numero un du GPGCU à l'heure actuelle : l'absence quasi totale de registre mathématique et de FPU des familles.
Quand un regsitre déborde, c'est un peu au petit bonheur la chance (parfois une erreur, parfois une rotation du registre sans rotation de carry (bien entendu, il y en a pas), parfois 2^x +1 = 2^x). Les arrondis dépendent du sens du vent et les trap à erreur genre "not a number" et "division by zero" sont variables d'une carte à l'autre.
En bref pour faire du GPGCU il faut quand même avoir une bonne maitrise de ses éléments de départ sinon c'est un poil le mur.
Pour moi un algorithme c'est une méthode pour résoudre un problème ou pour compléter une tâche, cela peut donc n'avoir aucun lien avec les mathématiques.
Définition presque parfaite, un algorithme est une méthode systématique pour passer d'un etat A à un etat B.
Systématique est utilisé ici dans les deux acceptions du terme :
a) reproductible
b) qui marche à chaque fois
Si ca ne marche pas à tous les coups, c'est juste une méthode.
Le seul utilitaire de sauvegarde qui se vautre pas comme une loutre bourrée à la bière sur les partitions corrompues, qui se moque des caractères bizarres/étranges/altérés/UTF-8 lors de la sauvegarde, qui sauvegarde les chemins de 1023 caractères de long au minimum (et plus suivant les versions), qui est compris par à peu près tous les unix et unix-like du monde et qui peut sauvegarder des hard links en cascades sur des kilomètres ?
Bon ca prend du temps et d la place, mais dump ca permet d'avoir une sauvgarde sure dans un coin (pan !) entre deux rsync.
C'est toute la notion blob + binaire qu'il faut prendre en compte.
Il n'y a aucun problème à lier un module binaire qui ne soit pas un blob (ie qui ne soit pas une boite noire, c'est à dire un module dont on a les specs )
Il y a pas trop de problèmes (encore que) à compiler un blob source et à le lier (c'est à dire que le code est pas commenté, voire volontairement complexifié)
Par contre il y a un gros problème à lier un truc qui soit les deux. Parceque comme on a pas les specs on peut pas en faire un autre, et comme on a pas les sources on peut pas le commiter dans une branche délocalisée du noyal pour valider que ca compile toujours, ne fait pas de warnings etc.
Windows est un système de merde, d'accord, mais le matos de marque est très bien supporté.
Alors ca faut le dire super vite.
Quelques exemples :
- Sous Vista patché les Geforce 7xxx mobility sont très très mal supportée (plantages, affichage corrompu, freeze etc.) Nividia ne sort pour ainsi dire plus de pilotes pour cette série. Les mecs qui ont achetés des Qosimo Toshiba il y a un an à 18 mois sont ravis.
- Sous windows de façon général le matériel sonore est géré de façon un poil accrobatique. Notament quand on a plusieurs périphériques son. Et je fais grace des fois ou un débranchement rebranchement d'un périphérique d'aquisition (comme un enregistreur mobile) provoque la redétection d'un nouveau matériel avec installation de pilotes supplémentaires et demande de reboot. En poste nomade, Windows pour la prise de son et le mixage il vaut mieux oublier.
- Plus récemment j'ai vu un système de prise de son entier être reconnu par XP comme un disque fixe. Pas moyen de l'ejecter. Obliger d'éteindre proprement l'ordinateur entre chaque prise de son pour être sur que le mixage soit sauvegardé.
Je t'accord que sous Linux le son est très complexe à mettre en place, surtout sur du matériel pro (le plus dur restant quand même de claquer définitvement la gueule à pulseaudio pour ne pas qu'il se remette en place à la prochaine mise à jour). Mais JACK + OSS4 ou même JACK + ALSA est très loin devant tout ce qui se fait sous Mac ou Windows en terme de qualité ou de fiabilité.
en même temps, si ils ont décidé de faire des changements APRES la mise en prod, c'est peut être que le jeux en valait la chandelle ? non?
Ben ca avait deux avantages principaux :
a) faire une console qui coute moins cher et donc qu'on a plus de chance de rentabiliser au final.
b) faire une console qui plante moins. Parceque les premiers batch de PS3 ont quand même eu pas mal d'emmerdes.
Je te rassure tout de suite, l'immense majorité composants utilisés dans les consoles, ce ne sont pas des composants fabriqué "sur mesure" en très petite série hein. Quant à "l'alimentation" les grands principes sont connue et archi connu. Pas comme si ils réinventait la poudre non plus.
Le principal problème lors d'un design de carte mère, ce sont les putains d'effets parasites. Deux fils se suivent sur plus de quelques milimmètres : condo parasite. un fil fait le tour de la plaque pour economiser un layer : hop bobine parasite. Un condensateur est au taquet de sa marge d'erreur : hop résonnance radio avec d'autres composants. etc.
Et pour l'alimentation, même si les grands principes sont connus, c'est pas forcément évident d'avoir de bonnes bobines quand tu les fait fabriquer spécifiquement pour toi car ton alim doit tenir dans un mouchoir de poche. Un bon transfo à découpage dans une intensité/tension non standard coute une fortune.
Clair... surtout quand des labos achètent des ps3 par rack entier car c'est une plateforme de dvp du cell pas cher, et on peut faire de beau truc avec.
Clairement ils ont du vendre à tout casser 2000 consoles à des labos qui les transforment en serveur grid. C'est avec ca qu'ils vont amortir leur R&D...
Tu réalises que des cartes mères (c'est ce dont on parle là) demande certe du boulot, mais est bien loin d'être la tache la plus couteuse du dvp
Oui de la carte mère, de tous les processus de fabrication qui vont avec, des problèmes alimentation, de design des bus externes, de controlleurs etc.
Pour la PS3 il y a eu 18 versions de la carte mère avant la sortie définitive (je ne parle que des préséries là, pas des prototypes). Et ca a juste couté son poste au grand manitou console de chez Sony. Depuis la sortie de la version commerciale il y a eu 9 évolutions de la carte mère, avec des modifications significatives : Le hard PS2 a giclé, les principaux controlleurs ont été changés, l'alim a été redessinée etc. Avec à chaque fois des lignes logisitiques à remettre en place et des usines à reconfigurer. Plus bien sur les tests qui vont bien etc.
tu trouves mêmes des cm à 30€ prix ttc, qui certes sont amortis sur le grande fabrication
Les cartes mères à 30€ sont le plus souvent des reference design constructeur (via, amd, intel ou nvidia) avec très peu d'autres modifications que de tirer un bus PCI sur la carte pour alimenter une carte son. On est très loin de la conception d'une carte mère, c'est purement de la fabrication. Et qui plus est de la fabrication sur du matériel hyper connu et répandu, avec des alims standards. Bref on est très loin de la carte mère mono machine, mono usage pour laquelle le fabriquant paye le design au prix fort.
et c'est là où intervient l'achat de jeux, la vente de licence de dvp, la conception de produits à bases de cell
Alors pour la conception de produits à base de cell, Sony ne touche rien. Et pour le reste si la console sert à faire tourner des applications devellopées sur un autre OS, Sony ne touche rien non plus. En bref l'option "other OS" a un impact ecconomique négatif pour Sony.
la R&D sur le cpu a été fait conjointement avec IBM et toshiba, et vise a équiper plusieurs type de machine.
De plus IBM et Toshiba se "rattrapent pas" sur les jeux eux.
Quant à la puce graphique, elle a été achetée, donc difficile quand même a "cacher".
Tu réalises, bien sur, que même quand tu as un processeur et une puce graphique stables et testés massivement (ce qui n'a pas été le cas pour la PS3) tu en as encore pour plusieurs années hommes de boulot avant de sortir une console de jeu qui fonctionne.
Ca fait partie des "couts de developpement" d'un produit, et n'impacte pas le fait que la console en elle même n'est pas vendue à perte (que la somme des matières premières utilisée pour la construction de la console ne coute pas plus que le prix à laquelle elle est payée).
Légalement elle n'est pas vendue à perte. Comptablement Sony perd de l'argent sur chaque console vendue (de moins en moins, mais encore un peu)
Après tout ça devait faire vendre des PS3 cette fonction non ?
Les PS3 sont vendues à perte (avec des jeux comptables pour étaler maintenance des firmwares , usines et R&D sur des années pour donner l'impression que c'est vendu à prix coutant).
Sony se fait du pognon sur les jeux.
En plus les os autres sont une bonne porte d'entrée pour qui veut jouer des jeux piratés/casser les codes blue-ray/tricher en ligne etc.
je ne suis pas sûr que ça vaut grand chose aux yeux du tribunal ...
De toute façon, comme il s'agit ici de "racheter" la société et pas seulement de reprendre des actifs d'une société qui ferme proprement (comem ce fut le cas avec Blender par exemple) tout se complique.
Pour faire appel à l'épargne populaire (ie demander du pognon en échange d'action à des gens qu'on ne connait pas) il faut être coté sur un des marchés qui existe. Pour être coté sur un marché en France il faut être
a) ne pas être en cessation de paiement
b) ne pas être en redressement, liquidation, protection judiciaire
c) être à jour fiscalement (surtout en ce qui concerne la TVA et l'URSSAF)
d) bien sur ne pas être interdit bancaire.
Plus tout un tas d'autres trucs mais je ne crois pas me tromper en disant que les quatres premières conditions ne risquent pas d'être remplie de si tôt.
La seule chose qui soit possible à plusieurs, c'est de laisser la société mourrir et de la racheter en liquidation. Au moins comme çà on se débarasse du passif et des employés et on garde les technos. Bon ca va juste poser un petit problème pour présenter un dossier qui plaise au juge et un chèque total qui devra bien être signé par quelqu'un...(Ceci étant, je doute que ca se presse au portillon pour reprndre la société, donc le juge risque de prendre à peu près n'importe quel chèque de plus de 30 000€ pour les caisses de l'Etat)
Après avant de retrouver des fournisseurs qui vont accepter de retravailler avec la société ca va être drole. Particulièrement les mecs qui ont les moules à injecter pour faire la coque...
Un CDD reconduit pendant 20 ans n'a qu'à se présenter aux prudhommes pour que son contrat passe en CDI d'office
Et non, les militaires sous contrats et certains autres fonctionnaires ne peuvent même pas pleurer aux prud'hommes...
A noter cependant qu'il s'agit de contrats fermes, donc sans période d'essai.
Si tu resetes ta dédibox, au moment ou tu te fais voler ont téléphone portable alors que tu est en train de déménager, il devient très dur de contacter le service de support.
Et aussi d'utiliser un périphérique sur le réseau comme carte son. Cela permet de lire les fichiers sur le PC principale et de diffuser dans toute la maison (enfin là où un périphérique capable de recevoir le son est présent).
Music Player Daemon fait çà aussi. En plus il gère la playlist, la bibliothèque de titres, le volume général ET le volume local client, ils est intégralement commandable à distace via TCP, est compatible avec à peu près tout et dernier tout petit détail : il fonctionne.
En plus comme il ne fait que du broadcast de paquets, on peut même faire d el'égalisation et rajouter du délai client par client. (Pour éviter que ca grince quand on passe d'une pièce à l'autre par exemple)
A ma connaissance, plus personne n'utilise les display lists dans le monde du jeu vidéo: tout passe par des VBO. Et, oui, le contenu de ces VBO est géré par le développeur.
Alors soit on ne parle pas de la même chose, soit tu le fais exprès. Que l'on soit en vertex array, en display list, en VBO ou en PBO de toute façon le contenu est géré à la main. Les VBO sont plutôt une fosi de plus une prise de distance vis à vis du GCU par rapport aux vertex array qui devaient être renvoyés au serveur en permanence.
Le GROS avantage des VBO est que le developpeur, une fois qu'il a optimisé ses vertex n'a plus qu'à donner au pilote des indications d'usage du VBO et qu'ensuite la carte graphique se charge de placer et de déplacer la zone mémoire pratiquement sans intervention du dev.
C'est exactement ce à quoi je pensais end isant qu'on a pas vraiment des GC car la problématique est différente, mais qu'on a quand même des systèmes qui y ressemblent furieusement.
Je ne comprends pas pourquoi tu parles de gérer les shaders vertex par vertex, où de réécrire les "fonctions de z-buffer". Quel est le rapport avec la gestion mémoire?
Le rapport est que toutes ces opérations provoquent un bon nombre de transformations en mémoire. Trier les vertexs pour éviter de transformer des segments inutiles, mapper les vertexs dans les buffers pour préparer à l'affichage, rappler les textures et les PBO pour y appliquer les pixels shaders qui vont bien etc. Une trè grosse partie de tout celà est transparente, soit géré par le pilote OpenGL lui même, soit directement en hard par la carte. Sans parler des couches d'anti-aliasing, de décompression de texture et autres culling.
Même si OpenGL offre des méthodes pour toucher à tout celà, une grosse partie du traitement reste souvent en automatique.
Les uniforms buffers permettent surtout d'allouer un bloc de mémoire GPU et de choisir ce que l'on va y stocker, afin d'optimiser le transferts des uniforms entre le CPU et le GPU. Cela en lieu et place d'une allocation transparente gérée par l'API. Donc oui, on est dans plein dans le vif du sujet: passer d'une gestion automatisée à une gestion manuelle.
A l'époque du T&L on était en gestion automatisée. Quand on est passé au shaders (et donc au moment ou il fallait renvoyer les info transformée au serveur) totu se faisait à la mano. Maintenant avec les Uniform Buffer on peut allouer des blocs qui seront raffraichi automatiquement sur des évènements. Il est normal que s'ait été automatique au moment du T&L car on ne transformait pas les polygones/pixels. On avait pas les outils pour. Depuis qu'on les a les cartes graphiques font à chaque géénration un peu plus de choses en automatique.
Si un GC n'est pas capable de garantir que pour une scène de telle complexité son temps d'exécution sera inférieur à une valeur donnée, cela revient à autoriser la dégradation du framerate par un facteur inconnu...
Mais cite moi un outil capable de garantir ce temps d'éxecution ! Un outil capable de dire qu'il aura la priorité kernel, que le swap ne se déclenchera pas, que l'anti virus ne fera pas des siennes, que la température ne forcera pas le CPU/GPU à ralentir, que le pilote ne prendra pas de libertés avec le rendu demandé (NVidia, on t'aime), que l'utilisateur ne forcera pas des options graphiques à la con (ATI, on t'aime aussi), qu'il n'y aura pas de micro corruption des buffer suite à un refresh à la barbare et j'en passe.
En plus un GC moyennant un surcout en mémoire est beaucoup plus à même de garantir un temps d'éxecution qu'une gestion native. Surtout sur des traitements de type DSP.
La véritable gestion mémoire se fait à l'intérieur des buffers alloués par des appels OpenGL; et là c'est le développeur qui y organise ses données, et y accède par un système de pointeur (relatif au début du buffer).
Estc-e que tu connais réellement des développeurs qui réorganisent leurs display lists à la main à chaque frame ? Des dev qui choississent vertex par vertex et pixel par pixel ou appliquer leurs shaders ? Des devellopeurs qui réécrivent toutes les fonctions de Z Buffer et de masking ?
Moi pas (Bon si sur Quake 3 Carmack a recodé toute la fonction de Z buffer mais a) sont algo Z aliase sur les grande distances et b) c'est Carmak)
le système "automatique" que tu décris pour les buffers consiste essentiellement à incrémenter/décrémenter un compteur pour chaque buffer
Non non, le système que je décris et celui qui se met en branle sur chaque buffer et dans chaque display list pour refaire le Z-Sorting, le meshig et autre anti aliasing intra et extra modèle.
par exemple les uniform buffers d'openGL 3.1
Les uniform buffers servent à passer des variables uniform aux shaders sans avoir à se refrapper de relancer des GLUniform dans tous les sens. C'est typiquement un cas ou on laisse le pilote se démerder parceque ca fait chier d'appeler sans arrêt une fonction à la main. J'ai du mal à voir en quoi ca rapproche du GPU.
Il y a des fonctions qui rapprochent du GPU, mais elle sont presque toutes tournées vers le GCGPU. Après il y a des fonctions qui rajoutent plus de finesse sur le controle des shaders, mais là c'est le pilote qui fait le boulot, au niveau du GPU à proprement parler on est ni plus près ni plus loin.
ce serait de pouvoir mettre une borne supérieure sur son temps d'exécution à chaque frame. Est-ce possible sur certains GC?
Ca ne pose aucun problème d'évaluer à priori le temps d'éxecution d'une fonction par un GC (le GC Erlang le fait très bien). Pour pouvoir adapter çà à une carte graphique, il faudrait d'abord qu'il existe une carte graphique qui possède une telle fonction. A ma connaissance il n'y en a aucune sur le marché. Toutes les cartes graphiques mettent plus ou moins de temps à rendre une image en fonction de la complexité de la scène. Comme en plus toutes les cartes graphiques sont différentes, et qu'une même carte graphique va avoir des comportements variant du tout au tout d'un pilote à l'autre, je ne vois pas comment garantir un temps d'éxecution par frame. (En plus l'industrie du benchmark de carte vidéo par les sites en lignes/journaux en serait détruite. Ce serait dommage, c'est tellement drôle)
Je parlais des moteurs de rendus utilisés principalement dans le domaine du jeu vidéo
Bon alors c'est bien ce qu'il me semblait. Juste pour information les API DirectX 7 et plus ainsi que OpenGL (et je ne parle pas des pilotes) utilisent pas mal de techniques très proches du comportement d'un GC. Les problematiques sont différentes mais même si le programmeur du jeu en lui même a l'impression de gérer la mémoire de son appli tout seul comme un grand, derrière le rideau c'est la foirefouille. Les polygones sont tordus, mappés, alloués, transformés et détruits de façon quasiment transparente (et ca tombe bien, parceque gérer quelques millions de polygones à la main un par un c'est lourd).
On ne peut pas vraiment appeler ca un garbage collector mais dans les faits le programmeur utilise une API de haut niveau (en descendant parfois un peu sur certains points) et derrière le système se démmerde tout seul pour gérer les buffers et la mémoire video.
au final, on en revient à tout gérer à la main
Pas du tout. On ne gère pas la mémoire à la main en définissant les pointeurs et les zones mémoires et en les manipulant à la pince à épiler, on donne des instructions au GC pour qu'il se comporte de telle ou telle façon.
De façon générale il y a trois "segments" mémoire gérés par le GC
- Les nouveaux arrivants : ce sont les objets fraichement créé. Si ils viennent d'être créés et que le compilateur byte code ne fait pas n'importe quoi, c'est pas al peine de tester pour savoir si il faut les détruire.
- les objet normaux : ce sont ceux qui sont là depuis un petit moment, mais qui peuvent être déréférencés n'importe quand
- les vétérans : ce sont les objets qui sont en mémoire depuis un long moment et dont on commence à se dire qu'il y a peu de chance qu'ils partent à la poubelle comme çà.
Après on donne des règles au GC
Règle 1 : tous les combiens de temps on déclenche un passage du GC
Règle 2 : au bout de combien de passage du GC un objet neuf passe dans la case "normal"
Règle 3 : au bout de combien de passage du GC un objet normal passe dans la case "vétéran"
Règle 4 : Tout les combiens de passages du GC doit on évaluer les objets de la case "vétéran"
Quatre paramètres + trois pour définir la mémoire initiale, maximale et minimale...
C'est très loin d'une gestion mémoire "à la main"
Seulement je crois que ce n'est pas forcément un outil adapté à toutes les situations.
Les garbages collectors ont étés mis à disposition du public en même temps que windows 95. Et de fait il souffrent ennormément d'une réputation de gaspilleurs de mémoire. Ce qui est vrai, mais qui n'est absolument plus grave aujourd'hui.
A part pour les applications ou l'accès au ressources en direct est primordial (noyeau, temps réel dur, deadlocks trop complexes à gérer en mode processus etc.) le garbage collector va faire un boulot fantastique tout en simplifiant grandement la vie du programmeur au prix de 30% de mémoire occupé en plus.
Bine sur c'est mon opinion, mais vu le chemin que prennent les architectures modernes (plétores de coeurs et mémoire par giga entiers) il va devenir très dur de battre les langages à GC avec les langages traditionnels. Dans des situations de forte charges, le machines virtuelles atteignent déjà les perfs des applications compilées en natif. Erlang par exemple est à peu près imbattable en terme du nombre de connexions par seconde qu'il peut accepter et traiter...
On alloue tout en bloc et on réutilise les mêmes zones de mémoires autant que possible. C'est en partie faisable avec un GC, mais en partie seulement,
Euh... En ce qui concerne Java, Erlang ou .Net il y a moyen très facilement de préciser la mémoire initiale, la mémoire minimum et la mémoire maximum utilisée. Si les trois paramêtres sont identiques on exactement un comportement d'allocation bloc sans pour autant avoir besoin de réinventer la roue. En java on peut même au démarrage d'une appli définir quasiment à la virgule prèt le comportement des générations et de l'eden, et donc avoir une application qui ne va allouer de la mémoire que quand il va vraiment y en avoir besoin, et libérer la mémoire que quand vraiment ca ne sert plus à rien.
Ca se fait en une petite ligne de paramètres, et comble du comble ca se fait après que le programme ait été compilé, et donc un non progammeur peut corriger ces paramêtres au cas par cas en fonction de l'usage qui est fait du programme.
Je ne dit pas que c'est impossible, mais actuellement je n'ai connaissance d'aucun moteurs de rendus,
En moteur de rendu temps réel, il y a trois domaines à ma connaissance
- l'imagerie médicale
- l'analyse electronique des structures
- le maquettage démo des grosses sociétés industrielles.
Dans ces trois cas il s'agit de matériels spécifiques, le plus souvent basés sur des clusters de processeurs vectoriels ou sur des batteries de DSP. Le fait qu'ils soient proches du hardware s'explique assez simplement par la relation un outil => un usage. Pas la peine de se casser les pieds à coder un garbage collector et de l'enrober dans un langage de programation alors qu'au final de toute façon il n'y aure jamais qu'une seule application qui tournera sur la machine. On fait du spécifique. La question ne se pose pas vraiment....
[^] # Re: La FSF fait son boulot !
Posté par Jerome Herman . En réponse au journal Le système que j'utilise est-il libre ?. Évalué à 3.
Les données statistiques sur les études psycho-accoustiques
a) Ne sont pas un logiciel
b) sont protégées par Fraunhofer (standard) ou Thomson (MP3 ISO) au titre du droit d'auteur (comme souvent pour les études et les statistiques)
c) Sont nécessaires à la compression ou à la décompression de tout contenu Mpeg-Layer3
De même, la partie sur les exportations rends peut être la copie illégale dans certains pays vers d'autres pays, mais ça ne veut pas dire non libre. Sinon, y a plein de soft qui sont illégaux parce que l'allemagne les interdit ( genre les softs de secu ).
En ce qui concerne l'implémentation de base du système Kerberos, tu n'as pas le droit de la faire sortir des US. Donc si tu l'installes sur un poste qui n'est pas aux US, ou qui est ammené à sortir des US, le gouvernement Américain a le droit de demander ton extradition pour te poursuivre sur le sol américain suivant la loi des US.
On va dire que ca compte comme "distribution/reproduction pas libre"
La probléme des noms de marques est différent des problèmes de restrictions sur les 4 libertés. Jamais il n'a été dit qu'un soft libre implique de pouvoir garder le nom original, même si il y a des problémes pratiques à ce genre de choses.
Il y a, par exemple, une pléthore de versions d'Emacs qui ne sont pas officiellement sanctionnée par RMS lui même. Ca ne veut pas dire que RMS va toutes les attaquer demain, mais ca veut dire qu'elles sont dans l'illégalité vis à vis des lois sur le copyright. De fait les distribuer constitue un délit de contrefaçon. Donc distribution non libre.
Idem le kernel de gNewSense avait été amputé de pas mal de fonctionnalités (notamment les wrappers et GLX). Je doute fortement que celà ait été cautionné officiellement par Linus Torvalds...
Enfin les drivers obsfusqués dont tu parles, c'est sur nvidia
Non, non c'est sur Intel. Notamment les puces graphiques GMA dont le code est cryptique à plusieurs endroit pour éviter les ennuis avec certains brevets sur la 3D et les puces Wifi, dont les pilotes sont écrits pour rendre complexe l'utilisation des ondes en dehors des normes américaines.
Et commencer à glisser des considérations de facilité de lecture dans une définition de la liberté, c'est la porte ouverte aux discussions sans fin et au troll infini.
Quand la boite elle même dit "vous aurez pas les specs et le code sera en hexa brut pour pas que vous puissiez contourner" c'est pas une considération, c'est un fait.
De plus, la fsf reconnait que la license d'apache 2 est libre et compatible avec la GPL v3
cf http://www.fsf.org/licensing/essays/apsl.html :
# It is not a true copyleft, because it allows linking with other files which may be entirely proprietary.
It is incompatible with the GPL.
cf http://www.apache.org/licenses/LICENSE-2.0.html
4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
1. You must give any other recipients of the Work or Derivative Works a copy of this License; and
2. You must cause any modified files to carry prominent notices stating that You changed the files; and
3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
4. If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
Après la FSF peut dire que c'est libre suivant sa définition à elle... Mais honnêtement faut le dire vite.
Donc je trouve que la dispute en question a permis à beaucoup de personnes ayant des conceptions encore plus approximatives que les miennes de donner un avis que j'estime erroné, juste pour contredire RMS. Bien sur, c'est pas du tout le caractére de certaines personnes, c'est un hasard.
Je pense juste que tes conceptions aproximatives, sont un peu plus approximatives que tu ne le penses.
[^] # Re: La FSF fait son boulot !
Posté par Jerome Herman . En réponse au journal Le système que j'utilise est-il libre ?. Évalué à 2.
La question n'est pas là. La question est :
"Est-ce que tu peux faire un fork d'OpenBSD et appeler ce fork OpenBSD" : Réponse OUI
"Est-ce que tu peux faire un fork de Linux (ou Apache) et appeler ce fork Linux" : Réponse NON
Par fork j'entends démarrer un projet complet qui n'aurais pas pour vocation de rejoindre le tronc principal, mais de créer un tronc totalement distinct.
Si on ne fait des distros qu'avec ce qui est dans le domaine public, on ne fera même pas une calculatrice.
Entièrement d'accord. C'est d'ailleurs pour celà qu'il n'existe AUCUNE distribution complètement libre. Même pas au sens de la FSF... D'ou le qualificatif "hypocrite".
[^] # Re: La FSF fait son boulot !
Posté par Jerome Herman . En réponse au journal Le système que j'utilise est-il libre ?. Évalué à 10.
Au moins avec la liste que dresse la FSF, on sait où on met ses pieds.
On va juste dire que les critères de la FSF en matière de 100% libres sont étrangement élastiques.
Lors de l'incartade entre RMS et de Raadt il y a eu plusieurs remarques qui ont été assez sanglantes contre les distribs 100% :
Certaines incluaient le support de la lecture MP3 (corrigé depuis)
Certaines incluent des éléments non libres à l'exportation US comme le Kerberos (contre argument : c'est pas grave il y a Heidmal qui fait la même chose chez ceux qui sont pas aux US)
Certaines incluent le support fat, y compris avec les noms long (Position officielle de gnewsense par exemple : on ne reconnait pas les brevets logiciels, donc on ne retire pas exprès des fonctionnalités à cause des brevets)
Toutes incluent des noms copyrightés (Linux, Emacs, Apache etc.)
Certains pilotes libres sont volontairement illisibles (obsfucated) et masquent des fonctionnalités du hard (pilotes intel notamment)
Quasiment toutes les distribs incluent apache2 (dont la licence est pas vraiment libre même pour un gpliste)
etc.
Donc quand la FSF déclare que certaines distribs sont 100% libres, elle est hypocrite. C'est le point de vue de Theo de Raadt, et c'est aussi le mien.
[^] # Re: pas sur
Posté par Jerome Herman . En réponse au journal Le système que j'utilise est-il libre ?. Évalué à 6.
On enlève aussi les produits des distribs qui se veulent 100% libres ?
[^] # Re: Coup de pub...
Posté par Jerome Herman . En réponse au journal Microsoft : Essaye encore petit scarabée !. Évalué à 8.
La c'est vrai. Ca va avoir un impact au moins aussi grand que quand ATI avait annoncé que les prochaines cartes radeon serait livrées avec un pilote Linux complet.
Ca va saigner.
[^] # Re: Un peu précipité, non ?
Posté par Jerome Herman . En réponse à la dépêche Processeur graphique : NVIDIA est mal parti pour les années à venir. Évalué à 8.
Quand un regsitre déborde, c'est un peu au petit bonheur la chance (parfois une erreur, parfois une rotation du registre sans rotation de carry (bien entendu, il y en a pas), parfois 2^x +1 = 2^x). Les arrondis dépendent du sens du vent et les trap à erreur genre "not a number" et "division by zero" sont variables d'une carte à l'autre.
En bref pour faire du GPGCU il faut quand même avoir une bonne maitrise de ses éléments de départ sinon c'est un poil le mur.
[^] # Re: hu ?
Posté par Jerome Herman . En réponse au journal Le WPA en déroute(ur). Évalué à 4.
Définition presque parfaite, un algorithme est une méthode systématique pour passer d'un etat A à un etat B.
Systématique est utilisé ici dans les deux acceptions du terme :
a) reproductible
b) qui marche à chaque fois
Si ca ne marche pas à tous les coups, c'est juste une méthode.
# Il y a pas dump ?
Posté par Jerome Herman . En réponse au sondage Je réalise mes sauvegardes avec. Évalué à 5.
Bon ca prend du temps et d la place, mais dump ca permet d'avoir une sauvgarde sure dans un coin (pan !) entre deux rsync.
[^] # Re: titre catastrophiste
Posté par Jerome Herman . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 2.
C'est toute la notion blob + binaire qu'il faut prendre en compte.
Il n'y a aucun problème à lier un module binaire qui ne soit pas un blob (ie qui ne soit pas une boite noire, c'est à dire un module dont on a les specs )
Il y a pas trop de problèmes (encore que) à compiler un blob source et à le lier (c'est à dire que le code est pas commenté, voire volontairement complexifié)
Par contre il y a un gros problème à lier un truc qui soit les deux. Parceque comme on a pas les specs on peut pas en faire un autre, et comme on a pas les sources on peut pas le commiter dans une branche délocalisée du noyal pour valider que ca compile toujours, ne fait pas de warnings etc.
[^] # Re: moi c'est le contraire
Posté par Jerome Herman . En réponse au journal Expérience d'un musicien qui abandonne le Mac pour Linux. Évalué à 7.
Alors ca faut le dire super vite.
Quelques exemples :
- Sous Vista patché les Geforce 7xxx mobility sont très très mal supportée (plantages, affichage corrompu, freeze etc.) Nividia ne sort pour ainsi dire plus de pilotes pour cette série. Les mecs qui ont achetés des Qosimo Toshiba il y a un an à 18 mois sont ravis.
- Sous windows de façon général le matériel sonore est géré de façon un poil accrobatique. Notament quand on a plusieurs périphériques son. Et je fais grace des fois ou un débranchement rebranchement d'un périphérique d'aquisition (comme un enregistreur mobile) provoque la redétection d'un nouveau matériel avec installation de pilotes supplémentaires et demande de reboot. En poste nomade, Windows pour la prise de son et le mixage il vaut mieux oublier.
- Plus récemment j'ai vu un système de prise de son entier être reconnu par XP comme un disque fixe. Pas moyen de l'ejecter. Obliger d'éteindre proprement l'ordinateur entre chaque prise de son pour être sur que le mixage soit sauvegardé.
Je t'accord que sous Linux le son est très complexe à mettre en place, surtout sur du matériel pro (le plus dur restant quand même de claquer définitvement la gueule à pulseaudio pour ne pas qu'il se remette en place à la prochaine mise à jour). Mais JACK + OSS4 ou même JACK + ALSA est très loin devant tout ce qui se fait sous Mac ou Windows en terme de qualité ou de fiabilité.
[^] # Re: Ø PS3 system software update version 3.00
Posté par Jerome Herman . En réponse à la dépêche Pas de prise en charge de Linux dans la nouvelle PlayStation 3 Slim. Évalué à 4.
Ben ca avait deux avantages principaux :
a) faire une console qui coute moins cher et donc qu'on a plus de chance de rentabiliser au final.
b) faire une console qui plante moins. Parceque les premiers batch de PS3 ont quand même eu pas mal d'emmerdes.
Je te rassure tout de suite, l'immense majorité composants utilisés dans les consoles, ce ne sont pas des composants fabriqué "sur mesure" en très petite série hein. Quant à "l'alimentation" les grands principes sont connue et archi connu. Pas comme si ils réinventait la poudre non plus.
Le principal problème lors d'un design de carte mère, ce sont les putains d'effets parasites. Deux fils se suivent sur plus de quelques milimmètres : condo parasite. un fil fait le tour de la plaque pour economiser un layer : hop bobine parasite. Un condensateur est au taquet de sa marge d'erreur : hop résonnance radio avec d'autres composants. etc.
Et pour l'alimentation, même si les grands principes sont connus, c'est pas forcément évident d'avoir de bonnes bobines quand tu les fait fabriquer spécifiquement pour toi car ton alim doit tenir dans un mouchoir de poche. Un bon transfo à découpage dans une intensité/tension non standard coute une fortune.
Clair... surtout quand des labos achètent des ps3 par rack entier car c'est une plateforme de dvp du cell pas cher, et on peut faire de beau truc avec.
Clairement ils ont du vendre à tout casser 2000 consoles à des labos qui les transforment en serveur grid. C'est avec ca qu'ils vont amortir leur R&D...
[^] # Re: Ø PS3 system software update version 3.00
Posté par Jerome Herman . En réponse à la dépêche Pas de prise en charge de Linux dans la nouvelle PlayStation 3 Slim. Évalué à 3.
Oui de la carte mère, de tous les processus de fabrication qui vont avec, des problèmes alimentation, de design des bus externes, de controlleurs etc.
Pour la PS3 il y a eu 18 versions de la carte mère avant la sortie définitive (je ne parle que des préséries là, pas des prototypes). Et ca a juste couté son poste au grand manitou console de chez Sony. Depuis la sortie de la version commerciale il y a eu 9 évolutions de la carte mère, avec des modifications significatives : Le hard PS2 a giclé, les principaux controlleurs ont été changés, l'alim a été redessinée etc. Avec à chaque fois des lignes logisitiques à remettre en place et des usines à reconfigurer. Plus bien sur les tests qui vont bien etc.
tu trouves mêmes des cm à 30€ prix ttc, qui certes sont amortis sur le grande fabrication
Les cartes mères à 30€ sont le plus souvent des reference design constructeur (via, amd, intel ou nvidia) avec très peu d'autres modifications que de tirer un bus PCI sur la carte pour alimenter une carte son. On est très loin de la conception d'une carte mère, c'est purement de la fabrication. Et qui plus est de la fabrication sur du matériel hyper connu et répandu, avec des alims standards. Bref on est très loin de la carte mère mono machine, mono usage pour laquelle le fabriquant paye le design au prix fort.
et c'est là où intervient l'achat de jeux, la vente de licence de dvp, la conception de produits à bases de cell
Alors pour la conception de produits à base de cell, Sony ne touche rien. Et pour le reste si la console sert à faire tourner des applications devellopées sur un autre OS, Sony ne touche rien non plus. En bref l'option "other OS" a un impact ecconomique négatif pour Sony.
[^] # Re: Ø PS3 system software update version 3.00
Posté par Jerome Herman . En réponse à la dépêche Pas de prise en charge de Linux dans la nouvelle PlayStation 3 Slim. Évalué à 4.
De plus IBM et Toshiba se "rattrapent pas" sur les jeux eux.
Quant à la puce graphique, elle a été achetée, donc difficile quand même a "cacher".
Tu réalises, bien sur, que même quand tu as un processeur et une puce graphique stables et testés massivement (ce qui n'a pas été le cas pour la PS3) tu en as encore pour plusieurs années hommes de boulot avant de sortir une console de jeu qui fonctionne.
Ca fait partie des "couts de developpement" d'un produit, et n'impacte pas le fait que la console en elle même n'est pas vendue à perte (que la somme des matières premières utilisée pour la construction de la console ne coute pas plus que le prix à laquelle elle est payée).
Légalement elle n'est pas vendue à perte. Comptablement Sony perd de l'argent sur chaque console vendue (de moins en moins, mais encore un peu)
[^] # Re: Ø PS3 system software update version 3.00
Posté par Jerome Herman . En réponse à la dépêche Pas de prise en charge de Linux dans la nouvelle PlayStation 3 Slim. Évalué à 2.
Les PS3 sont vendues à perte (avec des jeux comptables pour étaler maintenance des firmwares , usines et R&D sur des années pour donner l'impression que c'est vendu à prix coutant).
Sony se fait du pognon sur les jeux.
En plus les os autres sont une bonne porte d'entrée pour qui veut jouer des jeux piratés/casser les codes blue-ray/tricher en ligne etc.
[^] # Re: 2 millions d'euros ? D'ici le 4 Septembre ?
Posté par Jerome Herman . En réponse à la dépêche Save Nabaztag : un lapin libre ?. Évalué à 7.
De toute façon, comme il s'agit ici de "racheter" la société et pas seulement de reprendre des actifs d'une société qui ferme proprement (comem ce fut le cas avec Blender par exemple) tout se complique.
Pour faire appel à l'épargne populaire (ie demander du pognon en échange d'action à des gens qu'on ne connait pas) il faut être coté sur un des marchés qui existe. Pour être coté sur un marché en France il faut être
a) ne pas être en cessation de paiement
b) ne pas être en redressement, liquidation, protection judiciaire
c) être à jour fiscalement (surtout en ce qui concerne la TVA et l'URSSAF)
d) bien sur ne pas être interdit bancaire.
Plus tout un tas d'autres trucs mais je ne crois pas me tromper en disant que les quatres premières conditions ne risquent pas d'être remplie de si tôt.
La seule chose qui soit possible à plusieurs, c'est de laisser la société mourrir et de la racheter en liquidation. Au moins comme çà on se débarasse du passif et des employés et on garde les technos. Bon ca va juste poser un petit problème pour présenter un dossier qui plaise au juge et un chèque total qui devra bien être signé par quelqu'un...(Ceci étant, je doute que ca se presse au portillon pour reprndre la société, donc le juge risque de prendre à peu près n'importe quel chèque de plus de 30 000€ pour les caisses de l'Etat)
Après avant de retrouver des fournisseurs qui vont accepter de retravailler avec la société ca va être drole. Particulièrement les mecs qui ont les moules à injecter pour faire la coque...
[^] # Re: SFR et Android
Posté par Jerome Herman . En réponse au journal Orange et Android. Évalué à 7.
Sur un forfait pro (et vlan mange toi 80€ de tel par mois) :
IMAPS : OK
SMTPS : OK
SSH : OK
ports 5900-5920 (VNC) : OK
Je pense que les autres fonctionnent aussi.(pas testé)
[^] # Re: 1932.97 € ...
Posté par Jerome Herman . En réponse au message Offre d'emploi - développement de plugins pour OCS/GLPI (PHP/MySQL). Évalué à 3.
Et non, les militaires sous contrats et certains autres fonctionnaires ne peuvent même pas pleurer aux prud'hommes...
A noter cependant qu'il s'agit de contrats fermes, donc sans période d'essai.
# C'est un problème connu
Posté par Jerome Herman . En réponse au journal changement de coordonnées qui signifie perte de tout service pour l'éternité chez dedibox. Évalué à 2.
Dans la pratique heureusement ca se produit peu.
# Je veux pas être méchant..
Posté par Jerome Herman . En réponse au journal SquirrelMail compromis...one more time !. Évalué à 7.
A l'heure actuelle, si j'étais un utilisateur SquirrelMail, c'est pas du tout ce que je ferais.
[^] # Re: C'est pas tout
Posté par Jerome Herman . En réponse au journal [:mmmfff]. Évalué à 5.
Base de la philosophie Unix : faire une seule chose, mais la faire bien.
[^] # Re: C'est pas tout
Posté par Jerome Herman . En réponse au journal [:mmmfff]. Évalué à 3.
Music Player Daemon fait çà aussi. En plus il gère la playlist, la bibliothèque de titres, le volume général ET le volume local client, ils est intégralement commandable à distace via TCP, est compatible avec à peu près tout et dernier tout petit détail : il fonctionne.
En plus comme il ne fait que du broadcast de paquets, on peut même faire d el'égalisation et rajouter du délai client par client. (Pour éviter que ca grince quand on passe d'une pièce à l'autre par exemple)
[^] # Re: Fausse idée sur les garbages collectors
Posté par Jerome Herman . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 3.
Alors soit on ne parle pas de la même chose, soit tu le fais exprès. Que l'on soit en vertex array, en display list, en VBO ou en PBO de toute façon le contenu est géré à la main. Les VBO sont plutôt une fosi de plus une prise de distance vis à vis du GCU par rapport aux vertex array qui devaient être renvoyés au serveur en permanence.
Le GROS avantage des VBO est que le developpeur, une fois qu'il a optimisé ses vertex n'a plus qu'à donner au pilote des indications d'usage du VBO et qu'ensuite la carte graphique se charge de placer et de déplacer la zone mémoire pratiquement sans intervention du dev.
C'est exactement ce à quoi je pensais end isant qu'on a pas vraiment des GC car la problématique est différente, mais qu'on a quand même des systèmes qui y ressemblent furieusement.
Je ne comprends pas pourquoi tu parles de gérer les shaders vertex par vertex, où de réécrire les "fonctions de z-buffer". Quel est le rapport avec la gestion mémoire?
Le rapport est que toutes ces opérations provoquent un bon nombre de transformations en mémoire. Trier les vertexs pour éviter de transformer des segments inutiles, mapper les vertexs dans les buffers pour préparer à l'affichage, rappler les textures et les PBO pour y appliquer les pixels shaders qui vont bien etc. Une trè grosse partie de tout celà est transparente, soit géré par le pilote OpenGL lui même, soit directement en hard par la carte. Sans parler des couches d'anti-aliasing, de décompression de texture et autres culling.
Même si OpenGL offre des méthodes pour toucher à tout celà, une grosse partie du traitement reste souvent en automatique.
Les uniforms buffers permettent surtout d'allouer un bloc de mémoire GPU et de choisir ce que l'on va y stocker, afin d'optimiser le transferts des uniforms entre le CPU et le GPU. Cela en lieu et place d'une allocation transparente gérée par l'API. Donc oui, on est dans plein dans le vif du sujet: passer d'une gestion automatisée à une gestion manuelle.
A l'époque du T&L on était en gestion automatisée. Quand on est passé au shaders (et donc au moment ou il fallait renvoyer les info transformée au serveur) totu se faisait à la mano. Maintenant avec les Uniform Buffer on peut allouer des blocs qui seront raffraichi automatiquement sur des évènements. Il est normal que s'ait été automatique au moment du T&L car on ne transformait pas les polygones/pixels. On avait pas les outils pour. Depuis qu'on les a les cartes graphiques font à chaque géénration un peu plus de choses en automatique.
Si un GC n'est pas capable de garantir que pour une scène de telle complexité son temps d'exécution sera inférieur à une valeur donnée, cela revient à autoriser la dégradation du framerate par un facteur inconnu...
Mais cite moi un outil capable de garantir ce temps d'éxecution ! Un outil capable de dire qu'il aura la priorité kernel, que le swap ne se déclenchera pas, que l'anti virus ne fera pas des siennes, que la température ne forcera pas le CPU/GPU à ralentir, que le pilote ne prendra pas de libertés avec le rendu demandé (NVidia, on t'aime), que l'utilisateur ne forcera pas des options graphiques à la con (ATI, on t'aime aussi), qu'il n'y aura pas de micro corruption des buffer suite à un refresh à la barbare et j'en passe.
En plus un GC moyennant un surcout en mémoire est beaucoup plus à même de garantir un temps d'éxecution qu'une gestion native. Surtout sur des traitements de type DSP.
[^] # Re: Fausse idée sur les garbages collectors
Posté par Jerome Herman . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 2.
Estc-e que tu connais réellement des développeurs qui réorganisent leurs display lists à la main à chaque frame ? Des dev qui choississent vertex par vertex et pixel par pixel ou appliquer leurs shaders ? Des devellopeurs qui réécrivent toutes les fonctions de Z Buffer et de masking ?
Moi pas (Bon si sur Quake 3 Carmack a recodé toute la fonction de Z buffer mais a) sont algo Z aliase sur les grande distances et b) c'est Carmak)
le système "automatique" que tu décris pour les buffers consiste essentiellement à incrémenter/décrémenter un compteur pour chaque buffer
Non non, le système que je décris et celui qui se met en branle sur chaque buffer et dans chaque display list pour refaire le Z-Sorting, le meshig et autre anti aliasing intra et extra modèle.
par exemple les uniform buffers d'openGL 3.1
Les uniform buffers servent à passer des variables uniform aux shaders sans avoir à se refrapper de relancer des GLUniform dans tous les sens. C'est typiquement un cas ou on laisse le pilote se démerder parceque ca fait chier d'appeler sans arrêt une fonction à la main. J'ai du mal à voir en quoi ca rapproche du GPU.
Il y a des fonctions qui rapprochent du GPU, mais elle sont presque toutes tournées vers le GCGPU. Après il y a des fonctions qui rajoutent plus de finesse sur le controle des shaders, mais là c'est le pilote qui fait le boulot, au niveau du GPU à proprement parler on est ni plus près ni plus loin.
ce serait de pouvoir mettre une borne supérieure sur son temps d'exécution à chaque frame. Est-ce possible sur certains GC?
Ca ne pose aucun problème d'évaluer à priori le temps d'éxecution d'une fonction par un GC (le GC Erlang le fait très bien). Pour pouvoir adapter çà à une carte graphique, il faudrait d'abord qu'il existe une carte graphique qui possède une telle fonction. A ma connaissance il n'y en a aucune sur le marché. Toutes les cartes graphiques mettent plus ou moins de temps à rendre une image en fonction de la complexité de la scène. Comme en plus toutes les cartes graphiques sont différentes, et qu'une même carte graphique va avoir des comportements variant du tout au tout d'un pilote à l'autre, je ne vois pas comment garantir un temps d'éxecution par frame. (En plus l'industrie du benchmark de carte vidéo par les sites en lignes/journaux en serait détruite. Ce serait dommage, c'est tellement drôle)
[^] # Re: Fausse idée sur les garbages collectors
Posté par Jerome Herman . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 2.
Bon alors c'est bien ce qu'il me semblait. Juste pour information les API DirectX 7 et plus ainsi que OpenGL (et je ne parle pas des pilotes) utilisent pas mal de techniques très proches du comportement d'un GC. Les problematiques sont différentes mais même si le programmeur du jeu en lui même a l'impression de gérer la mémoire de son appli tout seul comme un grand, derrière le rideau c'est la foirefouille. Les polygones sont tordus, mappés, alloués, transformés et détruits de façon quasiment transparente (et ca tombe bien, parceque gérer quelques millions de polygones à la main un par un c'est lourd).
On ne peut pas vraiment appeler ca un garbage collector mais dans les faits le programmeur utilise une API de haut niveau (en descendant parfois un peu sur certains points) et derrière le système se démmerde tout seul pour gérer les buffers et la mémoire video.
au final, on en revient à tout gérer à la main
Pas du tout. On ne gère pas la mémoire à la main en définissant les pointeurs et les zones mémoires et en les manipulant à la pince à épiler, on donne des instructions au GC pour qu'il se comporte de telle ou telle façon.
De façon générale il y a trois "segments" mémoire gérés par le GC
- Les nouveaux arrivants : ce sont les objets fraichement créé. Si ils viennent d'être créés et que le compilateur byte code ne fait pas n'importe quoi, c'est pas al peine de tester pour savoir si il faut les détruire.
- les objet normaux : ce sont ceux qui sont là depuis un petit moment, mais qui peuvent être déréférencés n'importe quand
- les vétérans : ce sont les objets qui sont en mémoire depuis un long moment et dont on commence à se dire qu'il y a peu de chance qu'ils partent à la poubelle comme çà.
Après on donne des règles au GC
Règle 1 : tous les combiens de temps on déclenche un passage du GC
Règle 2 : au bout de combien de passage du GC un objet neuf passe dans la case "normal"
Règle 3 : au bout de combien de passage du GC un objet normal passe dans la case "vétéran"
Règle 4 : Tout les combiens de passages du GC doit on évaluer les objets de la case "vétéran"
Quatre paramètres + trois pour définir la mémoire initiale, maximale et minimale...
C'est très loin d'une gestion mémoire "à la main"
Seulement je crois que ce n'est pas forcément un outil adapté à toutes les situations.
Les garbages collectors ont étés mis à disposition du public en même temps que windows 95. Et de fait il souffrent ennormément d'une réputation de gaspilleurs de mémoire. Ce qui est vrai, mais qui n'est absolument plus grave aujourd'hui.
A part pour les applications ou l'accès au ressources en direct est primordial (noyeau, temps réel dur, deadlocks trop complexes à gérer en mode processus etc.) le garbage collector va faire un boulot fantastique tout en simplifiant grandement la vie du programmeur au prix de 30% de mémoire occupé en plus.
Bine sur c'est mon opinion, mais vu le chemin que prennent les architectures modernes (plétores de coeurs et mémoire par giga entiers) il va devenir très dur de battre les langages à GC avec les langages traditionnels. Dans des situations de forte charges, le machines virtuelles atteignent déjà les perfs des applications compilées en natif. Erlang par exemple est à peu près imbattable en terme du nombre de connexions par seconde qu'il peut accepter et traiter...
[^] # Re: Fausse idée sur les garbages collectors
Posté par Jerome Herman . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 2.
Euh... En ce qui concerne Java, Erlang ou .Net il y a moyen très facilement de préciser la mémoire initiale, la mémoire minimum et la mémoire maximum utilisée. Si les trois paramêtres sont identiques on exactement un comportement d'allocation bloc sans pour autant avoir besoin de réinventer la roue. En java on peut même au démarrage d'une appli définir quasiment à la virgule prèt le comportement des générations et de l'eden, et donc avoir une application qui ne va allouer de la mémoire que quand il va vraiment y en avoir besoin, et libérer la mémoire que quand vraiment ca ne sert plus à rien.
Ca se fait en une petite ligne de paramètres, et comble du comble ca se fait après que le programme ait été compilé, et donc un non progammeur peut corriger ces paramêtres au cas par cas en fonction de l'usage qui est fait du programme.
Je ne dit pas que c'est impossible, mais actuellement je n'ai connaissance d'aucun moteurs de rendus,
En moteur de rendu temps réel, il y a trois domaines à ma connaissance
- l'imagerie médicale
- l'analyse electronique des structures
- le maquettage démo des grosses sociétés industrielles.
Dans ces trois cas il s'agit de matériels spécifiques, le plus souvent basés sur des clusters de processeurs vectoriels ou sur des batteries de DSP. Le fait qu'ils soient proches du hardware s'explique assez simplement par la relation un outil => un usage. Pas la peine de se casser les pieds à coder un garbage collector et de l'enrober dans un langage de programation alors qu'au final de toute façon il n'y aure jamais qu'une seule application qui tournera sur la machine. On fait du spécifique. La question ne se pose pas vraiment....