Je ne connais pas un parti en France (FN, LR, PS) qui soit un vrai lieu de discussions. Les chef(s) et/ou bureau national y décide(nt) de presque tout, le fonctionnement des partis en réduit ses adhérents en une armée de zombies. Ce n'est pas des organisations qui font vivre la démocratie.
J'ai la folie de pensé qu'une assemblé tirée au sort n'aurait pas votée les lois sur le renseignement, les budgets inique qui sabre santé, éducation et justice. Bref j'ai la naïveté de penser que oui un système par tirage au sort donnerai un meilleur résultat. Je ne fais que le constat que le système actuel n'aboutit qu'a des résultats désastreux et par conséquent il est indéfendable à mes yeux.
Oui la révocation des élus serait un pas dans la bonne direction mais cela ne serait être suffisant pour expier ses fautes. Les détails techniques sont toujours important et dans notre système électifs il faudrait en changer beaucoup (vote a 1 tour par classement avec candidat blanc, proportionnel, révocabilité, …).
Je sais c'est vendredi, mais je ne peux m'empêcher d'être étonné de voir des gens pinailler sur le tirage au sort. L'un lui reproche de ne pouvoir représenter ceux qui refuseraient, les indépendants ou bien encore patrons de petite structure. Soit, mais dans le système actuel ces même personnes ne sont pas mieux représenté (la preuve par l'absurde est évidente). Le tirage au sort n'est donc pas pire sur ce point.
L'autre évoque le risque de tirer une assemblé ou un courant de pensé, minoritaire dans la population, serait majoritairement représenté. Si l'objection que cela est statistiquement improbable ne convainc pas, alors encore une fois soulignons que ce genre de situation est encore plus probable dans un système électif (simplement de part l'abstention).
J'espère qu'il est évident que le tirage au sort permettrait une bien meilleurs représentation des salariés, qui malgré qu'ils soient plus important en nombre que les indépendants ou patrons, sont aujourd'hui moins représenté que ces derniers. Il est évident que cela serait valable pour la majorité des catégories sociaux professionnelle.
Un dernier évoque la peur de l'incertitude quand à l'orientation de l'assemblée résultante. Je trouve l'état actuel des choses plus pré-occupant, car j'ai la certitude, conforté par l'expérience acquises, que le système actuel s'oriente rarement avec l'intérêt du plus grand nombres.
De plus, pour moi, la représentativité n'est pas l'argument ultime du tirage au sort. Il en est une propriété importante, et tous les cas particulier ne serait lui enlever cet aspect. Non, sa première qualité à mes yeux c'est qu'il est le boureau des partis politiques, la fin de ces organismes parasitique des démocraties.
Il est probablement important que je souligne certains aspect technique. Les tirés au sort doivent bénéficier d'une indemnité conséquente (disons 5000 ou 10000 euros/mois) le temps de leur mandat et une retraite garantie (disons la moitié de l'indemnité). L'assemblée doit être renouvelé en continue (23 nouveaux tiré par mois par exemple) afin d'éviter les temps morts en ayant en continue suffisamment de personnes expérimenté. L'on doit pouvoir révoquer un tiré au sort (par pétition ou par vote de l'assemblée). Les votes de l'assemblée doivent être publique, sans exception. Les lois voté doivent pouvoir être abrogé par pétition… Il y aurait encore bien d'autres détails à considérer avec attention (corruption, conflit d'intérêt, …), mais bien moins que ce que le système actuel demanderait.
Pour moi les 3 grandes puissances sont à part (Chine, Russie, Etats-Unis). Et il est impossible de ne pas avoir de relation avec elles. Alors oui tout le monde parle avec Vlad, mais aussi avec Xi Jingping ou Obama. Il faut être hypocrite pour refuser de parler et faire des affaires avec Vlad tout en continuant à en faire avec Xi Jingping ou même Obama. Les 3 occupent actuellement des territoires qu'ils ont envahit en infraction avec les principes internationaux.
Alors non ça ne me choque pas de voir des gens parler avec la Russie, les petits doivent jouer les gros les uns contre les autres.
Le problème c'est à qui vendre. Le gouvernement de Tsipras a l'air d'avoir certaine valeurs, donc vendre à des terroristes ou des dictatures c'est probablement pas près d'arriver. Je doute qu'un autre pays d'Europe soit intéresser pour racheter des équipements d'occasion.
Après il y a aussi le classique des dépenses militaire ou tu engloutis de l'argent sans jamais recevoir le produit final. Par exemples les sous-marins acheté aux Allemands, qui ont été payé en partie mais jamais livré :
Il y a une histoire similaire me semble t-il avec des chars Français, ou des hélicoptères (enfin j'oublie ce que c'était). Mais oui je suis d'accord il faudrait qu'il vende tous ces trucs inutiles (sous marins, missiles, chars) mais je comprends aussi qu'il ne veuille pas vendre à n'importe qui.
Vendre un stade olympique ? Pas facile, sur ebay peut être :) Même les équipement militaire c'est pas simple à vendre sans compter qu'une bonne partie de l'argent est simplement partie en frai de fonctionnement (essence, entretient, …).
J'aimerai avoir accès au rapport d'audit de leur dette en anglais mais pour le moment je ne trouve que des résumés. Donc d'après ce rapport beaucoup d'argent est partie en fumé. Taux d'intérêt particulièrement élevée, perte de revenue fiscaux suite à la fuite de capitale, maintient des dépenses publiques malgré cela, sauvetage des banques Grecques qui avait des bilans désastreux (montagne de dettes), ici encore socialisation des pertes privés par l'état. Enfin bon, aujourd'hui je doute qu'il puisse récupérer beaucoup en revendant ce qu'il leur reste de ces années faste. Peut être 1 milliards ou 2, mais certainement pas beaucoup plus, j'imagine qu'il regarde ça.
Faut se renseigner un peu, l'Europe n'a pas prêter 300 milliards à la Grèce, l'europe à racheter pour presque 300 milliards de dette privé. L'europe a socialisé les dettes de le Grèce qui était au paravant détenue par des banques privés.
Seulement les gouvernements européens ne pouvaient pas dire ouvertement qu'ils socialisaient les pertes des banques privés alors ils font passer ca pour un prêt à la Gréce, et on laisse les gens imaginer que les Grecques ont dépensé ces 300milliards pour boire de l'ouzo sur la plage. Je souligne au passage que les créancier privés on étaient irresponsable de prêter ainsi et que c'est eux qui devrait faire face aux conséquences de leur incompétences.
Je conseille de plus de se renseigner sur comment la Grèce à pu autant s'endetter, et la encore ce n'est pas ce que les grands médias disent. Le coûts des fonctionnaires en comparaisons du PIB est moins important en Grèce qu'en Allemagne ou France ou que la plus part des autres pays européens.
Mais celle-ci on drastiquement baissé depuis le début de la crise.
Je ne dis pas que le peuple Grecque n'est pas responsable de sa dette mais une grande partie est illégitime est n'a servis qu'à enrichir des intérêts privés qui ont canibalisé un état faible qui avait déjà du mal à lever des impôts. Et que ceux qui devrait payer aujourd'hui ceux sont les banques privés qui ont prêté sans aucun contrôle.
Alors oui le peuple Grecque avait le droit de se voir poser la question de savoir s'il fallait continuer sur les plans forcés de l'europe ou s'il faut changer d'approche. L'échec des politiques européenne d'austérité pour la Grèce est flagrant et néanmoins les créancier refusent de voir leur erreur. Ils s'obstinent à continuer dans l'impasse dans laquelle ils se sont eux même placer.
Je crois que tu surestimes l'importance des informations nécessaire pour le timing. Tout les constructeur de FPGA suivent les même principes et en gros c'est des blocs pour la logique (LUT, 2-3 flipflop, …), blocs mémoires et pour interconnecter le tout des switch-box. Il n'y a rien de secret ici, tout ça est décrit avec plus ou moins de détails dans les documents publique de ces constructeurs. Les différences sont plutôt sur des choix fin, comme l'inter-connectivité maximale entre les switch-box ou le ratio entre les différents blocs. Ces choix fin n'ont pas vraiment d'avantage intraséque, il vise a répondre au mieux à la majorité des cas. Souvent, d'ailleur, chaque constructeur change par petites touche ces aspects d'une génération à l'autre, preuve qu'il n'y pas de solution miracle. De plus les timing de chacun de ces blocs sont souvent décrit assez précisement dans les documentations publique.
Je pense que l'on peut facilement avoir le timing correct à 90% de la clock théorique maximal. Après oui quand on pousse le FPGA au limite de la fréquence maximal que ses blocs supportent, là il faut une connaissance très fine du delay de chaque bloc. Mais même cette information ne révéle pas grand chose (cela révèle probablement plus d'information sur le process utiliser pour faire le FPGA que sur la structure du FPGA lui même qui est déjà largement publique).
Personnellement je déteste utiliser les outils propriétaire pour les FPGA, ils sont lent, difficilement utilisable depuis un Makefile, les messages d'erreurs et de warning qu'ils produisent sont enchevétrés avec des informations annexes qu'il est souvent difficile de faire la part des choses. Il est presque impossible d'utiliser les blocs dure (controlleur mémoire, controlleur PCIE, …) sans avoir à intégrer un fichier avec une license douteuse dans son projet. Bref en ce qui me concerne ces outils sont un frein.
Non les GPU n'implementeront pas SPIR-V tout simplement parceque SPIR-V n'est pas un byte code mais un "intermediate representation langage". Alors a moins d'implementer un compilateur dans le GPU ca ne passera pas. Et comme implementer un compilateur en hard pour ce type de représentation c'est juste une idée complétement loufoque bah conclusion non aucun hardware ne comprendra nativement SPIR-V.
Après je reviens sur les erreurs de GaMa
Vulkan a un pipeline tout comme OpenGL 4. On a donc soit :
1 - (GL2) vertex -> pixel shader
2 - (GL3.1) vertex -> geometry -> pixel shader
3 - (GL4) vertex -> tesselation control -> tesselation evaluation -> geometry -> pixel shader
Vulkan permet aussi d'utiliser des computes shader (aussi disponible dans GL4) dans ce cas il n'y pas de pipeline comme pour les graphics shader.
Au final la manière de faire le rendu sous Vulkan ou sous OpenGL est la même, les deux reposes sur les mêmes principes, les GPU sont toujours conçus de la même manière.
Vulkan c'est avant tout une autre manière de programmer les GPUs. La grosse différence entre Vulkan et OpenGL c'est le context, dans OpenGL le context GL est implicite, à chaque appel de fonctions le libGL utilise un local thread storage pour savoir contre qu'elle context GL la fonction à lieux. Dans OpenGL on peut toujours modifier l'ensemble des paramêtres de pile de rendu.
Dans Vulkan au contraire, tout est explicite, à chaque appel de fonctions Vulkan l'application doit donner explicitement l'objet contre lequel le driver doit opérer. De plus Vulkan favorise les objets constant, ie dont les propriétés sont définis une seul fois à la création de l'objet et ne peuvent jamais changer mais le contenu oui (par exemple une texture on définis une seul fois ses dimensions mais on peut redéfinir ad-vitam-eternam sont contenue ie les pixels).
Cela est beaucoup plus adapté à la manière dont fonctionne les moteurs de jeux vidéos. En général il utilise un nombre limité d'états qu'il est facile de créer une fois pour toute avec Vulkan et de réutiliser plusieurs fois en changeant juste le contenue entre les différentes frames. Là où pour OpenGL chaque changement d'état implique que le driver doit revalider l'ensemble de tous les états avant de pouvoir soummettre un rendu. Au contraire avec Vulkan une fois les différent états crée on peut les réutiliser et changer entre eux sans que le driver n'est besoins de revérifier quoi que ce soit.
Pour le reste, tu ne te trompes pas, c'est bien l'application qui va gérer elle même la mémoire.
Pour information il y a plusieurs variations de la license BSD et seulement la license BSD "3 clauses" requière de citer l'auteur original. La 3 clauses et aujourd'hui la moins usité parce que citer l'auteur originel est souvent considéré comme problématique.
Dans un soucis d'apaisement je propose qu'on te pende haut et court ! :P
Oui tu as besoins de firmware non libre pour toutes les radeons y compris celle ou il dise que non. Pour la petite histoire pour des raisons historiques les vieux modèles de radeon ont eu leur firmware inclus dans le package firmware canal historique que Debian considère libre même si ce n'est pas le cas.
Pour revenir à cette initiative je trouve que c'est encore une fois un gachis de ressources. Ce n'est pas faire un site pour lister le matériel qu'il faut faire mais financer le développement de tout effort de reverse engineering des firmwares et autre composants qui posent problèmes. Je ne sais pas quand la FSF comprendra que leur initiative sont inutile et infructueuse (tout comme leur support a replicant qui est juste une vaste blague).
Il va falloir m'expliquer comment marche des drm sous linux … Dans tous les cas sous linux on peut facilement recuperer le contenu en clair. Soit en capturant l'image. Soit, si le decodage a lieu en utilisant des librairie comme vdpau en capturant directement le h264 decrypte mais pas decode.
Dans tous les cas sous linux les drm sont inefficace et inutile ou alors les distributeurs vont limiter la resolution 480p et son degrade mais alors prq s'embeter avec les drm.
Vraiment je veux comprendre qui est l'abrutis qui a dis que l'on pouvait faire des drms sous linux.
Filmer ton ecran c'est pas top. Entre capturer le flux HD en mémoire et la capture en filmant l'écran il y a un monde. Ton capteur de camera ainsi que ton écran introduisent des pertes et des biais. Le but du CDM comme annoncé par Mozilla c'est d'empécher la capture du flux en claire. Ce que je dis c'est que c'est impossible sous linux (hors android et chromeos) et que par conséquent la solution de Mozilla ne marchera pas sous linux à moins qu'Adobe soit con.
Mais oui nous sommes d'accord il n'y a aucune solution qui resiste complétement, elle rende au pire plus difficile ou plus pénible la capture.
Si je ne me trompe pas Android expose Trust Zone (http://www.arm.com/products/processors/technologies/trustzone/index.php), la solution ARM équivalente à HDCP, une partie de la mémoire est réservé pour stocker la vidéo décodé, cette mémoire réservé n'est pas accessible depuis le CPU (du moins pas depuis le niveau de privilége noyau mais seulement depuis le niveau de privilège trust zone qui execute du code propriétaire fermé et qui prend la main sur l'OS). Le GPU peut alors utiliser un overlay sécurisé pour afficher la video sur l'écran (tu ne pourras jamais avoir la video sur une face d'un cube, seulement comme un applat). Le GPU garantie que l'overlay peut uniquement envoyer les informations vers l'écran.
Je n'ai jamais regardé si Android exposait cela ou pas (Android c'est trop crade pour mes yeux) mais cela m'étonnerai que Netflix permette la diffusion HD sans la solution Trust Zone.
Il faut pas être naif, les contrats entre les diffuseurs et ceux qui fournissent les solutions techniques stipule toujours que les fournisseurs techniques sont légalement et financièrement responsable de la sécurité du système. De ce que j'ai entendu de la part d'autre acteurs c'est des dizaines de millions de dollars de pénalité si la solution technique permet la capture du contenu en haute résolution et je doute que les avocats d'Adobe et leur ingénieurs ignorent sciemment cela juste pour être gentil avec Linux.
En générale il existe une provision dans les contrats, qui permet la diffusion du contenu dans une qualité hautement dégradé si l'intégrité de la chaîne de diffusion ne peut être sécurisé.
Comme je l'expliquais, sous Linux (sous une distribution normal, pas chromeos ou android) il est impossible d'empêcher la capture de la mémoire du process d'un utilisateur par l'utilisateur lui même. Par conséquent la chaîne de diffusion n'est pas sécurisée et donc selon toute vraisemblance, si j'en crois les accords d'autres acteurs, Adobe ne pourra pas permettre la diffusion de contenu HD sur Linux sans s'exposer à de lourde pénalité financière.
Par conséquent, la solution la plus probable c'est que seul des résolutions dégradé type 480p maximum, seront autorisé sous Linux et donc à mon sens, cette solution de DRM est totalement inutile. Je ne veux pas avoir une solution avec des DRM pour en plus avoir une qualité de merde au final, c'est ridicule de mon point vu.
Ma phrase est dans un context, celui d'un plugin qui est executé à l'intérieur d'une sandbox elle même executé par l'utilisateur. Ce context me semblait évident mais forcement il y a toujours une personne pour pinailler et faire l'innocent.
Sur ton propre desktop c'est open bar, lance avec gdb n'importe quel programme et tu pourras écrire de manière automatique avec un script gdb l'ensemble de la mémoire de ce process dans un fichier. Donc oui un utilisateur peut toujours accéder à l'ensemble de la mémoire de l'ensemble des process qui lui appartient.
Tu rajoutes sur ca que sur ta machine perso tu peux devenir root et alors tu comprends que c'est open bar.
Tu ne peux pas empêcher un autre process d'acceder à l'ensemble de ta mémoire (/dev/mem ou juste un simple script gdb ou une addition au noyau pour simplifier ça). Donc sandbox ou pas sous linux tout le monde peut intercepter le flux décodé. C'est une réalité.
Donc oui il dise support d'ubuntu, red hat et compagnie mais non il ne dise rien. Aura ton la qualité hd sous linux ou sera ton limité à du 240p ou 480p avec un son crado.
Donc je me répète il y a trois solutions, ma première solution reste valide, ils peuvent dire support d'ubuntu ou red hat mais ca ne veut pas dire que tu pourras lire des vidéos avec des drm dessus, ou alors seulement si le content provider dis oui. Bref cette histoire de drm sous linux c'est une vaste blague.
J'attends les details techniques parceque la on est au debut de la blague (et je prefere prevenir c'est pas les Belges qui vont trinquer dans l'histoire).
Donc leur DRM la, sous linux ou autre systeme open source ca ne marchera pas, simplement parceque linux et autre ne supporte d'aucune maniere les technologies comme HDCP ou autre qui empeche le CPU ou tout autre peripherique d'acceder la memoire qui contient la video decrypte.
Je vois donc 3 pistes, certaines plus droles que les autres (oui moi je suis la pour rire) la premiere solution Adobe ne supporte pas linux, tout du moins pas les distributions libre mais seulement des systemes completement ferme (chromebook, android, ?) la deja ca fait rire quand Mozilla pretend que c'est pour permettre l'acces aux contenus sur toutes les plateformes desktop.
Deuxieme solution le cdm d'Abode voit qu'il n'y pas d'hdcp ou assimile et downscale la qualite, pas de hd du 480p maximum avec une bande son digne des discours du General depuis Londre (resortaient les postes a galene) c'est probablement la solution la plus probable. Mais cette solution aussi est risible, donc on cede au drm mais au final on pas le droit d'acceder a des videos en bonne qualite, serieusement au temps ne pas accepter les drm.
Troisieme, solution, le clou du spectacle, le cdm d'Abode export le contenu en hd dans des buffers memoire que l'on peut lire a volonte. La j'avoue, d'un cote je me dis non sont pas si con, d'un autre je me dis un con ca ose tout. Parceque serieusement nous faire chiez pour au final nous donner le truc decompresse en claire …
Donc j'attends les details technique pour savoir quand je pourrai m'arreter de rire. Et oui pour le troisieme cas j'ai pense au watermark mais c'est relativement facile de voir s'il y en a.
Mais arretons nous la et laissons place aux artistes !
Non je trouve qu'il a raison. La bar de titre c'est une perte d'espace ou aucune information pertinente n'est affiché. Je sais que GTK3 apporte enfin la possibilité d'y mettre des tabs mais ca fait quoi 10 ans que ça existe ailleurs ?
Mon autre point c'était de d'insinuer que Mozilla n'avait pas chercher à fixer le toolkit linux en essayant de pousser cette posibilitée dans GTK (au temps que je sache).
Il ne faut pas avoir de peur de montrer du doigt tous les aspects négatifs, point noir, du desktop sous linux. Ça ne m'empêche pas de préférer utiliser linux …
Et sinon des captures d'ecran sous linux c'est possible ? Parceque bon l'utilisation de la bare de titre pour autre chose que le titre sous linux c'est pas gagne. Du coup l'interface doit pas avoir le meme look.
Que faire pour les boites de dialogues pour les mots de passes. Tu peux imaginer une application, ou même un site web, qui reproduit le design du screenlocker et qui demande d'entrer le mot de passe pour dévérouiller. Le pauvre utilisateur rentre alors son mot de passe sans se douter de rien et si le tout est bien fait sans jamais savoir qu'il vient de perdre son mot de passe.
Je m'étais dis il y a longtemps qu'il suffirait que le compositeur affiche une petite icone dans un coin pour que l'utilisateur sache que la boite de dialogue qui a le focus de l'input a les privilèges qu'il faut. Le problème reste qu'une application en plein écran peut afficher la même icone et tromper l'utilisateur. La seul solution est à mon avis de périodiquement (et aléatoirement) vérifier le contenue de des buffers plein écrans, si le compositeur vois que l'application plein écran affiche la même icone au même endroit alors il récupère la main et bloque l'application.
Bref mon idée c'est un peux comme le feedback https et certificat de confiance dans la bar d'adresse des navigateurs mais il implique en plus que le compositeur vérifie constamment les applications qui sont en plein écran.
Bon je n'ai pas pu accéder au pdf (saloperie de publication payante) mais j'ai trouvé une présentation qui semble référer à l'article http://www.cs.indiana.edu/~achauhan/Teaching/B629/2010-Fall/StudentPresns/GPUcompilation.pdf si j'en crois cette présentation la technique n'est pas de casser le if/else mais de faire deux kernel/shader/(le nom que vous aimé pour le programme GPU) l'un qui exécute pour ce qui est la partie if et l'autre pour la partie else.
Bref le GPU marche bien comme je l'expliquai et dans certain cas ce genre d'optimization peut faire gagner en puissance mais bon c'est un genre de tradeoff difficilement évaluable et à mon avis cette astuce est utile que dans un cas nombre de cas limité.
Il y a beaucoup d'autre optimisation qui serait contre productive sur CPU mais qui améliore les performances et la gestions des branches avec un GPU (la présentation au dessus en liste un certains nombre). Mais bon comme je le disais plus haut pour tout les architectures many core c'est avant tout l'algorithme qui doit être repensé et évité le plus possible les branchements fait partie de la liste des choses à faire.
L'appelation SIMT de NVidia c'est plus du marketing qu'autre choses, c'est du SIMD au final comme sur AMD ou Intel mais pas du SIMD comme les extensions CPU ou les anciens SIMD des annees 90.
Ton exemple est completement faut a moins que tu es eu a faire a un bug driver. Le GPU (AMD, Intel ou NVidia) utilise un mask pour savoir qu'elle thread sont actif. Quand il y a une branch les threads qui ne passe pas le test sont masque, oui les instructions de la branch vont s'executer pour les 32 threads mais les resultats ne seront jamais ecris ni dans les registres ni en memoire pour les threads qui n'ont pas passe le test (bref ca tourne dans le vide). De plus si aucun thread n'est actif alors les instructions sont completement ignores. Si tu veux comprendre comment marche plus finement tout ca l'emulateur open source de GPU AMD/NVidia implemente le meme algorithme (sans certains details/optimizations/tricks) http://multi2sim.org/ le manuel en particulier donne une description tres claire du fonctionnement des GPU AMD ou NVidia.
Pour les acces memoire c'est comme ca pour tout les GPUs mais il faut vraiment avoir un programme qui fait des acces memoire massivement aleatoire pour voir les performances s'effondrer avec les acces memoire. Que ca soit NVidia ou AMD, le GPUs pour chaque groupe de thread va essayer de batcher ensemble les acces memoire (memory access coalescing). Il faut savoir que sur un GPU en general chaque acces a la VRAM retourne une grosse quantite de memoire (depends de la taille du bus) souvent > 256bits.
AMD n'est plus VLIW depuis les HD77xx mais sinon ca marchait comme NVidia tu avais un groupe de 32thread qui executait la meme instruction VLIW pour chaque threads.
[^] # Re: Pinaillons
Posté par glisse . En réponse au journal De la démocratie et des systèmes de vote. Évalué à 2.
Je ne connais pas un parti en France (FN, LR, PS) qui soit un vrai lieu de discussions. Les chef(s) et/ou bureau national y décide(nt) de presque tout, le fonctionnement des partis en réduit ses adhérents en une armée de zombies. Ce n'est pas des organisations qui font vivre la démocratie.
J'ai la folie de pensé qu'une assemblé tirée au sort n'aurait pas votée les lois sur le renseignement, les budgets inique qui sabre santé, éducation et justice. Bref j'ai la naïveté de penser que oui un système par tirage au sort donnerai un meilleur résultat. Je ne fais que le constat que le système actuel n'aboutit qu'a des résultats désastreux et par conséquent il est indéfendable à mes yeux.
Oui la révocation des élus serait un pas dans la bonne direction mais cela ne serait être suffisant pour expier ses fautes. Les détails techniques sont toujours important et dans notre système électifs il faudrait en changer beaucoup (vote a 1 tour par classement avec candidat blanc, proportionnel, révocabilité, …).
# Pinaillons
Posté par glisse . En réponse au journal De la démocratie et des systèmes de vote. Évalué à 3.
Je sais c'est vendredi, mais je ne peux m'empêcher d'être étonné de voir des gens pinailler sur le tirage au sort. L'un lui reproche de ne pouvoir représenter ceux qui refuseraient, les indépendants ou bien encore patrons de petite structure. Soit, mais dans le système actuel ces même personnes ne sont pas mieux représenté (la preuve par l'absurde est évidente). Le tirage au sort n'est donc pas pire sur ce point.
L'autre évoque le risque de tirer une assemblé ou un courant de pensé, minoritaire dans la population, serait majoritairement représenté. Si l'objection que cela est statistiquement improbable ne convainc pas, alors encore une fois soulignons que ce genre de situation est encore plus probable dans un système électif (simplement de part l'abstention).
J'espère qu'il est évident que le tirage au sort permettrait une bien meilleurs représentation des salariés, qui malgré qu'ils soient plus important en nombre que les indépendants ou patrons, sont aujourd'hui moins représenté que ces derniers. Il est évident que cela serait valable pour la majorité des catégories sociaux professionnelle.
Un dernier évoque la peur de l'incertitude quand à l'orientation de l'assemblée résultante. Je trouve l'état actuel des choses plus pré-occupant, car j'ai la certitude, conforté par l'expérience acquises, que le système actuel s'oriente rarement avec l'intérêt du plus grand nombres.
De plus, pour moi, la représentativité n'est pas l'argument ultime du tirage au sort. Il en est une propriété importante, et tous les cas particulier ne serait lui enlever cet aspect. Non, sa première qualité à mes yeux c'est qu'il est le boureau des partis politiques, la fin de ces organismes parasitique des démocraties.
Il est probablement important que je souligne certains aspect technique. Les tirés au sort doivent bénéficier d'une indemnité conséquente (disons 5000 ou 10000 euros/mois) le temps de leur mandat et une retraite garantie (disons la moitié de l'indemnité). L'assemblée doit être renouvelé en continue (23 nouveaux tiré par mois par exemple) afin d'éviter les temps morts en ayant en continue suffisamment de personnes expérimenté. L'on doit pouvoir révoquer un tiré au sort (par pétition ou par vote de l'assemblée). Les votes de l'assemblée doivent être publique, sans exception. Les lois voté doivent pouvoir être abrogé par pétition… Il y aurait encore bien d'autres détails à considérer avec attention (corruption, conflit d'intérêt, …), mais bien moins que ce que le système actuel demanderait.
# Drivers libre ?
Posté par glisse . En réponse au journal Turris Omnia en passe de doubler son objectif de financement participatif.. Évalué à 5. Dernière modification le 18 novembre 2015 à 21:45.
Les drivers sont libres ? (wifi et firmware, enfin tout le tintouin) ?
Parce que le site me donne l'impression d'être superficiel sur ce point.
[^] # Re: Le + intéressant c'est le futur proche
Posté par glisse . En réponse au journal Et ce soir, la démocratie l'emporte ! . Évalué à 4.
Pour moi les 3 grandes puissances sont à part (Chine, Russie, Etats-Unis). Et il est impossible de ne pas avoir de relation avec elles. Alors oui tout le monde parle avec Vlad, mais aussi avec Xi Jingping ou Obama. Il faut être hypocrite pour refuser de parler et faire des affaires avec Vlad tout en continuant à en faire avec Xi Jingping ou même Obama. Les 3 occupent actuellement des territoires qu'ils ont envahit en infraction avec les principes internationaux.
Alors non ça ne me choque pas de voir des gens parler avec la Russie, les petits doivent jouer les gros les uns contre les autres.
[^] # Re: Le + intéressant c'est le futur proche
Posté par glisse . En réponse au journal Et ce soir, la démocratie l'emporte ! . Évalué à 2.
Le problème c'est à qui vendre. Le gouvernement de Tsipras a l'air d'avoir certaine valeurs, donc vendre à des terroristes ou des dictatures c'est probablement pas près d'arriver. Je doute qu'un autre pays d'Europe soit intéresser pour racheter des équipements d'occasion.
Après il y a aussi le classique des dépenses militaire ou tu engloutis de l'argent sans jamais recevoir le produit final. Par exemples les sous-marins acheté aux Allemands, qui ont été payé en partie mais jamais livré :
http://www.defenseindustrydaily.com/greece-in-default-on-u-214-submarine-order-05801/
Il y a une histoire similaire me semble t-il avec des chars Français, ou des hélicoptères (enfin j'oublie ce que c'était). Mais oui je suis d'accord il faudrait qu'il vende tous ces trucs inutiles (sous marins, missiles, chars) mais je comprends aussi qu'il ne veuille pas vendre à n'importe qui.
[^] # Re: Le + intéressant c'est le futur proche
Posté par glisse . En réponse au journal Et ce soir, la démocratie l'emporte ! . Évalué à 3.
Vendre un stade olympique ? Pas facile, sur ebay peut être :) Même les équipement militaire c'est pas simple à vendre sans compter qu'une bonne partie de l'argent est simplement partie en frai de fonctionnement (essence, entretient, …).
J'aimerai avoir accès au rapport d'audit de leur dette en anglais mais pour le moment je ne trouve que des résumés. Donc d'après ce rapport beaucoup d'argent est partie en fumé. Taux d'intérêt particulièrement élevée, perte de revenue fiscaux suite à la fuite de capitale, maintient des dépenses publiques malgré cela, sauvetage des banques Grecques qui avait des bilans désastreux (montagne de dettes), ici encore socialisation des pertes privés par l'état. Enfin bon, aujourd'hui je doute qu'il puisse récupérer beaucoup en revendant ce qu'il leur reste de ces années faste. Peut être 1 milliards ou 2, mais certainement pas beaucoup plus, j'imagine qu'il regarde ça.
https://left.gr/news/executive-summary-report-debt-truth-committee
[^] # Re: Le + intéressant c'est le futur proche
Posté par glisse . En réponse au journal Et ce soir, la démocratie l'emporte ! . Évalué à 8.
Faut se renseigner un peu, l'Europe n'a pas prêter 300 milliards à la Grèce, l'europe à racheter pour presque 300 milliards de dette privé. L'europe a socialisé les dettes de le Grèce qui était au paravant détenue par des banques privés.
Sources:
http://www.okeanews.fr/20150115-ou-est-passe-largent-des-prets-faits-la-grece
http://www.lefigaro.fr/conjoncture/2012/06/16/20002-20120616ARTFIG00346-o-sont-passes-les-milliards-d-euros-d-aide-a-la-grece.php
Seulement les gouvernements européens ne pouvaient pas dire ouvertement qu'ils socialisaient les pertes des banques privés alors ils font passer ca pour un prêt à la Gréce, et on laisse les gens imaginer que les Grecques ont dépensé ces 300milliards pour boire de l'ouzo sur la plage. Je souligne au passage que les créancier privés on étaient irresponsable de prêter ainsi et que c'est eux qui devrait faire face aux conséquences de leur incompétences.
Je conseille de plus de se renseigner sur comment la Grèce à pu autant s'endetter, et la encore ce n'est pas ce que les grands médias disent. Le coûts des fonctionnaires en comparaisons du PIB est moins important en Grèce qu'en Allemagne ou France ou que la plus part des autres pays européens.
Sources
https://fr.wikipedia.org/wiki/Crise_de_la_dette_publique_grecque#Causes_.C3.A9conomiques_de_la_crise
http://www.agoravox.fr/tribune-libre/article/l-endettement-de-la-grece-au-168980
Celui des retraites est par contre plus important comparé à la moyenne européenne
http://lexpansion.lexpress.fr/actualite-economique/les-retraites-des-privilegies-sans-qui-la-grece-irait-encore-plus-mal_1692453.html
Mais celle-ci on drastiquement baissé depuis le début de la crise.
Je ne dis pas que le peuple Grecque n'est pas responsable de sa dette mais une grande partie est illégitime est n'a servis qu'à enrichir des intérêts privés qui ont canibalisé un état faible qui avait déjà du mal à lever des impôts. Et que ceux qui devrait payer aujourd'hui ceux sont les banques privés qui ont prêté sans aucun contrôle.
Alors oui le peuple Grecque avait le droit de se voir poser la question de savoir s'il fallait continuer sur les plans forcés de l'europe ou s'il faut changer d'approche. L'échec des politiques européenne d'austérité pour la Grèce est flagrant et néanmoins les créancier refusent de voir leur erreur. Ils s'obstinent à continuer dans l'impasse dans laquelle ils se sont eux même placer.
[^] # Re: Un peu réducteur comme raisonnement...
Posté par glisse . En réponse au journal Enfin une chaîne de développement complètement open source pour un FPGA. Évalué à 4.
Je crois que tu surestimes l'importance des informations nécessaire pour le timing. Tout les constructeur de FPGA suivent les même principes et en gros c'est des blocs pour la logique (LUT, 2-3 flipflop, …), blocs mémoires et pour interconnecter le tout des switch-box. Il n'y a rien de secret ici, tout ça est décrit avec plus ou moins de détails dans les documents publique de ces constructeurs. Les différences sont plutôt sur des choix fin, comme l'inter-connectivité maximale entre les switch-box ou le ratio entre les différents blocs. Ces choix fin n'ont pas vraiment d'avantage intraséque, il vise a répondre au mieux à la majorité des cas. Souvent, d'ailleur, chaque constructeur change par petites touche ces aspects d'une génération à l'autre, preuve qu'il n'y pas de solution miracle. De plus les timing de chacun de ces blocs sont souvent décrit assez précisement dans les documentations publique.
Je pense que l'on peut facilement avoir le timing correct à 90% de la clock théorique maximal. Après oui quand on pousse le FPGA au limite de la fréquence maximal que ses blocs supportent, là il faut une connaissance très fine du delay de chaque bloc. Mais même cette information ne révéle pas grand chose (cela révèle probablement plus d'information sur le process utiliser pour faire le FPGA que sur la structure du FPGA lui même qui est déjà largement publique).
Personnellement je déteste utiliser les outils propriétaire pour les FPGA, ils sont lent, difficilement utilisable depuis un Makefile, les messages d'erreurs et de warning qu'ils produisent sont enchevétrés avec des informations annexes qu'il est souvent difficile de faire la part des choses. Il est presque impossible d'utiliser les blocs dure (controlleur mémoire, controlleur PCIE, …) sans avoir à intégrer un fichier avec une license douteuse dans son projet. Bref en ce qui me concerne ces outils sont un frein.
[^] # Re: Mon analyse.
Posté par glisse . En réponse au journal Vulkan le successeur d'OpenGL. Évalué à 10.
Non les GPU n'implementeront pas SPIR-V tout simplement parceque SPIR-V n'est pas un byte code mais un "intermediate representation langage". Alors a moins d'implementer un compilateur dans le GPU ca ne passera pas. Et comme implementer un compilateur en hard pour ce type de représentation c'est juste une idée complétement loufoque bah conclusion non aucun hardware ne comprendra nativement SPIR-V.
Après je reviens sur les erreurs de GaMa
Vulkan a un pipeline tout comme OpenGL 4. On a donc soit :
1 - (GL2) vertex -> pixel shader
2 - (GL3.1) vertex -> geometry -> pixel shader
3 - (GL4) vertex -> tesselation control -> tesselation evaluation -> geometry -> pixel shader
Vulkan permet aussi d'utiliser des computes shader (aussi disponible dans GL4) dans ce cas il n'y pas de pipeline comme pour les graphics shader.
Au final la manière de faire le rendu sous Vulkan ou sous OpenGL est la même, les deux reposes sur les mêmes principes, les GPU sont toujours conçus de la même manière.
Vulkan c'est avant tout une autre manière de programmer les GPUs. La grosse différence entre Vulkan et OpenGL c'est le context, dans OpenGL le context GL est implicite, à chaque appel de fonctions le libGL utilise un local thread storage pour savoir contre qu'elle context GL la fonction à lieux. Dans OpenGL on peut toujours modifier l'ensemble des paramêtres de pile de rendu.
Dans Vulkan au contraire, tout est explicite, à chaque appel de fonctions Vulkan l'application doit donner explicitement l'objet contre lequel le driver doit opérer. De plus Vulkan favorise les objets constant, ie dont les propriétés sont définis une seul fois à la création de l'objet et ne peuvent jamais changer mais le contenu oui (par exemple une texture on définis une seul fois ses dimensions mais on peut redéfinir ad-vitam-eternam sont contenue ie les pixels).
Cela est beaucoup plus adapté à la manière dont fonctionne les moteurs de jeux vidéos. En général il utilise un nombre limité d'états qu'il est facile de créer une fois pour toute avec Vulkan et de réutiliser plusieurs fois en changeant juste le contenue entre les différentes frames. Là où pour OpenGL chaque changement d'état implique que le driver doit revalider l'ensemble de tous les états avant de pouvoir soummettre un rendu. Au contraire avec Vulkan une fois les différent états crée on peut les réutiliser et changer entre eux sans que le driver n'est besoins de revérifier quoi que ce soit.
Pour le reste, tu ne te trompes pas, c'est bien l'application qui va gérer elle même la mémoire.
[^] # Re: Incompréhension du logiciel libre
Posté par glisse . En réponse au journal État des lieux et typologie des Fab Labs. Évalué à 5.
Pour information il y a plusieurs variations de la license BSD et seulement la license BSD "3 clauses" requière de citer l'auteur original. La 3 clauses et aujourd'hui la moins usité parce que citer l'auteur originel est souvent considéré comme problématique.
Dans un soucis d'apaisement je propose qu'on te pende haut et court ! :P
[^] # Re: C'est l'inverse qu'il faut faire
Posté par glisse . En réponse au journal h-node.org : GNU/Linux matériel compatible, base de données. Évalué à 1.
Oui tu as besoins de firmware non libre pour toutes les radeons y compris celle ou il dise que non. Pour la petite histoire pour des raisons historiques les vieux modèles de radeon ont eu leur firmware inclus dans le package firmware canal historique que Debian considère libre même si ce n'est pas le cas.
Pour revenir à cette initiative je trouve que c'est encore une fois un gachis de ressources. Ce n'est pas faire un site pour lister le matériel qu'il faut faire mais financer le développement de tout effort de reverse engineering des firmwares et autre composants qui posent problèmes. Je ne sais pas quand la FSF comprendra que leur initiative sont inutile et infructueuse (tout comme leur support a replicant qui est juste une vaste blague).
[^] # Re: Pas spécifique linux
Posté par glisse . En réponse au journal Les DRM dans HTML 5. Évalué à 9.
Il va falloir m'expliquer comment marche des drm sous linux … Dans tous les cas sous linux on peut facilement recuperer le contenu en clair. Soit en capturant l'image. Soit, si le decodage a lieu en utilisant des librairie comme vdpau en capturant directement le h264 decrypte mais pas decode.
Dans tous les cas sous linux les drm sont inefficace et inutile ou alors les distributeurs vont limiter la resolution 480p et son degrade mais alors prq s'embeter avec les drm.
Vraiment je veux comprendre qui est l'abrutis qui a dis que l'on pouvait faire des drms sous linux.
[^] # Re: Non mais attendaient on va rire
Posté par glisse . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 1.
Control-Shift-Alt-r sous gnome-shell … bon il y a d'autre logiciel de screen recording aussi pour d'autre desktop.
[^] # Re: Non mais attendaient on va rire
Posté par glisse . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 6.
Filmer ton ecran c'est pas top. Entre capturer le flux HD en mémoire et la capture en filmant l'écran il y a un monde. Ton capteur de camera ainsi que ton écran introduisent des pertes et des biais. Le but du CDM comme annoncé par Mozilla c'est d'empécher la capture du flux en claire. Ce que je dis c'est que c'est impossible sous linux (hors android et chromeos) et que par conséquent la solution de Mozilla ne marchera pas sous linux à moins qu'Adobe soit con.
Mais oui nous sommes d'accord il n'y a aucune solution qui resiste complétement, elle rende au pire plus difficile ou plus pénible la capture.
[^] # Re: Non mais attendaient on va rire
Posté par glisse . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 4.
Si je ne me trompe pas Android expose Trust Zone (http://www.arm.com/products/processors/technologies/trustzone/index.php), la solution ARM équivalente à HDCP, une partie de la mémoire est réservé pour stocker la vidéo décodé, cette mémoire réservé n'est pas accessible depuis le CPU (du moins pas depuis le niveau de privilége noyau mais seulement depuis le niveau de privilège trust zone qui execute du code propriétaire fermé et qui prend la main sur l'OS). Le GPU peut alors utiliser un overlay sécurisé pour afficher la video sur l'écran (tu ne pourras jamais avoir la video sur une face d'un cube, seulement comme un applat). Le GPU garantie que l'overlay peut uniquement envoyer les informations vers l'écran.
Je n'ai jamais regardé si Android exposait cela ou pas (Android c'est trop crade pour mes yeux) mais cela m'étonnerai que Netflix permette la diffusion HD sans la solution Trust Zone.
[^] # Re: Non mais attendaient on va rire
Posté par glisse . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 7.
Il faut pas être naif, les contrats entre les diffuseurs et ceux qui fournissent les solutions techniques stipule toujours que les fournisseurs techniques sont légalement et financièrement responsable de la sécurité du système. De ce que j'ai entendu de la part d'autre acteurs c'est des dizaines de millions de dollars de pénalité si la solution technique permet la capture du contenu en haute résolution et je doute que les avocats d'Adobe et leur ingénieurs ignorent sciemment cela juste pour être gentil avec Linux.
En générale il existe une provision dans les contrats, qui permet la diffusion du contenu dans une qualité hautement dégradé si l'intégrité de la chaîne de diffusion ne peut être sécurisé.
Comme je l'expliquais, sous Linux (sous une distribution normal, pas chromeos ou android) il est impossible d'empêcher la capture de la mémoire du process d'un utilisateur par l'utilisateur lui même. Par conséquent la chaîne de diffusion n'est pas sécurisée et donc selon toute vraisemblance, si j'en crois les accords d'autres acteurs, Adobe ne pourra pas permettre la diffusion de contenu HD sur Linux sans s'exposer à de lourde pénalité financière.
Par conséquent, la solution la plus probable c'est que seul des résolutions dégradé type 480p maximum, seront autorisé sous Linux et donc à mon sens, cette solution de DRM est totalement inutile. Je ne veux pas avoir une solution avec des DRM pour en plus avoir une qualité de merde au final, c'est ridicule de mon point vu.
[^] # Re: Non mais attendaient on va rire
Posté par glisse . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 5.
Ma phrase est dans un context, celui d'un plugin qui est executé à l'intérieur d'une sandbox elle même executé par l'utilisateur. Ce context me semblait évident mais forcement il y a toujours une personne pour pinailler et faire l'innocent.
[^] # Re: Non mais attendaient on va rire
Posté par glisse . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 2.
Sur ton propre desktop c'est open bar, lance avec gdb n'importe quel programme et tu pourras écrire de manière automatique avec un script gdb l'ensemble de la mémoire de ce process dans un fichier. Donc oui un utilisateur peut toujours accéder à l'ensemble de la mémoire de l'ensemble des process qui lui appartient.
Tu rajoutes sur ca que sur ta machine perso tu peux devenir root et alors tu comprends que c'est open bar.
[^] # Re: Non mais attendaient on va rire
Posté par glisse . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 1.
Tu ne peux pas empêcher un autre process d'acceder à l'ensemble de ta mémoire (/dev/mem ou juste un simple script gdb ou une addition au noyau pour simplifier ça). Donc sandbox ou pas sous linux tout le monde peut intercepter le flux décodé. C'est une réalité.
Donc oui il dise support d'ubuntu, red hat et compagnie mais non il ne dise rien. Aura ton la qualité hd sous linux ou sera ton limité à du 240p ou 480p avec un son crado.
Donc je me répète il y a trois solutions, ma première solution reste valide, ils peuvent dire support d'ubuntu ou red hat mais ca ne veut pas dire que tu pourras lire des vidéos avec des drm dessus, ou alors seulement si le content provider dis oui. Bref cette histoire de drm sous linux c'est une vaste blague.
# Non mais attendaient on va rire
Posté par glisse . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 8.
J'attends les details techniques parceque la on est au debut de la blague (et je prefere prevenir c'est pas les Belges qui vont trinquer dans l'histoire).
Donc leur DRM la, sous linux ou autre systeme open source ca ne marchera pas, simplement parceque linux et autre ne supporte d'aucune maniere les technologies comme HDCP ou autre qui empeche le CPU ou tout autre peripherique d'acceder la memoire qui contient la video decrypte.
Je vois donc 3 pistes, certaines plus droles que les autres (oui moi je suis la pour rire) la premiere solution Adobe ne supporte pas linux, tout du moins pas les distributions libre mais seulement des systemes completement ferme (chromebook, android, ?) la deja ca fait rire quand Mozilla pretend que c'est pour permettre l'acces aux contenus sur toutes les plateformes desktop.
Deuxieme solution le cdm d'Abode voit qu'il n'y pas d'hdcp ou assimile et downscale la qualite, pas de hd du 480p maximum avec une bande son digne des discours du General depuis Londre (resortaient les postes a galene) c'est probablement la solution la plus probable. Mais cette solution aussi est risible, donc on cede au drm mais au final on pas le droit d'acceder a des videos en bonne qualite, serieusement au temps ne pas accepter les drm.
Troisieme, solution, le clou du spectacle, le cdm d'Abode export le contenu en hd dans des buffers memoire que l'on peut lire a volonte. La j'avoue, d'un cote je me dis non sont pas si con, d'un autre je me dis un con ca ose tout. Parceque serieusement nous faire chiez pour au final nous donner le truc decompresse en claire …
Donc j'attends les details technique pour savoir quand je pourrai m'arreter de rire. Et oui pour le troisieme cas j'ai pense au watermark mais c'est relativement facile de voir s'il y en a.
Mais arretons nous la et laissons place aux artistes !
[^] # Re: Capture d'ecran sous linux ?
Posté par glisse . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 1.
Non je trouve qu'il a raison. La bar de titre c'est une perte d'espace ou aucune information pertinente n'est affiché. Je sais que GTK3 apporte enfin la possibilité d'y mettre des tabs mais ca fait quoi 10 ans que ça existe ailleurs ?
Mon autre point c'était de d'insinuer que Mozilla n'avait pas chercher à fixer le toolkit linux en essayant de pousser cette posibilitée dans GTK (au temps que je sache).
Il ne faut pas avoir de peur de montrer du doigt tous les aspects négatifs, point noir, du desktop sous linux. Ça ne m'empêche pas de préférer utiliser linux …
# Capture d'ecran sous linux ?
Posté par glisse . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 5.
Et sinon des captures d'ecran sous linux c'est possible ? Parceque bon l'utilisation de la bare de titre pour autre chose que le titre sous linux c'est pas gagne. Du coup l'interface doit pas avoir le meme look.
# Boite de dialogue pour les mots de passe
Posté par glisse . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 4.
Que faire pour les boites de dialogues pour les mots de passes. Tu peux imaginer une application, ou même un site web, qui reproduit le design du screenlocker et qui demande d'entrer le mot de passe pour dévérouiller. Le pauvre utilisateur rentre alors son mot de passe sans se douter de rien et si le tout est bien fait sans jamais savoir qu'il vient de perdre son mot de passe.
Je m'étais dis il y a longtemps qu'il suffirait que le compositeur affiche une petite icone dans un coin pour que l'utilisateur sache que la boite de dialogue qui a le focus de l'input a les privilèges qu'il faut. Le problème reste qu'une application en plein écran peut afficher la même icone et tromper l'utilisateur. La seul solution est à mon avis de périodiquement (et aléatoirement) vérifier le contenue de des buffers plein écrans, si le compositeur vois que l'application plein écran affiche la même icone au même endroit alors il récupère la main et bloque l'application.
Bref mon idée c'est un peux comme le feedback https et certificat de confiance dans la bar d'adresse des navigateurs mais il implique en plus que le compositeur vérifie constamment les applications qui sont en plein écran.
Il y a d'autre idées ?
[^] # Re: Et les cartes graphiques ?
Posté par glisse . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 0.
Bon je n'ai pas pu accéder au pdf (saloperie de publication payante) mais j'ai trouvé une présentation qui semble référer à l'article http://www.cs.indiana.edu/~achauhan/Teaching/B629/2010-Fall/StudentPresns/GPUcompilation.pdf si j'en crois cette présentation la technique n'est pas de casser le if/else mais de faire deux kernel/shader/(le nom que vous aimé pour le programme GPU) l'un qui exécute pour ce qui est la partie if et l'autre pour la partie else.
Bref le GPU marche bien comme je l'expliquai et dans certain cas ce genre d'optimization peut faire gagner en puissance mais bon c'est un genre de tradeoff difficilement évaluable et à mon avis cette astuce est utile que dans un cas nombre de cas limité.
Il y a beaucoup d'autre optimisation qui serait contre productive sur CPU mais qui améliore les performances et la gestions des branches avec un GPU (la présentation au dessus en liste un certains nombre). Mais bon comme je le disais plus haut pour tout les architectures many core c'est avant tout l'algorithme qui doit être repensé et évité le plus possible les branchements fait partie de la liste des choses à faire.
[^] # Re: Et les cartes graphiques ?
Posté par glisse . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 3.
L'appelation SIMT de NVidia c'est plus du marketing qu'autre choses, c'est du SIMD au final comme sur AMD ou Intel mais pas du SIMD comme les extensions CPU ou les anciens SIMD des annees 90.
Ton exemple est completement faut a moins que tu es eu a faire a un bug driver. Le GPU (AMD, Intel ou NVidia) utilise un mask pour savoir qu'elle thread sont actif. Quand il y a une branch les threads qui ne passe pas le test sont masque, oui les instructions de la branch vont s'executer pour les 32 threads mais les resultats ne seront jamais ecris ni dans les registres ni en memoire pour les threads qui n'ont pas passe le test (bref ca tourne dans le vide). De plus si aucun thread n'est actif alors les instructions sont completement ignores. Si tu veux comprendre comment marche plus finement tout ca l'emulateur open source de GPU AMD/NVidia implemente le meme algorithme (sans certains details/optimizations/tricks) http://multi2sim.org/ le manuel en particulier donne une description tres claire du fonctionnement des GPU AMD ou NVidia.
Pour les acces memoire c'est comme ca pour tout les GPUs mais il faut vraiment avoir un programme qui fait des acces memoire massivement aleatoire pour voir les performances s'effondrer avec les acces memoire. Que ca soit NVidia ou AMD, le GPUs pour chaque groupe de thread va essayer de batcher ensemble les acces memoire (memory access coalescing). Il faut savoir que sur un GPU en general chaque acces a la VRAM retourne une grosse quantite de memoire (depends de la taille du bus) souvent > 256bits.
AMD n'est plus VLIW depuis les HD77xx mais sinon ca marchait comme NVidia tu avais un groupe de 32thread qui executait la meme instruction VLIW pour chaque threads.