Wikilivres:Accueil

<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.11/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.11/ http://www.mediawiki.org/xml/export-0.11.xsd" version="0.11" xml:lang="fr">
  <siteinfo>
    <sitename>Wikilivres</sitename>
    <dbname>frwikibooks</dbname>
    <base>https://fr.wikibooks.org/wiki/Accueil</base>
    <generator>MediaWiki 1.47.0-wmf.20</generator>
    <case>first-letter</case>
    <namespaces>
      <namespace key="-2" case="first-letter">Média</namespace>
      <namespace key="-1" case="first-letter">Spécial</namespace>
      <namespace key="0" case="first-letter" />
      <namespace key="1" case="first-letter">Discussion</namespace>
      <namespace key="2" case="first-letter">Utilisateur</namespace>
      <namespace key="3" case="first-letter">Discussion utilisateur</namespace>
      <namespace key="4" case="first-letter">Wikilivres</namespace>
      <namespace key="5" case="first-letter">Discussion Wikilivres</namespace>
      <namespace key="6" case="first-letter">Fichier</namespace>
      <namespace key="7" case="first-letter">Discussion fichier</namespace>
      <namespace key="8" case="first-letter">MediaWiki</namespace>
      <namespace key="9" case="first-letter">Discussion MediaWiki</namespace>
      <namespace key="10" case="first-letter">Modèle</namespace>
      <namespace key="11" case="first-letter">Discussion modèle</namespace>
      <namespace key="12" case="first-letter">Aide</namespace>
      <namespace key="13" case="first-letter">Discussion aide</namespace>
      <namespace key="14" case="first-letter">Catégorie</namespace>
      <namespace key="15" case="first-letter">Discussion catégorie</namespace>
      <namespace key="100" case="first-letter">Transwiki</namespace>
      <namespace key="101" case="first-letter">Discussion Transwiki</namespace>
      <namespace key="102" case="first-letter">Wikijunior</namespace>
      <namespace key="103" case="first-letter">Discussion Wikijunior</namespace>
      <namespace key="710" case="first-letter">TimedText</namespace>
      <namespace key="711" case="first-letter">TimedText talk</namespace>
      <namespace key="828" case="first-letter">Module</namespace>
      <namespace key="829" case="first-letter">Discussion module</namespace>
      <namespace key="1728" case="first-letter">Event</namespace>
      <namespace key="1729" case="first-letter">Event talk</namespace>
    </namespaces>
  </siteinfo>
  <page>
    <title>Wikilivres:Accueil</title>
    <ns>4</ns>
    <id>95</id>
    <revision>
      <id>772299</id>
      <parentid>754391</parentid>
      <timestamp>2026-09-16T14:27:29Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772299</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1420" sha1="ln9zdisbqxbjseegunlij8wb8teg9ef" xml:space="preserve">__NOTOC__

&lt;big&gt;Sur cette page de Wikilivres, vous trouverez tous les liens nécessaires pour trouver de l'aide.&lt;/big&gt;

{{Contact}}

&lt;div style=&quot;width: 49%; float: left;&quot;&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
&lt;h2 class=&quot;headerbleu&quot;&gt;Communiquer&lt;/h2&gt;
* [[Wikilivres:Le Bistro|Le Bistro]]
* [[Wikilivres:Ambassade|The embassy for non-French speakers]] (l'[[Wikilivres:Ambassade|ambassade]] pour l'accueil des non-francophones)
* Par [[Guide d’utilisation de l’IRC|IRC]] sur le canal [irc://irc.freenode.net/wikibooks-fr #wikibooks-fr]
&lt;/div&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
&lt;h2 class=&quot;headerbleu&quot;&gt;L'Équipe&lt;/h2&gt;
* [[Wikilivres:Wikirédacteurs par pays|Wikirédacteurs par pays]]
* [[Wikilivres:Wikirédacteurs par thèmes d'intérêt|Wikirédacteurs par thèmes d'intérêt]]
* Les [[Wikilivres:patrouilleurs|patrouilleurs]]
* Les [[Wikilivres:administrateurs|administrateurs]]
* Les [[Wikilivres:bureaucrates|bureaucrates]]
&lt;/div&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
{{:Wikilivres:Accueil/Nouveautés}}
&lt;/div&gt;
&lt;/div&gt;

&lt;div style=&quot;width: 49%; float: right;&quot;&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
&lt;h2 class=&quot;headerbleu&quot;&gt;Actualité et annonces&lt;/h2&gt;
[[Wikilivres:Annonces|Événements]] concernant le projet :
{{:Wikilivres:Annonces}}
&lt;/div&gt;

&lt;/div&gt;

[[Catégorie:Wikilivres]]</text>
      <sha1>ln9zdisbqxbjseegunlij8wb8teg9ef</sha1>
    </revision>
    <revision>
      <id>772308</id>
      <parentid>772299</parentid>
      <timestamp>2026-09-16T14:44:26Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772308</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1439" sha1="c67plu7mgo2z6tsmjt9wh88wa53zb1v" xml:space="preserve">__NOTOC__

&lt;big&gt;Sur cette page de Wikilivres, vous trouverez tous les liens nécessaires concernant la vie communautaire du projet.&lt;/big&gt;

{{Contact}}

&lt;div style=&quot;width: 49%; float: left;&quot;&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
&lt;h2 class=&quot;headerbleu&quot;&gt;Communiquer&lt;/h2&gt;
* [[Wikilivres:Le Bistro|Le Bistro]]
* [[Wikilivres:Ambassade|The embassy for non-French speakers]] (l'[[Wikilivres:Ambassade|ambassade]] pour l'accueil des non-francophones)
* Par [[Guide d’utilisation de l’IRC|IRC]] sur le canal [irc://irc.freenode.net/wikibooks-fr #wikibooks-fr]
&lt;/div&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
&lt;h2 class=&quot;headerbleu&quot;&gt;L'Équipe&lt;/h2&gt;
* [[Wikilivres:Wikirédacteurs par pays|Wikirédacteurs par pays]]
* [[Wikilivres:Wikirédacteurs par thèmes d'intérêt|Wikirédacteurs par thèmes d'intérêt]]
* Les [[Wikilivres:patrouilleurs|patrouilleurs]]
* Les [[Wikilivres:administrateurs|administrateurs]]
* Les [[Wikilivres:bureaucrates|bureaucrates]]
&lt;/div&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
{{:Wikilivres:Accueil/Nouveautés}}
&lt;/div&gt;
&lt;/div&gt;

&lt;div style=&quot;width: 49%; float: right;&quot;&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
&lt;h2 class=&quot;headerbleu&quot;&gt;Actualité et annonces&lt;/h2&gt;
[[Wikilivres:Annonces|Événements]] concernant le projet :
{{:Wikilivres:Annonces}}
&lt;/div&gt;

&lt;/div&gt;

[[Catégorie:Wikilivres]]</text>
      <sha1>c67plu7mgo2z6tsmjt9wh88wa53zb1v</sha1>
    </revision>
    <revision>
      <id>772359</id>
      <parentid>772308</parentid>
      <timestamp>2026-09-17T11:55:34Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772359</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1428" sha1="9io09yk95q4oo0swlj30u1i1nq68qya" xml:space="preserve">__NOTOC__

&lt;big&gt;Sur cette page de Wikilivres, vous trouverez des informations concernant la vie communautaire du projet.&lt;/big&gt;

{{Contact}}

&lt;div style=&quot;width: 49%; float: left;&quot;&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
&lt;h2 class=&quot;headerbleu&quot;&gt;Communiquer&lt;/h2&gt;
* [[Wikilivres:Le Bistro|Le Bistro]]
* [[Wikilivres:Ambassade|The embassy for non-French speakers]] (l'[[Wikilivres:Ambassade|ambassade]] pour l'accueil des non-francophones)
* Par [[Guide d’utilisation de l’IRC|IRC]] sur le canal [irc://irc.freenode.net/wikibooks-fr #wikibooks-fr]
&lt;/div&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
&lt;h2 class=&quot;headerbleu&quot;&gt;L'Équipe&lt;/h2&gt;
* [[Wikilivres:Wikirédacteurs par pays|Wikirédacteurs par pays]]
* [[Wikilivres:Wikirédacteurs par thèmes d'intérêt|Wikirédacteurs par thèmes d'intérêt]]
* Les [[Wikilivres:patrouilleurs|patrouilleurs]]
* Les [[Wikilivres:administrateurs|administrateurs]]
* Les [[Wikilivres:bureaucrates|bureaucrates]]
&lt;/div&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
{{:Wikilivres:Accueil/Nouveautés}}
&lt;/div&gt;
&lt;/div&gt;

&lt;div style=&quot;width: 49%; float: right;&quot;&gt;

&lt;div style=&quot;margin:0 1em 1em 0; padding:6px; border:1px #5555 solid;&quot;&gt;
&lt;h2 class=&quot;headerbleu&quot;&gt;Actualité et annonces&lt;/h2&gt;
[[Wikilivres:Annonces|Événements]] concernant le projet :
{{:Wikilivres:Annonces}}
&lt;/div&gt;

&lt;/div&gt;

[[Catégorie:Wikilivres]]</text>
      <sha1>9io09yk95q4oo0swlj30u1i1nq68qya</sha1>
    </revision>
  </page>
  <page>
    <title>Catégorie:Livres terminés</title>
    <ns>14</ns>
    <id>11928</id>
    <revision>
      <id>772289</id>
      <parentid>772256</parentid>
      <timestamp>2026-09-16T14:05:19Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772289</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="218" sha1="47pnfyijxaot73zcbvybla7jqiyyn1a" xml:space="preserve">&lt;noinclude&gt;&lt;big&gt;&lt;big&gt;Cette page de Wikilivres reprend toute la catégorie des livres considérés comme terminés et reprenant plusieurs chapitres.&lt;/big&gt;&lt;/big&gt;&lt;/noinclude&gt;

[[Catégorie:Livres par niveau d'avancement]]</text>
      <sha1>47pnfyijxaot73zcbvybla7jqiyyn1a</sha1>
    </revision>
    <revision>
      <id>772290</id>
      <parentid>772289</parentid>
      <timestamp>2026-09-16T14:06:15Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772290</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="224" sha1="s3r1vyaxz6dp0n2uyedzdppo3sb2vwg" xml:space="preserve">&lt;noinclude&gt;&lt;big&gt;&lt;big&gt;Cette page de Wikilivres reprend toute la catégorie des livres considérés comme terminés et qui comprennent plusieurs chapitres.&lt;/big&gt;&lt;/big&gt;&lt;/noinclude&gt;

[[Catégorie:Livres par niveau d'avancement]]</text>
      <sha1>s3r1vyaxz6dp0n2uyedzdppo3sb2vwg</sha1>
    </revision>
    <revision>
      <id>772291</id>
      <parentid>772290</parentid>
      <timestamp>2026-09-16T14:06:56Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772291</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="210" sha1="eydl9ag5blmzul0ynqjrhbftzyikzg5" xml:space="preserve">&lt;noinclude&gt;&lt;big&gt;&lt;big&gt;Cette page de Wikilivres regroupe tous les livres considérés comme terminés et qui comprennent plusieurs chapitres.&lt;/big&gt;&lt;/big&gt;&lt;/noinclude&gt;

[[Catégorie:Livres par niveau d'avancement]]</text>
      <sha1>eydl9ag5blmzul0ynqjrhbftzyikzg5</sha1>
    </revision>
  </page>
  <page>
    <title>Catégorie:Livres en cours de rédaction</title>
    <ns>14</ns>
    <id>11931</id>
    <revision>
      <id>772295</id>
      <parentid>463204</parentid>
      <timestamp>2026-09-16T14:19:03Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772295</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="319" sha1="5jmpa0x4who5mhx6351mtphz3j09u6t" xml:space="preserve">&lt;big&gt;Cette page de Wikilivres regroupe la liste de tous les livres considérés comme non terminés ainsi que les minilivres manifestement incomplets.&lt;/big&gt;

Si vous considérez un wikilivre terminé, n'hésitez pas à le déplacer vers la [[:Catégorie:Livres terminés]]

[[Catégorie:Livres par niveau d'avancement]]</text>
      <sha1>5jmpa0x4who5mhx6351mtphz3j09u6t</sha1>
    </revision>
    <revision>
      <id>772296</id>
      <parentid>772295</parentid>
      <timestamp>2026-09-16T14:19:25Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772296</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="307" sha1="eqvi81q8hcp6r2ak01u80stomn69xvl" xml:space="preserve">&lt;big&gt;Cette page de Wikilivres regroupe tous les livres considérés comme non terminés ainsi que les minilivres manifestement incomplets.&lt;/big&gt;

Si vous considérez un wikilivre terminé, n'hésitez pas à le déplacer vers la [[:Catégorie:Livres terminés]]

[[Catégorie:Livres par niveau d'avancement]]</text>
      <sha1>eqvi81q8hcp6r2ak01u80stomn69xvl</sha1>
    </revision>
  </page>
  <page>
    <title>Catégorie:Minilivres</title>
    <ns>14</ns>
    <id>11936</id>
    <revision>
      <id>772285</id>
      <parentid>772258</parentid>
      <timestamp>2026-09-16T14:01:20Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772285</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="202" sha1="eiiezunr0hifellai08aws0d4jhrql5" xml:space="preserve">

[[Catégorie:Livres par niveau d'avancement]]
&lt;big&gt;&lt;big&gt;Cette page de Wikilivres reprend la catégorie de tous les minilivres, c'est-à-dire tous les livres écrits sur une seule page web.&lt;/big&gt;&lt;/big&gt;</text>
      <sha1>eiiezunr0hifellai08aws0d4jhrql5</sha1>
    </revision>
    <revision>
      <id>772286</id>
      <parentid>772285</parentid>
      <timestamp>2026-09-16T14:01:39Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772286</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="208" sha1="h351fmwf1zgnurphm854yqt2dbpnlmn" xml:space="preserve">

[[Catégorie:Livres par niveau d'avancement]]
'''&lt;big&gt;&lt;big&gt;Cette page de Wikilivres reprend la catégorie de tous les minilivres, c'est-à-dire tous les livres écrits sur une seule page web.&lt;/big&gt;&lt;/big&gt;'''</text>
      <sha1>h351fmwf1zgnurphm854yqt2dbpnlmn</sha1>
    </revision>
    <revision>
      <id>772287</id>
      <parentid>772286</parentid>
      <timestamp>2026-09-16T14:02:18Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772287</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="202" sha1="eiiezunr0hifellai08aws0d4jhrql5" xml:space="preserve">

[[Catégorie:Livres par niveau d'avancement]]
&lt;big&gt;&lt;big&gt;Cette page de Wikilivres reprend la catégorie de tous les minilivres, c'est-à-dire tous les livres écrits sur une seule page web.&lt;/big&gt;&lt;/big&gt;</text>
      <sha1>eiiezunr0hifellai08aws0d4jhrql5</sha1>
    </revision>
    <revision>
      <id>772292</id>
      <parentid>772287</parentid>
      <timestamp>2026-09-16T14:08:01Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772292</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="224" sha1="khlpx6zrvug3utzrj12hv1ei7gw3piu" xml:space="preserve">&lt;noinclude&gt;&lt;big&gt;&lt;big&gt;Cette page de Wikilivres reprend la catégorie de tous les minilivres, c'est-à-dire tous les livres écrits sur une seule page web.&lt;/big&gt;&lt;/big&gt;&lt;noinclude/&gt;

[[Catégorie:Livres par niveau d'avancement]]</text>
      <sha1>khlpx6zrvug3utzrj12hv1ei7gw3piu</sha1>
    </revision>
    <revision>
      <id>772293</id>
      <parentid>772292</parentid>
      <timestamp>2026-09-16T14:09:05Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772293</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="224" sha1="8r1qvnfu8d0yy319bvhkrolv1dx8402" xml:space="preserve">&lt;noinclude&gt;&lt;big&gt;&lt;big&gt;Cette page de Wikilivres reprend la catégorie de tous les minilivres, c'est-à-dire tous les livres écrits sur une seule page web.&lt;/big&gt;&lt;/big&gt;&lt;/noinclude&gt;

[[Catégorie:Livres par niveau d'avancement]]</text>
      <sha1>8r1qvnfu8d0yy319bvhkrolv1dx8402</sha1>
    </revision>
  </page>
  <page>
    <title>Catégorie:Livres par titre</title>
    <ns>14</ns>
    <id>12058</id>
    <revision>
      <id>772298</id>
      <parentid>546407</parentid>
      <timestamp>2026-09-16T14:24:35Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772298</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="119" sha1="57v0tvmxmdc0vvx47k24olhduias6cc" xml:space="preserve">&lt;big&gt;Cette page de Wikilivres rassemble tous les livres existants par ordre alphabétique.&lt;/big&gt;

[[Catégorie:Livres]]</text>
      <sha1>57v0tvmxmdc0vvx47k24olhduias6cc</sha1>
    </revision>
  </page>
  <page>
    <title>Wikilivres:Tous les livres</title>
    <ns>4</ns>
    <id>14152</id>
    <revision>
      <id>772288</id>
      <parentid>772265</parentid>
      <timestamp>2026-09-16T14:03:33Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772288</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2712" sha1="2dxnb248w5iz4k7v544fl2qjr5mon6m" xml:space="preserve">&lt;big&gt;Cette page présente tous les livres disponibles sur Wikilivres, y compris les ébauches et les livres en cours d'écriture&lt;/big&gt;

N'hésitez pas à poursuivre l'écriture ou à améliorer les livres en cours de création. Un Wiki est fait pour cela. Si vous le désirez, vous pouvez aussi contacter les autres personnes qui ont contribué à la rédaction de l'ouvrage. Cela peut se faire en cliquant sur l'onglet « Voir l'historique » des pages de présentations.

[[Fichier:Pedia-shelf-1.jpg|right|250px]]
__NOEDITSECTION__
La bibliothèque contient [[Spécial:Statistics|{{NUMBEROFARTICLES}}]] pages réparties en [[:Catégorie:Livres par titre|{{formatnum:{{NUMBEROFBOOKS}}}} livres]], dont [[:Catégorie:Livres avec version PDF|{{PAGESINCATEGORY:Livres avec version PDF}}]] téléchargeables en PDF.

{{message|clear=left|style=margin:0.2em 0;|Il existe, pour le moment, deux systèmes d'indexation internes pour trouver du contenu :
* Le [[#Tous les livres par catégorie|système de catégories]] {{100}}. La quasi-intégralité des livres peuvent être trouvés via ce système.
* La [[#Tous les livres selon la classification décimale universelle|classification décimale universelle]] {{25}}, utilisée dans les bibliothèques. Hélas, beaucoup de livres ne sont pas encore rangés selon cette classification, préférez pour le moment la première méthode ou la [[Wikilivres:Rechercher un livre|recherche de livre]]. 
}}

== Tous les livres par catégorie ==

{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |[[Fichier:Book_icon.png|lien=Wikilivres:Tous_les_livres|100x100px]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Histoire|Histoire]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Technologie|Technologie]]
* [[:Catégorie:Informatique|Informatique]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
|}

&lt;div class=&quot;flex-content&quot;&gt;

&lt;div class=&quot;flex-content-half&quot;&gt;
&lt;div class=&quot;headerbleu&quot;&gt;Livres par thème&lt;/div&gt;
&lt;categorytree hideroot=&quot;on&quot; mode=&quot;pages&quot; style=&quot;border:1px solid #A0A0A0; padding:0.7ex; padding-right:1em;&quot;&gt;Livres par thème&lt;/categorytree&gt;
&lt;/div&gt;

&lt;div class=&quot;flex-content-half&quot;&gt;
&lt;div class=&quot;headerbleu&quot;&gt;Livres par niveau d'avancement&lt;/div&gt;
&lt;categorytree hideroot=&quot;on&quot; mode=&quot;pages&quot; style=&quot;border:1px solid #A0A0A0; padding:0.7ex;&quot;&gt;Livres par niveau d'avancement&lt;/categorytree&gt;
&lt;/div&gt;

&lt;/div&gt;

== Tous les livres selon la classification décimale universelle ==

{{:Wikilivres:CDU}}

[[Catégorie:Wikilivres]]</text>
      <sha1>2dxnb248w5iz4k7v544fl2qjr5mon6m</sha1>
    </revision>
    <revision>
      <id>772297</id>
      <parentid>772288</parentid>
      <timestamp>2026-09-16T14:22:47Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772297</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2823" sha1="pushaa9f62uuavpp29kh8nwsf0vswa0" xml:space="preserve">&lt;big&gt;Cette page présente tous les livres disponibles sur Wikilivres, y compris les [[b:fr:Catégorie:Ébauches sans ressources suggérées|ébauches]] et les [[b:fr:Catégorie:Livres en cours de rédaction|livres en cours de rédaction]].&lt;/big&gt;

N'hésitez pas à poursuivre l'écriture ou à améliorer les livres en cours de création. Un Wiki est fait pour cela. Si vous le désirez, vous pouvez aussi contacter les autres personnes qui ont contribué à la rédaction de l'ouvrage. Cela peut se faire en cliquant sur l'onglet « Voir l'historique » des pages de présentations.

[[Fichier:Pedia-shelf-1.jpg|right|250px]]
__NOEDITSECTION__
La bibliothèque contient [[Spécial:Statistics|{{NUMBEROFARTICLES}}]] pages réparties en [[:Catégorie:Livres par titre|{{formatnum:{{NUMBEROFBOOKS}}}} livres]], dont [[:Catégorie:Livres avec version PDF|{{PAGESINCATEGORY:Livres avec version PDF}}]] téléchargeables en PDF.

{{message|clear=left|style=margin:0.2em 0;|Il existe, pour le moment, deux systèmes d'indexation internes pour trouver du contenu :
* Le [[#Tous les livres par catégorie|système de catégories]] {{100}}. La quasi-intégralité des livres peuvent être trouvés via ce système.
* La [[#Tous les livres selon la classification décimale universelle|classification décimale universelle]] {{25}}, utilisée dans les bibliothèques. Hélas, beaucoup de livres ne sont pas encore rangés selon cette classification, préférez pour le moment la première méthode ou la [[Wikilivres:Rechercher un livre|recherche de livre]]. 
}}

== Tous les livres par catégorie ==

{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |[[Fichier:Book_icon.png|lien=Wikilivres:Tous_les_livres|100x100px]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Histoire|Histoire]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Technologie|Technologie]]
* [[:Catégorie:Informatique|Informatique]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
|}

&lt;div class=&quot;flex-content&quot;&gt;

&lt;div class=&quot;flex-content-half&quot;&gt;
&lt;div class=&quot;headerbleu&quot;&gt;Livres par thème&lt;/div&gt;
&lt;categorytree hideroot=&quot;on&quot; mode=&quot;pages&quot; style=&quot;border:1px solid #A0A0A0; padding:0.7ex; padding-right:1em;&quot;&gt;Livres par thème&lt;/categorytree&gt;
&lt;/div&gt;

&lt;div class=&quot;flex-content-half&quot;&gt;
&lt;div class=&quot;headerbleu&quot;&gt;Livres par niveau d'avancement&lt;/div&gt;
&lt;categorytree hideroot=&quot;on&quot; mode=&quot;pages&quot; style=&quot;border:1px solid #A0A0A0; padding:0.7ex;&quot;&gt;Livres par niveau d'avancement&lt;/categorytree&gt;
&lt;/div&gt;

&lt;/div&gt;

== Tous les livres selon la classification décimale universelle ==

{{:Wikilivres:CDU}}

[[Catégorie:Wikilivres]]</text>
      <sha1>pushaa9f62uuavpp29kh8nwsf0vswa0</sha1>
    </revision>
    <revision>
      <id>772300</id>
      <parentid>772297</parentid>
      <timestamp>2026-09-16T14:31:28Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772300</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2901" sha1="lvpn4pw4w0dkc7fllmghxx03eauf60y" xml:space="preserve">&lt;big&gt;Cette page présente tous les livres disponibles sur Wikilivres, y compris les [[b:fr:Catégorie:Ébauches sans ressources suggérées|ébauches]], les [[b:fr:Catégorie:Livres en cours de rédaction|livres en cours de rédaction]], et les  [[b:fr:Catégorie:Feuilles volantes|feuilles volantes]]&lt;/big&gt;

N'hésitez pas à poursuivre l'écriture ou à améliorer les livres ou les pages en cours de création. Un Wiki est fait pour cela. Si vous le désirez, vous pouvez aussi contacter les personnes qui ont déjà contribué sur les pages que vous voulez modifier. Cela peut se faire en cliquant sur l'onglet « Voir l'historique » des pages en question.

[[Fichier:Pedia-shelf-1.jpg|right|250px]]
__NOEDITSECTION__
La bibliothèque contient [[Spécial:Statistics|{{NUMBEROFARTICLES}}]] pages réparties en [[:Catégorie:Livres par titre|{{formatnum:{{NUMBEROFBOOKS}}}} livres]], dont [[:Catégorie:Livres avec version PDF|{{PAGESINCATEGORY:Livres avec version PDF}}]] téléchargeables en PDF.

{{message|clear=left|style=margin:0.2em 0;|Il existe, pour le moment, deux systèmes d'indexation internes pour trouver du contenu :
* Le [[#Tous les livres par catégorie|système de catégories]] {{100}}. La quasi-intégralité des livres peuvent être trouvés via ce système.
* La [[#Tous les livres selon la classification décimale universelle|classification décimale universelle]] {{25}}, utilisée dans les bibliothèques. Hélas, beaucoup de livres ne sont pas encore rangés selon cette classification, préférez pour le moment la première méthode ou la [[Wikilivres:Rechercher un livre|recherche de livre]]. 
}}

== Tous les livres par catégorie ==

{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |[[Fichier:Book_icon.png|lien=Wikilivres:Tous_les_livres|100x100px]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Histoire|Histoire]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Technologie|Technologie]]
* [[:Catégorie:Informatique|Informatique]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
|}

&lt;div class=&quot;flex-content&quot;&gt;

&lt;div class=&quot;flex-content-half&quot;&gt;
&lt;div class=&quot;headerbleu&quot;&gt;Livres par thème&lt;/div&gt;
&lt;categorytree hideroot=&quot;on&quot; mode=&quot;pages&quot; style=&quot;border:1px solid #A0A0A0; padding:0.7ex; padding-right:1em;&quot;&gt;Livres par thème&lt;/categorytree&gt;
&lt;/div&gt;

&lt;div class=&quot;flex-content-half&quot;&gt;
&lt;div class=&quot;headerbleu&quot;&gt;Livres par niveau d'avancement&lt;/div&gt;
&lt;categorytree hideroot=&quot;on&quot; mode=&quot;pages&quot; style=&quot;border:1px solid #A0A0A0; padding:0.7ex;&quot;&gt;Livres par niveau d'avancement&lt;/categorytree&gt;
&lt;/div&gt;

&lt;/div&gt;

== Tous les livres selon la classification décimale universelle ==

{{:Wikilivres:CDU}}

[[Catégorie:Wikilivres]]</text>
      <sha1>lvpn4pw4w0dkc7fllmghxx03eauf60y</sha1>
    </revision>
    <revision>
      <id>772306</id>
      <parentid>772300</parentid>
      <timestamp>2026-09-16T14:38:07Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772306</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2922" sha1="o2fy30zuff2nwp9g2xuz81j5jypekj4" xml:space="preserve">&lt;big&gt;Cette page présente [[:Catégorie:Livres par titre|tous les livres]] disponibles sur Wikilivres, y compris les [[:Catégorie:Ébauches sans ressources suggérées|ébauches]], les [[:Catégorie:Livres en cours de rédaction|livres en cours de rédaction]], et les  [[:Catégorie:Feuilles volantes|feuilles volantes]]&lt;/big&gt;

N'hésitez pas à poursuivre l'écriture ou à améliorer les livres ou les pages en cours de création. Un Wiki est fait pour cela. Si vous le désirez, vous pouvez aussi contacter les personnes qui ont déjà contribué sur les pages que vous voulez modifier. Cela peut se faire en cliquant sur l'onglet « Voir l'historique » des pages en question.

[[Fichier:Pedia-shelf-1.jpg|right|250px]]
__NOEDITSECTION__
La bibliothèque contient [[Spécial:Statistics|{{NUMBEROFARTICLES}}]] pages réparties en [[:Catégorie:Livres par titre|{{formatnum:{{NUMBEROFBOOKS}}}} livres]], dont [[:Catégorie:Livres avec version PDF|{{PAGESINCATEGORY:Livres avec version PDF}}]] téléchargeables en PDF.

{{message|clear=left|style=margin:0.2em 0;|Il existe, pour le moment, deux systèmes d'indexation internes pour trouver du contenu :
* Le [[#Tous les livres par catégorie|système de catégories]] {{100}}. La quasi-intégralité des livres peuvent être trouvés via ce système.
* La [[#Tous les livres selon la classification décimale universelle|classification décimale universelle]] {{25}}, utilisée dans les bibliothèques. Hélas, beaucoup de livres ne sont pas encore rangés selon cette classification, préférez pour le moment la première méthode ou la [[Wikilivres:Rechercher un livre|recherche de livre]]. 
}}

== Tous les livres par catégorie ==

{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |[[Fichier:Book_icon.png|lien=Wikilivres:Tous_les_livres|100x100px]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Histoire|Histoire]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Technologie|Technologie]]
* [[:Catégorie:Informatique|Informatique]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
|}

&lt;div class=&quot;flex-content&quot;&gt;

&lt;div class=&quot;flex-content-half&quot;&gt;
&lt;div class=&quot;headerbleu&quot;&gt;Livres par thème&lt;/div&gt;
&lt;categorytree hideroot=&quot;on&quot; mode=&quot;pages&quot; style=&quot;border:1px solid #A0A0A0; padding:0.7ex; padding-right:1em;&quot;&gt;Livres par thème&lt;/categorytree&gt;
&lt;/div&gt;

&lt;div class=&quot;flex-content-half&quot;&gt;
&lt;div class=&quot;headerbleu&quot;&gt;Livres par niveau d'avancement&lt;/div&gt;
&lt;categorytree hideroot=&quot;on&quot; mode=&quot;pages&quot; style=&quot;border:1px solid #A0A0A0; padding:0.7ex;&quot;&gt;Livres par niveau d'avancement&lt;/categorytree&gt;
&lt;/div&gt;

&lt;/div&gt;

== Tous les livres selon la classification décimale universelle ==

{{:Wikilivres:CDU}}

[[Catégorie:Wikilivres]]</text>
      <sha1>o2fy30zuff2nwp9g2xuz81j5jypekj4</sha1>
    </revision>
    <revision>
      <id>772355</id>
      <parentid>772306</parentid>
      <timestamp>2026-09-17T11:33:27Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772355</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2923" sha1="7kzs33px01dr46xor4b8m1uri309012" xml:space="preserve">&lt;big&gt;Cette page présente [[:Catégorie:Livres par titre|tous les livres]] disponibles sur Wikilivres, y compris les [[:Catégorie:Ébauches sans ressources suggérées|ébauches]], les [[:Catégorie:Livres en cours de rédaction|livres en cours de rédaction]], et les  [[:Catégorie:Feuilles volantes|feuilles volantes]].&lt;/big&gt;

N'hésitez pas à poursuivre l'écriture ou à améliorer les livres ou les pages en cours de création. Un Wiki est fait pour cela. Si vous le désirez, vous pouvez aussi contacter les personnes qui ont déjà contribué sur les pages que vous voulez modifier. Cela peut se faire en cliquant sur l'onglet « Voir l'historique » des pages en question.

[[Fichier:Pedia-shelf-1.jpg|right|250px]]
__NOEDITSECTION__
La bibliothèque contient [[Spécial:Statistics|{{NUMBEROFARTICLES}}]] pages réparties en [[:Catégorie:Livres par titre|{{formatnum:{{NUMBEROFBOOKS}}}} livres]], dont [[:Catégorie:Livres avec version PDF|{{PAGESINCATEGORY:Livres avec version PDF}}]] téléchargeables en PDF.

{{message|clear=left|style=margin:0.2em 0;|Il existe, pour le moment, deux systèmes d'indexation internes pour trouver du contenu :
* Le [[#Tous les livres par catégorie|système de catégories]] {{100}}. La quasi-intégralité des livres peuvent être trouvés via ce système.
* La [[#Tous les livres selon la classification décimale universelle|classification décimale universelle]] {{25}}, utilisée dans les bibliothèques. Hélas, beaucoup de livres ne sont pas encore rangés selon cette classification, préférez pour le moment la première méthode ou la [[Wikilivres:Rechercher un livre|recherche de livre]]. 
}}

== Tous les livres par catégorie ==

{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |[[Fichier:Book_icon.png|lien=Wikilivres:Tous_les_livres|100x100px]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Histoire|Histoire]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Technologie|Technologie]]
* [[:Catégorie:Informatique|Informatique]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
|}

&lt;div class=&quot;flex-content&quot;&gt;

&lt;div class=&quot;flex-content-half&quot;&gt;
&lt;div class=&quot;headerbleu&quot;&gt;Livres par thème&lt;/div&gt;
&lt;categorytree hideroot=&quot;on&quot; mode=&quot;pages&quot; style=&quot;border:1px solid #A0A0A0; padding:0.7ex; padding-right:1em;&quot;&gt;Livres par thème&lt;/categorytree&gt;
&lt;/div&gt;

&lt;div class=&quot;flex-content-half&quot;&gt;
&lt;div class=&quot;headerbleu&quot;&gt;Livres par niveau d'avancement&lt;/div&gt;
&lt;categorytree hideroot=&quot;on&quot; mode=&quot;pages&quot; style=&quot;border:1px solid #A0A0A0; padding:0.7ex;&quot;&gt;Livres par niveau d'avancement&lt;/categorytree&gt;
&lt;/div&gt;

&lt;/div&gt;

== Tous les livres selon la classification décimale universelle ==

{{:Wikilivres:CDU}}

[[Catégorie:Wikilivres]]</text>
      <sha1>7kzs33px01dr46xor4b8m1uri309012</sha1>
    </revision>
  </page>
  <page>
    <title>Catégorie:Ébauches sans ressources suggérées</title>
    <ns>14</ns>
    <id>14828</id>
    <revision>
      <id>772294</id>
      <parentid>749936</parentid>
      <timestamp>2026-09-16T14:15:58Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772294</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="253" sha1="b6mogm8s01v5y22thfpxooselmbe34e" xml:space="preserve">__HIDDENCAT__
&lt;big&gt;&lt;big&gt;Cette page de Wikilivres affiche la liste des livres à l'état d'ébauche.&lt;/big&gt;&lt;/big&gt;

Elle rassemble automatiquement toutes les pages sur lesquelles on a placé le modèle {{m|ébauche}}.

[[Catégorie:Maintenance Wikilivres]]</text>
      <sha1>b6mogm8s01v5y22thfpxooselmbe34e</sha1>
    </revision>
  </page>
  <page>
    <title>Accueil</title>
    <ns>0</ns>
    <id>15169</id>
    <revision>
      <id>772266</id>
      <parentid>761424</parentid>
      <timestamp>2026-09-16T11:59:34Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>Suite à la prise de décision https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil</comment>
      <origin>772266</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3861" sha1="76frcq0wh32s4glb4jbvpy7zw0mwhwj" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;
{| class=&quot;flexible&quot; style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;
|
&lt;div style=&quot;width:auto; text-align:center;&quot;&gt;

&lt;div id=&quot;mf-banner1&quot; style=&quot;font-size:162%; padding:0.1em;&quot;&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]],&lt;/div&gt;
&lt;div id=&quot;mf-banner2&quot; style=&quot;font-size:95%; margin-top:0.2em;&quot;&gt;{{Bloc|La bibliothèque}} {{Bloc|de livres pédagogiques libres}} {{Bloc|que chacun peut améliorer.}}&lt;/div&gt;
&lt;div style=&quot;text-align:center; font-size:95%; margin:0;&quot;&gt;[[Wikilivres:Présentation|Wikilivres ?]] • [[Wikilivres|Aide]] • [[Wikilivres:Accueil|Communauté]]&lt;/div&gt;
&lt;div id=&quot;pagecount&quot; style=&quot;font-size:85%;&quot;&gt;[[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres]] contenant [[Special:Allpages|{{NUMBEROFARTICLES}} pages]].&lt;/div&gt;
&lt;/div&gt;
| style=&quot;width:55%; font-size:95%;&quot; |
{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |
[[Fichier:Book icon.png|100px|link=Wikilivres:Tous les livres]]
| style=&quot;width:25%;&quot; |
* [[Wikilivre:Livres terminés|Livres terminés]]
* [[:Catégorie:Minilivres|Mini Livres]]
* [[Wikilivres:
* [[Wikilivres:Tous les livres|Tous les livres]] 
|}
|}
&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;

&lt;div class=&quot;livre-accueil-section2&quot; style=&quot;clear:both; margin:33px 0px 33px 0px; padding:0px;&quot;&gt;
{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}
&lt;/div&gt;

&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>76frcq0wh32s4glb4jbvpy7zw0mwhwj</sha1>
    </revision>
    <revision>
      <id>772267</id>
      <parentid>772266</parentid>
      <timestamp>2026-09-16T12:01:25Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>Retouche modification précédente</comment>
      <origin>772267</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3848" sha1="cuduig3m0jkmi3s54jklaiy67w9whvl" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;
{| class=&quot;flexible&quot; style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;
|
&lt;div style=&quot;width:auto; text-align:center;&quot;&gt;

&lt;div id=&quot;mf-banner1&quot; style=&quot;font-size:162%; padding:0.1em;&quot;&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]],&lt;/div&gt;
&lt;div id=&quot;mf-banner2&quot; style=&quot;font-size:95%; margin-top:0.2em;&quot;&gt;{{Bloc|La bibliothèque}} {{Bloc|de livres pédagogiques libres}} {{Bloc|que chacun peut améliorer.}}&lt;/div&gt;
&lt;div style=&quot;text-align:center; font-size:95%; margin:0;&quot;&gt;[[Wikilivres:Présentation|Wikilivres ?]] • [[Wikilivres|Aide]] • [[Wikilivres:Accueil|Communauté]]&lt;/div&gt;
&lt;div id=&quot;pagecount&quot; style=&quot;font-size:85%;&quot;&gt;[[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres]] contenant [[Special:Allpages|{{NUMBEROFARTICLES}} pages]].&lt;/div&gt;
&lt;/div&gt;
| style=&quot;width:55%; font-size:95%;&quot; |
{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |
[[Fichier:Book icon.png|100px|link=Wikilivres:Tous les livres]]
| style=&quot;width:25%;&quot; |
*  [[:Catégorie:Livres terminés|Livres terminés]]
* [[:Catégorie:Minilivres|Mini Livres]]
* [[Wikilivres:Tous les livres|Tous les livres]] 
|}
|}
&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;

&lt;div class=&quot;livre-accueil-section2&quot; style=&quot;clear:both; margin:33px 0px 33px 0px; padding:0px;&quot;&gt;
{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}
&lt;/div&gt;

&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>cuduig3m0jkmi3s54jklaiy67w9whvl</sha1>
    </revision>
    <revision>
      <id>772269</id>
      <parentid>772267</parentid>
      <timestamp>2026-09-16T12:27:38Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>Mise en page</comment>
      <origin>772269</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3706" sha1="4n81gc238utk8c4epixvxd5ql6vr9ks" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;
{| class=&quot;flexible&quot; style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;
|&lt;div style=&quot;width:auto; text-align:center;&quot;&gt;
&lt;div id=&quot;mf-banner1&quot; style=&quot;font-size:162%; padding:0.1em;&quot;&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]]&lt;/div&gt;
&lt;div id=&quot;mf-banner2&quot; style=&quot;font-size:95%; margin-top:0.2em;&quot;&gt;{{Bloc|La bibliothèque}} {{Bloc|de livres pédagogiques libres}} {{Bloc|que chacun peut enrichir et améliorer.}}&lt;/div&gt;
&lt;div style=&quot;text-align:center; font-size:95%; margin:0;&quot;&gt;[[Wikilivres:Présentation|Wikilivres ?]] • [[Wikilivres|Aide]] • [[Wikilivres:Accueil|Communauté]]&lt;/div&gt;
&lt;div id=&quot;pagecount&quot; style=&quot;font-size:85%;&quot;&gt;[[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres]] contenant [[Special:Allpages|{{NUMBEROFARTICLES}} pages]].&lt;/div&gt;&lt;/div&gt;

{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] - [[:Catégorie:Minilivres|Mini Livres]] - [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}
|}

&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;

&lt;div class=&quot;livre-accueil-section2&quot; style=&quot;clear:both; margin:33px 0px 33px 0px; padding:0px;&quot;&gt;
{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}
&lt;/div&gt;

&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>4n81gc238utk8c4epixvxd5ql6vr9ks</sha1>
    </revision>
    <revision>
      <id>772272</id>
      <parentid>772269</parentid>
      <timestamp>2026-09-16T12:43:33Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>Mise en page</comment>
      <origin>772272</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3730" sha1="7nylgvwy71j4f759ak4lwio173pgnyn" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;
{| class=&quot;flexible&quot; style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;
|&lt;div style=&quot;width:auto; text-align:center;&quot;&gt;
&lt;div id=&quot;mf-banner1&quot; style=&quot;font-size:162%; padding:0.1em;&quot;&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]]&lt;/div&gt;
&lt;div id=&quot;mf-banner2&quot; style=&quot;font-size:95%; margin-top:0.2em;&quot;&gt;{{Bloc|La bibliothèque}} {{Bloc|de livres pédagogiques libres}} {{Bloc|que chacun peut enrichir et améliorer.}}&lt;/div&gt;
&lt;div style=&quot;text-align:center; font-size:95%; margin:0;&quot;&gt;[[Wikilivres:Présentation|Wikilivres ?]] • [[Wikilivres|Aide]] • [[Wikilivres:Accueil|Communauté]]&lt;/div&gt;
&lt;div id=&quot;pagecount&quot; style=&quot;font-size:85%;&quot;&gt;[[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres]] contenant [[Special:Allpages|{{NUMBEROFARTICLES}} pages]].&lt;/div&gt;&lt;/div&gt;
{{Centrer|Découvertes}}
{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] - [[:Catégorie:Minilivres|Mini Livres]] - [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}
|}

&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;

&lt;div class=&quot;livre-accueil-section2&quot; style=&quot;clear:both; margin:33px 0px 33px 0px; padding:0px;&quot;&gt;
{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}
&lt;/div&gt;

&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>7nylgvwy71j4f759ak4lwio173pgnyn</sha1>
    </revision>
    <revision>
      <id>772279</id>
      <parentid>772272</parentid>
      <timestamp>2026-09-16T13:21:04Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>mise en page</comment>
      <origin>772279</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3757" sha1="pu76a7vn7oobkndm85ya1uw300mbi4e" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;
{| class=&quot;flexible&quot; style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;
|&lt;div style=&quot;width:auto; text-align:center;&quot;&gt;
&lt;div id=&quot;mf-banner1&quot; style=&quot;font-size:162%; padding:0.1em;&quot;&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]]&lt;/div&gt;
&lt;div id=&quot;mf-banner2&quot; style=&quot;font-size:95%; margin-top:0.2em;&quot;&gt;{{Bloc|La bibliothèque}} {{Bloc|de livres pédagogiques libres}} {{Bloc|que chacun peut enrichir et améliorer.}}&lt;/div&gt;
&lt;div style=&quot;text-align:center; font-size:95%; margin:0;&quot;&gt;[[Wikilivres:Présentation|Wikilivres ?]] • [[Wikilivres|Aide]] • [[Wikilivres:Accueil|Communauté]]&lt;/div&gt;
&lt;div id=&quot;pagecount&quot; style=&quot;font-size:85%;&quot;&gt;[[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres]] contenant [[Special:Allpages|{{NUMBEROFARTICLES}} pages]].&lt;/div&gt;&lt;/div&gt;


{{Centrer|'''Découverte de la bibliothèque'''}}
{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] - [[:Catégorie:Minilivres|Mini Livres]] - [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}
|}

&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;

&lt;div class=&quot;livre-accueil-section2&quot; style=&quot;clear:both; margin:33px 0px 33px 0px; padding:0px;&quot;&gt;
{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}
&lt;/div&gt;

&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>pu76a7vn7oobkndm85ya1uw300mbi4e</sha1>
    </revision>
    <revision>
      <id>772280</id>
      <parentid>772279</parentid>
      <timestamp>2026-09-16T13:22:35Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>Mise en page</comment>
      <origin>772280</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3795" sha1="b88a4005g7zxe6ywxnucspby88p4lq8" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;
{| class=&quot;flexible&quot; style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;
|&lt;div style=&quot;width:auto; text-align:center;&quot;&gt;
&lt;div id=&quot;mf-banner1&quot; style=&quot;font-size:162%; padding:0.1em;&quot;&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]]&lt;/div&gt;
&lt;div id=&quot;mf-banner2&quot; style=&quot;font-size:95%; margin-top:0.2em;&quot;&gt;{{Bloc|La bibliothèque}} {{Bloc|de livres pédagogiques libres}} {{Bloc|que chacun peut enrichir et améliorer.}}&lt;/div&gt;
&lt;div style=&quot;text-align:center; font-size:95%; margin:0;&quot;&gt;[[Wikilivres:Présentation|À propos de Wikilivres ?]] • [[Wikilivres|Besoin d'aide ?]] • [[Wikilivres:Accueil|Rejoindre la ommunauté ?]]&lt;/div&gt;
&lt;div id=&quot;pagecount&quot; style=&quot;font-size:85%;&quot;&gt;[[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres]] contenant [[Special:Allpages|{{NUMBEROFARTICLES}} pages]].&lt;/div&gt;&lt;/div&gt;


{{Centrer|'''Découverte de la bibliothèque'''}}
{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] - [[:Catégorie:Minilivres|Mini Livres]] - [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}
|}

&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;

&lt;div class=&quot;livre-accueil-section2&quot; style=&quot;clear:both; margin:33px 0px 33px 0px; padding:0px;&quot;&gt;
{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}
&lt;/div&gt;

&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>b88a4005g7zxe6ywxnucspby88p4lq8</sha1>
    </revision>
    <revision>
      <id>772281</id>
      <parentid>772280</parentid>
      <timestamp>2026-09-16T13:53:29Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>Mise en page et simplification par usage du Wikicode</comment>
      <origin>772281</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3398" sha1="bt3in1dbknyq4ms6nqq3natfe44kpsi" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;

{{Centrer|&lt;big&gt;&lt;big&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]]!&lt;/big&gt;&lt;/big&gt;}}

{{Centrer|{{Bloc|Une bibliothèque}} {{Bloc|de [[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres pédagogiques]] libres d'usage}} {{Bloc|et de [[Special:Allpages|{{NUMBEROFARTICLES}} pages web]]}} {{Bloc|que chacun peut enrichir et améliorer.}}}}

{{Centrer|[[Wikilivres|Besoin d'aide ?]] • [[Wikilivres:Accueil|Rejoindre la communauté ?]] • [[Wikilivres:Présentation|En savoir plus sur Wikilivres ?]]}}


{{Centrer|'''Découvrir la bibliothèque'''}}

{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] • [[:Catégorie:Minilivres|Mini Livres]] •  [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}

{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}


&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;


&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>bt3in1dbknyq4ms6nqq3natfe44kpsi</sha1>
    </revision>
    <revision>
      <id>772282</id>
      <parentid>772281</parentid>
      <timestamp>2026-09-16T13:55:22Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772282</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3399" sha1="24ouqfv54qz4necomgrce2a7iosfy6u" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;

{{Centrer|&lt;big&gt;&lt;big&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres ]]!&lt;/big&gt;&lt;/big&gt;}}

{{Centrer|{{Bloc|Une bibliothèque}} {{Bloc|de [[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres pédagogiques]] libres d'usage}} {{Bloc|et de [[Special:Allpages|{{NUMBEROFARTICLES}} pages web]]}} {{Bloc|que chacun peut enrichir et améliorer.}}}}

{{Centrer|[[Wikilivres|Besoin d'aide ?]] • [[Wikilivres:Accueil|Rejoindre la communauté ?]] • [[Wikilivres:Présentation|En savoir plus sur Wikilivres ?]]}}


{{Centrer|'''Découvrir la bibliothèque'''}}

{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] • [[:Catégorie:Minilivres|Mini Livres]] •  [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}

{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}


&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;


&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>24ouqfv54qz4necomgrce2a7iosfy6u</sha1>
    </revision>
    <revision>
      <id>772283</id>
      <parentid>772282</parentid>
      <timestamp>2026-09-16T13:55:53Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772283</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3397" sha1="sy5sovwzfkavqgfxre6shy5c97wgci9" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;

{{Centrer|&lt;big&gt;&lt;big&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]]&lt;/big&gt;&lt;/big&gt;}}

{{Centrer|{{Bloc|Une bibliothèque}} {{Bloc|de [[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres pédagogiques]] libres d'usage}} {{Bloc|et de [[Special:Allpages|{{NUMBEROFARTICLES}} pages web]]}} {{Bloc|que chacun peut enrichir et améliorer.}}}}

{{Centrer|[[Wikilivres|Besoin d'aide ?]] • [[Wikilivres:Accueil|Rejoindre la communauté ?]] • [[Wikilivres:Présentation|En savoir plus sur Wikilivres ?]]}}


{{Centrer|'''Découvrir la bibliothèque'''}}

{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] • [[:Catégorie:Minilivres|Mini Livres]] •  [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}

{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}


&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;


&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>sy5sovwzfkavqgfxre6shy5c97wgci9</sha1>
    </revision>
    <revision>
      <id>772304</id>
      <parentid>772283</parentid>
      <timestamp>2026-09-16T14:35:26Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>Mise en page</comment>
      <origin>772304</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3390" sha1="qkg0vryj0vm5s77d403b06tkvsgmuyu" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;

{{Centrer|&lt;big&gt;&lt;big&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]]&lt;/big&gt;&lt;/big&gt;}}

{{Centrer|{{Bloc|Une bibliothèque}} {{Bloc|de [[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres pédagogiques]] libres d'usage}} {{Bloc|et un site web de {{NUMBEROFARTICLES}} pages web}} {{Bloc|que chacun peut enrichir et améliorer.}}}}


{{Centrer|[[Wikilivres|Besoin d'aide ?]] • [[Wikilivres:Accueil|Rejoindre la communauté ?]] • [[Wikilivres:Présentation|En savoir plus sur Wikilivres ?]]}}


{{Centrer|'''Découvrir la bibliothèque'''}}

{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] • [[:Catégorie:Minilivres|Mini Livres]] •  [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}


{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}


&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;


&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>qkg0vryj0vm5s77d403b06tkvsgmuyu</sha1>
    </revision>
    <revision>
      <id>772305</id>
      <parentid>772304</parentid>
      <timestamp>2026-09-16T14:37:02Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <origin>772305</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3357" sha1="496wg6iizpt598eei1mg061k8adflzj" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;

{{Centrer|&lt;big&gt;&lt;big&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]]&lt;/big&gt;&lt;/big&gt;}}

{{Centrer|{{Bloc|Une bibliothèque}} {{Bloc|de {{NUMBEROFBOOKS}} livres pédagogiques libres d'usage}} {{Bloc|et un site web de {{NUMBEROFARTICLES}} pages web}} {{Bloc|que chacun peut enrichir et améliorer.}}}}


{{Centrer|[[Wikilivres|Besoin d'aide ?]] • [[Wikilivres:Accueil|Rejoindre la communauté ?]] • [[Wikilivres:Présentation|En savoir plus sur Wikilivres ?]]}}


{{Centrer|'''Découvrir la bibliothèque'''}}

{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] • [[:Catégorie:Minilivres|Mini Livres]] •  [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}


{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}


&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;


&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>496wg6iizpt598eei1mg061k8adflzj</sha1>
    </revision>
    <revision>
      <id>772307</id>
      <parentid>772305</parentid>
      <timestamp>2026-09-16T14:42:17Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>rationnalisation des liens</comment>
      <origin>772307</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3345" sha1="sifk4tqcp08av8s267sok5xkcfrqe4w" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;

{{Centrer|&lt;big&gt;&lt;big&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]]&lt;/big&gt;&lt;/big&gt;}}

{{Centrer|{{Bloc|Une bibliothèque}} {{Bloc|de {{NUMBEROFBOOKS}} livres pédagogiques libres d'usage}} {{Bloc|et un site web de {{NUMBEROFARTICLES}} pages web}} {{Bloc|que chacun peut enrichir et améliorer.}}}}


{{Centrer|[[Aide:Accueil|Besoin d'aide ?]] • [[Wikilivres:Accueil|Rejoindre la communauté ?]] • [[Wikilivres|En savoir plus sur Wikilivres ?]]}}


{{Centrer|'''Découvrir la bibliothèque'''}}

{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] • [[:Catégorie:Minilivres|Mini Livres]] •  [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}


{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}


&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;


&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>sifk4tqcp08av8s267sok5xkcfrqe4w</sha1>
    </revision>
    <revision>
      <id>772309</id>
      <parentid>772307</parentid>
      <timestamp>2026-09-16T14:46:14Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>mise en page</comment>
      <origin>772309</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3341" sha1="nxqo8do2i1fa5wxwp3w7gwi2erqzej0" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;

{{Centrer|&lt;big&gt;&lt;big&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]]&lt;/big&gt;&lt;/big&gt;}}

{{Centrer|{{Bloc|Une bibliothèque}} {{Bloc|de {{NUMBEROFBOOKS}} livres pédagogiques libres d'usage}} {{Bloc|et un site web de {{NUMBEROFARTICLES}} pages web}} {{Bloc|que chacun peut enrichir et améliorer.}}}}


{{Centrer|[[Aide:Accueil|Besoin d'aide ?]] • [[Wikilivres:Accueil|Rejoindre la communauté ?]] • [[Wikilivres|En savoir plus sur Wikilivres ?]]}}


{{Centrer|'''Découvrir la bibliothèque'''}}

{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] - [[:Catégorie:Minilivres|Mini Livres]] -  [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}


{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}


&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;


&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>nxqo8do2i1fa5wxwp3w7gwi2erqzej0</sha1>
    </revision>
    <revision>
      <id>772356</id>
      <parentid>772309</parentid>
      <timestamp>2026-09-17T11:39:20Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>Mise en page</comment>
      <origin>772356</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3345" sha1="ba3kazc6rwtwmbt5bk8j8htxgida9kn" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;

{{Centrer|&lt;big&gt;&lt;big&gt;&lt;big&gt;Bienvenue sur &lt;/big&gt;&lt;/big&gt;&lt;/big&gt;}}

{{Centrer|{{Bloc|Une bibliothèque}} {{Bloc|de {{NUMBEROFBOOKS}} livres pédagogiques libres d'usage}} {{Bloc|et un site web de {{NUMBEROFARTICLES}} pages web}} {{Bloc|que chacun peut enrichir et améliorer.}}}}


{{Centrer|[[Wikilivres:Présentation|Présentation]] • [[Aide:Accueil|Besoin d'aide ?]] • [[Wikilivres:Accueil|Rejoindre la communauté ?]] • [[Wikilivres|En savoir plus ?]]}}


{{Centrer|'''Découvrir la bibliothèque'''}}

{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] - [[:Catégorie:Minilivres|Mini Livres]] -  [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}


{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}


&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;


&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>ba3kazc6rwtwmbt5bk8j8htxgida9kn</sha1>
    </revision>
    <revision>
      <id>772357</id>
      <parentid>772356</parentid>
      <timestamp>2026-09-17T11:40:59Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>Oups...</comment>
      <origin>772357</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3355" sha1="omzmfh3mwstlgvn2eexelpb8t9uo7ym" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;

{{Centrer|&lt;big&gt;&lt;big&gt;&lt;big&gt;Bienvenue sur Wikilivres&lt;/big&gt;&lt;/big&gt;&lt;/big&gt;}}

{{Centrer|{{Bloc|Une bibliothèque}} {{Bloc|de {{NUMBEROFBOOKS}} livres pédagogiques libres d'usage}} {{Bloc|et un site web de {{NUMBEROFARTICLES}} pages web}} {{Bloc|que chacun peut enrichir et améliorer.}}}}


{{Centrer|[[Wikilivres:Présentation|Présentation]] • [[Aide:Accueil|Besoin d'aide ?]] • [[Wikilivres:Accueil|Rejoindre la communauté ?]] • [[Wikilivres|En savoir plus ?]]}}


{{Centrer|'''Découvrir la bibliothèque'''}}

{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] - [[:Catégorie:Minilivres|Mini Livres]] -  [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}


{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}


&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;


&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>omzmfh3mwstlgvn2eexelpb8t9uo7ym</sha1>
    </revision>
    <revision>
      <id>772358</id>
      <parentid>772357</parentid>
      <timestamp>2026-09-17T11:52:47Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>Mise en page</comment>
      <origin>772358</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3364" sha1="ej9eh231gvgvyrer3ltkym9tbzv20z6" xml:space="preserve">&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;

{{Centrer|&lt;big&gt;&lt;big&gt;&lt;big&gt;Bienvenue sur Wikilivres&lt;/big&gt;&lt;/big&gt;&lt;/big&gt;}}

{{Centrer|{{Bloc|Une bibliothèque}} {{Bloc|de {{NUMBEROFBOOKS}} livres pédagogiques libres d'usage}} {{Bloc|et un site web de {{NUMBEROFARTICLES}} pages web}} {{Bloc|que chacun peut enrichir et améliorer.}}}}


{{Centrer|[[Wikilivres:Présentation|Découvrir Wikilivres ?]] • [[Aide:Accueil|Besoin d'aide ?]] • [[Wikilivres:Accueil|Rejoindre la communauté ?]] • [[Wikilivres|En savoir plus ?]]}}


{{Centrer|'''Parcourir la bibliothèque'''}}

{{Centrer|&lt;big&gt;[[:Catégorie:Livres terminés|Livres terminés]] - [[:Catégorie:Minilivres|Mini Livres]] -  [[Wikilivres:Tous les livres|Tous les livres]]&lt;/big&gt;}}


{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}


&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;


&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés]] :''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>ej9eh231gvgvyrer3ltkym9tbzv20z6</sha1>
    </revision>
  </page>
  <page>
    <title>Discussion utilisateur:Lionel Scheepmans</title>
    <ns>3</ns>
    <id>42849</id>
    <revision>
      <id>772270</id>
      <parentid>772234</parentid>
      <timestamp>2026-09-16T12:36:00Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>/* Décision:Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil */ Réponse</comment>
      <origin>772270</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="25105" sha1="f615sezl5zchui2729it060dwwk5xt0" xml:space="preserve">Je vous écoute {{sourire}}

Bonjour, Lionel Scheepmans, et [[Wikilivres:Bienvenue|bienvenue]] sur Wikilivres. En cas de besoin, voici quelques pages qui devraient vous être utiles si vous n'êtes pas familiers des [[w:Wiki|wikis]] :

*[[Aide:Comment modifier une page|Comment modifier une page]]
*[[Aide:Accueil|Sommaire des pages d'aide]]
*[[Wikilivres:Conventions typographiques|Conventions typographiques]]
*[[Wikilivres:Règles|Règles et recommandations]]
*[[Wikilivres:Bac à sable|Le bac à sable pour essayer la syntaxe wiki]]

Pour signer vos messages en page de discussion (on ne [[Wikilivres:Règles#Rédaction collective|signe pas]] les livres) utilisez quatre tildes (&lt;nowiki&gt;~~~~&lt;/nowiki&gt;); cela produira automatiquement votre nom et la date de publication. Si vous avez besoin d'aide, demandez à la communauté au [[Wikilivres:Le Bistro|Bistro]] ou sur ma propre page de discussion, ou bien consultez la [[Wikilivres:Foire aux questions|FAQ]] . Bonne continuation.
[[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 10 décembre 2014 à 13:43 (CET)

== Copie-Coller ==
Bonjour, il faut éviter ce type de transfert, il serait plutôt préférable de demande une [[Spécial:Import|importation]] à un administrateur. Cordialement. [[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 10 décembre 2014 à 13:43 (CET)
:Bonjour[[Utilisateur:FrankyLeRoutier|Franky]] et merci pour ton message d'accueil. Malheureusement, je ne comprends pas ce que tu veux dire dans ton deuxième message ci-dessus ? Peux-tu être plus explicite ? Bien à toi, [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 10 décembre 2014 à 14:17 (CET)
::Rebonjour Lionel, par exemple si un des auteurs de cette [[Clefs pour mieux comprendre le monde et participer à son évolution|page]] effectue un copie-coller de son contenu sur Wikiversité sans faire l'importation des [[:w:Aide:Historique|historiques]], il ne respectera pas les droits des contributeurs puisque l'article source sera supprimés. Amicalement. [[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 11 décembre 2014 à 05:22 (CET)
:::Oui effectivement [[Utilisateur:FrankyLeRoutier|Franky]], je comprends mieux ta remarque. Je pensais que tu faisait allusion au copier coller d'un livre au départ d'un fichier de son ordinateur vers une page wiki comme ce fut le cas du texte en question. J'étais déjà en train de rêver à un outils d'importation accessible uniquement par les administrateurs et qui permettrait d'importer directement la mise en page d'un PDF par exemple. Ce n'étais qu'un rêve malheureusement.
:::Donc oui, je prends bonne note qu'il faudra contacter un bibliothécaire si jamais le déplacement du texte s'avérait nécessaire. Je pense l'avoir déjà fait au sujet d'un modèle ou l'autre. Merci pour ta remarque et bonne journée à toi. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 11 décembre 2014 à 09:10 (CET)
::::Bonjour Lionel, pour l'importation externe aux projets de la fondation, il y a cette page ; [[:s:Aide:Créer un fichier DjVu]] sur Wikisource. Cordialement. [[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 15 décembre 2014 à 01:56 (CET)

== Édition d'historique ==
Bonjour, j'apprécie sincèrement ta présence sur le bistro, mais est-ce que tu vois sur ton navigateur [//fr.wikibooks.org/w/index.php?title=Wikilivres:Le_Bistro/2015&amp;action=edit&amp;oldid=460231 le bandeau rouge &quot;Vous êtes en train de modifier une ancienne version de cette page&quot;]. Je me pose la question car sur la Wikiversité tu avais aussi blanchi de cette façon les éditions postérieures à celle que tu regardais. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 7 février 2015 à 21:05 (CET)
:Oups désolé [[Utilisateur:JackPotte|JackPotte]]. Non je ne me souviens pas d'avoir vu apparaître ce bandeau dans mon navigateur Firerfox. Mais ma mémoire n'est pas fiable :/ . J'avoue que [[v:Wikiversité:La_salle_café/février_2015#Pas_de_notifications|j'ai des problèmes avec l'organisation des bistros]]. Faudrait que je comprenne un jour le pourquoi du comment. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 7 février 2015 à 21:38 (CET)
::J'utilise aussi [[Firefox]] en habillage Monobook. D'ailleurs j'avais publié un &quot;best of&quot; des modules testés sur [[Firefox/Extensions]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 7 février 2015 à 22:20 (CET)
:::J'aime pas Monobook. C'est pas très joli et puis comme c'est pas le skin par défaut, c'est la meilleurs façon de ne pas voir les bug visible au grand publique. Merci pour le lien et bonne soirée, [[Utilisateur:JackPotte|JackPotte]], [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 7 février 2015 à 22:48 (CET)

== Matthius ==

Je te remercie pour tes messages sur la page de discussion WP de Matthius. Mais par contre, attention : &quot;''Personne n'est censé venir y intervenir sans votre demande''&quot; rétablit, de facto, le droit d'auteur. Et d'ailleurs comment peux-tu être aussi sûr que le déblocage se fera demain ? [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 mai 2023 à 19:25 (CEST)

:Par ce que l'administrateur qui l'a bloqué m'a donné son aval. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 mai 2023 à 19:37 (CEST)
::Ne trouves-tu pas sage d'attendre l'avis d'au moins un autre administrateur ? [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 mai 2023 à 19:56 (CEST)
:::Pas moins sage que le blocage qui s'est fait sous l'avis d'un seul administrateur. Ici, nous sommes deux sur trois actifs pour le moment. Et même trois comme je viens de le découvrir. As-tu quelque chose de personnelle contre cet utilisateur [[Utilisateur:Fourmidable|Fourmidable]]  ? Ne trouves-tu pas que chacun a le droit à une seconde chance ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 mai 2023 à 17:51 (CEST)
::::Il y a urgence à bloquer un contributeur quand celui-ci parasite les débats avec des modifications non constructives comme des blanchiments de pages et des tentatives d'enfouir les discussions. Par contre, il n'y a aucune urgence à le débloquer : nous pouvons prendre le temps d'en discuter tranquillement. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 27 mai 2023 à 20:23 (CEST)
:::::Je n'ai pas été contre le premier blocage. Et tu ne réponds pas à mes questions. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 mai 2023 à 23:29 (CEST)
::::::Et au fait [[Utilisateur:Fourmidable|Fourmidable]], t'es pas en examen toi ? T'en es où dans tes études ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 mai 2023 à 23:38 (CEST)
:::::::J'ai répété maintes fois que je n'avais rien contre ce contributeur en dehors de Wikilivres, c'est très bien qu'il diffuse ses idées. On peut lui donner une seconde chance sur Wikilivres mais il faut qu'il montre de son côté un peu de bonne foi, ce que j'ai toujours du mal à voir chez lui. Souvent, ses propos sont incohérents : ex. : [https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Lionel_Scheepmans&amp;diff=next&amp;oldid=204511533 je ne vois pas de prise de position] -&gt; [https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Lionel_Scheepmans&amp;diff=next&amp;oldid=204524525 Ils prennent position effectivement] -&gt; [https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Lionel_Scheepmans&amp;diff=next&amp;oldid=204568649 Je pense que ce livrel est neutre]. Honnêtement, je ne sais pas à quoi il joue. De mon côté : licence finie, je vais peut-être passer un ou deux rattrapages pour faire le plein de points et ainsi espérer une mention. Je suis encore pour un mois au conservatoire, dont l'année se termine à la toute fin juin, voire début juillet pour les concerts. Du 9 au 31 juillet, je serai tout seul en cure thermale, nous pourrons faire plus facilement des visios (le reste de l'année je vis chez mes parents et ceux-ci sont assez hostiles à mes activités sur les wikis, c'est aussi pour ça que j'ai du mal à me rendre disponible). Je me prépare à un master Didactique des langues, à Paris, Lyon ou Montpellier. {{Sourire}} [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 28 mai 2023 à 19:23 (CEST)
::::::::Chouette programme ! Et bravo déjà pour le parcours effectué. Concernant Matthius, J'espère que le temps nous aidera à mieux le comprendre. Les sujet qu'il traite sont fondamentaux et pas si loin de mes propres intérêts. Raisons pour laquelle je m'y investi. J'espère qu'il aura intégré les règles de savoir-vivre. À suivre. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 mai 2023 à 12:55 (CEST)
:::::::::Honnêtement, je ne vois toujours pas comment on pourrait transformer ces ouvrages pour les rendre réellement utiles et valables. Mais si tu te sens inspiré, NHP à faire une proposition. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 30 mai 2023 à 11:20 (CEST)
::::::::::Le mot utilité me fait penser à l'utilitarisme, une autre philosophie politique critiquée en sciences sociales [[w:Revue_du_MAUSS|Revue du MAUSS]]. Quoi qu'il arrive, le travail de réécriture sera profitable pour l'auteur et intéressant pour moi. Il est possible qu'en fin de compte les livres ne soient pas comme tu voudrais qu'il le soit, et ce sera à la communauté d'en déterminer leurs validités pour l'espace principale. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 30 mai 2023 à 12:15 (CEST)
: J'ai revu [https://archive.org/download/WikiBooks/Economie-petits%20Wikibooks.odt l'économie pour les petits]. Je pense qu'il est neutre même si je ne suis pas centriste. C'était le plus neutre des livrels qui ont été enlevés de Wikibooks. Pour l'instant, c'est le seul livrel qui pourrait être remis sur wikibooks. En plus il est court. Pourrez-vous m'aider à le remettre sur wikibooks ?--[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 30 janvier 2024 à 05:51 (CET)
::Bonjour [[Utilisateur:Matthius|Matthius]]. Content de voir que tu consacres toujours du temps dans ta participation au projet Wikiversité. Je ne vois pas comment t'aider à replacer ton travail dans l'espace principale de Wikilivres si ce n'est en t'encourageant à le faire. Idéalement, il faudrait que ta nouvelle version du livre apparaisse sur [[Utilisateur:Matthius/Économie Petits|cette page où l'on a déplacé l'ancienne jugée inadéquate]] grâce à la fonction « diff » il sera ainsi facile de voir toutes les modifications que apportées à l'ouvrage. Par la suite, tu peux laisser un message au bistro pour informer la communauté des changements et de ton intention de replacer l'ouvrage dans l'espace principale. Suite aux discussions, on pourra alors faire les démarches nécessaires. N'oublie pas de signer tes messages, cela facilite les échanges. Bien à toi, [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt;
:::Bonjour Lionel, j'espère que tu n'es plus trop fâché contre moi ^^', et je te remercie encore pour ton suivi. J'ai donné ma critique sur le Bistro. Bien à vous deux, --[[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 5 février 2024 à 07:27 (CET)
:::Salut @[[Utilisateur:Fourmidable|Fourmidable]]. Non je ne suis pas fâche. J'étais juste un peu irrité par ta façon de t'exprimé durant une période ou je te sentais particulièrement actif dans la sélection des contenus dans les projets wikimédia. Comme je suis plutôt en faveur de l'inclusion et l'encourragement er l'inclusion, avec certaines limites que j'ai déjà exprimé avec mes votes en faveur de certaines &quot;suppression&quot;. Un terme inadéqua puisque rien n'est supprimé des serveurs en vérité, mais juste retirer de l'espace visible pas internaute. Raison pour laquelle, je préfère déplacer le contenu vers l'espace utilisateur de l'auteur en prenant soin d'empêcher le référencement pas les moteurs de recherches, alors qu'il me semble que les espace utilisateur ne le sont pas.
:::Mais donc, contend.de reprendre contact avec toi Hérison. J'espère que tout se passe bien dans ta vie et tes études ! Bien à toi. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 5 février 2024 à 11:11 (CET)
Je propose mes livrels à la recréation. Je pense que Fourmidable n'est pas habitué à lire l'économie réelle. Je lui ai montré que valeur et monnaie sont liés et que la finance comme entité humaine c'est utilisé. Fourmidable n'agit plus maintenant.--[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 26 avril 2024 à 10:40 (CEST)

Cela fait 7 mois que mes livrels sont proposés à la publication dans wikibooks. Je comprends que vous vouliez garder les contributeurs à wikibooks, puisque vous êtes dorénavant le seul à participer à wikibooks pour mes livrels. Jacques Cheminade fait peur à Jackpotte. Pourtant Cheminade dit que ceux qui ont le plus peur de lui ne l'écoutent pas. Fourmidable est lui mandaté pour supprimer, pas pour restaurer. Sinon il aurait négocié avec moi une modification des livrels que j'ai finalement pu réaliser grâce à vous. Que pensez-vous faire ? --[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 7 décembre 2024 à 21:30 (CET)

:Bonsoir @[[Utilisateur:Matthius|Matthius]]. Je n'ai pas de réponse à votre question. Si vous voulez restaurer vos livres, il suffit de les déplacer dans l'espace principale en les renomant. On verra par la suite les réaction des quelques membres de notre communauté. Cette discussion dure depuis longtemps et pour le dire franchement, j'y ai déjà consacré beaucoup de temps que je ne suis pas prête à consacrer aujourd'hui. Il y a un moment ou, en tant que bénévole, on se fatigue de faire la médiation entre deux personnes qui n'arrive pas à s'entendre. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 8 décembre 2024 à 01:56 (CET)
:::Je vais les déplacer mais ça risque de réveiller quelqu'un. Ceci écrit, les livrels ont été neutralisés. Y a-t-il un moyen de garder l'historique ?
::::Quand on dit dêplacer, en réalité On change le nom de la page et rien d'autre pour qu'elle figure dans ce ca dans l'espaxe de nom principalr et plus dans l'espace de nom utilisateur. Une page renomée garde tout son historique. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 8 décembre 2024 à 10:50 (CET)
:Pour ceux qui m'ont défendu : [http://web.archive.org/web/20260517193237/https://www.informalibre.com/Des-contributeurs-de-Wikipedia-sont-devenus-des-agents-des-lobbies-50 www.informalibre.com/Des-contributeurs-de-Wikipedia-sont-devenus-des-agents-des-lobbies-50]--[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 17 mai 2026 à 21:37 (CEST)

== Pages orphelines ==

Bonjour,


Il semble que tu as perdu quelques pages dans les pages orphelines. Pourrais tu les garder sur ta Page d’utilisateur pour les sortir des pages orphelines. Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 18 février 2026 à 13:19 (CET)

:@[[Utilisateur:Xhungab|Xhungab]]. Si tu n'indiques pas la personne à qui tu adresses ton message, tu risques de rester sans réponse. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 18 février 2026 à 15:13 (CET)
::L'idéal est de la notifier en la faisant apparaitre en bleu grâce au menu de l'éditeur visuel qui affiche un petit bonhomme avec un + en haut à sa gauche.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 18 février 2026 à 15:16 (CET)
:::Oups. Oublie les messages précésent. Je croyais qu'on était dans le bistro... [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 18 février 2026 à 15:24 (CET)

* [[Le mouvement Wikimedia/Préface|Préface]]
* [[Le mouvement Wikimédia/Deuxième partie :Cosmographie du mouvement Wikimédia|Deuxième partie :Cosmographie du mouvement Wikimédia]]
* [[Le mouvement Wikimédia/Première partie : La naissance du mouvement Wikimédia|Première partie : La naissance du mouvement Wikimédia]]
* [[Le mouvement Wikimédia2/Version imprimable|Version imprimable]]
* [[Projet:KarthaLab|KarthaLab]]
* [[Le mouvement Wikimédia/Livre audio|Le mouvement Wikimédia : Livre audio]]

== You may be an eligible candidate for the U4C election ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;
Greetings,

The [[m:Special:MyLanguage/Universal_Code_of_Conduct/Coordinating_Committee|Universal Code of Conduct Coordinating Committee (U4C)]] seeks candidates for the 2026 election. The U4C is the global committee responsible for overseeing enforcement of the [[foundation:Special:MyLanguage/Policy:Universal Code of Conduct|Universal Code of Conduct]]. Elections are held annually, if elected a committee member serves for two years.

This year the U4C requires candidates to hold administrator rights on at least one wiki, which is why you are being contacted as you appear to hold this right. There are other requirements, such as candidates must be at least 18 years old and may not be employed by the Wikimedia Foundation or other related chapters and affiliates. You can find more information in the [[m:Special:MyLanguage/Universal_Code_of_Conduct/Coordinating_Committee/Election/2026#Call_for_Candidates|call for candidates on Meta-wiki]]. Additionally, the committee's working language is English; some ability to communicate in English is required.

The election opens on 18 May, if you are eligible and interested you have until 10 May to submit your candidacy. There will week between for candidates to answer questions from the community. Voting takes place privately in [[m:Special:MyLanguage/SecurePoll|SecurePoll]], successful candidates must receive at least 60% support. More information is available on [[m:Special:MyLanguage/Universal_Code_of_Conduct/Coordinating_Committee/Election/2026|the 2026 Elections page]], including timelines and other candidacy information. If you read over the material and consider yourself qualified, please consider submitting your name to run for the committee. If you think someone else in your community might be interested and qualified, please encourage them to run.

In partnership with the U4C -- [[m:User:Keegan (WMF)|Keegan (WMF)]] ([[m:User_talk:Keegan (WMF)|talk]]) 28 avril 2026 à 20:33 (CEST) &lt;/div&gt;
&lt;!-- Message envoyé par User:Keegan (WMF)@metawiki en utilisant la liste sur https://meta.wikimedia.org/w/index.php?title=User:Keegan_(WMF)/test&amp;oldid=30471754 --&gt;

== '''Décision''':Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

Petites nouvelles de wikibook. la décision a été prise. On a donc besoin d'un administrateur pour conclure ce travail.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''

'''Décision pour : [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']'''

Résultats : 3 + Pour, un Neutre Neutre et un - Contre soit 60 % de + Pour par rapport au total des votes exprimés : la proposition est adoptée. Quelques propositions de reformulations et de nuances ont été faites qui pourront être prise en compte. Cdlt, VIGNERON * discut. 13 septembre 2026 à 18:27 (CEST)

Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 14 septembre 2026 à 20:35 (CEST)

:Salut @[[Utilisateur:Xhungab|Xhungab]]. Content de voir que la décision est prise. Tu peux déjà créer la page dont tu nous as parlé. Je m'occuperai de la page d'accueil, mercredi. Bien à toi,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 15 septembre 2026 à 02:18 (CEST)
::J'ai créer la page :
::* '''[https://fr.wikibooks.org/wiki/coulisses Les coulisses de Wikibook]''' 
::Il faudra peut-être la protéger pour que seuls les administrateurs puissent la modifier.
::.
::Il suffit de recopier dans la vitrine par la page ci-dessous.
::https://fr.wikibooks.org/wiki/Utilisateur:Xhungab
::.
::Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 15 septembre 2026 à 09:47 (CEST)
:::OK. Je fais ça ce soir ou demain. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 15 septembre 2026 à 10:53 (CEST)
::::@[[Utilisateur:Xhungab|Xhungab]]. Je suis en train de modifier la page d'accueil.
::::Je prends quelques initiatives pour simplifier les choses et éviter un doublon entre la page Coulisse que tu avais créée et que j'ai supprimée et la page [[Wikilivres:Tous les livres]]. Comme cette dernière page existait déjà et qu'elle est modifiable par les contributeurs confirmés, ce que tu es certainement, sens-toi libre de modifier celle-ci. Sa page de discussion sera là pour discuter de tes changements si besoin.
::::Je t'invite aussi à t'exprimer sur la [[Discussion:Accueil|page de discussion de la page d'accueil]] si tu as des choses à dire suite à mes changements.
::::Bien à toi,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 septembre 2026 à 14:36 (CEST)</text>
      <sha1>f615sezl5zchui2729it060dwwk5xt0</sha1>
    </revision>
    <revision>
      <id>772273</id>
      <parentid>772270</parentid>
      <timestamp>2026-09-16T12:48:52Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>/* Décision:Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil */ Réponse</comment>
      <origin>772273</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="25343" sha1="n8tv94tuxx9w8ue9uqgvrmp3br36nqg" xml:space="preserve">Je vous écoute {{sourire}}

Bonjour, Lionel Scheepmans, et [[Wikilivres:Bienvenue|bienvenue]] sur Wikilivres. En cas de besoin, voici quelques pages qui devraient vous être utiles si vous n'êtes pas familiers des [[w:Wiki|wikis]] :

*[[Aide:Comment modifier une page|Comment modifier une page]]
*[[Aide:Accueil|Sommaire des pages d'aide]]
*[[Wikilivres:Conventions typographiques|Conventions typographiques]]
*[[Wikilivres:Règles|Règles et recommandations]]
*[[Wikilivres:Bac à sable|Le bac à sable pour essayer la syntaxe wiki]]

Pour signer vos messages en page de discussion (on ne [[Wikilivres:Règles#Rédaction collective|signe pas]] les livres) utilisez quatre tildes (&lt;nowiki&gt;~~~~&lt;/nowiki&gt;); cela produira automatiquement votre nom et la date de publication. Si vous avez besoin d'aide, demandez à la communauté au [[Wikilivres:Le Bistro|Bistro]] ou sur ma propre page de discussion, ou bien consultez la [[Wikilivres:Foire aux questions|FAQ]] . Bonne continuation.
[[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 10 décembre 2014 à 13:43 (CET)

== Copie-Coller ==
Bonjour, il faut éviter ce type de transfert, il serait plutôt préférable de demande une [[Spécial:Import|importation]] à un administrateur. Cordialement. [[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 10 décembre 2014 à 13:43 (CET)
:Bonjour[[Utilisateur:FrankyLeRoutier|Franky]] et merci pour ton message d'accueil. Malheureusement, je ne comprends pas ce que tu veux dire dans ton deuxième message ci-dessus ? Peux-tu être plus explicite ? Bien à toi, [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 10 décembre 2014 à 14:17 (CET)
::Rebonjour Lionel, par exemple si un des auteurs de cette [[Clefs pour mieux comprendre le monde et participer à son évolution|page]] effectue un copie-coller de son contenu sur Wikiversité sans faire l'importation des [[:w:Aide:Historique|historiques]], il ne respectera pas les droits des contributeurs puisque l'article source sera supprimés. Amicalement. [[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 11 décembre 2014 à 05:22 (CET)
:::Oui effectivement [[Utilisateur:FrankyLeRoutier|Franky]], je comprends mieux ta remarque. Je pensais que tu faisait allusion au copier coller d'un livre au départ d'un fichier de son ordinateur vers une page wiki comme ce fut le cas du texte en question. J'étais déjà en train de rêver à un outils d'importation accessible uniquement par les administrateurs et qui permettrait d'importer directement la mise en page d'un PDF par exemple. Ce n'étais qu'un rêve malheureusement.
:::Donc oui, je prends bonne note qu'il faudra contacter un bibliothécaire si jamais le déplacement du texte s'avérait nécessaire. Je pense l'avoir déjà fait au sujet d'un modèle ou l'autre. Merci pour ta remarque et bonne journée à toi. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 11 décembre 2014 à 09:10 (CET)
::::Bonjour Lionel, pour l'importation externe aux projets de la fondation, il y a cette page ; [[:s:Aide:Créer un fichier DjVu]] sur Wikisource. Cordialement. [[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 15 décembre 2014 à 01:56 (CET)

== Édition d'historique ==
Bonjour, j'apprécie sincèrement ta présence sur le bistro, mais est-ce que tu vois sur ton navigateur [//fr.wikibooks.org/w/index.php?title=Wikilivres:Le_Bistro/2015&amp;action=edit&amp;oldid=460231 le bandeau rouge &quot;Vous êtes en train de modifier une ancienne version de cette page&quot;]. Je me pose la question car sur la Wikiversité tu avais aussi blanchi de cette façon les éditions postérieures à celle que tu regardais. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 7 février 2015 à 21:05 (CET)
:Oups désolé [[Utilisateur:JackPotte|JackPotte]]. Non je ne me souviens pas d'avoir vu apparaître ce bandeau dans mon navigateur Firerfox. Mais ma mémoire n'est pas fiable :/ . J'avoue que [[v:Wikiversité:La_salle_café/février_2015#Pas_de_notifications|j'ai des problèmes avec l'organisation des bistros]]. Faudrait que je comprenne un jour le pourquoi du comment. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 7 février 2015 à 21:38 (CET)
::J'utilise aussi [[Firefox]] en habillage Monobook. D'ailleurs j'avais publié un &quot;best of&quot; des modules testés sur [[Firefox/Extensions]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 7 février 2015 à 22:20 (CET)
:::J'aime pas Monobook. C'est pas très joli et puis comme c'est pas le skin par défaut, c'est la meilleurs façon de ne pas voir les bug visible au grand publique. Merci pour le lien et bonne soirée, [[Utilisateur:JackPotte|JackPotte]], [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 7 février 2015 à 22:48 (CET)

== Matthius ==

Je te remercie pour tes messages sur la page de discussion WP de Matthius. Mais par contre, attention : &quot;''Personne n'est censé venir y intervenir sans votre demande''&quot; rétablit, de facto, le droit d'auteur. Et d'ailleurs comment peux-tu être aussi sûr que le déblocage se fera demain ? [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 mai 2023 à 19:25 (CEST)

:Par ce que l'administrateur qui l'a bloqué m'a donné son aval. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 mai 2023 à 19:37 (CEST)
::Ne trouves-tu pas sage d'attendre l'avis d'au moins un autre administrateur ? [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 mai 2023 à 19:56 (CEST)
:::Pas moins sage que le blocage qui s'est fait sous l'avis d'un seul administrateur. Ici, nous sommes deux sur trois actifs pour le moment. Et même trois comme je viens de le découvrir. As-tu quelque chose de personnelle contre cet utilisateur [[Utilisateur:Fourmidable|Fourmidable]]  ? Ne trouves-tu pas que chacun a le droit à une seconde chance ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 mai 2023 à 17:51 (CEST)
::::Il y a urgence à bloquer un contributeur quand celui-ci parasite les débats avec des modifications non constructives comme des blanchiments de pages et des tentatives d'enfouir les discussions. Par contre, il n'y a aucune urgence à le débloquer : nous pouvons prendre le temps d'en discuter tranquillement. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 27 mai 2023 à 20:23 (CEST)
:::::Je n'ai pas été contre le premier blocage. Et tu ne réponds pas à mes questions. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 mai 2023 à 23:29 (CEST)
::::::Et au fait [[Utilisateur:Fourmidable|Fourmidable]], t'es pas en examen toi ? T'en es où dans tes études ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 mai 2023 à 23:38 (CEST)
:::::::J'ai répété maintes fois que je n'avais rien contre ce contributeur en dehors de Wikilivres, c'est très bien qu'il diffuse ses idées. On peut lui donner une seconde chance sur Wikilivres mais il faut qu'il montre de son côté un peu de bonne foi, ce que j'ai toujours du mal à voir chez lui. Souvent, ses propos sont incohérents : ex. : [https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Lionel_Scheepmans&amp;diff=next&amp;oldid=204511533 je ne vois pas de prise de position] -&gt; [https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Lionel_Scheepmans&amp;diff=next&amp;oldid=204524525 Ils prennent position effectivement] -&gt; [https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Lionel_Scheepmans&amp;diff=next&amp;oldid=204568649 Je pense que ce livrel est neutre]. Honnêtement, je ne sais pas à quoi il joue. De mon côté : licence finie, je vais peut-être passer un ou deux rattrapages pour faire le plein de points et ainsi espérer une mention. Je suis encore pour un mois au conservatoire, dont l'année se termine à la toute fin juin, voire début juillet pour les concerts. Du 9 au 31 juillet, je serai tout seul en cure thermale, nous pourrons faire plus facilement des visios (le reste de l'année je vis chez mes parents et ceux-ci sont assez hostiles à mes activités sur les wikis, c'est aussi pour ça que j'ai du mal à me rendre disponible). Je me prépare à un master Didactique des langues, à Paris, Lyon ou Montpellier. {{Sourire}} [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 28 mai 2023 à 19:23 (CEST)
::::::::Chouette programme ! Et bravo déjà pour le parcours effectué. Concernant Matthius, J'espère que le temps nous aidera à mieux le comprendre. Les sujet qu'il traite sont fondamentaux et pas si loin de mes propres intérêts. Raisons pour laquelle je m'y investi. J'espère qu'il aura intégré les règles de savoir-vivre. À suivre. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 mai 2023 à 12:55 (CEST)
:::::::::Honnêtement, je ne vois toujours pas comment on pourrait transformer ces ouvrages pour les rendre réellement utiles et valables. Mais si tu te sens inspiré, NHP à faire une proposition. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 30 mai 2023 à 11:20 (CEST)
::::::::::Le mot utilité me fait penser à l'utilitarisme, une autre philosophie politique critiquée en sciences sociales [[w:Revue_du_MAUSS|Revue du MAUSS]]. Quoi qu'il arrive, le travail de réécriture sera profitable pour l'auteur et intéressant pour moi. Il est possible qu'en fin de compte les livres ne soient pas comme tu voudrais qu'il le soit, et ce sera à la communauté d'en déterminer leurs validités pour l'espace principale. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 30 mai 2023 à 12:15 (CEST)
: J'ai revu [https://archive.org/download/WikiBooks/Economie-petits%20Wikibooks.odt l'économie pour les petits]. Je pense qu'il est neutre même si je ne suis pas centriste. C'était le plus neutre des livrels qui ont été enlevés de Wikibooks. Pour l'instant, c'est le seul livrel qui pourrait être remis sur wikibooks. En plus il est court. Pourrez-vous m'aider à le remettre sur wikibooks ?--[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 30 janvier 2024 à 05:51 (CET)
::Bonjour [[Utilisateur:Matthius|Matthius]]. Content de voir que tu consacres toujours du temps dans ta participation au projet Wikiversité. Je ne vois pas comment t'aider à replacer ton travail dans l'espace principale de Wikilivres si ce n'est en t'encourageant à le faire. Idéalement, il faudrait que ta nouvelle version du livre apparaisse sur [[Utilisateur:Matthius/Économie Petits|cette page où l'on a déplacé l'ancienne jugée inadéquate]] grâce à la fonction « diff » il sera ainsi facile de voir toutes les modifications que apportées à l'ouvrage. Par la suite, tu peux laisser un message au bistro pour informer la communauté des changements et de ton intention de replacer l'ouvrage dans l'espace principale. Suite aux discussions, on pourra alors faire les démarches nécessaires. N'oublie pas de signer tes messages, cela facilite les échanges. Bien à toi, [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt;
:::Bonjour Lionel, j'espère que tu n'es plus trop fâché contre moi ^^', et je te remercie encore pour ton suivi. J'ai donné ma critique sur le Bistro. Bien à vous deux, --[[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 5 février 2024 à 07:27 (CET)
:::Salut @[[Utilisateur:Fourmidable|Fourmidable]]. Non je ne suis pas fâche. J'étais juste un peu irrité par ta façon de t'exprimé durant une période ou je te sentais particulièrement actif dans la sélection des contenus dans les projets wikimédia. Comme je suis plutôt en faveur de l'inclusion et l'encourragement er l'inclusion, avec certaines limites que j'ai déjà exprimé avec mes votes en faveur de certaines &quot;suppression&quot;. Un terme inadéqua puisque rien n'est supprimé des serveurs en vérité, mais juste retirer de l'espace visible pas internaute. Raison pour laquelle, je préfère déplacer le contenu vers l'espace utilisateur de l'auteur en prenant soin d'empêcher le référencement pas les moteurs de recherches, alors qu'il me semble que les espace utilisateur ne le sont pas.
:::Mais donc, contend.de reprendre contact avec toi Hérison. J'espère que tout se passe bien dans ta vie et tes études ! Bien à toi. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 5 février 2024 à 11:11 (CET)
Je propose mes livrels à la recréation. Je pense que Fourmidable n'est pas habitué à lire l'économie réelle. Je lui ai montré que valeur et monnaie sont liés et que la finance comme entité humaine c'est utilisé. Fourmidable n'agit plus maintenant.--[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 26 avril 2024 à 10:40 (CEST)

Cela fait 7 mois que mes livrels sont proposés à la publication dans wikibooks. Je comprends que vous vouliez garder les contributeurs à wikibooks, puisque vous êtes dorénavant le seul à participer à wikibooks pour mes livrels. Jacques Cheminade fait peur à Jackpotte. Pourtant Cheminade dit que ceux qui ont le plus peur de lui ne l'écoutent pas. Fourmidable est lui mandaté pour supprimer, pas pour restaurer. Sinon il aurait négocié avec moi une modification des livrels que j'ai finalement pu réaliser grâce à vous. Que pensez-vous faire ? --[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 7 décembre 2024 à 21:30 (CET)

:Bonsoir @[[Utilisateur:Matthius|Matthius]]. Je n'ai pas de réponse à votre question. Si vous voulez restaurer vos livres, il suffit de les déplacer dans l'espace principale en les renomant. On verra par la suite les réaction des quelques membres de notre communauté. Cette discussion dure depuis longtemps et pour le dire franchement, j'y ai déjà consacré beaucoup de temps que je ne suis pas prête à consacrer aujourd'hui. Il y a un moment ou, en tant que bénévole, on se fatigue de faire la médiation entre deux personnes qui n'arrive pas à s'entendre. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 8 décembre 2024 à 01:56 (CET)
:::Je vais les déplacer mais ça risque de réveiller quelqu'un. Ceci écrit, les livrels ont été neutralisés. Y a-t-il un moyen de garder l'historique ?
::::Quand on dit dêplacer, en réalité On change le nom de la page et rien d'autre pour qu'elle figure dans ce ca dans l'espaxe de nom principalr et plus dans l'espace de nom utilisateur. Une page renomée garde tout son historique. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 8 décembre 2024 à 10:50 (CET)
:Pour ceux qui m'ont défendu : [http://web.archive.org/web/20260517193237/https://www.informalibre.com/Des-contributeurs-de-Wikipedia-sont-devenus-des-agents-des-lobbies-50 www.informalibre.com/Des-contributeurs-de-Wikipedia-sont-devenus-des-agents-des-lobbies-50]--[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 17 mai 2026 à 21:37 (CEST)

== Pages orphelines ==

Bonjour,


Il semble que tu as perdu quelques pages dans les pages orphelines. Pourrais tu les garder sur ta Page d’utilisateur pour les sortir des pages orphelines. Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 18 février 2026 à 13:19 (CET)

:@[[Utilisateur:Xhungab|Xhungab]]. Si tu n'indiques pas la personne à qui tu adresses ton message, tu risques de rester sans réponse. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 18 février 2026 à 15:13 (CET)
::L'idéal est de la notifier en la faisant apparaitre en bleu grâce au menu de l'éditeur visuel qui affiche un petit bonhomme avec un + en haut à sa gauche.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 18 février 2026 à 15:16 (CET)
:::Oups. Oublie les messages précésent. Je croyais qu'on était dans le bistro... [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 18 février 2026 à 15:24 (CET)

* [[Le mouvement Wikimedia/Préface|Préface]]
* [[Le mouvement Wikimédia/Deuxième partie :Cosmographie du mouvement Wikimédia|Deuxième partie :Cosmographie du mouvement Wikimédia]]
* [[Le mouvement Wikimédia/Première partie : La naissance du mouvement Wikimédia|Première partie : La naissance du mouvement Wikimédia]]
* [[Le mouvement Wikimédia2/Version imprimable|Version imprimable]]
* [[Projet:KarthaLab|KarthaLab]]
* [[Le mouvement Wikimédia/Livre audio|Le mouvement Wikimédia : Livre audio]]

== You may be an eligible candidate for the U4C election ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;
Greetings,

The [[m:Special:MyLanguage/Universal_Code_of_Conduct/Coordinating_Committee|Universal Code of Conduct Coordinating Committee (U4C)]] seeks candidates for the 2026 election. The U4C is the global committee responsible for overseeing enforcement of the [[foundation:Special:MyLanguage/Policy:Universal Code of Conduct|Universal Code of Conduct]]. Elections are held annually, if elected a committee member serves for two years.

This year the U4C requires candidates to hold administrator rights on at least one wiki, which is why you are being contacted as you appear to hold this right. There are other requirements, such as candidates must be at least 18 years old and may not be employed by the Wikimedia Foundation or other related chapters and affiliates. You can find more information in the [[m:Special:MyLanguage/Universal_Code_of_Conduct/Coordinating_Committee/Election/2026#Call_for_Candidates|call for candidates on Meta-wiki]]. Additionally, the committee's working language is English; some ability to communicate in English is required.

The election opens on 18 May, if you are eligible and interested you have until 10 May to submit your candidacy. There will week between for candidates to answer questions from the community. Voting takes place privately in [[m:Special:MyLanguage/SecurePoll|SecurePoll]], successful candidates must receive at least 60% support. More information is available on [[m:Special:MyLanguage/Universal_Code_of_Conduct/Coordinating_Committee/Election/2026|the 2026 Elections page]], including timelines and other candidacy information. If you read over the material and consider yourself qualified, please consider submitting your name to run for the committee. If you think someone else in your community might be interested and qualified, please encourage them to run.

In partnership with the U4C -- [[m:User:Keegan (WMF)|Keegan (WMF)]] ([[m:User_talk:Keegan (WMF)|talk]]) 28 avril 2026 à 20:33 (CEST) &lt;/div&gt;
&lt;!-- Message envoyé par User:Keegan (WMF)@metawiki en utilisant la liste sur https://meta.wikimedia.org/w/index.php?title=User:Keegan_(WMF)/test&amp;oldid=30471754 --&gt;

== '''Décision''':Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

Petites nouvelles de wikibook. la décision a été prise. On a donc besoin d'un administrateur pour conclure ce travail.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''

'''Décision pour : [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']'''

Résultats : 3 + Pour, un Neutre Neutre et un - Contre soit 60 % de + Pour par rapport au total des votes exprimés : la proposition est adoptée. Quelques propositions de reformulations et de nuances ont été faites qui pourront être prise en compte. Cdlt, VIGNERON * discut. 13 septembre 2026 à 18:27 (CEST)

Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 14 septembre 2026 à 20:35 (CEST)

:Salut @[[Utilisateur:Xhungab|Xhungab]]. Content de voir que la décision est prise. Tu peux déjà créer la page dont tu nous as parlé. Je m'occuperai de la page d'accueil, mercredi. Bien à toi,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 15 septembre 2026 à 02:18 (CEST)
::J'ai créer la page :
::* '''[https://fr.wikibooks.org/wiki/coulisses Les coulisses de Wikibook]''' 
::Il faudra peut-être la protéger pour que seuls les administrateurs puissent la modifier.
::.
::Il suffit de recopier dans la vitrine par la page ci-dessous.
::https://fr.wikibooks.org/wiki/Utilisateur:Xhungab
::.
::Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 15 septembre 2026 à 09:47 (CEST)
:::OK. Je fais ça ce soir ou demain. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 15 septembre 2026 à 10:53 (CEST)
::::@[[Utilisateur:Xhungab|Xhungab]]. Je suis en train de modifier la page d'accueil.
::::Je prends quelques initiatives pour simplifier les choses et éviter un doublon entre la page Coulisse que tu avais créée et que j'ai supprimée et la page [[Wikilivres:Tous les livres]]. Comme cette dernière page existait déjà et qu'elle est modifiable par les contributeurs confirmés, ce que tu es certainement, sens-toi libre de modifier celle-ci. Sa page de discussion sera là pour discuter de tes changements si besoin.
::::Je t'invite aussi à t'exprimer sur la [[Discussion:Accueil|page de discussion de la page d'accueil]] si tu as des choses à dire suite à mes changements.
::::Bien à toi,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 septembre 2026 à 14:36 (CEST)
:::::On voit les choses différemment, mais je pense que tu as fait du bon travail. Merci de m'avoir accordé de ton temps. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 16 septembre 2026 à 14:48 (CEST)</text>
      <sha1>n8tv94tuxx9w8ue9uqgvrmp3br36nqg</sha1>
    </revision>
    <revision>
      <id>772278</id>
      <parentid>772273</parentid>
      <timestamp>2026-09-16T13:18:30Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>/* Décision:Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil */ Réponse</comment>
      <origin>772278</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="26456" sha1="tmm38hlzbnon9jasvy0g8d422vkj0qi" xml:space="preserve">Je vous écoute {{sourire}}

Bonjour, Lionel Scheepmans, et [[Wikilivres:Bienvenue|bienvenue]] sur Wikilivres. En cas de besoin, voici quelques pages qui devraient vous être utiles si vous n'êtes pas familiers des [[w:Wiki|wikis]] :

*[[Aide:Comment modifier une page|Comment modifier une page]]
*[[Aide:Accueil|Sommaire des pages d'aide]]
*[[Wikilivres:Conventions typographiques|Conventions typographiques]]
*[[Wikilivres:Règles|Règles et recommandations]]
*[[Wikilivres:Bac à sable|Le bac à sable pour essayer la syntaxe wiki]]

Pour signer vos messages en page de discussion (on ne [[Wikilivres:Règles#Rédaction collective|signe pas]] les livres) utilisez quatre tildes (&lt;nowiki&gt;~~~~&lt;/nowiki&gt;); cela produira automatiquement votre nom et la date de publication. Si vous avez besoin d'aide, demandez à la communauté au [[Wikilivres:Le Bistro|Bistro]] ou sur ma propre page de discussion, ou bien consultez la [[Wikilivres:Foire aux questions|FAQ]] . Bonne continuation.
[[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 10 décembre 2014 à 13:43 (CET)

== Copie-Coller ==
Bonjour, il faut éviter ce type de transfert, il serait plutôt préférable de demande une [[Spécial:Import|importation]] à un administrateur. Cordialement. [[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 10 décembre 2014 à 13:43 (CET)
:Bonjour[[Utilisateur:FrankyLeRoutier|Franky]] et merci pour ton message d'accueil. Malheureusement, je ne comprends pas ce que tu veux dire dans ton deuxième message ci-dessus ? Peux-tu être plus explicite ? Bien à toi, [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 10 décembre 2014 à 14:17 (CET)
::Rebonjour Lionel, par exemple si un des auteurs de cette [[Clefs pour mieux comprendre le monde et participer à son évolution|page]] effectue un copie-coller de son contenu sur Wikiversité sans faire l'importation des [[:w:Aide:Historique|historiques]], il ne respectera pas les droits des contributeurs puisque l'article source sera supprimés. Amicalement. [[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 11 décembre 2014 à 05:22 (CET)
:::Oui effectivement [[Utilisateur:FrankyLeRoutier|Franky]], je comprends mieux ta remarque. Je pensais que tu faisait allusion au copier coller d'un livre au départ d'un fichier de son ordinateur vers une page wiki comme ce fut le cas du texte en question. J'étais déjà en train de rêver à un outils d'importation accessible uniquement par les administrateurs et qui permettrait d'importer directement la mise en page d'un PDF par exemple. Ce n'étais qu'un rêve malheureusement.
:::Donc oui, je prends bonne note qu'il faudra contacter un bibliothécaire si jamais le déplacement du texte s'avérait nécessaire. Je pense l'avoir déjà fait au sujet d'un modèle ou l'autre. Merci pour ta remarque et bonne journée à toi. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 11 décembre 2014 à 09:10 (CET)
::::Bonjour Lionel, pour l'importation externe aux projets de la fondation, il y a cette page ; [[:s:Aide:Créer un fichier DjVu]] sur Wikisource. Cordialement. [[Utilisateur:FrankyLeRoutier|FrankyLeRoutier]] % [[Discussion utilisateur:FrankyLeRoutier|Service après-vente]] 15 décembre 2014 à 01:56 (CET)

== Édition d'historique ==
Bonjour, j'apprécie sincèrement ta présence sur le bistro, mais est-ce que tu vois sur ton navigateur [//fr.wikibooks.org/w/index.php?title=Wikilivres:Le_Bistro/2015&amp;action=edit&amp;oldid=460231 le bandeau rouge &quot;Vous êtes en train de modifier une ancienne version de cette page&quot;]. Je me pose la question car sur la Wikiversité tu avais aussi blanchi de cette façon les éditions postérieures à celle que tu regardais. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 7 février 2015 à 21:05 (CET)
:Oups désolé [[Utilisateur:JackPotte|JackPotte]]. Non je ne me souviens pas d'avoir vu apparaître ce bandeau dans mon navigateur Firerfox. Mais ma mémoire n'est pas fiable :/ . J'avoue que [[v:Wikiversité:La_salle_café/février_2015#Pas_de_notifications|j'ai des problèmes avec l'organisation des bistros]]. Faudrait que je comprenne un jour le pourquoi du comment. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 7 février 2015 à 21:38 (CET)
::J'utilise aussi [[Firefox]] en habillage Monobook. D'ailleurs j'avais publié un &quot;best of&quot; des modules testés sur [[Firefox/Extensions]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 7 février 2015 à 22:20 (CET)
:::J'aime pas Monobook. C'est pas très joli et puis comme c'est pas le skin par défaut, c'est la meilleurs façon de ne pas voir les bug visible au grand publique. Merci pour le lien et bonne soirée, [[Utilisateur:JackPotte|JackPotte]], [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;strong&gt;✉ &lt;/strong&gt; [[User talk:Lionel Scheepmans|Wiki]] ou [[Special:EmailUser/Lionel_Scheepmans|eMail]]&lt;/sup&gt; 7 février 2015 à 22:48 (CET)

== Matthius ==

Je te remercie pour tes messages sur la page de discussion WP de Matthius. Mais par contre, attention : &quot;''Personne n'est censé venir y intervenir sans votre demande''&quot; rétablit, de facto, le droit d'auteur. Et d'ailleurs comment peux-tu être aussi sûr que le déblocage se fera demain ? [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 mai 2023 à 19:25 (CEST)

:Par ce que l'administrateur qui l'a bloqué m'a donné son aval. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 mai 2023 à 19:37 (CEST)
::Ne trouves-tu pas sage d'attendre l'avis d'au moins un autre administrateur ? [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 mai 2023 à 19:56 (CEST)
:::Pas moins sage que le blocage qui s'est fait sous l'avis d'un seul administrateur. Ici, nous sommes deux sur trois actifs pour le moment. Et même trois comme je viens de le découvrir. As-tu quelque chose de personnelle contre cet utilisateur [[Utilisateur:Fourmidable|Fourmidable]]  ? Ne trouves-tu pas que chacun a le droit à une seconde chance ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 mai 2023 à 17:51 (CEST)
::::Il y a urgence à bloquer un contributeur quand celui-ci parasite les débats avec des modifications non constructives comme des blanchiments de pages et des tentatives d'enfouir les discussions. Par contre, il n'y a aucune urgence à le débloquer : nous pouvons prendre le temps d'en discuter tranquillement. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 27 mai 2023 à 20:23 (CEST)
:::::Je n'ai pas été contre le premier blocage. Et tu ne réponds pas à mes questions. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 mai 2023 à 23:29 (CEST)
::::::Et au fait [[Utilisateur:Fourmidable|Fourmidable]], t'es pas en examen toi ? T'en es où dans tes études ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 mai 2023 à 23:38 (CEST)
:::::::J'ai répété maintes fois que je n'avais rien contre ce contributeur en dehors de Wikilivres, c'est très bien qu'il diffuse ses idées. On peut lui donner une seconde chance sur Wikilivres mais il faut qu'il montre de son côté un peu de bonne foi, ce que j'ai toujours du mal à voir chez lui. Souvent, ses propos sont incohérents : ex. : [https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Lionel_Scheepmans&amp;diff=next&amp;oldid=204511533 je ne vois pas de prise de position] -&gt; [https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Lionel_Scheepmans&amp;diff=next&amp;oldid=204524525 Ils prennent position effectivement] -&gt; [https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Lionel_Scheepmans&amp;diff=next&amp;oldid=204568649 Je pense que ce livrel est neutre]. Honnêtement, je ne sais pas à quoi il joue. De mon côté : licence finie, je vais peut-être passer un ou deux rattrapages pour faire le plein de points et ainsi espérer une mention. Je suis encore pour un mois au conservatoire, dont l'année se termine à la toute fin juin, voire début juillet pour les concerts. Du 9 au 31 juillet, je serai tout seul en cure thermale, nous pourrons faire plus facilement des visios (le reste de l'année je vis chez mes parents et ceux-ci sont assez hostiles à mes activités sur les wikis, c'est aussi pour ça que j'ai du mal à me rendre disponible). Je me prépare à un master Didactique des langues, à Paris, Lyon ou Montpellier. {{Sourire}} [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 28 mai 2023 à 19:23 (CEST)
::::::::Chouette programme ! Et bravo déjà pour le parcours effectué. Concernant Matthius, J'espère que le temps nous aidera à mieux le comprendre. Les sujet qu'il traite sont fondamentaux et pas si loin de mes propres intérêts. Raisons pour laquelle je m'y investi. J'espère qu'il aura intégré les règles de savoir-vivre. À suivre. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 mai 2023 à 12:55 (CEST)
:::::::::Honnêtement, je ne vois toujours pas comment on pourrait transformer ces ouvrages pour les rendre réellement utiles et valables. Mais si tu te sens inspiré, NHP à faire une proposition. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 30 mai 2023 à 11:20 (CEST)
::::::::::Le mot utilité me fait penser à l'utilitarisme, une autre philosophie politique critiquée en sciences sociales [[w:Revue_du_MAUSS|Revue du MAUSS]]. Quoi qu'il arrive, le travail de réécriture sera profitable pour l'auteur et intéressant pour moi. Il est possible qu'en fin de compte les livres ne soient pas comme tu voudrais qu'il le soit, et ce sera à la communauté d'en déterminer leurs validités pour l'espace principale. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 30 mai 2023 à 12:15 (CEST)
: J'ai revu [https://archive.org/download/WikiBooks/Economie-petits%20Wikibooks.odt l'économie pour les petits]. Je pense qu'il est neutre même si je ne suis pas centriste. C'était le plus neutre des livrels qui ont été enlevés de Wikibooks. Pour l'instant, c'est le seul livrel qui pourrait être remis sur wikibooks. En plus il est court. Pourrez-vous m'aider à le remettre sur wikibooks ?--[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 30 janvier 2024 à 05:51 (CET)
::Bonjour [[Utilisateur:Matthius|Matthius]]. Content de voir que tu consacres toujours du temps dans ta participation au projet Wikiversité. Je ne vois pas comment t'aider à replacer ton travail dans l'espace principale de Wikilivres si ce n'est en t'encourageant à le faire. Idéalement, il faudrait que ta nouvelle version du livre apparaisse sur [[Utilisateur:Matthius/Économie Petits|cette page où l'on a déplacé l'ancienne jugée inadéquate]] grâce à la fonction « diff » il sera ainsi facile de voir toutes les modifications que apportées à l'ouvrage. Par la suite, tu peux laisser un message au bistro pour informer la communauté des changements et de ton intention de replacer l'ouvrage dans l'espace principale. Suite aux discussions, on pourra alors faire les démarches nécessaires. N'oublie pas de signer tes messages, cela facilite les échanges. Bien à toi, [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt;
:::Bonjour Lionel, j'espère que tu n'es plus trop fâché contre moi ^^', et je te remercie encore pour ton suivi. J'ai donné ma critique sur le Bistro. Bien à vous deux, --[[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 5 février 2024 à 07:27 (CET)
:::Salut @[[Utilisateur:Fourmidable|Fourmidable]]. Non je ne suis pas fâche. J'étais juste un peu irrité par ta façon de t'exprimé durant une période ou je te sentais particulièrement actif dans la sélection des contenus dans les projets wikimédia. Comme je suis plutôt en faveur de l'inclusion et l'encourragement er l'inclusion, avec certaines limites que j'ai déjà exprimé avec mes votes en faveur de certaines &quot;suppression&quot;. Un terme inadéqua puisque rien n'est supprimé des serveurs en vérité, mais juste retirer de l'espace visible pas internaute. Raison pour laquelle, je préfère déplacer le contenu vers l'espace utilisateur de l'auteur en prenant soin d'empêcher le référencement pas les moteurs de recherches, alors qu'il me semble que les espace utilisateur ne le sont pas.
:::Mais donc, contend.de reprendre contact avec toi Hérison. J'espère que tout se passe bien dans ta vie et tes études ! Bien à toi. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 5 février 2024 à 11:11 (CET)
Je propose mes livrels à la recréation. Je pense que Fourmidable n'est pas habitué à lire l'économie réelle. Je lui ai montré que valeur et monnaie sont liés et que la finance comme entité humaine c'est utilisé. Fourmidable n'agit plus maintenant.--[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 26 avril 2024 à 10:40 (CEST)

Cela fait 7 mois que mes livrels sont proposés à la publication dans wikibooks. Je comprends que vous vouliez garder les contributeurs à wikibooks, puisque vous êtes dorénavant le seul à participer à wikibooks pour mes livrels. Jacques Cheminade fait peur à Jackpotte. Pourtant Cheminade dit que ceux qui ont le plus peur de lui ne l'écoutent pas. Fourmidable est lui mandaté pour supprimer, pas pour restaurer. Sinon il aurait négocié avec moi une modification des livrels que j'ai finalement pu réaliser grâce à vous. Que pensez-vous faire ? --[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 7 décembre 2024 à 21:30 (CET)

:Bonsoir @[[Utilisateur:Matthius|Matthius]]. Je n'ai pas de réponse à votre question. Si vous voulez restaurer vos livres, il suffit de les déplacer dans l'espace principale en les renomant. On verra par la suite les réaction des quelques membres de notre communauté. Cette discussion dure depuis longtemps et pour le dire franchement, j'y ai déjà consacré beaucoup de temps que je ne suis pas prête à consacrer aujourd'hui. Il y a un moment ou, en tant que bénévole, on se fatigue de faire la médiation entre deux personnes qui n'arrive pas à s'entendre. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 8 décembre 2024 à 01:56 (CET)
:::Je vais les déplacer mais ça risque de réveiller quelqu'un. Ceci écrit, les livrels ont été neutralisés. Y a-t-il un moyen de garder l'historique ?
::::Quand on dit dêplacer, en réalité On change le nom de la page et rien d'autre pour qu'elle figure dans ce ca dans l'espaxe de nom principalr et plus dans l'espace de nom utilisateur. Une page renomée garde tout son historique. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 8 décembre 2024 à 10:50 (CET)
:Pour ceux qui m'ont défendu : [http://web.archive.org/web/20260517193237/https://www.informalibre.com/Des-contributeurs-de-Wikipedia-sont-devenus-des-agents-des-lobbies-50 www.informalibre.com/Des-contributeurs-de-Wikipedia-sont-devenus-des-agents-des-lobbies-50]--[[Utilisateur:Matthius|Matthius]] ([[Discussion utilisateur:Matthius|discussion]]) 17 mai 2026 à 21:37 (CEST)

== Pages orphelines ==

Bonjour,


Il semble que tu as perdu quelques pages dans les pages orphelines. Pourrais tu les garder sur ta Page d’utilisateur pour les sortir des pages orphelines. Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 18 février 2026 à 13:19 (CET)

:@[[Utilisateur:Xhungab|Xhungab]]. Si tu n'indiques pas la personne à qui tu adresses ton message, tu risques de rester sans réponse. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 18 février 2026 à 15:13 (CET)
::L'idéal est de la notifier en la faisant apparaitre en bleu grâce au menu de l'éditeur visuel qui affiche un petit bonhomme avec un + en haut à sa gauche.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 18 février 2026 à 15:16 (CET)
:::Oups. Oublie les messages précésent. Je croyais qu'on était dans le bistro... [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 18 février 2026 à 15:24 (CET)

* [[Le mouvement Wikimedia/Préface|Préface]]
* [[Le mouvement Wikimédia/Deuxième partie :Cosmographie du mouvement Wikimédia|Deuxième partie :Cosmographie du mouvement Wikimédia]]
* [[Le mouvement Wikimédia/Première partie : La naissance du mouvement Wikimédia|Première partie : La naissance du mouvement Wikimédia]]
* [[Le mouvement Wikimédia2/Version imprimable|Version imprimable]]
* [[Projet:KarthaLab|KarthaLab]]
* [[Le mouvement Wikimédia/Livre audio|Le mouvement Wikimédia : Livre audio]]

== You may be an eligible candidate for the U4C election ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;
Greetings,

The [[m:Special:MyLanguage/Universal_Code_of_Conduct/Coordinating_Committee|Universal Code of Conduct Coordinating Committee (U4C)]] seeks candidates for the 2026 election. The U4C is the global committee responsible for overseeing enforcement of the [[foundation:Special:MyLanguage/Policy:Universal Code of Conduct|Universal Code of Conduct]]. Elections are held annually, if elected a committee member serves for two years.

This year the U4C requires candidates to hold administrator rights on at least one wiki, which is why you are being contacted as you appear to hold this right. There are other requirements, such as candidates must be at least 18 years old and may not be employed by the Wikimedia Foundation or other related chapters and affiliates. You can find more information in the [[m:Special:MyLanguage/Universal_Code_of_Conduct/Coordinating_Committee/Election/2026#Call_for_Candidates|call for candidates on Meta-wiki]]. Additionally, the committee's working language is English; some ability to communicate in English is required.

The election opens on 18 May, if you are eligible and interested you have until 10 May to submit your candidacy. There will week between for candidates to answer questions from the community. Voting takes place privately in [[m:Special:MyLanguage/SecurePoll|SecurePoll]], successful candidates must receive at least 60% support. More information is available on [[m:Special:MyLanguage/Universal_Code_of_Conduct/Coordinating_Committee/Election/2026|the 2026 Elections page]], including timelines and other candidacy information. If you read over the material and consider yourself qualified, please consider submitting your name to run for the committee. If you think someone else in your community might be interested and qualified, please encourage them to run.

In partnership with the U4C -- [[m:User:Keegan (WMF)|Keegan (WMF)]] ([[m:User_talk:Keegan (WMF)|talk]]) 28 avril 2026 à 20:33 (CEST) &lt;/div&gt;
&lt;!-- Message envoyé par User:Keegan (WMF)@metawiki en utilisant la liste sur https://meta.wikimedia.org/w/index.php?title=User:Keegan_(WMF)/test&amp;oldid=30471754 --&gt;

== '''Décision''':Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

Petites nouvelles de wikibook. la décision a été prise. On a donc besoin d'un administrateur pour conclure ce travail.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''

'''Décision pour : [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']'''

Résultats : 3 + Pour, un Neutre Neutre et un - Contre soit 60 % de + Pour par rapport au total des votes exprimés : la proposition est adoptée. Quelques propositions de reformulations et de nuances ont été faites qui pourront être prise en compte. Cdlt, VIGNERON * discut. 13 septembre 2026 à 18:27 (CEST)

Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 14 septembre 2026 à 20:35 (CEST)

:Salut @[[Utilisateur:Xhungab|Xhungab]]. Content de voir que la décision est prise. Tu peux déjà créer la page dont tu nous as parlé. Je m'occuperai de la page d'accueil, mercredi. Bien à toi,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 15 septembre 2026 à 02:18 (CEST)
::J'ai créer la page :
::* '''[https://fr.wikibooks.org/wiki/coulisses Les coulisses de Wikibook]''' 
::Il faudra peut-être la protéger pour que seuls les administrateurs puissent la modifier.
::.
::Il suffit de recopier dans la vitrine par la page ci-dessous.
::https://fr.wikibooks.org/wiki/Utilisateur:Xhungab
::.
::Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 15 septembre 2026 à 09:47 (CEST)
:::OK. Je fais ça ce soir ou demain. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 15 septembre 2026 à 10:53 (CEST)
::::@[[Utilisateur:Xhungab|Xhungab]]. Je suis en train de modifier la page d'accueil.
::::Je prends quelques initiatives pour simplifier les choses et éviter un doublon entre la page Coulisse que tu avais créée et que j'ai supprimée et la page [[Wikilivres:Tous les livres]]. Comme cette dernière page existait déjà et qu'elle est modifiable par les contributeurs confirmés, ce que tu es certainement, sens-toi libre de modifier celle-ci. Sa page de discussion sera là pour discuter de tes changements si besoin.
::::Je t'invite aussi à t'exprimer sur la [[Discussion:Accueil|page de discussion de la page d'accueil]] si tu as des choses à dire suite à mes changements.
::::Bien à toi,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 septembre 2026 à 14:36 (CEST)
:::::On voit les choses différemment, mais je pense que tu as fait du bon travail. Merci de m'avoir accordé de ton temps. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 16 septembre 2026 à 14:48 (CEST)
::::::Le problème est que lorsque l'on commence à modifier les choses concrètement et pas seulement autour d'exemples ou de discussions, on s'aperçoit de l'énorme quantité de travail à faire pour rendre cohérent tout ce qui existe déjà dans le projet. Au fil du temps, beaucoup de personnes ont eu l'initiative de créer des pages avec de bonnes intentions et il est important, je trouve, de ne pas réinventer la roue et de recycler ce qui a déjà été fait par d'autres. Voir toutes les pages des espaces de nom [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Index?prefix=&amp;namespace=4 « Wikilivres: »] - [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Index?prefix=&amp;namespace=12 « Aide: »] - etc. C'est donc ce que je m'efforce de faire à présent et sens-toi libre de partager tes points de vue sur les pages de discussion.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 septembre 2026 à 15:18 (CEST)</text>
      <sha1>tmm38hlzbnon9jasvy0g8d422vkj0qi</sha1>
    </revision>
  </page>
  <page>
    <title>Soudage/Conception d'un assemblage soudé</title>
    <ns>0</ns>
    <id>49154</id>
    <revision>
      <id>772349</id>
      <parentid>757598</parentid>
      <timestamp>2026-09-17T11:03:40Z</timestamp>
      <contributor>
        <username>Cdang</username>
        <id>1202</id>
      </contributor>
      <comment>/* Choix du mode de soudage */ 111 par défaut</comment>
      <origin>772349</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="45167" sha1="a0szot6narwqzrq9uqox8c51ga28gjn" xml:space="preserve">{{soudage}}

Le chapitre présent aborde de manière générale la soudure dans le contexte de la pièce, de l'ensemble fabriqué. Il ne prétend pas être exhaustif, mais donner des orientations générales sur les cas les plus courants.

== Choix du mode d'assemblage ==

Un produit complexe — machine, structure — est fait de plusieurs pièces assemblées. Cela permet :
* de simplifier la conception et la fabrication : on ne travaille que sur un sous-ensemble simple à la fois ;
* de faciliter la manutention, le transport : on transporte en pièces détachées ;
* d'utiliser des éléments normalisés, fabriqués en grand nombre et par plusieurs entreprises concurrentes, ce qui réduit les coûts et temps de fabrication (économie d'échelle) ainsi que les risque de pénurie.
Il existe deux grandes familles d'assemblage :
* les assemblage démontables : vissage, boulonnage, serrage dans un étau, bridage, …
* les assemblages indémontables : collage, soudage, sertissage, rivetage, …
Les assemblages démontables facilitent la maintenance (démontage de pièces pour les changer ou les réparer), le transport (si l'ensemble doit être déplacé régulièrement), le réglage, le désassemblage en fin de vie (tri). L'assemblage nécessite en général peu de matériel (tournevis, clefs) et permet d'avoir des tolérances serrées, typiquement 1/10 à {{unité|1|échelle=/100|mm}}. Mais le serrage peut s'altérer : les vibrations desserrent les vis, l'assemblage prend du jeu.

Les assemblages indémontables sont robustes et tiennent dans la durée, mais la réparation ou le démontage définitif nécessitent de découper les pièces.

Le soudage est donc choisi dans le cas :
* d'un assemblage définitif ;
* ne nécessitant pas de tolérances serrées (typiquement de l'ordre du mm) ; 
* dont les pièces sont faites d'un matériau fusible (qui fond).
Notons que l'on peut usiner des surfaces fonctionnelles après soudure, et donc avoir des tolérences serrées. Il faut pour cela prévoir des surépaisseurs — matière à enlever — supérieures aux déplacements relatifs provoqués par la soudure, et disposer d'une machine pouvant usiner l'assemblage, qui est en général de grandes dimensions.

Le soudage est donc bien adapté pour la construction métallique (escaliers, passerelles, gardes-corps), les tolérances en génie civil étant en général de l'ordre du cm. Dans le cas de l'assemblage de pièces mécaniques par soudage — ensemble mécano-soudé —, donc avec notion de mouvement, il faut s'assurer que le mécanisme est isostatique afin de pouvoir s'adapter aux imperfection de positionnement et d'orientation (défaut de coaxialité, de concentricité, …). Le soudage permet également d'assurer l'étanchéité, il est donc utilisé en tuyauterie, et pour la fabrication des cuves, réservoirs, chaudières et appareil de pression (chaudronnerie).

Mais tous les matériaux fusibles ne sont pas soudables. Par exemple, les aciers dits « trempés » (rendus durs par un refroidissement rapide) fondent comme tous les aciers, mais la soudure les fragilise.

== Choix du mode de soudage ==

Comme nous l'avons vu [[../Généralités#Présentation des principaux procédés de soudage|précédemment]], il existe plusieurs modes de soudage. Le choix dépend des matériaux à assembler, de la résistance attendue, ainsi que de critères économiques. Le coût de la mise en œuvre du procédé dépend :
* du temps d'opération, donc du « rendement » du procédé ;
* de la complexité de la soudure, de la qualification requise pour l'opérateur ;
* du coût des consommables : métal d'apport, gaz de protection ou gaz actif, énergie.
Par ailleurs, le mode de soudage peut être imposé par une norme.

Voici quelques critères généraux de choix :
* si les pièces de base ne doivent pas être altérées : brasage (soudure hétérogène) ;&lt;br /&gt;le chauffage est modéré, seul le métal d'apport fond, cela nécessite peu de matériel (fer à souder, petit chalumeau), déforme peu les pièces, et permet d'assembler des matériaux très différents comme du verre et du métal, du polymère et du métal (composant sur carte en électronique) ;
* si l'assemblage doit avoir une grande résistance mécanique : soudage autogène ;&lt;br /&gt;le métal de base (c'est-à-dire les pièces) et le métal d'apport fondent et se resolidifient, on obtient donc au final une seule pièce (continuité métallique), mais le chauffage est important (température de fusion du métal) et cela déforme l'assemblage ;
** si les pièces sont en acier :
*** en acier non allié (acier au carbone) à basse teneur en carbone : tous les procédés de soudage peuvent être utilisés ; on utilise souvent le soudage à l'arc avec électrode enrobée (procédé 111), le plus simple à mettre en œuvre ;
*** en acier inoxydable : le bain de fusion doit être protégé de l'oxygène de l'air, on utilise donc essentiellement le procédé MIG (''metal inert gas'', procédé 131&lt;ref&gt;désignation numérique des procédés selon la norme ISO 4063&lt;/ref&gt;) ou bien TIG (''tungstene inert gas'', procédé 141),
** si les métaux s'oxydent facilement : alliages d'aluminium, de nickel, de titane : le problème est similaire à celui des inox, on utilise le TIG (141).
Le soudage au chalumeau — soudage autogène (procédés 311 à 313), brasage (procédés 91, 94 et 971) — est le plus simple à mettre en œuvre (il ne nécessite pas de source d'électricité, le poste avec les bouteille de gaz est autonome). Les procédés à arc (désignation commençant par un 1) sont les plus utilisés industriellement pour le soudage autogène : la fusion est très localisée, ce qui limite la déformation, et la productivité est importante, mais le refroidissement est rapide (phénomène de trempe, contraintes résiduelles).

Les cas les plus courants sont :
* électronique (assemblage de composants sur circuit imprimé — carte polymère) : brasure avec un alliage d'étain et de plomb (par exemple 60 %Sn/40 % Pb, fondant à {{unité|190|°C}}), avec un fer à souder (énergie électrique convertie en chaleur par une résistance) ;
* plomberie : assemblage de tuyaux de cuivre par soudo-brasage (brasage au chalumeau oxyacétylénique), le métal d'apport est un alliage de cuivre contenant du phosphore, du zinc (laiton) ou de l'argent, ces éléments d'alliage permettant d'abaisser le point de fusion entre 600 et {{unité|800|°C}} (le cuivre fond à {{unité|1085|°C}}) ; pour les raccords gaz, seul l'alliage cuivre/argent est autorisé (meilleure résistance mécanique) ;
* fonte galvanisée, acier galvanisé (recouverts de zinc) : soudo-brasage (procédé 97), le métal d’apport étant un laiton à 40 % de zinc (CuZn&lt;sub&gt;40&lt;/sub&gt;, CW509L selon la [[Désignation normalisée des alliages de cuivre|désignation européenne]]) ;
* acier non allié à basse teneur en carbone (aciers d'usage général, aciers de construction, aciers « à ferrer les ânes ») : on choisit en priorité les procédés suivants :
** soudage à l'arc avec électrode enrobée (procédé 111) : ne nécessite qu'un poste à souder (en particulier pas de bouteille de gaz), la fusion de l'enrobage produit un gaz qui protège le bain de fusion, c'est le procédé à arc qui a le meilleur rendement (chaleur produite par rapport à l'électricité consommée) ; le cordon doit être meulé entre deux passes pour éviter des inclusions de laitier ;
** MAG (''metal active gas'', procédé 135) : la présence d'un gaz actif permet d'abaisser la température et donc de moins déformer les pièces, le métal d'apport est sous forme de fil qui défile de manière semi-automatique ; il nécessite la présence d'une bouteille de gaz, mais le caractère semi-automatique facilite l'opération.
Le procédé TIG (141) peut être utilisé dans tous les cas et donne un cordon de soudure d'excellente qualité, mais :
* il nécessite une bonne formation de l'opérateur ;
* il nécessite la présence d'une bouteille de gaz protecteur ;
* il a un rendement chaleur produite/électricité consommée médiocre ;
* la température est très élevée (jusqu'à {{unité|4000|°C}} au niveau du cordon pour une température d'arc pouvant atteindre {{unité|19000|°C}}&lt;ref&gt;http://hypertextbook.com/facts/2007/AnthonyHo.shtml&lt;/ref&gt;, contre {{unité|3100|°C}} pour l'électrode enrobée et le MAG), il y a donc une déformation importante.

=== Choix de l'acier ===

Le refroidissement d'une soudure est rapide, on se retrouve donc dans des conditions de trempe. Or, la formation de martensite — phase durcissante des aciers trempables — fragilise la soudure. Il faut donc s'assurer que l'on ne formera pas de martensite. Il existe d'autres problèmes métallurgiques. Tout ceci conditionne le choix de la nuance des pièces — métal de base — et de la baguette — métal d'apport.

Le premier cas est celui des aciers de construction de type
* acier d'usage général, S185 (1.0035) à S355JR (1.0045) ;
* acier pour construction mécanique, E155 (1.003) à E370 (1.0261) ;
* acier pour appareil de pression à haute température, P195GH (1.0348) à P355GH (1.0473) ;
Ces aciers sont des aciers à basse teneur en carbone (inférieure à 0,25 % en masse), ils ne sont pas trempables, le problème ne se pose pas. Par contre, c'est le carbone qui permet d'élever la limite élastique. Si l'acier doit avoir une résistance importante, en particulier pour réduire la masse de l'ensemble, on choisira des nuances particulières : des aciers à haute limite d'élasticité (HLE) soudables. Pour ces aciers, on ajoute de petites quantités d'éléments d'alliage — niobium, titane, vanadium, … — qui durcissent l'acier tout en diminuant sa trempabilité (alphagènes) :
* aciers formables à froid de type S315MC (1.0972) à S700MC (1.8974) ; le suffixe M indique un formage thermomécanique (typiquement laminage) et le C un formage spécial à froid ''(cold forming)'' ;
* aciers soudables à grain fin de type S275N (1.0486) à S460N (1.8905), S275NL (1.0488) à S460NL (1.8915) ; le suffixe N désigne un acier normalisé, le L une utilisation possible à basse température ''(low temperature)'' ;
* ''idem'' pour les appareils de pression, nuances P275NH (1.0487) à P460NH (1.8935) pour les hautes températures, P215NL (1.0451) à P460NL1 (1.8915)/P460NL2 (1.8918) pour les basses températures ;
* aciers trempés ''(quenched)'' et revenus, de type S460Q (1.8908) à S960Q (1.8941), S460QL (1.8906) à S960QL (1.8933) ;
* aciers microalliés soudables de type H240LA (1.0480) à H400LA (1.0556).

Le cas des aciers inoxydables est plus compliqué. En effet, la très grande majorité des inox utilisés sont des inox austénitiques, de phase gamma, donc qui comportent des éléments gammagènes, ceux-là même qui favorisent la formation de martensite. Par ailleurs, comme ce sont des aciers fortement alliés, il y a lors du refroidissement une concentration des éléments d'alliage en certains endroit (phénomène de ségrégation) qui abaisse localement le point de fusion (eutexie) et provoque de la fissuration à chaud. Il existe d'autres phénomènes de fragilisation : formation d'une phase sigma (fer-chrome), grossissement de grains de phase alpha.

Pour les inox, le point capital est le choix de la nuance de métal d'apport : en utilisant un métal d'apport différent du métal de base, on crée un bain de fusion ayant une composition différente du reste des pièces, donc avec un comportement à la trempe différent. En particulier, on cherche à avoir un mélange d'austénite avec 5 à 15 % de ferrite (phase alpha), qui va « ancrer » la soudure. Pour choisir la nuance de métal d'apport, on peut utiliser par exemple le diagramme de {{pc|Schaeffler}}, {{pc|DeLong}}, WRC ou {{pc|Espy}} (voir ''[[wikiversity:fr:Métallurgie générale/Exercices/Composition et structure d'un cordon de soudure|Wikiversité : Composition et structure d'un cordon de soudure]]'').

Pour limiter les problèmes de fragilisation, on peut aussi :
* préchauffer les pièces, ce qui permet de réduire la vitesse de refroidissement ;
* effectuer un traitement thermique après soudage.

== Communication technique ==

[[Fichier:Symboles soudure angle.svg|thumb|Représentation d'une soudure d'angle symétrique : simplifiée (gauche) et symbolique (droite)]]

[[Fichier:Symboles soudure V.svg|thumb|Représentation d'une soudure en V (tôles chanfreinées) : simplifiée (gauche) et symbolique (droite)]]

Sur un plan, les soudures peuvent être représentées de deux manières : de manière simplifiée ou de manière symbolique.

La représentation simplifiée permet de visualiser le cordon de soudure. On peut coter sa longueur et son épaisseur, mais cela n'apporte pas d'information sur sa réalisation (mode de soudage). Vue en coupe, on représente les pièces avant soudage (bords préparés), et le cordon de soudure est noirci. En vue extérieure, on représente des arcs de cercle correspondant à la progression de la soudure.

La représentation symbolique consiste à coter toutes les caractéristiques de la soudure :
* épaisseur de la soudure ;
* préparation des bords (chanfreinage) ; les symboles élémentaires de soudure sont donnés [[#Conception du cordon de soudure|ci-après]] ;
* longueur de la soudure ;
* procédé de soudage.
Les pièces sont représentées avant préparation des bords.

Dans le cas d'une soudure bord-à-bord, on cote l'épaisseur ''s'' de la soudure (inférieure ou égale à l'épaisseur de la tôle). Dans le cas d'une soudure d'angle, on peut coter :
* soit la largeur du plan de gorge, ''a'' : c'est cette valeur qui conditionne la résistance de la soudure (voir le calcul de dimensionnement ci-après) ;
* soit la largeur du cordon de soudure ''z'' : elle indique l'encombrement, donc intervient lorsque le point important est le jeu, par exemple si le cordon est à proximité du chemin de roulement d'un galet.
Si l'angle entre les pièces est droit, on a simplement 
: &lt;math&gt;a = z \times \cos 45^{\mathrm{o}} = z\frac{\sqrt{2}}{{2}}\text{.}&lt;/math&gt;

{{clr}}

[[File:Cotation soudure exemple.svg|thumb|Représentation symbolique d'une soudure]]

La représentation symbolique d'une soudure selon la norme ISO 2553 comprend les éléments suivants (voir figure ci-contre) :
# Ligne de repère.
# Ligne d'identification (ici : symbole côté trait plein, indiquant que le cordon se trouve du côté où pointe la flèche).
# Symbole complémentaire (ici : soudure sur chantier).
# Épaisseur du cordon de soudure.
# Symbole de soudure (ici : soudure d'angle) .
# Longueur du cordon de soudure.
# Mode de soudage selon la norme ISO 4063 (ici : électrode enrobée).

Dans les domaines sensibles — assemblage soumis à de fortes pressions, fortes températures, nucléaire —, le mode opératoire de soudage (MOS) doit être défini de manière précise : procédé utilisé, mais aussi conditions (nature du métal d'apport, intensité du courant de l'arc, vitesse d'avance, …). Le soudage doit être réalisé sur des éprouvettes (pièces métalliques) qui sont ensuite testées pour vérifier leur résistance. On constitue un dossier de qualification du mode de soudage (QMOS). Le soudeur doit être lui-même qualifié pour réaliser la soudure : il réalise la soudure sur des éprouvettes qui sont testées, la qualification devant être renouvelée régulièrement. Le descriptif des modes opératoires de soudage (DMOS) accompagne les plans, souvent sous la forme d'un cahier de soudage.

{| class=&quot;wikitable&quot;
|+ Procédés de soudage selon ISO 4063 (extrait)
|-
! 1 !! Soudage à l'arc
|
! 3 !! Soudage aux gaz
|-
! 11 !! Électrode fusible sans protection gazeuse
|
! 31 !! Soudage oxygaz
|-
| 111 || électrode enrobée 
| 
| 311 || oxyacétylénique
|-
| 112 || électrode enrobée, par gravité 
|
| 312 || oxyproprane
|-
| 113 || fil nu
|
| 313 || oxyhydrique
|-
| 114 || fil fourré
|
! 4 !! Soudage par pression, à l'état solide
|-
! 12 !! Sous flux en poudre
|
| 41 || par ultrasons
|-
! 13 !! Sous protection gazeuse avec fil-électrode fusible
|
| 42 || par friction
|-
| 131 || MIG
| 
! 7 !! Autres procédés de soudage
|-
| 135 || MAG
|
| 71 || aluminothermie
|-
! 14 !! Sous protection gazeuse avec électrode réfractaire
|
| 74 || par induction
|-
| 141 || TIG
|
! 75 !! Par rayonnement
|-
! 15 !! Au plasma
|
| 751 || laser
|-
! 2 !! Soudage par résistance
|
! 78 !! Soudage des goujons
|-
| 21 || par points
|
! 9 !! Brasage
|-
| 22 || à la molette
|
| 91 || brasage fort
|-
| 24 || par étincelage
|
| 92 || brasage tendre
|-
| 25 || en bout par résistance pure
|
| 97 || soudobrasage
|}

[[File:Symboles complementaires soudure.svg|thumb|100px|Symboles complémentaires]]

; Symboles complémentaires
# Soudure périphérique.
# Soudure sur chantier.

{{clr}}

== Conception du cordon de soudure ==

La soudure en elle-même occasionne des déformations et la présence de contraintes résiduelles. Une bonne conception de la forme des pièces à assembler, et donc des cordons de soudure, permet de limiter les problèmes :
* on cherche à faire les cordons de soudure les plus petits possibles (diminution des déformations et du temps de travail) ; si possible, on fait des cordons discontinus ;
* on évite les cordons trop rapprochés ou se croisant ;
* si le cordon doit changer de direction, on utilise une courbe et non un angle vif ;
* on met le cordon au milieu des faces, pas aux arêtes ;
* l'épaisseur des pièces doit être la même de chaque côté du cordon, afin que la vitesse de refroidissement soit la même de chaque côté.

=== Soudure bord-à-bord ===

Les bords des pièces doivent être préparés : le métal doit être propre (dégraissé, sans trace d'oxydation). Les bords sont en général chanfreinés, hormis pour les tôles de faible épaisseur, afin d'avoir une bonne pénétration de la soudure ; sinon, le résultat n'est qu'un « collage » (seule une petite partie du métal de base fond, le métal d'apport pénètre dans le joint sans se mélanger).

[[Fichier:Symboles elementaire soudure bout a bout.svg|thumb|400px|Soudures bout-à-bout.]]

# Pour les très faibles épaisseurs (moins de {{unité|1|mm}}), on peut faire une soudure sur bords relevés complètement fondus : les plis aux extrémités des tôles disparaissent avec la fusion.
# Pour les faibles épaisseurs (entre 1 et {{unité|1.4|mm}}), on peut faire une simple soudure bord-à-bord.
# À partir de 3 ou {{unité|4|mm}}, on peut faire une soudure envers ou un chanfrein avec talon.
# 
# À partir de {{unité|10|mm}}, on peut faire une soudure en Y.
# Entre 3 et {{unité|20|mm}} (éventuellement jusqu'à {{unité|40|mm}}), on fait une soudure en vé ; par rapport à la soudure en Y, le talon fait moins de {{unité|3|mm}}.
# À partir de {{unité|6|mm}}, on peut faire une soudure en X (ou en double vé).
# Pour les très fortes épaisseurs (supérieures à {{unité|20|mm}}), on fait une soudure en tulipe.

[[Fichier:Soudage pieces epaisseurs differentes.svg|thumb|350px|Soudage de pièces d'épaisseur différente.]]

Si les pièces n'ont pas la même épaisseur, on s'arrange pour accommoder les épaisseurs au niveau de la soudure (illustration ci-contre, figures de droite) :
# Lorsque la différence d'épaisseur est faible, on fait simplement un chanfrein en vé.
# Lorsque l'épaisseur est plus importante, on fait un délardage : chanfrein en retrait ayant un angle de 25 % maximum.
# On peut également pratiquer une rainure de décharge.

{{clr}}

=== Soudure d'angle ===

[[Fichier:Symboles elementaire soudure angle.svg|thumb|300px|Soudures d'angle]]

On fait en général une soudure d'angle symétrique (figures 2 et 4). Si l'on ne fait un cordon que d'un seul côté, alors la sollicitation doit se faire dans le sens de l'ouverture de la soudure (fig. 1 et 3). Si l'on peut, on effectue la soudure bout-à-bout sur une partie rectiligne (fig. 3 et 4) : ainsi, la concentration de contrainte est hors du cordon (meilleure tenue en fatigue) et cela diminue la déformation, mais cela nécessite en général d'avoir une pièce de fonderie.

=== Dimensionnement d'une soudure ===

Le cordon est dimensionné en fonction de la résistance mécanique. On utilise la théorie des poutres en considérant que la section droite est le plan de gorge.

{{Cadre définition
 | titre = Plan de gorge
 | contenu = Le cordon de soudure peut être modélisé comme un dièdre ; le plan de gorge est le plan bissecteur de ce dièdre.
}}

==== Traction sur une soudure bout-à-bout en vé ====

[[Fichier:Resistance_soudure_v_traction.svg|thumb|300px|Traction sur une soudure bout-à-bout en vé.]]

Considérons deux tôles de même épaisseur ''s'', soudées sur une longueur L, et soumises à de la traction avec une force F. Le plan de gorge, hachuré en gris sur la figure, a une aire
: S = ''s''×L.
Le plan de gorge est soumis à de la contrainte normale σ :
: &lt;math&gt;\sigma = \frac{\mathrm{F}}{\mathrm{S}} = \frac{\mathrm{F}}{s \times \mathrm{L}}&lt;/math&gt;.
La valeur à ne pas dépasser est la résistance pratique à l'extension R&lt;sub&gt;pe&lt;/sub&gt;, qui est la limite d'élasticité R&lt;sub&gt;e&lt;/sub&gt; divisée par un coefficient de sécurité ''k'', R&lt;sub&gt;pe&lt;/sub&gt; = R&lt;sub&gt;e&lt;/sub&gt;/''k''. La condition de résistance de la soudure est donc :
: &lt;math&gt;\sigma \leqslant \mathrm{R_{pe}} \Longrightarrow
\frac{\mathrm{F}}{s \times \mathrm{L}} \leqslant \frac{\mathrm{R_e}}{k}&lt;/math&gt;.
Si l'on suppose que l'épaisseur ''s'' est fixée, la longueur minimum que doit faire le cordon est
: &lt;math&gt;\mathrm{L_{mini}} = \frac{k \times \mathrm{F}}{s \times \mathrm{R_e}}&lt;/math&gt;.
Par exemple, pour des tôle en acier S235 (R&lt;sub&gt;e&lt;/sub&gt; = {{unité|235|MPa}}) et d'épaisseur ''s'' = {{unité|5|mm}}, soumis à une force F = {{unité|5000|N}} et avec un facteur de sécurité ''k'' = 2, la longueur minimale du cordon vaut :
: &lt;math&gt;\mathrm{L_{mini}} = \frac{2 \times 5\,000}{5 \times 235} = 8,5\ \mathrm{mm}&lt;/math&gt;.
On retient en général que, avec un coefficient de sécurité de 2, un cordon ayant un plan de gorge de {{unité|1|cm|2}} (soit {{unité|10|mm}}×{{unité|10|mm}} ou bien {{unité|20|mm}}×{{unité|5|mm}}) peut tenir plus de {{unité|10000|N}} (soit l'équivalent de {{unité|1|t}}).
: '''Une soudure acier tient une tonne par centimètre carré en traction.'''

==== Cisaillement d'une soudure d'angle ====

[[File:Force longitudinale soudure angle cotes.svg|thumb|300px|Soudure d'angle soumise à une force longitudinale]]

Considérons deux plats soudés ; on effectue une traction symétrique sur chacun des plats, d'une intensité F. Nous négligeons le moment du couple et ne considérons que la force.

Cette force est parallèle au plan de gorge, c'est donc un effort tranchant. L'aire des plans de gorge, au nombre de deux, vaut
: S = ''n''×L×''a'' ; ''n'' = 2
et donc la contrainte, appelée « contrainte de cisaillement parallèle », vaut :
: &lt;math&gt;\tau_{//} = \frac{\mathrm{F}}{\mathrm{S}} = \frac{\mathrm{F}}{n \times \mathrm{L} \times a} &lt;/math&gt;.
Pour que la conception de la soudure soit validée, il faut que cette contrainte soit inférieure à la résistance pratique au glissement R&lt;sub&gt;pg&lt;/sub&gt;, qui est la limite élastique au glissement R&lt;sub&gt;eg&lt;/sub&gt; à laquelle on applique un coefficient de sécurité ''k'', R&lt;sub&gt;pg&lt;/sub&gt; = R&lt;sub&gt;eg&lt;/sub&gt;/''k'' :
: &lt;math&gt;\tau_{//} \leqslant \mathrm{R_{pg}} \Longrightarrow \frac{\mathrm{F}}{n \times \mathrm{L} \times a} \leqslant \frac{\mathrm{R_{eg}}}{k}&lt;/math&gt;.
Rappelons que pour un acier doux, dont notamment les aciers de construction, ou un alliage d'aluminium, on a R&lt;sub&gt;eg&lt;/sub&gt; ≈ R&lt;sub&gt;e&lt;/sub&gt;/2&lt;ref&gt;soit R&lt;sub&gt;eg&lt;/sub&gt; ≈ 0,5×R&lt;sub&gt;e&lt;/sub&gt; ; pour les aciers mi-durs, on a R&lt;sub&gt;eg&lt;/sub&gt; ≈ 0,7×R&lt;sub&gt;e&lt;/sub&gt;, et pour les aciers durs et les fontes, R&lt;sub&gt;eg&lt;/sub&gt; ≈ 0,8×R&lt;sub&gt;e&lt;/sub&gt;&lt;br /&gt;
voir {{ouvrage
 | prénom1 = Daniel | nom1 = Spenlé
 | prénom2 = Robert | nom2 = Gourhant
 | titre = Guide du calcul en mécanique
 | éditeur = Hachette technique
 | année = 2003
 | isbn = 2-01-16-8835-3
 | passage = 161
 }}&lt;/ref&gt;.

==== Étude d'une oreille de levage ====

[[File:Levage corps central electrolyseur bts roc 2009.svg|thumb|400px|Levage du corps central d'une cellule d'électrolyse.]]

Pour lever un ouvrage lourd, on utilise souvent des élingues que l'on relie à des oreilles de levage soudées. Nous considérons un électrolyseur utilisé pour fabriquer du dihydrogène à partir de l'eau ; il doit fonctionner à des températures allant de 120 à {{unité|160|°C}} sous des pressions de 30 à {{unité|70|bar}}.

L'électrolyseur est fait de plusieurs cellules contenues dans une virole en acier P295GH de diamètre extérieur {{unité|3100|mm}}, de longueur {{unité|3820|mm}} et d'épaisseur {{unité|40|mm}}. Lors du levage, les élingues font un angle α = {{unité|60|°}} avec l'horizontale. Le poids de l'ensemble vaut P = {{unité|200|kN}}, soit une traction de {{unité|116|kN}} sur chaque élingue.

{{clr}}

[[File:Projection force soudure angle complet alt.svg|thumb|400px|Projection du vecteur contrainte]]

Le système présente un plan de symétrie pour les charges comme pour les cordons, chaque cordon est donc sollicité de la même manière. L'aire de la gorge d'un cordon vaut
: S = ''a''×L = 10×350 = {{unité|3500|mm}}
donc l'intensité du vecteur contrainte pour un cordon vaut
: &lt;math&gt;\mathrm{T} = \frac{\mathrm{F}}{2\mathrm{S}} = \frac{\mathrm{F}}{2\times a \times \mathrm{L}} = \frac{116\,000}{2\times 10 \times 350} = 16,6\ \mathrm{MPa}&lt;/math&gt;
On considère le repère local du plan de gorge. Le vecteur contrainte s'exprime par ses composantes &lt;math&gt;(\tau_{//}, \tau_\perp, \sigma_\perp)&lt;/math&gt;. On peut obtenir ces composantes en appliquant la matrice de changement de repère
: &lt;math&gt;\begin{pmatrix}
\tau_{//} \\
\tau_\perp \\
\sigma_\perp \\
\end{pmatrix}
=
\begin{pmatrix}
1 &amp; 0 &amp; 0 \\
0 &amp; \cos 45^\mathrm{o} &amp; -\sin 45^\mathrm{o} \\
0 &amp; \sin 45^\mathrm{o} &amp; \cos 45^\mathrm{o} \\
\end{pmatrix}
\begin{pmatrix}
\mathrm{T}_x \\ \mathrm{T}_y \\ \mathrm{T}_z \\
\end{pmatrix}
&lt;/math&gt;
soit
: &lt;math&gt;\begin{pmatrix}
\tau_{//} \\
\tau_\perp \\
\sigma_\perp \\
\end{pmatrix}
=
\begin{pmatrix}
1 &amp; 0 &amp; 0\\
0 &amp; \cos 45^\mathrm{o} &amp; -\sin 45^\mathrm{o} \\
0 &amp; \sin 45^\mathrm{o} &amp; \cos 45^\mathrm{o} \\
\end{pmatrix}
\begin{pmatrix}
\mathrm{T} \cos \alpha \\ \mathrm{T} \sin \alpha \\ 0 \\
\end{pmatrix}
&lt;/math&gt;
: &lt;math&gt;\begin{pmatrix}
\tau_{//} \\
\tau_\perp \\
\sigma_\perp \\
\end{pmatrix}
=
\begin{pmatrix}
8,29 \\ 10,1 \\ 10,1
\end{pmatrix}
&lt;/math&gt; (MPa).
On peut aussi obtenir ce résultat de manière géométrique — voire graphique — plutôt qu'algébrique : on commence par projeter le vecteur contrainte sur les axes horizontaux et verticaux
: &lt;math&gt; \left \{
\begin{matrix}
\mathrm{T_h} = \tau_{//} = \mathrm{T}\times \cos 60^\mathrm{o} = 8,29\ \mathrm{MPa} \\
\mathrm{T_v} = \mathrm{T}\times \sin 60^\mathrm{o} = 14,4\ \mathrm{MPa} \\
\end{matrix}
\right .
&lt;/math&gt;
Puis on décompose la composante verticale :
: &lt;math&gt;\left \{
\begin{matrix}
\tau_\perp = \mathrm{T_v} \times \cos 45^\mathrm{o} = 10,1\ \mathrm{MPa} \\
\sigma_\perp = \mathrm{T_v} \times \sin 45^\mathrm{o} = 10,1\ \mathrm{MPa} \\
\end{matrix}
\right .
&lt;/math&gt;.
Comme nous sommes en présence à la fois de contrainte normale et de cisaillement, on calcule une contrainte équivalente σ&lt;sub&gt;e&lt;/sub&gt;, par exemple de {{pc|von Mises}} :
: &lt;math&gt;\sigma_\mathrm{e\ vM} = \sqrt{\sigma^2 + 3 \times \tau^2} = \sqrt{\sigma_\perp^2 + 3 \times (\tau_{//}^2 + \tau_\perp^2)} = \sqrt{10,1^2 + 3 \times (8,29^2 + 10,1^2)} = 24,8\ \mathrm{MPa}&lt;/math&gt;
ou bien de {{pc|Tresca}}
: &lt;math&gt;\sigma_\mathrm{e\ T} = \sqrt{\sigma^2 + 4 \times \tau^2} = \sqrt{\sigma_\perp^2 + 4 \times (\tau_{//}^2 + \tau_\perp^2)} = \sqrt{10,1^2 + 4 \times (8,29^2 + 10,1^2)} = 28\ \mathrm{MPa}&lt;/math&gt;

On compare ensuite cette contrainte à la résistance pratique à l'extension ; ici, R&lt;sub&gt;e&lt;/sub&gt; = {{unité|295|MPa}}, si l'on prend un coefficient de sécurité ''k'' = 2, on a R&lt;sub&gt;pe&lt;/sub&gt; = {{unité|147|MPa}}.

Concernant le choix entre {{pc|von Mises}} et {{pc|Tresca}}, citons Jean-Louis {{pc|Fanchon}} :
: Si, pour les matériaux ductiles, von Mises est un peu plus précis que Tresca, de nombreuses vérifications expérimentales ont donné des résultats situés sur la frontière entre les deux critères. Tresca, plus simple et souvent utilisé, est plus conservatif&lt;ref&gt;prudent&lt;/ref&gt; en laissant une marge de sécurité légèrement plus grande. Cependant, beaucoup de programmes commerciaux d'analyse des contraintes et d'éléments finis s'appuient sur von Mises ; de ce fait, il existe une tendance naturelle à utiliser celui-ci en toutes circonstances.
: {{ouvrage
 | auteur = Jean-Louis Fanchon
 | titre = Guide de mécanique — Sciences et technologies industrielles
 | éditeur = Nathan/VUEF
 | année = 2001
 | isbn = 2-09-178965 - 8
 | passage = 445}}

==== Prise en compte des moments ====

[[Fichier:Cordon soudure moment negligeable.svg|thumb|Cas où le moment d'encastrement est négligeable]]

L'étude de la résistance d'un cordon de soudure devrait prendre en compte les moments (couples). Cependant, dans de nombreux cas, le bras de levier est faible donc le moment négligeable. Mais ce n'est pas toujours le cas.

{{clr}}

Rappelons le calcul du moment d'encastrement dans deux cas (l'encastrement étant ici réalisé par la soudure).

{|class=&quot;wikitable&quot;
|+ Calcul du moment d'encastrement &lt;nowiki&gt;[&lt;/nowiki&gt;[[Résistance des matériaux/Formulaire des poutres simples - Efforts de cohésion|1]]&lt;nowiki&gt;]&lt;/nowiki&gt;
! Cas !! Illustration !! Moment d'encastrement
|-
! Poutre encastrée&lt;br /&gt;(console)
| [[Fichier:Poutre appuis console charge ponctuelle stat.svg]]
| M&lt;sub&gt;A&lt;/sub&gt; = F×L
|-
! Poutre biencastrée
| [[Fichier:Poutre appuis biencastree charge ponctuelle stat.svg]]
| M&lt;sub&gt;A&lt;/sub&gt; = -M&lt;sub&gt;B&lt;/sub&gt; = F×L/8
|}

[[Fichier:Superposition contraintes flexion torsion.svg|thumb|400px|Répartition de la contrainte dans le cas de la flexion, de la torsion et d'une superposition des deux]]

[[Fichier:Torsion section rectangulaire pleine axes eurocode 3.svg|thumb|Torsion d'une section rectangulaire pleine]]

Un moment se traduit par une répartition linéaire de la contrainte : la contrainte générée est nulle au centre de gravité de la section, et croît de manière linéaire lorsque l'on s'en éloigne : contrainte normale pour un moment fléchissant M&lt;sub&gt;f&lt;/sub&gt;, contrainte de cisaillement pour un moment de torsion M&lt;sub&gt;t&lt;/sub&gt;. On s'intéresse aux extrémités du cordon de soudure, là où les contraintes sont les plus élevées ; on a :
* &lt;math&gt;\sigma_\max = \frac{\mathrm{M_f}}{\mathrm{W}}&lt;/math&gt;, s'ajoute à &lt;math&gt;\sigma_\perp&lt;/math&gt; ;
* &lt;math&gt;\tau_{\max\ //} = \frac{\mathrm{M_t}}{\mathrm{C}_{//}}&lt;/math&gt;, s'ajoute à &lt;math&gt;\tau_{//}&lt;/math&gt; ;
* &lt;math&gt;\tau_{\max\ \perp} = \frac{\mathrm{M_t}}{\mathrm{C}_{\perp}}&lt;/math&gt;, s'ajoute à &lt;math&gt;\tau_{\perp}&lt;/math&gt; ;
avec, pour une section rectangulaire de dimensions ''b''×''h'' (''h'' ≥ ''b'') :
* module de flexion transversal : W = ''b''×''h''&lt;sup&gt;2&lt;/sup&gt;/6 ;
* module de flexion longitudinal : W = ''h''×''b''&lt;sup&gt;2&lt;/sup&gt;/6 ;
* constante de torsion sur l'axe parallèle : C&lt;sub&gt;//&lt;/sub&gt; = ''h''×''b''&lt;sup&gt;2&lt;/sup&gt;/3&lt;ref&gt;le coefficient dépend du rapport ''h''/''b'', nous supposons ici un rapport supérieur à 10 ; pour plus de précision, pour un rapport ''h''/''b'' supérieur ou égal à 5, on peut prendre&lt;br /&gt; C = ''k''&lt;sub&gt;1&lt;/sub&gt;×''h''×''b''&lt;sup&gt;2&lt;/sup&gt;&lt;br /&gt; avec ''k''&lt;sub&gt;1&lt;/sub&gt; = (1 - 0,63×''b''/''h'')/3&lt;br /&gt; voir {{ouvrage
 | prénom1=Jean-Louis | nom1 = Fanchon
 | titre = Guide de mécanique
 | éditeur = Nathan
 | année = 2001
 | isbn = 978-2-09-178965-1
 | passage = 315
}}&lt;/ref&gt; ;
* constante de torsion sur l'axe perpendiculaire : C&lt;sub&gt;&amp;perp;&lt;/sub&gt; = C&lt;sub&gt;//&amp;thinsp;&lt;/sub&gt;/0,742&lt;ref&gt;comme précédemment, nous avons supposé un rapport L/''a'' supérieur ou égal à 10 ; dans le cas général, on a &lt;br /&gt; C&lt;sub&gt;&amp;perp;&lt;/sub&gt; = C&lt;sub&gt;//&amp;thinsp;&lt;/sub&gt;/η&lt;br /&gt; où η dépend du rapport ''h''/''b'', mais varie très lentement : η = 0,743 pour un rapport de 6 &lt;br /&gt; voir [http://rdmestp.voila.net/poly/TP1_C11.pdf Torsion (ESTP)] p. 5&lt;/ref&gt;.
Notons que dans le cas d'une combinaison flexion transversale+torsion, la contrainte normale maximale n'est pas au même endroit que la contrainte de cisaillement maximal.

{{clr}}

==== Cordons de soudure multiples ====

Chaque cordon de soudure réalise une liaison encastrement. Avec la statique, on peut donc déterminer les efforts ''globaux'' qui s'exercent sur les cordons reliant deux pièces ; mais si l'on s'intéresse aux cordons ''individuellement'', on se retrouve face à un problème hyperstatique. La résolution analytique est bien trop complexe. On peut résoudre ce problème avec la méthode des éléments finis (calcul sur ordinateur). Cependant, certaines hypothèses permettent de faire un calcul approché à la main.

Lorsque le problème présente une symétrie des cordons de soudure ''et'' du chargement, alors l'effort se répartit équitablement sur chacun de cordons.

Sinon, il faut répartir les efforts en fonction de l'orientation des soudures, en appliquant les règles (simplifications) suivantes&lt;ref&gt;{{article| nom1 = Michel | prénom1 = Alain
 | titre = Pièces mécaniques soudées — Calcul des assemblages
 | journal = Techniques de l'ingénieur
 | année = 2006
 | numéro = BM 5 187
 | passage = 6
}}&lt;/ref&gt; :
* forces :
** si un cordon est parallèle à une force, alors il reprend intégralement cette force ;
** si plusieurs cordons sont dans ce cas, alors la force est répartie proportionnellement à l'aire de la section de la gorge ;
* moment :
** si un cordon est parallèle à un vecteur moment, alors il reprend intégralement ce moment ;
** si plusieurs cordons sont dans ce cas, alors le moment est réparti proportionnellement au moment quadratique de la section de la gorge.

==== Étude de la liaison d'un pied sur une cuve ====

[[File:Filtre vin perspective roulettes bacpro rocsm 2008.png|thumb|Mise en situation : filtre à vin]]

Nous étudions un filtre à vin utilisé dans une entreprise de stockage et de distribution du vin en gros. ce filtre est mobile pour pouvoir être amené aux différentes cuves. Le filtre est donc sur roulettes ; les pieds sont soudés sur la cuve. Les pieds sont en tube carré de section □115&lt;sub&gt;ext&lt;/sub&gt; ép.8 et font un angle de {{unité|45|°}} avec l'horizontale.

On détermine que l'action maximale du sol sur un pied est F = {{unité|1000|daN}}. La limite élastique de la soudure vaut R&lt;sub&gt;e&lt;/sub&gt; = {{unité|250|MPa}}, et le coefficient de sécurité vaut ''k'' = 2.

{{clr}}

[[File:Liaison pied filtre vin bacpro rocsm 2008 alt.svg|thumb|Soudure entre le pied et la cuve]]

L'effort d'encastrement au niveau de la soudure comprend donc :
* une force F = {{unité|10000|N}} ;
* un moment M = F×L = {{formatnum:10000}}×1,06 = {{unité|10600|Nm}} (L étant la longueur du bras de levier).
La force génère une contrainte de cisaillement
: &lt;math&gt;\tau_{//} = \frac{\mathrm{F}}{2\mathrm{L'}a} = \frac{10\,000}{2 \times 145 \times 5} = 6,90\ \mathrm{MPa}&lt;/math&gt;
La variable L' est ici la longueur du cordon de soudure, et il y a deux cordons symétriques.

{{clr}}

[[Fichier:Soudure pied cuve projection moment.svg|thumb|Projection du vecteur moment ; le plan de gorge est vu en bout.]]

Le vecteur moment se projette dans le plan de gorge selon M&lt;sub&gt;f&lt;/sub&gt;, un moment fléchissant, et perpendiculairement à ce plan selon M&lt;sub&gt;t&lt;/sub&gt;, un moment de torsion. On a :
: &lt;math&gt;\left \{ \begin{matrix}
\mathrm{M_f} = \mathrm{M} \times \cos 45^{\mathrm{o}} = 7\,500\ \mathrm{Nm} \\
\mathrm{M_t} = \mathrm{M} \times \sin 45^{\mathrm{o}} = 7\,500\ \mathrm{Nm} \\
\end{matrix} \right .&lt;/math&gt;

Les caractéristiques de la section sont :
* W = ''a''×L'&lt;sup&gt;2&lt;/sup&gt;/6 = 5×145&lt;sup&gt;2&lt;/sup&gt;/6 = {{unité|17500|mm|3}} (flexion transversale) ;
* C&lt;sub&gt;//&lt;/sub&gt; = L'×''a''&lt;sup&gt;2&lt;/sup&gt;/3 = 145×5&lt;sup&gt;2&lt;/sup&gt;/3 = {{unité|1210|mm|3}} (on a bien L'/''a'' &amp;gt; 10) ;
* C&lt;sub&gt;&amp;perp;&lt;/sub&gt; = C&lt;sub&gt;//&amp;thinsp;&lt;/sub&gt;/0,742 = L'×''a''&lt;sup&gt;2&lt;/sup&gt;/3/0,742 = {{unité|1630|mm|3}}.
On en déduit (il y a deux cordons symétriques ; attention aux unités, on a utilisé des m pour le moment et des mm pour les caractéristiques de la section) :
* &lt;math&gt;\sigma_\max = \frac{\mathrm{M_f}}{2 \mathrm{W}} = \frac{\mathrm{F} \times \mathrm{L} \times \cos 45^{\mathrm{o}} \times 6}{2 \times a \times \mathrm{L}'^2} = 214\ \mathrm{MPa}&lt;/math&gt;
* &lt;math&gt;\tau_{\max //} = \frac{\mathrm{M_t}}{2 \mathrm{C}_{//}} = \frac{\mathrm{F} \times \mathrm{L} \times \sin 45^{\mathrm{o}} \times 3} {2 \times \mathrm{L}' \times a^2} = 3\,100\ \mathrm{MPa}&lt;/math&gt;.
Il n'est pas nécessaire d'aller au bout du calcul : la contrainte maximale de cisaillement générée par la torsion est largement supérieure à la limite élastique en cisaillement ({{formatnum:3100}} &amp;gt;&amp;gt; 125, τ&lt;sub&gt;// max&lt;/sub&gt; &amp;gt;&amp;gt; R&lt;sub&gt;eg&lt;/sub&gt;).

{{clr}}

[[Fichier:Soudure pied cuve peripherique.svg|thumb|Modèle pour le cordon de soudure périphérique.]]

Considérons une autre conception avec un cordon de soudure périphérique de largeur de gorge uniforme ''a'' = {{unité|5|mm}}. On peut considérer qu'il y a quatre cordons : deux horizontaux et deux verticaux.

D'après la règle de répartition vue précédemment :
* les cordons verticaux supportent intégralement la force verticale F ;
* les cordons horizontaux supportent intégralement le moment d'axe horizontal M.
Dans les cordons verticaux, on a donc uniquement une contrainte de cisaillement uniforme
: τ&lt;sub&gt;//&lt;/sub&gt; = {{unité|6.90|MPa}}.
La résistance pratique au glissement vaut
: R&lt;sub&gt;pg&lt;/sub&gt; = R&lt;sub&gt;eg&lt;/sub&gt;/''k'' = R&lt;sub&gt;e&lt;/sub&gt;/(2''k'') = 250/(2*2) = {{unité|62.5|MPa}}.
On a ainsi 6,90 ≤ 25 soit τ&lt;sub&gt;//&lt;/sub&gt; ≤ R&lt;sub&gt;pg&lt;/sub&gt; donc les cordons verticaux sont validés.

Comme les cordons horizontaux sont espacés, on peut considérer que la contrainte est uniforme dans chaque cordon et que le couple M est sous la forme d'un couple de forces &lt;math&gt;(\vec{\mathrm{F}}_1, -\vec{\mathrm{F}}_1)&lt;/math&gt; distantes de ''d'' = {{unité|163|mm}} = {{unité|0.163|m}} :
: F&lt;sub&gt;1&lt;/sub&gt; = M/''d'' = F×L/''d'' = {{unité|65000|N}}.
Le vecteur contrainte a pour norme
: T = F&lt;sub&gt;1&lt;/sub&gt;/S = F×L/''d''/''a''/L&quot; = {{unité|113|MPa}}.
soit
: &lt;math&gt;\left \{ \begin{align}
\tau_{//} = &amp; \ 0 \\
\tau_\perp = &amp; \ \mathrm{T} \times \cos 22,5^{\mathrm{o}} = 104\ \mathrm{MPa} \\
\sigma_\perp = &amp; \ \mathrm{T} \times \sin 22,5^{\mathrm{o}} = 43,3\ \mathrm{MPa} \\
\end{align} \right .&lt;/math&gt;
La contrainte équivalente de {{pc|von Mises}} vaut
: &lt;math&gt;\sigma_{\mathrm{e\ vM}} = \sqrt{\sigma_\perp^2 + 3 \tau_\perp ^2} = 186\ \mathrm{MPa}&lt;/math&gt;.
Cette contrainte est inférieure à la limite élastique, mais hors de la zone de sécurité puisque la résistance pratique à l'extension vaut R&lt;sub&gt;pe&lt;/sub&gt; = R&lt;sub&gt;e&lt;/sub&gt;/''k'' = {{unité|125|MPa}}. Le coefficient de sécurité effectif vaut ''k''&lt;sub&gt;eff&lt;/sub&gt; = 250/186 = 1,3. Le cordon n'est donc pas validé.

=== Normes de calcul des soudures ===

[[Fichier:Nomenclature contraintes dans une soudure.svg|vignette|Nomenclature des contraintes dans un cordon de soudure.]]

Les normes reprennent la démarche utilisée précédemment. Le critère général est
: &lt;math&gt;\sqrt{\sigma_\perp^2 + \lambda \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \alpha \times \mathrm{R_e}&lt;/math&gt;
où
* λ est un coefficient établi expérimentalement ; il allait de 1,8 à 2 dans les années 1970&lt;ref&gt;par exemple norme CM66 (décembre 1966)&lt;/ref&gt;, il est établi actuellement entre 2,5 et 3 ; il vaut 3 si l'on considère le critère de {{pc|von Mises}} et 4 si l'on considère le critère de {{pc|Tresca}} ;
* α est un coefficient de qualité ; β = 1/α est le coefficient de sécurité.
Outre ce coefficient de qualité de soudure, on applique un coefficient de pondération de charge ''k''&lt;sub&gt;p&lt;/sub&gt; en fonction du domaine (typiquement, ''k''&lt;sub&gt;p&lt;/sub&gt; = 1,5 pour une oreille de levage) ; l'effort retenu est l'effort nominal multiplié par ce coefficient. Le coefficient de sécurité total vaut donc
: ''k'' = ''k''&lt;sub&gt;p&lt;/sub&gt;/α = ''k''&lt;sub&gt;p&lt;/sub&gt;β
(les notations ''k'', α et β diffèrent selon les normes).

Dans les normes récentes, citons

==== Acier — norme Afnor NF P 22-470 (1989) ====

: &lt;math&gt;\left \{ \begin{matrix}
k \times \sqrt{\sigma_\perp^2 + 3 \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \sigma_\mathrm{e} \\
\mathrm{et}\ \sigma_\perp \leqslant \sigma_\mathrm{e}
\end{matrix} \right .&lt;/math&gt;
avec
* ''k'' : coefficient fonction du matériau,
** ''k'' = 0,7 pour un acier S235 (1.038),
** ''k'' = 0,85 pour un acier S275 (1.044),
** ''k'' = 1 pour un acier S355 (1.0045) à S460N (1.8901)
* &amp;sigma;&lt;sub&gt;e&lt;/sub&gt; : limite d'élasticité du métal.

==== Acier — Eurocode 3 (1993) ====

: &lt;math&gt;\left \{ \begin{matrix}
\beta_\mathrm{w} \times \sqrt{\sigma_\perp^2 + 3 \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \frac{\mathrm{f_u}}{\gamma_{\mathrm{M2}}} \\
\mathrm{et}\ \sigma_\perp \leqslant 0,9\frac{\mathrm{f_u}}{\gamma_{\mathrm{M2}}}\end{matrix} \right .&lt;/math&gt;
avec
* β&lt;sub&gt;w&lt;/sub&gt; : facteur de corrélation allant de 0,7 à 1,8 ;
* f&lt;sub&gt;u&lt;/sub&gt; : résistance ultime de l’acier R&lt;sub&gt;m&lt;/sub&gt; ;
* γ&lt;sub&gt;M2&lt;/sub&gt; : coefficient partiel de sécurité de résistance à la rupture des sections transversales en traction, valant 1,25 [EN 1993-1-1:2005]

{| class=&quot;wikitable&quot;
|+ Coefficients selon la nuance d'acier
|-
! Nuance !! f&lt;sub&gt;u&lt;/sub&gt; (R&lt;sub&gt;m&lt;/sub&gt;)&lt;br /&gt;(MPa) !! β&lt;sub&gt;w&lt;/sub&gt; !! γ&lt;sub&gt;M2&lt;/sub&gt;
|-
| S235 || 360 || 0,8 || 1,25
|-
| S275 || 430 || 0,85 || 1,30
|-
| S355 || 510 || 0.9 || 1,35
|}

==== Alliage d'aluminium — Eurocode 9 (1999) ====

: &lt;math&gt;\frac{1}{\alpha \beta \gamma} \times \sqrt{\sigma_\perp^2 + 3 \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \mathrm{R_e}&lt;/math&gt;
avec
* α : coefficient de qualité d'exécution allant de 0,7 (soudure difficile à réaliser) à 1 (cordon de soudure travaillant en compression, ou bien soudure réalisé dans de bonnes conditions) ;
* β : coefficient d'efficacité métallurgiqure allant de 0,43 à 1 selon les nuances d'alliage ;
* γ : coefficient de prise en compte d'autres phénomènes allant de 0,8 à 1.
Le tableau ci-dessous utilise les [[Désignation normalisée des alliages d'aluminium|désignations normalisées européennes]] (5083 désigne l'EN AW-5083[AlMg4,5Mn0,7], 42100 désigne l'EN AC-42100[AlSi7Mg0,3]) ; on indique l'ancienne désignation française entre parenthèses.

{| class=&quot;wikitable&quot;
|+ Coefficients selon la nuance d'alliage d'aluminium
|-
! Type de pièce !! Métal de base !! État métallurgique&lt;br /&gt;&lt;nowiki&gt;[&lt;/nowiki&gt;[[wikipedia:fr:Alliages d'aluminium pour corroyage#Les états métallurgiques des alliages d'aluminium pour corroyage|1]]&lt;nowiki&gt;]&lt;/nowiki&gt; &lt;nowiki&gt;[&lt;/nowiki&gt;[[wikipedia:fr:Alliages d'aluminium pour fonderie#Les états de livraison des pièces moulées |2]]&lt;nowiki&gt;]&lt;/nowiki&gt; !! Métal d'apport !! β !! γ
|-
! rowspan=&quot;9&quot; | Corroyé
| 5083 (AG4MC) || 0, H111&lt;br /&gt; H116 || 5356, 5183&lt;br /&gt;5356, 5183 || 1&lt;br /&gt;0,58 || 1&lt;br /&gt;1
|-
| 5086 (A-G5MC) || 0, H111&lt;br /&gt; H116 || 5356, 5183&lt;br /&gt;5356, 5183 || 1&lt;br /&gt;0,51 || 1&lt;br /&gt;1
|-
| 5454 (A-G2,7M0,7) || H24&lt;br /&gt; H111 || 5356, 5183&lt;br /&gt;5356, 5183 || 0,43&lt;br /&gt;1 || 1&lt;br /&gt;1
|-
| 5754 (A-G3M) || H111 || 5356, 5183 || 1 || 1&lt;br /&gt;1
|-
| 6005A (A-SG0,5MC) || T5&lt;br /&gt; T5 || 5356, 5183&lt;br /&gt;4043 || 0,50&lt;br /&gt;0,45 || 1&lt;br /&gt;0,90
|-
| 6060 (A-GS) || T5&lt;br /&gt; T5 || 5356, 5183&lt;br /&gt;4043 || 0,56&lt;br /&gt;0,56 || 1&lt;br /&gt;1
|-
| 6061 (A-GSUC) || T6&lt;br /&gt; T6 || 5356, 5183&lt;br /&gt;4043 || 0,53&lt;br /&gt;0,53 || 1&lt;br /&gt;0,80
|-
| 6082 (A-SGM0,7) || T6&lt;br /&gt; T6 || 5356, 5183&lt;br /&gt;4043 || 0,49&lt;br /&gt;0,49 || 1&lt;br /&gt;0,80
|-
| 6106 || T5&lt;br /&gt; T5 || 5356&lt;br /&gt;4043 || 0,45&lt;br /&gt;0,45 || 1&lt;br /&gt;1
|-
! rowspan=&quot;4&quot; | Fonderie
| 42100 (A-S7G0,3) || KT6 (Y33) || 4043 || 0,55 || 0,80
|-
| 42200 (A-S7G0,6) || KT6 (Y33) || 4047 || 0,55 || 0,80
|-
| 44200 (A-S13) || SF (Y20) || 4043, 4047 || 1 || 1
|-
| 71000 (A-Z5G) || ST64 (Y29) || 5356, 5280 || 0,80 || 0,80
|}

== Voir aussi ==

=== Bibliographie ===

* {{ouvrage
 | nom1 = Hazard | prénom1 = Claude
 | nom2 = Lelong | prénom2 = Frédy
 | nom3 = Quinzain | prénom3 = Bruno
 | titre = Mémotech — Structures métalliques
 | éditeur = Casteilla
 | lieu = Paris
 | année = 1997
 | isbn = 2-7135-1751-6
 | passage = 249-292
}}
* {{ouvrage
 | nom1 = Chevalier | prénom1 = André
 | titre = Guide du dessinateur industriel
 | éditeur = Hachette
 | lieu = Paris
 | année = 2004
 | isbn = 978-2-01-168831-6
 | passage = 172-179
}}
* {{ouvrage
 | nom1 = Fanchon | prénom1 = Jean-Louis
 | titre = Guide des sciences et technologies industrielles
 | éditeur = Nathan/Afnor | lieu = Paris
 | année = 2011
 | isbn = 978-2-09-161590-5
 | passage = 223-244
}}

== Notes et références ==

&lt;references /&gt;

----
&amp;lt; ''[[../Généralités|Généralités]]'' — ''[[../Soudage par friction|Soudage par friction]]'' &amp;gt;</text>
      <sha1>a0szot6narwqzrq9uqox8c51ga28gjn</sha1>
    </revision>
    <revision>
      <id>772350</id>
      <parentid>772349</parentid>
      <timestamp>2026-09-17T11:06:28Z</timestamp>
      <contributor>
        <username>Cdang</username>
        <id>1202</id>
      </contributor>
      <comment>/* Choix du mode de soudage */ tig : vitesse lente, faible dépot</comment>
      <origin>772350</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="45237" sha1="50taqrwo3ubl0pqp6didr1mlmkmkbfi" xml:space="preserve">{{soudage}}

Le chapitre présent aborde de manière générale la soudure dans le contexte de la pièce, de l'ensemble fabriqué. Il ne prétend pas être exhaustif, mais donner des orientations générales sur les cas les plus courants.

== Choix du mode d'assemblage ==

Un produit complexe — machine, structure — est fait de plusieurs pièces assemblées. Cela permet :
* de simplifier la conception et la fabrication : on ne travaille que sur un sous-ensemble simple à la fois ;
* de faciliter la manutention, le transport : on transporte en pièces détachées ;
* d'utiliser des éléments normalisés, fabriqués en grand nombre et par plusieurs entreprises concurrentes, ce qui réduit les coûts et temps de fabrication (économie d'échelle) ainsi que les risque de pénurie.
Il existe deux grandes familles d'assemblage :
* les assemblage démontables : vissage, boulonnage, serrage dans un étau, bridage, …
* les assemblages indémontables : collage, soudage, sertissage, rivetage, …
Les assemblages démontables facilitent la maintenance (démontage de pièces pour les changer ou les réparer), le transport (si l'ensemble doit être déplacé régulièrement), le réglage, le désassemblage en fin de vie (tri). L'assemblage nécessite en général peu de matériel (tournevis, clefs) et permet d'avoir des tolérances serrées, typiquement 1/10 à {{unité|1|échelle=/100|mm}}. Mais le serrage peut s'altérer : les vibrations desserrent les vis, l'assemblage prend du jeu.

Les assemblages indémontables sont robustes et tiennent dans la durée, mais la réparation ou le démontage définitif nécessitent de découper les pièces.

Le soudage est donc choisi dans le cas :
* d'un assemblage définitif ;
* ne nécessitant pas de tolérances serrées (typiquement de l'ordre du mm) ; 
* dont les pièces sont faites d'un matériau fusible (qui fond).
Notons que l'on peut usiner des surfaces fonctionnelles après soudure, et donc avoir des tolérences serrées. Il faut pour cela prévoir des surépaisseurs — matière à enlever — supérieures aux déplacements relatifs provoqués par la soudure, et disposer d'une machine pouvant usiner l'assemblage, qui est en général de grandes dimensions.

Le soudage est donc bien adapté pour la construction métallique (escaliers, passerelles, gardes-corps), les tolérances en génie civil étant en général de l'ordre du cm. Dans le cas de l'assemblage de pièces mécaniques par soudage — ensemble mécano-soudé —, donc avec notion de mouvement, il faut s'assurer que le mécanisme est isostatique afin de pouvoir s'adapter aux imperfection de positionnement et d'orientation (défaut de coaxialité, de concentricité, …). Le soudage permet également d'assurer l'étanchéité, il est donc utilisé en tuyauterie, et pour la fabrication des cuves, réservoirs, chaudières et appareil de pression (chaudronnerie).

Mais tous les matériaux fusibles ne sont pas soudables. Par exemple, les aciers dits « trempés » (rendus durs par un refroidissement rapide) fondent comme tous les aciers, mais la soudure les fragilise.

== Choix du mode de soudage ==

Comme nous l'avons vu [[../Généralités#Présentation des principaux procédés de soudage|précédemment]], il existe plusieurs modes de soudage. Le choix dépend des matériaux à assembler, de la résistance attendue, ainsi que de critères économiques. Le coût de la mise en œuvre du procédé dépend :
* du temps d'opération, donc du « rendement » du procédé ;
* de la complexité de la soudure, de la qualification requise pour l'opérateur ;
* du coût des consommables : métal d'apport, gaz de protection ou gaz actif, énergie.
Par ailleurs, le mode de soudage peut être imposé par une norme.

Voici quelques critères généraux de choix :
* si les pièces de base ne doivent pas être altérées : brasage (soudure hétérogène) ;&lt;br /&gt;le chauffage est modéré, seul le métal d'apport fond, cela nécessite peu de matériel (fer à souder, petit chalumeau), déforme peu les pièces, et permet d'assembler des matériaux très différents comme du verre et du métal, du polymère et du métal (composant sur carte en électronique) ;
* si l'assemblage doit avoir une grande résistance mécanique : soudage autogène ;&lt;br /&gt;le métal de base (c'est-à-dire les pièces) et le métal d'apport fondent et se resolidifient, on obtient donc au final une seule pièce (continuité métallique), mais le chauffage est important (température de fusion du métal) et cela déforme l'assemblage ;
** si les pièces sont en acier :
*** en acier non allié (acier au carbone) à basse teneur en carbone : tous les procédés de soudage peuvent être utilisés ; on utilise souvent le soudage à l'arc avec électrode enrobée (procédé 111), le plus simple à mettre en œuvre ;
*** en acier inoxydable : le bain de fusion doit être protégé de l'oxygène de l'air, on utilise donc essentiellement le procédé MIG (''metal inert gas'', procédé 131&lt;ref&gt;désignation numérique des procédés selon la norme ISO 4063&lt;/ref&gt;) ou bien TIG (''tungstene inert gas'', procédé 141),
** si les métaux s'oxydent facilement : alliages d'aluminium, de nickel, de titane : le problème est similaire à celui des inox, on utilise le TIG (141).
Le soudage au chalumeau — soudage autogène (procédés 311 à 313), brasage (procédés 91, 94 et 971) — est le plus simple à mettre en œuvre (il ne nécessite pas de source d'électricité, le poste avec les bouteille de gaz est autonome). Les procédés à arc (désignation commençant par un 1) sont les plus utilisés industriellement pour le soudage autogène : la fusion est très localisée, ce qui limite la déformation, et la productivité est importante, mais le refroidissement est rapide (phénomène de trempe, contraintes résiduelles).

Les cas les plus courants sont :
* électronique (assemblage de composants sur circuit imprimé — carte polymère) : brasure avec un alliage d'étain et de plomb (par exemple 60 %Sn/40 % Pb, fondant à {{unité|190|°C}}), avec un fer à souder (énergie électrique convertie en chaleur par une résistance) ;
* plomberie : assemblage de tuyaux de cuivre par soudo-brasage (brasage au chalumeau oxyacétylénique), le métal d'apport est un alliage de cuivre contenant du phosphore, du zinc (laiton) ou de l'argent, ces éléments d'alliage permettant d'abaisser le point de fusion entre 600 et {{unité|800|°C}} (le cuivre fond à {{unité|1085|°C}}) ; pour les raccords gaz, seul l'alliage cuivre/argent est autorisé (meilleure résistance mécanique) ;
* fonte galvanisée, acier galvanisé (recouverts de zinc) : soudo-brasage (procédé 97), le métal d’apport étant un laiton à 40 % de zinc (CuZn&lt;sub&gt;40&lt;/sub&gt;, CW509L selon la [[Désignation normalisée des alliages de cuivre|désignation européenne]]) ;
* acier non allié à basse teneur en carbone (aciers d'usage général, aciers de construction, aciers « à ferrer les ânes ») : on choisit en priorité les procédés suivants :
** soudage à l'arc avec électrode enrobée (procédé 111) : ne nécessite qu'un poste à souder (en particulier pas de bouteille de gaz), la fusion de l'enrobage produit un gaz qui protège le bain de fusion, c'est le procédé à arc qui a le meilleur rendement (chaleur produite par rapport à l'électricité consommée) ; le cordon doit être meulé entre deux passes pour éviter des inclusions de laitier ;
** MAG (''metal active gas'', procédé 135) : la présence d'un gaz actif permet d'abaisser la température et donc de moins déformer les pièces, le métal d'apport est sous forme de fil qui défile de manière semi-automatique ; il nécessite la présence d'une bouteille de gaz, mais le caractère semi-automatique facilite l'opération.
Le procédé TIG (141) peut être utilisé dans tous les cas et donne un cordon de soudure d'excellente qualité, mais :
* il nécessite une bonne formation de l'opérateur ;
* il nécessite la présence d'une bouteille de gaz protecteur ;
* la vitesse de soudage est lente, il y a un faible taux de dépôt ;
* il a un rendement chaleur produite/électricité consommée médiocre ;
* la température est très élevée (jusqu'à {{unité|4000|°C}} au niveau du cordon pour une température d'arc pouvant atteindre {{unité|19000|°C}}&lt;ref&gt;http://hypertextbook.com/facts/2007/AnthonyHo.shtml&lt;/ref&gt;, contre {{unité|3100|°C}} pour l'électrode enrobée et le MAG), il y a donc une déformation importante.

=== Choix de l'acier ===

Le refroidissement d'une soudure est rapide, on se retrouve donc dans des conditions de trempe. Or, la formation de martensite — phase durcissante des aciers trempables — fragilise la soudure. Il faut donc s'assurer que l'on ne formera pas de martensite. Il existe d'autres problèmes métallurgiques. Tout ceci conditionne le choix de la nuance des pièces — métal de base — et de la baguette — métal d'apport.

Le premier cas est celui des aciers de construction de type
* acier d'usage général, S185 (1.0035) à S355JR (1.0045) ;
* acier pour construction mécanique, E155 (1.003) à E370 (1.0261) ;
* acier pour appareil de pression à haute température, P195GH (1.0348) à P355GH (1.0473) ;
Ces aciers sont des aciers à basse teneur en carbone (inférieure à 0,25 % en masse), ils ne sont pas trempables, le problème ne se pose pas. Par contre, c'est le carbone qui permet d'élever la limite élastique. Si l'acier doit avoir une résistance importante, en particulier pour réduire la masse de l'ensemble, on choisira des nuances particulières : des aciers à haute limite d'élasticité (HLE) soudables. Pour ces aciers, on ajoute de petites quantités d'éléments d'alliage — niobium, titane, vanadium, … — qui durcissent l'acier tout en diminuant sa trempabilité (alphagènes) :
* aciers formables à froid de type S315MC (1.0972) à S700MC (1.8974) ; le suffixe M indique un formage thermomécanique (typiquement laminage) et le C un formage spécial à froid ''(cold forming)'' ;
* aciers soudables à grain fin de type S275N (1.0486) à S460N (1.8905), S275NL (1.0488) à S460NL (1.8915) ; le suffixe N désigne un acier normalisé, le L une utilisation possible à basse température ''(low temperature)'' ;
* ''idem'' pour les appareils de pression, nuances P275NH (1.0487) à P460NH (1.8935) pour les hautes températures, P215NL (1.0451) à P460NL1 (1.8915)/P460NL2 (1.8918) pour les basses températures ;
* aciers trempés ''(quenched)'' et revenus, de type S460Q (1.8908) à S960Q (1.8941), S460QL (1.8906) à S960QL (1.8933) ;
* aciers microalliés soudables de type H240LA (1.0480) à H400LA (1.0556).

Le cas des aciers inoxydables est plus compliqué. En effet, la très grande majorité des inox utilisés sont des inox austénitiques, de phase gamma, donc qui comportent des éléments gammagènes, ceux-là même qui favorisent la formation de martensite. Par ailleurs, comme ce sont des aciers fortement alliés, il y a lors du refroidissement une concentration des éléments d'alliage en certains endroit (phénomène de ségrégation) qui abaisse localement le point de fusion (eutexie) et provoque de la fissuration à chaud. Il existe d'autres phénomènes de fragilisation : formation d'une phase sigma (fer-chrome), grossissement de grains de phase alpha.

Pour les inox, le point capital est le choix de la nuance de métal d'apport : en utilisant un métal d'apport différent du métal de base, on crée un bain de fusion ayant une composition différente du reste des pièces, donc avec un comportement à la trempe différent. En particulier, on cherche à avoir un mélange d'austénite avec 5 à 15 % de ferrite (phase alpha), qui va « ancrer » la soudure. Pour choisir la nuance de métal d'apport, on peut utiliser par exemple le diagramme de {{pc|Schaeffler}}, {{pc|DeLong}}, WRC ou {{pc|Espy}} (voir ''[[wikiversity:fr:Métallurgie générale/Exercices/Composition et structure d'un cordon de soudure|Wikiversité : Composition et structure d'un cordon de soudure]]'').

Pour limiter les problèmes de fragilisation, on peut aussi :
* préchauffer les pièces, ce qui permet de réduire la vitesse de refroidissement ;
* effectuer un traitement thermique après soudage.

== Communication technique ==

[[Fichier:Symboles soudure angle.svg|thumb|Représentation d'une soudure d'angle symétrique : simplifiée (gauche) et symbolique (droite)]]

[[Fichier:Symboles soudure V.svg|thumb|Représentation d'une soudure en V (tôles chanfreinées) : simplifiée (gauche) et symbolique (droite)]]

Sur un plan, les soudures peuvent être représentées de deux manières : de manière simplifiée ou de manière symbolique.

La représentation simplifiée permet de visualiser le cordon de soudure. On peut coter sa longueur et son épaisseur, mais cela n'apporte pas d'information sur sa réalisation (mode de soudage). Vue en coupe, on représente les pièces avant soudage (bords préparés), et le cordon de soudure est noirci. En vue extérieure, on représente des arcs de cercle correspondant à la progression de la soudure.

La représentation symbolique consiste à coter toutes les caractéristiques de la soudure :
* épaisseur de la soudure ;
* préparation des bords (chanfreinage) ; les symboles élémentaires de soudure sont donnés [[#Conception du cordon de soudure|ci-après]] ;
* longueur de la soudure ;
* procédé de soudage.
Les pièces sont représentées avant préparation des bords.

Dans le cas d'une soudure bord-à-bord, on cote l'épaisseur ''s'' de la soudure (inférieure ou égale à l'épaisseur de la tôle). Dans le cas d'une soudure d'angle, on peut coter :
* soit la largeur du plan de gorge, ''a'' : c'est cette valeur qui conditionne la résistance de la soudure (voir le calcul de dimensionnement ci-après) ;
* soit la largeur du cordon de soudure ''z'' : elle indique l'encombrement, donc intervient lorsque le point important est le jeu, par exemple si le cordon est à proximité du chemin de roulement d'un galet.
Si l'angle entre les pièces est droit, on a simplement 
: &lt;math&gt;a = z \times \cos 45^{\mathrm{o}} = z\frac{\sqrt{2}}{{2}}\text{.}&lt;/math&gt;

{{clr}}

[[File:Cotation soudure exemple.svg|thumb|Représentation symbolique d'une soudure]]

La représentation symbolique d'une soudure selon la norme ISO 2553 comprend les éléments suivants (voir figure ci-contre) :
# Ligne de repère.
# Ligne d'identification (ici : symbole côté trait plein, indiquant que le cordon se trouve du côté où pointe la flèche).
# Symbole complémentaire (ici : soudure sur chantier).
# Épaisseur du cordon de soudure.
# Symbole de soudure (ici : soudure d'angle) .
# Longueur du cordon de soudure.
# Mode de soudage selon la norme ISO 4063 (ici : électrode enrobée).

Dans les domaines sensibles — assemblage soumis à de fortes pressions, fortes températures, nucléaire —, le mode opératoire de soudage (MOS) doit être défini de manière précise : procédé utilisé, mais aussi conditions (nature du métal d'apport, intensité du courant de l'arc, vitesse d'avance, …). Le soudage doit être réalisé sur des éprouvettes (pièces métalliques) qui sont ensuite testées pour vérifier leur résistance. On constitue un dossier de qualification du mode de soudage (QMOS). Le soudeur doit être lui-même qualifié pour réaliser la soudure : il réalise la soudure sur des éprouvettes qui sont testées, la qualification devant être renouvelée régulièrement. Le descriptif des modes opératoires de soudage (DMOS) accompagne les plans, souvent sous la forme d'un cahier de soudage.

{| class=&quot;wikitable&quot;
|+ Procédés de soudage selon ISO 4063 (extrait)
|-
! 1 !! Soudage à l'arc
|
! 3 !! Soudage aux gaz
|-
! 11 !! Électrode fusible sans protection gazeuse
|
! 31 !! Soudage oxygaz
|-
| 111 || électrode enrobée 
| 
| 311 || oxyacétylénique
|-
| 112 || électrode enrobée, par gravité 
|
| 312 || oxyproprane
|-
| 113 || fil nu
|
| 313 || oxyhydrique
|-
| 114 || fil fourré
|
! 4 !! Soudage par pression, à l'état solide
|-
! 12 !! Sous flux en poudre
|
| 41 || par ultrasons
|-
! 13 !! Sous protection gazeuse avec fil-électrode fusible
|
| 42 || par friction
|-
| 131 || MIG
| 
! 7 !! Autres procédés de soudage
|-
| 135 || MAG
|
| 71 || aluminothermie
|-
! 14 !! Sous protection gazeuse avec électrode réfractaire
|
| 74 || par induction
|-
| 141 || TIG
|
! 75 !! Par rayonnement
|-
! 15 !! Au plasma
|
| 751 || laser
|-
! 2 !! Soudage par résistance
|
! 78 !! Soudage des goujons
|-
| 21 || par points
|
! 9 !! Brasage
|-
| 22 || à la molette
|
| 91 || brasage fort
|-
| 24 || par étincelage
|
| 92 || brasage tendre
|-
| 25 || en bout par résistance pure
|
| 97 || soudobrasage
|}

[[File:Symboles complementaires soudure.svg|thumb|100px|Symboles complémentaires]]

; Symboles complémentaires
# Soudure périphérique.
# Soudure sur chantier.

{{clr}}

== Conception du cordon de soudure ==

La soudure en elle-même occasionne des déformations et la présence de contraintes résiduelles. Une bonne conception de la forme des pièces à assembler, et donc des cordons de soudure, permet de limiter les problèmes :
* on cherche à faire les cordons de soudure les plus petits possibles (diminution des déformations et du temps de travail) ; si possible, on fait des cordons discontinus ;
* on évite les cordons trop rapprochés ou se croisant ;
* si le cordon doit changer de direction, on utilise une courbe et non un angle vif ;
* on met le cordon au milieu des faces, pas aux arêtes ;
* l'épaisseur des pièces doit être la même de chaque côté du cordon, afin que la vitesse de refroidissement soit la même de chaque côté.

=== Soudure bord-à-bord ===

Les bords des pièces doivent être préparés : le métal doit être propre (dégraissé, sans trace d'oxydation). Les bords sont en général chanfreinés, hormis pour les tôles de faible épaisseur, afin d'avoir une bonne pénétration de la soudure ; sinon, le résultat n'est qu'un « collage » (seule une petite partie du métal de base fond, le métal d'apport pénètre dans le joint sans se mélanger).

[[Fichier:Symboles elementaire soudure bout a bout.svg|thumb|400px|Soudures bout-à-bout.]]

# Pour les très faibles épaisseurs (moins de {{unité|1|mm}}), on peut faire une soudure sur bords relevés complètement fondus : les plis aux extrémités des tôles disparaissent avec la fusion.
# Pour les faibles épaisseurs (entre 1 et {{unité|1.4|mm}}), on peut faire une simple soudure bord-à-bord.
# À partir de 3 ou {{unité|4|mm}}, on peut faire une soudure envers ou un chanfrein avec talon.
# 
# À partir de {{unité|10|mm}}, on peut faire une soudure en Y.
# Entre 3 et {{unité|20|mm}} (éventuellement jusqu'à {{unité|40|mm}}), on fait une soudure en vé ; par rapport à la soudure en Y, le talon fait moins de {{unité|3|mm}}.
# À partir de {{unité|6|mm}}, on peut faire une soudure en X (ou en double vé).
# Pour les très fortes épaisseurs (supérieures à {{unité|20|mm}}), on fait une soudure en tulipe.

[[Fichier:Soudage pieces epaisseurs differentes.svg|thumb|350px|Soudage de pièces d'épaisseur différente.]]

Si les pièces n'ont pas la même épaisseur, on s'arrange pour accommoder les épaisseurs au niveau de la soudure (illustration ci-contre, figures de droite) :
# Lorsque la différence d'épaisseur est faible, on fait simplement un chanfrein en vé.
# Lorsque l'épaisseur est plus importante, on fait un délardage : chanfrein en retrait ayant un angle de 25 % maximum.
# On peut également pratiquer une rainure de décharge.

{{clr}}

=== Soudure d'angle ===

[[Fichier:Symboles elementaire soudure angle.svg|thumb|300px|Soudures d'angle]]

On fait en général une soudure d'angle symétrique (figures 2 et 4). Si l'on ne fait un cordon que d'un seul côté, alors la sollicitation doit se faire dans le sens de l'ouverture de la soudure (fig. 1 et 3). Si l'on peut, on effectue la soudure bout-à-bout sur une partie rectiligne (fig. 3 et 4) : ainsi, la concentration de contrainte est hors du cordon (meilleure tenue en fatigue) et cela diminue la déformation, mais cela nécessite en général d'avoir une pièce de fonderie.

=== Dimensionnement d'une soudure ===

Le cordon est dimensionné en fonction de la résistance mécanique. On utilise la théorie des poutres en considérant que la section droite est le plan de gorge.

{{Cadre définition
 | titre = Plan de gorge
 | contenu = Le cordon de soudure peut être modélisé comme un dièdre ; le plan de gorge est le plan bissecteur de ce dièdre.
}}

==== Traction sur une soudure bout-à-bout en vé ====

[[Fichier:Resistance_soudure_v_traction.svg|thumb|300px|Traction sur une soudure bout-à-bout en vé.]]

Considérons deux tôles de même épaisseur ''s'', soudées sur une longueur L, et soumises à de la traction avec une force F. Le plan de gorge, hachuré en gris sur la figure, a une aire
: S = ''s''×L.
Le plan de gorge est soumis à de la contrainte normale σ :
: &lt;math&gt;\sigma = \frac{\mathrm{F}}{\mathrm{S}} = \frac{\mathrm{F}}{s \times \mathrm{L}}&lt;/math&gt;.
La valeur à ne pas dépasser est la résistance pratique à l'extension R&lt;sub&gt;pe&lt;/sub&gt;, qui est la limite d'élasticité R&lt;sub&gt;e&lt;/sub&gt; divisée par un coefficient de sécurité ''k'', R&lt;sub&gt;pe&lt;/sub&gt; = R&lt;sub&gt;e&lt;/sub&gt;/''k''. La condition de résistance de la soudure est donc :
: &lt;math&gt;\sigma \leqslant \mathrm{R_{pe}} \Longrightarrow
\frac{\mathrm{F}}{s \times \mathrm{L}} \leqslant \frac{\mathrm{R_e}}{k}&lt;/math&gt;.
Si l'on suppose que l'épaisseur ''s'' est fixée, la longueur minimum que doit faire le cordon est
: &lt;math&gt;\mathrm{L_{mini}} = \frac{k \times \mathrm{F}}{s \times \mathrm{R_e}}&lt;/math&gt;.
Par exemple, pour des tôle en acier S235 (R&lt;sub&gt;e&lt;/sub&gt; = {{unité|235|MPa}}) et d'épaisseur ''s'' = {{unité|5|mm}}, soumis à une force F = {{unité|5000|N}} et avec un facteur de sécurité ''k'' = 2, la longueur minimale du cordon vaut :
: &lt;math&gt;\mathrm{L_{mini}} = \frac{2 \times 5\,000}{5 \times 235} = 8,5\ \mathrm{mm}&lt;/math&gt;.
On retient en général que, avec un coefficient de sécurité de 2, un cordon ayant un plan de gorge de {{unité|1|cm|2}} (soit {{unité|10|mm}}×{{unité|10|mm}} ou bien {{unité|20|mm}}×{{unité|5|mm}}) peut tenir plus de {{unité|10000|N}} (soit l'équivalent de {{unité|1|t}}).
: '''Une soudure acier tient une tonne par centimètre carré en traction.'''

==== Cisaillement d'une soudure d'angle ====

[[File:Force longitudinale soudure angle cotes.svg|thumb|300px|Soudure d'angle soumise à une force longitudinale]]

Considérons deux plats soudés ; on effectue une traction symétrique sur chacun des plats, d'une intensité F. Nous négligeons le moment du couple et ne considérons que la force.

Cette force est parallèle au plan de gorge, c'est donc un effort tranchant. L'aire des plans de gorge, au nombre de deux, vaut
: S = ''n''×L×''a'' ; ''n'' = 2
et donc la contrainte, appelée « contrainte de cisaillement parallèle », vaut :
: &lt;math&gt;\tau_{//} = \frac{\mathrm{F}}{\mathrm{S}} = \frac{\mathrm{F}}{n \times \mathrm{L} \times a} &lt;/math&gt;.
Pour que la conception de la soudure soit validée, il faut que cette contrainte soit inférieure à la résistance pratique au glissement R&lt;sub&gt;pg&lt;/sub&gt;, qui est la limite élastique au glissement R&lt;sub&gt;eg&lt;/sub&gt; à laquelle on applique un coefficient de sécurité ''k'', R&lt;sub&gt;pg&lt;/sub&gt; = R&lt;sub&gt;eg&lt;/sub&gt;/''k'' :
: &lt;math&gt;\tau_{//} \leqslant \mathrm{R_{pg}} \Longrightarrow \frac{\mathrm{F}}{n \times \mathrm{L} \times a} \leqslant \frac{\mathrm{R_{eg}}}{k}&lt;/math&gt;.
Rappelons que pour un acier doux, dont notamment les aciers de construction, ou un alliage d'aluminium, on a R&lt;sub&gt;eg&lt;/sub&gt; ≈ R&lt;sub&gt;e&lt;/sub&gt;/2&lt;ref&gt;soit R&lt;sub&gt;eg&lt;/sub&gt; ≈ 0,5×R&lt;sub&gt;e&lt;/sub&gt; ; pour les aciers mi-durs, on a R&lt;sub&gt;eg&lt;/sub&gt; ≈ 0,7×R&lt;sub&gt;e&lt;/sub&gt;, et pour les aciers durs et les fontes, R&lt;sub&gt;eg&lt;/sub&gt; ≈ 0,8×R&lt;sub&gt;e&lt;/sub&gt;&lt;br /&gt;
voir {{ouvrage
 | prénom1 = Daniel | nom1 = Spenlé
 | prénom2 = Robert | nom2 = Gourhant
 | titre = Guide du calcul en mécanique
 | éditeur = Hachette technique
 | année = 2003
 | isbn = 2-01-16-8835-3
 | passage = 161
 }}&lt;/ref&gt;.

==== Étude d'une oreille de levage ====

[[File:Levage corps central electrolyseur bts roc 2009.svg|thumb|400px|Levage du corps central d'une cellule d'électrolyse.]]

Pour lever un ouvrage lourd, on utilise souvent des élingues que l'on relie à des oreilles de levage soudées. Nous considérons un électrolyseur utilisé pour fabriquer du dihydrogène à partir de l'eau ; il doit fonctionner à des températures allant de 120 à {{unité|160|°C}} sous des pressions de 30 à {{unité|70|bar}}.

L'électrolyseur est fait de plusieurs cellules contenues dans une virole en acier P295GH de diamètre extérieur {{unité|3100|mm}}, de longueur {{unité|3820|mm}} et d'épaisseur {{unité|40|mm}}. Lors du levage, les élingues font un angle α = {{unité|60|°}} avec l'horizontale. Le poids de l'ensemble vaut P = {{unité|200|kN}}, soit une traction de {{unité|116|kN}} sur chaque élingue.

{{clr}}

[[File:Projection force soudure angle complet alt.svg|thumb|400px|Projection du vecteur contrainte]]

Le système présente un plan de symétrie pour les charges comme pour les cordons, chaque cordon est donc sollicité de la même manière. L'aire de la gorge d'un cordon vaut
: S = ''a''×L = 10×350 = {{unité|3500|mm}}
donc l'intensité du vecteur contrainte pour un cordon vaut
: &lt;math&gt;\mathrm{T} = \frac{\mathrm{F}}{2\mathrm{S}} = \frac{\mathrm{F}}{2\times a \times \mathrm{L}} = \frac{116\,000}{2\times 10 \times 350} = 16,6\ \mathrm{MPa}&lt;/math&gt;
On considère le repère local du plan de gorge. Le vecteur contrainte s'exprime par ses composantes &lt;math&gt;(\tau_{//}, \tau_\perp, \sigma_\perp)&lt;/math&gt;. On peut obtenir ces composantes en appliquant la matrice de changement de repère
: &lt;math&gt;\begin{pmatrix}
\tau_{//} \\
\tau_\perp \\
\sigma_\perp \\
\end{pmatrix}
=
\begin{pmatrix}
1 &amp; 0 &amp; 0 \\
0 &amp; \cos 45^\mathrm{o} &amp; -\sin 45^\mathrm{o} \\
0 &amp; \sin 45^\mathrm{o} &amp; \cos 45^\mathrm{o} \\
\end{pmatrix}
\begin{pmatrix}
\mathrm{T}_x \\ \mathrm{T}_y \\ \mathrm{T}_z \\
\end{pmatrix}
&lt;/math&gt;
soit
: &lt;math&gt;\begin{pmatrix}
\tau_{//} \\
\tau_\perp \\
\sigma_\perp \\
\end{pmatrix}
=
\begin{pmatrix}
1 &amp; 0 &amp; 0\\
0 &amp; \cos 45^\mathrm{o} &amp; -\sin 45^\mathrm{o} \\
0 &amp; \sin 45^\mathrm{o} &amp; \cos 45^\mathrm{o} \\
\end{pmatrix}
\begin{pmatrix}
\mathrm{T} \cos \alpha \\ \mathrm{T} \sin \alpha \\ 0 \\
\end{pmatrix}
&lt;/math&gt;
: &lt;math&gt;\begin{pmatrix}
\tau_{//} \\
\tau_\perp \\
\sigma_\perp \\
\end{pmatrix}
=
\begin{pmatrix}
8,29 \\ 10,1 \\ 10,1
\end{pmatrix}
&lt;/math&gt; (MPa).
On peut aussi obtenir ce résultat de manière géométrique — voire graphique — plutôt qu'algébrique : on commence par projeter le vecteur contrainte sur les axes horizontaux et verticaux
: &lt;math&gt; \left \{
\begin{matrix}
\mathrm{T_h} = \tau_{//} = \mathrm{T}\times \cos 60^\mathrm{o} = 8,29\ \mathrm{MPa} \\
\mathrm{T_v} = \mathrm{T}\times \sin 60^\mathrm{o} = 14,4\ \mathrm{MPa} \\
\end{matrix}
\right .
&lt;/math&gt;
Puis on décompose la composante verticale :
: &lt;math&gt;\left \{
\begin{matrix}
\tau_\perp = \mathrm{T_v} \times \cos 45^\mathrm{o} = 10,1\ \mathrm{MPa} \\
\sigma_\perp = \mathrm{T_v} \times \sin 45^\mathrm{o} = 10,1\ \mathrm{MPa} \\
\end{matrix}
\right .
&lt;/math&gt;.
Comme nous sommes en présence à la fois de contrainte normale et de cisaillement, on calcule une contrainte équivalente σ&lt;sub&gt;e&lt;/sub&gt;, par exemple de {{pc|von Mises}} :
: &lt;math&gt;\sigma_\mathrm{e\ vM} = \sqrt{\sigma^2 + 3 \times \tau^2} = \sqrt{\sigma_\perp^2 + 3 \times (\tau_{//}^2 + \tau_\perp^2)} = \sqrt{10,1^2 + 3 \times (8,29^2 + 10,1^2)} = 24,8\ \mathrm{MPa}&lt;/math&gt;
ou bien de {{pc|Tresca}}
: &lt;math&gt;\sigma_\mathrm{e\ T} = \sqrt{\sigma^2 + 4 \times \tau^2} = \sqrt{\sigma_\perp^2 + 4 \times (\tau_{//}^2 + \tau_\perp^2)} = \sqrt{10,1^2 + 4 \times (8,29^2 + 10,1^2)} = 28\ \mathrm{MPa}&lt;/math&gt;

On compare ensuite cette contrainte à la résistance pratique à l'extension ; ici, R&lt;sub&gt;e&lt;/sub&gt; = {{unité|295|MPa}}, si l'on prend un coefficient de sécurité ''k'' = 2, on a R&lt;sub&gt;pe&lt;/sub&gt; = {{unité|147|MPa}}.

Concernant le choix entre {{pc|von Mises}} et {{pc|Tresca}}, citons Jean-Louis {{pc|Fanchon}} :
: Si, pour les matériaux ductiles, von Mises est un peu plus précis que Tresca, de nombreuses vérifications expérimentales ont donné des résultats situés sur la frontière entre les deux critères. Tresca, plus simple et souvent utilisé, est plus conservatif&lt;ref&gt;prudent&lt;/ref&gt; en laissant une marge de sécurité légèrement plus grande. Cependant, beaucoup de programmes commerciaux d'analyse des contraintes et d'éléments finis s'appuient sur von Mises ; de ce fait, il existe une tendance naturelle à utiliser celui-ci en toutes circonstances.
: {{ouvrage
 | auteur = Jean-Louis Fanchon
 | titre = Guide de mécanique — Sciences et technologies industrielles
 | éditeur = Nathan/VUEF
 | année = 2001
 | isbn = 2-09-178965 - 8
 | passage = 445}}

==== Prise en compte des moments ====

[[Fichier:Cordon soudure moment negligeable.svg|thumb|Cas où le moment d'encastrement est négligeable]]

L'étude de la résistance d'un cordon de soudure devrait prendre en compte les moments (couples). Cependant, dans de nombreux cas, le bras de levier est faible donc le moment négligeable. Mais ce n'est pas toujours le cas.

{{clr}}

Rappelons le calcul du moment d'encastrement dans deux cas (l'encastrement étant ici réalisé par la soudure).

{|class=&quot;wikitable&quot;
|+ Calcul du moment d'encastrement &lt;nowiki&gt;[&lt;/nowiki&gt;[[Résistance des matériaux/Formulaire des poutres simples - Efforts de cohésion|1]]&lt;nowiki&gt;]&lt;/nowiki&gt;
! Cas !! Illustration !! Moment d'encastrement
|-
! Poutre encastrée&lt;br /&gt;(console)
| [[Fichier:Poutre appuis console charge ponctuelle stat.svg]]
| M&lt;sub&gt;A&lt;/sub&gt; = F×L
|-
! Poutre biencastrée
| [[Fichier:Poutre appuis biencastree charge ponctuelle stat.svg]]
| M&lt;sub&gt;A&lt;/sub&gt; = -M&lt;sub&gt;B&lt;/sub&gt; = F×L/8
|}

[[Fichier:Superposition contraintes flexion torsion.svg|thumb|400px|Répartition de la contrainte dans le cas de la flexion, de la torsion et d'une superposition des deux]]

[[Fichier:Torsion section rectangulaire pleine axes eurocode 3.svg|thumb|Torsion d'une section rectangulaire pleine]]

Un moment se traduit par une répartition linéaire de la contrainte : la contrainte générée est nulle au centre de gravité de la section, et croît de manière linéaire lorsque l'on s'en éloigne : contrainte normale pour un moment fléchissant M&lt;sub&gt;f&lt;/sub&gt;, contrainte de cisaillement pour un moment de torsion M&lt;sub&gt;t&lt;/sub&gt;. On s'intéresse aux extrémités du cordon de soudure, là où les contraintes sont les plus élevées ; on a :
* &lt;math&gt;\sigma_\max = \frac{\mathrm{M_f}}{\mathrm{W}}&lt;/math&gt;, s'ajoute à &lt;math&gt;\sigma_\perp&lt;/math&gt; ;
* &lt;math&gt;\tau_{\max\ //} = \frac{\mathrm{M_t}}{\mathrm{C}_{//}}&lt;/math&gt;, s'ajoute à &lt;math&gt;\tau_{//}&lt;/math&gt; ;
* &lt;math&gt;\tau_{\max\ \perp} = \frac{\mathrm{M_t}}{\mathrm{C}_{\perp}}&lt;/math&gt;, s'ajoute à &lt;math&gt;\tau_{\perp}&lt;/math&gt; ;
avec, pour une section rectangulaire de dimensions ''b''×''h'' (''h'' ≥ ''b'') :
* module de flexion transversal : W = ''b''×''h''&lt;sup&gt;2&lt;/sup&gt;/6 ;
* module de flexion longitudinal : W = ''h''×''b''&lt;sup&gt;2&lt;/sup&gt;/6 ;
* constante de torsion sur l'axe parallèle : C&lt;sub&gt;//&lt;/sub&gt; = ''h''×''b''&lt;sup&gt;2&lt;/sup&gt;/3&lt;ref&gt;le coefficient dépend du rapport ''h''/''b'', nous supposons ici un rapport supérieur à 10 ; pour plus de précision, pour un rapport ''h''/''b'' supérieur ou égal à 5, on peut prendre&lt;br /&gt; C = ''k''&lt;sub&gt;1&lt;/sub&gt;×''h''×''b''&lt;sup&gt;2&lt;/sup&gt;&lt;br /&gt; avec ''k''&lt;sub&gt;1&lt;/sub&gt; = (1 - 0,63×''b''/''h'')/3&lt;br /&gt; voir {{ouvrage
 | prénom1=Jean-Louis | nom1 = Fanchon
 | titre = Guide de mécanique
 | éditeur = Nathan
 | année = 2001
 | isbn = 978-2-09-178965-1
 | passage = 315
}}&lt;/ref&gt; ;
* constante de torsion sur l'axe perpendiculaire : C&lt;sub&gt;&amp;perp;&lt;/sub&gt; = C&lt;sub&gt;//&amp;thinsp;&lt;/sub&gt;/0,742&lt;ref&gt;comme précédemment, nous avons supposé un rapport L/''a'' supérieur ou égal à 10 ; dans le cas général, on a &lt;br /&gt; C&lt;sub&gt;&amp;perp;&lt;/sub&gt; = C&lt;sub&gt;//&amp;thinsp;&lt;/sub&gt;/η&lt;br /&gt; où η dépend du rapport ''h''/''b'', mais varie très lentement : η = 0,743 pour un rapport de 6 &lt;br /&gt; voir [http://rdmestp.voila.net/poly/TP1_C11.pdf Torsion (ESTP)] p. 5&lt;/ref&gt;.
Notons que dans le cas d'une combinaison flexion transversale+torsion, la contrainte normale maximale n'est pas au même endroit que la contrainte de cisaillement maximal.

{{clr}}

==== Cordons de soudure multiples ====

Chaque cordon de soudure réalise une liaison encastrement. Avec la statique, on peut donc déterminer les efforts ''globaux'' qui s'exercent sur les cordons reliant deux pièces ; mais si l'on s'intéresse aux cordons ''individuellement'', on se retrouve face à un problème hyperstatique. La résolution analytique est bien trop complexe. On peut résoudre ce problème avec la méthode des éléments finis (calcul sur ordinateur). Cependant, certaines hypothèses permettent de faire un calcul approché à la main.

Lorsque le problème présente une symétrie des cordons de soudure ''et'' du chargement, alors l'effort se répartit équitablement sur chacun de cordons.

Sinon, il faut répartir les efforts en fonction de l'orientation des soudures, en appliquant les règles (simplifications) suivantes&lt;ref&gt;{{article| nom1 = Michel | prénom1 = Alain
 | titre = Pièces mécaniques soudées — Calcul des assemblages
 | journal = Techniques de l'ingénieur
 | année = 2006
 | numéro = BM 5 187
 | passage = 6
}}&lt;/ref&gt; :
* forces :
** si un cordon est parallèle à une force, alors il reprend intégralement cette force ;
** si plusieurs cordons sont dans ce cas, alors la force est répartie proportionnellement à l'aire de la section de la gorge ;
* moment :
** si un cordon est parallèle à un vecteur moment, alors il reprend intégralement ce moment ;
** si plusieurs cordons sont dans ce cas, alors le moment est réparti proportionnellement au moment quadratique de la section de la gorge.

==== Étude de la liaison d'un pied sur une cuve ====

[[File:Filtre vin perspective roulettes bacpro rocsm 2008.png|thumb|Mise en situation : filtre à vin]]

Nous étudions un filtre à vin utilisé dans une entreprise de stockage et de distribution du vin en gros. ce filtre est mobile pour pouvoir être amené aux différentes cuves. Le filtre est donc sur roulettes ; les pieds sont soudés sur la cuve. Les pieds sont en tube carré de section □115&lt;sub&gt;ext&lt;/sub&gt; ép.8 et font un angle de {{unité|45|°}} avec l'horizontale.

On détermine que l'action maximale du sol sur un pied est F = {{unité|1000|daN}}. La limite élastique de la soudure vaut R&lt;sub&gt;e&lt;/sub&gt; = {{unité|250|MPa}}, et le coefficient de sécurité vaut ''k'' = 2.

{{clr}}

[[File:Liaison pied filtre vin bacpro rocsm 2008 alt.svg|thumb|Soudure entre le pied et la cuve]]

L'effort d'encastrement au niveau de la soudure comprend donc :
* une force F = {{unité|10000|N}} ;
* un moment M = F×L = {{formatnum:10000}}×1,06 = {{unité|10600|Nm}} (L étant la longueur du bras de levier).
La force génère une contrainte de cisaillement
: &lt;math&gt;\tau_{//} = \frac{\mathrm{F}}{2\mathrm{L'}a} = \frac{10\,000}{2 \times 145 \times 5} = 6,90\ \mathrm{MPa}&lt;/math&gt;
La variable L' est ici la longueur du cordon de soudure, et il y a deux cordons symétriques.

{{clr}}

[[Fichier:Soudure pied cuve projection moment.svg|thumb|Projection du vecteur moment ; le plan de gorge est vu en bout.]]

Le vecteur moment se projette dans le plan de gorge selon M&lt;sub&gt;f&lt;/sub&gt;, un moment fléchissant, et perpendiculairement à ce plan selon M&lt;sub&gt;t&lt;/sub&gt;, un moment de torsion. On a :
: &lt;math&gt;\left \{ \begin{matrix}
\mathrm{M_f} = \mathrm{M} \times \cos 45^{\mathrm{o}} = 7\,500\ \mathrm{Nm} \\
\mathrm{M_t} = \mathrm{M} \times \sin 45^{\mathrm{o}} = 7\,500\ \mathrm{Nm} \\
\end{matrix} \right .&lt;/math&gt;

Les caractéristiques de la section sont :
* W = ''a''×L'&lt;sup&gt;2&lt;/sup&gt;/6 = 5×145&lt;sup&gt;2&lt;/sup&gt;/6 = {{unité|17500|mm|3}} (flexion transversale) ;
* C&lt;sub&gt;//&lt;/sub&gt; = L'×''a''&lt;sup&gt;2&lt;/sup&gt;/3 = 145×5&lt;sup&gt;2&lt;/sup&gt;/3 = {{unité|1210|mm|3}} (on a bien L'/''a'' &amp;gt; 10) ;
* C&lt;sub&gt;&amp;perp;&lt;/sub&gt; = C&lt;sub&gt;//&amp;thinsp;&lt;/sub&gt;/0,742 = L'×''a''&lt;sup&gt;2&lt;/sup&gt;/3/0,742 = {{unité|1630|mm|3}}.
On en déduit (il y a deux cordons symétriques ; attention aux unités, on a utilisé des m pour le moment et des mm pour les caractéristiques de la section) :
* &lt;math&gt;\sigma_\max = \frac{\mathrm{M_f}}{2 \mathrm{W}} = \frac{\mathrm{F} \times \mathrm{L} \times \cos 45^{\mathrm{o}} \times 6}{2 \times a \times \mathrm{L}'^2} = 214\ \mathrm{MPa}&lt;/math&gt;
* &lt;math&gt;\tau_{\max //} = \frac{\mathrm{M_t}}{2 \mathrm{C}_{//}} = \frac{\mathrm{F} \times \mathrm{L} \times \sin 45^{\mathrm{o}} \times 3} {2 \times \mathrm{L}' \times a^2} = 3\,100\ \mathrm{MPa}&lt;/math&gt;.
Il n'est pas nécessaire d'aller au bout du calcul : la contrainte maximale de cisaillement générée par la torsion est largement supérieure à la limite élastique en cisaillement ({{formatnum:3100}} &amp;gt;&amp;gt; 125, τ&lt;sub&gt;// max&lt;/sub&gt; &amp;gt;&amp;gt; R&lt;sub&gt;eg&lt;/sub&gt;).

{{clr}}

[[Fichier:Soudure pied cuve peripherique.svg|thumb|Modèle pour le cordon de soudure périphérique.]]

Considérons une autre conception avec un cordon de soudure périphérique de largeur de gorge uniforme ''a'' = {{unité|5|mm}}. On peut considérer qu'il y a quatre cordons : deux horizontaux et deux verticaux.

D'après la règle de répartition vue précédemment :
* les cordons verticaux supportent intégralement la force verticale F ;
* les cordons horizontaux supportent intégralement le moment d'axe horizontal M.
Dans les cordons verticaux, on a donc uniquement une contrainte de cisaillement uniforme
: τ&lt;sub&gt;//&lt;/sub&gt; = {{unité|6.90|MPa}}.
La résistance pratique au glissement vaut
: R&lt;sub&gt;pg&lt;/sub&gt; = R&lt;sub&gt;eg&lt;/sub&gt;/''k'' = R&lt;sub&gt;e&lt;/sub&gt;/(2''k'') = 250/(2*2) = {{unité|62.5|MPa}}.
On a ainsi 6,90 ≤ 25 soit τ&lt;sub&gt;//&lt;/sub&gt; ≤ R&lt;sub&gt;pg&lt;/sub&gt; donc les cordons verticaux sont validés.

Comme les cordons horizontaux sont espacés, on peut considérer que la contrainte est uniforme dans chaque cordon et que le couple M est sous la forme d'un couple de forces &lt;math&gt;(\vec{\mathrm{F}}_1, -\vec{\mathrm{F}}_1)&lt;/math&gt; distantes de ''d'' = {{unité|163|mm}} = {{unité|0.163|m}} :
: F&lt;sub&gt;1&lt;/sub&gt; = M/''d'' = F×L/''d'' = {{unité|65000|N}}.
Le vecteur contrainte a pour norme
: T = F&lt;sub&gt;1&lt;/sub&gt;/S = F×L/''d''/''a''/L&quot; = {{unité|113|MPa}}.
soit
: &lt;math&gt;\left \{ \begin{align}
\tau_{//} = &amp; \ 0 \\
\tau_\perp = &amp; \ \mathrm{T} \times \cos 22,5^{\mathrm{o}} = 104\ \mathrm{MPa} \\
\sigma_\perp = &amp; \ \mathrm{T} \times \sin 22,5^{\mathrm{o}} = 43,3\ \mathrm{MPa} \\
\end{align} \right .&lt;/math&gt;
La contrainte équivalente de {{pc|von Mises}} vaut
: &lt;math&gt;\sigma_{\mathrm{e\ vM}} = \sqrt{\sigma_\perp^2 + 3 \tau_\perp ^2} = 186\ \mathrm{MPa}&lt;/math&gt;.
Cette contrainte est inférieure à la limite élastique, mais hors de la zone de sécurité puisque la résistance pratique à l'extension vaut R&lt;sub&gt;pe&lt;/sub&gt; = R&lt;sub&gt;e&lt;/sub&gt;/''k'' = {{unité|125|MPa}}. Le coefficient de sécurité effectif vaut ''k''&lt;sub&gt;eff&lt;/sub&gt; = 250/186 = 1,3. Le cordon n'est donc pas validé.

=== Normes de calcul des soudures ===

[[Fichier:Nomenclature contraintes dans une soudure.svg|vignette|Nomenclature des contraintes dans un cordon de soudure.]]

Les normes reprennent la démarche utilisée précédemment. Le critère général est
: &lt;math&gt;\sqrt{\sigma_\perp^2 + \lambda \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \alpha \times \mathrm{R_e}&lt;/math&gt;
où
* λ est un coefficient établi expérimentalement ; il allait de 1,8 à 2 dans les années 1970&lt;ref&gt;par exemple norme CM66 (décembre 1966)&lt;/ref&gt;, il est établi actuellement entre 2,5 et 3 ; il vaut 3 si l'on considère le critère de {{pc|von Mises}} et 4 si l'on considère le critère de {{pc|Tresca}} ;
* α est un coefficient de qualité ; β = 1/α est le coefficient de sécurité.
Outre ce coefficient de qualité de soudure, on applique un coefficient de pondération de charge ''k''&lt;sub&gt;p&lt;/sub&gt; en fonction du domaine (typiquement, ''k''&lt;sub&gt;p&lt;/sub&gt; = 1,5 pour une oreille de levage) ; l'effort retenu est l'effort nominal multiplié par ce coefficient. Le coefficient de sécurité total vaut donc
: ''k'' = ''k''&lt;sub&gt;p&lt;/sub&gt;/α = ''k''&lt;sub&gt;p&lt;/sub&gt;β
(les notations ''k'', α et β diffèrent selon les normes).

Dans les normes récentes, citons

==== Acier — norme Afnor NF P 22-470 (1989) ====

: &lt;math&gt;\left \{ \begin{matrix}
k \times \sqrt{\sigma_\perp^2 + 3 \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \sigma_\mathrm{e} \\
\mathrm{et}\ \sigma_\perp \leqslant \sigma_\mathrm{e}
\end{matrix} \right .&lt;/math&gt;
avec
* ''k'' : coefficient fonction du matériau,
** ''k'' = 0,7 pour un acier S235 (1.038),
** ''k'' = 0,85 pour un acier S275 (1.044),
** ''k'' = 1 pour un acier S355 (1.0045) à S460N (1.8901)
* &amp;sigma;&lt;sub&gt;e&lt;/sub&gt; : limite d'élasticité du métal.

==== Acier — Eurocode 3 (1993) ====

: &lt;math&gt;\left \{ \begin{matrix}
\beta_\mathrm{w} \times \sqrt{\sigma_\perp^2 + 3 \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \frac{\mathrm{f_u}}{\gamma_{\mathrm{M2}}} \\
\mathrm{et}\ \sigma_\perp \leqslant 0,9\frac{\mathrm{f_u}}{\gamma_{\mathrm{M2}}}\end{matrix} \right .&lt;/math&gt;
avec
* β&lt;sub&gt;w&lt;/sub&gt; : facteur de corrélation allant de 0,7 à 1,8 ;
* f&lt;sub&gt;u&lt;/sub&gt; : résistance ultime de l’acier R&lt;sub&gt;m&lt;/sub&gt; ;
* γ&lt;sub&gt;M2&lt;/sub&gt; : coefficient partiel de sécurité de résistance à la rupture des sections transversales en traction, valant 1,25 [EN 1993-1-1:2005]

{| class=&quot;wikitable&quot;
|+ Coefficients selon la nuance d'acier
|-
! Nuance !! f&lt;sub&gt;u&lt;/sub&gt; (R&lt;sub&gt;m&lt;/sub&gt;)&lt;br /&gt;(MPa) !! β&lt;sub&gt;w&lt;/sub&gt; !! γ&lt;sub&gt;M2&lt;/sub&gt;
|-
| S235 || 360 || 0,8 || 1,25
|-
| S275 || 430 || 0,85 || 1,30
|-
| S355 || 510 || 0.9 || 1,35
|}

==== Alliage d'aluminium — Eurocode 9 (1999) ====

: &lt;math&gt;\frac{1}{\alpha \beta \gamma} \times \sqrt{\sigma_\perp^2 + 3 \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \mathrm{R_e}&lt;/math&gt;
avec
* α : coefficient de qualité d'exécution allant de 0,7 (soudure difficile à réaliser) à 1 (cordon de soudure travaillant en compression, ou bien soudure réalisé dans de bonnes conditions) ;
* β : coefficient d'efficacité métallurgiqure allant de 0,43 à 1 selon les nuances d'alliage ;
* γ : coefficient de prise en compte d'autres phénomènes allant de 0,8 à 1.
Le tableau ci-dessous utilise les [[Désignation normalisée des alliages d'aluminium|désignations normalisées européennes]] (5083 désigne l'EN AW-5083[AlMg4,5Mn0,7], 42100 désigne l'EN AC-42100[AlSi7Mg0,3]) ; on indique l'ancienne désignation française entre parenthèses.

{| class=&quot;wikitable&quot;
|+ Coefficients selon la nuance d'alliage d'aluminium
|-
! Type de pièce !! Métal de base !! État métallurgique&lt;br /&gt;&lt;nowiki&gt;[&lt;/nowiki&gt;[[wikipedia:fr:Alliages d'aluminium pour corroyage#Les états métallurgiques des alliages d'aluminium pour corroyage|1]]&lt;nowiki&gt;]&lt;/nowiki&gt; &lt;nowiki&gt;[&lt;/nowiki&gt;[[wikipedia:fr:Alliages d'aluminium pour fonderie#Les états de livraison des pièces moulées |2]]&lt;nowiki&gt;]&lt;/nowiki&gt; !! Métal d'apport !! β !! γ
|-
! rowspan=&quot;9&quot; | Corroyé
| 5083 (AG4MC) || 0, H111&lt;br /&gt; H116 || 5356, 5183&lt;br /&gt;5356, 5183 || 1&lt;br /&gt;0,58 || 1&lt;br /&gt;1
|-
| 5086 (A-G5MC) || 0, H111&lt;br /&gt; H116 || 5356, 5183&lt;br /&gt;5356, 5183 || 1&lt;br /&gt;0,51 || 1&lt;br /&gt;1
|-
| 5454 (A-G2,7M0,7) || H24&lt;br /&gt; H111 || 5356, 5183&lt;br /&gt;5356, 5183 || 0,43&lt;br /&gt;1 || 1&lt;br /&gt;1
|-
| 5754 (A-G3M) || H111 || 5356, 5183 || 1 || 1&lt;br /&gt;1
|-
| 6005A (A-SG0,5MC) || T5&lt;br /&gt; T5 || 5356, 5183&lt;br /&gt;4043 || 0,50&lt;br /&gt;0,45 || 1&lt;br /&gt;0,90
|-
| 6060 (A-GS) || T5&lt;br /&gt; T5 || 5356, 5183&lt;br /&gt;4043 || 0,56&lt;br /&gt;0,56 || 1&lt;br /&gt;1
|-
| 6061 (A-GSUC) || T6&lt;br /&gt; T6 || 5356, 5183&lt;br /&gt;4043 || 0,53&lt;br /&gt;0,53 || 1&lt;br /&gt;0,80
|-
| 6082 (A-SGM0,7) || T6&lt;br /&gt; T6 || 5356, 5183&lt;br /&gt;4043 || 0,49&lt;br /&gt;0,49 || 1&lt;br /&gt;0,80
|-
| 6106 || T5&lt;br /&gt; T5 || 5356&lt;br /&gt;4043 || 0,45&lt;br /&gt;0,45 || 1&lt;br /&gt;1
|-
! rowspan=&quot;4&quot; | Fonderie
| 42100 (A-S7G0,3) || KT6 (Y33) || 4043 || 0,55 || 0,80
|-
| 42200 (A-S7G0,6) || KT6 (Y33) || 4047 || 0,55 || 0,80
|-
| 44200 (A-S13) || SF (Y20) || 4043, 4047 || 1 || 1
|-
| 71000 (A-Z5G) || ST64 (Y29) || 5356, 5280 || 0,80 || 0,80
|}

== Voir aussi ==

=== Bibliographie ===

* {{ouvrage
 | nom1 = Hazard | prénom1 = Claude
 | nom2 = Lelong | prénom2 = Frédy
 | nom3 = Quinzain | prénom3 = Bruno
 | titre = Mémotech — Structures métalliques
 | éditeur = Casteilla
 | lieu = Paris
 | année = 1997
 | isbn = 2-7135-1751-6
 | passage = 249-292
}}
* {{ouvrage
 | nom1 = Chevalier | prénom1 = André
 | titre = Guide du dessinateur industriel
 | éditeur = Hachette
 | lieu = Paris
 | année = 2004
 | isbn = 978-2-01-168831-6
 | passage = 172-179
}}
* {{ouvrage
 | nom1 = Fanchon | prénom1 = Jean-Louis
 | titre = Guide des sciences et technologies industrielles
 | éditeur = Nathan/Afnor | lieu = Paris
 | année = 2011
 | isbn = 978-2-09-161590-5
 | passage = 223-244
}}

== Notes et références ==

&lt;references /&gt;

----
&amp;lt; ''[[../Généralités|Généralités]]'' — ''[[../Soudage par friction|Soudage par friction]]'' &amp;gt;</text>
      <sha1>50taqrwo3ubl0pqp6didr1mlmkmkbfi</sha1>
    </revision>
    <revision>
      <id>772351</id>
      <parentid>772350</parentid>
      <timestamp>2026-09-17T11:12:15Z</timestamp>
      <contributor>
        <username>Cdang</username>
        <id>1202</id>
      </contributor>
      <minor />
      <comment>/* Communication technique */ précisions</comment>
      <origin>772351</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="45333" sha1="e698kbly4v9dcbrnum8hkiaqk197kup" xml:space="preserve">{{soudage}}

Le chapitre présent aborde de manière générale la soudure dans le contexte de la pièce, de l'ensemble fabriqué. Il ne prétend pas être exhaustif, mais donner des orientations générales sur les cas les plus courants.

== Choix du mode d'assemblage ==

Un produit complexe — machine, structure — est fait de plusieurs pièces assemblées. Cela permet :
* de simplifier la conception et la fabrication : on ne travaille que sur un sous-ensemble simple à la fois ;
* de faciliter la manutention, le transport : on transporte en pièces détachées ;
* d'utiliser des éléments normalisés, fabriqués en grand nombre et par plusieurs entreprises concurrentes, ce qui réduit les coûts et temps de fabrication (économie d'échelle) ainsi que les risque de pénurie.
Il existe deux grandes familles d'assemblage :
* les assemblage démontables : vissage, boulonnage, serrage dans un étau, bridage, …
* les assemblages indémontables : collage, soudage, sertissage, rivetage, …
Les assemblages démontables facilitent la maintenance (démontage de pièces pour les changer ou les réparer), le transport (si l'ensemble doit être déplacé régulièrement), le réglage, le désassemblage en fin de vie (tri). L'assemblage nécessite en général peu de matériel (tournevis, clefs) et permet d'avoir des tolérances serrées, typiquement 1/10 à {{unité|1|échelle=/100|mm}}. Mais le serrage peut s'altérer : les vibrations desserrent les vis, l'assemblage prend du jeu.

Les assemblages indémontables sont robustes et tiennent dans la durée, mais la réparation ou le démontage définitif nécessitent de découper les pièces.

Le soudage est donc choisi dans le cas :
* d'un assemblage définitif ;
* ne nécessitant pas de tolérances serrées (typiquement de l'ordre du mm) ; 
* dont les pièces sont faites d'un matériau fusible (qui fond).
Notons que l'on peut usiner des surfaces fonctionnelles après soudure, et donc avoir des tolérences serrées. Il faut pour cela prévoir des surépaisseurs — matière à enlever — supérieures aux déplacements relatifs provoqués par la soudure, et disposer d'une machine pouvant usiner l'assemblage, qui est en général de grandes dimensions.

Le soudage est donc bien adapté pour la construction métallique (escaliers, passerelles, gardes-corps), les tolérances en génie civil étant en général de l'ordre du cm. Dans le cas de l'assemblage de pièces mécaniques par soudage — ensemble mécano-soudé —, donc avec notion de mouvement, il faut s'assurer que le mécanisme est isostatique afin de pouvoir s'adapter aux imperfection de positionnement et d'orientation (défaut de coaxialité, de concentricité, …). Le soudage permet également d'assurer l'étanchéité, il est donc utilisé en tuyauterie, et pour la fabrication des cuves, réservoirs, chaudières et appareil de pression (chaudronnerie).

Mais tous les matériaux fusibles ne sont pas soudables. Par exemple, les aciers dits « trempés » (rendus durs par un refroidissement rapide) fondent comme tous les aciers, mais la soudure les fragilise.

== Choix du mode de soudage ==

Comme nous l'avons vu [[../Généralités#Présentation des principaux procédés de soudage|précédemment]], il existe plusieurs modes de soudage. Le choix dépend des matériaux à assembler, de la résistance attendue, ainsi que de critères économiques. Le coût de la mise en œuvre du procédé dépend :
* du temps d'opération, donc du « rendement » du procédé ;
* de la complexité de la soudure, de la qualification requise pour l'opérateur ;
* du coût des consommables : métal d'apport, gaz de protection ou gaz actif, énergie.
Par ailleurs, le mode de soudage peut être imposé par une norme.

Voici quelques critères généraux de choix :
* si les pièces de base ne doivent pas être altérées : brasage (soudure hétérogène) ;&lt;br /&gt;le chauffage est modéré, seul le métal d'apport fond, cela nécessite peu de matériel (fer à souder, petit chalumeau), déforme peu les pièces, et permet d'assembler des matériaux très différents comme du verre et du métal, du polymère et du métal (composant sur carte en électronique) ;
* si l'assemblage doit avoir une grande résistance mécanique : soudage autogène ;&lt;br /&gt;le métal de base (c'est-à-dire les pièces) et le métal d'apport fondent et se resolidifient, on obtient donc au final une seule pièce (continuité métallique), mais le chauffage est important (température de fusion du métal) et cela déforme l'assemblage ;
** si les pièces sont en acier :
*** en acier non allié (acier au carbone) à basse teneur en carbone : tous les procédés de soudage peuvent être utilisés ; on utilise souvent le soudage à l'arc avec électrode enrobée (procédé 111), le plus simple à mettre en œuvre ;
*** en acier inoxydable : le bain de fusion doit être protégé de l'oxygène de l'air, on utilise donc essentiellement le procédé MIG (''metal inert gas'', procédé 131&lt;ref&gt;désignation numérique des procédés selon la norme ISO 4063&lt;/ref&gt;) ou bien TIG (''tungstene inert gas'', procédé 141),
** si les métaux s'oxydent facilement : alliages d'aluminium, de nickel, de titane : le problème est similaire à celui des inox, on utilise le TIG (141).
Le soudage au chalumeau — soudage autogène (procédés 311 à 313), brasage (procédés 91, 94 et 971) — est le plus simple à mettre en œuvre (il ne nécessite pas de source d'électricité, le poste avec les bouteille de gaz est autonome). Les procédés à arc (désignation commençant par un 1) sont les plus utilisés industriellement pour le soudage autogène : la fusion est très localisée, ce qui limite la déformation, et la productivité est importante, mais le refroidissement est rapide (phénomène de trempe, contraintes résiduelles).

Les cas les plus courants sont :
* électronique (assemblage de composants sur circuit imprimé — carte polymère) : brasure avec un alliage d'étain et de plomb (par exemple 60 %Sn/40 % Pb, fondant à {{unité|190|°C}}), avec un fer à souder (énergie électrique convertie en chaleur par une résistance) ;
* plomberie : assemblage de tuyaux de cuivre par soudo-brasage (brasage au chalumeau oxyacétylénique), le métal d'apport est un alliage de cuivre contenant du phosphore, du zinc (laiton) ou de l'argent, ces éléments d'alliage permettant d'abaisser le point de fusion entre 600 et {{unité|800|°C}} (le cuivre fond à {{unité|1085|°C}}) ; pour les raccords gaz, seul l'alliage cuivre/argent est autorisé (meilleure résistance mécanique) ;
* fonte galvanisée, acier galvanisé (recouverts de zinc) : soudo-brasage (procédé 97), le métal d’apport étant un laiton à 40 % de zinc (CuZn&lt;sub&gt;40&lt;/sub&gt;, CW509L selon la [[Désignation normalisée des alliages de cuivre|désignation européenne]]) ;
* acier non allié à basse teneur en carbone (aciers d'usage général, aciers de construction, aciers « à ferrer les ânes ») : on choisit en priorité les procédés suivants :
** soudage à l'arc avec électrode enrobée (procédé 111) : ne nécessite qu'un poste à souder (en particulier pas de bouteille de gaz), la fusion de l'enrobage produit un gaz qui protège le bain de fusion, c'est le procédé à arc qui a le meilleur rendement (chaleur produite par rapport à l'électricité consommée) ; le cordon doit être meulé entre deux passes pour éviter des inclusions de laitier ;
** MAG (''metal active gas'', procédé 135) : la présence d'un gaz actif permet d'abaisser la température et donc de moins déformer les pièces, le métal d'apport est sous forme de fil qui défile de manière semi-automatique ; il nécessite la présence d'une bouteille de gaz, mais le caractère semi-automatique facilite l'opération.
Le procédé TIG (141) peut être utilisé dans tous les cas et donne un cordon de soudure d'excellente qualité, mais :
* il nécessite une bonne formation de l'opérateur ;
* il nécessite la présence d'une bouteille de gaz protecteur ;
* la vitesse de soudage est lente, il y a un faible taux de dépôt ;
* il a un rendement chaleur produite/électricité consommée médiocre ;
* la température est très élevée (jusqu'à {{unité|4000|°C}} au niveau du cordon pour une température d'arc pouvant atteindre {{unité|19000|°C}}&lt;ref&gt;http://hypertextbook.com/facts/2007/AnthonyHo.shtml&lt;/ref&gt;, contre {{unité|3100|°C}} pour l'électrode enrobée et le MAG), il y a donc une déformation importante.

=== Choix de l'acier ===

Le refroidissement d'une soudure est rapide, on se retrouve donc dans des conditions de trempe. Or, la formation de martensite — phase durcissante des aciers trempables — fragilise la soudure. Il faut donc s'assurer que l'on ne formera pas de martensite. Il existe d'autres problèmes métallurgiques. Tout ceci conditionne le choix de la nuance des pièces — métal de base — et de la baguette — métal d'apport.

Le premier cas est celui des aciers de construction de type
* acier d'usage général, S185 (1.0035) à S355JR (1.0045) ;
* acier pour construction mécanique, E155 (1.003) à E370 (1.0261) ;
* acier pour appareil de pression à haute température, P195GH (1.0348) à P355GH (1.0473) ;
Ces aciers sont des aciers à basse teneur en carbone (inférieure à 0,25 % en masse), ils ne sont pas trempables, le problème ne se pose pas. Par contre, c'est le carbone qui permet d'élever la limite élastique. Si l'acier doit avoir une résistance importante, en particulier pour réduire la masse de l'ensemble, on choisira des nuances particulières : des aciers à haute limite d'élasticité (HLE) soudables. Pour ces aciers, on ajoute de petites quantités d'éléments d'alliage — niobium, titane, vanadium, … — qui durcissent l'acier tout en diminuant sa trempabilité (alphagènes) :
* aciers formables à froid de type S315MC (1.0972) à S700MC (1.8974) ; le suffixe M indique un formage thermomécanique (typiquement laminage) et le C un formage spécial à froid ''(cold forming)'' ;
* aciers soudables à grain fin de type S275N (1.0486) à S460N (1.8905), S275NL (1.0488) à S460NL (1.8915) ; le suffixe N désigne un acier normalisé, le L une utilisation possible à basse température ''(low temperature)'' ;
* ''idem'' pour les appareils de pression, nuances P275NH (1.0487) à P460NH (1.8935) pour les hautes températures, P215NL (1.0451) à P460NL1 (1.8915)/P460NL2 (1.8918) pour les basses températures ;
* aciers trempés ''(quenched)'' et revenus, de type S460Q (1.8908) à S960Q (1.8941), S460QL (1.8906) à S960QL (1.8933) ;
* aciers microalliés soudables de type H240LA (1.0480) à H400LA (1.0556).

Le cas des aciers inoxydables est plus compliqué. En effet, la très grande majorité des inox utilisés sont des inox austénitiques, de phase gamma, donc qui comportent des éléments gammagènes, ceux-là même qui favorisent la formation de martensite. Par ailleurs, comme ce sont des aciers fortement alliés, il y a lors du refroidissement une concentration des éléments d'alliage en certains endroit (phénomène de ségrégation) qui abaisse localement le point de fusion (eutexie) et provoque de la fissuration à chaud. Il existe d'autres phénomènes de fragilisation : formation d'une phase sigma (fer-chrome), grossissement de grains de phase alpha.

Pour les inox, le point capital est le choix de la nuance de métal d'apport : en utilisant un métal d'apport différent du métal de base, on crée un bain de fusion ayant une composition différente du reste des pièces, donc avec un comportement à la trempe différent. En particulier, on cherche à avoir un mélange d'austénite avec 5 à 15 % de ferrite (phase alpha), qui va « ancrer » la soudure. Pour choisir la nuance de métal d'apport, on peut utiliser par exemple le diagramme de {{pc|Schaeffler}}, {{pc|DeLong}}, WRC ou {{pc|Espy}} (voir ''[[wikiversity:fr:Métallurgie générale/Exercices/Composition et structure d'un cordon de soudure|Wikiversité : Composition et structure d'un cordon de soudure]]'').

Pour limiter les problèmes de fragilisation, on peut aussi :
* préchauffer les pièces, ce qui permet de réduire la vitesse de refroidissement ;
* effectuer un traitement thermique après soudage.

== Communication technique ==

[[Fichier:Symboles soudure angle.svg|thumb|Représentation d'une soudure d'angle symétrique : simplifiée (gauche) et symbolique (droite)]]

[[Fichier:Symboles soudure V.svg|thumb|Représentation d'une soudure en V (tôles chanfreinées) : simplifiée (gauche) et symbolique (droite)]]

Sur un plan, les soudures peuvent être représentées de deux manières : de manière simplifiée ou de manière symbolique.

La représentation simplifiée permet de visualiser le cordon de soudure. On peut coter sa longueur et son épaisseur, mais cela n'apporte pas d'information sur sa réalisation (mode de soudage). Vue en coupe, on représente les pièces avant soudage (bords préparés), et le cordon de soudure est noirci. En vue extérieure, on représente des arcs de cercle correspondant à la progression de la soudure.

La représentation symbolique consiste à coter toutes les caractéristiques de la soudure :
* épaisseur de la soudure ;
* préparation des bords (chanfreinage) ; les symboles élémentaires de soudure sont donnés [[#Conception du cordon de soudure|ci-après]] ;
* longueur de la soudure ;
* procédé de soudage.
Les pièces sont représentées avant préparation des bords.

Dans le cas d'une soudure bord-à-bord, on cote l'épaisseur ''s'' de la soudure (inférieure ou égale à l'épaisseur de la tôle). Dans le cas d'une soudure d'angle, on peut coter :
* soit la largeur du plan de gorge, ''a'' : c'est cette valeur qui conditionne la résistance de la soudure (voir le calcul de dimensionnement ci-après) ;
* soit la largeur du cordon de soudure ''z'' : elle indique l'encombrement, donc intervient lorsque le point important est le jeu, par exemple si le cordon est à proximité du chemin de roulement d'un galet.
Si l'angle entre les pièces est droit, on a simplement 
: &lt;math&gt;a = z \times \cos 45^{\mathrm{o}} = z\frac{\sqrt{2}}{{2}}\text{ ;}&lt;/math&gt;
: &lt;math&gt;z = a \times \sqrt{2}\text{.}&lt;/math&gt;

{{clr}}

[[File:Cotation soudure exemple.svg|thumb|Représentation symbolique d'une soudure]]

La représentation symbolique d'une soudure selon la norme ISO 2553 comprend les éléments suivants (voir figure ci-contre) :
# Ligne de repère.
# Ligne d'identification (ici : symbole côté trait plein, indiquant que le cordon se trouve du côté où pointe la flèche).
# Symbole complémentaire (ici : soudure sur chantier).
# Épaisseur du cordon de soudure (ici : cote de gorge ''a'' = {{unité|3|mm}}).
# Symbole de soudure (ici : soudure d'angle).
# Longueur du cordon de soudure.
# Mode de soudage selon la norme ISO 4063 (ici : 111, électrode enrobée).

Dans les domaines sensibles — assemblage soumis à de fortes pressions, fortes températures, nucléaire —, le mode opératoire de soudage (MOS) doit être défini de manière précise : procédé utilisé, mais aussi conditions (nature du métal d'apport, intensité du courant de l'arc, vitesse d'avance, …). Le soudage doit être réalisé sur des éprouvettes (pièces métalliques) qui sont ensuite testées pour vérifier leur résistance. On constitue un dossier de qualification du mode de soudage (QMOS). Le soudeur doit être lui-même qualifié pour réaliser la soudure : il réalise la soudure sur des éprouvettes qui sont testées, la qualification devant être renouvelée régulièrement. Le descriptif des modes opératoires de soudage (DMOS) accompagne les plans, souvent sous la forme d'un cahier de soudage.

{| class=&quot;wikitable&quot;
|+ Procédés de soudage selon ISO 4063 (extrait)
|-
! 1 !! Soudage à l'arc
|
! 3 !! Soudage aux gaz
|-
! 11 !! Électrode fusible sans protection gazeuse
|
! 31 !! Soudage oxygaz
|-
| 111 || électrode enrobée 
| 
| 311 || oxyacétylénique
|-
| 112 || électrode enrobée, par gravité 
|
| 312 || oxyproprane
|-
| 113 || fil nu
|
| 313 || oxyhydrique
|-
| 114 || fil fourré
|
! 4 !! Soudage par pression, à l'état solide
|-
! 12 !! Sous flux en poudre
|
| 41 || par ultrasons
|-
! 13 !! Sous protection gazeuse avec fil-électrode fusible
|
| 42 || par friction
|-
| 131 || MIG
| 
! 7 !! Autres procédés de soudage
|-
| 135 || MAG
|
| 71 || aluminothermie
|-
! 14 !! Sous protection gazeuse avec électrode réfractaire
|
| 74 || par induction
|-
| 141 || TIG
|
! 75 !! Par rayonnement
|-
! 15 !! Au plasma
|
| 751 || laser
|-
! 2 !! Soudage par résistance
|
! 78 !! Soudage des goujons
|-
| 21 || par points
|
! 9 !! Brasage
|-
| 22 || à la molette
|
| 91 || brasage fort
|-
| 24 || par étincelage
|
| 92 || brasage tendre
|-
| 25 || en bout par résistance pure
|
| 97 || soudobrasage
|}

[[File:Symboles complementaires soudure.svg|thumb|100px|Symboles complémentaires]]

; Symboles complémentaires
# Soudure périphérique.
# Soudure sur chantier.

{{clr}}

== Conception du cordon de soudure ==

La soudure en elle-même occasionne des déformations et la présence de contraintes résiduelles. Une bonne conception de la forme des pièces à assembler, et donc des cordons de soudure, permet de limiter les problèmes :
* on cherche à faire les cordons de soudure les plus petits possibles (diminution des déformations et du temps de travail) ; si possible, on fait des cordons discontinus ;
* on évite les cordons trop rapprochés ou se croisant ;
* si le cordon doit changer de direction, on utilise une courbe et non un angle vif ;
* on met le cordon au milieu des faces, pas aux arêtes ;
* l'épaisseur des pièces doit être la même de chaque côté du cordon, afin que la vitesse de refroidissement soit la même de chaque côté.

=== Soudure bord-à-bord ===

Les bords des pièces doivent être préparés : le métal doit être propre (dégraissé, sans trace d'oxydation). Les bords sont en général chanfreinés, hormis pour les tôles de faible épaisseur, afin d'avoir une bonne pénétration de la soudure ; sinon, le résultat n'est qu'un « collage » (seule une petite partie du métal de base fond, le métal d'apport pénètre dans le joint sans se mélanger).

[[Fichier:Symboles elementaire soudure bout a bout.svg|thumb|400px|Soudures bout-à-bout.]]

# Pour les très faibles épaisseurs (moins de {{unité|1|mm}}), on peut faire une soudure sur bords relevés complètement fondus : les plis aux extrémités des tôles disparaissent avec la fusion.
# Pour les faibles épaisseurs (entre 1 et {{unité|1.4|mm}}), on peut faire une simple soudure bord-à-bord.
# À partir de 3 ou {{unité|4|mm}}, on peut faire une soudure envers ou un chanfrein avec talon.
# 
# À partir de {{unité|10|mm}}, on peut faire une soudure en Y.
# Entre 3 et {{unité|20|mm}} (éventuellement jusqu'à {{unité|40|mm}}), on fait une soudure en vé ; par rapport à la soudure en Y, le talon fait moins de {{unité|3|mm}}.
# À partir de {{unité|6|mm}}, on peut faire une soudure en X (ou en double vé).
# Pour les très fortes épaisseurs (supérieures à {{unité|20|mm}}), on fait une soudure en tulipe.

[[Fichier:Soudage pieces epaisseurs differentes.svg|thumb|350px|Soudage de pièces d'épaisseur différente.]]

Si les pièces n'ont pas la même épaisseur, on s'arrange pour accommoder les épaisseurs au niveau de la soudure (illustration ci-contre, figures de droite) :
# Lorsque la différence d'épaisseur est faible, on fait simplement un chanfrein en vé.
# Lorsque l'épaisseur est plus importante, on fait un délardage : chanfrein en retrait ayant un angle de 25 % maximum.
# On peut également pratiquer une rainure de décharge.

{{clr}}

=== Soudure d'angle ===

[[Fichier:Symboles elementaire soudure angle.svg|thumb|300px|Soudures d'angle]]

On fait en général une soudure d'angle symétrique (figures 2 et 4). Si l'on ne fait un cordon que d'un seul côté, alors la sollicitation doit se faire dans le sens de l'ouverture de la soudure (fig. 1 et 3). Si l'on peut, on effectue la soudure bout-à-bout sur une partie rectiligne (fig. 3 et 4) : ainsi, la concentration de contrainte est hors du cordon (meilleure tenue en fatigue) et cela diminue la déformation, mais cela nécessite en général d'avoir une pièce de fonderie.

=== Dimensionnement d'une soudure ===

Le cordon est dimensionné en fonction de la résistance mécanique. On utilise la théorie des poutres en considérant que la section droite est le plan de gorge.

{{Cadre définition
 | titre = Plan de gorge
 | contenu = Le cordon de soudure peut être modélisé comme un dièdre ; le plan de gorge est le plan bissecteur de ce dièdre.
}}

==== Traction sur une soudure bout-à-bout en vé ====

[[Fichier:Resistance_soudure_v_traction.svg|thumb|300px|Traction sur une soudure bout-à-bout en vé.]]

Considérons deux tôles de même épaisseur ''s'', soudées sur une longueur L, et soumises à de la traction avec une force F. Le plan de gorge, hachuré en gris sur la figure, a une aire
: S = ''s''×L.
Le plan de gorge est soumis à de la contrainte normale σ :
: &lt;math&gt;\sigma = \frac{\mathrm{F}}{\mathrm{S}} = \frac{\mathrm{F}}{s \times \mathrm{L}}&lt;/math&gt;.
La valeur à ne pas dépasser est la résistance pratique à l'extension R&lt;sub&gt;pe&lt;/sub&gt;, qui est la limite d'élasticité R&lt;sub&gt;e&lt;/sub&gt; divisée par un coefficient de sécurité ''k'', R&lt;sub&gt;pe&lt;/sub&gt; = R&lt;sub&gt;e&lt;/sub&gt;/''k''. La condition de résistance de la soudure est donc :
: &lt;math&gt;\sigma \leqslant \mathrm{R_{pe}} \Longrightarrow
\frac{\mathrm{F}}{s \times \mathrm{L}} \leqslant \frac{\mathrm{R_e}}{k}&lt;/math&gt;.
Si l'on suppose que l'épaisseur ''s'' est fixée, la longueur minimum que doit faire le cordon est
: &lt;math&gt;\mathrm{L_{mini}} = \frac{k \times \mathrm{F}}{s \times \mathrm{R_e}}&lt;/math&gt;.
Par exemple, pour des tôle en acier S235 (R&lt;sub&gt;e&lt;/sub&gt; = {{unité|235|MPa}}) et d'épaisseur ''s'' = {{unité|5|mm}}, soumis à une force F = {{unité|5000|N}} et avec un facteur de sécurité ''k'' = 2, la longueur minimale du cordon vaut :
: &lt;math&gt;\mathrm{L_{mini}} = \frac{2 \times 5\,000}{5 \times 235} = 8,5\ \mathrm{mm}&lt;/math&gt;.
On retient en général que, avec un coefficient de sécurité de 2, un cordon ayant un plan de gorge de {{unité|1|cm|2}} (soit {{unité|10|mm}}×{{unité|10|mm}} ou bien {{unité|20|mm}}×{{unité|5|mm}}) peut tenir plus de {{unité|10000|N}} (soit l'équivalent de {{unité|1|t}}).
: '''Une soudure acier tient une tonne par centimètre carré en traction.'''

==== Cisaillement d'une soudure d'angle ====

[[File:Force longitudinale soudure angle cotes.svg|thumb|300px|Soudure d'angle soumise à une force longitudinale]]

Considérons deux plats soudés ; on effectue une traction symétrique sur chacun des plats, d'une intensité F. Nous négligeons le moment du couple et ne considérons que la force.

Cette force est parallèle au plan de gorge, c'est donc un effort tranchant. L'aire des plans de gorge, au nombre de deux, vaut
: S = ''n''×L×''a'' ; ''n'' = 2
et donc la contrainte, appelée « contrainte de cisaillement parallèle », vaut :
: &lt;math&gt;\tau_{//} = \frac{\mathrm{F}}{\mathrm{S}} = \frac{\mathrm{F}}{n \times \mathrm{L} \times a} &lt;/math&gt;.
Pour que la conception de la soudure soit validée, il faut que cette contrainte soit inférieure à la résistance pratique au glissement R&lt;sub&gt;pg&lt;/sub&gt;, qui est la limite élastique au glissement R&lt;sub&gt;eg&lt;/sub&gt; à laquelle on applique un coefficient de sécurité ''k'', R&lt;sub&gt;pg&lt;/sub&gt; = R&lt;sub&gt;eg&lt;/sub&gt;/''k'' :
: &lt;math&gt;\tau_{//} \leqslant \mathrm{R_{pg}} \Longrightarrow \frac{\mathrm{F}}{n \times \mathrm{L} \times a} \leqslant \frac{\mathrm{R_{eg}}}{k}&lt;/math&gt;.
Rappelons que pour un acier doux, dont notamment les aciers de construction, ou un alliage d'aluminium, on a R&lt;sub&gt;eg&lt;/sub&gt; ≈ R&lt;sub&gt;e&lt;/sub&gt;/2&lt;ref&gt;soit R&lt;sub&gt;eg&lt;/sub&gt; ≈ 0,5×R&lt;sub&gt;e&lt;/sub&gt; ; pour les aciers mi-durs, on a R&lt;sub&gt;eg&lt;/sub&gt; ≈ 0,7×R&lt;sub&gt;e&lt;/sub&gt;, et pour les aciers durs et les fontes, R&lt;sub&gt;eg&lt;/sub&gt; ≈ 0,8×R&lt;sub&gt;e&lt;/sub&gt;&lt;br /&gt;
voir {{ouvrage
 | prénom1 = Daniel | nom1 = Spenlé
 | prénom2 = Robert | nom2 = Gourhant
 | titre = Guide du calcul en mécanique
 | éditeur = Hachette technique
 | année = 2003
 | isbn = 2-01-16-8835-3
 | passage = 161
 }}&lt;/ref&gt;.

==== Étude d'une oreille de levage ====

[[File:Levage corps central electrolyseur bts roc 2009.svg|thumb|400px|Levage du corps central d'une cellule d'électrolyse.]]

Pour lever un ouvrage lourd, on utilise souvent des élingues que l'on relie à des oreilles de levage soudées. Nous considérons un électrolyseur utilisé pour fabriquer du dihydrogène à partir de l'eau ; il doit fonctionner à des températures allant de 120 à {{unité|160|°C}} sous des pressions de 30 à {{unité|70|bar}}.

L'électrolyseur est fait de plusieurs cellules contenues dans une virole en acier P295GH de diamètre extérieur {{unité|3100|mm}}, de longueur {{unité|3820|mm}} et d'épaisseur {{unité|40|mm}}. Lors du levage, les élingues font un angle α = {{unité|60|°}} avec l'horizontale. Le poids de l'ensemble vaut P = {{unité|200|kN}}, soit une traction de {{unité|116|kN}} sur chaque élingue.

{{clr}}

[[File:Projection force soudure angle complet alt.svg|thumb|400px|Projection du vecteur contrainte]]

Le système présente un plan de symétrie pour les charges comme pour les cordons, chaque cordon est donc sollicité de la même manière. L'aire de la gorge d'un cordon vaut
: S = ''a''×L = 10×350 = {{unité|3500|mm}}
donc l'intensité du vecteur contrainte pour un cordon vaut
: &lt;math&gt;\mathrm{T} = \frac{\mathrm{F}}{2\mathrm{S}} = \frac{\mathrm{F}}{2\times a \times \mathrm{L}} = \frac{116\,000}{2\times 10 \times 350} = 16,6\ \mathrm{MPa}&lt;/math&gt;
On considère le repère local du plan de gorge. Le vecteur contrainte s'exprime par ses composantes &lt;math&gt;(\tau_{//}, \tau_\perp, \sigma_\perp)&lt;/math&gt;. On peut obtenir ces composantes en appliquant la matrice de changement de repère
: &lt;math&gt;\begin{pmatrix}
\tau_{//} \\
\tau_\perp \\
\sigma_\perp \\
\end{pmatrix}
=
\begin{pmatrix}
1 &amp; 0 &amp; 0 \\
0 &amp; \cos 45^\mathrm{o} &amp; -\sin 45^\mathrm{o} \\
0 &amp; \sin 45^\mathrm{o} &amp; \cos 45^\mathrm{o} \\
\end{pmatrix}
\begin{pmatrix}
\mathrm{T}_x \\ \mathrm{T}_y \\ \mathrm{T}_z \\
\end{pmatrix}
&lt;/math&gt;
soit
: &lt;math&gt;\begin{pmatrix}
\tau_{//} \\
\tau_\perp \\
\sigma_\perp \\
\end{pmatrix}
=
\begin{pmatrix}
1 &amp; 0 &amp; 0\\
0 &amp; \cos 45^\mathrm{o} &amp; -\sin 45^\mathrm{o} \\
0 &amp; \sin 45^\mathrm{o} &amp; \cos 45^\mathrm{o} \\
\end{pmatrix}
\begin{pmatrix}
\mathrm{T} \cos \alpha \\ \mathrm{T} \sin \alpha \\ 0 \\
\end{pmatrix}
&lt;/math&gt;
: &lt;math&gt;\begin{pmatrix}
\tau_{//} \\
\tau_\perp \\
\sigma_\perp \\
\end{pmatrix}
=
\begin{pmatrix}
8,29 \\ 10,1 \\ 10,1
\end{pmatrix}
&lt;/math&gt; (MPa).
On peut aussi obtenir ce résultat de manière géométrique — voire graphique — plutôt qu'algébrique : on commence par projeter le vecteur contrainte sur les axes horizontaux et verticaux
: &lt;math&gt; \left \{
\begin{matrix}
\mathrm{T_h} = \tau_{//} = \mathrm{T}\times \cos 60^\mathrm{o} = 8,29\ \mathrm{MPa} \\
\mathrm{T_v} = \mathrm{T}\times \sin 60^\mathrm{o} = 14,4\ \mathrm{MPa} \\
\end{matrix}
\right .
&lt;/math&gt;
Puis on décompose la composante verticale :
: &lt;math&gt;\left \{
\begin{matrix}
\tau_\perp = \mathrm{T_v} \times \cos 45^\mathrm{o} = 10,1\ \mathrm{MPa} \\
\sigma_\perp = \mathrm{T_v} \times \sin 45^\mathrm{o} = 10,1\ \mathrm{MPa} \\
\end{matrix}
\right .
&lt;/math&gt;.
Comme nous sommes en présence à la fois de contrainte normale et de cisaillement, on calcule une contrainte équivalente σ&lt;sub&gt;e&lt;/sub&gt;, par exemple de {{pc|von Mises}} :
: &lt;math&gt;\sigma_\mathrm{e\ vM} = \sqrt{\sigma^2 + 3 \times \tau^2} = \sqrt{\sigma_\perp^2 + 3 \times (\tau_{//}^2 + \tau_\perp^2)} = \sqrt{10,1^2 + 3 \times (8,29^2 + 10,1^2)} = 24,8\ \mathrm{MPa}&lt;/math&gt;
ou bien de {{pc|Tresca}}
: &lt;math&gt;\sigma_\mathrm{e\ T} = \sqrt{\sigma^2 + 4 \times \tau^2} = \sqrt{\sigma_\perp^2 + 4 \times (\tau_{//}^2 + \tau_\perp^2)} = \sqrt{10,1^2 + 4 \times (8,29^2 + 10,1^2)} = 28\ \mathrm{MPa}&lt;/math&gt;

On compare ensuite cette contrainte à la résistance pratique à l'extension ; ici, R&lt;sub&gt;e&lt;/sub&gt; = {{unité|295|MPa}}, si l'on prend un coefficient de sécurité ''k'' = 2, on a R&lt;sub&gt;pe&lt;/sub&gt; = {{unité|147|MPa}}.

Concernant le choix entre {{pc|von Mises}} et {{pc|Tresca}}, citons Jean-Louis {{pc|Fanchon}} :
: Si, pour les matériaux ductiles, von Mises est un peu plus précis que Tresca, de nombreuses vérifications expérimentales ont donné des résultats situés sur la frontière entre les deux critères. Tresca, plus simple et souvent utilisé, est plus conservatif&lt;ref&gt;prudent&lt;/ref&gt; en laissant une marge de sécurité légèrement plus grande. Cependant, beaucoup de programmes commerciaux d'analyse des contraintes et d'éléments finis s'appuient sur von Mises ; de ce fait, il existe une tendance naturelle à utiliser celui-ci en toutes circonstances.
: {{ouvrage
 | auteur = Jean-Louis Fanchon
 | titre = Guide de mécanique — Sciences et technologies industrielles
 | éditeur = Nathan/VUEF
 | année = 2001
 | isbn = 2-09-178965 - 8
 | passage = 445}}

==== Prise en compte des moments ====

[[Fichier:Cordon soudure moment negligeable.svg|thumb|Cas où le moment d'encastrement est négligeable]]

L'étude de la résistance d'un cordon de soudure devrait prendre en compte les moments (couples). Cependant, dans de nombreux cas, le bras de levier est faible donc le moment négligeable. Mais ce n'est pas toujours le cas.

{{clr}}

Rappelons le calcul du moment d'encastrement dans deux cas (l'encastrement étant ici réalisé par la soudure).

{|class=&quot;wikitable&quot;
|+ Calcul du moment d'encastrement &lt;nowiki&gt;[&lt;/nowiki&gt;[[Résistance des matériaux/Formulaire des poutres simples - Efforts de cohésion|1]]&lt;nowiki&gt;]&lt;/nowiki&gt;
! Cas !! Illustration !! Moment d'encastrement
|-
! Poutre encastrée&lt;br /&gt;(console)
| [[Fichier:Poutre appuis console charge ponctuelle stat.svg]]
| M&lt;sub&gt;A&lt;/sub&gt; = F×L
|-
! Poutre biencastrée
| [[Fichier:Poutre appuis biencastree charge ponctuelle stat.svg]]
| M&lt;sub&gt;A&lt;/sub&gt; = -M&lt;sub&gt;B&lt;/sub&gt; = F×L/8
|}

[[Fichier:Superposition contraintes flexion torsion.svg|thumb|400px|Répartition de la contrainte dans le cas de la flexion, de la torsion et d'une superposition des deux]]

[[Fichier:Torsion section rectangulaire pleine axes eurocode 3.svg|thumb|Torsion d'une section rectangulaire pleine]]

Un moment se traduit par une répartition linéaire de la contrainte : la contrainte générée est nulle au centre de gravité de la section, et croît de manière linéaire lorsque l'on s'en éloigne : contrainte normale pour un moment fléchissant M&lt;sub&gt;f&lt;/sub&gt;, contrainte de cisaillement pour un moment de torsion M&lt;sub&gt;t&lt;/sub&gt;. On s'intéresse aux extrémités du cordon de soudure, là où les contraintes sont les plus élevées ; on a :
* &lt;math&gt;\sigma_\max = \frac{\mathrm{M_f}}{\mathrm{W}}&lt;/math&gt;, s'ajoute à &lt;math&gt;\sigma_\perp&lt;/math&gt; ;
* &lt;math&gt;\tau_{\max\ //} = \frac{\mathrm{M_t}}{\mathrm{C}_{//}}&lt;/math&gt;, s'ajoute à &lt;math&gt;\tau_{//}&lt;/math&gt; ;
* &lt;math&gt;\tau_{\max\ \perp} = \frac{\mathrm{M_t}}{\mathrm{C}_{\perp}}&lt;/math&gt;, s'ajoute à &lt;math&gt;\tau_{\perp}&lt;/math&gt; ;
avec, pour une section rectangulaire de dimensions ''b''×''h'' (''h'' ≥ ''b'') :
* module de flexion transversal : W = ''b''×''h''&lt;sup&gt;2&lt;/sup&gt;/6 ;
* module de flexion longitudinal : W = ''h''×''b''&lt;sup&gt;2&lt;/sup&gt;/6 ;
* constante de torsion sur l'axe parallèle : C&lt;sub&gt;//&lt;/sub&gt; = ''h''×''b''&lt;sup&gt;2&lt;/sup&gt;/3&lt;ref&gt;le coefficient dépend du rapport ''h''/''b'', nous supposons ici un rapport supérieur à 10 ; pour plus de précision, pour un rapport ''h''/''b'' supérieur ou égal à 5, on peut prendre&lt;br /&gt; C = ''k''&lt;sub&gt;1&lt;/sub&gt;×''h''×''b''&lt;sup&gt;2&lt;/sup&gt;&lt;br /&gt; avec ''k''&lt;sub&gt;1&lt;/sub&gt; = (1 - 0,63×''b''/''h'')/3&lt;br /&gt; voir {{ouvrage
 | prénom1=Jean-Louis | nom1 = Fanchon
 | titre = Guide de mécanique
 | éditeur = Nathan
 | année = 2001
 | isbn = 978-2-09-178965-1
 | passage = 315
}}&lt;/ref&gt; ;
* constante de torsion sur l'axe perpendiculaire : C&lt;sub&gt;&amp;perp;&lt;/sub&gt; = C&lt;sub&gt;//&amp;thinsp;&lt;/sub&gt;/0,742&lt;ref&gt;comme précédemment, nous avons supposé un rapport L/''a'' supérieur ou égal à 10 ; dans le cas général, on a &lt;br /&gt; C&lt;sub&gt;&amp;perp;&lt;/sub&gt; = C&lt;sub&gt;//&amp;thinsp;&lt;/sub&gt;/η&lt;br /&gt; où η dépend du rapport ''h''/''b'', mais varie très lentement : η = 0,743 pour un rapport de 6 &lt;br /&gt; voir [http://rdmestp.voila.net/poly/TP1_C11.pdf Torsion (ESTP)] p. 5&lt;/ref&gt;.
Notons que dans le cas d'une combinaison flexion transversale+torsion, la contrainte normale maximale n'est pas au même endroit que la contrainte de cisaillement maximal.

{{clr}}

==== Cordons de soudure multiples ====

Chaque cordon de soudure réalise une liaison encastrement. Avec la statique, on peut donc déterminer les efforts ''globaux'' qui s'exercent sur les cordons reliant deux pièces ; mais si l'on s'intéresse aux cordons ''individuellement'', on se retrouve face à un problème hyperstatique. La résolution analytique est bien trop complexe. On peut résoudre ce problème avec la méthode des éléments finis (calcul sur ordinateur). Cependant, certaines hypothèses permettent de faire un calcul approché à la main.

Lorsque le problème présente une symétrie des cordons de soudure ''et'' du chargement, alors l'effort se répartit équitablement sur chacun de cordons.

Sinon, il faut répartir les efforts en fonction de l'orientation des soudures, en appliquant les règles (simplifications) suivantes&lt;ref&gt;{{article| nom1 = Michel | prénom1 = Alain
 | titre = Pièces mécaniques soudées — Calcul des assemblages
 | journal = Techniques de l'ingénieur
 | année = 2006
 | numéro = BM 5 187
 | passage = 6
}}&lt;/ref&gt; :
* forces :
** si un cordon est parallèle à une force, alors il reprend intégralement cette force ;
** si plusieurs cordons sont dans ce cas, alors la force est répartie proportionnellement à l'aire de la section de la gorge ;
* moment :
** si un cordon est parallèle à un vecteur moment, alors il reprend intégralement ce moment ;
** si plusieurs cordons sont dans ce cas, alors le moment est réparti proportionnellement au moment quadratique de la section de la gorge.

==== Étude de la liaison d'un pied sur une cuve ====

[[File:Filtre vin perspective roulettes bacpro rocsm 2008.png|thumb|Mise en situation : filtre à vin]]

Nous étudions un filtre à vin utilisé dans une entreprise de stockage et de distribution du vin en gros. ce filtre est mobile pour pouvoir être amené aux différentes cuves. Le filtre est donc sur roulettes ; les pieds sont soudés sur la cuve. Les pieds sont en tube carré de section □115&lt;sub&gt;ext&lt;/sub&gt; ép.8 et font un angle de {{unité|45|°}} avec l'horizontale.

On détermine que l'action maximale du sol sur un pied est F = {{unité|1000|daN}}. La limite élastique de la soudure vaut R&lt;sub&gt;e&lt;/sub&gt; = {{unité|250|MPa}}, et le coefficient de sécurité vaut ''k'' = 2.

{{clr}}

[[File:Liaison pied filtre vin bacpro rocsm 2008 alt.svg|thumb|Soudure entre le pied et la cuve]]

L'effort d'encastrement au niveau de la soudure comprend donc :
* une force F = {{unité|10000|N}} ;
* un moment M = F×L = {{formatnum:10000}}×1,06 = {{unité|10600|Nm}} (L étant la longueur du bras de levier).
La force génère une contrainte de cisaillement
: &lt;math&gt;\tau_{//} = \frac{\mathrm{F}}{2\mathrm{L'}a} = \frac{10\,000}{2 \times 145 \times 5} = 6,90\ \mathrm{MPa}&lt;/math&gt;
La variable L' est ici la longueur du cordon de soudure, et il y a deux cordons symétriques.

{{clr}}

[[Fichier:Soudure pied cuve projection moment.svg|thumb|Projection du vecteur moment ; le plan de gorge est vu en bout.]]

Le vecteur moment se projette dans le plan de gorge selon M&lt;sub&gt;f&lt;/sub&gt;, un moment fléchissant, et perpendiculairement à ce plan selon M&lt;sub&gt;t&lt;/sub&gt;, un moment de torsion. On a :
: &lt;math&gt;\left \{ \begin{matrix}
\mathrm{M_f} = \mathrm{M} \times \cos 45^{\mathrm{o}} = 7\,500\ \mathrm{Nm} \\
\mathrm{M_t} = \mathrm{M} \times \sin 45^{\mathrm{o}} = 7\,500\ \mathrm{Nm} \\
\end{matrix} \right .&lt;/math&gt;

Les caractéristiques de la section sont :
* W = ''a''×L'&lt;sup&gt;2&lt;/sup&gt;/6 = 5×145&lt;sup&gt;2&lt;/sup&gt;/6 = {{unité|17500|mm|3}} (flexion transversale) ;
* C&lt;sub&gt;//&lt;/sub&gt; = L'×''a''&lt;sup&gt;2&lt;/sup&gt;/3 = 145×5&lt;sup&gt;2&lt;/sup&gt;/3 = {{unité|1210|mm|3}} (on a bien L'/''a'' &amp;gt; 10) ;
* C&lt;sub&gt;&amp;perp;&lt;/sub&gt; = C&lt;sub&gt;//&amp;thinsp;&lt;/sub&gt;/0,742 = L'×''a''&lt;sup&gt;2&lt;/sup&gt;/3/0,742 = {{unité|1630|mm|3}}.
On en déduit (il y a deux cordons symétriques ; attention aux unités, on a utilisé des m pour le moment et des mm pour les caractéristiques de la section) :
* &lt;math&gt;\sigma_\max = \frac{\mathrm{M_f}}{2 \mathrm{W}} = \frac{\mathrm{F} \times \mathrm{L} \times \cos 45^{\mathrm{o}} \times 6}{2 \times a \times \mathrm{L}'^2} = 214\ \mathrm{MPa}&lt;/math&gt;
* &lt;math&gt;\tau_{\max //} = \frac{\mathrm{M_t}}{2 \mathrm{C}_{//}} = \frac{\mathrm{F} \times \mathrm{L} \times \sin 45^{\mathrm{o}} \times 3} {2 \times \mathrm{L}' \times a^2} = 3\,100\ \mathrm{MPa}&lt;/math&gt;.
Il n'est pas nécessaire d'aller au bout du calcul : la contrainte maximale de cisaillement générée par la torsion est largement supérieure à la limite élastique en cisaillement ({{formatnum:3100}} &amp;gt;&amp;gt; 125, τ&lt;sub&gt;// max&lt;/sub&gt; &amp;gt;&amp;gt; R&lt;sub&gt;eg&lt;/sub&gt;).

{{clr}}

[[Fichier:Soudure pied cuve peripherique.svg|thumb|Modèle pour le cordon de soudure périphérique.]]

Considérons une autre conception avec un cordon de soudure périphérique de largeur de gorge uniforme ''a'' = {{unité|5|mm}}. On peut considérer qu'il y a quatre cordons : deux horizontaux et deux verticaux.

D'après la règle de répartition vue précédemment :
* les cordons verticaux supportent intégralement la force verticale F ;
* les cordons horizontaux supportent intégralement le moment d'axe horizontal M.
Dans les cordons verticaux, on a donc uniquement une contrainte de cisaillement uniforme
: τ&lt;sub&gt;//&lt;/sub&gt; = {{unité|6.90|MPa}}.
La résistance pratique au glissement vaut
: R&lt;sub&gt;pg&lt;/sub&gt; = R&lt;sub&gt;eg&lt;/sub&gt;/''k'' = R&lt;sub&gt;e&lt;/sub&gt;/(2''k'') = 250/(2*2) = {{unité|62.5|MPa}}.
On a ainsi 6,90 ≤ 25 soit τ&lt;sub&gt;//&lt;/sub&gt; ≤ R&lt;sub&gt;pg&lt;/sub&gt; donc les cordons verticaux sont validés.

Comme les cordons horizontaux sont espacés, on peut considérer que la contrainte est uniforme dans chaque cordon et que le couple M est sous la forme d'un couple de forces &lt;math&gt;(\vec{\mathrm{F}}_1, -\vec{\mathrm{F}}_1)&lt;/math&gt; distantes de ''d'' = {{unité|163|mm}} = {{unité|0.163|m}} :
: F&lt;sub&gt;1&lt;/sub&gt; = M/''d'' = F×L/''d'' = {{unité|65000|N}}.
Le vecteur contrainte a pour norme
: T = F&lt;sub&gt;1&lt;/sub&gt;/S = F×L/''d''/''a''/L&quot; = {{unité|113|MPa}}.
soit
: &lt;math&gt;\left \{ \begin{align}
\tau_{//} = &amp; \ 0 \\
\tau_\perp = &amp; \ \mathrm{T} \times \cos 22,5^{\mathrm{o}} = 104\ \mathrm{MPa} \\
\sigma_\perp = &amp; \ \mathrm{T} \times \sin 22,5^{\mathrm{o}} = 43,3\ \mathrm{MPa} \\
\end{align} \right .&lt;/math&gt;
La contrainte équivalente de {{pc|von Mises}} vaut
: &lt;math&gt;\sigma_{\mathrm{e\ vM}} = \sqrt{\sigma_\perp^2 + 3 \tau_\perp ^2} = 186\ \mathrm{MPa}&lt;/math&gt;.
Cette contrainte est inférieure à la limite élastique, mais hors de la zone de sécurité puisque la résistance pratique à l'extension vaut R&lt;sub&gt;pe&lt;/sub&gt; = R&lt;sub&gt;e&lt;/sub&gt;/''k'' = {{unité|125|MPa}}. Le coefficient de sécurité effectif vaut ''k''&lt;sub&gt;eff&lt;/sub&gt; = 250/186 = 1,3. Le cordon n'est donc pas validé.

=== Normes de calcul des soudures ===

[[Fichier:Nomenclature contraintes dans une soudure.svg|vignette|Nomenclature des contraintes dans un cordon de soudure.]]

Les normes reprennent la démarche utilisée précédemment. Le critère général est
: &lt;math&gt;\sqrt{\sigma_\perp^2 + \lambda \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \alpha \times \mathrm{R_e}&lt;/math&gt;
où
* λ est un coefficient établi expérimentalement ; il allait de 1,8 à 2 dans les années 1970&lt;ref&gt;par exemple norme CM66 (décembre 1966)&lt;/ref&gt;, il est établi actuellement entre 2,5 et 3 ; il vaut 3 si l'on considère le critère de {{pc|von Mises}} et 4 si l'on considère le critère de {{pc|Tresca}} ;
* α est un coefficient de qualité ; β = 1/α est le coefficient de sécurité.
Outre ce coefficient de qualité de soudure, on applique un coefficient de pondération de charge ''k''&lt;sub&gt;p&lt;/sub&gt; en fonction du domaine (typiquement, ''k''&lt;sub&gt;p&lt;/sub&gt; = 1,5 pour une oreille de levage) ; l'effort retenu est l'effort nominal multiplié par ce coefficient. Le coefficient de sécurité total vaut donc
: ''k'' = ''k''&lt;sub&gt;p&lt;/sub&gt;/α = ''k''&lt;sub&gt;p&lt;/sub&gt;β
(les notations ''k'', α et β diffèrent selon les normes).

Dans les normes récentes, citons

==== Acier — norme Afnor NF P 22-470 (1989) ====

: &lt;math&gt;\left \{ \begin{matrix}
k \times \sqrt{\sigma_\perp^2 + 3 \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \sigma_\mathrm{e} \\
\mathrm{et}\ \sigma_\perp \leqslant \sigma_\mathrm{e}
\end{matrix} \right .&lt;/math&gt;
avec
* ''k'' : coefficient fonction du matériau,
** ''k'' = 0,7 pour un acier S235 (1.038),
** ''k'' = 0,85 pour un acier S275 (1.044),
** ''k'' = 1 pour un acier S355 (1.0045) à S460N (1.8901)
* &amp;sigma;&lt;sub&gt;e&lt;/sub&gt; : limite d'élasticité du métal.

==== Acier — Eurocode 3 (1993) ====

: &lt;math&gt;\left \{ \begin{matrix}
\beta_\mathrm{w} \times \sqrt{\sigma_\perp^2 + 3 \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \frac{\mathrm{f_u}}{\gamma_{\mathrm{M2}}} \\
\mathrm{et}\ \sigma_\perp \leqslant 0,9\frac{\mathrm{f_u}}{\gamma_{\mathrm{M2}}}\end{matrix} \right .&lt;/math&gt;
avec
* β&lt;sub&gt;w&lt;/sub&gt; : facteur de corrélation allant de 0,7 à 1,8 ;
* f&lt;sub&gt;u&lt;/sub&gt; : résistance ultime de l’acier R&lt;sub&gt;m&lt;/sub&gt; ;
* γ&lt;sub&gt;M2&lt;/sub&gt; : coefficient partiel de sécurité de résistance à la rupture des sections transversales en traction, valant 1,25 [EN 1993-1-1:2005]

{| class=&quot;wikitable&quot;
|+ Coefficients selon la nuance d'acier
|-
! Nuance !! f&lt;sub&gt;u&lt;/sub&gt; (R&lt;sub&gt;m&lt;/sub&gt;)&lt;br /&gt;(MPa) !! β&lt;sub&gt;w&lt;/sub&gt; !! γ&lt;sub&gt;M2&lt;/sub&gt;
|-
| S235 || 360 || 0,8 || 1,25
|-
| S275 || 430 || 0,85 || 1,30
|-
| S355 || 510 || 0.9 || 1,35
|}

==== Alliage d'aluminium — Eurocode 9 (1999) ====

: &lt;math&gt;\frac{1}{\alpha \beta \gamma} \times \sqrt{\sigma_\perp^2 + 3 \times (\tau_\perp^2 + \tau_{//}^2)} \leqslant \mathrm{R_e}&lt;/math&gt;
avec
* α : coefficient de qualité d'exécution allant de 0,7 (soudure difficile à réaliser) à 1 (cordon de soudure travaillant en compression, ou bien soudure réalisé dans de bonnes conditions) ;
* β : coefficient d'efficacité métallurgiqure allant de 0,43 à 1 selon les nuances d'alliage ;
* γ : coefficient de prise en compte d'autres phénomènes allant de 0,8 à 1.
Le tableau ci-dessous utilise les [[Désignation normalisée des alliages d'aluminium|désignations normalisées européennes]] (5083 désigne l'EN AW-5083[AlMg4,5Mn0,7], 42100 désigne l'EN AC-42100[AlSi7Mg0,3]) ; on indique l'ancienne désignation française entre parenthèses.

{| class=&quot;wikitable&quot;
|+ Coefficients selon la nuance d'alliage d'aluminium
|-
! Type de pièce !! Métal de base !! État métallurgique&lt;br /&gt;&lt;nowiki&gt;[&lt;/nowiki&gt;[[wikipedia:fr:Alliages d'aluminium pour corroyage#Les états métallurgiques des alliages d'aluminium pour corroyage|1]]&lt;nowiki&gt;]&lt;/nowiki&gt; &lt;nowiki&gt;[&lt;/nowiki&gt;[[wikipedia:fr:Alliages d'aluminium pour fonderie#Les états de livraison des pièces moulées |2]]&lt;nowiki&gt;]&lt;/nowiki&gt; !! Métal d'apport !! β !! γ
|-
! rowspan=&quot;9&quot; | Corroyé
| 5083 (AG4MC) || 0, H111&lt;br /&gt; H116 || 5356, 5183&lt;br /&gt;5356, 5183 || 1&lt;br /&gt;0,58 || 1&lt;br /&gt;1
|-
| 5086 (A-G5MC) || 0, H111&lt;br /&gt; H116 || 5356, 5183&lt;br /&gt;5356, 5183 || 1&lt;br /&gt;0,51 || 1&lt;br /&gt;1
|-
| 5454 (A-G2,7M0,7) || H24&lt;br /&gt; H111 || 5356, 5183&lt;br /&gt;5356, 5183 || 0,43&lt;br /&gt;1 || 1&lt;br /&gt;1
|-
| 5754 (A-G3M) || H111 || 5356, 5183 || 1 || 1&lt;br /&gt;1
|-
| 6005A (A-SG0,5MC) || T5&lt;br /&gt; T5 || 5356, 5183&lt;br /&gt;4043 || 0,50&lt;br /&gt;0,45 || 1&lt;br /&gt;0,90
|-
| 6060 (A-GS) || T5&lt;br /&gt; T5 || 5356, 5183&lt;br /&gt;4043 || 0,56&lt;br /&gt;0,56 || 1&lt;br /&gt;1
|-
| 6061 (A-GSUC) || T6&lt;br /&gt; T6 || 5356, 5183&lt;br /&gt;4043 || 0,53&lt;br /&gt;0,53 || 1&lt;br /&gt;0,80
|-
| 6082 (A-SGM0,7) || T6&lt;br /&gt; T6 || 5356, 5183&lt;br /&gt;4043 || 0,49&lt;br /&gt;0,49 || 1&lt;br /&gt;0,80
|-
| 6106 || T5&lt;br /&gt; T5 || 5356&lt;br /&gt;4043 || 0,45&lt;br /&gt;0,45 || 1&lt;br /&gt;1
|-
! rowspan=&quot;4&quot; | Fonderie
| 42100 (A-S7G0,3) || KT6 (Y33) || 4043 || 0,55 || 0,80
|-
| 42200 (A-S7G0,6) || KT6 (Y33) || 4047 || 0,55 || 0,80
|-
| 44200 (A-S13) || SF (Y20) || 4043, 4047 || 1 || 1
|-
| 71000 (A-Z5G) || ST64 (Y29) || 5356, 5280 || 0,80 || 0,80
|}

== Voir aussi ==

=== Bibliographie ===

* {{ouvrage
 | nom1 = Hazard | prénom1 = Claude
 | nom2 = Lelong | prénom2 = Frédy
 | nom3 = Quinzain | prénom3 = Bruno
 | titre = Mémotech — Structures métalliques
 | éditeur = Casteilla
 | lieu = Paris
 | année = 1997
 | isbn = 2-7135-1751-6
 | passage = 249-292
}}
* {{ouvrage
 | nom1 = Chevalier | prénom1 = André
 | titre = Guide du dessinateur industriel
 | éditeur = Hachette
 | lieu = Paris
 | année = 2004
 | isbn = 978-2-01-168831-6
 | passage = 172-179
}}
* {{ouvrage
 | nom1 = Fanchon | prénom1 = Jean-Louis
 | titre = Guide des sciences et technologies industrielles
 | éditeur = Nathan/Afnor | lieu = Paris
 | année = 2011
 | isbn = 978-2-09-161590-5
 | passage = 223-244
}}

== Notes et références ==

&lt;references /&gt;

----
&amp;lt; ''[[../Généralités|Généralités]]'' — ''[[../Soudage par friction|Soudage par friction]]'' &amp;gt;</text>
      <sha1>e698kbly4v9dcbrnum8hkiaqk197kup</sha1>
    </revision>
  </page>
  <page>
    <title>Discussion utilisateur:Xhungab</title>
    <ns>3</ns>
    <id>55548</id>
    <revision>
      <id>772343</id>
      <parentid>772191</parentid>
      <timestamp>2026-09-17T08:02:06Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>772343</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3136" sha1="5xkh0lb5mv32xorjsi55fs4i2mf40g2" xml:space="preserve">
&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;
{| class=&quot;flexible&quot; style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;
|
&lt;div style=&quot;width:auto; text-align:center;&quot;&gt;

&lt;div id=&quot;mf-banner1&quot; style=&quot;font-size:162%; padding:0.1em;&quot;&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]],&lt;/div&gt;
&lt;div id=&quot;mf-banner2&quot; style=&quot;font-size:95%; margin-top:0.2em;&quot;&gt;{{Bloc|La bibliothèque}} {{Bloc|de livres pédagogiques libres}} {{Bloc|que chacun peut améliorer.}}&lt;/div&gt;
&lt;div style=&quot;text-align:center; font-size:95%; margin:0;&quot;&gt;[[Wikilivres:Présentation|Wikilivres ?]] • [[Wikilivres|Aide]] • [[Wikilivres:Accueil|Communauté]]&lt;/div&gt;
&lt;div id=&quot;pagecount&quot; style=&quot;font-size:85%;&quot;&gt;[[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres]] contenant [[Special:Allpages|{{NUMBEROFARTICLES}} pages]].&lt;/div&gt;
&lt;/div&gt;

'''Dans cette page, vous trouverez en particulier des livres en construction, vous pourrez entrer en contact avec les auteurs. Vous trouverez aussi des livres en construction sans auteur actif que vous pourrez compléter.'''

{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |
[[Fichier:Book icon.png|100px|link=Wikilivres:Tous les livres]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Histoire|Histoire]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Technologie|Technologie]]
* [[:Catégorie:Informatique|Informatique]]
| style=&quot;width:25%;&quot; |
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
|}

&lt;div style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;&gt;
&lt;div id=&quot;mf-index&quot; title=&quot;Index des livres&quot; class=&quot;only_mobile&quot;&gt;
* [[:Catégorie:Classe 7 - Arts. Divertissements. Sports|Arts]]
* [[:Catégorie:Informatique|Informatique]]
* [[:Catégorie:Classe 8 - Langue. Linguistique. Littérature|Langues]]
* [[:Catégorie:Loisirs|Loisirs]]
* [[:Catégorie:Classe 5 - Mathématique. Sciences exactes et naturelles|Sciences]]
* [[:Catégorie:Sciences humaines|Sciences humaines]]
* [[:Catégorie:Technologie|Technologie]]
* '''[[Wikilivres:Tous les livres|Tous les livres]]'''
&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>5xkh0lb5mv32xorjsi55fs4i2mf40g2</sha1>
    </revision>
  </page>
  <page>
    <title>Utilisateur:Xhungab</title>
    <ns>2</ns>
    <id>56767</id>
    <revision>
      <id>772268</id>
      <parentid>772232</parentid>
      <timestamp>2026-09-16T12:22:10Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>772268</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3407" sha1="ppudzhzy5ziw30aal8jt3w68rzkx44v" xml:space="preserve">
&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;
{| class=&quot;flexible&quot; style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;
|
&lt;div style=&quot;width:auto; text-align:center;&quot;&gt;

&lt;div id=&quot;mf-banner1&quot; style=&quot;font-size:162%; padding:0.1em;&quot;&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]],&lt;/div&gt;
&lt;div id=&quot;mf-banner2&quot; style=&quot;font-size:95%; margin-top:0.2em;&quot;&gt;{{Bloc|La bibliothèque}} {{Bloc|de livres pédagogiques libres}} {{Bloc|que chacun peut améliorer.}}&lt;/div&gt;
&lt;div style=&quot;text-align:center; font-size:95%; margin:0;&quot;&gt;[[Wikilivres:Présentation|Wikilivres ?]] • [[Wikilivres|Aide]] • [[Wikilivres:Accueil|Communauté]]&lt;/div&gt;
&lt;div id=&quot;pagecount&quot; style=&quot;font-size:85%;&quot;&gt;[[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres]] contenant [[Special:Allpages|{{NUMBEROFARTICLES}} pages]].&lt;/div&gt;
&lt;/div&gt;
| style=&quot;width:55%; font-size:95%;&quot; |
{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |
[[Fichier:Book icon.png|100px|link=Wikilivres:Tous les livres]]
| style=&quot;width:50%;&quot; |
* [[:Catégorie:Livres terminés|Livres disponibles]]
* [[:Catégorie:Minilivres|Mini Livres disponibles]]
| style=&quot;width:10%;&quot; |

| style=&quot;width:0%;&quot; |
 
|}
|}

&lt;div class=&quot;livre-accueil-section2&quot; style=&quot;clear:both; margin:33px 0px 33px 0px; padding:0px;&quot;&gt;
{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}
&lt;/div&gt;

&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''Nouveautés et Projets en construction actifs[[:Catégorie:Nouveaux livres|:]]''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

'''[https://fr.wikibooks.org/wiki/Discussion_utilisateur:Xhungab Les coulisses de Wikibook]'''  

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>ppudzhzy5ziw30aal8jt3w68rzkx44v</sha1>
    </revision>
    <revision>
      <id>772271</id>
      <parentid>772268</parentid>
      <timestamp>2026-09-16T12:37:55Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>772271</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3374" sha1="qkpizuw0qrts4g58c8wt2tchq3b4fbe" xml:space="preserve">
&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;
{| class=&quot;flexible&quot; style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;
|
&lt;div style=&quot;width:auto; text-align:center;&quot;&gt;

&lt;div id=&quot;mf-banner1&quot; style=&quot;font-size:162%; padding:0.1em;&quot;&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]],&lt;/div&gt;
&lt;div id=&quot;mf-banner2&quot; style=&quot;font-size:95%; margin-top:0.2em;&quot;&gt;{{Bloc|La bibliothèque}} {{Bloc|de livres pédagogiques libres}} {{Bloc|que chacun peut améliorer.}}&lt;/div&gt;
&lt;div style=&quot;text-align:center; font-size:95%; margin:0;&quot;&gt;[[Wikilivres:Présentation|Wikilivres ?]] • [[Wikilivres|Aide]] • [[Wikilivres:Accueil|Communauté]]&lt;/div&gt;
&lt;div id=&quot;pagecount&quot; style=&quot;font-size:85%;&quot;&gt;[[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres]] contenant [[Special:Allpages|{{NUMBEROFARTICLES}} pages]].&lt;/div&gt;
&lt;/div&gt;
| style=&quot;width:55%; font-size:95%;&quot; |
{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |
[[Fichier:Book icon.png|100px|link=Wikilivres:Tous les livres]]
| style=&quot;width:50%;&quot; |
* [[:Catégorie:Livres terminés|Livres disponibles]]
* [[:Catégorie:Minilivres|Mini Livres disponibles]]
| style=&quot;width:10%;&quot; |

| style=&quot;width:0%;&quot; |
 
|}
|}

&lt;div class=&quot;livre-accueil-section2&quot; style=&quot;clear:both; margin:33px 0px 33px 0px; padding:0px;&quot;&gt;
{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}
&lt;/div&gt;

&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés :]]''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;
&lt;/div&gt;

'''[https://fr.wikibooks.org/wiki/Discussion_utilisateur:Xhungab Les coulisses de Wikibook]'''  

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>qkpizuw0qrts4g58c8wt2tchq3b4fbe</sha1>
    </revision>
    <revision>
      <id>772312</id>
      <parentid>772271</parentid>
      <timestamp>2026-09-16T15:51:06Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>772312</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3374" sha1="hshundbrh88ns5y3g7vfyqgaitv2109" xml:space="preserve">
&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;
{| class=&quot;flexible&quot; style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;
|
&lt;div style=&quot;width:auto; text-align:center;&quot;&gt;

&lt;div id=&quot;mf-banner1&quot; style=&quot;font-size:162%; padding:0.1em;&quot;&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]],&lt;/div&gt;
&lt;div id=&quot;mf-banner2&quot; style=&quot;font-size:95%; margin-top:0.2em;&quot;&gt;{{Bloc|La bibliothèque}} {{Bloc|de livres pédagogiques libres}} {{Bloc|que chacun peut améliorer.}}&lt;/div&gt;
&lt;div style=&quot;text-align:center; font-size:95%; margin:0;&quot;&gt;[[Wikilivres:Présentation|Wikilivres ?]] • [[Wikilivres|Aide]] • [[Wikilivres:Accueil|Communauté]]&lt;/div&gt;
&lt;div id=&quot;pagecount&quot; style=&quot;font-size:85%;&quot;&gt;[[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres]] contenant [[Special:Allpages|{{NUMBEROFARTICLES}} pages]].&lt;/div&gt;
&lt;/div&gt;
| style=&quot;width:55%; font-size:95%;&quot; |
{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |
[[Fichier:Book icon.png|100px|link=Wikilivres:Tous les livres]]
| style=&quot;width:50%;&quot; |
* [[:Catégorie:Livres terminés|Livres disponibles]]
* [[:Catégorie:Minilivres|Mini Livres disponibles]]
| style=&quot;width:10%;&quot; |

| style=&quot;width:0%;&quot; |
 
|}
|}

&lt;div class=&quot;livre-accueil-section2&quot; style=&quot;clear:both; margin:33px 0px 33px 0px; padding:0px;&quot;&gt;
{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}
&lt;/div&gt;

&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés :]]''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;'''[https://fr.wikibooks.org/wiki/Discussion_utilisateur:Xhungab ... Les coulisses de Wikibook]'''
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>hshundbrh88ns5y3g7vfyqgaitv2109</sha1>
    </revision>
    <revision>
      <id>772342</id>
      <parentid>772312</parentid>
      <timestamp>2026-09-17T08:01:00Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>772342</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3372" sha1="3o9vsgk4udficjugme13yxzcl8da4t9" xml:space="preserve">
&lt;templatestyles src=&quot;Main Page/minerva.css&quot; /&gt;
&lt;div style=&quot;display: none;&quot;&gt;
Version : {{CURRENTTIMESTAMP}}
({{CURRENTHOUR}}h.. UTC)
&lt;!-- Page à purger tous les jours pour tous. --&gt;
Cette page a besoin de __NOCACHE__
&lt;/div&gt;
{| class=&quot;flexible&quot; style=&quot;width:100%; margin:0px; padding:0px 5px 5px 5px;&quot;
|
&lt;div style=&quot;width:auto; text-align:center;&quot;&gt;

&lt;div id=&quot;mf-banner1&quot; style=&quot;font-size:162%; padding:0.1em;&quot;&gt;Bienvenue sur [[Wikilivres:Présentation|Wikilivres]],&lt;/div&gt;
&lt;div id=&quot;mf-banner2&quot; style=&quot;font-size:95%; margin-top:0.2em;&quot;&gt;{{Bloc|La bibliothèque}} {{Bloc|de livres pédagogiques libres}} {{Bloc|que chacun peut améliorer.}}&lt;/div&gt;
&lt;div style=&quot;text-align:center; font-size:95%; margin:0;&quot;&gt;[[Wikilivres:Présentation|Wikilivres ?]] • [[Wikilivres|Aide]] • [[Wikilivres:Accueil|Communauté]]&lt;/div&gt;
&lt;div id=&quot;pagecount&quot; style=&quot;font-size:85%;&quot;&gt;[[:Catégorie:Livres par titre|{{NUMBEROFBOOKS}} livres]] contenant [[Special:Allpages|{{NUMBEROFARTICLES}} pages]].&lt;/div&gt;
&lt;/div&gt;
| style=&quot;width:55%; font-size:95%;&quot; |
{| class=&quot;flexible&quot;
| style=&quot;width:25%;&quot; |
[[Fichier:Book icon.png|100px|link=Wikilivres:Tous les livres]]
| style=&quot;width:50%;&quot; |
* [[:Catégorie:Livres terminés|Livres disponibles]]
* [[:Catégorie:Minilivres|Mini Livres disponibles]]
| style=&quot;width:10%;&quot; |

| style=&quot;width:0%;&quot; |
 
|}
|}

&lt;div class=&quot;livre-accueil-section2&quot; style=&quot;clear:both; margin:33px 0px 33px 0px; padding:0px;&quot;&gt;
{| class=&quot;livre-accueil-table2&quot; style=&quot;width:100%; border-spacing:8px 8px;&quot;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre1&quot; title=&quot;Exemple de livre en vitrine&quot;&gt;{{:Accueil/Vitrine|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre2&quot; title=&quot;Exemple de livre Wikijunior&quot;&gt;{{:Accueil/Wikijunior|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
| class=&quot;livre-presentation livre-accueil2&quot; style=&quot;width:33%; padding:10px; vertical-align:top;&quot; |
&lt;div id=&quot;mf-livre3&quot; title=&quot;Exemple de recette de cuisine&quot;&gt;{{:Accueil/Recette|date={{LOCALYEAR}}-{{LOCALMONTH}}-{{LOCALDAY}}}}&lt;/div&gt;
|}
&lt;/div&gt;

&lt;div id=&quot;mf-newbooks&quot; class=&quot;newbooks-{{PAGESINCATEGORY:Nouveaux livres}}&quot; title=&quot;Nouveaux livres&quot; style=&quot;text-align: center&quot;&gt;
'''[[:Catégorie:Nouveaux livres|Nouveautés :]]''' &lt;dynamicpagelist&gt;
 category=Nouveaux livres
 namespace=Main
 suppresserrors=true
 order=descending
 count=20
 mode=inline
&lt;/dynamicpagelist&gt;'''[https://fr.wikibooks.org/wiki/Discussion_utilisateur:Xhungab ... La Réserve de Wikibook]'''
&lt;/div&gt;

&lt;hr style=&quot;border: 1px solid #4faff380; margin: 10px; border-top: 0px;&quot; /&gt;

&lt;/div&gt;

&lt;div class=&quot;projects only_nonmobile&quot;&gt;{{Projets Wikimedia}}&lt;/div&gt;
&lt;div class=&quot;projects only_mobile&quot;&gt;{{Projets Wikimedia|Mobile}}&lt;/div&gt;

&lt;div style=&quot;margin-top:12px;border:1px solid #4faff380;border-radius:10px;text-align:center;&quot; class=&quot;plainlinks&quot;&gt;
[[Wikilivres:Avertissements généraux|Wikilivres ne garantit pas le contenu mis en ligne]].
&lt;div style=&quot;font-size:85%;&quot;&gt;La [{{fullurl:wikimedia:Accueil|uselang=fr}} Wikimedia Foundation] étant un hébergeur, elle ne saurait être tenue responsable des erreurs éventuelles contenues sur ce site.&lt;br /&gt;Chaque rédacteur est responsable de ses contributions.&lt;/div&gt;
&lt;/div&gt;

__NOTOC__
__NOEDITSECTION__

[[Catégorie:Wikilivres]]</text>
      <sha1>3o9vsgk4udficjugme13yxzcl8da4t9</sha1>
    </revision>
  </page>
  <page>
    <title>Discussion:Accueil</title>
    <ns>1</ns>
    <id>56846</id>
    <revision>
      <id>772274</id>
      <parentid>769420</parentid>
      <timestamp>2026-09-16T13:06:12Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>772274</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="4971" sha1="kal2vb7le5wuziczzlsp7dg91m6q8x3" xml:space="preserve">{{Avertissement|Cette page est réservée aux discussions au sujet de la page d'[[Accueil]]. Les discussions sur le projet Wikilivres en général ont lieux sur [[Wikilivres:Le Bistro|Le Bistro]]}}

{{RemarqueIndex|Pour la maintenance, voir [[Wikilivres:Maintenance/Page d'accueil|Maintenance de la page d'accueil]].}}

*[[Discuter:Accueil/Archive 1|Archive ==&gt;mars 2009]]
*[[Discuter:Accueil/Archive 2|Archive ==&gt;mai 2013]]

== Chiffres ==
Pourquoi ne publie-t-on pas comme sur les autres wikis une indication de l'importance du site, avec quelque chose comme :
; {{PAGESINCATEGORY:Livres par titre}} livres sur {{NUMBEROFARTICLES}} pages
? [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 16 août 2013 à 22:21 (CEST)
:Je pense qu'il s'agit d'afficher des stats sur la page d'accueil, comme sur celle de Wikipedia tout en haut à droite ou dans le bistro du jour. Pourquoi pas? ''Liebe Grüße'', [[Utilisateur:Perditax|Perditax]] ([[Discussion utilisateur:Perditax|d]]) 19 septembre 2013 à 13:45 (CEST)
:: Pour ! [[Utilisateur:Jean-Jacques MILAN|Jean-Jacques MILAN]] ([[Discussion utilisateur:Jean-Jacques MILAN|discussion]]) 22 septembre 2013 à 13:51 (CEST)


== Auteur ???? ==

Et si on cherche livres d'un auteur specifique ?

???
:Les auteurs de Wikilivres qui le souhaitent peuvent publier leur bibliographie sur leur profil. Quant aux auteurs célèbres, ils sont sur [[s:|Wikisource]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 18 juillet 2015 à 16:56 (CEST)

== Version mobile ==

Bonjour,

Je pense que ce serait une bonne idée de mettre le lien de la version mobile de Wikibooks pour que celui qui utilise un téléphone ou une tablette ne soit pas perdu et ne cherche pas n'importe où comment avoir un affichage correct.

Merci, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 19 décembre 2018 à 15:39 (CET).
:Les navigateurs des téléphones basculent automatiquement dessus par défaut. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 19 décembre 2018 à 23:54 (CET)

== Rénovation ==

Bonjour,

Selon le projet [[w:fr:Projet:Charte graphique|Charte graphique]] de Wikipédia, pourrait-t-on rénover la page d'accueil avec les modèles [[Modèle:Boîte colorée|Boîte colorée]] et [[Modèle:Barre colorée|Barre colorée]].

Merci &amp; Cordialement, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]), le [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 13 mars 2019 à 17:38 (CET).
:Les rendus des versions desktop et mobile me semblent corrects aujourd'hui, donc je ne souhaiterais pas toucher à quelque chose qui fonctionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mars 2019 à 20:52 (CET)

== Faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]] ==
Il y a une faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]], mais dès que je veux modifier cette page, je suis redirigé vers la page d'accueil. J'ai corrigé d'innombrables pages sur wikipedia et les autres wiki cousins, mais là : impossible.

Je veux juste remplacer &quot;été crée&quot; par &quot;été créé&quot;.

[[Utilisateur:Romanc19s|Romanc19s]] ([[Discussion utilisateur:Romanc19s|discussion]]) 4 mars 2021 à 19:03 (CET)
:Salut Romanc19s
:Effectivement, il y a un script qui bloque la création et la modification des pages ayant un nom bizarre.
:La page ne peut avoir été créée que par un bot (javascript ignoré) ou un administrateur.
:J'ai effectué la correction. Mais on peut remettre en cause la pertinence de la présence d'une telle page.
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 4 mars 2021 à 19:49 (CET)

== Connexion ==

Pourquoi ne puis-je plus me connecter sous mon autre nom ? --[[Utilisateur:Elnon|Elnon]] ([[Discussion utilisateur:Elnon|discussion]]) 9 juillet 2026 à 21:59 (CEST)

== Un changement de la page d'Accueil ==
J'ai enclenché un changement de la page d'Accueil pour éviter aux lecteurs de se perdre dans les méandres de Wikibook. Je pense que les liens &quot;Livres terminés&quot; - &quot;Mini Livres&quot; font bien leur travail. Dans les nouveautés j'ai proposé de laisser les nouveaux livres pendant 1 mois, mais de permettre aux auteurs actifs de laisser leurs livres pendant plusieurs mois, voire plusieurs années tant qu'ils n'estimeront pas leurs livres terminés. Il y a toujours un lien qui permet de visiter tout le contenu de Wikilivre. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 16 septembre 2026 à 15:05 (CEST)</text>
      <sha1>kal2vb7le5wuziczzlsp7dg91m6q8x3</sha1>
    </revision>
    <revision>
      <id>772275</id>
      <parentid>772274</parentid>
      <timestamp>2026-09-16T13:06:27Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>/* Usage du Wikicode */ nouvelle section</comment>
      <origin>772275</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="6356" sha1="2weknz5fkqw5vwmrze0ax5edgueenye" xml:space="preserve">{{Avertissement|Cette page est réservée aux discussions au sujet de la page d'[[Accueil]]. Les discussions sur le projet Wikilivres en général ont lieux sur [[Wikilivres:Le Bistro|Le Bistro]]}}

{{RemarqueIndex|Pour la maintenance, voir [[Wikilivres:Maintenance/Page d'accueil|Maintenance de la page d'accueil]].}}

*[[Discuter:Accueil/Archive 1|Archive ==&gt;mars 2009]]
*[[Discuter:Accueil/Archive 2|Archive ==&gt;mai 2013]]

== Chiffres ==
Pourquoi ne publie-t-on pas comme sur les autres wikis une indication de l'importance du site, avec quelque chose comme :
; {{PAGESINCATEGORY:Livres par titre}} livres sur {{NUMBEROFARTICLES}} pages
? [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 16 août 2013 à 22:21 (CEST)
:Je pense qu'il s'agit d'afficher des stats sur la page d'accueil, comme sur celle de Wikipedia tout en haut à droite ou dans le bistro du jour. Pourquoi pas? ''Liebe Grüße'', [[Utilisateur:Perditax|Perditax]] ([[Discussion utilisateur:Perditax|d]]) 19 septembre 2013 à 13:45 (CEST)
:: Pour ! [[Utilisateur:Jean-Jacques MILAN|Jean-Jacques MILAN]] ([[Discussion utilisateur:Jean-Jacques MILAN|discussion]]) 22 septembre 2013 à 13:51 (CEST)


== Auteur ???? ==

Et si on cherche livres d'un auteur specifique ?

???
:Les auteurs de Wikilivres qui le souhaitent peuvent publier leur bibliographie sur leur profil. Quant aux auteurs célèbres, ils sont sur [[s:|Wikisource]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 18 juillet 2015 à 16:56 (CEST)

== Version mobile ==

Bonjour,

Je pense que ce serait une bonne idée de mettre le lien de la version mobile de Wikibooks pour que celui qui utilise un téléphone ou une tablette ne soit pas perdu et ne cherche pas n'importe où comment avoir un affichage correct.

Merci, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 19 décembre 2018 à 15:39 (CET).
:Les navigateurs des téléphones basculent automatiquement dessus par défaut. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 19 décembre 2018 à 23:54 (CET)

== Rénovation ==

Bonjour,

Selon le projet [[w:fr:Projet:Charte graphique|Charte graphique]] de Wikipédia, pourrait-t-on rénover la page d'accueil avec les modèles [[Modèle:Boîte colorée|Boîte colorée]] et [[Modèle:Barre colorée|Barre colorée]].

Merci &amp; Cordialement, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]), le [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 13 mars 2019 à 17:38 (CET).
:Les rendus des versions desktop et mobile me semblent corrects aujourd'hui, donc je ne souhaiterais pas toucher à quelque chose qui fonctionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mars 2019 à 20:52 (CET)

== Faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]] ==
Il y a une faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]], mais dès que je veux modifier cette page, je suis redirigé vers la page d'accueil. J'ai corrigé d'innombrables pages sur wikipedia et les autres wiki cousins, mais là : impossible.

Je veux juste remplacer &quot;été crée&quot; par &quot;été créé&quot;.

[[Utilisateur:Romanc19s|Romanc19s]] ([[Discussion utilisateur:Romanc19s|discussion]]) 4 mars 2021 à 19:03 (CET)
:Salut Romanc19s
:Effectivement, il y a un script qui bloque la création et la modification des pages ayant un nom bizarre.
:La page ne peut avoir été créée que par un bot (javascript ignoré) ou un administrateur.
:J'ai effectué la correction. Mais on peut remettre en cause la pertinence de la présence d'une telle page.
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 4 mars 2021 à 19:49 (CET)

== Connexion ==

Pourquoi ne puis-je plus me connecter sous mon autre nom ? --[[Utilisateur:Elnon|Elnon]] ([[Discussion utilisateur:Elnon|discussion]]) 9 juillet 2026 à 21:59 (CEST)

== Un changement de la page d'Accueil ==
J'ai enclenché un changement de la page d'Accueil pour éviter aux lecteurs de se perdre dans les méandres de Wikibook. Je pense que les liens &quot;Livres terminés&quot; - &quot;Mini Livres&quot; font bien leur travail. Dans les nouveautés j'ai proposé de laisser les nouveaux livres pendant 1 mois, mais de permettre aux auteurs actifs de laisser leurs livres pendant plusieurs mois, voire plusieurs années tant qu'ils n'estimeront pas leurs livres terminés. Il y a toujours un lien qui permet de visiter tout le contenu de Wikilivre. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 16 septembre 2026 à 15:05 (CEST)

== Usage du Wikicode ==
@[[Utilisateur:DavidL|DavidL]] et @[[Utilisateur:JackPotte|JackPotte]]. Je suis en train de refaire la mise en page de notre page d'accueil suite à la décision initiée par @. J'en profite aussi pour traiter les problèmes d'affichage par les smartphones. Le code de cette page utilise beaucoup de code CSS, voire HTML. C'est sans doute très commode pour les personnes comme vous qui connaissent bien ce langage, mais j'y vois un inconvénient.

Cela rend les choses plus difficiles à comprendre et à modifier pour des gens comme moi qui ne maîtrisent pas le CSS et l'HTML, contrairement au Wikicode.

Le Wikicode a été créé pour être plus facile d'usage et je me dis qu'il sera aussi toujours pris en charge par les futurs contributeurs qui ne sont pas informaticiens. De plus, tout ce qui est écrit en Wikicode sera toujours pris en charge dans le cadre des améliorations faites par le personnel de la fondation. 

Je propose donc de réécrire le code de la page d'accueil en utilisant au maximum le Wikicode et aucun code HTML ou CSS si possible.

Qu'en pensez-vous ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 septembre 2026 à 15:06 (CEST)</text>
      <sha1>2weknz5fkqw5vwmrze0ax5edgueenye</sha1>
    </revision>
    <revision>
      <id>772276</id>
      <parentid>772275</parentid>
      <timestamp>2026-09-16T13:08:24Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>/* Usage du Wikicode */</comment>
      <origin>772276</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="6379" sha1="mig9ijlzcd6lmy2r0zm930eyn95uujy" xml:space="preserve">{{Avertissement|Cette page est réservée aux discussions au sujet de la page d'[[Accueil]]. Les discussions sur le projet Wikilivres en général ont lieux sur [[Wikilivres:Le Bistro|Le Bistro]]}}

{{RemarqueIndex|Pour la maintenance, voir [[Wikilivres:Maintenance/Page d'accueil|Maintenance de la page d'accueil]].}}

*[[Discuter:Accueil/Archive 1|Archive ==&gt;mars 2009]]
*[[Discuter:Accueil/Archive 2|Archive ==&gt;mai 2013]]

== Chiffres ==
Pourquoi ne publie-t-on pas comme sur les autres wikis une indication de l'importance du site, avec quelque chose comme :
; {{PAGESINCATEGORY:Livres par titre}} livres sur {{NUMBEROFARTICLES}} pages
? [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 16 août 2013 à 22:21 (CEST)
:Je pense qu'il s'agit d'afficher des stats sur la page d'accueil, comme sur celle de Wikipedia tout en haut à droite ou dans le bistro du jour. Pourquoi pas? ''Liebe Grüße'', [[Utilisateur:Perditax|Perditax]] ([[Discussion utilisateur:Perditax|d]]) 19 septembre 2013 à 13:45 (CEST)
:: Pour ! [[Utilisateur:Jean-Jacques MILAN|Jean-Jacques MILAN]] ([[Discussion utilisateur:Jean-Jacques MILAN|discussion]]) 22 septembre 2013 à 13:51 (CEST)


== Auteur ???? ==

Et si on cherche livres d'un auteur specifique ?

???
:Les auteurs de Wikilivres qui le souhaitent peuvent publier leur bibliographie sur leur profil. Quant aux auteurs célèbres, ils sont sur [[s:|Wikisource]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 18 juillet 2015 à 16:56 (CEST)

== Version mobile ==

Bonjour,

Je pense que ce serait une bonne idée de mettre le lien de la version mobile de Wikibooks pour que celui qui utilise un téléphone ou une tablette ne soit pas perdu et ne cherche pas n'importe où comment avoir un affichage correct.

Merci, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 19 décembre 2018 à 15:39 (CET).
:Les navigateurs des téléphones basculent automatiquement dessus par défaut. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 19 décembre 2018 à 23:54 (CET)

== Rénovation ==

Bonjour,

Selon le projet [[w:fr:Projet:Charte graphique|Charte graphique]] de Wikipédia, pourrait-t-on rénover la page d'accueil avec les modèles [[Modèle:Boîte colorée|Boîte colorée]] et [[Modèle:Barre colorée|Barre colorée]].

Merci &amp; Cordialement, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]), le [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 13 mars 2019 à 17:38 (CET).
:Les rendus des versions desktop et mobile me semblent corrects aujourd'hui, donc je ne souhaiterais pas toucher à quelque chose qui fonctionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mars 2019 à 20:52 (CET)

== Faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]] ==
Il y a une faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]], mais dès que je veux modifier cette page, je suis redirigé vers la page d'accueil. J'ai corrigé d'innombrables pages sur wikipedia et les autres wiki cousins, mais là : impossible.

Je veux juste remplacer &quot;été crée&quot; par &quot;été créé&quot;.

[[Utilisateur:Romanc19s|Romanc19s]] ([[Discussion utilisateur:Romanc19s|discussion]]) 4 mars 2021 à 19:03 (CET)
:Salut Romanc19s
:Effectivement, il y a un script qui bloque la création et la modification des pages ayant un nom bizarre.
:La page ne peut avoir été créée que par un bot (javascript ignoré) ou un administrateur.
:J'ai effectué la correction. Mais on peut remettre en cause la pertinence de la présence d'une telle page.
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 4 mars 2021 à 19:49 (CET)

== Connexion ==

Pourquoi ne puis-je plus me connecter sous mon autre nom ? --[[Utilisateur:Elnon|Elnon]] ([[Discussion utilisateur:Elnon|discussion]]) 9 juillet 2026 à 21:59 (CEST)

== Un changement de la page d'Accueil ==
J'ai enclenché un changement de la page d'Accueil pour éviter aux lecteurs de se perdre dans les méandres de Wikibook. Je pense que les liens &quot;Livres terminés&quot; - &quot;Mini Livres&quot; font bien leur travail. Dans les nouveautés j'ai proposé de laisser les nouveaux livres pendant 1 mois, mais de permettre aux auteurs actifs de laisser leurs livres pendant plusieurs mois, voire plusieurs années tant qu'ils n'estimeront pas leurs livres terminés. Il y a toujours un lien qui permet de visiter tout le contenu de Wikilivre. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 16 septembre 2026 à 15:05 (CEST)

== Usage du Wikicode ==
@[[Utilisateur:DavidL|DavidL]] et @[[Utilisateur:JackPotte|JackPotte]]. Je suis en train de refaire la mise en page de notre page d'accueil suite à la décision initiée par 
[[Utilisateur:Xhungab]]. J'en profite aussi pour traiter les problèmes d'affichage par les smartphones. Le code de cette page utilise beaucoup de code CSS, voire HTML. C'est sans doute très commode pour les personnes comme vous qui connaissent bien ce langage, mais j'y vois un inconvénient.

Cela rend les choses plus difficiles à comprendre et à modifier pour des gens comme moi qui ne maîtrisent pas le CSS et l'HTML, contrairement au Wikicode.

Le Wikicode a été créé pour être plus facile d'usage et je me dis qu'il sera aussi toujours pris en charge par les futurs contributeurs qui ne sont pas informaticiens. De plus, tout ce qui est écrit en Wikicode sera toujours pris en charge dans le cadre des améliorations faites par le personnel de la fondation. 

Je propose donc de réécrire le code de la page d'accueil en utilisant au maximum le Wikicode et aucun code HTML ou CSS si possible.

Qu'en pensez-vous ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 septembre 2026 à 15:06 (CEST)</text>
      <sha1>mig9ijlzcd6lmy2r0zm930eyn95uujy</sha1>
    </revision>
    <revision>
      <id>772277</id>
      <parentid>772276</parentid>
      <timestamp>2026-09-16T13:08:56Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>/* Usage du Wikicode */</comment>
      <origin>772277</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="6387" sha1="82hdwkwn386u0homduwgmapdd5y4zm6" xml:space="preserve">{{Avertissement|Cette page est réservée aux discussions au sujet de la page d'[[Accueil]]. Les discussions sur le projet Wikilivres en général ont lieux sur [[Wikilivres:Le Bistro|Le Bistro]]}}

{{RemarqueIndex|Pour la maintenance, voir [[Wikilivres:Maintenance/Page d'accueil|Maintenance de la page d'accueil]].}}

*[[Discuter:Accueil/Archive 1|Archive ==&gt;mars 2009]]
*[[Discuter:Accueil/Archive 2|Archive ==&gt;mai 2013]]

== Chiffres ==
Pourquoi ne publie-t-on pas comme sur les autres wikis une indication de l'importance du site, avec quelque chose comme :
; {{PAGESINCATEGORY:Livres par titre}} livres sur {{NUMBEROFARTICLES}} pages
? [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 16 août 2013 à 22:21 (CEST)
:Je pense qu'il s'agit d'afficher des stats sur la page d'accueil, comme sur celle de Wikipedia tout en haut à droite ou dans le bistro du jour. Pourquoi pas? ''Liebe Grüße'', [[Utilisateur:Perditax|Perditax]] ([[Discussion utilisateur:Perditax|d]]) 19 septembre 2013 à 13:45 (CEST)
:: Pour ! [[Utilisateur:Jean-Jacques MILAN|Jean-Jacques MILAN]] ([[Discussion utilisateur:Jean-Jacques MILAN|discussion]]) 22 septembre 2013 à 13:51 (CEST)


== Auteur ???? ==

Et si on cherche livres d'un auteur specifique ?

???
:Les auteurs de Wikilivres qui le souhaitent peuvent publier leur bibliographie sur leur profil. Quant aux auteurs célèbres, ils sont sur [[s:|Wikisource]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 18 juillet 2015 à 16:56 (CEST)

== Version mobile ==

Bonjour,

Je pense que ce serait une bonne idée de mettre le lien de la version mobile de Wikibooks pour que celui qui utilise un téléphone ou une tablette ne soit pas perdu et ne cherche pas n'importe où comment avoir un affichage correct.

Merci, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 19 décembre 2018 à 15:39 (CET).
:Les navigateurs des téléphones basculent automatiquement dessus par défaut. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 19 décembre 2018 à 23:54 (CET)

== Rénovation ==

Bonjour,

Selon le projet [[w:fr:Projet:Charte graphique|Charte graphique]] de Wikipédia, pourrait-t-on rénover la page d'accueil avec les modèles [[Modèle:Boîte colorée|Boîte colorée]] et [[Modèle:Barre colorée|Barre colorée]].

Merci &amp; Cordialement, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]), le [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 13 mars 2019 à 17:38 (CET).
:Les rendus des versions desktop et mobile me semblent corrects aujourd'hui, donc je ne souhaiterais pas toucher à quelque chose qui fonctionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mars 2019 à 20:52 (CET)

== Faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]] ==
Il y a une faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]], mais dès que je veux modifier cette page, je suis redirigé vers la page d'accueil. J'ai corrigé d'innombrables pages sur wikipedia et les autres wiki cousins, mais là : impossible.

Je veux juste remplacer &quot;été crée&quot; par &quot;été créé&quot;.

[[Utilisateur:Romanc19s|Romanc19s]] ([[Discussion utilisateur:Romanc19s|discussion]]) 4 mars 2021 à 19:03 (CET)
:Salut Romanc19s
:Effectivement, il y a un script qui bloque la création et la modification des pages ayant un nom bizarre.
:La page ne peut avoir été créée que par un bot (javascript ignoré) ou un administrateur.
:J'ai effectué la correction. Mais on peut remettre en cause la pertinence de la présence d'une telle page.
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 4 mars 2021 à 19:49 (CET)

== Connexion ==

Pourquoi ne puis-je plus me connecter sous mon autre nom ? --[[Utilisateur:Elnon|Elnon]] ([[Discussion utilisateur:Elnon|discussion]]) 9 juillet 2026 à 21:59 (CEST)

== Un changement de la page d'Accueil ==
J'ai enclenché un changement de la page d'Accueil pour éviter aux lecteurs de se perdre dans les méandres de Wikibook. Je pense que les liens &quot;Livres terminés&quot; - &quot;Mini Livres&quot; font bien leur travail. Dans les nouveautés j'ai proposé de laisser les nouveaux livres pendant 1 mois, mais de permettre aux auteurs actifs de laisser leurs livres pendant plusieurs mois, voire plusieurs années tant qu'ils n'estimeront pas leurs livres terminés. Il y a toujours un lien qui permet de visiter tout le contenu de Wikilivre. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 16 septembre 2026 à 15:05 (CEST)

== Usage du Wikicode ==
@[[Utilisateur:DavidL|DavidL]] et @[[Utilisateur:JackPotte|JackPotte]]. Je suis en train de refaire la mise en page de notre page d'accueil suite à la décision initiée par 
[[Utilisateur:Xhungab|Xhungab]]. J'en profite aussi pour traiter les problèmes d'affichage par les smartphones. Le code de cette page utilise beaucoup de code CSS, voire HTML. C'est sans doute très commode pour les personnes comme vous qui connaissent bien ce langage, mais j'y vois un inconvénient.

Cela rend les choses plus difficiles à comprendre et à modifier pour des gens comme moi qui ne maîtrisent pas le CSS et l'HTML, contrairement au Wikicode.

Le Wikicode a été créé pour être plus facile d'usage et je me dis qu'il sera aussi toujours pris en charge par les futurs contributeurs qui ne sont pas informaticiens. De plus, tout ce qui est écrit en Wikicode sera toujours pris en charge dans le cadre des améliorations faites par le personnel de la fondation. 

Je propose donc de réécrire le code de la page d'accueil en utilisant au maximum le Wikicode et aucun code HTML ou CSS si possible.

Qu'en pensez-vous ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 septembre 2026 à 15:06 (CEST)</text>
      <sha1>82hdwkwn386u0homduwgmapdd5y4zm6</sha1>
    </revision>
    <revision>
      <id>772284</id>
      <parentid>772277</parentid>
      <timestamp>2026-09-16T13:59:52Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>/* Problème des cadre et tableau en version mobile */ nouvelle section</comment>
      <origin>772284</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="6871" sha1="565gk6tt99kvj4eu4peo5u09y80g440" xml:space="preserve">{{Avertissement|Cette page est réservée aux discussions au sujet de la page d'[[Accueil]]. Les discussions sur le projet Wikilivres en général ont lieux sur [[Wikilivres:Le Bistro|Le Bistro]]}}

{{RemarqueIndex|Pour la maintenance, voir [[Wikilivres:Maintenance/Page d'accueil|Maintenance de la page d'accueil]].}}

*[[Discuter:Accueil/Archive 1|Archive ==&gt;mars 2009]]
*[[Discuter:Accueil/Archive 2|Archive ==&gt;mai 2013]]

== Chiffres ==
Pourquoi ne publie-t-on pas comme sur les autres wikis une indication de l'importance du site, avec quelque chose comme :
; {{PAGESINCATEGORY:Livres par titre}} livres sur {{NUMBEROFARTICLES}} pages
? [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 16 août 2013 à 22:21 (CEST)
:Je pense qu'il s'agit d'afficher des stats sur la page d'accueil, comme sur celle de Wikipedia tout en haut à droite ou dans le bistro du jour. Pourquoi pas? ''Liebe Grüße'', [[Utilisateur:Perditax|Perditax]] ([[Discussion utilisateur:Perditax|d]]) 19 septembre 2013 à 13:45 (CEST)
:: Pour ! [[Utilisateur:Jean-Jacques MILAN|Jean-Jacques MILAN]] ([[Discussion utilisateur:Jean-Jacques MILAN|discussion]]) 22 septembre 2013 à 13:51 (CEST)


== Auteur ???? ==

Et si on cherche livres d'un auteur specifique ?

???
:Les auteurs de Wikilivres qui le souhaitent peuvent publier leur bibliographie sur leur profil. Quant aux auteurs célèbres, ils sont sur [[s:|Wikisource]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 18 juillet 2015 à 16:56 (CEST)

== Version mobile ==

Bonjour,

Je pense que ce serait une bonne idée de mettre le lien de la version mobile de Wikibooks pour que celui qui utilise un téléphone ou une tablette ne soit pas perdu et ne cherche pas n'importe où comment avoir un affichage correct.

Merci, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 19 décembre 2018 à 15:39 (CET).
:Les navigateurs des téléphones basculent automatiquement dessus par défaut. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 19 décembre 2018 à 23:54 (CET)

== Rénovation ==

Bonjour,

Selon le projet [[w:fr:Projet:Charte graphique|Charte graphique]] de Wikipédia, pourrait-t-on rénover la page d'accueil avec les modèles [[Modèle:Boîte colorée|Boîte colorée]] et [[Modèle:Barre colorée|Barre colorée]].

Merci &amp; Cordialement, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]), le [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 13 mars 2019 à 17:38 (CET).
:Les rendus des versions desktop et mobile me semblent corrects aujourd'hui, donc je ne souhaiterais pas toucher à quelque chose qui fonctionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mars 2019 à 20:52 (CET)

== Faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]] ==
Il y a une faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]], mais dès que je veux modifier cette page, je suis redirigé vers la page d'accueil. J'ai corrigé d'innombrables pages sur wikipedia et les autres wiki cousins, mais là : impossible.

Je veux juste remplacer &quot;été crée&quot; par &quot;été créé&quot;.

[[Utilisateur:Romanc19s|Romanc19s]] ([[Discussion utilisateur:Romanc19s|discussion]]) 4 mars 2021 à 19:03 (CET)
:Salut Romanc19s
:Effectivement, il y a un script qui bloque la création et la modification des pages ayant un nom bizarre.
:La page ne peut avoir été créée que par un bot (javascript ignoré) ou un administrateur.
:J'ai effectué la correction. Mais on peut remettre en cause la pertinence de la présence d'une telle page.
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 4 mars 2021 à 19:49 (CET)

== Connexion ==

Pourquoi ne puis-je plus me connecter sous mon autre nom ? --[[Utilisateur:Elnon|Elnon]] ([[Discussion utilisateur:Elnon|discussion]]) 9 juillet 2026 à 21:59 (CEST)

== Un changement de la page d'Accueil ==
J'ai enclenché un changement de la page d'Accueil pour éviter aux lecteurs de se perdre dans les méandres de Wikibook. Je pense que les liens &quot;Livres terminés&quot; - &quot;Mini Livres&quot; font bien leur travail. Dans les nouveautés j'ai proposé de laisser les nouveaux livres pendant 1 mois, mais de permettre aux auteurs actifs de laisser leurs livres pendant plusieurs mois, voire plusieurs années tant qu'ils n'estimeront pas leurs livres terminés. Il y a toujours un lien qui permet de visiter tout le contenu de Wikilivre. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 16 septembre 2026 à 15:05 (CEST)

== Usage du Wikicode ==
@[[Utilisateur:DavidL|DavidL]] et @[[Utilisateur:JackPotte|JackPotte]]. Je suis en train de refaire la mise en page de notre page d'accueil suite à la décision initiée par 
[[Utilisateur:Xhungab|Xhungab]]. J'en profite aussi pour traiter les problèmes d'affichage par les smartphones. Le code de cette page utilise beaucoup de code CSS, voire HTML. C'est sans doute très commode pour les personnes comme vous qui connaissent bien ce langage, mais j'y vois un inconvénient.

Cela rend les choses plus difficiles à comprendre et à modifier pour des gens comme moi qui ne maîtrisent pas le CSS et l'HTML, contrairement au Wikicode.

Le Wikicode a été créé pour être plus facile d'usage et je me dis qu'il sera aussi toujours pris en charge par les futurs contributeurs qui ne sont pas informaticiens. De plus, tout ce qui est écrit en Wikicode sera toujours pris en charge dans le cadre des améliorations faites par le personnel de la fondation. 

Je propose donc de réécrire le code de la page d'accueil en utilisant au maximum le Wikicode et aucun code HTML ou CSS si possible.

Qu'en pensez-vous ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 septembre 2026 à 15:06 (CEST)

== Problème des cadre et tableau en version mobile ==
Je découvre que l'usage de cadre et de tableau contrarie l'affichage en version mobile. Je tenterai de trouver une solution. N'hésitez pas à réagir. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 septembre 2026 à 15:59 (CEST)</text>
      <sha1>565gk6tt99kvj4eu4peo5u09y80g440</sha1>
    </revision>
    <revision>
      <id>772339</id>
      <parentid>772284</parentid>
      <timestamp>2026-09-17T06:57:55Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <comment>/* Un changement de la page d'Accueil */</comment>
      <origin>772339</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="7080" sha1="jwi75rolqq1ikcatufq6z9954q7k5pw" xml:space="preserve">{{Avertissement|Cette page est réservée aux discussions au sujet de la page d'[[Accueil]]. Les discussions sur le projet Wikilivres en général ont lieux sur [[Wikilivres:Le Bistro|Le Bistro]]}}

{{RemarqueIndex|Pour la maintenance, voir [[Wikilivres:Maintenance/Page d'accueil|Maintenance de la page d'accueil]].}}

*[[Discuter:Accueil/Archive 1|Archive ==&gt;mars 2009]]
*[[Discuter:Accueil/Archive 2|Archive ==&gt;mai 2013]]

== Chiffres ==
Pourquoi ne publie-t-on pas comme sur les autres wikis une indication de l'importance du site, avec quelque chose comme :
; {{PAGESINCATEGORY:Livres par titre}} livres sur {{NUMBEROFARTICLES}} pages
? [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 16 août 2013 à 22:21 (CEST)
:Je pense qu'il s'agit d'afficher des stats sur la page d'accueil, comme sur celle de Wikipedia tout en haut à droite ou dans le bistro du jour. Pourquoi pas? ''Liebe Grüße'', [[Utilisateur:Perditax|Perditax]] ([[Discussion utilisateur:Perditax|d]]) 19 septembre 2013 à 13:45 (CEST)
:: Pour ! [[Utilisateur:Jean-Jacques MILAN|Jean-Jacques MILAN]] ([[Discussion utilisateur:Jean-Jacques MILAN|discussion]]) 22 septembre 2013 à 13:51 (CEST)


== Auteur ???? ==

Et si on cherche livres d'un auteur specifique ?

???
:Les auteurs de Wikilivres qui le souhaitent peuvent publier leur bibliographie sur leur profil. Quant aux auteurs célèbres, ils sont sur [[s:|Wikisource]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;font color=&quot;#FF6600&quot;&gt;$&lt;/font&gt;♠]]) 18 juillet 2015 à 16:56 (CEST)

== Version mobile ==

Bonjour,

Je pense que ce serait une bonne idée de mettre le lien de la version mobile de Wikibooks pour que celui qui utilise un téléphone ou une tablette ne soit pas perdu et ne cherche pas n'importe où comment avoir un affichage correct.

Merci, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 19 décembre 2018 à 15:39 (CET).
:Les navigateurs des téléphones basculent automatiquement dessus par défaut. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 19 décembre 2018 à 23:54 (CET)

== Rénovation ==

Bonjour,

Selon le projet [[w:fr:Projet:Charte graphique|Charte graphique]] de Wikipédia, pourrait-t-on rénover la page d'accueil avec les modèles [[Modèle:Boîte colorée|Boîte colorée]] et [[Modèle:Barre colorée|Barre colorée]].

Merci &amp; Cordialement, [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]), le [[Utilisateur:Aabbccddeeffabcdef|Aabbccddeeffabcdef]] ([[Discussion utilisateur:Aabbccddeeffabcdef|discussion]]) 13 mars 2019 à 17:38 (CET).
:Les rendus des versions desktop et mobile me semblent corrects aujourd'hui, donc je ne souhaiterais pas toucher à quelque chose qui fonctionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mars 2019 à 20:52 (CET)

== Faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]] ==
Il y a une faute d'orthographe sur [[Ict@innovation: Free your IT Business in Africa/2-1]], mais dès que je veux modifier cette page, je suis redirigé vers la page d'accueil. J'ai corrigé d'innombrables pages sur wikipedia et les autres wiki cousins, mais là : impossible.

Je veux juste remplacer &quot;été crée&quot; par &quot;été créé&quot;.

[[Utilisateur:Romanc19s|Romanc19s]] ([[Discussion utilisateur:Romanc19s|discussion]]) 4 mars 2021 à 19:03 (CET)
:Salut Romanc19s
:Effectivement, il y a un script qui bloque la création et la modification des pages ayant un nom bizarre.
:La page ne peut avoir été créée que par un bot (javascript ignoré) ou un administrateur.
:J'ai effectué la correction. Mais on peut remettre en cause la pertinence de la présence d'une telle page.
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 4 mars 2021 à 19:49 (CET)

== Connexion ==

Pourquoi ne puis-je plus me connecter sous mon autre nom ? --[[Utilisateur:Elnon|Elnon]] ([[Discussion utilisateur:Elnon|discussion]]) 9 juillet 2026 à 21:59 (CEST)

== Un changement de la page d'Accueil ==
J'ai enclenché un changement de la page d'Accueil pour éviter aux lecteurs de se perdre dans les méandres de Wikibook.

Je pense que les liens &quot;Livres terminés&quot; - &quot;Mini Livres&quot; font bien leur travail. Dans les nouveautés j'ai proposé de laisser les nouveaux livres pendant 1 mois, mais de permettre aux auteurs actifs de laisser leurs livres pendant plusieurs mois, voire plusieurs années tant qu'ils n'estimeront pas leurs livres terminés. 

Il y a toujours un lien de déperdition qui permet de se perdre dans les méandres de Wikilivre. Où est '''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil l'espace pour les lecteurs ?]'''  [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 16 septembre 2026 à 15:05 (CEST)

== Usage du Wikicode ==
@[[Utilisateur:DavidL|DavidL]] et @[[Utilisateur:JackPotte|JackPotte]]. Je suis en train de refaire la mise en page de notre page d'accueil suite à la décision initiée par 
[[Utilisateur:Xhungab|Xhungab]]. J'en profite aussi pour traiter les problèmes d'affichage par les smartphones. Le code de cette page utilise beaucoup de code CSS, voire HTML. C'est sans doute très commode pour les personnes comme vous qui connaissent bien ce langage, mais j'y vois un inconvénient.

Cela rend les choses plus difficiles à comprendre et à modifier pour des gens comme moi qui ne maîtrisent pas le CSS et l'HTML, contrairement au Wikicode.

Le Wikicode a été créé pour être plus facile d'usage et je me dis qu'il sera aussi toujours pris en charge par les futurs contributeurs qui ne sont pas informaticiens. De plus, tout ce qui est écrit en Wikicode sera toujours pris en charge dans le cadre des améliorations faites par le personnel de la fondation. 

Je propose donc de réécrire le code de la page d'accueil en utilisant au maximum le Wikicode et aucun code HTML ou CSS si possible.

Qu'en pensez-vous ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 septembre 2026 à 15:06 (CEST)

== Problème des cadre et tableau en version mobile ==
Je découvre que l'usage de cadre et de tableau contrarie l'affichage en version mobile. Je tenterai de trouver une solution. N'hésitez pas à réagir. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 septembre 2026 à 15:59 (CEST)</text>
      <sha1>jwi75rolqq1ikcatufq6z9954q7k5pw</sha1>
    </revision>
  </page>
  <page>
    <title>Les cartes graphiques/L'évolution vers la programmabilité : les GPUs</title>
    <ns>0</ns>
    <id>67392</id>
    <revision>
      <id>772301</id>
      <parentid>765349</parentid>
      <timestamp>2026-09-16T14:32:04Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* L'introduction des premiers jeux 3D : Quake et les drivers miniGL */</comment>
      <origin>772301</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="56560" sha1="mqmgdh6peq86kz4dn6edb1nqegtt733" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, pour lesquelles le jeu vidéo était un cas d'utilisation parmi tant d'autres. Et les consoles étaient la plateforme principale pour jouer à des jeux vidéo, le jeu vidéo PC étant plus marginal. Mais cela ne veut pas dire que le jeu PC n'existait pas, loin de là ! 

Un problème pour les jeux PC était que l'écosystème des PC était aussi fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Les fonctionnalités des cartes graphiques ont évolué dans le temps, en suivant les évolutions des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

===L'introduction des premiers jeux 3D : Quake et les drivers miniGL===

L'API OpenGL est née de la main de SGI, encore eux ! SGI avait créé l'API Iris GL pour ses stations de travail Iris Graphics. Iris GL a ensuite été libéré et est devenu le standard Open GL. Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Mais Open GL était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires, pas pour le jeu vidéo. Mais cela changea avec la sortie du jeu Quake, d'IdSoftware, en 1996.

Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célébre John Carmack) ajouta une version OpenGL du jeu. Il faut dire que le jeu était programmé sur une station de travail compatible avec OpenGL, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire. En théorie, le rendu par OpenGL aurait dû se faire intégralement en logiciel, sauf sur quelques rares stations de travail adaptées. Mais les premières cartes graphiques étaient déjà dans les starting blocks.

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

[[File:Architecture de base d'une carte 3D - 3.png|vignette|upright=1|Carte 3D avec gestion de la géométrie.]]

Les autres cartes graphiques, sorties peu après, étaient les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes sfaits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

Pour exploiter les unités de texture et le circuit de rastérisation, OpenGL et Direct 3D étaient partiellement implémentées en logiciel, car les cartes graphiques ne supportaient pas toutes les fonctionnalités de l'API. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Les fonctionnalités d'OpenGL implémentées dans ces pilotes étaient presque toutes exécutées en matériel, par la carte graphique. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses voodoo, disposaient de leur propre API graphique, l'API Glide. Elle facilitait la gestion de la géométrie et des textures, ce qui collait bien avec l'architecture de ces cartes 3D. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles dataient d'avant le jeu Quake, et elles étaient très éloignées du hardware des premières cartes graphiques. Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, Microsoft espérait que le matériel 3D implémenterait ce genre de système. Ce qui ne fu pas le cas.

Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0. Le mode de rendu laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison... C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>mqmgdh6peq86kz4dn6edb1nqegtt733</sha1>
    </revision>
    <revision>
      <id>772302</id>
      <parentid>772301</parentid>
      <timestamp>2026-09-16T14:32:33Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* L'introduction des premiers jeux 3D : Quake et les drivers miniGL */</comment>
      <origin>772302</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="56569" sha1="i4hcfpzp4gxvm9v5b64xgkdfbqybkqz" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, pour lesquelles le jeu vidéo était un cas d'utilisation parmi tant d'autres. Et les consoles étaient la plateforme principale pour jouer à des jeux vidéo, le jeu vidéo PC étant plus marginal. Mais cela ne veut pas dire que le jeu PC n'existait pas, loin de là ! 

Un problème pour les jeux PC était que l'écosystème des PC était aussi fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Les fonctionnalités des cartes graphiques ont évolué dans le temps, en suivant les évolutions des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

===L'introduction des premiers jeux 3D : Quake et les drivers miniGL===

L'API OpenGL est née de la main de SGI, encore eux ! SGI avait créé l'API Iris GL pour ses stations de travail Iris Graphics. Iris GL a ensuite été libéré et est devenu le standard Open GL. Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Mais Open GL était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires, pas pour le jeu vidéo. Mais cela changea avec la sortie du jeu Quake, d'IdSoftware, en 1996.

Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célébre John Carmack) ajouta une version OpenGL du jeu. Il faut dire que le jeu était programmé sur une station de travail compatible avec OpenGL, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire. En théorie, le rendu par OpenGL aurait dû se faire intégralement en logiciel, sauf sur quelques rares stations de travail adaptées. Mais les premières cartes graphiques étaient déjà dans les starting blocks.

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

Les autres cartes graphiques, sorties peu après, étaient les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes sfaits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Pour exploiter les unités de texture et le circuit de rastérisation, OpenGL et Direct 3D étaient partiellement implémentées en logiciel, car les cartes graphiques ne supportaient pas toutes les fonctionnalités de l'API. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Les fonctionnalités d'OpenGL implémentées dans ces pilotes étaient presque toutes exécutées en matériel, par la carte graphique. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses voodoo, disposaient de leur propre API graphique, l'API Glide. Elle facilitait la gestion de la géométrie et des textures, ce qui collait bien avec l'architecture de ces cartes 3D. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles dataient d'avant le jeu Quake, et elles étaient très éloignées du hardware des premières cartes graphiques. Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, Microsoft espérait que le matériel 3D implémenterait ce genre de système. Ce qui ne fu pas le cas.

Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0. Le mode de rendu laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison... C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>i4hcfpzp4gxvm9v5b64xgkdfbqybkqz</sha1>
    </revision>
    <revision>
      <id>772310</id>
      <parentid>772302</parentid>
      <timestamp>2026-09-16T14:47:52Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* L'historique des cartes graphiques pour PC */</comment>
      <origin>772310</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="55968" sha1="2q79b8mqg3kq3flinlsgtafgvtgu0jh" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité.

Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent. Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les premières cartes accélératrices 3D===

Les autres cartes graphiques, sorties peu après, étaient les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes sfaits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Pour exploiter les unités de texture et le circuit de rastérisation, OpenGL et Direct 3D étaient partiellement implémentées en logiciel, car les cartes graphiques ne supportaient pas toutes les fonctionnalités de l'API. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Les fonctionnalités d'OpenGL implémentées dans ces pilotes étaient presque toutes exécutées en matériel, par la carte graphique. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses voodoo, disposaient de leur propre API graphique, l'API Glide. Elle facilitait la gestion de la géométrie et des textures, ce qui collait bien avec l'architecture de ces cartes 3D. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles dataient d'avant le jeu Quake, et elles étaient très éloignées du hardware des premières cartes graphiques. Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, Microsoft espérait que le matériel 3D implémenterait ce genre de système. Ce qui ne fu pas le cas.

Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0. Le mode de rendu laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison... C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>2q79b8mqg3kq3flinlsgtafgvtgu0jh</sha1>
    </revision>
    <revision>
      <id>772311</id>
      <parentid>772310</parentid>
      <timestamp>2026-09-16T14:52:31Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les premières cartes accélératrices 3D */</comment>
      <origin>772311</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="55499" sha1="gr3xst6eypebxa6xrxyveomprz6wnwv" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité.

Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent. Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les premières cartes accélératrices 3D===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison... C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>gr3xst6eypebxa6xrxyveomprz6wnwv</sha1>
    </revision>
    <revision>
      <id>772313</id>
      <parentid>772311</parentid>
      <timestamp>2026-09-16T16:20:07Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les premières cartes accélératrices 3D */</comment>
      <origin>772313</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="58099" sha1="qyyggzd96dmp0ynsr9r1s7dcd3gze6p" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité.

Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent. Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les premières cartes accélératrices 3D===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier est à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. A la place, il y a une mémoire pour les textures et une mémoire pour le ''framebuffer''. Les deux font 4 mébioctets chacune. La mémoire de texture est composée de 4 RAM de 1 mégaoctet chacune. Les quatre mémoires sont accédées en parallèle, ce qui permet de lire quatre texels en une seule fois. L'intérêt est que cela accélère certaines fonctionnalités de rendu, en l’occurrence le filtrage de texture bilinéaire.

Le processeur de commande et l'interface avec le bus intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison... C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>qyyggzd96dmp0ynsr9r1s7dcd3gze6p</sha1>
    </revision>
    <revision>
      <id>772314</id>
      <parentid>772313</parentid>
      <timestamp>2026-09-16T16:24:52Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les premières cartes accélératrices 3D */</comment>
      <origin>772314</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="59057" sha1="dn8atq6fht2v144lntjrx1lfa9neead" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité.

Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent. Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les premières cartes accélératrices 3D===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier est à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. A la place, il y a une mémoire pour les textures et une mémoire pour le ''framebuffer''. Les deux font 4 mébioctets chacune. La mémoire de texture est composée de 4 RAM de 1 mégaoctet chacune. Les quatre mémoires sont accédées en parallèle, ce qui permet de lire quatre texels en une seule fois. L'intérêt est que cela accélère certaines fonctionnalités de rendu, en l’occurrence le filtrage de texture bilinéaire.

Le processeur de commande et l'interface avec le bus intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande recoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous :

{|class=&quot;wikitable&quot;
|-
! triangleCMD || Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD || Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD || Vide le pipeline de la carte graphique.
|-
! fastfillCMD || Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD || Envoie l'image dessinée à la carte d'affichage.
|}

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison... C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>dn8atq6fht2v144lntjrx1lfa9neead</sha1>
    </revision>
    <revision>
      <id>772315</id>
      <parentid>772314</parentid>
      <timestamp>2026-09-16T16:35:52Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les premières cartes accélératrices 3D */</comment>
      <origin>772315</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="60552" sha1="q49lzjvxeijhr9vkh10dfd9antqoa9y" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité.

Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent. Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les premières cartes accélératrices 3D===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier est à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. A la place, il y a une mémoire pour les textures et une mémoire pour le ''framebuffer''. Les deux font 4 mébioctets chacune. La mémoire de texture est composée de 4 RAM de 1 mégaoctet chacune, idem pour le ''framebuffer''.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont convertie en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées , à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire. L'idée est qu'un pixel à l'écran ne tombe pas souvent pile sur un texel. A la place, il se trouve entouré par quatre texels. L'idée est alors de faire une moyenne pondérée de ces quatre texels pour déterminer la couleur finale du pixel.

Rappelons que la mémoire de texture est composée de 4 mémoires de 1 mébioctet chacune. Sur la Voodoo, les textures sont découpées en blocs de quatre texels, chaque texel allant dans une mémoire différente. L'intérêt est que cela accélère le filtrage bilinéaire : les quatre texels nécessaires sont lus depuis la mémoire en une seule fois. L'unité de texture accède aux quatre mémoire en parallèle, et le format des textures garantit que ces quatre texels sont dans des mémoires différentes.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison... C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>q49lzjvxeijhr9vkh10dfd9antqoa9y</sha1>
    </revision>
    <revision>
      <id>772316</id>
      <parentid>772315</parentid>
      <timestamp>2026-09-16T17:14:06Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les premières cartes accélératrices 3D */</comment>
      <origin>772316</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="61736" sha1="chj3xnv8nnks4qqi5gb4t620m32q07t" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité.

Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent. Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les premières cartes accélératrices 3D===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier est à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. A la place, il y a une mémoire pour les textures et une mémoire pour le ''framebuffer''. Les deux font 4 mébioctets chacune. La mémoire de texture est composée de 4 RAM de 1 mégaoctet chacune, idem pour le ''framebuffer''.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont convertie en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées , à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire. L'idée est qu'un pixel à l'écran ne tombe pas souvent pile sur un texel. Il est alors difficile de déterminer la couleur du pixel. Une solution simple prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche. Une solution alternative, appelée '''filtrage bilinéaire''', prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

Rappelons que la mémoire de texture est composée de 4 mémoires de 1 mébioctet chacune. Et l'unité de texture peut accéder aux quatre mémoires RAM en même temps. Le format des textures garantit que, lors d'un filtrage bilinéaire, les quatre texels nécessaires sont lus en même temps, chacun depuis une RAM différente. Le format de texture est illustré ci-dessous : chaque couleur correspond à une mémoire différent, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison... C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>chj3xnv8nnks4qqi5gb4t620m32q07t</sha1>
    </revision>
    <revision>
      <id>772317</id>
      <parentid>772316</parentid>
      <timestamp>2026-09-16T17:17:29Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les premières cartes accélératrices 3D */</comment>
      <origin>772317</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62004" sha1="5542a2mwem5uzscm5mrjvxvu8lpqmcf" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité.

Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent. Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les premières cartes accélératrices 3D===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier est à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. A la place, il y a deux mémoires séparées : une pour les textures et une pour le ''framebuffer''. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont convertie en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées , à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire. L'idée est qu'un pixel à l'écran ne tombe pas souvent pile sur un texel. Il est alors difficile de déterminer la couleur du pixel. Une solution simple prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche. Une solution alternative, appelée '''filtrage bilinéaire''', prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

Rappelons que la mémoire de texture est composée de 4 mémoires de 1 mébioctet chacune. Et l'unité de texture peut accéder aux quatre mémoires RAM en même temps. Le format des textures garantit que, lors d'un filtrage bilinéaire, les quatre texels nécessaires sont lus en même temps, chacun depuis une RAM différente. Le format de texture est illustré ci-dessous : chaque couleur correspond à une mémoire différent, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison... C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>5542a2mwem5uzscm5mrjvxvu8lpqmcf</sha1>
    </revision>
    <revision>
      <id>772318</id>
      <parentid>772317</parentid>
      <timestamp>2026-09-16T17:21:20Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* L'historique des cartes graphiques pour PC */</comment>
      <origin>772318</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62276" sha1="mwdql9jmiq7g359iuhzro9gbaatin3j" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

===Un historique rapide des API 3D===

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les premières cartes accélératrices 3D===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier est à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. A la place, il y a deux mémoires séparées : une pour les textures et une pour le ''framebuffer''. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont convertie en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées , à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire. L'idée est qu'un pixel à l'écran ne tombe pas souvent pile sur un texel. Il est alors difficile de déterminer la couleur du pixel. Une solution simple prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche. Une solution alternative, appelée '''filtrage bilinéaire''', prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

Rappelons que la mémoire de texture est composée de 4 mémoires de 1 mébioctet chacune. Et l'unité de texture peut accéder aux quatre mémoires RAM en même temps. Le format des textures garantit que, lors d'un filtrage bilinéaire, les quatre texels nécessaires sont lus en même temps, chacun depuis une RAM différente. Le format de texture est illustré ci-dessous : chaque couleur correspond à une mémoire différent, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>mwdql9jmiq7g359iuhzro9gbaatin3j</sha1>
    </revision>
    <revision>
      <id>772319</id>
      <parentid>772318</parentid>
      <timestamp>2026-09-16T17:21:48Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les premières cartes accélératrices 3D */</comment>
      <origin>772319</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62284" sha1="2gx7c36nb9to2kjl4ptw51ft91zq3ef" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

===Un historique rapide des API 3D===

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier est à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. A la place, il y a deux mémoires séparées : une pour les textures et une pour le ''framebuffer''. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont convertie en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées , à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire. L'idée est qu'un pixel à l'écran ne tombe pas souvent pile sur un texel. Il est alors difficile de déterminer la couleur du pixel. Une solution simple prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche. Une solution alternative, appelée '''filtrage bilinéaire''', prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

Rappelons que la mémoire de texture est composée de 4 mémoires de 1 mébioctet chacune. Et l'unité de texture peut accéder aux quatre mémoires RAM en même temps. Le format des textures garantit que, lors d'un filtrage bilinéaire, les quatre texels nécessaires sont lus en même temps, chacun depuis une RAM différente. Le format de texture est illustré ci-dessous : chaque couleur correspond à une mémoire différent, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>2gx7c36nb9to2kjl4ptw51ft91zq3ef</sha1>
    </revision>
    <revision>
      <id>772320</id>
      <parentid>772319</parentid>
      <timestamp>2026-09-16T17:22:16Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* L'historique des cartes graphiques pour PC */</comment>
      <origin>772320</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62245" sha1="3yvgithperb4ah5sgxn0j5c7el7pof6" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX ou même sa son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier est à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. A la place, il y a deux mémoires séparées : une pour les textures et une pour le ''framebuffer''. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont convertie en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées , à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire. L'idée est qu'un pixel à l'écran ne tombe pas souvent pile sur un texel. Il est alors difficile de déterminer la couleur du pixel. Une solution simple prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche. Une solution alternative, appelée '''filtrage bilinéaire''', prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

Rappelons que la mémoire de texture est composée de 4 mémoires de 1 mébioctet chacune. Et l'unité de texture peut accéder aux quatre mémoires RAM en même temps. Le format des textures garantit que, lors d'un filtrage bilinéaire, les quatre texels nécessaires sont lus en même temps, chacun depuis une RAM différente. Le format de texture est illustré ci-dessous : chaque couleur correspond à une mémoire différent, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>3yvgithperb4ah5sgxn0j5c7el7pof6</sha1>
    </revision>
    <revision>
      <id>772321</id>
      <parentid>772320</parentid>
      <timestamp>2026-09-16T17:22:31Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* La première carte 3D : la Rendition Vérité V1000 */</comment>
      <origin>772321</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62236" sha1="i07iamjvk7ecbcbnhnqvxxi3wxkhf9n" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier est à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. A la place, il y a deux mémoires séparées : une pour les textures et une pour le ''framebuffer''. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont convertie en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées , à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire. L'idée est qu'un pixel à l'écran ne tombe pas souvent pile sur un texel. Il est alors difficile de déterminer la couleur du pixel. Une solution simple prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche. Une solution alternative, appelée '''filtrage bilinéaire''', prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

Rappelons que la mémoire de texture est composée de 4 mémoires de 1 mébioctet chacune. Et l'unité de texture peut accéder aux quatre mémoires RAM en même temps. Le format des textures garantit que, lors d'un filtrage bilinéaire, les quatre texels nécessaires sont lus en même temps, chacun depuis une RAM différente. Le format de texture est illustré ci-dessous : chaque couleur correspond à une mémoire différent, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>i07iamjvk7ecbcbnhnqvxxi3wxkhf9n</sha1>
    </revision>
    <revision>
      <id>772322</id>
      <parentid>772321</parentid>
      <timestamp>2026-09-16T17:23:39Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les cartes accélératrices 3D avant Direct X 6.0 */</comment>
      <origin>772322</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62239" sha1="o04xe43lva2qp7oz18yf72aars1gfjz" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier sert à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. À la place, il y a deux mémoires séparées : une pour les textures et une pour le ''framebuffer''. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont converties en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées, à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire. L'idée est qu'un pixel à l'écran ne tombe pas souvent pile sur un texel. Il est alors difficile de déterminer la couleur du pixel. Une solution simple prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche. Une solution alternative, appelée '''filtrage bilinéaire''', prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

Rappelons que la mémoire de texture est composée de 4 mémoires de 1 mébioctet chacune. Et l'unité de texture peut accéder aux quatre mémoires RAM en même temps. Le format des textures garantit que, lors d'un filtrage bilinéaire, les quatre texels nécessaires sont lus en même temps, chacun depuis une RAM différente. Le format de texture est illustré ci-dessous : chaque couleur correspond à une mémoire différente, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>o04xe43lva2qp7oz18yf72aars1gfjz</sha1>
    </revision>
    <revision>
      <id>772323</id>
      <parentid>772322</parentid>
      <timestamp>2026-09-16T17:30:34Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les cartes accélératrices 3D avant Direct X 6.0 */</comment>
      <origin>772323</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62774" sha1="srwqblyfd0an509yeukcltxm24ao81g" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier sert à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. À la place, il y a deux mémoires séparées : une pour les textures et une pour le ''framebuffer''. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont converties en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées, à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire.

L'idée est que lors du placage de textures, un texel ne tombe pas tout pile sur un pixel à l'écran (je rappelle que pixels et texels sont des points, pas des petits carrés). Un pixel est alors entouré de plusieurs texels, et il faut bien les choisir pour calculer la couleur du pixel. Une solution simple prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche, avec beaucoup d'aliasising et des scintillements lorsque la caméra bouge. Une solution alternative, appelée '''filtrage bilinéaire''', prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

La Voodoo intégre une optimisation pour que le filtrage bilinéaire se fasse rapidement. Le filtrage bilinéaire demande de lire quatre texels. Sans optimisation, ils sont lus un par un depuis la mémoire de texture. Avec l'optimisation, ils sont tous lus en même temps. Pour ce faire, la Voodoo profite du fait que sa mémoire de texture est composée de 4 RAM EDO. La Voodoo répartit les texels dans les quatre mémoires, de manière à ce lors d'un filtrage bilinéaire, les quatre texels nécessaires soient chacun dans une mémoire séparée des autres.

La répartition des texels est illustrée ci-dessous. Le tableau correspond à une texture, chaque case est un texel. Chaque couleur correspond à une mémoire différente, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>srwqblyfd0an509yeukcltxm24ao81g</sha1>
    </revision>
    <revision>
      <id>772324</id>
      <parentid>772323</parentid>
      <timestamp>2026-09-16T17:39:30Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les cartes accélératrices 3D avant Direct X 6.0 */</comment>
      <origin>772324</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62780" sha1="7gjpxauecpozlf6xxkmshlx8b1qir7c" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier sert à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. À la place, il y a deux mémoires séparées : une pour les textures et une pour le ''framebuffer''. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont converties en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées, à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire.

L'idée est que lors du placage de textures, un texel ne tombe pas tout pile sur un pixel à l'écran (je rappelle que pixels et texels sont des points, pas des petits carrés). Un pixel est alors entouré de plusieurs texels, et il faut bien les choisir pour calculer la couleur du pixel. Une solution simple, appelée ''filtrage au plus proche'', prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche, avec beaucoup d'aliasising et des scintillements lorsque la caméra bouge. Le '''filtrage bilinéaire''' prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

La Voodoo intégre une optimisation pour que le filtrage bilinéaire se fasse rapidement. Le filtrage bilinéaire demande de lire quatre texels. Sans optimisation, ils sont lus un par un depuis la mémoire de texture. Avec l'optimisation, ils sont tous lus en même temps. Pour ce faire, la Voodoo profite du fait que sa mémoire de texture est composée de 4 RAM EDO. La Voodoo répartit les texels dans les quatre mémoires, de manière à ce lors d'un filtrage bilinéaire, les quatre texels nécessaires soient chacun dans une mémoire séparée des autres.

La répartition des texels est illustrée ci-dessous. Le tableau correspond à une texture, chaque case est un texel. Chaque couleur correspond à une mémoire différente, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>7gjpxauecpozlf6xxkmshlx8b1qir7c</sha1>
    </revision>
    <revision>
      <id>772325</id>
      <parentid>772324</parentid>
      <timestamp>2026-09-16T17:45:06Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les cartes accélératrices 3D avant Direct X 6.0 */</comment>
      <origin>772325</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62805" sha1="85h1affwdlthx5htmj6d92t3ewh8b8k" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier sert à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. À la place, il y a deux mémoires séparées : une pour les textures, une pour le ''framebuffer'' et le tampon de profondeur. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface un rectangle dans le ''framebuffer'' et le tampon de profondeur, peut effacer complétement leur contenu si le rectangle prend tout l'écran.
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont converties en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées, à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire.

L'idée est que lors du placage de textures, un texel ne tombe pas tout pile sur un pixel à l'écran (je rappelle que pixels et texels sont des points, pas des petits carrés). Un pixel est alors entouré de plusieurs texels, et il faut bien les choisir pour calculer la couleur du pixel. Une solution simple, appelée ''filtrage au plus proche'', prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche, avec beaucoup d'aliasising et des scintillements lorsque la caméra bouge. Le '''filtrage bilinéaire''' prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

La Voodoo intégre une optimisation pour que le filtrage bilinéaire se fasse rapidement. Le filtrage bilinéaire demande de lire quatre texels. Sans optimisation, ils sont lus un par un depuis la mémoire de texture. Avec l'optimisation, ils sont tous lus en même temps. Pour ce faire, la Voodoo profite du fait que sa mémoire de texture est composée de 4 RAM EDO. La Voodoo répartit les texels dans les quatre mémoires, de manière à ce lors d'un filtrage bilinéaire, les quatre texels nécessaires soient chacun dans une mémoire séparée des autres.

La répartition des texels est illustrée ci-dessous. Le tableau correspond à une texture, chaque case est un texel. Chaque couleur correspond à une mémoire différente, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>85h1affwdlthx5htmj6d92t3ewh8b8k</sha1>
    </revision>
    <revision>
      <id>772326</id>
      <parentid>772325</parentid>
      <timestamp>2026-09-16T17:46:38Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les cartes accélératrices 3D avant Direct X 6.0 */</comment>
      <origin>772326</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62824" sha1="tnzo44u0m8mf1inatir6zlbmtojbb4o" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier sert à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. À la place, il y a deux mémoires séparées : une pour les textures, une pour le ''framebuffer'' et le tampon de profondeur. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface le ''framebuffer'' et le tampon de profondeur. &lt;/br&gt; ''Pour être plus précis, elle efface un rectangle à l'écran, ce rectangle peut prendre tous l'écran.''
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont converties en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées, à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire.

L'idée est que lors du placage de textures, un texel ne tombe pas tout pile sur un pixel à l'écran (je rappelle que pixels et texels sont des points, pas des petits carrés). Un pixel est alors entouré de plusieurs texels, et il faut bien les choisir pour calculer la couleur du pixel. Une solution simple, appelée ''filtrage au plus proche'', prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche, avec beaucoup d'aliasising et des scintillements lorsque la caméra bouge. Le '''filtrage bilinéaire''' prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

La Voodoo intégre une optimisation pour que le filtrage bilinéaire se fasse rapidement. Le filtrage bilinéaire demande de lire quatre texels. Sans optimisation, ils sont lus un par un depuis la mémoire de texture. Avec l'optimisation, ils sont tous lus en même temps. Pour ce faire, la Voodoo profite du fait que sa mémoire de texture est composée de 4 RAM EDO. La Voodoo répartit les texels dans les quatre mémoires, de manière à ce lors d'un filtrage bilinéaire, les quatre texels nécessaires soient chacun dans une mémoire séparée des autres.

La répartition des texels est illustrée ci-dessous. Le tableau correspond à une texture, chaque case est un texel. Chaque couleur correspond à une mémoire différente, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>tnzo44u0m8mf1inatir6zlbmtojbb4o</sha1>
    </revision>
    <revision>
      <id>772327</id>
      <parentid>772326</parentid>
      <timestamp>2026-09-16T17:47:08Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les cartes accélératrices 3D avant Direct X 6.0 */</comment>
      <origin>772327</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62824" sha1="8xmsdq6m8pvjzmlsjplh0e9pdioyjdp" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier sert à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. À la place, il y a deux mémoires séparées : une pour les textures, une pour le ''framebuffer'' et le tampon de profondeur. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

L'unité de texture supporte des fonctionnalités qu'on pourrait croire avancées, à savoir le filtrage bilinéaire et le mip-mapping. Nous détaillerons ces deux techniques dans le chapitre sur les unités de textures, mais nous allons devoir parler rapidement du filtrage bilinéaire.

L'idée est que lors du placage de textures, un texel ne tombe pas tout pile sur un pixel à l'écran (je rappelle que pixels et texels sont des points, pas des petits carrés). Un pixel est alors entouré de plusieurs texels, et il faut bien les choisir pour calculer la couleur du pixel. Une solution simple, appelée ''filtrage au plus proche'', prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche, avec beaucoup d'aliasising et des scintillements lorsque la caméra bouge. Le '''filtrage bilinéaire''' prend les quatre texels les plus proches et en fait une moyenne pondérée. C'est cette moyenne qui donne la couleur finale du pixel. 

La Voodoo intégre une optimisation pour que le filtrage bilinéaire se fasse rapidement. Le filtrage bilinéaire demande de lire quatre texels. Sans optimisation, ils sont lus un par un depuis la mémoire de texture. Avec l'optimisation, ils sont tous lus en même temps. Pour ce faire, la Voodoo profite du fait que sa mémoire de texture est composée de 4 RAM EDO. La Voodoo répartit les texels dans les quatre mémoires, de manière à ce lors d'un filtrage bilinéaire, les quatre texels nécessaires soient chacun dans une mémoire séparée des autres.

La répartition des texels est illustrée ci-dessous. Le tableau correspond à une texture, chaque case est un texel. Chaque couleur correspond à une mémoire différente, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface le ''framebuffer'' et le tampon de profondeur. &lt;/br&gt; ''Pour être plus précis, elle efface un rectangle à l'écran, ce rectangle peut prendre tous l'écran.''
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont converties en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>8xmsdq6m8pvjzmlsjplh0e9pdioyjdp</sha1>
    </revision>
    <revision>
      <id>772328</id>
      <parentid>772327</parentid>
      <timestamp>2026-09-16T17:56:00Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les cartes accélératrices 3D avant Direct X 6.0 */</comment>
      <origin>772328</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="62822" sha1="pl0d5g03jq4auf6az2mhcrk5ningoq2" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier sert à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. À la place, il y a deux mémoires séparées : une pour les textures, une pour le ''framebuffer'' et le tampon de profondeur. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

L'unité de texture supporte des fonctionnalités avancées, appelées ''filtrage bilinéaire'' et ''mip-mapping''., que nous détaillerons dans le chapitre sur les unités de textures. Mais parlons rapidement du filtrage bilinéaire.

Lors du placage de textures, un texel ne tombe pas tout pile sur un pixel à l'écran (je rappelle que pixels et texels sont des points, pas des petits carrés). Un pixel est alors entouré de plusieurs texels, et la couleur du pixel est calculée à partir des texels alentour. Une solution simple, appelée ''filtrage au plus proche'', prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche, avec des scintillements lorsque la caméra bouge. Le '''filtrage bilinéaire''' prend les quatre texels les plus proches et en fait une moyenne pondérée. Il donne un résultat bien plus joli à l'écran, sans causer de scintillement ni d'aliasing.

La Voodoo intègre une optimisation pour le filtrage bilinéaire. Le filtrage bilinéaire demande de lire quatre texels. Sans optimisation, ils sont lus un par un depuis la mémoire de texture. Avec l'optimisation, ils sont tous lus en même temps. Pour ce faire, la Voodoo profite du fait que sa mémoire de texture est composée de 4 RAM EDO. La Voodoo répartit les texels dans les quatre mémoires, de manière à ce lors d'un filtrage bilinéaire, les quatre texels nécessaires soient chacun dans une mémoire séparée des autres.

La répartition des texels est illustrée ci-dessous. Le tableau correspond à une texture, chaque case est un texel. Chaque couleur correspond à une mémoire différente, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

Le Voodoo supporte l'antialiasing et l'éclairage de Gouraud en matériel.

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline. Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface le ''framebuffer'' et le tampon de profondeur. &lt;/br&gt; ''Pour être plus précis, elle efface un rectangle à l'écran, ce rectangle peut prendre tous l'écran.''
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont converties en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>pl0d5g03jq4auf6az2mhcrk5ningoq2</sha1>
    </revision>
    <revision>
      <id>772329</id>
      <parentid>772328</parentid>
      <timestamp>2026-09-16T18:58:16Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les cartes accélératrices 3D avant Direct X 6.0 */</comment>
      <origin>772329</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="63103" sha1="39qekn83g2ysu4osutfe084yzxbo2qr" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier sert à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. À la place, il y a deux mémoires séparées : une pour les textures, une pour le ''framebuffer'' et le tampon de profondeur. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

L'unité de texture supporte des fonctionnalités avancées, appelées ''filtrage bilinéaire'' et ''mip-mapping''., que nous détaillerons dans le chapitre sur les unités de textures. Mais parlons rapidement du filtrage bilinéaire.

Lors du placage de textures, un texel ne tombe pas tout pile sur un pixel à l'écran (je rappelle que pixels et texels sont des points, pas des petits carrés). Un pixel est alors entouré de plusieurs texels, et la couleur du pixel est calculée à partir des texels alentour. Une solution simple, appelée ''filtrage au plus proche'', prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche, avec des scintillements lorsque la caméra bouge. Le '''filtrage bilinéaire''' prend les quatre texels les plus proches et en fait une moyenne pondérée. Il donne un résultat bien plus joli à l'écran, sans causer de scintillement ni d'aliasing.

La Voodoo intègre une optimisation pour le filtrage bilinéaire. Le filtrage bilinéaire demande de lire quatre texels. Sans optimisation, ils sont lus un par un depuis la mémoire de texture. Avec l'optimisation, ils sont tous lus en même temps. Pour ce faire, la Voodoo profite du fait que sa mémoire de texture est composée de 4 RAM EDO. La Voodoo répartit les texels dans les quatre mémoires, de manière à ce lors d'un filtrage bilinéaire, les quatre texels nécessaires soient chacun dans une mémoire séparée des autres.

La répartition des texels est illustrée ci-dessous. Le tableau correspond à une texture, chaque case est un texel. Chaque couleur correspond à une mémoire différente, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

Le Voodoo supporte l'antialiasing et l'éclairage de Gouraud en matériel.

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface le ''framebuffer'' et le tampon de profondeur. &lt;/br&gt; ''Pour être plus précis, elle efface un rectangle à l'écran, ce rectangle peut prendre tous l'écran.''
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés. La FIFO fait exactement 64 écritures (des commandes surtout, mais pas que). De plus, la Voodoo peut utiliser la mémoire du ''framebuffer'' comme FIFO secondaire. Elle peut réserver de l'espace inutilisé pour cette FIFO secondaire, avec au maximum 65536 écritures en attente.

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont converties en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>39qekn83g2ysu4osutfe084yzxbo2qr</sha1>
    </revision>
    <revision>
      <id>772330</id>
      <parentid>772329</parentid>
      <timestamp>2026-09-16T22:24:13Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les cartes accélératrices 3D avant Direct X 6.0 */</comment>
      <origin>772330</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="63278" sha1="2omh7za1r5j83i65myszylgpb1cnh9z" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier sert à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. À la place, il y a deux mémoires séparées : une pour les textures, une pour le ''framebuffer'' et le tampon de profondeur. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

L'unité de texture supporte des fonctionnalités avancées, appelées ''filtrage bilinéaire'' et ''mip-mapping''., que nous détaillerons dans le chapitre sur les unités de textures. Mais parlons rapidement du filtrage bilinéaire.

Lors du placage de textures, un texel ne tombe pas tout pile sur un pixel à l'écran (je rappelle que pixels et texels sont des points, pas des petits carrés). Un pixel est alors entouré de plusieurs texels, et la couleur du pixel est calculée à partir des texels alentour. Une solution simple, appelée ''filtrage au plus proche'', prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche, avec des scintillements lorsque la caméra bouge. Le '''filtrage bilinéaire''' prend les quatre texels les plus proches et en fait une moyenne pondérée. Il donne un résultat bien plus joli à l'écran, sans causer de scintillement ni d'aliasing.

La Voodoo intègre une optimisation pour le filtrage bilinéaire. Le filtrage bilinéaire demande de lire quatre texels. Sans optimisation, ils sont lus un par un depuis la mémoire de texture. Avec l'optimisation, ils sont tous lus en même temps. Pour ce faire, la Voodoo profite du fait que sa mémoire de texture est composée de 4 RAM EDO. La Voodoo répartit les texels dans les quatre mémoires, de manière à ce lors d'un filtrage bilinéaire, les quatre texels nécessaires soient chacun dans une mémoire séparée des autres.

La répartition des texels est illustrée ci-dessous. Le tableau correspond à une texture, chaque case est un texel. Chaque couleur correspond à une mémoire différente, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

Le Voodoo supporte l'antialiasing et l'éclairage de Gouraud en matériel.

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface le ''framebuffer'' et le tampon de profondeur. &lt;/br&gt; ''Pour être plus précis, elle efface un rectangle à l'écran, ce rectangle peut prendre tous l'écran.''
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés. La FIFO fait exactement 64 écritures (des commandes surtout, mais pas que). De plus, la Voodoo peut utiliser la mémoire du ''framebuffer'' comme FIFO secondaire. Elle peut réserver de l'espace inutilisé pour cette FIFO secondaire, avec au maximum 65536 écritures en attente.

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont converties en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

: Vous pouvez trouver la documentation d'époque sur les cartes Voodoo de 3dfx via ce lien : [http://bitsavers.computerhistory.org/components/3dfx/ Bitsavers, section 3dfx].

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique du '''''multi-texturing'''''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effet graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails, du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 supportait l'application de plusieurs textures directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublaient les unités de texture et adaptaient les connexions entre unités de texture et mémoire vidéo. La mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>2omh7za1r5j83i65myszylgpb1cnh9z</sha1>
    </revision>
    <revision>
      <id>772331</id>
      <parentid>772330</parentid>
      <timestamp>2026-09-16T22:38:23Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Le multi-texturing de l'époque Direct X 6.0 : combiner plusieurs textures */</comment>
      <origin>772331</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="64068" sha1="2rz4guepa1bgvge10719zvlqyjejzz9" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier sert à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. À la place, il y a deux mémoires séparées : une pour les textures, une pour le ''framebuffer'' et le tampon de profondeur. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

L'unité de texture supporte des fonctionnalités avancées, appelées ''filtrage bilinéaire'' et ''mip-mapping''., que nous détaillerons dans le chapitre sur les unités de textures. Mais parlons rapidement du filtrage bilinéaire.

Lors du placage de textures, un texel ne tombe pas tout pile sur un pixel à l'écran (je rappelle que pixels et texels sont des points, pas des petits carrés). Un pixel est alors entouré de plusieurs texels, et la couleur du pixel est calculée à partir des texels alentour. Une solution simple, appelée ''filtrage au plus proche'', prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche, avec des scintillements lorsque la caméra bouge. Le '''filtrage bilinéaire''' prend les quatre texels les plus proches et en fait une moyenne pondérée. Il donne un résultat bien plus joli à l'écran, sans causer de scintillement ni d'aliasing.

La Voodoo intègre une optimisation pour le filtrage bilinéaire. Le filtrage bilinéaire demande de lire quatre texels. Sans optimisation, ils sont lus un par un depuis la mémoire de texture. Avec l'optimisation, ils sont tous lus en même temps. Pour ce faire, la Voodoo profite du fait que sa mémoire de texture est composée de 4 RAM EDO. La Voodoo répartit les texels dans les quatre mémoires, de manière à ce lors d'un filtrage bilinéaire, les quatre texels nécessaires soient chacun dans une mémoire séparée des autres.

La répartition des texels est illustrée ci-dessous. Le tableau correspond à une texture, chaque case est un texel. Chaque couleur correspond à une mémoire différente, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

Le Voodoo supporte l'antialiasing et l'éclairage de Gouraud en matériel.

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface le ''framebuffer'' et le tampon de profondeur. &lt;/br&gt; ''Pour être plus précis, elle efface un rectangle à l'écran, ce rectangle peut prendre tous l'écran.''
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés. La FIFO fait exactement 64 écritures (des commandes surtout, mais pas que). De plus, la Voodoo peut utiliser la mémoire du ''framebuffer'' comme FIFO secondaire. Elle peut réserver de l'espace inutilisé pour cette FIFO secondaire, avec au maximum 65536 écritures en attente.

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont converties en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

: Vous pouvez trouver la documentation d'époque sur les cartes Voodoo de 3dfx via ce lien : [http://bitsavers.computerhistory.org/components/3dfx/ Bitsavers, section 3dfx].

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique dite du ''multi-texturing''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effets graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails ou du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 a justement introduit le '''''multi-texturing''''', à savoir l'application de plusieurs textures sur une même surface, directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublait les unités de texture. De plus, la mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

Un exemple de carte accélératrice gérant le ''multi-texturing'' est la carte Voodoo 2, de 3dfx. Le support du ''multi-texturing'' avait été anticipé, et la Voodoo 1 aurait pu l'implémenter assez simplement. L'unité de texture de la Voodoo 1, la TREX, intégrait déjà un ''combiner'' et de quoi l'utiliser. Elle pouvait prendre en entrée un &quot;pixel&quot;, le combiner avec un texel lu depuis la mémoire vidéo, et fournit le résultat en sortie. Pour cela, elle disposait d'un bus d'extension spécialisé, qui permettait d'enchainer plusieurs unités TREX l'une à la suite de l'autre. Toute unité TREX avait une entrée et une sortie : une entrée pour recevoir un pixel texturé par l'unité de texture précédent, une sortie pour envoyer son résultat à la suivante.

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>2rz4guepa1bgvge10719zvlqyjejzz9</sha1>
    </revision>
    <revision>
      <id>772332</id>
      <parentid>772331</parentid>
      <timestamp>2026-09-16T22:45:01Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Le multi-texturing de l'époque Direct X 6.0 : combiner plusieurs textures */</comment>
      <origin>772332</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="64166" sha1="6fvnszaact5prrtfx2f7s0mreku50n2" xml:space="preserve">Il est intéressant d'étudier le hardware des cartes graphiques en faisant un petit résumé de leur évolution dans le temps. En effet, leur hardware a fortement évolué dans le temps. Et il serait difficile à comprendre le hardware actuel sans parler du hardware d'antan. En effet, une carte graphique moderne est partiellement programmable. Certains circuits sont totalement programmables, d'autres non. Et pour comprendre pourquoi, il faut étudier comment ces circuits ont évolués.

Le hardware des cartes graphiques a fortement évolué dans le temps, ce qui n'est pas une surprise. Les évolutions de la technologie, avec la miniaturisation des transistors et l'augmentation de leurs performances a permis aux cartes graphiques d'incorporer de plus en plus de circuits avec les années. Avant l'invention des cartes graphiques, toutes les étapes du pipeline graphique étaient réalisées par le processeur : il calculait l'image à afficher, et l’envoyait à une carte d'affichage 2D. Au fil du temps, de nombreux circuits furent ajoutés, afin de déporter un maximum de calculs vers la carte vidéo.

Le rendu 3D moderne est basé sur le placage de texture inverse, avec des coordonnées de texture, une correction de perspective, etc. Mais les anciennes consoles et bornes d'arcade utilisaient le placage de texture direct. Et cela a impacté le hardware des consoles/PCs de l'époque. Avec le placage de texture direct, il était primordial de calculer la géométrie, mais la rasterisation était le fait de VDC améliorés. Aussi, les premières bornes d'arcade 3D et les consoles de 5ème génération disposaient processeurs pour calculer la géométrie et de circuits d'application de textures très particuliers. À l'inverse, les PC utilisaient un rendu inverse, totalement différent. Sur les PC, les premières cartes graphiques avaient un circuit de rastérisation et des unités de textures, mais pas de circuits géométriques.

==Les premières cartes graphiques, pour ''mainframes'' et stations de travail==

Dès les années 70-80, le rendu 3D était utilisé par de nombreuses entreprises industrielles : des applications de visualisation 3D étaient utilisées en architecture, des applications de conception assistée par ordinateur étaient déjà d'utilisation courante, sans compter les simulateurs de vol utilisés par l'armée et les instructeurs qui formaient les pilotes d'avion. Le rendu 3D était aussi étudié au niveau académique, la recherche en 3D était déjà florissante.

Il existait même du matériel spécifiquement conçu pour le rendu graphique, mais celui-ci était spécifiquement dédié à des super-calculateurs ou des ''workstations'' (des sortes d'ancêtres des PC, très puissants pour l'époque, mais conçus uniquement pour les entreprises).

===Le début des années 80 : le rendu en fils de fer===

Le tout premier système de ce genre était le '''''Line Drawing System-1''''' de l'entreprise Evans &amp; Sutherland, daté de 1969. Ce n'est ni plus ni moins que le toute premier circuit graphique séparé du processeur ayant existé. C'est en un sens la toute première carte graphique, le tout premier GPU. Il prenait la forme d'un périphérique qui se connectait à l'ordinateur d'un côté et était relié à l'écran de l'autre. Il était compatible avec un grand nombre d'ordinateurs et de processeurs existants. Il a été suivi par plusieurs successeurs, nommés ''Picture System 1, 2'' et le ''PS300 series''.

[[File:Evans &amp; Sutherland LDS-1 (1).jpg|vignette|Evans &amp; Sutherland LDS-1 (1)]]

Ils permettaient de faire du rendu en fil de fer, sans texture ni même sans polygones colorés. Un tel rendu était utile pour des applications assez limitées : architecture, dessin de molécules pour les entreprises pharmaceutique et certains centres de recherche, l'aérospatiale, etc. 

Ces cartes graphiques étaient utilisées de concert avec des écrans appelés '''écrans vectoriels''' (''vector display''). Pour simplifier, ils ressemblaient à des écrans CRT, sauf que le faisceau d'électron ne balayait pas l'écran ligne par ligne, mais traçait des lignes arbitraires à l'écran. On lui précisait deux points de coordonnées x1,y1 ; et x2,y2 ; puis l'écran tracait une ligne entre ces deux points. En général, la ligne tracée était maintenue pendant un long moment, entre plusieurs secondes et plusieurs minutes.

L'intérieur du circuit était assez simple : un circuit de multiplication de matrice pour les calculs géométriques, un rastériser simplifié (le ''clipping diviser''), un circuit de tracé de lignes, et un processeur de contrôle pour commander les autres circuits. Le fait que ces trois circuits soient séparés permettait une implémentation en pipeline, où plusieurs portions de l'image pouvaient être calculées en même temps : pendant que l'une est dans l'unité géométrique, l'autre est dans le rastériseur et une troisième est en cours de tracé.

[[File:Lds1blockdiagram05.svg|centre|vignette|upright=2|Architecture du LDS-1. Le processeur de contrôle n'est pas représenté.]]

Le processeur de contrôle exécute un programme qui se charge de commander l'unité géométrique et les autres circuits. Le programme en question est fourni par le programmeur, le LDS-1 est donc totalement programmable. Il lit directement les données nécessaires pour le rendu dans la mémoire de l’ordinateur et le programme exécuté est lui aussi en mémoire principale. Il n'a pas de mémoire vidéo dédiée, il utilise la RAM de l'ordinateur principal.

Le multiplieur de matrices est plus complexe qu'on pourrait s'y attendre. Il ne s'agit pas que d'un circuit arithmétique tout simple, mais d'un véritable processeur avec des registres et des instructions machine complexes. Il contient plusieurs registres, l'ensemble mémorisant 4 matrices de 16 nombres chacune (4 lignes de 4 colonnes). Un nombre est codé sur 18 bits. Les registres sont reliés à un ensemble de circuits arithmétiques, des additionneurs et des multiplieurs. Le circuit supporte des instructions de copie entre registres, pour copier une ligne d'une matrice à une autre, des instructions LOAD/STORE pour lire ou écrire dans la mémoire RAM, etc. Il supporte aussi des multiplications en 2D et 3D. 

Le ''clipping divider'' est un circuit assez complexe, contenant un processeur à accumulateur, une mémoire ROM pour le programme du processeur.  Le programme exécuté par le processeur est un petit programme de 62 instructions, stocké dans la ROM. L'algorithme du ''clipping divider'' est décrite dans le papier de recherche &quot;A clipping divider&quot;, écrit par Robert Sproull.

Un détail assez intéressant est que le résultat en sortie de l'unité géométrique et du rastériseur peuvent être envoyés à l'ordinateur en parallèle du rendu. C'était très utile sur les anciens ordinateurs qui étaient connectés à plusieurs terminaux. Le LDS-1 calculait la géométrie et le rendu, et le tout pouvait petre envoyé à d'autres composants, comme des terminaux, une imprimante, etc.

===Les systèmes ultérieurs : rendu à triangles colorés et texturé===

Les systèmes précédents étaient très limités : ils calculaient la géométrie et n'avaient pas de ''framebuffer'', ni de tampon de profondeur, ni gestion de l'éclairage, ni quoique ce soit. De tels systèmes étaient donc des accélérateurs géométriques que de vrais systèmes graphiques complets, du fait de l'absence de ''framebuffer''. Ils étaient composés de processeurs spécialisés dans les calculs à virgule flottante, faisant des calculs géométriques, et éventuellement d'un processeur pour la rastérisation. La raison est que la RAM était très chère et que créer des circuits fixes étaient très chers et peu disponibles. Par contre, les processeurs à virgule flottante étaient peu chers et facile à trouver. 

Vers la fin des années 80, grâce à la baisse du prix de la RAM et la démocratisation des ASIC (des circuits fixes fait sur mesure), ajouter un ''framebuffer'' est est devenu possible. C'est alors que sont apparus les '''systèmes de rendu 3D de première génération'''. De tels systèmes ont permis d'implémenter le rendu à primitives colorées qu'on a vu il y a quelques chapitres, à savoir un rendu où les triangles sont coloriés avec une couleur unique. Les systèmes de première génération étaient simples : des processeurs pour le calcul de la géométrie, un circuit de rastérisation, une RAM pour le ''framebuffer'' et des ASIC servant de ROPs très simples. Il n'y avait pas d'élimination des pixels cachés, pas de textures, et encore moins d'éclairage par pixels.

Le premier système de ce genre était le ''Shaded Picture System'', toujours par Evans &amp; Sutherland. Il ne gérait pas la couleur et ne pouvait afficher que des images en noir et blanc, mais il gérait l'éclairage par sommet (''vertex lighting''). Il a rapidement été dépassé par les systèmes de l'entreprise ''Silicon Graphics Inc'' (SGI), ainsi que ceux de l'entreprise Apollo avec sa série Apollo DN.

Les '''systèmes de seconde génération''' sont apparus vers la fin des années 80, et se distinguent des précédents par l'ajout un tampon de profondeur.  Ils intègrent aussi des capacités d'éclairage par pixel, à savoir de l'éclairage plat, de Gouraud, voire de Phong ! 

Enfin, les '''systèmes de troisième génération''' ont acquis des capacités de placage de texture, que les systèmes précédents n'avaient pas. Ils ont aussi ajouté un support de l'antialiasing. Les systèmes SGI avec placage de texture ont déjà été abordé au chapitre précédent, dans la section sur les GPU en mode immédiat et à ''tile''. Aussi, nous ne reviendrons pas dessus.

[[File:Evolution de l'architecture des premières cartes graphiques, dans les années 80-90.png|centre|vignette|upright=2.5|Evolution de l'architecture des premières cartes graphiques, dans les années 80-90]]

Les systèmes de première, seconde et troisième génération avaient de nombreux points communs. En premier lieu, ils étaient fabriqués en connectant plusieurs cartes électroniques : une carte pour les calculs géométriques, une ou plusieurs cartes pour le reste du rendu graphique, une carte dédiée au VDC et avec un connecteur écran. Les transistors de l'époque n'étaient pas encore miniaturisés, ce qui fait que le système graphique ne pouvait pas tenir sur une seule carte électronique. Il n'y avait donc pas de carte graphique proprement dit, mais un équivalent éclaté sur plusieurs cartes électroniques.

La carte pour la géométrie contenait typiquement une mémoire FIFO pour accumuler les commandes de rendu, un processeur de commande, et plusieurs processeurs géométriques. Les processeurs géométriques étaient parfois conçus sur mesure, comme l'a été le le ''Geometry Engine'' de SGI. Mais il est arrivé qu'ils utilisent des processeurs commerciaux comme le Weitek 3222, l'Intel i860, etc. Les processeurs pouvaient être placés en série ou en parallèle, comme expliqué dans le chapitre précédent.

Le circuit de rastérisation était réalisé soit avec un processeur dédié, soit avec un circuit fixe, soit un mélange des deux. La rastérisation est en effet réalisée en plusieurs étapes, certaines peuvent être implémentées avec un processeur et d'autres avec des circuits fixes. 

Un point important est qu'à l'époque, le rendu n'utilisait pas que des triangles, mais des polygones en général. Ce n'est que par la suite que le rendu s'est focalisé sur les triangles et les ''quads'' (quadrilatères). Il arrivait que le système graphique gérait partiellement des polygones concaves, voire convexes. Sur les systèmes SGI, les calculs géométriques se faisaient avec des polygones, que la rastérisation découpait en triangles, le reste du rendu se faisait avec des triangles. Les stations de travail Apollo DN 10000VS découpaient les polygones en trapézoïdes orientés à l'horizontale, alignés avec des ''scanlines''. D'autres systèmes découpaient tout en triangle lors de l'étape géométrique

==Les précurseurs grand public : les bornes d'arcade==

L'accélération du rendu 3D sur les bornes d'arcade était déjà bien avancé dès les années 90. Les bornes d'arcade ont toujours été un segment haut de gamme de l'industrie du jeu vidéo, aussi ce n'est pas étonnant. Le prix d'une borne d'arcade dépassait facilement les 10 000 dollars pour les plus chères et une bonne partie du prix était celui du matériel informatique. Le matériel était donc très puissant et débordait de mémoire RAM comparé aux consoles de jeu et aux PC.

[[File:Sega ST-V Dynamite Deka PCB 20100324.jpg|vignette|Sega ST-V Dynamite Deka PCB 20100324]]

La plupart des bornes d'arcade utilisaient du matériel standardisé entre plusieurs bornes. À l'intérieur d'une borne d'arcade se trouve une '''carte de borne d'arcade''' qui est une carte mère avec un ou plusieurs processeurs, de la RAM, une carte graphique, un VDC et pas mal d'autres matériels. La carte est reliée aux périphériques de la borne : joysticks, écran, pédales, le dispositif pour insérer les pièces afin de payer, le système sonore, etc. Le jeu utilisé pour la borne est placé dans une cartouche qui est insérée dans un connecteur spécialisé.

Les cartes de bornes d'arcade étaient généralement assez complexes, elles avaient une grande taille et avaient plus de composants que les cartes mères de PC. Chaque carte contenait un grand nombre de chips pour la mémoire RAM et ROM, et il n'était pas rare d'avoir plusieurs processeurs sur une même carte. Et il n'était pas rare d'avoir trois à quatre cartes superposées dans une seule borne. Pour ceux qui veulent en savoir plus, Fabien Sanglard a publié gratuitement un livre sur le fonctionnement des cartes d'arcade CPS System, disponible via ce lien : [https://fabiensanglard.net/b/cpsb.pdf The book of CP System].

Les premières cartes graphiques des bornes d'arcade étaient des cartes graphiques 2D auxquelles on avait ajouté quelques fonctionnalités. Les sprites pouvaient être tournés, agrandit/réduits, ou déformés pour simuler de la perspective et faire de la fausse 3D. Par la suite, le vrai rendu 3D est apparu sur les bornes d'arcade.

Dès 1988, la carte d'arcade Namco System 21	et Sega Model 1 géraient les calculs géométriques. Quelques années plus tard, les cartes graphiques se sont mises à supporter un éclairage de Gouraud et du placage de texture. Par exemple, le Namco System 22 et la Sega model 2 supportaient des textures 2D et comme le filtrage de texture (bilinéaire et trilinéaire), le mip-mapping, et quelques autres. Au passage, les cartes graphiques de la Namco System 22 étaient développées en partenariat avec Eans &amp; Sutherland, qui avait commencé à se diversifier dans le marché grand public.

Les cartes graphiques de l'époque faisaient les calculs géométriques sur plusieurs processeurs, généralement des processeurs de type DSP (des processeurs spécialisés dans le traitement de signal). Par exemple, la Namco System 2 utilisait 4 DSP de marque Texas Instruments TMS320C25, cadencés à 24,576 MHz. La carte d'arcade Sega Model 1 utilisait quant à elle un DSP spécialisé dans les calculs géométriques.

Par la suite, les bornes d'arcade ont réutilisé le hardware des PC et autres consoles de jeux.

==La 3D sur les consoles de quatrième/cinquième génération==

Les consoles avant la quatrième génération de console étaient des consoles purement 2D, sans circuits d'accélération 3D. Leur carte graphique était un simple VDC 2D, plus ou moins performant selon la console. Les premières consoles de jeu capables de rendu 3D par elles-mêmes sont les consoles dites de 5ème génération. Il y a diverses manières de classer les consoles en générations, la plus commune place la 3D à la 5ème génération, mais détailler ces controverses quant à ce classement nous amènerait trop loin.

Les consoles de génération avaient une architecture assez différente des systèmes antérieurs. Les systèmes SGI et assimilés pouvaient se permettre de couter assez cher, d'utiliser beaucoup de circuits, de prendre beaucoup de place. Les bornes d'arcade sont aussi dans ce cas. Aussi, il n'était pas rare que les cartes 3D de l'époque tiennent sur plusieurs cartes électroniques séparées. Mais une console ne peut pas se permettre ce genre de folies. Aussi, les cartes 3D des consoles de l'époque tenaient dans un seul circuit intégré, comme il est d'usage de nos jours.

La conséquence est que certains circuits étaient fortement simplifiés, sur les consoles de cinquième génération. Et cela a impacté l'architecture interne des GPU des consoles. Les systèmes SGI avaient plusieurs processeurs pour calculer la géométrie, couplés à plusieurs unités non-programmables pour les pixels/textures. Les cartes 3D des consoles gardaient cette organisation : processeurs pour la géométrie, circuits fixes pour le reste. Mais elles se débrouillaient souvent avec un seul processeur, voire aucun ! Dans ce dernier cas, la géométrie était calculée sur le processeur principal, le CPU. Les unités pour les pixels étaient aussi moins nombreuses, mais il y en avait plusieurs, pour profiter de l'amplification des pixels.

: Les cartes 3D des consoles de jeu utilisaient le placage de texture inverse, avec quelques exceptions qui utilisaient le placage de texture direct.

===Le rendu 3D sur les consoles de quatrième génération : la SNES===

Plus haut, j'ai dit que les consoles de quatrième génération n'avaient pas de carte accélératrice 3D. Pourtant, elles ont connus quelques jeux en vraie 3D. La raison à cela est que la 3D était calculée par un GPU placé dans les cartouches du jeu ! Par exemple, les cartouches de Starfox et de Super Mario 2 contenaient un coprocesseur Super FX, qui gérait des calculs de rendu 2D/3D.

En tout, il y a environ 16 coprocesseurs pour la SNES et on en trouve facilement la liste sur le net. La console était conçue pour, des pins sur les ports cartouches étaient prévues pour des fonctionnalités de cartouche annexes, dont ces coprocesseurs. Ces pins connectaient le coprocesseur au bus des entrées-sorties. Les coprocesseurs des cartouches de NES avaient souvent de la mémoire rien que pour eux, qui était intégrée dans la cartouche.

Ceci étant dit, passons aux consoles de cinquième génération.

===La Nintendo 64 : un GPU avancé===

La Nintendo 64 avait le GPU le plus complexe comparé aux autres consoles, et dépassait même les cartes graphiques des PC. Il faut dire que son GPU a été conçu avec l'aide de l'entreprise SGI, dont on a vu les systèmes graphiques plus haut. Le GPU de la N64 incorporait une unité pour les calculs géométriques, un circuit de rasterisation, une unité de textures et un ROP final pour les calculs de transparence/brouillard/antialiasing, ainsi qu'un circuit pour gérer la profondeur des pixels. En somme, tout le pipeline graphique était implémenté dans le GPU de la Nintendo 64, chose très en avance sur son temps, comparé au PC ou aux autres consoles !

Le GPU est construit autour d'un processeur dédié aux calculs géométriques, le ''Reality Signal Processor'' (RSP), autour duquel on a ajouté des circuits pour le reste du pipeline graphique. L'unité de calcul géométrique est un processeur MIPS R4000, un processeur assez courant à l'époque, auquel on avait retiré quelques fonctionnalités inutiles pour le rendu 3D. Il était couplé à 4 KB de mémoire vidéo, ainsi qu'à 4 KB de mémoire ROM. Le reste du GPU était réalisé avec des circuits fixes.

Un point intéressant est que le programme exécuté par le RSP pouvait être programmé ! Le RSP gérait déjà des espèces de proto-shaders, qui étaient appelés des ''[https://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/microcode.html micro-codes]'' dans la documentation de l'époque. La ROM associée au RSP mémorise cinq à sept programmes différents, aux fonctionnalités différentes.
* Les microcodes gspFast3D et gspF3DNoN, implémentent un rendu 3D normal, avec des options de ''clipping'' différentes entre les deux.
* Le microcode gspTurbo3D fait la même chose, mais avec moins de fonctionnalités et avec une précision réduite. Il ne gère pas le ''clipping'', l'éclairage par pixel, la correction de perspective, l'antialiasing et quelques autres fonctionnalités. Il gère cependant l'éclairage de Gouraud. Il utilise une ''display list'' simplifiée comparé aux deux microcodes précédents.
* Le microcode gspZ-Sort effectue une pré-passe z, à savoir qu'il calcule le tampon de profondeur final de la scène 3D, sans rendre l'image. Cela sert à faire une élimination des pixels cachés parfaite, en logiciel. On calcule le tampon de profondeur pour déterminer quels pixels sont visibles, puis une seconde passe rend l'image en, rejetant les pixels non-visibles.
* Le microcode gspSprite2D implémente un rendu 2D émulé : les sprites et arrière-plan sont des rectangles texturés. Le microcode gspS2DEX fait la même chose, mais sert à émuler le rendu de la SNES plus qu'autre chose.
* Le microcode gspLine3D ne gére que des lignes, pas de triangles. Il sert pour du rendu en fil de fer.

Ils géraient le rendu 3D de manière différente et avec une gestion des ressources différentes. Très peu de studios de jeu vidéo ont développé leur propre microcodes N64, car la documentation était mal faite, que Nintendo ne fournissait pas de support officiel pour cela, que les outils de développement ne permettaient pas de faire cela proprement et efficacement.

===La Playstation 1===

Sur la Playstation 1 le calcul de la géométrie était réalisé par le processeur, la carte graphique gérait tout le reste. Et la carte graphique était un circuit fixe spécialisé dans la rasterisation et le placage de textures. Elle utilisait, comme la Nintendo 64, le placage de texture inverse, qui est apparu ensuite sur les cartes graphiques.

===La 3DO et la Sega Saturn===

La Sega Saturn et la 3DO étaient les deux seules consoles à utiliser le rendu direct. La géométrie était calculée sur le processeur, même si les consoles utilisaient parfois un CPU dédié au calcul de la géométrie. Le reste du pipeline était géré par un VDC 2D qui implémentait le placage de textures.

La Sega Saturn incorpore trois processeurs et deux GPU. Les deux GPUs sont nommés le VDP1 et le VDP2. Le VDP1 s'occupe des textures et des sprites, le VDP2 s'occupe uniquement de l'arrière-plan et incorpore un VDC tout ce qu'il y a de plus simple. Ils ne gèrent pas du tout la géométrie, qui est calculée par les trois processeurs.

Le troisième processeur, la Saturn Control Unit, est un processeur de type DSP, à savoir un processeur spécialisé dans le traitement de signal. Il est utilisé presque exclusivement pour accélérer les calculs géométriques. Il avait sa propre mémoire RAM dédiée, 32 KB de SRAM, soit une mémoire locale très rapide. Les transferts entre cette RAM et le reste de l'ordinateur était géré par un contrôleur DMA intégré dans le DSP. En somme, il s'agit d'une sorte de processeur spécialisé dans la géométrie, une sorte d'unité géométrique programmable. Mais la géométrie n'était pas forcément calculée que sur ce DSP, mais pouvait être prise en charge par les 3 CPU.

==L'historique des cartes graphiques pour PC==

Sur PC, l'évolution des cartes graphiques a eu du retard par rapport aux consoles. Les PC sont en effet des machines multi-usage, contrairement aux consoles qui sont spécifiquement conçues pour le jeu vidéo. De plus, l'écosystème des PC était fragmenté en plusieurs machines différentes : machines Apple 1 et 2, ordinateurs Commdore et Amiga, IBM PC et dérivés, etc. Aussi, programmer des jeux PC n'était pas mince affaire, car les problèmes de compatibilité étaient légion. C'est seulement quand la plateforme x86 des IBM PC s'est démocratisée que l'informatique grand public s'est standardisée, réduisant fortement les problèmes de compatibilité. Mais cela n'a pas suffit, il a aussi fallu que les API 3D naissent.

Les API 3D comme Direct X et Open GL sont absolument cruciales pour garantir la compatibilité entre plusieurs ordinateurs aux cartes graphiques différentes. Aussi, l'évolution des cartes graphiques pour PC s'est faite main dans la main avec l'évolution des API 3D. Du moins dans les grandes lignes, car il est arrivé plusieurs fois que des fonctionnalités naissent sur les cartes graphiques, pour que les fabricants forcent la main de Microsoft ou d'Open GL pour les intégrer de force dans les API 3D. Passons.

Open GL existait déjà avant l'apparition des cartes accélératrices 3D. Elle est en effet un dérivé libre de l'API Iris GL, l'API que SGI avait programmée pour ses stations de travail Iris Graphics. Elle était surtout utilisé pour des applications industrielles, médicales (imagerie), graphiques ou militaires. Il y a avait donc déjà un terreau que les programmeurs graphiques pouvaient utiliser. Et sa première utilisation dans le domaine du jeu vidéo a été le jeu Quake, d'IdSoftware, en 1996. Quake pouvait fonctionner en rendu logiciel, mais le programmeur responsable du moteur 3D (le célèbre John Carmack) ajouta une version OpenGL du jeu, même si aucune carte accélératrice de l'époque ne supportait OpenGL. C'était là un choix qui se révéla visionnaire, car les premières cartes graphiques étaient déjà dans les starting blocks.

Les cartes accélératrices 3D de l'époque ne supportaient pas toutes les fonctionnalités d'OpenGL, qui était partiellement implémentée en logiciel, partiellement en matériel. C'était l'époque du miniGL, des implémentations partielles d'OpenGL, fournies par les fabricants de cartes 3D, implémentées dans les pilotes de périphériques de ces dernières. Avec l'évolution du matériel, les pilotes de périphériques devinrent de plus en plus complets, au point de devenir des implémentations totales d'OpenGL.

Mais au-delà d'OpenGL, chaque fabricant de carte graphique avait sa propre API propriétaire, qui était gérée par leurs pilotes de périphériques (''drivers''). Par exemple, les premières cartes graphiques de 3dfx interactive, les fameuses Voodoo, disposaient de leur propre API graphique, l'API Glide. Mais ces API propriétaires tombèrent rapidement en désuétude avec l'évolution de DirectX et d'OpenGL.

Direct X était une API dans l'ombre d'Open GL. La première version de Direct X qui supportait la 3D était DirectX 2.0 (juin 2, 1996), suivie rapidement par DirectX 3.0 (septembre 1996). Elles utilisaient un système d'''execute buffer'' pour communiquer avec la carte graphique, qui n'a jamais été implémenté en matériel. Direct X 4.0 a été abandonné en cours de développement pour laisser à une version 5.0 assez semblable à la 2.0/3.0, mais qui laissait de côté les ''execute buffer'' pour coller un peu plus au hardware de l'époque. Mais rien de vraiment probant comparé à Open GL. Même Windows utilisait Open GL au lieu de Direct X maison...

C'est avec Direct X 6.0 que Direct X est entré dans la cours des grands. Il gérait la plupart des technologies supportées par les cartes graphiques de l'époque. Il a notamment introduit le ''multi-texturing'', ainsi que d'autres fonctionnalités de rendu particulièrement importantes. C'est à ce moment là que Direct X a pris le pas sur Open GL, et a imposé sa cadence sur la concurrence.

===La première carte 3D : la Rendition Vérité V1000===

La toute première carte 3D pour PC est la '''Rendition Vérité V1000''', sortie en Septembre 1995, soit quelques mois avant l'arrivée de la Nintendo 64. La Rendition Vérité V1000 contenait un processeur MIPS cadencé à 25 MHz, 4 mébioctets de RAM, une ROM pour le BIOS, et un RAMDAC, rien de plus. C'était un vrai ordinateur complètement programmable de bout en bout, sans aucun circuit fixe. Les programmeurs ne pouvaient cependant pas utiliser cette programmabilité avec des ''shaders'', mais elle permettait à Rendition d'implémenter n'importe quelle API 3D, que ce soit OpenGL, DirectX et son API propriétaire.

La Rendition Vérité avait de bonnes performances pour ce qui est de la géométrie, mais pas pour le reste. Réaliser la rastérisation et le placage de texture en logiciel n'est pas efficace, pareil pour les opérations de fin de pipeline comme l'antialiasing. Le manque d'unités fixes très rapides pour la rastérisation, le placage de texture ou les opérations de fin de pipeline était clairement un gros défaut. Mais la Rendition Vérité était un cas à part, une exception dans le paysage des cartes 3D de l'époque, qui ne faisait rien comme les autres.

===Les cartes accélératrices 3D avant Direct X 6.0===

Peu après, d'autres cartes accélératrices ont été commercialisées : les Voodoo de 3dfx, les Riva TNT de NVIDIA, les Rage/3D d'ATI, la Virge/3D de S3, et la Matrox Mystique. Elles avaient une architecture franchement différente de la Rendition Vérité. Au lieu d'utiliser un processeur, elles utilisaient des circuits fixes faits sur mesure pour une tâche bien précise, à savoir des ASICs. Elles intégraient un circuit de rastérisation, des unités de textures et des ROPs. Le ou les ROPs géraient le ''z-buffer'' en mémoire vidéo, ainsi que des effets de brouillard.

Elles avaient donc une architecture similaire à celle des systèmes professionnels et des consoles de jeux, à une différence près : elles se passaient des processeurs pour la géométrie. Les calculs géométriques étaient réalisés par le CPU, ce qui fait que leurs performances étaient opposées à celles de la Rendition Vérité V1000 : de bonnes performances pour le placage de textures et la rastérization, mais pas pour les calculs géométriques.

[[File:Architecture de base d'une carte 3D - 3.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

Un exemple extrêmement intéressant à étudier est celui de la Voodoo, par 3dfx. 3dfx était une entreprise très populaire à l'époque et c'était clairement l'entreprise dominante sur le marché des cartes accélératrices 3D. La Voodoo 1 et 2 étaient de très bons produits pour leur époque, et le déclin de 3dfx a commencé avec la Voodoo 3 et l'arrivée de la compétition de NVIDIA, ATI et consorts.

La Voodoo originale était une carte 3D au sens pur, à savoir qu'elle n'intégrait pas d'accélération 2D, ni même de VDC ! Elle n'était même pas capable d'envoyer l'image qu'elle avait calculée à l'écran. Elle devait être connectée à une autre carte d'affichage, qui recevait l'image 3D calculée par la Voodoo, et l'affichait à l'écran. La connexion entre les deux se faisait avec un câble VGA spécial. Pour palier ce problème, 3dfx sortit la Voodoo Rush, qui intégrait un VDC. Cependant, l'intégration du VDC réduisait les performances 3D d'environ 10%, pour plusieurs raisons techniques. La plus simple à comprendre est que lire le ''framebuffer'' en mémoire vidéo utilisait de la bande passante mémoire.

Toujours est-il que nous allons nous concentrer sur le modèle de Voodoo originel, la Voodoo Graphics PCI. Voici à quoi ressemble cette carte accélératrice 3D :

[[File:KL Diamond Monster3D Voodoo 1.jpg|centre|vignette|upright=2|KL Diamond Monster3D Voodoo 1]]

Vous remarquerez immédiatement la présence de circuits imprimés carrés et rectangulaires. Les rectangulaires sont de la mémoire RAM, les carrés sont des ASICs. les ASICs sont au nombre de trois.
* Le premier sert à la fois le processeur de commande et l'interface avec le bus.
* Le second est le circuit FBI (''Frame Buffer Interface''), qui regroupe à la fois le rastériseur et un ROP.
* Enfin, le circuit TREX est une unité de texture.

Pour ce qui est de la mémoire, il n'y a pas de mémoire vidéo unique. À la place, il y a deux mémoires séparées : une pour les textures, une pour le ''framebuffer'' et le tampon de profondeur. Les deux font 4 mébioctets chacune. Pour être plus précis, la mémoire de texture est composée en assemblant chacun 4 RAM EDO de 1 mégaoctet chacune, idem pour le ''framebuffer''. L'intérêt de faire ainsi est que les puces de mémoire EDO de 1 mégaoctet étaient plus fréquentes que celles de 4 mégaoctets. De plus, cela ouvre la porte à une optimisation qu'on abordera dans la suite.

[[File:Voodoo 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 3dfx - architecture]]

L'unité de texture supporte des fonctionnalités avancées, appelées ''filtrage bilinéaire'' et ''mip-mapping''., que nous détaillerons dans le chapitre sur les unités de textures. Mais parlons rapidement du filtrage bilinéaire.

Lors du placage de textures, un texel ne tombe pas tout pile sur un pixel à l'écran (je rappelle que pixels et texels sont des points, pas des petits carrés). Un pixel est alors entouré de plusieurs texels, et la couleur du pixel est calculée à partir des texels alentour. Une solution simple, appelée ''filtrage au plus proche'', prend le texel le plus proche du texel, mais le résultat à l'écran est assez moche, avec des scintillements lorsque la caméra bouge. Le '''filtrage bilinéaire''' prend les quatre texels les plus proches et en fait une moyenne pondérée. Il donne un résultat bien plus joli à l'écran, sans causer de scintillement ni d'aliasing.

La Voodoo intègre une optimisation pour le filtrage bilinéaire. Le filtrage bilinéaire demande de lire quatre texels. Sans optimisation, ils sont lus un par un depuis la mémoire de texture. Avec l'optimisation, ils sont tous lus en même temps. Pour ce faire, la Voodoo profite du fait que sa mémoire de texture est composée de 4 RAM EDO. La Voodoo répartit les texels dans les quatre mémoires, de manière à ce lors d'un filtrage bilinéaire, les quatre texels nécessaires soient chacun dans une mémoire séparée des autres.

La répartition des texels est illustrée ci-dessous. Le tableau correspond à une texture, chaque case est un texel. Chaque couleur correspond à une mémoire différente, elle indique dans quelle mémoire est mémorisé le texel. Vous voyez qu'en prenant des blocs carrés de 4 pixels, les quatre texels de ce bloc sont tous dans des mémoires différentes.

{|class=&quot;wikitable&quot;
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel
|-
| class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel || class=&quot;f_bleu&quot; | Texel || class=&quot;f_vert&quot; | Texel
|-
| class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel || class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel ||  class=&quot;f_rouge&quot; | Texel || class=&quot;f_jaune&quot; | Texel 
|}

Le Voodoo supporte l'antialiasing et l'éclairage de Gouraud en matériel.

Le travail du processeur de commande était particulièrement simple : il reçoit des triangles et les envoie au rastériseur. Il gère aussi les échanges entre le circuit FBI et TREX. Le processeur de commande reçoit, comme son nom l'indique, des commandes provenant du processeur. Chaque commande lui dit quoi faire. Et la Voodoo Graphics ne gère que les cinq commandes ci-dessous. Il peut donc : afficher un triangle, effacer le ''framebuffer''/z-buffer, envoyer une image vers la carte d'affichage, reset le pipeline.

{|class=&quot;wikitable&quot;
|-
! triangleCMD
| Recoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées entières/fixes.
|-
! ftriangleCMD
| Reçoit un triangle et en effectue le rendu, le triangle est encodé avec des coordonnées flottantes.
|-
! nopCMD
| Vide le pipeline de la carte graphique.
|-
! fastfillCMD
| Efface le ''framebuffer'' et le tampon de profondeur. &lt;/br&gt; ''Pour être plus précis, elle efface un rectangle à l'écran, ce rectangle peut prendre tous l'écran.''
|-
! swapbufferCMD
| Envoie l'image dessinée à la carte d'affichage.
|}

Le processeur de commande intègre une mémoire FIFO pour mettre en attente les triangles qui lui sont envoyés. La FIFO fait exactement 64 écritures (des commandes surtout, mais pas que). De plus, la Voodoo peut utiliser la mémoire du ''framebuffer'' comme FIFO secondaire. Elle peut réserver de l'espace inutilisé pour cette FIFO secondaire, avec au maximum 65536 écritures en attente.

Il faut noter que la Voodoo ne travaille qu'avec des nombres entiers, pas des nombres flottants. Pour être précis, il s'agit de nombre  virgule fixe, à savoir que certains bits codent pour les chiffres à droite de la virgule, les autres à gauche de la virgule. Si la Voodoo reçoit un triangle avec des coordonnées flottantes, elles sont converties en entiers avant tout calcul. Pour donner un exemple, la coordonnée de profondeur est encodée avec un entier de 32 bits : 20 bits pour la partie entière, 12 pour la partie fractionnaire.

: Vous pouvez trouver la documentation d'époque sur les cartes Voodoo de 3dfx via ce lien : [http://bitsavers.computerhistory.org/components/3dfx/ Bitsavers, section 3dfx].

===Le ''multi-texturing'' de l'époque Direct X 6.0 : combiner plusieurs textures===

Une technologie très importante standardisée par Dirext X 6 est la technique dite du ''multi-texturing''. Avec ce qu'on a dit dans le chapitre précédent, vous pensez sans doute qu'il n'y a qu'une seule texture par objet, qui est plaquée sur sa surface. Mais divers effets graphiques demandent d'ajouter des textures par dessus d'autres textures. En général, elles servent pour ajouter des détails ou du relief, sur une surface pré-existante.

Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de '''''decals''''', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc. Les textures en question sont de petite taille et se superposent à une texture existante, plus grande. Rendre des ''decals'' demande de pouvoir superposer deux textures.

Direct X 6.0 a justement introduit le '''''multi-texturing''''', à savoir l'application de plusieurs textures sur une même surface, directement dans le matériel. La carte graphique devait être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. Pour cela, elle doublait les unités de texture. De plus, la mémoire vidéo devait être capable de gérer plusieurs accès mémoire en même temps et devait alors avoir un débit binaire élevé.

[[File:Multitexturing.png|centre|vignette|upright=2|Multitexturing]]

La carte graphique devait aussi gérer de quoi combiner deux textures entre elles. Par exemple, pour revenir sur l'exemple d'une texture d'impact de balle, il faut que la texture d'impact recouvre totalement la texture du mur. Dans ce cas, la combinaison est simple : la première texture remplace l'ancienne, là où elle est appliquée. Mais les cartes graphiques ont ajouté d'autres combinaisons possibles, par exemple additionner les deux textures entre elle, faire une moyenne des texels, etc.

Les opérations pour combiner les textures était le fait de circuits appelés des '''''combiners'''''. Concrètement, les ''combiners'' sont de simples unités de calcul. Les ''conbiners'' ont beaucoup évolués dans le temps, mais les premières implémentation se limitaient à quelques opérations simples : addition, multiplication, superposition, interpolation. L'opération effectuer était envoyée au ''conbiner'' sur une entrée dédiée.

[[File:Multitexturing avec combiners.png|centre|vignette|upright=2|Multitexturing avec combiners]]

S'il y avait eu un seul ''conbiner'', le circuit de ''multitexturing'' aurait été simplement configurable. Mais dans la réalité, les premières cartes utilisant du ''multi-texturing'' utilisaient plusieurs ''combiners'' placés les uns à la suite des autres. L'implémentation des ''combiners'' retenue par Open Gl, et par le hardware des cartes graphiques, était la suivante. Les ''combiners'' étaient placés en série, l'un à la suite de l'autre, chacun combinant le résultat de l'étage précédent avec une texture. Le premier ''combiner'' gérait l'éclairage par sommet, afin de conserver un minimum de rétrocompatibilité.

[[File:Texture combiners Open GL.png|centre|vignette|upright=2|Texture combiners Open GL]]

Voici les opérations supportées par les ''combiners'' d'Open GL. Ils prennent en entrée le résultat de l'étage précédent et le combinent avec une texture lue depuis l'unité de texture.

{|class=&quot;wikitable&quot;
|+ Opérations supportées par les ''combiners'' d'Open GL
|-
! Replace
| colspan=&quot;2&quot; | Pixel provenant de l'unité de texture
|-
! Addition
| colspan=&quot;2&quot; | Additionne l'entrée au texel lu.
|-
! Modulate
| colspan=&quot;2&quot; | Multiplie l'entrée avec le texel lu
|-
! Mélange (''blending'')
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence || La couleur de transparence du texel lu et de l'entrée sont multipliées.
|-
! Decals
| Moyenne pondérée des deux entrées, pondérée par la composante de transparence. || La transparence du résultat est celle de l'entrée.
|}

Il faut noter qu'un dernier étage de ''combiners'' s'occupait d'ajouter la couleur spéculaire et les effets de brouillards. Il était à part des autres et n'était pas configurable, c'était un étage fixe, qui était toujours présent, peu importe le nombre de textures utilisé. Il était parfois appelé le '''''combiner'' final''', terme que nous réutiliserons par la suite.

Mine de rien, cela a rendu les cartes graphiques partiellement programmables. Le fait qu'il y ait des opérations enchainées à la suite, opérations qu'on peut choisir librement, suffit à créer une sorte de mini-programme qui décide comment mélanger plusieurs textures. Mais il y avait une limitation de taille : le fait que les données soient transmises d'un étage à l'autre, sans détours possibles. Par exemple, le troisième étage ne pouvait avoir comme seule opérande le résultat du second étage, mais ne pouvait pas utiliser celui du premier étage. Il n'y avait pas de registres pour stocker ce qui sortait de la rastérisation, ni pour mémoriser temporairement les texels lus.

Un exemple de carte accélératrice gérant le ''multi-texturing'' est la carte Voodoo 2, de 3dfx. Le support du ''multi-texturing'' avait été anticipé, et la Voodoo 1 aurait pu l'implémenter assez simplement. L'unité de texture de la Voodoo 1, la TREX, intégrait déjà un ''combiner'' et de quoi l'utiliser. Elle pouvait prendre en entrée un &quot;pixel&quot;, le combiner avec un texel lu depuis la mémoire vidéo, et fournit le résultat en sortie. Pour cela, elle disposait d'un bus d'extension spécialisé, qui permettait d'enchainer plusieurs unités TREX l'une à la suite de l'autre. Toute unité TREX avait une entrée et une sortie : une entrée pour recevoir un pixel texturé par l'unité de texture précédent, une sortie pour envoyer son résultat à la suivante.

[[File:Voodoo 2 3dfx - architecture.png|centre|vignette|upright=2|Voodoo 2 3dfx - architecture]]

===Le ''Transform &amp; Lighting'' matériel de Direct X 7.0===

La première carte graphique pour PC capable de gérer la géométrie en hardware fût la Geforce 256, la toute première Geforce. Son unité de gestion de la géométrie n'est autre que la bien connue '''unité T&amp;L''' (''Transform And Lighting''). Elle implémentait des algorithmes d'éclairage de la scène 3D assez simples, comme un éclairage de Gouraud, qui étaient directement câblés dans ses circuits. Mais contrairement à la Nintendo 64 et aux bornes d'arcade, elle implémentait le tout, non pas avec un processeur classique, mais avec des circuits fixes.

Avec Direct X 7.0 et Open GL 1.0, l'éclairage était en théorie limité à de l'éclairage par sommet, l'éclairage par pixel n'était pas implémentable en hardware. Les cartes graphiques ont tenté d'implémenter l'éclairage par pixel, mais cela n'est pas allé au-delà du support de quelques techniques de ''bump-mapping'' très limitées. Par exemple, Direct X 6.0 implémentait une forme limitée de ''bump-mapping'', guère plus.

Un autre problème est qu'il a beaucoup d'algorithmes d'éclairages différents, aux résultats visuels différents, bien au-delà des algorithmes d'éclairage plat, de Gouraud et de Phong. Et les unités de T&amp;L étaient souvent en retard sur les algorithmes logiciels. Les programmeurs avaient le choix entre programmer les algorithmes d’éclairage qu'ils voulaient et les exécuter en logiciel, ou utiliser ceux de l'unité de T&amp;L. Ils choisissaient souvent la première option. Par exemple, Quake 3 Arena et Unreal Tournament n'utilisaient pas les capacités d'éclairage géométrique et préféraient utiliser leurs calculs d'éclairage logiciel fait maison.

Cependant, le hardware dépassait les capacités des API et avait déjà commencé à ajouter des capacités de programmation liées au ''multi-texturing''. Les cartes graphiques de l'époque, surtout chez NVIDIA, implémentaient un système de '''''register combiners''''', une forme améliorée de ''texture combiners'', qui permettait de faire une forme limitée d'éclairage par pixel, notamment du vrai ''bump-mampping'', voire du ''normal-mapping''. Mais ce n'était pas totalement supporté par les API 3D de l'époque.

Les ''registers combiners'' sont des ''texture combiners'' mais dans lesquels ont aurait retiré la stricte organisation en série. Il y a toujours plusieurs étages à la suite, qui peuvent exécuter chacun une opération, mais tous les étages ont maintenant accès à toutes les textures lues et à tout ce qui sort de la rastérisation, pas seulement au résultat de l'étape précédente. Pour cela, on ajoute des registres pour mémoriser ce qui sort des unités de texture, et pour ce qui sort de la rastérisation. De plus, on ajoute des registres temporaires pour mémoriser les résultats de chaque ''combiner'', de chaque étage.

Il faut cependant signaler qu'il existe un ''combiner'' final, séparé des étages qui effectuent des opérations proprement dits. Il s'agit de l'étage qui applique la couleur spéculaire et les effets de brouillards. Il ne peut être utilisé qu'à la toute fin du traitement, en tant que dernier étage, on ne peut pas mettre d'opérations après lui. Sa sortie est directement connectée aux ROPs, pas à des registres. Il faut donc faire la distinction entre les '''''combiners'' généraux''' qui effectuent une opération et mémorisent le résultat dans des registres, et le ''combiner'' final qui envoie le résultat aux ROPs.

L'implémentation des ''register combiners'' utilisait un processeur spécialisés dans les traitements sur des pixels, une sorte de proto-processeur de ''shader''. Le processeur supportait des opérations assez complexes : multiplication, produit scalaire, additions. Il s'agissait d'un processeur de type VLIW, qui sera décrit dans quelques chapitres. Mais ce processeur avait des programmes très courts. Les premières cartes NVIDIA, comme les cartes TNT pouvaient exécuter deux opérations à la suite, suivie par l'application de la couleurs spéculaire et du brouillard. En somme, elles étaient limitées à un ''shader'' à deux/trois opérations, mais c'était un début. Le nombre d'opérations consécutives est rapidement passé à 8 sur la Geforce 3.

[[File:Architecture de base d'une carte 3D - 4.png|centre|vignette|upright=1.5|Carte 3D avec gestion de la géométrie.]]

===L'arrivée des ''shaders'' avec Direct X 8.0===

Les ''register combiners'' était un premier pas vers un éclairage programmable. Paradoxalement, l'évolution suivante s'est faite non pas dans l'unité de rastérisation/texture, mais dans l'unité de traitement de la géométrie. La Geforce 3 a remplacé l'unité de T&amp;L par un processeur capable d'exécuter des programmes. Les programmes en question complétaient l'unité de T&amp;L, afin de pouvoir rajouter des techniques d'éclairage plus complexes. Le tout a permis aussi d'ajouter des animations, des effets de fourrures, des ombres par ''shadow volume'', des systèmes de particule évolués, et bien d'autres.

À partir de la Geforce 3 de Nvidia, les cartes graphiques sont devenues capables d'exécuter des programmes appelés '''''shaders'''''. Le terme ''shader'' vient de ''shading'' : ombrage en anglais. Grace aux ''shaders'', l'éclairage est devenu programmable, il n'est plus géré par des unités d'éclairage fixes mais été laissé à la créativité des programmeurs. Les programmeurs ne sont plus vraiment limités par les algorithmes d'éclairage implémentés dans les cartes graphiques, mais peuvent implémenter les algorithmes d'éclairage qu'ils veulent et peuvent le faire exécuter directement sur la carte graphique.

Les ''shaders'' sont classifiés suivant les données qu'ils manipulent : '''''pixel shader''''' pour ceux qui manipulent des pixels, '''''vertex shaders''''' pour ceux qui manipulent des sommets. Les premiers sont utilisés pour implémenter l'éclairage par pixel, les autres pour gérer tout ce qui a trait à la géométrie, pas seulement l'éclairage par sommets.

Direct X 8.0 avait un standard pour les shaders, appelé ''shaders 1.0'', qui correspondait parfaitement à ce dont était capable la Geforce 3. Il standardisait les ''vertex shaders'' de la Geforce 3, mais il a aussi renommé les ''register combiners'' comme étant des ''pixel shaders'' version 1.0. Les ''register combiners'' n'ont pas évolués depuis la Geforce 256, si ce n'est que les programmes sont passés de deux opérations successives à 8, et qu'il y avait possibilité de lire 4 textures en ''multitexturing''. À l'opposé, le processeur de ''vertex shader'' de la Geforce 3 était capable d'exécuter des programmes de 128 opérations consécutives et avait 258 registres différents !

Des ''pixels shaders'' plus évolués sont arrivés avec l'ATI Radeon 8500 et ses dérivés. Elle incorporait la technologie ''SMARTSHADER'' qui remplacait les ''registers combiners'' par un processeur de ''shader'' un peu limité. Un point est que le processeur acceptait de calculer des adresses de texture dans le ''pixel shader''. Avant, les adresses des texels à lire étaient fournis par l'unité de rastérisation et basta. L'avantage est que certains effets graphiques étaient devenus possibles : du ''bump-mapping'' avancé, des textures procédurales, de l'éclairage par pixel anisotrope, du éclairage de Phong réel, etc.

Avec la Radeon 8500, le ''pixel shader'' pouvait calculer des adresses, et lire les texels associés à ces adresses calculées. Les ''pixel shaders'' pouvaient lire 6 textures, faire 8 opérations sur les texels lus, puis lire 6 textures avec les adresses calculées à l'étape précédente, et refaire 8 opérations. Quelque chose de limité, donc, mais déjà plus pratique. Les ''pixel shaders'' de ce type ont été standardisé dans Direct X 8.1, sous le nom de ''pixel shaders 1.4''. Encore une fois, le hardware a forcé l'intégration dans une API 3D.

[[File:Architecture de la Geforce 3.png|centre|vignette|upright=1.5|Architecture de la Geforce 3]]

===Les ''shaders'' de Direct X 9.0 : de vrais ''pixel shaders''===

Avec Direct X 9.0, les ''shaders'' sont devenus de vrais programmes, sans les limitations des ''shaders'' précédents. Les ''pixels shaders'' sont passés à la version 2.0, idem pour les ''vertex shaders''. Concrètement, ils ont des fonctionnalités bien supérieures à celles des ''registers combiners''. Les ''shaders'' pouvaient exécuter une suite d'opérations arbitraire, dans le sens où elle n'était pas structurée avec tel type d'opération au début, suivie par un accès aux textures, etc. On pouvait mettre n'importe quelle opération dans n'importe quel ordre.

De plus, les ''shaders'' ne sont plus écrit en assembleur comme c'était le cas avant. Ils sont dorénavant écrits dans un langage de haut-niveau, le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Les ''shaders'' sont ensuite traduit (compilés) en instructions machines compréhensibles par la carte graphique. Au début, ces langages et la carte graphique supportaient uniquement des opérations simples. Mais au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant.

Le matériel s'est alors adapté, en incorporant un véritable processeur pour les ''pixel shaders''. Les ''pixel shaders'' sont maintenant exécutés par un processeur de ''shader'' dédié, aux fonctionnalités bien supérieures à celles des ''registers combiners''. Le processeur de ''pixel shader'' incorpore l'unité de texture en sont sein, les deux sont fusionnés. La raison à cela sera expliqué dans la suite du chapitre.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=1.5|Carte 3D avec pixels et vertex shaders non-unifiés.]]

===L'après Direct X 9.0 : GPGPU et shaders unifiés===

Avant Direct X 10, les processeurs de ''shaders'' ne géraient pas exactement les mêmes opérations pour les processeurs de ''vertex shader'' et de ''pixel shader''. Les processeurs de ''vertex shader'' et de ''pixel shader''étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders, ce qui fait qu'il n'y a plus de distinction entre processeurs de vertex shaders et de pixels shaders, chaque processeur pouvant traiter indifféremment l'un ou l'autre. 

[[File:Architecture de base d'une carte 3D - 6.png|centre|vignette|upright=1.5|Architecture de la GeForce 6800.]]

Les GPU modernes sont capables d’exécuter des programmes informatiques qui n'ont aucun lien avec le rendu 3D, comme des calculs scientifiques, tout ce qui implique des réseaux de neurones, de l'imagerie médicale, etc. De manière générale, tout calcul faisant usage d'un grand nombre de calculs sur des matrices ou des vecteurs est concerné. L'usage d'une carte graphique pour autre chose que le rendu 3D porte le nom de '''GPGPU''', ''General Processing GPU''. En soi, le GPGPU est assez logique : les processeurs de shaders, bien que conçus avec le rendu 3D en tête, n'en restent pas moins des processeurs assez puissants. Pour ce genre d'utilisations, les GPU actuel supportent des ''shaders'' sans lien avec le rendu 3D, appelés des ''compute shader''.

==Les cartes graphiques d'aujourd'hui==

Les circuits d'un GPU ont beaucoup évolué depuis l'introduction des ''shaders'', pour devenir de plus en plus programmables. Mais à côté des processeurs de ''shaders'', il reste quelques circuits non-programmables appelés des circuits fixes. La rastérisation, le placage de texture, l'élimination des pixels cachés et le mélange ''alpha'' sont gérés par des circuits fixes. 

[[File:3D-Pipeline.svg|centre|vignette|upright=3.0|Pipeline 3D : ce qui est programmable et ce qui ne l'est pas dans une carte graphique moderne.]]

Mais pourquoi ne pas tout rendre programmable ? Ou au contraire, utiliser seulement des circuits fixes ? La réponse n'est pas la même pour les ROPs, le rastériseur, et les unités de texture. Pour simplifier, la réponse rapide est qu'il s'agit d'un compromis entre flexibilité et performance qui permet d'avoir le meilleur des deux mondes. Mais ce compromis a fortement évolué dans le temps, comme on va le voir plus bas.

Rendre l'éclairage programmable permet d'implémenter facilement un grand nombre d'effets graphiques sans avoir à les implémenter en hardware. Avant les ''shaders'', les effets graphiques derniers cri n'étaient disponibles que sur les derniers modèles de carte graphique. Avec des ''vertex/pixel shaders'', ce genre de défaut est passé à la trappe. Si un nouvel algorithme de rendu graphique est inventé, il peut être utilisé dès le lendemain sur toutes les cartes graphiques modernes. De plus, implémenter beaucoup d'algorithmes d'éclairage différents avec des circuits fixes a un cout en termes de transistors, alors qu'utiliser des circuits programmable a un cout en hardware plus limité.

Tout cela est à l'exact opposé de ce qu'on a avec les autres circuits, comme les circuits pour la rastérisation ou le placage de texture. Il n'y a pas 36 façons de rastériser une scène 3D et la flexibilité n'est pas un besoin important pour cette opération, alors que les performances sont cruciales. Même chose pour le placage/filtrage de textures. En conséquences, les unités de rastérisation et de texture sont toutes implémentées en matériel. Faire ainsi permet de gagner en performance sans que cela ait le moindre impact pour le programmeur. Reste à expliquer dans le détail pourquoi.

Le cas du ROP est plus complexe et on en reparlera dans un chapitre dédié. Mais pour simplifier, c'est parce que les GPU actuels sont de type ''sort-last'', comme vu dans le chapitre précédent. Il trient les pixels suivant leur position à l'écran à la toute fin du pipeline, et ce tri ne peut pas être rendu programmable.

===Les unités de texture sont intégrées aux processeurs de shaders===

Avec l'arrivée des processeurs de shaders, les unités de texture ont été intégrées dans les processeurs de shaders eux-mêmes. C'est la seule unité fixe qui a subit ce traitement, et il est intéressant de comprendre pourquoi.

[[File:Architecture de base d'une carte 3D - 5.png|centre|vignette|upright=2|Architecture de base d'une carte 3D.]]

Pour cela, il faut faire un rappel sur ce qu'il y a dans un processeur. Un processeur contient globalement quatre circuits :
* une unité de calcul qui fait des calculs ;
* des registres pour stocker les opérandes et résultats des calculs ;
* une unité de communication avec la mémoire ;
* et un séquenceur, un circuit de contrôle qui commande les autres.

L'unité de communication avec la mémoire sert à lire ou écrire des données, à les transférer de la RAM vers les registres, ou l'inverse. Lire une donnée demande d'envoyer son adresse à la RAM, qui répond en envoyant la donnée lue. Elle est donc toute indiquée pour lire une texture : lire une texture n'est qu'un cas particulier de lecture de données. Les texels à lire sont à une adresse précise, la RAM répond à la lecture avec le texel demandé. Il est donc possible d'utiliser l'unité de communication avec la mémoire comme si c'était une unité de texture.

Cependant, les textures ne sont pas utilisées comme telles de nos jours. Le rendu 3D moderne utilise des techniques dites de filtrage de texture, qui permettent d'améliorer la qualité du rendu des textures. Sans ce filtrage de texture, les textures appliquées naïvement donnent un résultat assez pixelisé et assez moche, pour des raisons assez techniques. Le filtrage élimine ces artefacts, en utilisant une forme d'''antialiasing'' interne aux textures, le fameux filtrage de texture.

Le filtrage de texture peut être réalisé en logiciel ou en matériel. Techniquement, il est possible de le faire dans un ''shader''. Le ''shader'' calcule les adresses des texels à lire, lit les texels, et effectue ensuite le filtrage avec des opérations de calcul. Mais ce n'est pas ce qui est fait, le filtrage de texture est toujours effectué directement en matériel. La raison est que le filtrage de texture est très simple à implémenter en hardware. Le filtrage bilinéaire ou trilinéaire demande juste des circuits d'interpolation et quelques registres, ce qui est trivial. Et la seconde raison est qu'il n'y a pas 36 façons de filtrer des textures : une carte graphique peut implémenter les algorithmes principaux existants en assez peu de circuits.

Pour simplifier l'implémentation, les processeurs de ''shader'' modernes disposent d'une unité d'accès mémoire séparée de l'unité de texture. L'unité d'accès mémoire normale s'occupe des accès mémoire hors-textures, alors que l'unité mémoire s'occupe de lire les textures. L'unité de texture contient de quoi faire du filtrage de texture, mais aussi faire des calculs d'adresse spécialisées, intrinsèquement liés au format des textures, qu'on détaillera dans le chapitre sur les textures. En comparaison, les unités d'accès mémoire effectuent des calculs d'adresse plus basiques. Un dernier avantage est que l'unité de texture est reliée au cache de texture, alors que l'unité d'accès mémoire est relié au cache L1/L2.

===Le projet Larrabee d'Intel : une programmabilité maximale===

Pour finir, nous allons parler d'un ancien projet d'Intel, qui ne s'est pas matérialisé : le projet Larrabee. Il s'agissait d'un projet de GPU, qui a été annulé en 2009 avant d'être commercialisé. Le GFU avait pour particularité de limiter les circuits fixes au minimum. Il ne gardait qu'une unité de texture, les ROPs et le rastériseur étaient émulés en logiciel. L'unité de texture n'était pas intégrée aux processeurs de shader, mais en était séparée. Le GPU était composé de plusieurs centaines de processeurs, reliés entre eux avec un réseau d'interconnexion assez complexe. L'unité de texture était connectée sur ce réseau d'interconnexion, de même que le VDC et l'interface avec le bus.

[[File:Larrabee slide block diagram.svg|centre|vignette|upright=2.5|Larrabee, diagramme. Les processeurs de shaders sont en orange.]]

Un autre point important est que les processeurs utilisés étaient des processeurs x86, les mêmes que ceux utilisés comme CPU dans nos PCs. Le choix d'utiliser des CPU x86 peut sembler étrange, ceux-ci ayant des instructions qui ne servaient à rien pour le rendu 3D, mais qui consommaient une partie du budget en transistors. Mais cela se comprend quand on sait que le GPU était prévu à la fois pour le GPGPU et le rendu 3D. Utiliser des processeurs x86 était très intéressant pour le GPGPU, cela assurait une certaine forme de compatibilité, sans compter que les programmeurs PC sont familiers avec le x86.

Pour gérer le problème mentionné plus haut avec les ROPs, Larrabee simulait un GPU de type ''Tile Based Rendering'', où l'écran est divisé en ''tiles'', et la rastérisation se fait ''tile'' par ''tile''. L'émulation logicielle des ROPs était nettement plus simple avec ce genre d'émulation. Mais le logiciel qui émulait les ROPs et le rastériseur était programmé pour éviter ce genre de problèmes.

Le projet a été annulé en 2009, sans doute parce qu'il n’arrivait pas à obtenir des performances acceptables. Mais larrabee été recyclé pour donner les Xeon Phi, des cartes d'extension utilisées pour des serveurs, du calcul scientifique ou intensif, ou d'autres usages. Les circuits de rendu 3D avaient été retirées de ces cartes, qui ne faisaient que du calcul.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Avant les GPUs : les cartes accélératrices 3D
           | prevText=Avant les GPUs : les cartes accélératrices 3D
           | next=Les processeurs de shaders
           | nextText=Les processeurs de shaders
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>6fvnszaact5prrtfx2f7s0mreku50n2</sha1>
    </revision>
  </page>
  <page>
    <title>Programmation PHP avec Symfony/Doctrine</title>
    <ns>0</ns>
    <id>71848</id>
    <revision>
      <id>772340</id>
      <parentid>771751</parentid>
      <timestamp>2026-09-17T06:59:36Z</timestamp>
      <contributor>
        <username>JackPotte</username>
        <id>5426</id>
      </contributor>
      <comment>/* Commandes Doctrine */</comment>
      <origin>772340</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="35901" sha1="epsthkfares45yh0aysqqiwb78ymjus" xml:space="preserve">&lt;noinclude&gt;{{PHP}}&lt;/noinclude&gt;

== Installation ==
{{w|Doctrine (ORM)|Doctrine}} est l'ORM par défaut de Symfony. Il utilise {{w|PHP Data Objects|PDO}}. Son langage PHP traduit en SQL est appelé DQL, et utilise le principe de la [[Patrons de conception/Chaîne de responsabilité|chaîne de responsabilité]].

Installation en SF4&lt;ref&gt;https://symfony.com/doc/current/doctrine.html&lt;/ref&gt; :
&lt;pre&gt;
 composer require symfony/orm-pack
 composer require symfony/maker-bundle --dev
&lt;/pre&gt;

Renseigner l'accès au SGBD dans le .env :
&lt;pre&gt;
 DATABASE_URL=&quot;mysql://mon_login:mon_mot_de_passe@127.0.0.1:3306/ma_base&quot;
&lt;/pre&gt;

Ensuite la base de données doit être créée avec :
&lt;pre&gt;
 php bin/console doctrine:database:create
&lt;/pre&gt;Si la commande précédente échoue avec le message d'erreur suivant:

''Could not create database &quot;database_name&quot; for connection named default''

''An exception occurred in the driver: could not find driver''

Ce qui veut dire que vous devez installer le driver approprié.

'''Exemple:'''

sudo apt install  php8.3-pgsql{{remarque|1=symfony/orm-pack équivaut aux paquets suivants, qui peuvent bien sûr être installés séparément à la place :
*doctrine/doctrine-bundle
*doctrine/doctrine-migrations-bundle
*doctrine/orm
*symfony/proxy-manager-bridge
}}

== Commandes Doctrine ==
Exemples de commandes :
&lt;pre&gt;
php bin/console dbal:run-sql &quot;SELECT * FROM ma_table&quot; 
php bin/console dbal:run-sql &quot;$(&lt; mon_fichier.sql)&quot;

# Ces deux commandes sont équivalentes des précédentes mais sur Doctrine &lt; 3.
php bin/console doctrine:query:sql &quot;SELECT * FROM ma_table&quot;
php bin/console doctrine:query:sql &quot;$(&lt; mon_fichier.sql)&quot;

php bin/console doctrine:cache:clear-metadata
php bin/console doctrine:cache:clear-query 
php bin/console doctrine:cache:clear-result
&lt;/pre&gt;

== Entity ==
Une entité est une classe PHP associée à une table de la base de données. Elle est composée d'un attribut par colonne, et de leurs {{wt|getter}}s et {{wt|setter}}s respectifs. Pour en générer une :
&lt;pre&gt;
 php bin/console generate:doctrine:entity
&lt;/pre&gt;
Cette association est définie par des attributs Doctrine. Pour les vérifier :
&lt;pre&gt;
 php bin/console doctrine:schema:validate
&lt;/pre&gt;

=== Exemple ===
Voici par exemple plusieurs types d'attributs :

&lt;syntaxhighlight lang=php&gt;
#[ORM\Table(name: 'word')]
#[ORM\Entity(repositoryClass: WordRepository::class)]

class Word
{
    #[ORM\Id]
    #[ORM\GeneratedValue(strategy: 'IDENTITY')]
    #[ORM\Column(name: 'id', type: 'integer', nullable: false)]
    private ?int $id = null;

    #[ORM\ManyToOne(targetEntity: 'Language')]
    #[ORM\JoinColumn(name: 'language_id', referencedColumnName: 'id', nullable: false)]
    private ?Language $language = null;

    #[ORM\Column(name: 'spelling', type: 'string', nullable: false)]
    private ?string $spelling = null;

    #[ORM\Column(name: 'pronunciation', type: 'string', nullable: true)]
    private ?string $pronunciation = null;

    #[ORM\OneToMany(targetEntity: 'Homophon', cascade: ['persist', 'remove'])]
    private ?Collection $homophons;
&lt;/syntaxhighlight&gt;

{{(|Exemple avec annotation (avant PHP 8)}}
&lt;syntaxhighlight lang=php&gt;
/**
* @ORM\Table(name=&quot;word&quot;)
* @ORM\Entity(repositoryClass=&quot;App\Repository\WordRepository&quot;)
*/
class Word
{
    /**
    * @ORM\Id
    * @ORM\Column(name=&quot;id&quot;, type=&quot;integer&quot;, nullable=false)
    * @ORM\GeneratedValue(strategy=&quot;IDENTITY&quot;)
    */
    private $id;

    /**
    * @ORM\Column(name=&quot;spelling&quot;, type=&quot;string&quot;, length=255, nullable=false)
    */
    private $spelling;

    /**
    * @ORM\Column(name=&quot;pronunciation&quot;, type=&quot;string&quot;, length=255, nullable=true)
    */
    private $pronunciation;

    /**
     * @var Language
     *
     * @ORM\ManyToOne(targetEntity=&quot;Language&quot;, inversedBy=&quot;words&quot;)
     * @ORM\JoinColumn(name=&quot;language_id&quot;, referencedColumnName=&quot;id&quot;)
     */
    protected $language;

    /**
     * @var ArrayCollection
     *
     * @ORM\OneToMany(targetEntity=&quot;Homophon&quot;, mappedBy=&quot;word&quot;, cascade={&quot;persist&quot;, &quot;remove&quot;})
     */
    private $homophons;
&lt;/syntaxhighlight&gt;
{{)}}

Et leurs modificateurs (getters et setters) :
&lt;syntaxhighlight lang=php&gt;
    public function __construct()
    {
        $this-&gt;homophons = new ArrayCollection();
    }

    public function setSpelling($p): self
    {
        $this-&gt;spelling = $p;

        return $this;
    }

    public function getSpelling(): ?string
    {
        return $this-&gt;spelling;
    }

    public function setPronunciation($p): self
    {
        $this-&gt;pronunciation = $p;

        return $this;
    }

    public function getPronunciation(): ?string
    {
        return $this-&gt;pronunciation;
    }

    public function setLanguage($l): self
    {
        $this-&gt;language = $l;

        return $this;
    }

    public function getLanguage(): ?Language
    {
        return $this-&gt;language;
    }

    public function addHomophons($homophon): self
    {
        if (!$this-&gt;homophons-&gt;contains($homophon)) {
            $this-&gt;homophons-&gt;add($homophon);
            $homophon-&gt;setWord($this);
        }
        return $this;
    }
}
&lt;/syntaxhighlight&gt;

On voit ici que la table &quot;word&quot; possède trois champs : &quot;id&quot; (clé primaire), &quot;pronunciation&quot; (chaine de caractère) et &quot;language_id&quot; (clé étrangère vers la table &quot;language&quot;). Doctrine stockera automatiquement l'id de la table &quot;language&quot; dans la troisième colonne quand on associera une entité &quot;Language&quot; à une &quot;Word&quot; avec &lt;code&gt;$word-&gt;setLanguage($language)&lt;/code&gt;.

Le quatrième attribut permet juste de récupérer les enregistrements de la table &quot;homophon&quot; ayant une clé étrangère pointant vers &quot;word&quot;.

Par ailleurs, en relation &quot;OneToMany&quot;, c'est toujours l'entité ciblée par le &quot;Many&quot; qui définit la relation car elle contient la clé étrangère. Elle contient donc l'attribut &quot;inversedBy=&quot;, alors que celle ciblée par &quot;One&quot; contient &quot;mappedBy=&quot;. Elle contient aussi un deuxième attribut &lt;code&gt;#[ORM\JoinColumn&lt;/code&gt; (anciennement &lt;code&gt;@ORM\JoinColumn&lt;/code&gt;) mentionnant la clé étrangère en base de données (et pas en PHP).

=== Bonnes pratiques ===
L'attribut &lt;code&gt;#[ORM\Table(name: 'word')]&lt;/code&gt; était facultatif dans cet exemple, car le nom de la table peut être déduit du nom de l'entité.

Avant PHP 8, les contraintes d'unicité (utiles entre autres pour les clés composites) étaient encapsulées dans l'annotation &lt;code&gt;Table&lt;/code&gt;, mais ce n'est plus le cas avec les attributs :
&lt;pre&gt;
#[ORM\UniqueConstraint(name: 'spelling-pronunciation', columns: ['spelling', 'pronunciation'])]
&lt;/pre&gt;

{{(|Exemple avec annotation (avant PHP 8)}}
&lt;pre&gt;
 * @ORM\Table(uniqueConstraints={
 *  @ORM\UniqueConstraint(name=&quot;spelling-pronunciation&quot;, columns={&quot;spelling&quot;, &quot;pronunciation&quot;})
 * })
&lt;/pre&gt;
{{)}}

{{attention|Dans les relations *toMany :
* il faut initialiser l'attribut dans le constructeur en &lt;code&gt;ArrayCollection()&lt;/code&gt;.
* on peut avoir une méthode -&gt;set(ArrayCollection) mais le plus souvent on utilise -&gt;add(un seul élément)
* cette méthode add() doit idéalement contenir le set() de l'entité cible vers la courante (pour ne pas avoir à l'ajouter après chaque appel).
}}

{{attention|Il faut ajouter le &lt;code&gt;#[ORM\JoinColumn(&lt;/code&gt; dans les deux entités liées, car :
* dans aucune cela renvoie &lt;code&gt;Could not resolve type of column &quot;id&quot;&lt;/code&gt;
* dans une seule cela provoque un problème N+1 (celle qui ne l'a pas appelle celle qui l'a pour chacun de ses enregistrements, même si celle qui l'a n'est pas utilisée ensuite).
}}


NB : par défaut la longueur des types &quot;string&quot; est 255, on peut l'écraser ou la retirer avec &lt;code&gt;length=0&lt;/code&gt;&lt;ref&gt;https://www.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#string&lt;/ref&gt;. Le type &quot;text&quot; par contre n'a pas de limite.

=== ArrayCollection ===
Cet objet itérable peut être converti en tableau avec -&gt;toArray().

Pour le trier :
* Dans une entité : &lt;code&gt;#[ORM\OrderBy(['sort_order' =&gt; 'ASC'])]&lt;/code&gt; (anciennement &lt;code&gt;@ORM\OrderBy({&quot;sort_order&quot; = &quot;ASC&quot;})&lt;/code&gt;).
* Sinon, instancier un critère :
&lt;pre&gt;
        $sort = new Criteria(null, ['slug' =&gt; Criteria::ASC]);
        $services = $maCollection-&gt;matching($sort);
&lt;/pre&gt;

=== GeneratedValue ===
L'annotation ''GeneratedValue'' peut valoir &quot;AUTO&quot;, &quot;SEQUENCE&quot;, &quot;TABLE&quot;, &quot;IDENTITY&quot;, &quot;NONE&quot;, &quot;UUID&quot;, &quot;CUSTOM&quot;.

{{attention|
Dans le cas du CUSTOM, un setId() réaliser avant le persist() sera écrasé par la génération d'un nouvel ID&lt;ref&gt;https://stackoverflow.com/questions/31594338/overriding-default-identifier-generation-strategy-has-no-effect-on-associations&lt;/ref&gt;. Ce nouvel ID peut être écrasé à son tour, mais si l'entité possède des liens vers d'autres, c'est l'ID custom qui est utilisé comme clé (on a alors une erreur '' Integrity constraint violation'' puisque la clé générée n'est pas retenue). Pour éviter cela (par exemple dans des tests automatiques), il faut désactiver la génération à la volée :
&lt;syntaxhighlight lang=php&gt;
        $metadata = $this-&gt;em-&gt;getClassMetadata(get_class($entity));
        $metadata-&gt;setIdGeneratorType(ClassMetadata::GENERATOR_TYPE_NONE);
        $metadata-&gt;setIdGenerator(new AssignedGenerator());
        $entity-&gt;setId(static::TEST_ID);
&lt;/syntaxhighlight&gt;
}}

=== Triggers ===
Les opérations en cascade sont définies sous deux formes d'attributs :
* &lt;code&gt;#[ORM\OneToMany(cascade: ['persist', 'remove'])]&lt;/code&gt; : au niveau ORM.
* &lt;code&gt;#[ORM\JoinColumn(onDelete: 'CASCADE')]&lt;/code&gt; : au niveau base de données.

Ainsi, quand on supprime l'entité contenant un cascade remove, cela supprime aussi ses entités liées par cette relation.

=== Concepts avancés ===
Pour utiliser une entité depuis une autre, alors qu'elles n'ont pas de liaison SQL, il existe l'interface ObjectManagerAware&lt;ref&gt;https://www.doctrine-project.org/api/persistence/1.0/Doctrine/Common/Persistence/ObjectManagerAware.html&lt;/ref&gt;.

{{attention|Les types des attributs peuvent être quelque peu différents du SGBD&lt;ref&gt;https://www.doctrine-project.org/projects/doctrine-dbal/en/2.8/reference/types.html#mapping-matrix&lt;/ref&gt;.}}

{{attention|Dans le cas de jointure vers une entité d'un autre espace de nom (par exemple une table d'une autre base), il faut indiquer son namespace complet dans l'annotation Doctrine (car elle ne tient pas compte des &quot;use&quot;).}}

L'autojointure est appelé ''self-referencing association mapping'' par Doctrine&lt;ref&gt;https://www.doctrine-project.org/projects/doctrine-orm/en/2.8/reference/association-mapping.html#many-to-many-self-referencing&lt;/ref&gt;).

=== Héritage ===
Une entité peut hériter d'une classe si celle-ci contient l'annotation suivante&lt;ref&gt;https://www.doctrine-project.org/projects/doctrine-orm/en/2.8/reference/inheritance-mapping.html&lt;/ref&gt; :
&lt;syntaxhighlight lang=php&gt;
/** @MappedSuperclass */
class MyEntityParent
...
&lt;/syntaxhighlight&gt;

=== Tables sans classe ===
Doctrine peut créer des tables de mapping sans entité, si on précise son nom dans les deux tables reliées :
&lt;pre&gt;
    #[ORM\JoinTable(name: 'table_de_mapping')]
    #[ORM\JoinColumn(name: 'table_source_id', referencedColumnName: 'table_source_id')]
    #[ORM\InverseJoinColumn(name: 'table_cible_id', referencedColumnName: 'table_cible_id')]
    #[ORM\ManyToMany(targetEntity: TableCible::class)]
&lt;/pre&gt;

== EntityManager ==
L'EntityManager (em) est l'objet qui synchronise les entités avec la base de données. Une application doit en avoir un par base de données, définis dans doctrine.yaml.

Il possède trois méthodes pour cela :
* persist() : prépare un INSERT SQL (rattache une entité à un entity manager).
* remove() : prépare un DELETE SQL.
* flush() : exécute le code SQL préparé.

Il existe aussi les méthodes suivantes :
* merge() : fusionne une entité absent de l'em dedans.
* refresh() : rafraichit l'entité PHP à partir de la base de données. C'est utile par exemple pour tenir compte des résultats d'un trigger ''after insert'' sur le SGBD. Exemple si le trigger ajoute une date de création après le persist, à écraser par &lt;code&gt;$createdDate&lt;/code&gt; :
&lt;syntaxhighlight lang=php&gt;
        $entity = new MyEntity();
        $em-&gt;persist($entity);
        $em-&gt;flush($entity);
        // Trigger SGBD déclenché ici en parallèle
        $em-&gt;refresh($entity);
        $entity-&gt;setCreatedDate($createdDate);
        $em-&gt;flush($entity);
&lt;/syntaxhighlight&gt;

== Repository ==
On appelle &quot;repository&quot; les classes PHP qui contiennent les requêtes pour la base de données. Elles héritent de &lt;code&gt;Doctrine\ORM\EntityRepository&lt;/code&gt;. Chacune permet de récupérer une entité associée en base de données. Les repo doivent donc être nommés ''NomDeLEntitéRepository''.

{{remarque|D'un point de vue architectural, avant d'instancier une nouvelle entité, on utilise généralement le repository pour savoir si son enregistrement existe en base ou si on doit le créer. Dans ce deuxième cas, la bonne pratique en {{wt|DDD}} est d'utiliser une Factory pour faire le new de l'entité, mais aussi pour les new de son agrégat si elle est le nœud racine. Par exemple une &lt;code&gt;CarFactory&lt;/code&gt; fera un &lt;code&gt;new Car()&lt;/code&gt; mais aussi créera et lui associera ses composants : &lt;code&gt;new Motor()&lt;/code&gt;...}}

{{remarque|Il est possible de préciser le nom du repository d'une entité dans cette dernière :
&lt;pre&gt;
#[ORM\Entity(repositoryClass: \App\Repository\WordRepository::class)]
&lt;/pre&gt;

{{(|Exemple avec annotation (avant PHP 8)}}
&lt;pre&gt;
@ORM\Entity(repositoryClass=&quot;App\Repository\WordRepository&quot;)
&lt;/pre&gt;
{{)}}

}}

=== SQL ===
==== Depuis Doctrine ====
Utile pour exploiter les fonctionnalités du SGBD utilisé, absentes de Doctrine.

Par exemple, pour appeler une procédure stockée :
&lt;pre&gt;
$rsm = new ResultSetMapping();
$this-&gt;_em-&gt;createNativeQuery('call my_stored_procedure', $rsm)-&gt;getResult();
&lt;/pre&gt;

Ou tronquer une table :
&lt;pre&gt;
$rsm = new ResultSetMapping();
$this-&gt;_em-&gt;createNativeQuery('TRUNCATE TABLE ma_table', $rsm)-&gt;getResult();
&lt;/pre&gt;

{{remarque|Dans cet exemple, on peut aussi utiliser ceci :
&lt;pre&gt;
        $connection = $this-&gt;_em-&gt;getConnection();
        $databasePlatform = $connection-&gt;getDatabasePlatform();

        $connection-&gt;executeStatement(
            $databasePlatform-&gt;getTruncateTableSQL($this-&gt;_em-&gt;getClassMetadata(MonEntite::class)-&gt;getTableName(), true),
        );
&lt;/pre&gt;
}}

==== Sans Doctrine ====
Pour exécuter du SQL natif dans Symfony sans Doctrine, il faut créer un service de connexion, par exemple qui appelle PDO en utilisant les identifiants du .env, puis l'injecter dans les repos (dans chaque constructeur ou par une classe mère commune) : 
&lt;pre&gt;
return $this-&gt;connection-&gt;fetchAll($sql);
&lt;/pre&gt;

Depuis un repository Doctrine, tout ceci est déjà fait et les deux techniques sont disponibles :

1. Par l'attribut ''entity manager'' (''em'', ou ''_em'' pour les anciennes versions) hérité de la classe mère (le &quot;use&quot; permettra ici d'appeler des constantes pour paramétrer le résultat) :
&lt;syntaxhighlight lang=php&gt;
use Doctrine\DBAL\Connection;
...
$statement = $this-&gt;_em-&gt;getConnection()-&gt;executeQuery($sql);
$statement-&gt;fetchAll(\PDO::FETCH_KEY_PAIR);
$statement-&gt;closeCursor();
$this-&gt;_em-&gt;getConnection()-&gt;close();

return $statement;
&lt;/syntaxhighlight&gt;

2. En injectant le service de connexion dans le constructeur (&lt;code&gt;'@database_connection'&lt;/code&gt;) :
&lt;pre&gt;
use Doctrine\DBAL\Connection;
...
return $this-&gt;dbalConnection-&gt;fetchAll($sql);
&lt;/pre&gt;

=== DQL ===
==== Méthodes magiques ====
Doctrine peut ensuite générer des requêtes SQL à partir du nom d'une méthode PHP appelée mais non écrite dans les repository (car ils en héritent). Ex :
* &lt;code&gt;$repo-&gt;find($id)&lt;/code&gt; : cherche par la clé primaire définie dans l'entité.
* &lt;code&gt;$repo-&gt;findAll()&lt;/code&gt; : récupère tous les enregistrements (sans clause &lt;code&gt;WHERE&lt;/code&gt;).
* &lt;code&gt;$repo-&gt;findById($id)&lt;/code&gt; : engendre automatiquement un &lt;code&gt;SELECT * WHERE id = $id&lt;/code&gt; dans la table associée au repo.
* &lt;code&gt;$repo-&gt;findBy(['lastname' =&gt; $lastname, 'firstname' =&gt; $firstname])&lt;/code&gt; engendre automatiquement un &lt;code&gt;SELECT * WHERE lastname = $lastname AND firstname = $firstname&lt;/code&gt;.
* &lt;code&gt;$repo-&gt;findOneById($id)&lt;/code&gt; : engendre automatiquement un &lt;code&gt;SELECT * WHERE id = $id LIMIT 1&lt;/code&gt;.
* &lt;code&gt;$repo-&gt;findOneBy(['lastname' =&gt; $lastname, 'firstname' =&gt; $firstname])&lt;/code&gt; : engendre automatiquement un &lt;code&gt;SELECT * WHERE lastname = $lastname AND firstname = $firstname LIMIT 1&lt;/code&gt;.

{{attention|Lors des tests unitaires PHPUnit, il est probable qu'une erreur survienne sur l'inexistence de méthode &quot;&lt;code&gt;findById&lt;/code&gt;&quot; pour le mock du repository (du fait qu'elle est magique). Il vaut donc mieux utiliser &lt;code&gt;findBy()&lt;/code&gt;.
}}

Par ailleurs, on peut compléter les requêtes avec des paramètres supplémentaires. Ex :
&lt;syntaxhighlight lang=php&gt;
$repo-&gt;findBy(
    ['lastname' =&gt; $lastname], // where
    ['lastname' =&gt; 'ASC'],     // order by
    10,                        // limit
    0,                         // offset
);
&lt;/syntaxhighlight&gt;

==== createQuery ====
DQL possède une syntaxe proche du SQL, si ce n'est qu'il faut convertir les entités jointes en ID avec &lt;code&gt;IDENTITY()&lt;/code&gt; pour les jointures. Ex :
&lt;pre&gt;
    public function findComplicatedStuff()
    {
        $em = $this-&gt;getEntityManager();
        $query = $em-&gt;createQuery(&quot;
            SELECT
                u.last_name, u.first_name
            FROM
                App\Entity\Users u
                INNER JOIN App\Entity\Invoices i WITH u.id = IDENTITY(i.users)
            WHERE 
                i.status='waiting'
        &quot;);

        return $query-&gt;getResult();
    }
&lt;/pre&gt;

==== createQueryBuilder ====
L'autre syntaxe du DQL est en POO. Les méthodes des repos font appel &lt;code&gt;createQueryBuilder()&lt;/code&gt; :

&lt;syntaxhighlight lang=php&gt;
public function findAllWithCalculus()
{
    return $this-&gt;createQueryBuilder('mon_entité')
        -&gt;where('id &lt; 3')
        -&gt;getQuery()
        -&gt;getResult()
    ;
}
&lt;/syntaxhighlight&gt;

Pour éviter le &lt;code&gt;SELECT *&lt;/code&gt; dans cet exemple, on peut y ajouter la méthode &lt;code&gt;-&gt;select()&lt;/code&gt;.

Pour afficher la requête SQL générée par le DQL, remplacer &quot;-&gt;getResult()&quot; par &quot;-&gt;getQuery()&quot;.

===== Jointures =====
Quand deux entités ne sont pas reliées entre elles, on peut tout de même lancer une jointure en DQL :
&lt;pre&gt;
use Doctrine\ORM\Query\Expr\Join;
...
    -&gt;join('AcmeCategoryBundle:Category', 'c', Expr\Join::WITH, 'v.id = c.id')
&lt;/pre&gt;

Pour filtrer quand une jointure toMany contient des résultats, utiliser &lt;code&gt;EMPTY&lt;/code&gt; :
&lt;pre&gt;
...
    -&gt;andWhere('files IS NOT EMPTY')
&lt;/pre&gt;

===== Résultats =====
Doctrine peut renvoyer avec :
* &lt;code&gt;getResult()&lt;/code&gt; : un objet ArrayCollection (iterable, pour rechercher dedans : &lt;code&gt;-&gt;contains()&lt;/code&gt;), d'objets (du type de l'entité) avec leurs méthodes get (pas set) ;
* &lt;code&gt;getArrayResult()&lt;/code&gt; ou &lt;code&gt;getScalarResult()&lt;/code&gt; : un tableau de tableaux (entité normalisée) ;
* &lt;code&gt;getSingleColumnResult()&lt;/code&gt; : un tableau unidimensionnel.

On peut aussi utiliser &lt;code&gt;-&gt;indexBy('id')&lt;/code&gt; pour définir que les clés du tableau de résultat soir les IDs de l'entité.

===== Cache =====

====== Configuration globale ======
Doctrine propose trois caches pour ses requêtes : celui de métadonnées, de requête et de résultats. Il faut d'abord définir les pools dans cache.yaml :
&lt;syntaxhighlight lang=yaml&gt;
framework:
    cache:
        default_redis_provider: '%env(REDIS_URL)%'
        pools:
            doctrine.metadata_cache_pool:
                adapter: cache.system
            doctrine.query_cache_pool:
                adapter: cache.system
            doctrine.result_cache_pool:
                adapter: cache.app
&lt;/syntaxhighlight&gt;

Puis dans doctrine.yaml, les utiliser :
&lt;syntaxhighlight lang=yaml&gt;
doctrine:
    orm:
        metadata_cache_driver:
            type: pool
            pool: doctrine.metadata_cache_pool
        query_cache_driver:
            type: pool
            pool: doctrine.query_cache_pool
        result_cache_driver:
            type: pool
            pool: doctrine.result_cache_pool
&lt;/syntaxhighlight&gt;

À partir de là le cache des métadonnées est utilisé partout.

====== Configuration par entité ======
Par contre pour ceux de requêtes et de résultats, il faut les définir pour chaque entité, soit :

* Dans l'entité, avec un attribut &lt;code&gt;#[ORM\Cache(usage: 'READ_ONLY', region: 'write_rare')]&lt;/code&gt; (anciennement &lt;code&gt;@ORM\Cache(usage=&quot;READ_ONLY&quot;, region=&quot;write_rare&quot;)&lt;/code&gt;&lt;ref&gt;https://medium.com/@dotcom.software/using-doctrines-l2-cache-in-symfony-eba300ab1e6&lt;/ref&gt;), utilisant la configuration doctrine.yaml :
&lt;pre&gt;
doctrine:
    orm:
        second_level_cache:
            enabled: true
            regions:
                write_rare:
                    lifetime: 864000
                    cache_driver: { type: service, id: cache.app }
&lt;/pre&gt;

* Dans le repository :
&lt;syntaxhighlight lang=php&gt;
$query
    -&gt;useQueryCache($hasQueryCache)
    -&gt;setQueryCacheLifetime($lifetime)
    -&gt;enableResultCache($lifetime)
;
&lt;/syntaxhighlight&gt;

Dans cet exemple, on n'utilise pas &lt;code&gt;cache.system&lt;/code&gt; pour le cache de résultats pour ne pas saturer le serveur qui héberge le code. &lt;code&gt;cache.app&lt;/code&gt; pointe donc vers une autre machine, par exemple Redis, ce qui nécessite un appel réseau supplémentaire, et n'améliore donc pas forcément les performances selon la requête.

Pour invalider le cache d'une entité afin que les findAll() renvoient la liste à jour depuis la base de données modifiée sur Doctrine 3 :

Une seule instance de cette entité :
&lt;pre&gt;
$em-&gt;getCache()-&gt;evictEntity(myEntity::class, $entityId);
&lt;/pre&gt;
Toutes les instances de l'entité :
&lt;pre&gt;
$em-&gt;getCache()-&gt;getRegion(myEntity::class)-&gt;clear();
&lt;/pre&gt;
{{(|Doctrine 2}}
&lt;pre&gt;
$em-&gt;getCache()-&gt;evictEntityRegion(myEntity::class);
&lt;/pre&gt;
{{)}}

==== Expressions ====
Pour ajouter une expression en DQL, utilise &lt;code&gt;$qb-&gt;expr()&lt;/code&gt;. Ex&lt;ref&gt;https://www.doctrine-project.org/projects/doctrine-orm/en/2.12/reference/query-builder.html#the-expr-class&lt;/ref&gt; :
* &lt;code&gt;$qb-&gt;expr()-&gt;count('u.id')&lt;/code&gt;
* &lt;code&gt;$qb-&gt;expr()-&gt;between('u.id', 2, 10)&lt;/code&gt; (entre 2 et 10)
* &lt;code&gt;$qb-&gt;expr()-&gt;gte('u.id', 2)&lt;/code&gt; (plus grand ou égal à 2)
* &lt;code&gt;$qb-&gt;expr()-&gt;like('u.name', '%son')&lt;/code&gt;
* &lt;code&gt;$qb-&gt;expr()-&gt;lower('u.name')&lt;/code&gt;
* &lt;code&gt;$qb-&gt;expr()-&gt;substring('u.name', 0, 1)&lt;/code&gt;

==== Injection de dépendances ====
Les repository DQL deoivent ''ServiceEntityRepository'' :

&lt;syntaxhighlight lang=php&gt;
namespace App\Repository;

use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;

class WordRepository extends ServiceEntityRepository
{
    public function __construct(ManagerRegistry $registry)
    {
        parent::__construct($registry, Word::class);
    }
}
&lt;/syntaxhighlight&gt;

Mais parfois on souhaite injecter un service dans un repository. Pour ce faire il y a plusieurs solutions :
* Étendre une classe qui étend ''ServiceEntityRepository''.
* Le redéfinir dans services.yaml.
* Utiliser un trait.

== Transactions ==
Pour garantir d'intégrité d'une transaction&lt;ref&gt;https://www.doctrine-project.org/projects/doctrine-orm/en/2.7/reference/transactions-and-concurrency.html#approach-2-explicitly&lt;/ref&gt; :
&lt;syntaxhighlight lang=php&gt;
            $connection = $this-&gt;entityManager-&gt;getConnection();
            $connection-&gt;beginTransaction();
            try {
                $this-&gt;persist($myEntity);
                $this-&gt;flush();
                $connection-&gt;commit();
            } catch (Exception $e) {
                $connection-&gt;rollBack();
                throw $e;
            }
&lt;/syntaxhighlight&gt;

Il existe aussi une syntaxe alternative :
&lt;syntaxhighlight lang=php&gt;
            $em-&gt;transactional(function($em, $myEntity) {
                $em-&gt;persist($myEntity);
            });
&lt;/syntaxhighlight&gt;


== Évènements ==

Pour ajouter des triggers sur la mise à jour d'une table, il y a deux solutions :
* ajouter dans son entité l'attribut &lt;code&gt;#[ORM\HasLifecycleCallbacks]&lt;/code&gt;, et à ses méthodes l'attribut de l'évènement concerné. Ex :
&lt;pre&gt;
    #[ORM\PrePersist]
    public function setCreatedAt(): self
    {
        $this-&gt;createdAt = new DateTime();
        return $this;
    }
&lt;/pre&gt;
* ajouter des tags dans services.yaml. Ex :
&lt;pre&gt;
    App\EventListener\MyEntityListener:
        tags:
            - { name: doctrine.event_listener, event: PrePersist }
&lt;/pre&gt;

Voici les [[Programmation PHP avec Symfony/Évènement|évènements]] utilisables ensuite (dans les listeners / subscribers) :

=== prePersist ===
Se produit avant la persistance d'une entité (paramètre : &lt;code&gt;PrePersistEventArgs $args&lt;/code&gt;).

=== postPersist ===
Se produit après la persistance d'une entité (&lt;code&gt;PostPersistEventArgs $args&lt;/code&gt;).

=== preUpdate ===
Se produit avant l'update d'une entité (&lt;code&gt;PreUpdateEventArgs $args&lt;/code&gt;).

=== postUpdate ===
Se produit après l'update d'une entité (&lt;code&gt;PostUpdateEventArgs $args&lt;/code&gt;).

=== preRemove ===
Se produit avant l'update d'une entité (&lt;code&gt;PreRemoveEventArgs $args&lt;/code&gt;).

=== postRemove ===
Se produit après l'update d'une entité (&lt;code&gt;PostRemoveEventArgs $args&lt;/code&gt;).

=== preFlush ===
Se produit avant la sauvegarde d'une entité (&lt;code&gt;PreFlushEventArgs $args&lt;/code&gt;).

{{attention|
* Dans cet évènement, les attributs en lazy loading de l'entité flushée s'ils sont appelés, sont issus de la base de données et donc correspondent aux données écrasées (et pas aux nouvelles flushées).
* Si on flush l'entité qui déclenche cet évènement il faut penser à un dispositif anti-boucle infinie (ex : variable d'instance).
* Dans le cas d'un new sur une entité, le persist ne suffit pas pour préparer sa sauvegarde. Il faut alors appeler &lt;code&gt;$unitOfWork-&gt;computeChangeSet($classMetadata, $entity)&lt;/code&gt;&lt;ref&gt;https://stackoverflow.com/questions/37831828/symfony-onflush-doctrine-listener&lt;/ref&gt;.
}}

{{remarque|On peut aussi appeler computeChangeSet() depuis ailleurs pour savoir si une entité va occasionner une requête SQL lors de son flush&lt;ref&gt;https://stackoverflow.com/questions/10800178/how-to-check-if-entity-changed-in-doctrine-2&lt;/ref&gt;.}} Ex :
&lt;pre&gt;
$uow = $em-&gt;getUnitOfWork();
$uow-&gt;computeChangeSets();
if ($uow-&gt;isEntityScheduled($myEntity)) {
    //...
}
&lt;/pre&gt;

{{remarque|On peut aussi utiliser le paramètre &lt;code&gt;LifecycleEventArgs $args&lt;/code&gt; dans ces fonctions.}}

{{attention|Parfois le &lt;code&gt;$object::class&lt;/code&gt; peut renvoyer &lt;code&gt;Proxies\__CG__\App\Entity\MyEntity&lt;/code&gt; au lieu de &lt;code&gt;App\Entity\MyEntity&lt;/code&gt;, selon le cache utilisé.}}

=== postFlush ===
Se produit après la sauvegarde d'une entité (&lt;code&gt;PostFlushEventArgs $args&lt;/code&gt;).

== Migrations ==
Pour modifier la base de données avec une commande, par exemple pour ajouter une colonne à une table ou modifier une procédure stockée, il existe une bibliothèque qui s'installe comme suit :
&lt;syntaxhighlight lang=bash&gt;
composer require doctrine/doctrine-migrations-bundle
&lt;/syntaxhighlight&gt;

=== Création ===
Ensuite, on peut créer un squelette de &quot;migration&quot; :
&lt;syntaxhighlight lang=bash&gt;
php bin/console doctrine:migrations:generate
&lt;/syntaxhighlight&gt;

Cette classe comporte une méthode &quot;up()&quot; qui réalise la modification en SQL ou DQL, et une &quot;down()&quot; censée faire l'inverse à des fins de rollback. De plus, on ne peut pas lancer deux fois de suite le &quot;up()&quot; sans un &quot;down()&quot; entre les deux (une table nommée &lt;code&gt;migration_versions&lt;/code&gt; enregistre leur succession).

==== Exemple SQL ====
&lt;syntaxhighlight lang=php&gt;
final class Version20210719125146 extends AbstractMigration
{
    public function up(Schema $schema) : void
    {
        $this-&gt;connection-&gt;fetchAll('SHOW DATABASES;');

        $this-&gt;addSql(&lt;&lt;&lt;SQL
          CREATE TABLE ma_table(ma_colonne VARCHAR(255) NOT NULL);
SQL);
    }

    public function down(Schema $schema) : void
    {
        $this-&gt;addSql('DROP TABLE ma_table');
    }
}
&lt;/syntaxhighlight&gt;

==== Exemple DQL ====
&lt;syntaxhighlight lang=php&gt;
final class Version20210719125146 extends AbstractMigration
{
    public function up(Schema $schema) : void
    {
        $table = $schema-&gt;createTable('ma_table');
        $table-&gt;addColumn('ma_colonne', 'string');
    }

    public function down(Schema $schema) : void
    {
        $schema-&gt;dropTable('ma_table');
    }
}
&lt;/syntaxhighlight&gt;

==== Exemple PHP ====
Depuis Symfony 7.0, il faut implémenter &lt;code&gt;MigrationFactory&lt;/code&gt; pour injecter des dépendances dans les migrations (et on ne peut plus injecter tout le conteneur)&lt;ref&gt;https://symfony.com/bundles/DoctrineMigrationsBundle/current/index.html#migration-dependencies&lt;/ref&gt;.

{{Boîte déroulante début|titre=Avant Symfony 7.0, il fallait juste utiliser &lt;code&gt;ContainerAwareTrait&lt;/code&gt;}}
Exemple :
&lt;syntaxhighlight lang=php&gt;
final class Version20210719125146 extends AbstractMigration implements ContainerAwareInterface
{
    use ContainerAwareTrait;

    public function up(Schema $schema) : void
    {
        $em = $this-&gt;container-&gt;get('doctrine.orm.entity_manager');
        $monEntite = new MonEntite();
        $em-&gt;persist($monEntite);
        $em-&gt;flush();
    }
}
&lt;/syntaxhighlight&gt;
{{Boîte déroulante fin}}

{{attention|Cette technique est déconseillée car les entités peuvent évoluer indépendamment de la migration. Mais elle peut s'avérer utile pour stocker des données dépendantes de l'environnement.}}

{{attention|&lt;code&gt;$this-&gt;container-&gt;getParameter()&lt;/code&gt; ne fonctionne pas sur la valeur du paramètre quand elle doit être remplacée par une variable d'environnement. Par exemple &lt;code&gt;$_SERVER['SUBAPI_URI']&lt;/code&gt; renvoie la variable d'environnement et &lt;code&gt;$this-&gt;containergetParameter('env(SUBAPI_URI)')&lt;/code&gt; sa valeur par défaut (définie dans services.yaml).}}

=== Exécution ===
La commande suivante exécute toutes les migrations qui n'ont pas encore été lancées dans une base :
&lt;syntaxhighlight lang=bash&gt;
php bin/console doctrine:migrations:migrate
&lt;/syntaxhighlight&gt;

Sinon, on peut les exécuter une par une selon le paramètre, avec la partie variable du nom du fichier de la classe (timestamp) :
&lt;syntaxhighlight lang=bash&gt;
php bin/console doctrine:migrations:execute --up 20170321095644
# ou si &quot;migrations_paths&quot; dans doctrine_migrations.yaml contient le namespace :
php bin/console doctrine:migrations:execute --up &quot;App\Migrations\Version20170321095644&quot;
# ou encore :
php bin/console doctrine:migrations:execute --up App\\Migrations\\Version20170321095644
&lt;/syntaxhighlight&gt;

Pour le rollback :
&lt;syntaxhighlight lang=bash&gt;
php bin/console doctrine:migrations:execute --down 20170321095644
&lt;/syntaxhighlight&gt;

Pour éviter que Doctrine pose des questions durant les migrations, ajouter &lt;code&gt;--no-interaction&lt;/code&gt; (ou &lt;code&gt;-n&lt;/code&gt;).

Pour voir le code SQL au lieu de l'exécuter : &lt;code&gt;--write-sql&lt;/code&gt;.

==== Sur plusieurs bases de données ====
Pour exécuter sur plusieurs bases :
&lt;syntaxhighlight lang=bash&gt;
 php bin/console doctrine:migrations:migrate --em=em1 --configuration=src/DoctrineMigrations/Base1/migrations.yaml
 php bin/console doctrine:migrations:migrate --em=em2 --configuration=src/DoctrineMigrations/Base2/migrations.yaml
&lt;/syntaxhighlight&gt;

Avec des migrations.yaml de type :
&lt;syntaxhighlight lang=bash&gt;
name: 'Doctrine Migrations base 1'
migrations_namespace: 'App\DoctrineMigrations\Base1'
migrations_directory: 'src/DoctrineMigrations/Base1'
table_name: 'migration_versions'
# custom_template: 'src/DoctrineMigrations/migration.tpl'
&lt;/syntaxhighlight&gt;

=== Synchronisation ===
==== Vers le code ====
===== Vers les entités =====
&lt;pre&gt;
 php bin/console doctrine:mapping:import App\\Entity annotation --path=src/Entity
&lt;/pre&gt;

{{attention|Ce script ne fonctionne pas avec les attributs PHP8. Donc pour créer une nouvelle entité à partir d'une table, utiliser un filtre et passer [[Programmation_PHP_avec_Symfony/Migration_de_Symfony_6_à_7#Rector|Rector]] pour convertir les annotations. Ex :
&lt;pre&gt;
 php bin/console doctrine:mapping:import App\\Entity annotation --path=src/Entity --filter=myNewTable
 vendor/bin/rector process src/Entity/MyNewEntity.php
&lt;/pre&gt;
}}

===== Vers les migrations =====
Pour créer la migration permettant de parvenir à la base de données actuelle :

 php bin/console doctrine:migrations:diff

==== Vers la base ====
À contrario, pour mettre à jour la BDD à partir des entités :

 php bin/console doctrine:schema:update --force


Pour le prévoir dans une migration :

 php bin/console doctrine:schema:update --dump-sql

== Fixtures ==
Il existe plusieurs bibliothèques pour créer des {{wt|fixture}}s, dont une de Doctrine&lt;ref&gt;https://symfony.com/doc/current/bundles/DoctrineFixturesBundle/index.html&lt;/ref&gt; :
&lt;syntaxhighlight lang=bash&gt;
composer require --dev orm-fixtures
&lt;/syntaxhighlight&gt;

Pour charger les fixtures du code dans la base :
&lt;syntaxhighlight lang=bash&gt;
php bin/console doctrine:fixtures:load -n
&lt;/syntaxhighlight&gt;

== Types de champ ==
La liste des types de champ Doctrine se trouve dans &lt;code&gt;Doctrine\DBAL\Types&lt;/code&gt;. Toutefois, il est possible d'en créer des nouveaux pour définir des comportements particuliers quand on lit ou écrit en base.

Par exemple on peut étendre &lt;code&gt;JsonType&lt;/code&gt; pour surcharger le type JSON par défaut afin de lui faire faire &lt;code&gt;json_encode($value, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)&lt;/code&gt; automatiquement.

Ou encore, pour y stocker du code de configuration désérialisé dans une colonne&lt;ref&gt;https://speakerdeck.com/lyrixx/doctrine-objet-type-et-colonne-json?slide=23&lt;/ref&gt;.

== Réplication SQL ==
Anciennement appelée MasterSlaveConnection, la réplication entre une base de données accessible en écriture et ses réplicas accessibles en lecture par l'application, est prise en charge par Doctrine qui effectuera automatiquement les SELECT vers les réplicas pour soulager la base principale. Il suffit juste d'indiquer les adresses des réplicas dans doctrine.yml.
Ex&lt;ref&gt;https://medium.com/@dominykasmurauskas1/how-to-add-read-write-replicas-on-symfony-6-using-doctrine-bundle-a46447449f35&lt;/ref&gt; :
&lt;pre&gt;
doctrine:
    dbal:
        url: '%env(resolve:DATABASE_URL)%'
        replicas:
            replica1:
                url: '%env(resolve:REPLICA_DATABASE_URL)%'
&lt;/pre&gt;

== Critique ==
# Il faut revenir en SQL si les performances sont limites (ex : un million de lignes avec jointures) ou si on veut tronquer une table.
# Si les valeurs d'une table jointe n'apparaissent pas tout le temps, vérifier que le {{wt|lazy loading}} est contourné par au choix :
## Avant l'appel null, un &lt;code&gt;ObjetJoint-&gt;get()&lt;/code&gt;.
## Dans l'entité, un &lt;code&gt;@ManyToOne(…, fetch=&quot;EAGER&quot;)&lt;/code&gt;.
## Dans le repository, un &lt;code&gt;$this-&gt;queryBuilder-&gt;addSelect()&lt;/code&gt;. NB : si cela ajoute un problème N+1, joindre aussi la deuxième entité qui le provoque.
# Pas de HAVING MAX car il n'est pas connu lors de la construction dans la chaine de responsabilité
# Pas de FULL OUTER JOIN ou RIGHT JOIN (que &quot;leftJoin&quot; et &quot;innerJoin&quot;)
# Attention aux &lt;code&gt;$this-&gt;queryBuilder-&gt;setMaxResults()&lt;/code&gt; et &lt;code&gt;$this-&gt;queryBuilder-&gt;setFirstResult()&lt;/code&gt; en cas de jointure, car elles ne conservent que le nombre d'enregistrements de la première table (à l'instar du &lt;code&gt;LIMIT&lt;/code&gt; SQL). La solution consiste à ajouter un paginateur&lt;ref&gt;https://stackoverflow.com/questions/50199102/setmaxresults-does-not-works-fine-when-doctrine-query-has-join/50203939&lt;/ref&gt;.
# L'annotation @ORM/JOIN TABLE crée une table vide et ne permet pas d'y placer des fixtures lors de sa construction.
# Pas de hints.
# Bug des &lt;code&gt;UNION ALL&lt;/code&gt; quand on joint deux entités non liées dans le repo.

{{todo|
* Ajouter la connexion à chaque SGBD Doctrine : MSSQL + GUI Linux, MariaDB, Webdis, MySQL (patrons à copier-coller ?)
}}

== Références ==
{{Références}}</text>
      <sha1>epsthkfares45yh0aysqqiwb78ymjus</sha1>
    </revision>
  </page>
  <page>
    <title>Programmation PHP avec Symfony/Composant</title>
    <ns>0</ns>
    <id>73411</id>
    <revision>
      <id>772337</id>
      <parentid>767811</parentid>
      <timestamp>2026-09-17T06:57:21Z</timestamp>
      <contributor>
        <username>JackPotte</username>
        <id>5426</id>
      </contributor>
      <comment>/* process */</comment>
      <origin>772337</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22145" sha1="srir86wt9zewym4ptm0ed7ccch5082w" xml:space="preserve">&lt;noinclude&gt;{{Symfony}}&lt;/noinclude&gt;

== Description ==
Le framework Symfony permet nativement les fonctionnalités minimum dans un souci de performances, à l'instar d'un micro-framework.
Par exemple son compilateur permet d'utiliser plusieurs patrons de conception (design patterns) via des mots réservés dans services.yaml :
* arguments : [[Patrons de conception/Injection de dépendance|Injection de dépendance]]
* decorator : [[Patrons de conception/Décorateur|Décorateur]].
* shared : [[Patrons de conception/Singleton|Singleton]].
* factory : [[Patrons de conception/Fabrique|Fabrique]]&lt;ref&gt;https://symfony.com/doc/current/service_container/factories.html&lt;/ref&gt;.


Toutefois, on peut lui ajouter des composants&lt;ref&gt;https://symfony.com/components&lt;/ref&gt;, dont il convient de connaitre les fonctionnalités pour ne pas réinventer la roue. Pour les installer :
&lt;pre&gt;
composer require symfony/nom_du_composant
&lt;/pre&gt;

Les quatre premiers ci-dessous sont inclus par défaut dans le microframework &lt;code&gt;symfony/skeleton&lt;/code&gt;.

== framework-bundle ==
Structure la configuration principale du framework sans laquelle aucun composant n'est installable&lt;ref&gt;https://symfony.com/doc/current/reference/configuration/framework.html&lt;/ref&gt;.

== console ==
[[Patrons de conception/Commande|Patrons de conception &quot;Commande&quot;]].

Fournit la possibilité d'exécuter le framework avec des commandes shell&lt;ref&gt;https://symfony.com/doc/current/components/console.html&lt;/ref&gt;. Par exemple pour obtenir la liste de toutes les commandes disponibles dans un projet :
&lt;pre&gt;
php bin/console help list
&lt;/pre&gt;

== dotenv ==
Gère les variables d'environnement non versionnées, contenues dans un fichier .env&lt;ref&gt;https://symfony.com/doc/current/components/dotenv.html&lt;/ref&gt;. Elles peuvent aussi bénéficier de {{wt|type checking}} en préfixant les types avec &quot;:&quot;. Ex de .env :

&lt;pre&gt;
IS_DEV_SERVER=1
&lt;/pre&gt;

Le ''services.yaml, parameters:'' récupère ensuite cette valeur et vérifie qu'il s'agit d'un booléen (via le processeur de variable d'environnement &quot;bool&quot;) :
&lt;pre&gt;
is_dev_server: '%env(bool:IS_DEV_SERVER)%'
&lt;/pre&gt;

Il existe plusieurs processeurs de variable d'environnement (en plus de &quot;bool&quot; et des autres types)&lt;ref&gt;https://symfony.com/doc/current/configuration/env_var_processors.html&lt;/ref&gt; :
* &lt;code&gt;base64:&lt;/code&gt; encode en base64.
* &lt;code&gt;default:&lt;/code&gt; remplace le deuxième paramètre par le premier si absent. Ex :
** &lt;code&gt;$addTestValues: '%env(bool:default::ADD_TEST_VALUES)%'&lt;/code&gt; injecte &quot;null&quot; si ADD_TEST_VALUES n'est pas défini.
** &lt;code&gt;$addTestValues: '%env(bool:default:ADD_TEST_VALUES2:ADD_TEST_VALUES1)%'&lt;/code&gt; injecte le contenu de ADD_TEST_VALUES2 si ADD_TEST_VALUES1 n'est pas défini.
* &lt;code&gt;file:&lt;/code&gt; remplace le chemin d'un fichier par son contenu.
* &lt;code&gt;not:&lt;/code&gt; renvoie l'inverse.
* &lt;code&gt;require:&lt;/code&gt; fait un require() PHP.
* &lt;code&gt;resolve:&lt;/code&gt; remplace le nom d'une variable par sa valeur.
* &lt;code&gt;trim:&lt;/code&gt; fait un trim() PHP.

Pour définir une valeur par défaut en cas de variable d'environnement manquante (sans utiliser &lt;code&gt;default:&lt;/code&gt;), dans ''services.yaml, parameters:'' :
&lt;pre&gt;
    env(MY_MISSING_CONSTANT): '0'
&lt;/pre&gt;

== yaml ==
Ajoute la conversion de fichier {{w|YAML}} en tableau PHP&lt;ref&gt;https://symfony.com/doc/current/components/yaml.html&lt;/ref&gt;. Ce format de données constitue une alternative plus lisible au XML pour renseigner la configuration des services. Par défaut le framework se configure avec config.yaml.

== routing ==
[[Patrons de conception/Façade|patron de conception &quot;Façade&quot;]].

Installe les annotations permettant de router des URLs vers les classes des contrôleurs MVC.

{{article détaillé|Programmation PHP avec Symfony/Contrôleur#Routing}}

== serializer ==
Permet de convertir des objets en tableaux ou dans les principaux formats de notation : JSON, XML, YAML et CSV&lt;ref&gt;https://symfony.com/doc/current/components/serializer.html&lt;/ref&gt;.
&lt;pre&gt;
    composer require symfony/serializer
&lt;/pre&gt;

Ce composant est notamment utilisé pour créer des APIs.

== form ==
Construit des formulaires HTML.

{{article détaillé|Programmation PHP avec Symfony/Formulaire}}

== validator ==
Fournit des règles de validation pour les données telles que les adresses emails ou les codes postaux. Utile à coupler avec les formulaires pour contrôler les saisies.

Ces règles peuvent porter sur les propriétés ou les getters.

Il permet aussi de créer des groupes de validateurs, et de les ordonner par séquences. Par défaut chaque classe a automatiquement deux groupes de validateurs : &quot;default&quot; et celui de son nom. Si une séquence est définie, le groupe &quot;default&quot; n'est plus égal au groupe de la classe (celui par défaut) mais à la séquence par défaut&lt;ref&gt;https://symfony.com/doc/current/validation/sequence_provider.html&lt;/ref&gt;.

=== Exemples ===
* Dans une entité :
&lt;pre&gt;
use Symfony\Component\Validator\Constraints as Assert;
...
    #[Assert\Email]
    private ?string $email = null;
&lt;/pre&gt;
* Dans un formulaire (inutile à faire si c'est déjà dans l'entité) :
&lt;pre&gt;
use Symfony\Component\Validator\Constraints\Email;
...
            $builder-&gt;add('email', EmailType::class, [
                'required' =&gt; false,
                'constraints' =&gt; [new Email()],
            ])
&lt;/pre&gt;

== translation ==
Les traductions sont stockées dans un fichier différent par domaine et par langue (code {{w|ISO 639}}). Les formats acceptés sont YAML, XML, PHP&lt;ref&gt;https://symfony.com/doc/current/translation.html&lt;/ref&gt;.

On peut ensuite récupérer ces dictionnaires en Twig (via le filtre &quot;trans&quot;), ou en PHP (via le service &quot;translator&quot;).

Par exemple, le domaine par défaut étant &quot;messages&quot;, le français se trouve donc dans &lt;code&gt;translations/messages.fr.yml&lt;/code&gt; ou &lt;code&gt;translations/messages.fr-FR.yml&lt;/code&gt;.

=== Installation ===
&lt;pre&gt;
 composer require symfony/translation
&lt;/pre&gt;

Pour avoir les traductions inutilisées en anglais :
&lt;pre&gt;
 bin/console debug:translation en --only-unused
&lt;/pre&gt;

Pour les traductions manquantes en anglais :
&lt;pre&gt;
 bin/console debug:translation en --only-missing
&lt;/pre&gt;

On peut restreindre à un seul domaine avec une option : &lt;code&gt;--domain=mon_domaine&lt;/code&gt;

=== Traduction en PHP ===
Le domaine et la langue sont facultatifs (car ils ont des valeurs par défaut) :
&lt;pre&gt;
 $translator-&gt;trans('Hello World', domain: 'login', locale: 'fr_FR');
&lt;/pre&gt;

{{remarque|le composant Symfony Form appelle automatiquement Translations pour ses &quot;labels&quot;.}}

=== Traduction en Twig ===
Les traductions en Twig sont appelées par le [[Programmation PHP avec Symfony/Twig#Filtre_trans|filtre &quot;trans&quot;]] :
&lt;pre&gt;
 {% trans_default_domain 'login' %}
 {{ 'Hello World' |trans }}
&lt;/pre&gt;
Ou :
&lt;pre&gt;
 {{ 'Hello World' |trans({}, 'login', 'fr-FR') }}
&lt;/pre&gt;

=== Variables ===
* YAML : la variable est entre accolades (selon la norme de l'{{w|International Components for Unicode|ICU}}&lt;ref&gt;https://symfony.com/doc/current/reference/formats/message_format.html&lt;/ref&gt;)
&lt;pre&gt;
 Hello World: 'Hello World name!'
&lt;/pre&gt;

* Twig :
&lt;pre&gt;
 {{ Hello World |trans({&quot;name&quot;: userName}) }}
&lt;/pre&gt;

* PHP
&lt;pre&gt;
 $translator-&gt;trans('Hello World', ['name' =&gt; $userName]);
&lt;/pre&gt;

Dans un formulaire Symfony :
&lt;pre&gt;
        $builder
            -&gt;add('hello', TextType::class,([
                'label' =&gt; 'Hello World',
                'label_translation_parameters' =&gt; [
                    'name' =&gt; $userName,
                ]
            ]))
        ;
&lt;/pre&gt;

Par défaut le domaine de traduction est &quot;message&quot; mais on peut désactiver ces dernières avec : &lt;code&gt;choice_translation_domain =&gt; false&lt;/code&gt;.

== event-dispatcher ==
[[Patrons de conception/Observateur|Patrons de conception &quot;Observateur&quot;]]&lt;ref&gt;http://www.jpsymfony.com/design_patterns/le-design-pattern-observer-avec-symfony2&lt;/ref&gt; et [[Patrons de conception/Médiateur|&quot;Médiateur&quot;]]&lt;ref&gt;https://github.com/certificationy/symfony-pack/blob/babd3fee68a7e793767f67c6df140630f52e7f8d/data/architecture.yml#L13&lt;/ref&gt;.

Assure la possibilité d'écouter des évènements pour qu'ils déclenchent des actions.

{{article détaillé|Programmation PHP avec Symfony/Évènement}}

== process ==
Permet de lancer des sous-processus en parallèle&lt;ref&gt;https://symfony.com/doc/current/components/process.html&lt;/ref&gt;. Exemple qui lance une commande shell :
&lt;pre&gt;
    $process = new Process(['ls']);
    $process-&gt;run();
&lt;/pre&gt;

{{attention|En l'absence de &lt;code&gt;$process-&gt;stop()&lt;/code&gt; ou de timeout, le sous-processus peut être stoppé en redémarrant le serveur PHP.|clear=left}}

Exemple de requête SQL asynchrone&lt;ref&gt;https://gist.github.com/appaydin/42eaf953172fc7ea6a8b193694645324&lt;/ref&gt; :
&lt;pre&gt;
    $sql = 'SELECT * FROM ma_table LIMIT 1';
    $process = Process::fromShellCommandline(sprintf('../bin/console dbal:run-sql &quot;%s&quot;', $sql));
    $process-&gt;setTimeout(3600);
    $process-&gt;start();
&lt;/pre&gt;

{{remarque|Avant &lt;code&gt;dbal:run-sql&lt;/code&gt; c'était &lt;code&gt;doctrine:query:sql&lt;/code&gt;.}}

== cache ==
Gère les connexions, lectures et écritures vers des serveurs de mémoire caches tels que {{w|Redis}} ou {{w|Memcached}}.

Il fournit une classe ''cacheItem'' conforme à la PSR, instanciable par plusieurs adaptateurs.

Le cache ne sert qu'à accélérer l'application donc une panne sur celui-ci ne doit pas la bloquer. C'est pourquoi il vaut mieux avoir un ou plusieurs caches de secours, même moins rapides, pour prendre le relais dans une chaine de caches.

Pour mettre cela en place sur Symfony, définir le chaine et ses composants dans cache.yaml.

{{article détaillé|Programmation PHP/Redis#Dans Symfony}}

== asset ==
Ajoute la fonction Twig &lt;code&gt;asset()&lt;/code&gt; pour accéder aux fichiers CSS, JS ou images selon leurs versions&lt;ref&gt;https://symfony.com/doc/current/components/asset.html&lt;/ref&gt;.

== webpack-encore ==
Intégration de {{w|Webpack|lang=en}} pour gérer la partie {{wt|front end}} (ex : minifications des CSS et JS).

=== Installation&lt;ref&gt;https://symfonycasts.com/screencast/stimulus/encore&lt;/ref&gt; ===
&lt;pre&gt;
 composer require symfony/webpack-encore-bundle
 yarn install
 yarn build
&lt;/pre&gt;

NB : si {{w|Yarn}} n'est pas installé, le faire avec {{w|npm}} : &lt;code&gt;apt install nodejs npm; npm install --global yarn&lt;/code&gt;.

Cela crée les fichiers package.json et yarn.lock contenant les dépendances JavaScript, le dossier assets/ contenant les JS et CSS versionnés, et le fichier webpack.config.js dans lequel ils sont appelés.

De plus, des fonctions Twig permettent d'y accéder depuis les templates : &lt;code&gt;encore_entry_link_tags()&lt;/code&gt; et &lt;code&gt;encore_entry_script_tags()&lt;/code&gt;.

Par ailleurs, cela installe le framework JS Stimulus, et interprète les {{wt|attributs de données}} pour appeler ses contrôleurs ou méthodes.

=== Rebuild ===
Pour que le code se build en cours de frappe, deux solutions&lt;ref&gt;https://symfony.com/doc/current/frontend/encore/simple-example.html&lt;/ref&gt; :
* Avec Yarn :
** yarn watch
** yarn dev-server
* Avec npm :
** npm watch
** npm run dev-server

La différence entre les deux est que le dev-server peut mettre à jour la page sans même la rafraichir.

== messenger ==
[[Patrons de conception/Chaîne de responsabilité|Patrons de conception &quot;Chaîne de responsabilité&quot;]].

Messenger permet d'utiliser des queues au protocole {{w|AMQP}}. En résumé, il gère l'envoi de messages dans des bus, ces messages transitent par d'éventuels ''middlewares'' puis arrivent à destination dans des ''handlers''&lt;ref&gt;https://vria.eu/delve_into_the_heart_of_the_symfony_messenger/&lt;/ref&gt;. On peut aussi persister ces messages en les envoyant dans des ''transports'' via un {{wt|DSN}}, par exemple dans RabbitMQ, Redis ou Doctrine (donc une table des SGBD les plus populaires).
&lt;pre&gt;
    php bin/console debug:messenger
&lt;/pre&gt;

Chaque middleware doit passer le relais au suivant ainsi :
&lt;pre&gt;
    return $stack-&gt;next()-&gt;handle($envelope, $stack);
&lt;/pre&gt;

Pour stopper le message dans un middleware sans qu'il arrive aux handlers :
&lt;pre&gt;
    return $envelope;
&lt;/pre&gt;

Chaque message peut être défini comme à traiter en synchrone ou asynchrone.

=== En asynchrone ===
Une même commande peur traiter les plusieurs groupes de messages asynchrones, par exemple ceux qui doivent se relancer en cas d'erreur et ceux à ne surtout pas relancer car ils pourraient générer des doublons. Ex :
&lt;pre&gt;
 bin/console messenger:consume async async_no_retry
&lt;/pre&gt;

{{attention|Pour le faire tourner en dev avec les mêmes données dans le webprofiler que les autres commandes Symfony (requêtes Doctrine et HTTP Client), il faut ajouter l'option &quot;no-reset&quot; après &quot;profile&quot; :
&lt;pre&gt;
 bin/console messenger:consume async async_no_retry --profile --no-reset -vvv
&lt;/pre&gt;
}}

{{attention|Pour le faire tourner en prod sans qu'il n'interrompe ses traitements en cours à chaque MEP, il existe plusieurs solutions :
* Processus Linux ''supervisord'' : ne convient pas aux conteneurs car ils interrompent leurs traitements à chaque relance.
* Sidecar container [[Docker/Kubernetes|Kubernetes]] : idem.
* Conteneur dédié qui se redéploie gracieusement après chaque MEP. Par exemple dans Kubernetes, l'option &lt;code&gt;ttlSecondsAfterFinished: 3600&lt;/code&gt; garantit que le conteneur attend la fin du traitement en cours jusqu'à 1h maximum avant de se redéployer.
}}

== workflow ==
[[Patrons de conception/Commande|Patrons de conception &quot;État&quot;]].

Ce composant nécessite de créer (en YAML, XML ou PHP) la configuration d'un {{w|automate fini}}&lt;ref&gt;https://symfony.com/doc/current/workflow.html&lt;/ref&gt;, c'est-à-dire la liste de ses transitions et états (appelés &quot;places&quot;).

Ces graphes sont ensuite visualisables en image ainsi :
&lt;pre&gt;
    use Symfony\Component\Workflow\Definition;
    use Symfony\Component\Workflow\Dumper\StateMachineGraphvizDumper;

    class WorkflowDisplayer
    ...
    $definition = new Definition($places, $transitions);
    echo (new StateMachineGraphvizDumper())-&gt;dump($definition);
&lt;/pre&gt;

&lt;pre&gt;
    sudo apt install graphviz
    php WorkflowDisplayer.php | dot -Tpng -o workflow.png
&lt;/pre&gt;

== browser-kit ==
Simule un navigateur pour les tests d'intégration.

== config ==
Permet de manipuler des fichiers de configurations.

== contracts ==
Pour la {{w|programmation par contrat}}.

== css-selector ==
Pour utiliser {{w|XPath}}.

== debug ==
Fournit des méthodes statiques pour déboguer le PHP.

== dependency-injection ==
Normalise l'utilisation du ''container'' de services.

Permet aussi d'exécuter du code pendant la compilation via un ''compiler pass'', en implémentant l'interface ''CompilerPassInterface'' avec sa méthode ''process''&lt;ref&gt;https://symfony.com/doc/current/components/dependency_injection/compilation.html&lt;/ref&gt;.

== dom-crawler ==
Fournit des méthodes pour parcourir le {{w|DOM}}.

== expression-language ==
[[Patrons de conception/Interpréteur|Patrons de conception &quot;Interpréteur&quot;]].

''Expression language ''sert à évaluer des expressions, ce qui peut permettre de définir des règles métier&lt;ref&gt;https://symfony.com/doc/current/components/expression_language.html&lt;/ref&gt;.

Installation :
composer require symfony/expression-language

Exemple :
&lt;pre&gt;
    $el = new ExpressionLanguage();
    $operation = '1 + 2';
    echo(
    sprintf(
    &quot;L'opération %s vaut %s&quot;,
    $el-&gt;compile($operation));
    $el-&gt;evaluate($operation));
    )
    );
    // Affiche : L'opération 1 + 2 vaut 3
&lt;/pre&gt;

== filesystem ==
Méthodes de lecture et écriture dans les dossiers et fichiers.

== finder ==
Recherche dans les dossiers et fichiers.

== security ==
Ensemble de sous-composants assurant la sécurité d'un site. Ex : authentification, anti-{{w|CSRF}} ou droit des utilisateurs d'accéder à une page.

=== Installation ===
&lt;pre&gt;
composer require symfony/security-bundle
&lt;/pre&gt;

=== Utilisation ===
Dans security.yaml, on peut par exemple définir les classes qui vont assurer l'authentification (''guard''), ou celle ''User'' qui sera instanciée après.

Pour obtenir l'utilisateur ou son token, on peut injecter :
&lt;pre&gt;
 TokenStorageInterface $tokenStorage
&lt;/pre&gt;

pour avoir l'utilisateur courant avec &lt;code&gt;$this-&gt;tokenStorage-&gt;getToken()?-&gt;getUser()&lt;/code&gt;.

== guard ==
Extension de sécurité pour des authentifications complexes.

== http-client ==
Pour lancer des requêtes HTTP depuis l'application.

{{article détaillé|Programmation PHP avec Symfony/HttpClient}}

== http-foundation ==
Fournit des classes pour manipuler les requêtes HTTP, comme ''Request'' et ''Response'' que l'on retrouve dans les contrôleurs.

Par exemple :
&lt;pre&gt;
    use Symfony\Component\HttpFoundation\Response;
    //...
    echo Response::HTTP_OK; // 200
    echo Response::HTTP_NOT_FOUND; // 404
&lt;/pre&gt;

== http-kernel ==
Permet d'utiliser des évènements lors des transformations des requêtes HTTP en réponses.

== inflector ==
Deprecated depuis Symfony 5.

Accorde les mots anglais au pluriel à partir de leurs singuliers.

== intl ==
Internationalisation, comme par exemple la classe &quot;Locale&quot; pour gérer une langue.

== ldap ==
Connexion aux serveur {{w|LDAP}}.

== lock ==
Pour verrouiller les accès aux ressources&lt;ref&gt;https://symfony.com/doc/current/components/lock.html&lt;/ref&gt;.

Par exemple, pour ne pas qu'une commande soit lancée deux fois simultanément, bien que le composant console aie aussi cette fonctionnalité :
&lt;pre&gt;
 use Symfony\Component\Console\Command\LockableTrait;
 ...
    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        if ($this-&gt;lock() === false) {
            return Command::SUCCESS;
        }

        ...

        $this-&gt;release();
        return Command::SUCCESS;
    }
&lt;/pre&gt;

== Maker bundle ==
Pour créer ou recréer des classes à partir de déductions&lt;ref&gt;https://symfony.com/bundles/SymfonyMakerBundle/current/index.html&lt;/ref&gt;.
&lt;pre&gt;
 composer require --dev symfony/maker-bundle
&lt;/pre&gt;

NB : ce composant ne permet pas de générer des entités à partir d'une base de données.

== mailer ==
Pour envoyer des emails.

== mime ==
Manipulation des messages {{w|MIME}}.

== notifier ==
Pour envoyer des notifications telles que des emails, des SMS, des messages instantanés, etc.

== options-resolver ==
Gère les remplacements de propriétés par d'autres, avec certaines par défaut.

== phpunit-bridge ==
[[Patrons de conception/Pont|Patron de conception &quot;Pont&quot;]] qui apporte plusieurs fonctionnalités liées aux tests unitaires, telles que la liste des tests désuets ou des mocks de fonctions PHP natif.

== property-access ==
Pour lire les attributs de classe à partir de leurs getters, ou des tableaux.

== property-info ==
Pour lire les métadonnées des attributs de classe.

== stopwatch ==
Chronomètre pour mesurer des temps d'exécution.

== string ==
API convertissant certains objets en chaine de caractères. Ex :
&lt;pre&gt;
    use Symfony\Component\String\Slugger\AsciiSlugger;

    $slugger = new AsciiSlugger();
    echo $slugger-&gt;slug('caractères spéciaux € $');
&lt;/pre&gt;
Résultat :
caracteres-speciaux-EUR

== templating ==
Extension de construction de templates.

{{article détaillé|Programmation PHP avec Symfony/Templating}}

== var-dumper ==
Ajoute une fonction globale &lt;code&gt;dump()&lt;/code&gt; pour déboguer des objets en les affichant avec une coloration syntaxique et des menus déroulant.

Ajoute aussi &lt;code&gt;dd()&lt;/code&gt; pour ''dump() and die()''.

== var-exporter ==
Permet d'instancier une classe sans utiliser son constructeur.

== polyfill* ==
On trouve aussi une vingtaine de composants {{wt|polyfill}}, fournissant des fonctions PHP retirées dans les versions les plus récentes.

== Composants désuets ==
=== locale (&lt;= v2.3) ===
Arrêté en 2011, car remplacé par le composant ''intl''&lt;ref&gt;https://symfony.com/components/Locale&lt;/ref&gt;.

=== icu (&lt;= v2.6) ===
Arrêté en 2014, car remplacé par le composant ''intl''&lt;ref&gt;https://symfony.com/components/Icu&lt;/ref&gt;.

=== class-loader (&lt;= v3.3) ===
Arrêté en 2011, car remplacé par composer.json&lt;ref&gt;https://symfony.com/components/ClassLoader&lt;/ref&gt;.

== Ajoutés en 2020 ==
=== Uid ''(sic)'' (&gt;= v5.1) ===
Pour générer des {{w|UUID}}&lt;ref&gt;https://symfony.com/doc/current/components/uid.html&lt;/ref&gt;.

=== RateLimiter (&gt;= v5.2) ===
[[Patrons de conception/Proxy|Patron de conception &quot;Proxy&quot;]], qui permet de limiter la consommation de ressources du serveur par les clients&lt;ref&gt;https://symfony.com/doc/current/rate_limiter.html&lt;/ref&gt;

Installation :
&lt;pre&gt;
composer require symfony/rate-limiter
&lt;/pre&gt;

Pour l'activer, ajouter la ligne suivante dans les pare-feux de security.yaml concernés :
&lt;pre&gt;
 login_throttling: true
&lt;/pre&gt;

=== Semaphore (&gt;= v5.2) ===
Pour donner l'exclusivité d'accès à une ressource&lt;ref&gt;https://symfony.com/doc/current/components/semaphore.html&lt;/ref&gt;.

== Ajoutés en 2021 ==
=== PasswordHasher (&gt;= v5.3) ===
Pour gérer les chiffrements&lt;ref&gt;https://symfony.com/blog/new-in-symfony-5-3-passwordhasher-component&lt;/ref&gt;.

=== Runtime (&gt;= v5.3) ===
Pour le démarrage (bootstrap) : permettre de découpler l'application de son code de retour.
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-5-3-runtime-component&lt;/ref&gt;.

== Ajoutés en 2022 ==
=== HtmlSanitizer (&gt;= v6.1) ===

=== Clock (&gt;= v6.2) ===

=== Symfony UX (&gt;= v5.4) ===
==== ux-autocomplete ====

==== ux-chartjs ====
Utilise Chart.js via Stimulus pour afficher des graphiques, via la fonction Twig &lt;code&gt;render_chart()&lt;/code&gt;&lt;ref&gt;https://symfony.com/bundles/ux-chartjs/current/index.html&lt;/ref&gt;.

==== ux-react ====
Ajoute le framework {{w|React.js}}.

{{article détaillé|Programmation PHP avec Symfony/Stimulus}}

==== ux-vue ====
Ajoute le framework {{w|Vue.js}}.

== Ajoutés en 2023 ==
=== Webhook et RemoteEvent (&gt;= v6.3) ===
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-6-3-webhook-and-remoteevent-components&lt;/ref&gt;

=== AssetMapper (&gt;= v6.3) ===
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-6-3-assetmapper-component&lt;/ref&gt;

=== Scheduler (&gt;= v6.3) ===
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-6-3-scheduler-component&lt;/ref&gt;

== Composants non listés comme tels ==
=== apache-pack ===
Pour faire tourner le site sans passer par le serveur &lt;code&gt;symfony server:start&lt;/code&gt;.

== Références ==
{{Références}}</text>
      <sha1>srir86wt9zewym4ptm0ed7ccch5082w</sha1>
    </revision>
    <revision>
      <id>772338</id>
      <parentid>772337</parentid>
      <timestamp>2026-09-17T06:57:36Z</timestamp>
      <contributor>
        <username>JackPotte</username>
        <id>5426</id>
      </contributor>
      <minor />
      <comment>/* process */</comment>
      <origin>772338</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22145" sha1="b3pgh5mhp8ee71d6ymporpr8vkccu77" xml:space="preserve">&lt;noinclude&gt;{{Symfony}}&lt;/noinclude&gt;

== Description ==
Le framework Symfony permet nativement les fonctionnalités minimum dans un souci de performances, à l'instar d'un micro-framework.
Par exemple son compilateur permet d'utiliser plusieurs patrons de conception (design patterns) via des mots réservés dans services.yaml :
* arguments : [[Patrons de conception/Injection de dépendance|Injection de dépendance]]
* decorator : [[Patrons de conception/Décorateur|Décorateur]].
* shared : [[Patrons de conception/Singleton|Singleton]].
* factory : [[Patrons de conception/Fabrique|Fabrique]]&lt;ref&gt;https://symfony.com/doc/current/service_container/factories.html&lt;/ref&gt;.


Toutefois, on peut lui ajouter des composants&lt;ref&gt;https://symfony.com/components&lt;/ref&gt;, dont il convient de connaitre les fonctionnalités pour ne pas réinventer la roue. Pour les installer :
&lt;pre&gt;
composer require symfony/nom_du_composant
&lt;/pre&gt;

Les quatre premiers ci-dessous sont inclus par défaut dans le microframework &lt;code&gt;symfony/skeleton&lt;/code&gt;.

== framework-bundle ==
Structure la configuration principale du framework sans laquelle aucun composant n'est installable&lt;ref&gt;https://symfony.com/doc/current/reference/configuration/framework.html&lt;/ref&gt;.

== console ==
[[Patrons de conception/Commande|Patrons de conception &quot;Commande&quot;]].

Fournit la possibilité d'exécuter le framework avec des commandes shell&lt;ref&gt;https://symfony.com/doc/current/components/console.html&lt;/ref&gt;. Par exemple pour obtenir la liste de toutes les commandes disponibles dans un projet :
&lt;pre&gt;
php bin/console help list
&lt;/pre&gt;

== dotenv ==
Gère les variables d'environnement non versionnées, contenues dans un fichier .env&lt;ref&gt;https://symfony.com/doc/current/components/dotenv.html&lt;/ref&gt;. Elles peuvent aussi bénéficier de {{wt|type checking}} en préfixant les types avec &quot;:&quot;. Ex de .env :

&lt;pre&gt;
IS_DEV_SERVER=1
&lt;/pre&gt;

Le ''services.yaml, parameters:'' récupère ensuite cette valeur et vérifie qu'il s'agit d'un booléen (via le processeur de variable d'environnement &quot;bool&quot;) :
&lt;pre&gt;
is_dev_server: '%env(bool:IS_DEV_SERVER)%'
&lt;/pre&gt;

Il existe plusieurs processeurs de variable d'environnement (en plus de &quot;bool&quot; et des autres types)&lt;ref&gt;https://symfony.com/doc/current/configuration/env_var_processors.html&lt;/ref&gt; :
* &lt;code&gt;base64:&lt;/code&gt; encode en base64.
* &lt;code&gt;default:&lt;/code&gt; remplace le deuxième paramètre par le premier si absent. Ex :
** &lt;code&gt;$addTestValues: '%env(bool:default::ADD_TEST_VALUES)%'&lt;/code&gt; injecte &quot;null&quot; si ADD_TEST_VALUES n'est pas défini.
** &lt;code&gt;$addTestValues: '%env(bool:default:ADD_TEST_VALUES2:ADD_TEST_VALUES1)%'&lt;/code&gt; injecte le contenu de ADD_TEST_VALUES2 si ADD_TEST_VALUES1 n'est pas défini.
* &lt;code&gt;file:&lt;/code&gt; remplace le chemin d'un fichier par son contenu.
* &lt;code&gt;not:&lt;/code&gt; renvoie l'inverse.
* &lt;code&gt;require:&lt;/code&gt; fait un require() PHP.
* &lt;code&gt;resolve:&lt;/code&gt; remplace le nom d'une variable par sa valeur.
* &lt;code&gt;trim:&lt;/code&gt; fait un trim() PHP.

Pour définir une valeur par défaut en cas de variable d'environnement manquante (sans utiliser &lt;code&gt;default:&lt;/code&gt;), dans ''services.yaml, parameters:'' :
&lt;pre&gt;
    env(MY_MISSING_CONSTANT): '0'
&lt;/pre&gt;

== yaml ==
Ajoute la conversion de fichier {{w|YAML}} en tableau PHP&lt;ref&gt;https://symfony.com/doc/current/components/yaml.html&lt;/ref&gt;. Ce format de données constitue une alternative plus lisible au XML pour renseigner la configuration des services. Par défaut le framework se configure avec config.yaml.

== routing ==
[[Patrons de conception/Façade|patron de conception &quot;Façade&quot;]].

Installe les annotations permettant de router des URLs vers les classes des contrôleurs MVC.

{{article détaillé|Programmation PHP avec Symfony/Contrôleur#Routing}}

== serializer ==
Permet de convertir des objets en tableaux ou dans les principaux formats de notation : JSON, XML, YAML et CSV&lt;ref&gt;https://symfony.com/doc/current/components/serializer.html&lt;/ref&gt;.
&lt;pre&gt;
    composer require symfony/serializer
&lt;/pre&gt;

Ce composant est notamment utilisé pour créer des APIs.

== form ==
Construit des formulaires HTML.

{{article détaillé|Programmation PHP avec Symfony/Formulaire}}

== validator ==
Fournit des règles de validation pour les données telles que les adresses emails ou les codes postaux. Utile à coupler avec les formulaires pour contrôler les saisies.

Ces règles peuvent porter sur les propriétés ou les getters.

Il permet aussi de créer des groupes de validateurs, et de les ordonner par séquences. Par défaut chaque classe a automatiquement deux groupes de validateurs : &quot;default&quot; et celui de son nom. Si une séquence est définie, le groupe &quot;default&quot; n'est plus égal au groupe de la classe (celui par défaut) mais à la séquence par défaut&lt;ref&gt;https://symfony.com/doc/current/validation/sequence_provider.html&lt;/ref&gt;.

=== Exemples ===
* Dans une entité :
&lt;pre&gt;
use Symfony\Component\Validator\Constraints as Assert;
...
    #[Assert\Email]
    private ?string $email = null;
&lt;/pre&gt;
* Dans un formulaire (inutile à faire si c'est déjà dans l'entité) :
&lt;pre&gt;
use Symfony\Component\Validator\Constraints\Email;
...
            $builder-&gt;add('email', EmailType::class, [
                'required' =&gt; false,
                'constraints' =&gt; [new Email()],
            ])
&lt;/pre&gt;

== translation ==
Les traductions sont stockées dans un fichier différent par domaine et par langue (code {{w|ISO 639}}). Les formats acceptés sont YAML, XML, PHP&lt;ref&gt;https://symfony.com/doc/current/translation.html&lt;/ref&gt;.

On peut ensuite récupérer ces dictionnaires en Twig (via le filtre &quot;trans&quot;), ou en PHP (via le service &quot;translator&quot;).

Par exemple, le domaine par défaut étant &quot;messages&quot;, le français se trouve donc dans &lt;code&gt;translations/messages.fr.yml&lt;/code&gt; ou &lt;code&gt;translations/messages.fr-FR.yml&lt;/code&gt;.

=== Installation ===
&lt;pre&gt;
 composer require symfony/translation
&lt;/pre&gt;

Pour avoir les traductions inutilisées en anglais :
&lt;pre&gt;
 bin/console debug:translation en --only-unused
&lt;/pre&gt;

Pour les traductions manquantes en anglais :
&lt;pre&gt;
 bin/console debug:translation en --only-missing
&lt;/pre&gt;

On peut restreindre à un seul domaine avec une option : &lt;code&gt;--domain=mon_domaine&lt;/code&gt;

=== Traduction en PHP ===
Le domaine et la langue sont facultatifs (car ils ont des valeurs par défaut) :
&lt;pre&gt;
 $translator-&gt;trans('Hello World', domain: 'login', locale: 'fr_FR');
&lt;/pre&gt;

{{remarque|le composant Symfony Form appelle automatiquement Translations pour ses &quot;labels&quot;.}}

=== Traduction en Twig ===
Les traductions en Twig sont appelées par le [[Programmation PHP avec Symfony/Twig#Filtre_trans|filtre &quot;trans&quot;]] :
&lt;pre&gt;
 {% trans_default_domain 'login' %}
 {{ 'Hello World' |trans }}
&lt;/pre&gt;
Ou :
&lt;pre&gt;
 {{ 'Hello World' |trans({}, 'login', 'fr-FR') }}
&lt;/pre&gt;

=== Variables ===
* YAML : la variable est entre accolades (selon la norme de l'{{w|International Components for Unicode|ICU}}&lt;ref&gt;https://symfony.com/doc/current/reference/formats/message_format.html&lt;/ref&gt;)
&lt;pre&gt;
 Hello World: 'Hello World name!'
&lt;/pre&gt;

* Twig :
&lt;pre&gt;
 {{ Hello World |trans({&quot;name&quot;: userName}) }}
&lt;/pre&gt;

* PHP
&lt;pre&gt;
 $translator-&gt;trans('Hello World', ['name' =&gt; $userName]);
&lt;/pre&gt;

Dans un formulaire Symfony :
&lt;pre&gt;
        $builder
            -&gt;add('hello', TextType::class,([
                'label' =&gt; 'Hello World',
                'label_translation_parameters' =&gt; [
                    'name' =&gt; $userName,
                ]
            ]))
        ;
&lt;/pre&gt;

Par défaut le domaine de traduction est &quot;message&quot; mais on peut désactiver ces dernières avec : &lt;code&gt;choice_translation_domain =&gt; false&lt;/code&gt;.

== event-dispatcher ==
[[Patrons de conception/Observateur|Patrons de conception &quot;Observateur&quot;]]&lt;ref&gt;http://www.jpsymfony.com/design_patterns/le-design-pattern-observer-avec-symfony2&lt;/ref&gt; et [[Patrons de conception/Médiateur|&quot;Médiateur&quot;]]&lt;ref&gt;https://github.com/certificationy/symfony-pack/blob/babd3fee68a7e793767f67c6df140630f52e7f8d/data/architecture.yml#L13&lt;/ref&gt;.

Assure la possibilité d'écouter des évènements pour qu'ils déclenchent des actions.

{{article détaillé|Programmation PHP avec Symfony/Évènement}}

== process ==
Permet de lancer des sous-processus en parallèle&lt;ref&gt;https://symfony.com/doc/current/components/process.html&lt;/ref&gt;. Exemple qui lance une commande shell :
&lt;pre&gt;
    $process = new Process(['ls']);
    $process-&gt;run();
&lt;/pre&gt;

{{attention|En l'absence de &lt;code&gt;$process-&gt;stop()&lt;/code&gt; ou de timeout, le sous-processus peut être stoppé en redémarrant le serveur PHP.|clear=left}}

Exemple de requête SQL asynchrone&lt;ref&gt;https://gist.github.com/appaydin/42eaf953172fc7ea6a8b193694645324&lt;/ref&gt; :
&lt;pre&gt;
    $sql = 'SELECT * FROM ma_table LIMIT 1';
    $process = Process::fromShellCommandline(sprintf('../bin/console dbal:run-sql &quot;%s&quot;', $sql));
    $process-&gt;setTimeout(3600);
    $process-&gt;start();
&lt;/pre&gt;

{{remarque|avant &lt;code&gt;dbal:run-sql&lt;/code&gt; c'était &lt;code&gt;doctrine:query:sql&lt;/code&gt;.}}

== cache ==
Gère les connexions, lectures et écritures vers des serveurs de mémoire caches tels que {{w|Redis}} ou {{w|Memcached}}.

Il fournit une classe ''cacheItem'' conforme à la PSR, instanciable par plusieurs adaptateurs.

Le cache ne sert qu'à accélérer l'application donc une panne sur celui-ci ne doit pas la bloquer. C'est pourquoi il vaut mieux avoir un ou plusieurs caches de secours, même moins rapides, pour prendre le relais dans une chaine de caches.

Pour mettre cela en place sur Symfony, définir le chaine et ses composants dans cache.yaml.

{{article détaillé|Programmation PHP/Redis#Dans Symfony}}

== asset ==
Ajoute la fonction Twig &lt;code&gt;asset()&lt;/code&gt; pour accéder aux fichiers CSS, JS ou images selon leurs versions&lt;ref&gt;https://symfony.com/doc/current/components/asset.html&lt;/ref&gt;.

== webpack-encore ==
Intégration de {{w|Webpack|lang=en}} pour gérer la partie {{wt|front end}} (ex : minifications des CSS et JS).

=== Installation&lt;ref&gt;https://symfonycasts.com/screencast/stimulus/encore&lt;/ref&gt; ===
&lt;pre&gt;
 composer require symfony/webpack-encore-bundle
 yarn install
 yarn build
&lt;/pre&gt;

NB : si {{w|Yarn}} n'est pas installé, le faire avec {{w|npm}} : &lt;code&gt;apt install nodejs npm; npm install --global yarn&lt;/code&gt;.

Cela crée les fichiers package.json et yarn.lock contenant les dépendances JavaScript, le dossier assets/ contenant les JS et CSS versionnés, et le fichier webpack.config.js dans lequel ils sont appelés.

De plus, des fonctions Twig permettent d'y accéder depuis les templates : &lt;code&gt;encore_entry_link_tags()&lt;/code&gt; et &lt;code&gt;encore_entry_script_tags()&lt;/code&gt;.

Par ailleurs, cela installe le framework JS Stimulus, et interprète les {{wt|attributs de données}} pour appeler ses contrôleurs ou méthodes.

=== Rebuild ===
Pour que le code se build en cours de frappe, deux solutions&lt;ref&gt;https://symfony.com/doc/current/frontend/encore/simple-example.html&lt;/ref&gt; :
* Avec Yarn :
** yarn watch
** yarn dev-server
* Avec npm :
** npm watch
** npm run dev-server

La différence entre les deux est que le dev-server peut mettre à jour la page sans même la rafraichir.

== messenger ==
[[Patrons de conception/Chaîne de responsabilité|Patrons de conception &quot;Chaîne de responsabilité&quot;]].

Messenger permet d'utiliser des queues au protocole {{w|AMQP}}. En résumé, il gère l'envoi de messages dans des bus, ces messages transitent par d'éventuels ''middlewares'' puis arrivent à destination dans des ''handlers''&lt;ref&gt;https://vria.eu/delve_into_the_heart_of_the_symfony_messenger/&lt;/ref&gt;. On peut aussi persister ces messages en les envoyant dans des ''transports'' via un {{wt|DSN}}, par exemple dans RabbitMQ, Redis ou Doctrine (donc une table des SGBD les plus populaires).
&lt;pre&gt;
    php bin/console debug:messenger
&lt;/pre&gt;

Chaque middleware doit passer le relais au suivant ainsi :
&lt;pre&gt;
    return $stack-&gt;next()-&gt;handle($envelope, $stack);
&lt;/pre&gt;

Pour stopper le message dans un middleware sans qu'il arrive aux handlers :
&lt;pre&gt;
    return $envelope;
&lt;/pre&gt;

Chaque message peut être défini comme à traiter en synchrone ou asynchrone.

=== En asynchrone ===
Une même commande peur traiter les plusieurs groupes de messages asynchrones, par exemple ceux qui doivent se relancer en cas d'erreur et ceux à ne surtout pas relancer car ils pourraient générer des doublons. Ex :
&lt;pre&gt;
 bin/console messenger:consume async async_no_retry
&lt;/pre&gt;

{{attention|Pour le faire tourner en dev avec les mêmes données dans le webprofiler que les autres commandes Symfony (requêtes Doctrine et HTTP Client), il faut ajouter l'option &quot;no-reset&quot; après &quot;profile&quot; :
&lt;pre&gt;
 bin/console messenger:consume async async_no_retry --profile --no-reset -vvv
&lt;/pre&gt;
}}

{{attention|Pour le faire tourner en prod sans qu'il n'interrompe ses traitements en cours à chaque MEP, il existe plusieurs solutions :
* Processus Linux ''supervisord'' : ne convient pas aux conteneurs car ils interrompent leurs traitements à chaque relance.
* Sidecar container [[Docker/Kubernetes|Kubernetes]] : idem.
* Conteneur dédié qui se redéploie gracieusement après chaque MEP. Par exemple dans Kubernetes, l'option &lt;code&gt;ttlSecondsAfterFinished: 3600&lt;/code&gt; garantit que le conteneur attend la fin du traitement en cours jusqu'à 1h maximum avant de se redéployer.
}}

== workflow ==
[[Patrons de conception/Commande|Patrons de conception &quot;État&quot;]].

Ce composant nécessite de créer (en YAML, XML ou PHP) la configuration d'un {{w|automate fini}}&lt;ref&gt;https://symfony.com/doc/current/workflow.html&lt;/ref&gt;, c'est-à-dire la liste de ses transitions et états (appelés &quot;places&quot;).

Ces graphes sont ensuite visualisables en image ainsi :
&lt;pre&gt;
    use Symfony\Component\Workflow\Definition;
    use Symfony\Component\Workflow\Dumper\StateMachineGraphvizDumper;

    class WorkflowDisplayer
    ...
    $definition = new Definition($places, $transitions);
    echo (new StateMachineGraphvizDumper())-&gt;dump($definition);
&lt;/pre&gt;

&lt;pre&gt;
    sudo apt install graphviz
    php WorkflowDisplayer.php | dot -Tpng -o workflow.png
&lt;/pre&gt;

== browser-kit ==
Simule un navigateur pour les tests d'intégration.

== config ==
Permet de manipuler des fichiers de configurations.

== contracts ==
Pour la {{w|programmation par contrat}}.

== css-selector ==
Pour utiliser {{w|XPath}}.

== debug ==
Fournit des méthodes statiques pour déboguer le PHP.

== dependency-injection ==
Normalise l'utilisation du ''container'' de services.

Permet aussi d'exécuter du code pendant la compilation via un ''compiler pass'', en implémentant l'interface ''CompilerPassInterface'' avec sa méthode ''process''&lt;ref&gt;https://symfony.com/doc/current/components/dependency_injection/compilation.html&lt;/ref&gt;.

== dom-crawler ==
Fournit des méthodes pour parcourir le {{w|DOM}}.

== expression-language ==
[[Patrons de conception/Interpréteur|Patrons de conception &quot;Interpréteur&quot;]].

''Expression language ''sert à évaluer des expressions, ce qui peut permettre de définir des règles métier&lt;ref&gt;https://symfony.com/doc/current/components/expression_language.html&lt;/ref&gt;.

Installation :
composer require symfony/expression-language

Exemple :
&lt;pre&gt;
    $el = new ExpressionLanguage();
    $operation = '1 + 2';
    echo(
    sprintf(
    &quot;L'opération %s vaut %s&quot;,
    $el-&gt;compile($operation));
    $el-&gt;evaluate($operation));
    )
    );
    // Affiche : L'opération 1 + 2 vaut 3
&lt;/pre&gt;

== filesystem ==
Méthodes de lecture et écriture dans les dossiers et fichiers.

== finder ==
Recherche dans les dossiers et fichiers.

== security ==
Ensemble de sous-composants assurant la sécurité d'un site. Ex : authentification, anti-{{w|CSRF}} ou droit des utilisateurs d'accéder à une page.

=== Installation ===
&lt;pre&gt;
composer require symfony/security-bundle
&lt;/pre&gt;

=== Utilisation ===
Dans security.yaml, on peut par exemple définir les classes qui vont assurer l'authentification (''guard''), ou celle ''User'' qui sera instanciée après.

Pour obtenir l'utilisateur ou son token, on peut injecter :
&lt;pre&gt;
 TokenStorageInterface $tokenStorage
&lt;/pre&gt;

pour avoir l'utilisateur courant avec &lt;code&gt;$this-&gt;tokenStorage-&gt;getToken()?-&gt;getUser()&lt;/code&gt;.

== guard ==
Extension de sécurité pour des authentifications complexes.

== http-client ==
Pour lancer des requêtes HTTP depuis l'application.

{{article détaillé|Programmation PHP avec Symfony/HttpClient}}

== http-foundation ==
Fournit des classes pour manipuler les requêtes HTTP, comme ''Request'' et ''Response'' que l'on retrouve dans les contrôleurs.

Par exemple :
&lt;pre&gt;
    use Symfony\Component\HttpFoundation\Response;
    //...
    echo Response::HTTP_OK; // 200
    echo Response::HTTP_NOT_FOUND; // 404
&lt;/pre&gt;

== http-kernel ==
Permet d'utiliser des évènements lors des transformations des requêtes HTTP en réponses.

== inflector ==
Deprecated depuis Symfony 5.

Accorde les mots anglais au pluriel à partir de leurs singuliers.

== intl ==
Internationalisation, comme par exemple la classe &quot;Locale&quot; pour gérer une langue.

== ldap ==
Connexion aux serveur {{w|LDAP}}.

== lock ==
Pour verrouiller les accès aux ressources&lt;ref&gt;https://symfony.com/doc/current/components/lock.html&lt;/ref&gt;.

Par exemple, pour ne pas qu'une commande soit lancée deux fois simultanément, bien que le composant console aie aussi cette fonctionnalité :
&lt;pre&gt;
 use Symfony\Component\Console\Command\LockableTrait;
 ...
    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        if ($this-&gt;lock() === false) {
            return Command::SUCCESS;
        }

        ...

        $this-&gt;release();
        return Command::SUCCESS;
    }
&lt;/pre&gt;

== Maker bundle ==
Pour créer ou recréer des classes à partir de déductions&lt;ref&gt;https://symfony.com/bundles/SymfonyMakerBundle/current/index.html&lt;/ref&gt;.
&lt;pre&gt;
 composer require --dev symfony/maker-bundle
&lt;/pre&gt;

NB : ce composant ne permet pas de générer des entités à partir d'une base de données.

== mailer ==
Pour envoyer des emails.

== mime ==
Manipulation des messages {{w|MIME}}.

== notifier ==
Pour envoyer des notifications telles que des emails, des SMS, des messages instantanés, etc.

== options-resolver ==
Gère les remplacements de propriétés par d'autres, avec certaines par défaut.

== phpunit-bridge ==
[[Patrons de conception/Pont|Patron de conception &quot;Pont&quot;]] qui apporte plusieurs fonctionnalités liées aux tests unitaires, telles que la liste des tests désuets ou des mocks de fonctions PHP natif.

== property-access ==
Pour lire les attributs de classe à partir de leurs getters, ou des tableaux.

== property-info ==
Pour lire les métadonnées des attributs de classe.

== stopwatch ==
Chronomètre pour mesurer des temps d'exécution.

== string ==
API convertissant certains objets en chaine de caractères. Ex :
&lt;pre&gt;
    use Symfony\Component\String\Slugger\AsciiSlugger;

    $slugger = new AsciiSlugger();
    echo $slugger-&gt;slug('caractères spéciaux € $');
&lt;/pre&gt;
Résultat :
caracteres-speciaux-EUR

== templating ==
Extension de construction de templates.

{{article détaillé|Programmation PHP avec Symfony/Templating}}

== var-dumper ==
Ajoute une fonction globale &lt;code&gt;dump()&lt;/code&gt; pour déboguer des objets en les affichant avec une coloration syntaxique et des menus déroulant.

Ajoute aussi &lt;code&gt;dd()&lt;/code&gt; pour ''dump() and die()''.

== var-exporter ==
Permet d'instancier une classe sans utiliser son constructeur.

== polyfill* ==
On trouve aussi une vingtaine de composants {{wt|polyfill}}, fournissant des fonctions PHP retirées dans les versions les plus récentes.

== Composants désuets ==
=== locale (&lt;= v2.3) ===
Arrêté en 2011, car remplacé par le composant ''intl''&lt;ref&gt;https://symfony.com/components/Locale&lt;/ref&gt;.

=== icu (&lt;= v2.6) ===
Arrêté en 2014, car remplacé par le composant ''intl''&lt;ref&gt;https://symfony.com/components/Icu&lt;/ref&gt;.

=== class-loader (&lt;= v3.3) ===
Arrêté en 2011, car remplacé par composer.json&lt;ref&gt;https://symfony.com/components/ClassLoader&lt;/ref&gt;.

== Ajoutés en 2020 ==
=== Uid ''(sic)'' (&gt;= v5.1) ===
Pour générer des {{w|UUID}}&lt;ref&gt;https://symfony.com/doc/current/components/uid.html&lt;/ref&gt;.

=== RateLimiter (&gt;= v5.2) ===
[[Patrons de conception/Proxy|Patron de conception &quot;Proxy&quot;]], qui permet de limiter la consommation de ressources du serveur par les clients&lt;ref&gt;https://symfony.com/doc/current/rate_limiter.html&lt;/ref&gt;

Installation :
&lt;pre&gt;
composer require symfony/rate-limiter
&lt;/pre&gt;

Pour l'activer, ajouter la ligne suivante dans les pare-feux de security.yaml concernés :
&lt;pre&gt;
 login_throttling: true
&lt;/pre&gt;

=== Semaphore (&gt;= v5.2) ===
Pour donner l'exclusivité d'accès à une ressource&lt;ref&gt;https://symfony.com/doc/current/components/semaphore.html&lt;/ref&gt;.

== Ajoutés en 2021 ==
=== PasswordHasher (&gt;= v5.3) ===
Pour gérer les chiffrements&lt;ref&gt;https://symfony.com/blog/new-in-symfony-5-3-passwordhasher-component&lt;/ref&gt;.

=== Runtime (&gt;= v5.3) ===
Pour le démarrage (bootstrap) : permettre de découpler l'application de son code de retour.
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-5-3-runtime-component&lt;/ref&gt;.

== Ajoutés en 2022 ==
=== HtmlSanitizer (&gt;= v6.1) ===

=== Clock (&gt;= v6.2) ===

=== Symfony UX (&gt;= v5.4) ===
==== ux-autocomplete ====

==== ux-chartjs ====
Utilise Chart.js via Stimulus pour afficher des graphiques, via la fonction Twig &lt;code&gt;render_chart()&lt;/code&gt;&lt;ref&gt;https://symfony.com/bundles/ux-chartjs/current/index.html&lt;/ref&gt;.

==== ux-react ====
Ajoute le framework {{w|React.js}}.

{{article détaillé|Programmation PHP avec Symfony/Stimulus}}

==== ux-vue ====
Ajoute le framework {{w|Vue.js}}.

== Ajoutés en 2023 ==
=== Webhook et RemoteEvent (&gt;= v6.3) ===
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-6-3-webhook-and-remoteevent-components&lt;/ref&gt;

=== AssetMapper (&gt;= v6.3) ===
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-6-3-assetmapper-component&lt;/ref&gt;

=== Scheduler (&gt;= v6.3) ===
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-6-3-scheduler-component&lt;/ref&gt;

== Composants non listés comme tels ==
=== apache-pack ===
Pour faire tourner le site sans passer par le serveur &lt;code&gt;symfony server:start&lt;/code&gt;.

== Références ==
{{Références}}</text>
      <sha1>b3pgh5mhp8ee71d6ymporpr8vkccu77</sha1>
    </revision>
    <revision>
      <id>772341</id>
      <parentid>772338</parentid>
      <timestamp>2026-09-17T06:59:45Z</timestamp>
      <contributor>
        <username>JackPotte</username>
        <id>5426</id>
      </contributor>
      <minor />
      <comment>/* process */</comment>
      <origin>772341</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22057" sha1="jzqd3srccdk1v8wmamm69zs5y2y391y" xml:space="preserve">&lt;noinclude&gt;{{Symfony}}&lt;/noinclude&gt;

== Description ==
Le framework Symfony permet nativement les fonctionnalités minimum dans un souci de performances, à l'instar d'un micro-framework.
Par exemple son compilateur permet d'utiliser plusieurs patrons de conception (design patterns) via des mots réservés dans services.yaml :
* arguments : [[Patrons de conception/Injection de dépendance|Injection de dépendance]]
* decorator : [[Patrons de conception/Décorateur|Décorateur]].
* shared : [[Patrons de conception/Singleton|Singleton]].
* factory : [[Patrons de conception/Fabrique|Fabrique]]&lt;ref&gt;https://symfony.com/doc/current/service_container/factories.html&lt;/ref&gt;.


Toutefois, on peut lui ajouter des composants&lt;ref&gt;https://symfony.com/components&lt;/ref&gt;, dont il convient de connaitre les fonctionnalités pour ne pas réinventer la roue. Pour les installer :
&lt;pre&gt;
composer require symfony/nom_du_composant
&lt;/pre&gt;

Les quatre premiers ci-dessous sont inclus par défaut dans le microframework &lt;code&gt;symfony/skeleton&lt;/code&gt;.

== framework-bundle ==
Structure la configuration principale du framework sans laquelle aucun composant n'est installable&lt;ref&gt;https://symfony.com/doc/current/reference/configuration/framework.html&lt;/ref&gt;.

== console ==
[[Patrons de conception/Commande|Patrons de conception &quot;Commande&quot;]].

Fournit la possibilité d'exécuter le framework avec des commandes shell&lt;ref&gt;https://symfony.com/doc/current/components/console.html&lt;/ref&gt;. Par exemple pour obtenir la liste de toutes les commandes disponibles dans un projet :
&lt;pre&gt;
php bin/console help list
&lt;/pre&gt;

== dotenv ==
Gère les variables d'environnement non versionnées, contenues dans un fichier .env&lt;ref&gt;https://symfony.com/doc/current/components/dotenv.html&lt;/ref&gt;. Elles peuvent aussi bénéficier de {{wt|type checking}} en préfixant les types avec &quot;:&quot;. Ex de .env :

&lt;pre&gt;
IS_DEV_SERVER=1
&lt;/pre&gt;

Le ''services.yaml, parameters:'' récupère ensuite cette valeur et vérifie qu'il s'agit d'un booléen (via le processeur de variable d'environnement &quot;bool&quot;) :
&lt;pre&gt;
is_dev_server: '%env(bool:IS_DEV_SERVER)%'
&lt;/pre&gt;

Il existe plusieurs processeurs de variable d'environnement (en plus de &quot;bool&quot; et des autres types)&lt;ref&gt;https://symfony.com/doc/current/configuration/env_var_processors.html&lt;/ref&gt; :
* &lt;code&gt;base64:&lt;/code&gt; encode en base64.
* &lt;code&gt;default:&lt;/code&gt; remplace le deuxième paramètre par le premier si absent. Ex :
** &lt;code&gt;$addTestValues: '%env(bool:default::ADD_TEST_VALUES)%'&lt;/code&gt; injecte &quot;null&quot; si ADD_TEST_VALUES n'est pas défini.
** &lt;code&gt;$addTestValues: '%env(bool:default:ADD_TEST_VALUES2:ADD_TEST_VALUES1)%'&lt;/code&gt; injecte le contenu de ADD_TEST_VALUES2 si ADD_TEST_VALUES1 n'est pas défini.
* &lt;code&gt;file:&lt;/code&gt; remplace le chemin d'un fichier par son contenu.
* &lt;code&gt;not:&lt;/code&gt; renvoie l'inverse.
* &lt;code&gt;require:&lt;/code&gt; fait un require() PHP.
* &lt;code&gt;resolve:&lt;/code&gt; remplace le nom d'une variable par sa valeur.
* &lt;code&gt;trim:&lt;/code&gt; fait un trim() PHP.

Pour définir une valeur par défaut en cas de variable d'environnement manquante (sans utiliser &lt;code&gt;default:&lt;/code&gt;), dans ''services.yaml, parameters:'' :
&lt;pre&gt;
    env(MY_MISSING_CONSTANT): '0'
&lt;/pre&gt;

== yaml ==
Ajoute la conversion de fichier {{w|YAML}} en tableau PHP&lt;ref&gt;https://symfony.com/doc/current/components/yaml.html&lt;/ref&gt;. Ce format de données constitue une alternative plus lisible au XML pour renseigner la configuration des services. Par défaut le framework se configure avec config.yaml.

== routing ==
[[Patrons de conception/Façade|patron de conception &quot;Façade&quot;]].

Installe les annotations permettant de router des URLs vers les classes des contrôleurs MVC.

{{article détaillé|Programmation PHP avec Symfony/Contrôleur#Routing}}

== serializer ==
Permet de convertir des objets en tableaux ou dans les principaux formats de notation : JSON, XML, YAML et CSV&lt;ref&gt;https://symfony.com/doc/current/components/serializer.html&lt;/ref&gt;.
&lt;pre&gt;
    composer require symfony/serializer
&lt;/pre&gt;

Ce composant est notamment utilisé pour créer des APIs.

== form ==
Construit des formulaires HTML.

{{article détaillé|Programmation PHP avec Symfony/Formulaire}}

== validator ==
Fournit des règles de validation pour les données telles que les adresses emails ou les codes postaux. Utile à coupler avec les formulaires pour contrôler les saisies.

Ces règles peuvent porter sur les propriétés ou les getters.

Il permet aussi de créer des groupes de validateurs, et de les ordonner par séquences. Par défaut chaque classe a automatiquement deux groupes de validateurs : &quot;default&quot; et celui de son nom. Si une séquence est définie, le groupe &quot;default&quot; n'est plus égal au groupe de la classe (celui par défaut) mais à la séquence par défaut&lt;ref&gt;https://symfony.com/doc/current/validation/sequence_provider.html&lt;/ref&gt;.

=== Exemples ===
* Dans une entité :
&lt;pre&gt;
use Symfony\Component\Validator\Constraints as Assert;
...
    #[Assert\Email]
    private ?string $email = null;
&lt;/pre&gt;
* Dans un formulaire (inutile à faire si c'est déjà dans l'entité) :
&lt;pre&gt;
use Symfony\Component\Validator\Constraints\Email;
...
            $builder-&gt;add('email', EmailType::class, [
                'required' =&gt; false,
                'constraints' =&gt; [new Email()],
            ])
&lt;/pre&gt;

== translation ==
Les traductions sont stockées dans un fichier différent par domaine et par langue (code {{w|ISO 639}}). Les formats acceptés sont YAML, XML, PHP&lt;ref&gt;https://symfony.com/doc/current/translation.html&lt;/ref&gt;.

On peut ensuite récupérer ces dictionnaires en Twig (via le filtre &quot;trans&quot;), ou en PHP (via le service &quot;translator&quot;).

Par exemple, le domaine par défaut étant &quot;messages&quot;, le français se trouve donc dans &lt;code&gt;translations/messages.fr.yml&lt;/code&gt; ou &lt;code&gt;translations/messages.fr-FR.yml&lt;/code&gt;.

=== Installation ===
&lt;pre&gt;
 composer require symfony/translation
&lt;/pre&gt;

Pour avoir les traductions inutilisées en anglais :
&lt;pre&gt;
 bin/console debug:translation en --only-unused
&lt;/pre&gt;

Pour les traductions manquantes en anglais :
&lt;pre&gt;
 bin/console debug:translation en --only-missing
&lt;/pre&gt;

On peut restreindre à un seul domaine avec une option : &lt;code&gt;--domain=mon_domaine&lt;/code&gt;

=== Traduction en PHP ===
Le domaine et la langue sont facultatifs (car ils ont des valeurs par défaut) :
&lt;pre&gt;
 $translator-&gt;trans('Hello World', domain: 'login', locale: 'fr_FR');
&lt;/pre&gt;

{{remarque|le composant Symfony Form appelle automatiquement Translations pour ses &quot;labels&quot;.}}

=== Traduction en Twig ===
Les traductions en Twig sont appelées par le [[Programmation PHP avec Symfony/Twig#Filtre_trans|filtre &quot;trans&quot;]] :
&lt;pre&gt;
 {% trans_default_domain 'login' %}
 {{ 'Hello World' |trans }}
&lt;/pre&gt;
Ou :
&lt;pre&gt;
 {{ 'Hello World' |trans({}, 'login', 'fr-FR') }}
&lt;/pre&gt;

=== Variables ===
* YAML : la variable est entre accolades (selon la norme de l'{{w|International Components for Unicode|ICU}}&lt;ref&gt;https://symfony.com/doc/current/reference/formats/message_format.html&lt;/ref&gt;)
&lt;pre&gt;
 Hello World: 'Hello World name!'
&lt;/pre&gt;

* Twig :
&lt;pre&gt;
 {{ Hello World |trans({&quot;name&quot;: userName}) }}
&lt;/pre&gt;

* PHP
&lt;pre&gt;
 $translator-&gt;trans('Hello World', ['name' =&gt; $userName]);
&lt;/pre&gt;

Dans un formulaire Symfony :
&lt;pre&gt;
        $builder
            -&gt;add('hello', TextType::class,([
                'label' =&gt; 'Hello World',
                'label_translation_parameters' =&gt; [
                    'name' =&gt; $userName,
                ]
            ]))
        ;
&lt;/pre&gt;

Par défaut le domaine de traduction est &quot;message&quot; mais on peut désactiver ces dernières avec : &lt;code&gt;choice_translation_domain =&gt; false&lt;/code&gt;.

== event-dispatcher ==
[[Patrons de conception/Observateur|Patrons de conception &quot;Observateur&quot;]]&lt;ref&gt;http://www.jpsymfony.com/design_patterns/le-design-pattern-observer-avec-symfony2&lt;/ref&gt; et [[Patrons de conception/Médiateur|&quot;Médiateur&quot;]]&lt;ref&gt;https://github.com/certificationy/symfony-pack/blob/babd3fee68a7e793767f67c6df140630f52e7f8d/data/architecture.yml#L13&lt;/ref&gt;.

Assure la possibilité d'écouter des évènements pour qu'ils déclenchent des actions.

{{article détaillé|Programmation PHP avec Symfony/Évènement}}

== process ==
Permet de lancer des sous-processus en parallèle&lt;ref&gt;https://symfony.com/doc/current/components/process.html&lt;/ref&gt;. Exemple qui lance une commande shell :
&lt;pre&gt;
    $process = new Process(['ls']);
    $process-&gt;run();
&lt;/pre&gt;

{{attention|En l'absence de &lt;code&gt;$process-&gt;stop()&lt;/code&gt; ou de timeout, le sous-processus peut être stoppé en redémarrant le serveur PHP.|clear=left}}

Exemple de requête SQL asynchrone&lt;ref&gt;https://gist.github.com/appaydin/42eaf953172fc7ea6a8b193694645324&lt;/ref&gt; :
&lt;pre&gt;
    $sql = 'SELECT * FROM ma_table LIMIT 1';
    $process = Process::fromShellCommandline(sprintf('../bin/console dbal:run-sql &quot;%s&quot;', $sql));
    $process-&gt;setTimeout(3600);
    $process-&gt;start();
&lt;/pre&gt;

== cache ==
Gère les connexions, lectures et écritures vers des serveurs de mémoire caches tels que {{w|Redis}} ou {{w|Memcached}}.

Il fournit une classe ''cacheItem'' conforme à la PSR, instanciable par plusieurs adaptateurs.

Le cache ne sert qu'à accélérer l'application donc une panne sur celui-ci ne doit pas la bloquer. C'est pourquoi il vaut mieux avoir un ou plusieurs caches de secours, même moins rapides, pour prendre le relais dans une chaine de caches.

Pour mettre cela en place sur Symfony, définir le chaine et ses composants dans cache.yaml.

{{article détaillé|Programmation PHP/Redis#Dans Symfony}}

== asset ==
Ajoute la fonction Twig &lt;code&gt;asset()&lt;/code&gt; pour accéder aux fichiers CSS, JS ou images selon leurs versions&lt;ref&gt;https://symfony.com/doc/current/components/asset.html&lt;/ref&gt;.

== webpack-encore ==
Intégration de {{w|Webpack|lang=en}} pour gérer la partie {{wt|front end}} (ex : minifications des CSS et JS).

=== Installation&lt;ref&gt;https://symfonycasts.com/screencast/stimulus/encore&lt;/ref&gt; ===
&lt;pre&gt;
 composer require symfony/webpack-encore-bundle
 yarn install
 yarn build
&lt;/pre&gt;

NB : si {{w|Yarn}} n'est pas installé, le faire avec {{w|npm}} : &lt;code&gt;apt install nodejs npm; npm install --global yarn&lt;/code&gt;.

Cela crée les fichiers package.json et yarn.lock contenant les dépendances JavaScript, le dossier assets/ contenant les JS et CSS versionnés, et le fichier webpack.config.js dans lequel ils sont appelés.

De plus, des fonctions Twig permettent d'y accéder depuis les templates : &lt;code&gt;encore_entry_link_tags()&lt;/code&gt; et &lt;code&gt;encore_entry_script_tags()&lt;/code&gt;.

Par ailleurs, cela installe le framework JS Stimulus, et interprète les {{wt|attributs de données}} pour appeler ses contrôleurs ou méthodes.

=== Rebuild ===
Pour que le code se build en cours de frappe, deux solutions&lt;ref&gt;https://symfony.com/doc/current/frontend/encore/simple-example.html&lt;/ref&gt; :
* Avec Yarn :
** yarn watch
** yarn dev-server
* Avec npm :
** npm watch
** npm run dev-server

La différence entre les deux est que le dev-server peut mettre à jour la page sans même la rafraichir.

== messenger ==
[[Patrons de conception/Chaîne de responsabilité|Patrons de conception &quot;Chaîne de responsabilité&quot;]].

Messenger permet d'utiliser des queues au protocole {{w|AMQP}}. En résumé, il gère l'envoi de messages dans des bus, ces messages transitent par d'éventuels ''middlewares'' puis arrivent à destination dans des ''handlers''&lt;ref&gt;https://vria.eu/delve_into_the_heart_of_the_symfony_messenger/&lt;/ref&gt;. On peut aussi persister ces messages en les envoyant dans des ''transports'' via un {{wt|DSN}}, par exemple dans RabbitMQ, Redis ou Doctrine (donc une table des SGBD les plus populaires).
&lt;pre&gt;
    php bin/console debug:messenger
&lt;/pre&gt;

Chaque middleware doit passer le relais au suivant ainsi :
&lt;pre&gt;
    return $stack-&gt;next()-&gt;handle($envelope, $stack);
&lt;/pre&gt;

Pour stopper le message dans un middleware sans qu'il arrive aux handlers :
&lt;pre&gt;
    return $envelope;
&lt;/pre&gt;

Chaque message peut être défini comme à traiter en synchrone ou asynchrone.

=== En asynchrone ===
Une même commande peur traiter les plusieurs groupes de messages asynchrones, par exemple ceux qui doivent se relancer en cas d'erreur et ceux à ne surtout pas relancer car ils pourraient générer des doublons. Ex :
&lt;pre&gt;
 bin/console messenger:consume async async_no_retry
&lt;/pre&gt;

{{attention|Pour le faire tourner en dev avec les mêmes données dans le webprofiler que les autres commandes Symfony (requêtes Doctrine et HTTP Client), il faut ajouter l'option &quot;no-reset&quot; après &quot;profile&quot; :
&lt;pre&gt;
 bin/console messenger:consume async async_no_retry --profile --no-reset -vvv
&lt;/pre&gt;
}}

{{attention|Pour le faire tourner en prod sans qu'il n'interrompe ses traitements en cours à chaque MEP, il existe plusieurs solutions :
* Processus Linux ''supervisord'' : ne convient pas aux conteneurs car ils interrompent leurs traitements à chaque relance.
* Sidecar container [[Docker/Kubernetes|Kubernetes]] : idem.
* Conteneur dédié qui se redéploie gracieusement après chaque MEP. Par exemple dans Kubernetes, l'option &lt;code&gt;ttlSecondsAfterFinished: 3600&lt;/code&gt; garantit que le conteneur attend la fin du traitement en cours jusqu'à 1h maximum avant de se redéployer.
}}

== workflow ==
[[Patrons de conception/Commande|Patrons de conception &quot;État&quot;]].

Ce composant nécessite de créer (en YAML, XML ou PHP) la configuration d'un {{w|automate fini}}&lt;ref&gt;https://symfony.com/doc/current/workflow.html&lt;/ref&gt;, c'est-à-dire la liste de ses transitions et états (appelés &quot;places&quot;).

Ces graphes sont ensuite visualisables en image ainsi :
&lt;pre&gt;
    use Symfony\Component\Workflow\Definition;
    use Symfony\Component\Workflow\Dumper\StateMachineGraphvizDumper;

    class WorkflowDisplayer
    ...
    $definition = new Definition($places, $transitions);
    echo (new StateMachineGraphvizDumper())-&gt;dump($definition);
&lt;/pre&gt;

&lt;pre&gt;
    sudo apt install graphviz
    php WorkflowDisplayer.php | dot -Tpng -o workflow.png
&lt;/pre&gt;

== browser-kit ==
Simule un navigateur pour les tests d'intégration.

== config ==
Permet de manipuler des fichiers de configurations.

== contracts ==
Pour la {{w|programmation par contrat}}.

== css-selector ==
Pour utiliser {{w|XPath}}.

== debug ==
Fournit des méthodes statiques pour déboguer le PHP.

== dependency-injection ==
Normalise l'utilisation du ''container'' de services.

Permet aussi d'exécuter du code pendant la compilation via un ''compiler pass'', en implémentant l'interface ''CompilerPassInterface'' avec sa méthode ''process''&lt;ref&gt;https://symfony.com/doc/current/components/dependency_injection/compilation.html&lt;/ref&gt;.

== dom-crawler ==
Fournit des méthodes pour parcourir le {{w|DOM}}.

== expression-language ==
[[Patrons de conception/Interpréteur|Patrons de conception &quot;Interpréteur&quot;]].

''Expression language ''sert à évaluer des expressions, ce qui peut permettre de définir des règles métier&lt;ref&gt;https://symfony.com/doc/current/components/expression_language.html&lt;/ref&gt;.

Installation :
composer require symfony/expression-language

Exemple :
&lt;pre&gt;
    $el = new ExpressionLanguage();
    $operation = '1 + 2';
    echo(
    sprintf(
    &quot;L'opération %s vaut %s&quot;,
    $el-&gt;compile($operation));
    $el-&gt;evaluate($operation));
    )
    );
    // Affiche : L'opération 1 + 2 vaut 3
&lt;/pre&gt;

== filesystem ==
Méthodes de lecture et écriture dans les dossiers et fichiers.

== finder ==
Recherche dans les dossiers et fichiers.

== security ==
Ensemble de sous-composants assurant la sécurité d'un site. Ex : authentification, anti-{{w|CSRF}} ou droit des utilisateurs d'accéder à une page.

=== Installation ===
&lt;pre&gt;
composer require symfony/security-bundle
&lt;/pre&gt;

=== Utilisation ===
Dans security.yaml, on peut par exemple définir les classes qui vont assurer l'authentification (''guard''), ou celle ''User'' qui sera instanciée après.

Pour obtenir l'utilisateur ou son token, on peut injecter :
&lt;pre&gt;
 TokenStorageInterface $tokenStorage
&lt;/pre&gt;

pour avoir l'utilisateur courant avec &lt;code&gt;$this-&gt;tokenStorage-&gt;getToken()?-&gt;getUser()&lt;/code&gt;.

== guard ==
Extension de sécurité pour des authentifications complexes.

== http-client ==
Pour lancer des requêtes HTTP depuis l'application.

{{article détaillé|Programmation PHP avec Symfony/HttpClient}}

== http-foundation ==
Fournit des classes pour manipuler les requêtes HTTP, comme ''Request'' et ''Response'' que l'on retrouve dans les contrôleurs.

Par exemple :
&lt;pre&gt;
    use Symfony\Component\HttpFoundation\Response;
    //...
    echo Response::HTTP_OK; // 200
    echo Response::HTTP_NOT_FOUND; // 404
&lt;/pre&gt;

== http-kernel ==
Permet d'utiliser des évènements lors des transformations des requêtes HTTP en réponses.

== inflector ==
Deprecated depuis Symfony 5.

Accorde les mots anglais au pluriel à partir de leurs singuliers.

== intl ==
Internationalisation, comme par exemple la classe &quot;Locale&quot; pour gérer une langue.

== ldap ==
Connexion aux serveur {{w|LDAP}}.

== lock ==
Pour verrouiller les accès aux ressources&lt;ref&gt;https://symfony.com/doc/current/components/lock.html&lt;/ref&gt;.

Par exemple, pour ne pas qu'une commande soit lancée deux fois simultanément, bien que le composant console aie aussi cette fonctionnalité :
&lt;pre&gt;
 use Symfony\Component\Console\Command\LockableTrait;
 ...
    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        if ($this-&gt;lock() === false) {
            return Command::SUCCESS;
        }

        ...

        $this-&gt;release();
        return Command::SUCCESS;
    }
&lt;/pre&gt;

== Maker bundle ==
Pour créer ou recréer des classes à partir de déductions&lt;ref&gt;https://symfony.com/bundles/SymfonyMakerBundle/current/index.html&lt;/ref&gt;.
&lt;pre&gt;
 composer require --dev symfony/maker-bundle
&lt;/pre&gt;

NB : ce composant ne permet pas de générer des entités à partir d'une base de données.

== mailer ==
Pour envoyer des emails.

== mime ==
Manipulation des messages {{w|MIME}}.

== notifier ==
Pour envoyer des notifications telles que des emails, des SMS, des messages instantanés, etc.

== options-resolver ==
Gère les remplacements de propriétés par d'autres, avec certaines par défaut.

== phpunit-bridge ==
[[Patrons de conception/Pont|Patron de conception &quot;Pont&quot;]] qui apporte plusieurs fonctionnalités liées aux tests unitaires, telles que la liste des tests désuets ou des mocks de fonctions PHP natif.

== property-access ==
Pour lire les attributs de classe à partir de leurs getters, ou des tableaux.

== property-info ==
Pour lire les métadonnées des attributs de classe.

== stopwatch ==
Chronomètre pour mesurer des temps d'exécution.

== string ==
API convertissant certains objets en chaine de caractères. Ex :
&lt;pre&gt;
    use Symfony\Component\String\Slugger\AsciiSlugger;

    $slugger = new AsciiSlugger();
    echo $slugger-&gt;slug('caractères spéciaux € $');
&lt;/pre&gt;
Résultat :
caracteres-speciaux-EUR

== templating ==
Extension de construction de templates.

{{article détaillé|Programmation PHP avec Symfony/Templating}}

== var-dumper ==
Ajoute une fonction globale &lt;code&gt;dump()&lt;/code&gt; pour déboguer des objets en les affichant avec une coloration syntaxique et des menus déroulant.

Ajoute aussi &lt;code&gt;dd()&lt;/code&gt; pour ''dump() and die()''.

== var-exporter ==
Permet d'instancier une classe sans utiliser son constructeur.

== polyfill* ==
On trouve aussi une vingtaine de composants {{wt|polyfill}}, fournissant des fonctions PHP retirées dans les versions les plus récentes.

== Composants désuets ==
=== locale (&lt;= v2.3) ===
Arrêté en 2011, car remplacé par le composant ''intl''&lt;ref&gt;https://symfony.com/components/Locale&lt;/ref&gt;.

=== icu (&lt;= v2.6) ===
Arrêté en 2014, car remplacé par le composant ''intl''&lt;ref&gt;https://symfony.com/components/Icu&lt;/ref&gt;.

=== class-loader (&lt;= v3.3) ===
Arrêté en 2011, car remplacé par composer.json&lt;ref&gt;https://symfony.com/components/ClassLoader&lt;/ref&gt;.

== Ajoutés en 2020 ==
=== Uid ''(sic)'' (&gt;= v5.1) ===
Pour générer des {{w|UUID}}&lt;ref&gt;https://symfony.com/doc/current/components/uid.html&lt;/ref&gt;.

=== RateLimiter (&gt;= v5.2) ===
[[Patrons de conception/Proxy|Patron de conception &quot;Proxy&quot;]], qui permet de limiter la consommation de ressources du serveur par les clients&lt;ref&gt;https://symfony.com/doc/current/rate_limiter.html&lt;/ref&gt;

Installation :
&lt;pre&gt;
composer require symfony/rate-limiter
&lt;/pre&gt;

Pour l'activer, ajouter la ligne suivante dans les pare-feux de security.yaml concernés :
&lt;pre&gt;
 login_throttling: true
&lt;/pre&gt;

=== Semaphore (&gt;= v5.2) ===
Pour donner l'exclusivité d'accès à une ressource&lt;ref&gt;https://symfony.com/doc/current/components/semaphore.html&lt;/ref&gt;.

== Ajoutés en 2021 ==
=== PasswordHasher (&gt;= v5.3) ===
Pour gérer les chiffrements&lt;ref&gt;https://symfony.com/blog/new-in-symfony-5-3-passwordhasher-component&lt;/ref&gt;.

=== Runtime (&gt;= v5.3) ===
Pour le démarrage (bootstrap) : permettre de découpler l'application de son code de retour.
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-5-3-runtime-component&lt;/ref&gt;.

== Ajoutés en 2022 ==
=== HtmlSanitizer (&gt;= v6.1) ===

=== Clock (&gt;= v6.2) ===

=== Symfony UX (&gt;= v5.4) ===
==== ux-autocomplete ====

==== ux-chartjs ====
Utilise Chart.js via Stimulus pour afficher des graphiques, via la fonction Twig &lt;code&gt;render_chart()&lt;/code&gt;&lt;ref&gt;https://symfony.com/bundles/ux-chartjs/current/index.html&lt;/ref&gt;.

==== ux-react ====
Ajoute le framework {{w|React.js}}.

{{article détaillé|Programmation PHP avec Symfony/Stimulus}}

==== ux-vue ====
Ajoute le framework {{w|Vue.js}}.

== Ajoutés en 2023 ==
=== Webhook et RemoteEvent (&gt;= v6.3) ===
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-6-3-webhook-and-remoteevent-components&lt;/ref&gt;

=== AssetMapper (&gt;= v6.3) ===
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-6-3-assetmapper-component&lt;/ref&gt;

=== Scheduler (&gt;= v6.3) ===
&lt;ref&gt;https://symfony.com/blog/new-in-symfony-6-3-scheduler-component&lt;/ref&gt;

== Composants non listés comme tels ==
=== apache-pack ===
Pour faire tourner le site sans passer par le serveur &lt;code&gt;symfony server:start&lt;/code&gt;.

== Références ==
{{Références}}</text>
      <sha1>jzqd3srccdk1v8wmamm69zs5y2y391y</sha1>
    </revision>
  </page>
  <page>
    <title>Wikilivres:Vitrine/Cuisine:Pâte à crêpe</title>
    <ns>4</ns>
    <id>78129</id>
    <revision>
      <id>772334</id>
      <parentid>675115</parentid>
      <timestamp>2026-09-17T06:36:07Z</timestamp>
      <contributor>
        <username>DavidL</username>
        <id>1746</id>
      </contributor>
      <origin>772334</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="510" sha1="c2jpgtff1a84gkt5emcx5igxg3fww9c" xml:space="preserve">&lt;noinclude&gt;[[Catégorie:Livres en vitrine]]&lt;/noinclude&gt;{{VitrineLivre{{{1|}}}|
image=Crepes dsc07085.jpg|
lien=Livre de cuisine/Pâte à crêpe|
textelien=Pâte à crêpe|
texte=La '''[[Livre de cuisine/Pâte à crêpe|pâte à crêpe]]''' est une fine galette de pâte à base de farine, d'œufs et de lait. Elle est dégustée soit sucrée (sucre, crème de marron, etc.), soit salée (œufs au plat, thon, fromage, etc.), ou encore comme ingrédient pour des {{i|nocat=1|crêpe|plats à base de crêpes}}.}}</text>
      <sha1>c2jpgtff1a84gkt5emcx5igxg3fww9c</sha1>
    </revision>
  </page>
  <page>
    <title>Wikilivres:GUS2Wiki</title>
    <ns>4</ns>
    <id>78643</id>
    <revision>
      <id>772344</id>
      <parentid>771887</parentid>
      <timestamp>2026-09-17T08:47:35Z</timestamp>
      <contributor>
        <username>Alexis Jazz</username>
        <id>81580</id>
      </contributor>
      <comment>Updating gadget usage statistics from [[Special:GadgetUsage]] ([[phab:T121049]])</comment>
      <origin>772344</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3781" sha1="hfkn1uz2cq2bl4h4o54hqlxnv28j7ju" xml:space="preserve">{{#ifexist:Project:GUS2Wiki/top|{{/top}}|This page provides a historical record of [[Special:GadgetUsage]] through its page history. To get the data in CSV format, see wikitext. To customize this message or add categories, create [[/top]].}}
Les données suivantes sont en cache et ont été mises à jour pour la dernière fois le 2026-09-16T07:05:04Z. {{PLURAL:5000|1=Un seul résultat|5000 résultats}} au maximum {{PLURAL:5000|est disponible|sont disponibles}} dans le cache.
{| class=&quot;sortable wikitable&quot;
! Gadget !! data-sort-type=&quot;number&quot; | Nombre d’utilisateurs !! data-sort-type=&quot;number&quot; | Utilisateurs actifs
|-
|AncreTitres || 34 || 1
|-
|ArchiveLinks || 13 || 1
|-
|Barre de luxe || 36 || 1
|-
|BoutonsLiens || 42 || 0
|-
|CategoryAboveAll || 21 || 2
|-
|CategorySeparator || 23 || 0
|-
|CoinsArrondis || 99 || 2
|-
|CollapseSidebox || 36 || 2
|-
|CouleurContributions || 33 || 1
|-
|CouleursLiens || 26 || 0
|-
|DeluxeAdmin || 6 || 2
|-
|DeluxeEdit || 36 || 1
|-
|DeluxeHistory || 46 || 1
|-
|DeluxeImport || 19 || 1
|-
|DeluxeRename || 16 || 1
|-
|DeluxeSummary || 37 || 3
|-
|DevTools || 18 || 1
|-
|DirectPageLink || 26 || 2
|-
|Emoticons || 45 || 1
|-
|EmoticonsToolbar || 46 || 1
|-
|FastRevert || 37 || 1
|-
|FixArrayAltLines || 23 || 1
|-
|FlecheHaut || 66 || 2
|-
|GoogleTrans || 28 || 0
|-
|HotCats || 81 || 6
|-
|JournalDebug || 22 || 1
|-
|JournalEnTable || 3 || 1
|-
|LeftPaneSwitch || 6 || 1
|-
|ListeABordure || 30 || 2
|-
|LiveRC || 30 || 1
|-
|LocalLiveClock || 27 || 2
|-
|Logo || 42 || 1
|-
|MobileView || 19 || 4
|-
|NavigAdmin || 39 || 1
|-
|OngletEditCount || 45 || 2
|-
|OngletEditZeroth || 67 || 2
|-
|OngletGoogle || 29 || 2
|-
|OngletPurge || 57 || 3
|-
|OptimizedSuivi || 18 || 0
|-
|Popups || 61 || 1
|-
|RenommageCategorie || 7 || 3
|-
|RestaurationDeluxe || 12 || 1
|-
|RevertDiff || 35 || 3
|-
|ScriptAutoVersion || 17 || 2
|-
|ScriptSidebox || 32 || 0
|-
|ScriptToolbar || 43 || 1
|-
|SisterProjects || 18 || 2
|-
|SkinPreview || 4 || 1
|-
|Smart patrol || 2 || 2
|-
|SourceLanguage || 24 || 1
|-
|SousPages || 57 || 4
|-
|SpaceToolbar || 30 || 1
|-
|TableUnicode || 56 || 1
|-
|Tableau || 67 || 1
|-
|TitreDeluxe || 56 || 2
|-
|TitreHierarchique || 17 || 0
|-
|UTCLiveClock || 27 || 1
|-
|UnicodeEditRendering || 29 || 2
|-
|WikEd || 30 || 0
|-
|autonum || 2 || 0
|-
|massblock || 3 || 1
|-
|monBrouillon || 20 || 2
|-
|perpagecustomization || 17 || 2
|-
|recentchangesbox || 15 || 0
|-
|searchFocus || 19 || 1
|-
|searchbox || 30 || 3
|}
* [[Spécial:GadgetUsage]]
* [[m:Meta:GUS2Wiki/Script|GUS2Wiki]]
&lt;!-- data in CSV format:
AncreTitres,34,1
ArchiveLinks,13,1
Barre de luxe,36,1
BoutonsLiens,42,0
CategoryAboveAll,21,2
CategorySeparator,23,0
CoinsArrondis,99,2
CollapseSidebox,36,2
CouleurContributions,33,1
CouleursLiens,26,0
DeluxeAdmin,6,2
DeluxeEdit,36,1
DeluxeHistory,46,1
DeluxeImport,19,1
DeluxeRename,16,1
DeluxeSummary,37,3
DevTools,18,1
DirectPageLink,26,2
Emoticons,45,1
EmoticonsToolbar,46,1
FastRevert,37,1
FixArrayAltLines,23,1
FlecheHaut,66,2
GoogleTrans,28,0
HotCats,81,6
JournalDebug,22,1
JournalEnTable,3,1
LeftPaneSwitch,6,1
ListeABordure,30,2
LiveRC,30,1
LocalLiveClock,27,2
Logo,42,1
MobileView,19,4
NavigAdmin,39,1
OngletEditCount,45,2
OngletEditZeroth,67,2
OngletGoogle,29,2
OngletPurge,57,3
OptimizedSuivi,18,0
Popups,61,1
RenommageCategorie,7,3
RestaurationDeluxe,12,1
RevertDiff,35,3
ScriptAutoVersion,17,2
ScriptSidebox,32,0
ScriptToolbar,43,1
SisterProjects,18,2
SkinPreview,4,1
Smart patrol,2,2
SourceLanguage,24,1
SousPages,57,4
SpaceToolbar,30,1
TableUnicode,56,1
Tableau,67,1
TitreDeluxe,56,2
TitreHierarchique,17,0
UTCLiveClock,27,1
UnicodeEditRendering,29,2
WikEd,30,0
autonum,2,0
massblock,3,1
monBrouillon,20,2
perpagecustomization,17,2
recentchangesbox,15,0
searchFocus,19,1
searchbox,30,3
--&gt;</text>
      <sha1>hfkn1uz2cq2bl4h4o54hqlxnv28j7ju</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc initiation/a512</title>
    <ns>0</ns>
    <id>80964</id>
    <revision>
      <id>772333</id>
      <parentid>772184</parentid>
      <timestamp>2026-09-17T06:34:33Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>772333</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3045" sha1="mv3nact8jab1uql7xewlxdsp828nsxy" xml:space="preserve">__NOTOC__ 
[[Catégorie:Mathc initiation (livre)]]

[[Mathc initiation/a522#Analyse IV : Se familiariser avec la Transformée de Laplace|Sommaire]]

'''L'étude de ce chapitre peut ce faire à l'aide de cette [[https://youtube.com/playlist?list=PLi6peGpf8EPP8YlloOLhIv5WflA0cpr5n&amp;si=n_rhSX0G-o18nxFY Playlist]].'''
:
.
:
* La transformée de Laplace va nous permettre de passer du domaine temporel (t) au domaine fréquentiel (s).

* La transformée de Laplace va transformer les fonctions trigonométriques, exponentielles, ... en fonctions algébriques (+,-,*).
 
* La transformée de Laplace ne fonctionne que sur les '''fonctions causales'''. 

[https://commons.wikimedia.org/wiki/File:Causal_function_with_gnuplot_and_C_language.png Une '''fonction causale'''] est une fonction qui ne prend sa valeur que quand t est supérieur à zéro. La fonction est nulle entre moins l'infini et zéro. 

Ceci se matérialise sur l'intégrale dont les bornes sont entre zéro et l'infini positif.

L'intégrale de la transformée de Laplace de F(t) :
 
              / +oo
             |
   L{F(t)} = |    exp(-s t) F(t) dt = f(s)
             |
            /  0
 
* Si G(t) est une fonction (sin, cos, exp, t^n, ...) alors :

F(t) = G(t) * U(t) est une fonction causale, ou '''U(t)''' est la fonction [[Mathc initiation/a579| '''Heaviside''']].

   U(t) = 0 si t &lt;  0
   U(t) = 1 si t &gt;= 0
   
Pour simplifier la lecture de ce texte j'ai remplacé systématiquement '''G(t) * U(t)''' par '''F(t)'''.

* La transformée de Laplace est un '''opérateur linéaire''' : 
     L{a F(t) + b G(t)}   = a L{F(t)} + b L{G(t)}
:
.
:
'''Se familiariser avec la transformée de Laplace : '''
{{Partie{{{type|}}}|[[Mathc initiation/a513|* la Transformée de Laplace : Première approche]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a520|* la Transformée de Laplace : Deuxième approche]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a536|* la Transformée de Laplace : Changement d'échelle]]}}
:
.
:
{{Partie{{{type|}}}|[[Mathc initiation/a528|* La transformée de Laplace de la dérivée]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a532|* La transformée de Laplace de la dérivée seconde]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a524|* La transformée de Laplace d'une intégrale]]}}

:
.
:
{{Partie{{{type|}}}|[[Mathc initiation/a559|* La transformée de Laplace : Multiplication par t^n]]}}
{{Partie{{{type|}}}|[[Mathc_initiation/a563|* La transformée de Laplace : Division par t]]}}
:
.
:
{{Partie{{{type|}}}|[[Mathc initiation/a540|* la Transformée de Laplace : Translation de la variable s]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a551|* la Transformée de Laplace : Translation de la variable t]]}}
:
.
:
'''Quelques rappels mathématiques  : '''
{{Partie{{{type|}}}|[[Mathc initiation/a566|* Trigonométriques. Trigonométriques hyperboliques]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a569|* Fractions partielles]]}}
:
.
:
{{Partie{{{type|}}}|[[Mathc initiation/006z|* la Transformée de Laplace : Théorème des valeurs initiales]]}}
:
.
:
{{AutoCat}}</text>
      <sha1>mv3nact8jab1uql7xewlxdsp828nsxy</sha1>
    </revision>
    <revision>
      <id>772336</id>
      <parentid>772333</parentid>
      <timestamp>2026-09-17T06:43:48Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>772336</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3045" sha1="nl3mwa9999636qtse4hpgixb07kjy0w" xml:space="preserve">__NOTOC__ 
[[Catégorie:Mathc initiation (livre)]]

[[Mathc initiation/a522#Analyse IV : Se familiariser avec la Transformée de Laplace|Sommaire]]

'''L'étude de ce chapitre peut ce faire à l'aide de cette [[https://youtube.com/playlist?list=PLi6peGpf8EPP8YlloOLhIv5WflA0cpr5n&amp;si=n_rhSX0G-o18nxFY Playlist]].'''
:
.
:
* La transformée de Laplace va nous permettre de passer du domaine temporel (t) au domaine fréquentiel (s).

* La transformée de Laplace va transformer les fonctions trigonométriques, exponentielles, ... en fonctions algébriques (+,-,*).
 
* La transformée de Laplace ne fonctionne que sur les '''fonctions causales'''. 

[https://commons.wikimedia.org/wiki/File:Causal_function_with_gnuplot_and_C_language.png Une '''fonction causale'''] est une fonction qui ne prend sa valeur que quand t est supérieur à zéro. La fonction est nulle entre moins l'infini et zéro. 

Ceci se matérialise sur l'intégrale dont les bornes sont entre zéro et l'infini positif.

L'intégrale de la transformée de Laplace de F(t) :
 
              / +oo
             |
   L{F(t)} = |    exp(-s t) F(t) dt = f(s)
             |
            /  0
 
* Si G(t) est une fonction (sin, cos, exp, t^n, ...) alors :

F(t) = G(t) * U(t) est une fonction causale, ou '''U(t)''' est la fonction [[Mathc initiation/a579| '''Heaviside''']].

   U(t) = 0 si t &lt;  0
   U(t) = 1 si t &gt;= 0
   
Pour simplifier la lecture de ce texte j'ai remplacé systématiquement '''G(t) * U(t)''' par '''F(t)'''.

* La transformée de Laplace est un '''opérateur linéaire''' : 
     L{a F(t) + b G(t)}   = a L{F(t)} + b L{G(t)}
:
.
:
'''Se familiariser avec la transformée de Laplace : '''
{{Partie{{{type|}}}|[[Mathc initiation/a513|* la Transformée de Laplace : Première approche]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a520|* la Transformée de Laplace : Deuxième approche]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a536|* la Transformée de Laplace : Changement d'échelle]]}}
:
.
:
{{Partie{{{type|}}}|[[Mathc initiation/a528|* La transformée de Laplace de la dérivée]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a532|* La transformée de Laplace de la dérivée seconde]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a524|* La transformée de Laplace d'une intégrale]]}}

:
.
:
{{Partie{{{type|}}}|[[Mathc initiation/a559|* La transformée de Laplace : Multiplication par t^n]]}}
{{Partie{{{type|}}}|[[Mathc_initiation/a563|* La transformée de Laplace : Division par t]]}}
:
.
:
{{Partie{{{type|}}}|[[Mathc initiation/a540|* la Transformée de Laplace : Translation de la variable s]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a551|* la Transformée de Laplace : Translation de la variable t]]}}
:
.
:
{{Partie{{{type|}}}|[[Mathc initiation/006z|* la Transformée de Laplace : Théorème des valeurs initiales]]}}
:
.
:
'''Quelques rappels mathématiques  : '''
{{Partie{{{type|}}}|[[Mathc initiation/a566|* Trigonométriques. Trigonométriques hyperboliques]]}}
{{Partie{{{type|}}}|[[Mathc initiation/a569|* Fractions partielles]]}}
:
.
:
{{AutoCat}}</text>
      <sha1>nl3mwa9999636qtse4hpgixb07kjy0w</sha1>
    </revision>
  </page>
  <page>
    <title>Les cartes graphiques/Avant les GPUs : les cartes accélératrices 3D</title>
    <ns>0</ns>
    <id>81913</id>
    <revision>
      <id>772303</id>
      <parentid>765166</parentid>
      <timestamp>2026-09-16T14:33:32Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* L'architecture d'une carte graphique 3D */</comment>
      <origin>772303</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="61181" sha1="qf04bvoqsah0hpd1vdky8r14m627n2z" xml:space="preserve">Dans le chapitre précédent, nous avons vu les bases du rendu 3D. Nous avons parlé de textures, de rastérisation, des calculs d'éclairage, et de bien d'autres choses. Vers la fin du chapitre, nous avons parlé des shaders, des programmes informatiques exécutés sur la carte graphique. Mais ils n'ont pas été toujours présents ! Les anciennes cartes graphiques faisaient sans shaders. Elles étaient autrefois appelées des '''cartes accélératrices 3D''', encore que la terminologie ne soit pas très précise.Nous les opposerons aux cartes graphiques capables d'exécuter des shaders, qui sont couramment appelées des '''Graphic Processing Units''', des GPUs.

L'introduction des shaders a grandement modifié l'architecture des cartes graphiques. Il a fallu ajouter des processeurs pour exécuter les shaders, qui n'étaient pas là avant. Par contre, les circuits déjà présents ont été conservés, intégrés aux processeurs de shaders, ou remplacés par ceux-ci. D'un point de vue pédagogique, il est préférable de voir les cartes accélératrices 3D, avant de voir comment elles ont évolués vers des GPUs. Et nous allons voir cela dans deux chapitres. Ce chapitre portera sur les cartes accélératrices 3D, sans shaders, alors que le suivant expliquera comment s'est passée la transition vers les GPUs.

: Nous allons nous concentrer sur les cartes graphiques à placage de texture inverse, le placage de texture direct ayant déjà été abordé dans le chapitre précédent.

==L'architecture d'une carte accélératrice 3D==

Une carte accélératrice 3D est un carte d'affichage à laquelle on aurait rajouté des circuits de rendu 3D. Elle incorpore donc tous les circuits présents sur une carte d'affichage : un VDC, une interface avec le bus, une mémoire vidéo, des circuits d’interfaçage avec l'écran, un contrôleur DMA, etc. Le VDC s'occupe de l'affichage et éventuellement du rendu 2D, mais ne s'occupe pas du traitement de la 3D. Du moins, c'est le cas sur les cartes à placage de texture inverse. Le placage de texture direct utilise au contraire un VDC avec accélération 2D très performant, comme nous l'avons vu au chapitre précédent. Mais nous mettons ce cas particulier de côté.

La carte accélératrice 3D reçoit des commandes graphiques, qui proviennent du pilote de la carte graphique, exécuté sur le processeur. les commandes en question sont très variées, avec des commandes de rendu 3D, de rendu 2D, de décodage/encodage vidéo, des transferts DMA, et bien d'autres. Mais nous allons nous concentrer sur les commandes de rendu 3D, qui demandent à la  carte accélératrice 3D de faire une opération de rendu 3D. Pour cela, elles précisent quel tampon de sommet utiliser, quelles textures utiliser, quels shaders sont nécessaires, etc.

La carte accélératrice 3D traite ces commandes grâce à deux circuits : des circuits de rendu 3D, et un chef d'orchestre qui dirige ces circuits de rendu pour qu'ils exécutent la commande demandée. Le chef d'orchestre s'appelle le '''processeur de commandes''', et il sera vu en détail dans quelques chapitres. Pour le moment, nous allons juste dire qu'il s'occupe de la logistique, de la répartition du travail. Pour les commandes de rendu 3D, il commande les différentes étapes du pipeline graphique et s'assure que les étapes s’exécutent dans le bon ordre.

[[File:Architecture globale d'une carte 3D.png|centre|vignette|upright=2|Architecture globale d'une carte 3D]]

Les circuits de rendu 3D regroupent des circuits hétérogènes, aux fonctions fort différentes. Dans le cas le plus simple, il y a un circuit pour chaque étape du pipeline graphique. De tels circuits sont appelés des '''unités de traitement graphique'''. On trouve ainsi une unité pour le placage de textures, une unité de traitement de la géométrie, une unité de rasterization, une unité d'enregistrement des pixels en mémoire appelée ROP, etc. Les anciennes cartes graphiques fonctionnaient ainsi, mais on verra que les cartes graphiques modernes font un petit peu différemment.

Pour simplifier les explications, nous allons séparer la carte graphique en deux gros circuits bien distincts. En réalité, ils sont souvent séparés en sous-circuits plus petits, mais laissons cela de côté pour le moment.
* Les '''unités géométriques''' pour les calculs géométriques ;
* Les '''pipelines de pixel''' qui rastérisent l'image, plaquent les textures, et autres.

Les unités géométriques manipulent des triangles, sommets ou polygones, donc des données géométriques. Les unités de pixel font tout le reste, mais le gros de leur travail est de manipuler des pixels ou des texels. Dans ce chapitre, on considère que les deux sont des circuits fixes, nous verrons leur évolution vers des processeurs programmables dans le prochain chapitre.

===Les circuits de traitement des pixels===

Parlons un peu plus en détail des pipelines de pixels. Pour mieux comprendre ce qu'elles font, il est intéressant de regarder ce qu'il y a dans un pipeline de pixel. Un pipeline de pixel effectue plusieurs opérations les unes à la suite, dans un ordre bien précis. Et cela explique l'usage du terme &quot;pipeline&quot; pour les désigner. Et ces opérations sont souvent réalisées par des circuits séparés, qui sont :
* Un '''rastériseur''' qui fait le lien entre triangles et pixels ;
* Une '''unité de texture''' qui lit les textures et les plaque sur les modèles 3D ;
* Un '''ROP''' (''Raster Operation Pipeline''), qui gère grossièrement le tampon de profondeur (''z-buffer'').

Le circuit de '''rastérisation''' prend en charge la rastérisation proprement dite. Pour rappel, la rastérisation projette une scène 3D sur l'écran. Elle fait passer d'une scène 3D à un écran en 2D avec des pixels. Lors de la rastérisation, chaque sommet est associé à un ou plusieurs pixels, à savoir les pixels qu'il occupe à l'écran. Elle fournit aussi diverses informations utiles pour la suite du pipeline graphique : la profondeur du sommet associé au pixel, les coordonnées de textures qui permettent de colorier le pixel.

L'étape de '''placage de texture''' lit la texture associée au modèle 3D et identifie le texel adéquat avec les coordonnées textures, pour colorier le pixel. On travaille pixel par pixel, on récupère le texel associé à chaque pixel. Soit l'inverse du placage de texture direct, qui traversait une texture texel par texel, pour recopier le texel dans le pixel adéquat.

Après l'étape de placage de textures, la carte graphique enregistre le résultat en mémoire. Lors de cette étape, divers traitements de '''post-traitement''' sont effectués et divers effets peuvent être ajoutés à l'image. Un effet de brouillard peut être ajouté, des tests de profondeur sont effectués pour éliminer certains pixels cachés, l'antialiasing est ajouté, on gère les effets de transparence, etc. Un chapitre entier sera dédié à ces opérations.

[[File:Unité post-géométrie d'une carte graphique sans elimination des surfaces cachées.png|centre|vignette|upright=1.5|Unité post-1.5éométrie d'une carte graphique sans elimination des surfaces cachées]]

===Les circuits d'élimination des pixels cachés===

L'élimination des surfaces cachées élimine les triangles invisibles à l'écran, car cachés par un objet opaque. En théorie, elle est prise en charge à la toute fin du pipeline, dans les ROPs, car cela permet de gérer la transparence. En effet, on ne sait pas si une texture transparente sera plaquée sur le triangle ou non. En clair, on doit éliminer les triangles invisibles après le placage de textures, et donc dans les ROP. Les ROPs se chargent à la fois de l’élimination des pixels cachées et de la transparence, les deux s’influençant l'un l'autre.

[[File:Unité post-géométrie d'une carte graphique avec elimination des surfaces cachées dans les ROPs.png|centre|vignette|upright=2|Unité post-géométrie d'une carte graphique avec élimination des surfaces cachées dans les ROPs]]

Il y a cependant des cas où on sait d'avance que les textures ne sont pas transparentes. Dans ce cas, la carte graphique utilise les circuits d'élimination des pixels cachés juste après la rastérisation. Cela permet d'éliminer à l'avance les triangles dont on sait qu'ils ne seront pas rendus.

[[File:Unité post-géométrie d'une carte graphique.png|centre|vignette|upright=2|Unité post-géométrie d'une carte graphique]]

Les deux possibilités coexistent sur les cartes graphiques modernes. Une carte graphique moderne peut éliminer les surfaces cachées avant et après la rastérisation, grâce à des techniques d''''''early-z''''' dont nous parlerons plus tard, dans un chapitre dédié sur la rastérisation.

===Les circuits d'éclairage===

Les explications précédentes décrivent une carte graphique qui ne gère pas les techniques d'éclairage, et nous allons remédier à cela immédiatement. L'éclairage a été pris en charge avant même l'arrivée des shaders, dès les années 2000. Par contre, les cartes accélératrices pour PC géraient uniquement l'éclairage par sommet. Elles utilisaient un circuit non-programmable, appelé le '''circuit de ''Transform &amp; Lightning''''', qui effectue les calculs d'éclairage par sommet (le L de T&amp;L), en plus des calculs de transformation (le T de T&amp;L). La première carte graphique à avoir intégré un circuit de T&amp;L était la Geforce 256, la Geforce 1. L'unité de T&amp;L a rapidement été remplacée par les ''vertex shader'', dont nous reparlerons d'ici quelques chapitres. Dès la Geforce 3, ce remplacement été effectué.

L'unité de T&amp;L calcule une couleur RGB pour chaque sommet/triangle, appelée la '''couleur de sommet'''. Une fois calculée par l'unité de T&amp;L, la couleur de sommet est envoyée à l'unité de rastérisation. L'unité de rastérisation calcule la couleur des pixels à partir des trois couleurs de sommet. Pour cela, il y a deux méthodes principales, qui correspondent à l'éclairage plat et l'éclairage de Gouraud, qu'on a vu dans le chapitre précédent. Les cartes accélératrices utilisaient généralement l'éclairage de Gouraud.

L'éclairage de Gouraud effectue une interpolation, à savoir une sorte de moyenne pondérée de la couleur des trois sommets. L'éclairage de Gouraud demande donc d'ajouter un circuit d'interpolation pour les couleurs des sommets. Il fait normalement partie du circuit de rastérisation, comme on le verra dans le chapitre dédié sur la rastérisation. Pour donner un exemple, la console de jeu Playstation 1 gérait l'éclairage de Gouraud directement en matériel, mais seulement partiellement. Elle n'avait pas de circuit de T&amp;L, ni de ''vertex shaders'', mais intégrait une unité de rastérisation qui interpolait les couleurs de chaque sommet.

Enfin, il faut prendre en compte les textures. Pour cela, le pixel texturé est multiplié par la luminosité/couleur calculée par l'unité géométrique. Il y a donc un '''circuit de combinaison''' situé après l'unité de texture qui effectue la combinaison/multiplication. Le circuit de combinaison est parfois configurable, à savoir qu'on peut remplacer la multiplication par une addition ou d'autres opérations. Un tel circuit de combinaison s'appelle alors un '''''combiner''''', dans la vieille nomenclature graphique de l'époque des années 90-2000.

[[File:Implémentation de l'éclairage par sommet avec des combiners.png|centre|vignette|upright=2|Implémentation de l'éclairage par sommet avec des combiners]]

Il a existé quelques rares cartes graphiques capables de faire de l'éclairage par pixel en matériel. Un exemple de carte graphique capable de faire cela est celle de la Nintendo DS, la PICA200. Créée par une startup japonaise, elle incorporait un circuit de T&amp;L, un éclairage de Phong, du ''cel shading'', des techniques de ''normal-mapping'', de ''Shadow Mapping'', de ''light-mapping'', du ''cubemapping'', de nombreux effets de post-traitement (bloom, effet de flou cinétique, ''motion blur'', rendu HDR, et autres).

Pour l'éclairage de Phong, il faut ajouter une unité qui fasse les calculs d'éclairage par pixel, et renvoie son résultat. La couleur de pixel calculée est ensuite combinée avec une texture, avec un ''combiner''. Du moins, si la carte accélératrice supporte les textures... Il faut aussi que le rastériseur interpole les normales, et non des couleurs de sommets comme avec l'éclairage de Gouraud. Les normales sont fournies par l'unité de T&amp;L, ce qui demande une modification assez importante des unités de T&amp;L et du rastériseur.

[[File:Implémentation de l'éclairage par pixel avec des combiners.png|centre|vignette|upright=2|Implémentation de l'éclairage par pixel avec des combiners]]

Voyons maintenant le ''bump-mapping'' et le ''normal-mapping''. Pour rappel, les deux dernières mémorisent des informations d'éclairage dans une texture en mémoire vidéo. La texture contient des informations de relief pour le ''bump-mapping'', des normales précalculées pour le ''normal-mapping''. Pour cela, l'unité d'éclairage par pixel doit être reliée à l'unité de texture, mais l'implémentation matérielle n'est pas aisée.

[[File:Normal mapping matériel.png|centre|vignette|upright=2|Normal mapping matériel]]

==Les cartes graphiques avec plusieurs unités parallèles==

Plus haut, nous avons décrit une carte graphique basique, très basique, avec seulement quatre unités. Une unité pour les calculs géométriques, un rastériseur, une unité pour les pixels/textures et un ROP. Cependant, les cartes graphiques ayant cette architecture sont très rares, pour ne pas dire inexistantes. Il n'est pas impossible que les toutes premières cartes graphiques aient suivi à la lettre cette architecture, mais même cela n'est pas sur. La raison : toutes les cartes graphiques dupliquent les circuits précédents pour gagner en performance, mais aussi pour s'adapter aux contraintes du rendu 3D.

===L'amplification des pixels et son impact sur les cartes graphiques===

Un triangle prend une certaine place à l'écran, il recouvre un ou plusieurs pixels lors de l'étape de rastérisation. Le nombre de pixels recouvert dépend fortement du triangle, de sa position, de sa profondeur, etc. Un triangle peut donner quelques pixels lors de l'étape de rastérisation, alors qu'un autre va couvrir 10 fois de pixels, un autre seulement trois fois plus, un autre seulement un pixel, etc. Le cas où un triangle ne recouvre qu'un seul pixel est rare, encore que la tendance commence à changer avec les jeux vidéos récents de la décennie 2020 utilisant l'Unreal Engine et la technologie Nanite.

La conséquence est qu'il y a plus de travail à faire sur les pixels que sur les sommets, ce qui a reçu le nom d''''amplification des pixels'''. La conséquence est qu'une unité géométrique prendra un triangle en entrée, l'enverra au rastériseur, qui fournira en sortie un ou plusieurs pixels à éclairer/texturer. Et cette règle un triangle = 1,N pixels fait qu'il y a un déséquilibre entre les calculs géométriques et ce qui suit, que ce soit le placage de textures, l'éclairage par pixel ou l'enregistrement des pixels dans le ''framebuffer''. Et ce déséquilibre a un impact sur la manière dont un conçoit une carte graphique, ancienne comme moderne.

S'il y a une seule unité de texture/pixels, alors le rastériseur envoie chaque pixel à texturer/éclairé un par un à l'unité de pixel. Le rastériseur produits ces pixels un par un, avec un algorithme adapté pour. L'unité géométrique attendra le temps que la rastérisation ait fini de traiter tous les pixels du triangle précédent. Elle calculera le prochain triangle pendant ce temps, mais cela ne fera que limiter la casse si beaucoup de pixels sont générés.

Mais il est possible de profiter de l'amplification des pixels pour gagner en performances. L'idée est que le rastériseur produit plusieurs pixels en même temps, qui sont envoyés à plusieurs unités de texture et d'éclairage par pixel. Un exemple est illustré ci-dessous, avec une seule unité géométrique, mais quatre unités de texture, quatre unités d'éclairage par pixel, et quatre ROPs. Le rastériseur est conçu pour générer quatre pixels d'un seul coup si nécessaire.

[[File:Architecture d'un GPU tenant compte de l'amplification des pixels.png|centre|vignette|upright=2.5|Architecture d'un GPU tenant compte de l'amplification des pixels]]

La carte graphique précédente a des performances optimales quand un triangle recouvre 4 pixels : tout est fait en une seule passe. Si un triangle ne recouvre que 1, 2 ou 3 pixels, alors le rastériseur produira 1, 2 ou 3 et certaines unités suivant le rastériseur seront inutilisées. Mais si un triangle recouvre plus de 4 pixels, alors les pixels sont générés, texturés, éclairés et enregistrés en RAM par paquets de 4. En clair, la carte graphique peut s'adapter à l'amplification des pixels, mais pas parfaitement. Les GPU récents ont résolu partiellement ce problème avec un système de ''shaders'' unifiés, mais qu'on ne peut pas expliquer pour le moment.

Pour donner un exemple du monde réel, les premières cartes graphique de l'entreprise SGI était de ce type. SGI a été une entreprise pinière dans le domaine du rendu en 3D, qui a opéré dans les années 80-90, avant de progressivement décliner et fermer. Elle a conçu de nombreux systèmes de type ''workstation'', donc destinés aux professionnels, avec des cartes graphiques dédiées. le grand public n'avait pas accès à ce genre de matériel, qui était très cher, vu qu'on n'était qu'au tout début de l'informatique. Nous ne détaillerons pas ces systèmes, car ils géraient leur mémoire vidéo d'une manière assez bizarre : elle était éclatée en plusieurs morceaux fusionnés chacun avec un ROP... Mais ils avaient tous une unité géométrique unique reliée à un rastériseur, qui alimentait plusieurs unités de texture/pixel et ROPs.

Plus proche de nous, certaines cartes graphiques pour PC étaient aussi dans ce cas. Les toutes premières cartes graphiques pour PC n'avaient même pas de circuits géométriques, et se contentaient d'un rastériseur, d'unités de texture et de ROPs. Par la suite, la Geforce 256 a introduit une unité géométrique appelée l'unité de T&amp;L. Les cartes graphiques de l'époque ont suivi le mouvement et ont aussi intégrée une unité géométrique presque identique. La Geforce 256 avait une unité géométrique, mais 4 unités de texture, 4 unités d'éclairage par pixel et 4 ROPs.

===Le multitexturing : dupliquer les unités de texture===

Le '''''multi-texturing''''' est une technique très importante pour le rendu 3D moderne. L'idée est de permettre à plusieurs textures de se superposer sur un objet. Divers effets graphiques demandent d'ajouter des textures par-dessus d'autres textures, pour ajouter des détails, du relief, sur une surface pré-existante. Un exemple intéressant vient des jeux de tir : ajouter des impacts de balles sur les murs. Pour cela, on plaque une texture d'impact de balle sur le mur, à la position du tir. Il s'agit là d'un exemple de ''decals'', des petites textures ajoutées sur les murs ou le sol, afin de simuler de la poussière, des impacts de balle, des craquelures, des fissures, des trous, etc.

Le ''multi-texturing'' implique que calculer un pixel implique de lire plusieurs textures. En général, un pixel avec ''multi-texturing'' demande de lire deux textures, rarement plus. La carte graphique doit alors être capable d'accéder à deux textures en même temps, ou du moins faire semblant que. De plus, elle doit combiner les deux textures pour générer le pixel voulu, ce qui demande d'ajouter un circuit qui combine deux texels (des pixels de texture) pour donner un pixel. La solution la plus simple est de doubler les unités de texture et de combiner les textures dans l'unité d'éclairage par pixel. Résultat : pour une unité d'éclairage par pixel, on a deux unités de textures.

La Geforce 2 et 3 utilisaient cette solution, dont le seul défaut est que la seconde unité de texture était utilisée seulement pour les objets sur lesquels le ''multi-texturing'' était utilisé. Les cartes ATI, le concurrent de l'époque de NVIDIA, aujourd'hui racheté par AMD, triplait les unités de texture. Mais cette possibilité était peu utilisée, la majorité des jeux se dépassant pas deux texture max par pixel. C'est sans doute pour cette raison que ce triplement a été abandonné à la génération suivante, les Radeon 9000 et 8500 se contentant de doubler les unités de texture.

{|class=&quot;wikitable&quot;
|-
! Nom de la carte graphique !! Unités géométriques !! Unité de texture !! Unités de pixel !! ROPs
|-
! Geforce 2 d'entrée de gamme
| 1 || 2 || 4 || 2
|-
! Geforce 2 milieu/haut de gamme, Geforce 3
| 1 || 4 || 8 || 4
|-
! Radeon R100 bas de gamme
| 1 || 1 || 3 || 1
|-
! Radeon R100 autres
| 1 || 2 || 6 || 2
|}

===L'usage de plusieurs unités géométriques===

Pour encore augmenter les performances, il est possible d'utiliser plusieurs circuits de calcul géométriques, plusieurs unités géométriques. Et ce peu importe que ces unités soient des processeurs ou des circuits fixes non-programmables. Et pour cela, il existe deux grandes implémentations : utiliser plusieurs processeurs placés en série, ou les mettre en parallèle. Comprendre la première implémentation demande de faire quelques rappels sur les calculs géométriques.

====L'usage d'un pipeline géométrique proprement dit====

Pour rappel, le pipeline géométrique regroupe les quatre étapes suivantes :
* L'étape de '''chargement des sommets/triangles''', qui sont lus depuis la mémoire vidéo et injectés dans le pipeline graphique.
* L'étape de '''transformation''' effectue deux changements de coordonnées pour chaque sommet.
** Premièrement, elle place les objets au bon endroit dans la scène 3D, ce qui demande de mettre à jour les coordonnées de chaque sommet de chaque modèle. C'est la première étape de calcul : l'''étape de transformation des modèles 3D''.
** Deuxièmement, elle effectue un changement de coordonnées pour centrer l'univers sur la caméra, dans la direction du regard. C'est l'étape de ''transformation de la caméra''.
* La phase d''''éclairage''' (en anglais ''lighting'') attribue une couleur à chaque sommet, qui définit son niveau de luminosité : est-ce que le sommet est fortement éclairé ou est-il dans l'ombre ?
* La phase d''''assemblage des primitives''' regroupe les sommets en triangles.
* Les phases de '''''clipping''''' ou le '''''culling''''' agissent sur des sommets/triangles/primitives, même si elles sont souvent regroupées dans l'étape de rastérisation.

Si on met de côté le chargement des sommets/triangles, il est possible de faire tous ces calculs en bloc, dans un seul processeur ou une seule unité de T&amp;L. Mais une autre idée, plus simple, attribue un processeur/circuit pour chaque étape. En faisant cela, on peut traiter plusieurs triangles/sommets en même temps, chacun étant dans une étape différente, chacun dans un processeur/circuit. Ceux qui auront déjà lu un cours d'architecture des ordinateurs reconnaitront la fameuse technique du pipeline, mais appliquée ici à un algorithme plus conséquent.

Les processeurs sont en série, et chaque processeur reçoit les résultats du processeur précédent, et envoie son résultat au processeur suivant. Sauf en début ou en bout de chaine, évidemment. Pour donner un exemple, les premières cartes graphiques de SGI utilisaient 10/12 processeurs enchainés l'un à la suite de l'autre. Les 4 premiers géraient les étapes de transformation, les 6 suivants faisaient les opérations de clipping/culling, les deux derniers faisaient la rastérisation proprement dite. 

Pour lisser les transferts de données, il est possible d'ajouter des mémoires FIFOs entre les processeurs. Comme ça, si un processeur est bloqué par un calcul un peu trop long, cela ne bloque pas les processeurs précédents. A la place, le processeur précédent accumule des résultats dans la mémoire FIFOs, qui seront consommé ultérieurement.

En théorie, on peut  s'attendre à ce que la performance soit multipliée par le nombre de processeurs. En réalité, les étapes sont rarement équilibrées, certaines étapes prennent beaucoup plus de temps que les autres, ce qui fait que la répartition des calculs n'est pas idéale : certains processeurs attendent que le processeur suivant ait finit son travail. De plus, l'organisation en pipeline entraine des couts de transmission/communication entre étapes, notamment si on utilise des mémoires FIFOs entre processeurs, ce qui est toujours le cas.

Cette implémentation n'a été utilisée que sur les toutes premières cartes graphiques, avant l'apparition des PC grand public. Les systèmes SGI, utilisés pour des stations de travail, utilisaient cette architecture, par exemple. Mais elle est totalement abandonnée depuis les années 90.

====L'usage de plusieurs unités géométriques en parallèle====

La seconde solution utilise plusieurs unités géométriques en parallèle. Chaque unité géométrique traite un triangle/sommet de bout en bout, en faisant transformation, éclairage, etc. Mais vu qu'il y en a plusieurs, on peut traiter plusieurs triangles/sommets : un dans chaque unité géométrique. C'est la solution retenue sur toutes les cartes graphiques depuis les années 90. Mais la présence de plusieurs unités géométriques a deux conséquences : il faut alimenter plusieurs unités géométriques en triangles/sommets, il faut gérer l'envoi des triangles au rastériseur. Les deux demandent des solutions distinctes.

La répartition du travail sur les unités géométriques est déléguée au processeur de commandes. Il utilise les unités géométriques à tour de rôle : on envoie le premier triangle à la première unité, le second triangle à la seconde unité, le troisième triangle à la troisième, etc. Il s'agit de ce que l'on appelle l''''algorithme du tourniquet''', qui est assez efficace malgré sa simplicité. Il marche assez bien quand tous les triangles/sommets mettent approximativement le même temps pour être traités. Si le temps de calcul varie beaucoup d'un triangle/sommet à l'autre, une solution toute simple détecte quels sont les processeurs de shaders libres et ceux occupés. Il suffit alors d'appliquer l'algorithme du tourniquet seulement sur les processeurs de shaders libres, qui n'ont rien à faire.

Un autre problème survient cette fois-ci en sortie des unités géométriques. Comment connecter plusieurs unités géométriques au reste de la carte graphique ? Évidemment, la carte graphique contient plusieurs unités de texture/pixel et plusieurs ROPs. Elle tient compte de l'amplification des pixels, ce qui fait qu'il y a moins d'unités géométriques que d'autres circuits, entre 2 à 8 fois moins environ. Pour créer une carte graphique avec plusieurs unités géométriques, il y a plusieurs solutions, que nous allons détailler dans ce qui suit. Pour les explications, nous allons prendre l'exemple de cartes graphiques avec 2 unités géométriques et 8 unités de texture/pixel, et autant de ROPs.

La première solution serait simplement de dupliquer les circuits précédents, en gardant leurs interconnexions. Pour l'exemple, on aurait 2 unités géométriques, chacune connectée à 4 unités de textures/pixels. L'unité géométrique est suivie par un rastériseur qui alimente 4 unités de texture/pixel, comme c'était le cas dans la section précédente. L'implémentation est alors très simple : on a juste à dupliquer les circuits et à modifier le processeur de commande. Il faut aussi modifier les connexions des ROPs à la mémoire vidéo. Mais les interconnexions avec le rastériseur ne sont pas modifiées.

Un désavantage est que l'amplification des pixels n'est pas gérée au mieux. Imaginez que l'on ait deux triangles à rastériser, qui génèrent 8 pixels en tout : un qui génère 6 pixels à la rastérisation, l'autre seulement 2. Il n'est pas possible de traiter les 8 pixels générés. Le triangle générant deux pixels va alimenter deux unités de texture/pixels et en laisser deux inutilisées, l'autre triangle sera traité en deux fois (4 pixels, puis 2). La duplication bête et méchante n'utilise donc pas à la perfection les unités de texture/pixel.

Une autre solution permet de gérer à la perfection l'amplification des pixels. Elle consiste à utiliser un seul rastériseur à haute performance, sur lequel on connecte les unités géométriques et les unités de texture/pixel. L'idée est que le rastériseur peut recevoir N triangles à la fois et alimenter M unités de texture/pixels. Le rastériseur unique s'occupe de faire plusieurs rastérisations de triangles à la fois, et répartit automatiquement les pixels générés sur les unités de texture/pixel. Pour donner un exemple, le GPU Geforce 6800 de NVIDIA avait 6 unités géométriques, 16 unités faisant à la fois placage de textures et éclairage par pixel, et 16 ROPs. Un point important avec ce GPU est qu'il n'avait qu'un seul rastériseur, détail sur lequel on reviendra dans ce qui suit !

==Les cartes graphiques en mode immédiat et à tuile==

Il est courant de dire qu'il existe deux types de cartes graphiques : celles en mode immédiat, et celles avec un rendu en tuiles (''tiles''). Il s'agit là des deux types principaux de cartes graphiques à l'heure actuelle, mais quelques architectures faisaient autrement dans le passé. Une autre classification, plus générale, sépare les cartes graphiques en cartes graphiques ''sort-last'', ''sort-first'' et ''sort-middle''. Les cartes graphiques en mode immédiat correspondent aux cartes graphiques en mode immédiat, alors que le rendu à tuile est une sous-catégorie des cartes graphiques ''sort-middle''.

La différence entre les deux est liée à la manière dont les pixels/primitives sont réparties sur l'écran. Leur existence est liée au fait que les API graphiques imposent que les triangles envoyées à la carte graphique soient traités dans l'ordre. Le tampon de sommets contient en effet une liste de sommets/triangles, qui sont censés être traités dans l'ordre d'arrivée. Et si je dis censé être, c'est parce que la carte graphique ne va pas forcément traiter les triangles/pixels dans l'ordre. 

A la place, elle va traiter des triangles/pixels en parallèle, et il n'est pas garantit que les résultats sortent des circuits dans l'ordre d'arrivée. Après tout, certains triangles sont traités plus rapidement que d'autres, idem pour les pixels. La carte graphique doit donc remettre les résultats dans l'ordre. L'endroit du pipeline où se fait cette remise en ordre est ce qui fait la différence entre cartes graphioques ''sort last'' et ''sort middle''.

===Les trois types de cartes graphiques : ''sort-first'', ''sort-middle'' et ''sort-last''===

Les cartes graphiques ''sort-first'' ont plusieurs pipelines séparés, chacun traitant une partie de l'écran. Ils déterminent la position des triangles à l'écran, puis répartissent les triangles dans les pipelines adéquats. Par exemple, on peut imaginer un GPU ''sort-first'' avec quatre unités séparées, chacune traitant un quart de l'écran. Au tout début du rendu, une unité de répartition détermine la position d'un triangle à l'écran, et l'envoie à l'unité adéquate. Si le triangle est dans le coin inférieur gauche, il sera envoyé à l'unité dédiée à ce coin. S'il est situé au milieu de l'écran, il sera envoyé aux quatre unités, chacune ne traitant les pixels que pour son coin à elle.

Les cartes graphiques ''sort-middle'' découpent l'écran en carrés de 4, 8, 16, 32 pixels de côté , qui sont rendus séparément les uns des autres. Les morceaux d'image en question sont appelés des ''tiles'' en anglais, mot que nous avons décidé de ne pas traduire pour ne pas le confondre avec les tuiles du rendu 2D. Il y a une assignation stricte entre une unité de pixel/texture et une ''tile''. Par exemple, sur un système avec deux unités de texture/pixel, la première unité traitera les ''tiles'' paires, l'autre unité les ''tiles'' impaires.

Les cartes graphiques ''sort-last'' sont l'extrême inverse. Ils ont des unités banalisées qui se moquent de l'endroit où se trouve un pixel à l'écran. Leurs unités géométriques traitent des polygones sans se préoccuper de leur place à l'écran. Le rastériseur envoie les pixels aux unités de textures/ROPs sans se soucier de leur place à l'écran. Encore que quelques optimisations s'en mêlent pour profiter au mieux des caches de texture et des caches intégrés aux ROPs, mais l'essentiel est qu'il n'y a pas de répartition fixe. Il n'y a pas de logique du type : ce pixel ou ce triangle est à tel endroit à l'écran, on l'envoie vers telle unité de texture/ROP. Ce sont les ROPs qui se chargent d'enregistrer les pixles finaux au bon endroit dans le ''framebuffer''. La gestion de la place des pixels à l'écran se fait donc à la toute fin du pipeline, d'où le nom de ''sort-last''.

Pour résumer, les trois types de cartes graphiques se distinguent suivant l'endroit où les triangles/pixels sont répartis suivant leur place à l'écran. Avec le ''sort-first'', ce sont les triangles qui sont triés suivant leur place à l'écran. Le tri a donc lieu avant les unités géométriques. Avec le ''sort-middle'', ce sont les fragments générés par la rastérisation qui sont triés suivant leur place à l'écran, d'où l'existence de ''tiles''. Le tri a lieu entre les unités géométriques et le rastériseur. Les unités géométriques se moquent de la place à l'écran des primitives qu'ils traitent, mais pas les rastériseurs et les unités de texture. Enfin, avec le ''sort-last'', ce sont les pixels finaux qui sont triés selon leur place à l'écran, seuls les ROPs se préoccupent de cette place à l'écran.

Concrètement, les cartes graphiques de type ''sort-first'' sont très rares, l'auteur de ce cours n'en connait aucun exemple. Les deux autres types de cartes graphiques sont eux beaucoup plus communs. Reste à voir ce qu'il y a à l'intérieur d'une carte graphique ''sort-middle'' et/ou ''sort-last''. Pour simplifier les explications, nous allons regrouper les circuits de traitement des pixels dans un seul gros circuits appelé le rastériseur, par abus de langage.  La carte graphique est donc composée de deux circuits : l'unité géométrique et le mal-nommé rastériseur. Les cartes graphiques ajoutent des mémoires caches pour la géométrie et les textures, afin de rendre leur accès plus rapide.

[[File:Carte graphique, généralités.png|centre|vignette|upright=2|Carte graphique, généralités]]

===Les cartes graphiques ''sort-last'', en mode immédiat===

Les cartes graphiques en mode immédiat implémentent le pipeline graphique d'une manière assez évidente. L'unité géométrique envoie des triangles au rastériseur, qui lui-même envoie les pixels à l'unité de texture, qui elle-même envoie le pixel texturé au ROP. Elles effectuent le rendu 3D triangle par tringle, pixel par pixel. Un point important est que pendant que le pixel N est dans les ROP, les pixels N+1 est dans l'unité de texture, le pixel N+2 est dans le rastériseur et le triangle suivant est dans l'unité géométrique. En clair, on n'attend pas qu'un triangle soit affiché pour en démarrer un autre.

Un problème est qu'un triangle dans une scène 3D correspond souvent à plusieurs pixels, ce qui fait que la rastérisation prend plus de temps de calcul que la géométrie. En conséquence, il arrive fréquemment que le rastériseur soit occupé, alors que l'unité de géométrie veut lui envoyer des données. Pour éviter tout problème, on insère une petite mémoire entre l'unité géométrique et le rastériseur, qui porte le nom de '''tampon de primitives'''. Elle permet d'accumuler les sommets calculés quand le rastériseur est occupé. 

[[File:Carte graphique en rendu immédiat.png|centre|vignette|upright=2|Carte graphique en rendu immédiat]]

Le tout peut s'adapter à la présence de plusieurs unités géométriques, de plusieurs unités de texture ou processeurs de shaders, tant qu'on conserve un rastériseur unique. Il suffit alors d'adapter le tampon de primitive et le rastériseur. Si on veut rajouter des unités de texture ou des processeurs de pixel shaders, le tampon de primitives n'est pas concerné : il suffit que le rastériseur ait plusieurs sorties, une par unité de texture/pixel shader. Par contre, la présence de plusieurs unités géométriques impacte le tampon de primitive.

Avec plusieurs unités géométriques, il y a deux solutions : soit on garde un tampon de primitive unique partagé, soit il y a un tampon de primitive par unité géométrique. Avec la première solution, toutes les unités géométriques sont reliées à un tampon de primitives unique. Le tampon de primitive est conçu pour qu'on puisse écrire plusieurs primitives dedans en même temps. Le rastériseur n'a pas à être modifié. Une autre solution utilise un tampon de primitive par unité géométrique. Le rastériseur peut alors piocher dans plusieurs tampons de primitive, ce qui demande de modifier le rastériseur. Il y a alors un système d'arbitrage, pour que le rastériseur pioche des primitives équitablement dans tous les tampons de primitive, pas question que l'un d'entre eux soit ignoré durant trop longtemps.

===Les cartes graphiques ''sort-middle'' des années 90===

Voyons maintenant les architectures ''sort-middle'' utilisée dans les années 80-90, à une époque où les cartes graphiques grand public n'existaient pas encore. Les cartes graphiques de l’entreprise SGI sont dans ce cas, mais aussi le Pixel Planes 5, et de nombreux autres systèmes graphiques. Elles utilisaient un rendu à ''tile'' assez original. Dans ce qui suit, nous allons décrire l'architecture des systèmes SGI, qui sont représentatifs.

L'idée était que l'image était découpée en un nombre de ''tiles'' qui variait selon le système utilisé, mais qui était au minimum de 5 et pouvait aller jusqu'à 20. Et chaque ''tile'' avait sa propre unité de traitement, qui contenait un rastériseur, une unité de texture, un ROP, etc. En clair, la carte graphique contenait entre 5 et 20 unités de traitement séparées, chacune dédiée à une ''tile''.

Les triangles sortant des unités géométriques étaient envoyés à toutes les unités de traitement, sans exception. Une fois le triangle réceptionné, l'unité de traitement déterminait si le triangle s'affichait dans la ''tile'' associée ou non. Si c'est le cas, le rastériseur rastérise le triangle, génère les pixels, les textures sont lues, puis le tout est enregistré en mémoire vidéo. Si ce n'est pas le cas, elle abandonne le polygone/triangle reçu. Si le triangle est partiellement dans la ''tile'', le rastériseur génère les pixels qui sont dans la ''tile'', par les autres.

Précisons que les cartes de ce style incorporaient un tampon de primitive, ce qui permettait de simplifier la conception de la carte graphique. Sur la carte ''Infinite Reality'', le tampon de primitive faisait 4 méga-octets de RAM, ce qui permettait de mémoriser 65 536 sommets. Sur la carte ''Reality Engine'', il y avait même plusieurs tampons de primitives, un par unité géométrique. Les polygones sortaient des unités géométriques, étaient accumulés dans les tampons de primitives, puis étaient ''broadcastés'' à toutes les unités de traitement. Pour cela, le bus en bleu dans le schéma précédent est en réalité un réseau ''crossbar'' avec un système de ''broadcast''.

Une caractéristique de ces architectures est qu'elles mettent le ''framebuffer'' à part de la mémoire vidéo. De plus, ce ''framebuffer'' est lui-même découpée en ''tile''. Sur la carte ''Reality Engine'', le ''framebuffer'' est découpé en 5 à 20 sous-''framebuffer'', un par ''tile''. Et chaque mini-''framebuffer'' est placé dans l'unité de traitement de la ''tile'' associée ! Ainsi, au lieu de connecter 5-20 ROPs à une mémoire vidéo unique, chaque ROP contient une '''''RAM tile''''', qui mémorise la ''tile'' en cours de traitement. Évidemment, cela pose quelques problèmes pour la connexion au VDC, en raison de l'absence de ''framebuffer'' unique, mais rien d'insurmontable. L'architecture est illustrée ci-dessous.

: Le Pixel Planes 5 avait un système similaire, mais avait en plus un ''framebuffer'' complet, dans lequel les sous-''framebuffer'' étaient recopiés pour obtenir l'image finale.

[[File:Architecture des premières cartes graphiques SGI.png|centre|vignette|upright=2|Architecture des premières cartes graphiques SGI]]

Un autre détail de l'architecture est lié à la mémoire pour les textures. Les concepteurs de SGI ont décidé de séparer les textures dans une mémoire à part du reste de la mémoire vidéo. Il n'y a pour ainsi dire pas de mémoire vidéo proprement dit : la géométrie à rendre est dans une mémoire à part, idem pour les textures, et pour le ''framebuffer''. On s'attendrait à ce que la mémoire de texture soit reliée aux 5-20 unités de texture, mais les concepteurs ont décidé de faire autrement. A la place, chaque unité de texture contient une copie de la mémoire de texture, qui est donc dupliquée en 5-20 exemplaires ! Difficile de comprendre la raison de ce choix, mais cela simplifiait sans doute les interconnexions internes de la carte graphique, au prix d'un cout en RAM assez important.

===Les cartes graphiques à rendu à ''tile''===

Les cartes graphiques de SGI, vus précédemment, disposent d'une unité de traitement par ''tile''. Faire ainsi permet de nombreuses optimisations, comme éclater le ''framebuffer'' en plusieurs ''RAM tile''. Mais le cout en matériel est conséquent. Pour économiser des circuits, l'idéal serait d'utiliser moins d'unités de traitement pour les pixels/fragments/textures. Mais pour cela, il faut profondément modifier l'architecture précédente. On perd forcément le lien entre une unité de traitement et une ''tile''. Et cela impose de revoir totalement la manière dont les unités géométriques communiquent avec les unités de traitement.

La solution retenue est celle des cartes graphiques à rendu en ''tile'' proprement dit, aussi appelés ''cartes graphiques TBR'' (''Tile Based Rendering''). Les plus simples n'utilisent qu'une seule unité de traitement et n'ont qu'une seule ''RAM tile''. En conséquence, les ''tiles'' sont rendues l'une après l'autre. Au lieu de rendre chaque triangle/polygone l'un après l'autre, la géométrie est intégralement rendue avant de faire la rastérisation. Les triangles sont enregistrés dans la mémoire vidéo et regroupés par ''tile'', avant la rastérisation. La mémoire vidéo contient donc plusieurs paquets de triangles, avec un paquet par ''tile''. Les paquets/''tiles'' sont envoyées au rastériseur un par un, la rastérisation se fait ''tile'' par ''tile''.

La ''RAM tile'' existe toujours, même si son utilité est différente. La ''RAM tile'' accélère le rendu d'une ''tile'', car tout ce qui est nécessaire pour rendre une ''tile'' est mémorisé dedans : la ''tile'', le tampon de profondeur, le tampon de stencil et plein d'autres trucs. Pas besoin d’accéder à un gigantesque z-buffer pour toute l'image, juste d'un minuscule z-buffer pour la ''tile'' en cours de traitement, qui tient totalement dans la SRAM.

: Il faut noter que les ''tiles'' sont généralement assez petites : 16 ou 32 pixels de côté, rarement plus. En comparaison, les ''tiles'' faisaient 128 pixels de côté pour les cartes de SGI.

[[File:Carte graphique en rendu par tiles.png|centre|vignette|upright=2|Carte graphique en rendu par tiles]]

Il est possible pour une carte graphique TBR de traiter plusieurs ''tiles'' en même temps, en parallèle, dans des unités séparées. Un exemple est celui du GPU ARM Mali 400, qui dispose d'une unité géométrique (un processeur de ''vertex''), mais 4 processeurs de pixels. Il peut donc traiter quatre ''tiles'' en même temps, chacune étant rendue dans un processeur de pixel dédié. Les 4 processeurs de pixels ont chacun leur propre ''RAM tile'' rien qu'à eux.

La présence d'une ''RAM tile'' a de nombreux avantages et impacte grandement l'architecture de la carte graphique. En premier lieu, les ROPs sont drastiquement modifiés. De nombreux GPU TBR n'ont même pas de ROPs ! A la place, les ROPs sont émulés par les processeurs de pixel shader. Les ''pixel shaders'' peuvent lire ou écrire directement dans le ''framebuffer'', sur les GPU TBR, ce qui leur permet d'émuler les ROPs avec des instructions mathématique/mémoire. Le ''driver'' patche automatiquement les ''pixel shader'' pour ajouter de quoi émuler les ROPs à la fin des ''pixel shaders''. Cela garantit une économie de circuits non-négligeable.

La présence d'une ''RAM tile'' fait que le tampon de profondeur disparait. Par contre, les cartes graphiques de type TBR doivent enregistrer les triangles en mémoire vidéo, et les trier par paquets. Cela compense partiellement, totalement, ou sur-compense, les économies liées à la ''RAM tile''. Le regroupement des triangles par ''tile'' s'accompagne de quelques optimisations assez sympathiques. Par exemple, les GPU TBR modernes peuvent trier les triangles selon leur profondeur, directement lors du regroupement en paquets. L'avantage est que cela permet à l'élimination des pixels cachés de fonctionner au mieux. L'élimination des pixels cachés fonctionne à la perfection quand les triangles sont triés du plus proche au plus lointain, pour les objets opaques. Les cartes graphiques en mode immédiat ne peuvent pas faire ce tri, mais les cartes graphiques TBR peuvent le faire, soit totalement, soit partiellement.

Un autre avantage est que l’antialiasing est plus rapide. Pour ceux qui ne le savent pas, l'antialiasing est une technique qui améliore la qualité d’image, en simulant une résolution supérieure. Une image rendue avec antialiasing aura la même résolution que l'écran, mais n'aura pas certains artefacts liés à une résolution insuffisante. Et l'antialiasing a lieu dans et après la rastérisation, et augmente la résolution du tampon de profondeur et du z-buffer. Les cartes graphiques en mode immédiat disposent d'optimisations pour limiter la casse, mais les ROP font malgré tout beaucoup d'accès mémoire. Avec le rendu en tiles, l'antialising se fait dans la ''RAM tile'', n'a pas besoin de passer par la mémoire vidéo et est donc plus rapide.

===Des compromis différents===

Les cartes graphiques des ordinateurs de bureau ou portables sont toutes en mode immédiat, alors que celles des appareils mobiles, smartphones et autres équipements embarqués ont un rendu en ''tiles''. Les raisons à cela sont multiples, mais la principale est que le rendu en ''tiles'' marche beaucoup mieux pour le rendu en 2D, comparé aux architectures en mode immédiat, ce qui se marie bien aux besoins des smartphones et autres objets connectés.

La performance d'une carte graphique est limitée par la quantité d'accès mémoire par seconde. Autant dire que les économiser est primordial. Et les cartes en mode immédiat et par tile ne sont pas égales de ce point de vue. En mode immédiat, le tampon de primitives évite de passer par la mémoire vidéo, mais le z-buffer et le ''framebuffer'' sont très gourmand en accès mémoire. Avec les architectures à tile, c'est l'inverse : la géométrie est enregistrée en mémoire vidéo, mais le tampon de profondeur n'utilise pas la RAM vidéo.

Au final, les deux architectures sont optimisées pour deux types de rendus différents. Les cartes à rendu en tile brillent quand la géométrie n'est pas trop compliquée, et que la résolution est grande ou que l'antialising est activé. Les cartes en mode immédiat sont douées pour les scènes géométriquement lourdes, mais avec peu d'accès aux pixels. Le tout est limité par divers caches qui tentent de rendre les accès mémoires moins fréquents, sur les deux types de cartes, mais sans que ce soit une solution miracle.

==La performance des anciennes cartes graphiques 3D==

Intuitivement, la performance d'une carte graphique dépend de la performance de chacun de ses circuits : processeur de commande, mémoire vidéo, circuits de rendu 3D, VDC, etc. En pratique, il est rare qu'on soit limité par le VDC ou le processeur de commande. Les seules limitations viennent des circuits de rendu 3D et de la mémoire vidéo.

Nous ne pouvons pas aborder la performance de la mémoire vidéo pour le moment. Tout ce que l'on peut dire est qu'il faut qu'elle soit assez rapide pour alimenter le rendu 3D en données. Les circuits de rendu 3D doivent lire des triangles et textures en mémoire vidéo, qui doit être assez rapide pour ça et ne pas les faire attendre. Pour le reste, voyons la performance des circuits de rendu 3D. 

Il ne nous est là aussi pas possible de détailler ce qui impacte la performance d'un GPU moderne. Dès que des processeurs de shaders sont impliqués, parler de performance demande de connaitre sur le bout des doigts les processeurs de shaders, ce qu'on n'a pas encore vu à ce stade du cours. Par contre, on peut détailler ce qu'il en était pour les anciennes cartes 3D, sans processeurs de shaders. Elles contenaient des ROPs, des unités de texture, un rastériseur et une unité géométrique (l'unité de T&amp;L).

Étudions d'abord la performance des unités de texture et des ROPs. Cela nous permettra de parler d'un paramètre qui avait son importance sur les anciennes cartes graphiques, avant les années 2000 : le ''fillrate''. Le '''''fill rate''''', ou taux de remplissage, est une ancienne mesure de performance autrefois utilisée pour comparer les cartes graphiques entre elles. Il s'agit d'une mesure assez approximative, au même titre que la fréquence d'horloge. Concrètement, plus il est élevé, meilleures seront les performances, en théorie. Mais attention : les petites différences de ''fillrate'' ne suffisent pas à rendre un verdict. De plus, il existe deux types distincts de ''fillrate'' : le ''Texture Fillrate'' et le ''Pixel Fillrate''. Voyons d'abord le ''Pixel Fillrate''.

===Le ''pixel fillrate'' : la performance des ROPs===

Le '''''pixel fillrate''''' est le nombre maximal de pixels que la carte graphique peut écrire en mémoire vidéo par seconde. Il est exprimé en ''Méga-Pixels par seconde'' ou en ''Giga-Pixels par seconde'', souvent abréviés en GP/s et MP/s. C'est une unité que vous croisez sans doute pour la première fois et qui mérite quelques explications.

Premièrement, dans méga-pixels par seconde, il y a mégapixels. Il s'agit d'une unité pour compter le nombre de pixels d'une image. Un mégapixel signifie tout simplement un million de pixels, un gigapixel signifie un milliard de pixels. Je précise bien un million et un milliard, ce ne sont pas des multiples de 1024, comme on est habitué à en voir en informatique. Le nombre de pixels d'une image augmente avec la résolution utilisée, mais il reste de l'ordre du mégapixel, guère plus. Voici un tableau avec les résolutions les plus utilisées et le nombre de pixels associé.

{|class=&quot;wikitable&quot;
|-
! Résolution !! Nombre de pixels
|-
| colspan=&quot;2&quot; | 
|-
| colspan=&quot;2&quot; | Résolutions anciennes en 4:3
|-
| 640 × 480 || 307 200 &lt;math&gt;\approx&lt;/math&gt; 0,3 MP
|-
| 800 × 600 || 480 000 = 0,48 MP
|-
| 1 024 × 768  || 786 432 &lt;math&gt;\approx&lt;/math&gt; 0,8 MP
|-
| 1 280 × 960 || 1 228 800 &lt;math&gt;\approx&lt;/math&gt; 1,2 MP
|-
| 1 600 × 1 200 || 1 920 000 = 1,92 MP
|-
| colspan=&quot;2&quot; | 
|-
| colspan=&quot;2&quot; | Résolutions modernes en 16:9
|-
| 1 920 × 1 080 || 2 073 600 &lt;math&gt;\approx&lt;/math&gt; 2 MP
|-
| 3 840 × 2 160 (4k) || 8 294 400 &lt;math&gt;\approx&lt;/math&gt; 8.3 MP
|}

Maintenant, regardons ce qui se passe si on veut rendre plusieurs images par secondes. Intuitivement, on se dit qu'il faudra un ''pixel fillrate'' minimal pour cela. Et il se trouve qu'on peut le calculer aisément. Prenons par exemple une image en 1600 × 1200, de 1,92 mégapixels. Si on veut avoir 60 images par secondes, avec cette résolution, cela fait 1,92 * 60 mégapixels par secondes. En clair, le ''pixel fillrate'' minimal se calcule en multipliant la résolution par le ''framerate''. Le ''pixel fillrate'' minimal tourne autour de la centaine de mégapixels par seconde, voire approche le gigapixel par seconde en haute résolution. Les images font entre 1 et 10 mégapixels, pour environ 100 FPS, l'intervalle colle parfaitement.

Maintenant, comparons un peu avec ce dont sont capables les GPUs. Les toutes premières cartes graphiques commerciales avaient un ''pixel fillrate'' proche de la centaine de méga-pixels par seconde. Pour donner un exemple, la Geforce 256 avait un ''pixel fillrate'' de 480 MP/s, la Geforce 3 faisait entre 700 et 960 MP/s selon le modèle. De nos jours, le ''pixel fillrate'' est de l'ordre de la centaine de Gigapixels. Pour donner un exemple, les Geforce RTX 5000 ont un ''pixel fillrate'' de 82.3GP/s pour la RTX 5050, à 423.6 GP/S pour la RTX 5090. Les GPU ont un ''pixel fillrate'' qui dépasse de très loin la valeur minimale, ce qui est franchement étrange.

La raison à cela est que le ''pixel fillrate'' minimal se calcule sous l'hypothèse que chaque pixel de l'image finale ne sera écrit qu'une seule fois. Mais dans les faits, il est fréquent qu'un pixel soit dessiné plusieurs fois avant d'obtenir l'image finale. La raison principale est liée aux surfaces cachées. Si un objet est derrière un autre, il arrive que celui-ci soit dessiné dans le ''framebuffer'', avant que l'objet devant soit re-dessiné par-dessus. Des pixels ont alors été écrits, puis ré-écrits.

Le fait de dessiner un pixel plusieurs fois porte un nom. Il s'agit d'un phénomène d''''''overdraw''''', ou sur-dessinage en français. Le sur-dessinage fait que le ''pixel fillrate'' minimal ne suffit pas en pratique. Pour éviter tout problème, le ''pixel fillrate'' du GPU doit être supérieur au ''pixel fillrate'' minimal, d'environ un ordre de grandeur. L'élimination des surfaces cachées réduit l'''overdraw'', mais elle ne fait pas de miracles. En pratique, le sur-dessinage ne concerne qu'une partie assez mineure des pixels de l'image, et un pixel est rarement écrit plus d'une dizaine de fois. Et les GPus modernes ont un ''pixel fillrate'' tellement démentiel qu'il n'est presque jamais un facteur limitant.

Le ''pixel fillrate'' d'un GPU dépend de plusieurs choses : le nombre de ROPs, leur fréquence d'horloge exprimée en MHz/GHz, la bande passante mémoire, et bien d'autres. En théorie, la bande passante mémoire n'est pas un point limitant, les concepteurs du GPU prévoient une mémoire suffisamment rapide pour qu'elle puisse encaisser le ''pixel fillrate'' maximal, tout en ayant encore de la marge pour lire des textures et la géométrie. En clair, le ''pixel fillrate'' est surtout dépendant des ROPs, de leur nombre, de leur vitesse, de leur implémentation.

Le ''pixel fillrate'' du GPU est difficile à calculer, mais l'approximation la plus utilisée est la suivante. Elle part du principe qu'un ROP peut écrire un pixel par cycle d'horloge. Ce n'est pas forcément le cas, tout dépend de l'implémentation des ROPs. Certains GPU performants ont des ROPs capables d'écrire des blocs de 8*8 pixels d'un seul coup en mémoire vidéo, alors que d'anciens GPU font avec des ROPs limités, seulement capables d'écrire un pixel tout les 10 cycles d'horloge. Toujours est-il qu'avec cette hypothèse, le ''pixel fillrate'' est égal au nombre de ROPs, multiplié par leur fréquence d'horloge.

Je précise &quot;leur&quot; fréquence d'horloge, car il est possible de faire fonctionner l'unité de T&amp;L, les ROPs, les unités de texture et le rastériseur à des fréquences différentes. C'est parfaitement possible, le cout en performance est parfois assez faible, mais le gain en consommation d'énergie est souvent important. Et justement, il a existé des GPU sur lesquels les ROPs avaient une fréquence inférieure à celle du reste du GPU. Dans ce cas, c'est la fréquence des ROPs qui est importante. Mais rassurez-vous : sur la majorité des GPUs actuels, les ROPs vont à la même fréquence que le reste du GPU.

===Le ''texture fillrate'' : la performance des unités de texture===

Le '''''texture fillrate''''' est l'équivalent du ''pixel fillrate'', mais pour les textures. Pour rappel, une texture est avant tout une image, composée de pixels. Pour éviter toute confusion, ces pixels de textures sont appelés ''des texels''. Le ''texture fillrate'' est le nombre de texels que la carte graphique peut plaquer par seconde, dans le meilleur des cas. Il est mesuré en mégatexels par secondes, voire en gigatexels par secondes.

L'interprétation de ce chiffre dépend de si on le mesure en entrée ou en sortie des unités de texture. En effet, les unités de texture intègrent des fonctionnalités de filtrage de texture, qui lissent les textures. Ces techniques lisent plusieurs texels et les mélangent pour fournir le texel final, celui envoyé aux unités de ''shader'' ou aux ROPs. La coutume est de le mesurer en sortie des unités de texture. Le nombre en entrée dépend grandement de la bande passante mémoire et du filtrage de texture utilisé, pas celui en sortie.

Le ''texture fillrate'' en sortie est le nombre maximal d'opérations de placage de texture par seconde. Là encore, on peut l'estimer en multipliant le nombre d'unités de texture par leur fréquence. Il s'agit évidemment d'une approximation assez peu fiable, car les unités de texture peuvent mettre plusieurs cycles pour plaquer une texture, les filtrer, etc.

Le ''texture fillrate'' est bien plus important que le ''pixel fillrate'', surtout pour les GPU modernes. Un point important est que le ''texture fillrate'' a longtemps été égal au ''pixel fillrate''. C'était le cas avant la Geforce 2 de NVIDIA. Les cartes graphiques avaient autant d'unités de texture que de ROP, et les deux fonctionnaient à la même fréquence. Les deux ont commencés à diverger quand le multi-texturing est arrivé, avec la Geforce 2, justement. Le nombre d'unités de texture a doublé comparé aux ROPs, ce qui fait que le ''texture fillrate'' est rapidement devenu le double du ''pixel fillrate''. Sur les GPU modernes, le ''texture fillrate'' est le triple, quadruple, voire octuple du ''pixel fillrate''.

===La performance de l'unité géométrique===

Pour l'unité géométrique, l'équivalent au ''fillrate'' est le '''''polygon throughput'''''. C'est nombre de sommets que l'unité géométrique peut traiter par seconde, exprimé en ''méga-sommets par secondes'', en millions de sommets par seconde. Il dépend de la fréquence et du nombre d'unités géométriques, mais n'est pas exactement le produit des deux. Il varie beaucoup d'une carte graphique à l'autre, mais une approximation souvent utilisée prend le quart du produit fréquence * nombre d'unités géométriques.

Il faut noter que cette mesure de performance a survécu à l'arrivée des shaders. Les GPU anciens, avant DirectX 10, avaient des processeurs séparés pour les ''vertex shaders'' et les ''pixel shaders''. Mais les calculs géométriques restaient séparés des autres calculs, ils avaient des unités géométriques dédiées. Quand les processeurs de shaders dit unifiés sont arrivés, la séparation entre géométrie et autres calculs a cédé et cet indicateur a simplement disparu.

===Les autres circuits===

Pour les autres circuits, il n'y a malheureusement pas d'indicateur de performance clair et net comme peut l'être le ''fillrate''. La raison à cela se comprend assez bien quand on regarde comment se calcule le ''fillrate''. C'est juste le produit de la fréquence et d'un nombre d'unités, en l’occurrence des unités de texture ou des ROPs. Le produit signifie que ces unités travaillent en parallèle et qu'elles peuvent chacune traiter un pixel/texel indépendamment des autres. Par contre, sur les anciens GPUs de l'époque, le rastériseur et l'unité géométrique sont un seul et unique circuit. Le nombre d'unité est donc égal à 1, et il ne nous reste plus que la fréquence.

&lt;noinclude&gt;
{{NavChapitre | book=Les cartes graphiques
           | prev=Le rendu d'une scène 3D : concepts de base
           | prevText=Le rendu d'une scène 3D : concepts de base
           | next=L'évolution vers la programmabilité : les GPUs
           | nextText=L'évolution vers la programmabilité : les GPUs
}}{{autocat}}
&lt;/noinclude&gt;</text>
      <sha1>qf04bvoqsah0hpd1vdky8r14m627n2z</sha1>
    </revision>
  </page>
  <page>
    <title>Wikilivres:Le Bistro/2026</title>
    <ns>4</ns>
    <id>83439</id>
    <revision>
      <id>772345</id>
      <parentid>772163</parentid>
      <timestamp>2026-09-17T08:51:19Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>/* Je ne suis donc pas content tous seul. */ nouvelle section</comment>
      <origin>772345</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="72891" sha1="2plbcw5xt4ov9hjt5m3v5rvnaq1roej" xml:space="preserve">&lt;noinclude&gt;{{Wikilivres:Le Bistro/En-tête}}&lt;/noinclude&gt;

== Le meilleur à Wikilivres pour 2026 ! ==

Je crée la page du bistrot 2026 en transmettant mes vœux. Bonne année éditoriale à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 janvier 2026 à 06:05 (CET)
:Merci, meilleurs vœux ! [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 16 janvier 2026 à 09:53 (CET)
::Meilleurs vœux pour 2026 !
::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 janvier 2026 à 20:13 (CET)
:::Meilleurs vœux pour 2026
:::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 janvier 2026 à 11:56 (CET)
::::Bonne année et bonnes lectures et écritures !
::::[[Utilisateur:Matthius|Matthius]]


== Page orpheline du livre : États généraux du multilinguisme dans les outre-mer ==

Bonjour,

Le livre &quot;États généraux du multilinguisme dans les outre-mer&quot; a laissé quelques pages orphelines. Ces pages orphelines ont été recopiées ou regroupé dans le texte du livre. Elles font donc doublons.

Je montre dans ce livre [[Wikilivres:Feuilles dupliquées orphelines]] cette suite de pages orphelines accompagnée par la page où elles ont été recopiées.

Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 10 février 2026 à 19:57 (CET)

:@[[Utilisateur:Xhungab|Xhungab]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], bonjour. Je vois que l'on est en campagne de gestion de pages orphelines et je me pose la question de savoir si on doit les supprimer une fois réintégrées ailleurs ou les supprimer ? Je vois que les deux cas de figure ont été mis en œuvre précédemment. L'avantage de la fusion est de conserver l'historique des modifications, mais je ne suis pas habitué à le faire. Si quelqu'un d'entre vous pouvait m'indiquer une page d'explication, cela m'aiderait à m'y mettre. Ensuite, je me demande si la fusion a vraiment un sens lorsque c'est la même personne qui a créé la page orpheline et la nouvelle au contenu copié collé pour insertion ? Qu'en pensez-vous ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:02 (CET)
:::Ça fait plaisir de voir une personne s'investir dans la maintenance de Wikilivres =). Soit le ou la bienvenu.e. J'attends les avis des autres administrateurs pour te donner mon soutien @[[Utilisateur:Xhungab|Xhungab]]. @ bientôt. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:27 (CET)
:::: @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]] bonjour, je n'ai pas compris en quoi &quot;deux cas de figure ont été mis en œuvre précédemment&quot; : si la page est vide on la supprime et si elle a au moins une phrase valable on la fusionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:26 (CET)
::::Concernant l'auteur pour moi cela importe peu, car on souhaite conserver chaque élément permettant de prouver une primauté du droit d'auteur (par exemple pour ne pas accuser un contributeur d'avoir copié un site miroir de sa page supprimée). [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:30 (CET)
:::::Désolé [[Utilisateur:JackPotte|JackPotte]], je n'avais pas vu que les pages que tu as supprimées étaient vides. La règle est donc supprimer si vide et fusionner si non. Tu peux me conseiller une page d'aide pour oppérer les fusions ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:34 (CET)
::::::Salut,
::::::Pour la fusion d'historique :
::::::* soit [[Wikilivres:Le guide de l'administrateur#Fusionner deux pages|Utiliser la page spéciale pour cela]] (cependant ne fonctionne pas toujours),
::::::* soit [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages utiliser l'ancienne méthode] qui reste toujours valable quand la première ne fonctionne pas.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 13 février 2026 à 19:34 (CET)
:::::::Salut @[[Utilisateur:DavidL|DavidL]]. Je viens de tester l'outil fusionner avec les deux pages suivantes
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes/Contexte]]
:::::::vers
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes]]
:::::::Et j'ai le message suivant :
:::::::« La période spécifiée chevauche les versions préexistantes de la page de destination. »
:::::::Tu peux m'expliquer si tu as le temps ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 00:19 (CET)
::::::::Salut @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]]
::::::::Dans ce cas, j'utilise [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages l'ancienne méthode].
::::::::# Renommer A (page qui n'existera plus) vers B, sans laisser de redirection, et en cochant la case de suppression de B (case qui apparait après 1er clic sur le bouton Renommer) (&amp;rarr; l'historique de A est sur B, celui de B est supprimé)
::::::::# Supprimer B (&amp;rarr; l'historique de A et B sont supprimés)
::::::::# Restaurer B et cocher toutes les cases des versions (bouton &quot;Inverser la sélection&quot;) (&amp;rarr; restaurer l'historique de A et B)
::::::::# Effectuer une modification de la version finale de la page à afficher, trouvée dans l'historique.
::::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 février 2026 à 08:29 (CET)
:::::::::Merci @[[Utilisateur:DavidL|DavidL]]. Ça m'a l'air bien compliqué tout ça. Et avec toute les pages qu'il faut faire, ça risque de prendre un certain temps. Je manque de courage en pensant que c'est juste pour ajouter une ligne dans l'historique des versions. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 14:51 (CET)
::::::::::Finalement, dans l'exemple que j'ai pris, la fusion n'avait aucun sens puisque le contenu du doublon que j'ai finalement supprimé était intégralement repris dans l'autre doublon par le même auteur. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 22 août 2026 à 23:55 (CEST)
:::::::::::Désolé @[[Utilisateur:Xhungab|Xhungab]]. Je ne comprends rien à l'outil de fusion et je ne trouve rien qui me permet de comprendre sur le net. Une vidéo avec exemple des différents cas de figure serait bien, mais je ne trouve pas. Je vais donc laisser ce travail à ceux qui savent utiliser l'outil.
:::::::::::En revanche, j'ai remarqué que certains doublons, comme dit précédemment, ne nécessitent pas de fusion puisqu'il s'agit de pages qui ont été créées sans aucune autre modification, puis, copiées par le même auteur dans une autre page créée avec un autre nom, au lieu de faire un renommage. Il faudrait donc que je prenne le temps de parcourir la liste pour repérer ces cas de figure avant de supprimer le premier doublon. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 01:27 (CEST)
::::::::::::Merci pour ton aide. Actuellement ces pages ont été en quelque sorte neutralisées. Donc fais de ton mieux, mais ne te tracasse pas elles ne posent plus de problème. Encore merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 09:13 (CEST)
:::::::::::::OK @[[Utilisateur:Xhungab|Xhungab]], merci pour l'info. Au fait comment as-tu fais pour les détecter ? En parcourant les pages de la catégorie orphelines et en vérifiant celles qui sont doublons ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 12:36 (CEST)
::::::::::::::Dans la catégorie pages orphelines, il y avait un lien sur une page.
::::::::::::::Je choisissais une phrase et je recherchais avec la fonction recherche de wikibook où se trouvait cette phrase. Si c'était un doublon, j'avais un lien vers la nouvelle page. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 12:48 (CEST)
:::::::::::::::Intelligent. Tu poserais pas ta candidature d'admin !? Ici, avec @[[Utilisateur:Fourmidable|Fourmidable]] et puis sur wikiversité aussi. Ça pourrait aider pour le projet des 20 ans., si tu comote toujours t'investir. On est en sous effectif dans les deux projects et les communautés me semblent plus ouverte que sur Wikipédia. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 13:48 (CEST)
::::::::::::::::Je ne souhaite pas devenir un administrateur. Pourquoi ? Si on me donne du pouvoir, je l'utiliserais. Par la suite, ceux qui m'ont accordé le pouvoir auront le choix entre pleurer, nous quitter ou me mettre en arrêt de travail. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 14:59 (CEST)
:::::::::::::::::Ah ah ah. T'es si foireux que ça !? Ou peut-être as-tu eu des expériences antérieures ? Dans tous les cas, c'est super de ta part de pouvoir t'auto évaluer.
:::::::::::::::::Ceci dit, le système de demander au administrateurs de faire des tâches qu'il faut expliquer est une perte de temps et d'efficacité. On pourrait d'ailleurs penser à attribuer les droits temporairement pour effectuer certaines tâches. Je me demande si ça se fait déja quelque part ? Si oui, on pourrait s'en inspirer pour mettre le système en application sur Wikilibres et Wikobersité. T'en penses quoi @[[Utilisateur:Xhungab|Xhungab]] ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 15:40 (CEST)
::::::::::::::::::Oui, je pourrais obtenir des droits temporaires par rapport à un projet. Par exemple 2 projets
::::::::::::::::::Premier projet :  Supprimer toutes les feuilles volantes. Ce sont des feuilles tests très bien faites mais qui n'appartiennent à aucun livre. Je crois qu'il y a actuellement, Feuilles volantes – 54 P. 
:::::::::::::::::: 
:::::::::::::::::: Deuxième projet : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Pages_anciennes Les pages les plus anciennement modifiées]
::::::::::::::::::Supprimer tous les livres entre 2006 et 2010 qui sont à l'abandon. Parfois il sera possible de sauvegarder un livre en supprimant les chapitres vides, ce qui nous permettra de créer un livre complet. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 16:19 (CEST)
Donc, tu as du temps à consacrer à ce genre de maintenance ? Ce serait bête de ne pas en profiter. Reste à voir à présent si les autres administrateurs et bureaucrates seraient d'accord de t'octroyer les droits, tout en approuvant les deux projets que tu proposes. Cependant, je ne suis pas un grand fan des suppressions, je préfère de loin renommer les pages pour les placer en dehors de l'espace principal de sorte à ce que les auteurs puissent toujours les retrouver. Pour ça, un bon espace, c'est les sous-pages des principaux auteurs. Cela pourrait ainsi s'appliquer aux feuilles volantes et aux projets d'écriture abandonnés qui sont suffisamment développés pour justifier une conservation. L'avantage de cette méthode est qu'elle ne demande pas d'avoir les outils d'administrateurs. Faudrait voir maintenant dans quel cas on supprime et dans quel cas on renomme. On pourrait par exemple définir un nombre d'octets ou de caractères, question d'avoir un critère standard et accepté par tous. Qu'en penses-tu [[Utilisateur:Xhungab|Xhungab]] ?
:En fait je préfère continuer comme actuellement. Proposer mes services  pour améliorer wikibook sans avoir aucun droit. De cette manière, si je propose quelque chose d'incongru, comme cela est déjà arrivé, il suffit de neutraliser ma demande. Merci à ceux qui me suivent sur ce travail.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 01:52 (CEST)

:Je comprends @[[Utilisateur:Xhungab|Xhungab]]. Mais précisément, déplacer une page à l'abandon dans une sous-page l'espace utilisateur de l'auteur principal, cela ne demande justement aucun droit et tout le monde peut le faire, toi en premier puisque tu sembles actif à ce niveau. C'est pour ça que je te demande ton avis : que penses-tu de l'idée de déplacer les pages comme je viens de le décrire, plutôt que de les supprimer ? Je viens de soumettre l'idée dans une nouvelle discussion ci-dessous. Tu peux donner ton avis là-bas si tu veux. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 02:27 (CEST)

== archive.today ==
''Voir [[:w:Wikipédia:Le Bistro/21 février 2026#archive.today]].''

Ce site pose apparemment des problèmes de sécurité, il faudrait le remplacer au plus vite si possible, et sinon désactiver les liens.

[[Utilisateur:SyntaxTerror|SyntaxTerror]] ([[Discussion utilisateur:SyntaxTerror|discussion]]) 21 février 2026 à 13:07 (CET)
:Salut SyntaxTerror,
:* 0 liens vers archive.today : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.today]
:* &lt;s&gt;18&lt;/s&gt; 0 liens vers archive.is [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.is]
:* 0 liens vers archive.li [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.li]
:* 0 liens vers archive.ec [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ec]
:* 0 liens vers archive.ph [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ph]
:* 0 liens vers archive.fo [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.fo]
:* 0 liens vers archive.md [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.md]
:* &lt;s&gt;1&lt;/s&gt; 0 liens vers archive.vn [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.vn]
:* 0 liens vers archive.closed.social [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.closed.social]
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 21 février 2026 à 16:14 (CET)
::Merci pour vos efforts ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:22 (CEST)

== demande aide pour sortir du mode &quot;ébauche&quot; ==

je viens de terminer mon livre ... ci dessous. J'ai compris qu'il fallait le signaler comme n'étant plus au stade &quot;ébauche&quot;  commente faire   Merci

https://fr.wikibooks.org/w/index.php?title=Essai_pour_un_mod%C3%A8le_de_psychisme_objectif&amp;action=info#mw-pageinfo-header-basic [[Utilisateur:Clopeau|Clopeau]] ([[Discussion utilisateur:Clopeau|discussion]]) 17 mars 2026 à 08:20 (CET)
:Bonjour, quand je regarde ''[[Essai pour un modèle de psychisme objectif]]'', sa complétude permettrait en effet de le sortir des ébauches, mais il semble plutôt d'agir d'un travail de recherche que d'un livre pédagogique sur un sujet sourcé comme reconnu.
:Donc en vertu de [[Wikilivres:Principes fondateurs|notre charte]], je propose de le déplacer sur {{WV|Recherche:Accueil}}. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 18 mars 2026 à 09:06 (CET)

== Don à wikipédia depuis wikilivres ==

{{BlocCitation|La Wikimedia Foundation est l’organisation à but non lucratif qui soutient Wikipédia, '''les autres sites de connaissance libre de Wikimédia''', et sa mission de connaissance libre pour tous.|auteur=[https://wikimediafoundation.org/fr/give/donor-frequently-asked-questions/ FAQ], {{g|Qu'est-ce-que la Wikimedia Foundation ?}}}}
Le lien de donation https://donate.wikimedia.org/w/index.php?title=Special:LandingPage&amp;country=FR&amp;uselang=fr&amp;wmf_medium=sidebar&amp;wmf_source=donate&amp;wmf_campaign=fr.wikibooks.org '''ne parle que de wikipédia'''. '''Où sont passés les autres projets ?''' Vont-ils être fermés sauvagement par la fondation comme Wikinews récemment ? La suite au prochain épisode d{{'}}''Highlander-Wikimedia'' : {{g|À la fin, un seul ''projet'' survivra.}} ... &amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 12 mai 2026 à 11:26 (CEST)

:Bonjour,
:Je pense personnellement que les wikis ont des problèmes.
:Il y a une vingtaine d'années, il représentait l'innovation la plus ambitieuse.
:Aujourd'hui, les wikis me semblent dépassés de tous les côtés.
:           wiki = Erreurs 404 (&quot;Page introuvable&quot;)
:Problèmes:
:* 568 livres déclarés. 50 livres terminés (combien sont obsolètes)
:* 21 527 pages déclarées. 20 000 pages orphelines. (Papa t'est où?)
:Solution:
:* Où sont les cours sur YouTube qui utilisent un wikibook comme référence?
:Voilà mon idée sur les wiki.
:* https://fr.wikiversity.org/wiki/Facult%C3%A9:Droit
:* https://fr.wikiversity.org/wiki/D%C3%A9partement:Introduction_au_droit
:&lt;nowiki&gt;~~~~&lt;/nowiki&gt; [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 12 mai 2026 à 13:50 (CEST)
::Ce serait intéressant de mentionner tous les projets actifs oui. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:23 (CEST)
::: En même temps, le message est plutôt franc étant donné que l'argent des dons n'est pas investi dans le développement de Wikilivres (cf [[:meta:Community Wishlist Survey]] et les réponses à nos tickets Phabricator).
::: Par ailleurs, concernant la qualité des contenus, cela a toujours était un sujet depuis le début, et nous disposons tout de même de plusieurs pages spéciales dans [[Wikilivres:Maintenance]] pour y remédier afin que le lecteur n'ait pas la sensation de se faire empapaouter en se retrouvant sur des ébauches bien placées dans Google. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mai 2026 à 08:48 (CEST)

== La catégorie SI est pleine ! ==

Bonjour tous,

Pour info, la [[:Catégorie:Suppressions immédiates demandées]] contient 9 pages.

Wikilivresquement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 14 juin 2026 à 15:36 (CEST)

:Elle est maintenant vide, merci à ceux qui s'y sont collés ! {{Sourire}} [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 24 juin 2026 à 17:17 (CEST)

== Un RAW bien frais pour juillet ==

{| style=&quot;width:100%;&quot;
| valign=&quot;top&quot; align=&quot;center&quot; style=&quot;border:1px gray solid; padding:1em;&quot; |
{| align=&quot;center&quot;
|-
| style=&quot;text-align: center;&quot; | &lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:4.5em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em;text-align:center; color: #fff; font-style:italic;&quot;&gt;Regards sur l’actualité du mouvement Wikimédia.&lt;/div&gt;
&lt;div style=&quot;text-align: center;&quot;&gt;{{#ifeq:{{FULLPAGENAME}}|Wikipédia:RAW/Rédaction}}&lt;/div&gt;
&lt;/div&gt;&lt;br /&gt;
&lt;hr /&gt;
&lt;div style=&quot;font-size:12pt; font-family:Times New Roman; text-align:center;&quot;&gt;[[w:fr:Wikipédia:RAW/2026-07-05|&lt;span style=&quot;color:darkslategray;&quot;&gt;Le numéro de juillet 2026 est sorti.&lt;/span&gt;]]&lt;/div&gt;
&lt;hr /&gt;&lt;br /&gt;

|- style=&quot;text-align: center;&quot;
| &lt;span style=&quot;font-size:12pt; font-family:Times New Roman;&quot;&gt; '''❖ Au menu de ce numéro ❖'''&lt;/span&gt;
|- style=&quot;font-size:10pt; font-family:Times New Roman; text-align:center;&quot;
| &lt;div style=&quot;text-align:center; column-count:1; column-width:28em; vertical-align:top;&quot;&gt;

'''L'Édito'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Édito|Fêtons notre mouvement !]]

'''Échos francophones'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Résidence|Un nouveau vigneron dans la résidence]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Logo_WP25|Wikipédia en français aux couleurs des 25 ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#DAF|Wikipédia dans le ''Dictionnaire de l'Académie française'']]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Millésime_Wiktionnaire|Quelles sont les nouvelles entrées en français sur le Wiktionnaire ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ADS|Relance de l'Article de la semaine]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#sans_pagEs|Le projet des sans pagEs fête ses dix ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#contributions_rémunérées|Faut-il faire évoluer les règles sur les contributions rémunérées ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#wikification|Le mois de la wikification fait son retour pour une septième édition]]

'''Ailleurs dans le mouvement'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Txikipedia|Txikipedia franchit le cap des 10 000 articles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Concours_santé_2026|Un concours sur la santé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Commons_et_IA|Commons se penche sur l'IA]]

'''Nouveautés techniques et outils'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#VIZWP|VIZWP : un outil pour visualiser les lacunes dans les sujets climatiques sur Wikipédia, mais pas que…]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#AI_Source_Verification|Examiner la vérifiabilité grâce à l'IA ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Icônes|Les icônes de l'interface ont changé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Sous-références|Ça y est, les sous-références sont là]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ConvoCompass|ConvoCompass, pour moins d'attaques personnelles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LSV-Tools|LSV-Tools : faciliter la gestion des anecdotes « Le saviez-vous ? »]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LegendAndDot|Semi-automatiser l'ajout de ponctuation dans les légendes d'images]]

'''Du côté de la recherche'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#COMSAV|COMSAV : la contribution à Wikipédia fait-elle d'un ensemble d'individus un ensemble de pairs ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#JourneyMap|Où commence la contribution et où s'arrête-t-elle ?]]

'''Le POV'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Le_POV|Guide survie pour la Wikimania 2026]] par Trizek

'''L'Atelier'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Atelier|Le point sur la diversité de genre dans les articles]] par PAC2

'''L'Analyse'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Analyse|Larry Sanger is back... and fired!]] par Madelgarius, Trizek et Jules*

'''L'interview'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'interview|Pronoia : de Byzance aux réseaux sociaux, un œil sur Wikipédia et le monde]] par Antimuonium

'''Le wik’hit-parade'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Wikit|Articles les plus vus en juin 2026]] par Ælfgar

&lt;/div&gt;
|-
| style=&quot;font-family:Times New Roman; text-align:center; font-size:90%;&quot; | [[w:fr:Wikipédia:RAW/2026-07-05|Lire tout le numéro]]
|-
| valign=&quot;top&quot; colspan=&quot;2&quot; style=&quot;padding:0.5em; font-family:Times New Roman;text-align:center; font-size:100%;&quot; |
Venez rédiger le prochain numéro, y parler de ce qui se fait dans votre communauté : [[w:fr:Discussion_Wikipédia:RAW/Rédaction|Salle de rédaction]].&lt;/br&gt;Les anciens numéros sont retrouvables [[w:fr:Modèle:Palette RAW|ici]].
|-
|}
|}
&lt;div style=&quot;margin-top:10px; font-size:90%; padding-left:5px; font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif;&quot;&gt;[[w:fr:Wikipédia:RAW/Inscription|Abonnez-vous !]] [[Utilisateur:L&amp;#39;embellie|L&amp;#39;embellie]] ([[Discussion utilisateur:L&amp;#39;embellie|discussion]]) 5 juillet 2026 à 01:53 (CEST)&lt;/div&gt;

== Les RAW en mode fiesta sur la Wikimania ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro d'août 2026 (n°295) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-08-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;&lt;/div&gt;

'''Un numéro exceptionnel'''

La conférence Wikimania s'est achevée le 25 juillet. Que vous ressentiez de la frustration (si vous n’avez pas pu y assister) ou du [[:w:Wikipédia:Wikispleen|wikispleen]] (si vous y étiez et que vous avez du mal à digérer que ce soit déjà fini), l’équipe des RAW n’a pas ménagé ses efforts pour vous proposer un numéro XXL qui revient en long, en large et en travers sur cet événement qui le mérite bien. Comptes-rendus, témoignages, entretiens, il y en aura pour tous les goûts ! Le numéro est aussi exceptionnel par le nombre de rédactrices et de rédacteurs qui y ont participé {{incise|merci !|stop}} 

Au-delà de Wikimania, l’actualité wikimédienne est loin d’être paisible cet été. Nous vous proposons donc aussi de revenir en détail sur la crise qui secoue la fondation Wikimédia autour de la reconnaissance du syndicat Wiki Workers United (WWU). Nous aurons probablement l’occasion de couvrir la suite de cette histoire dans le prochain numéro. D’ici là, bonne lecture !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia et des nouveaux outils

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Dossier spécial Wikimania&lt;/span&gt;'''

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les POV&lt;/span&gt;'''&lt;br&gt;— Ma Wikimania : la joie, l'inquiétude et la raison d'être&lt;br&gt;— Témoignages : regards sur la Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;L'Analyse&lt;/span&gt;''' — La crise s'intensifie après le refus de la WMF de reconnaître le syndicat WWU

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Comptes-rendus&lt;/span&gt;'''&lt;br&gt;— Une Wikimania sous le signe de la jeunesse&lt;br&gt;— Sur les conséquences de la définition de « wikimédien·ne »&lt;br&gt;— Petit tour d’horizon de la créativité wikimédienne&lt;br&gt;— CultureStrong : respecter les savoirs des Premières Nations sur les plateformes Wikimédia&lt;br&gt;— Des événements techniques à Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Interviews&lt;/span&gt;'''&lt;br&gt;— Ses goûts, sa Wikimania, sa prochaine tournée... : Baby Globe nous dévoile tout !&lt;br&gt;— Jules*, notre Wikimédien de l'année : comment rendre compte du changement climatique tout en protégeant l'encyclopédie

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : si un sujet vous tient à cœur, n'hésitez pas à proposer une idée d'article ou à participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]]. Toutes les contributions sont les bienvenues, quel que soit votre wiki d'origine ! &lt;span class=&quot;smiley&quot;&gt;[[Image:Face-smile.svg|20px|Sourire|alt=Émoticône sourire]]&lt;/span&gt;

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 août 2026 à 00:28 (CEST)

== Bientôt les 20 ans de Wikiversité ==

Bonjour.

Un petit message de « débauchage » dans le cadre d'un projet d'amélioration de Wikiversité. Comme dit la chanson : « On n'a pas tous les jours vingt ans ! » Plus d'infos [[v:Wikiversité:La_salle_café/août_2026#Améliorer_Wikiversité_pour_ses_vingt_ans_d'existence|dans la salle café du projet]].

Belle fin de journée à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 août 2026 à 00:26 (CEST)

== [[:Catégorie:Suppressions immédiates demandées|Série de demandes de suppression immédiate]] ==

Bonjour,

La [[:Catégorie:Suppressions immédiates demandées]] est de nouveau pleine, mais cette fois, il semble qu'elle ait été remplie par le seul {{U|Xhungab}}.

Cordialement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 16 août 2026 à 14:56 (CEST)
:{{fait}} Bonjour, oui c'était effectivement un ensemble d'ébauches abandonnées. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 17 août 2026 à 10:38 (CEST)
::Merci pour votre aide [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 août 2026 à 14:26 (CEST)

== Deux idées à débattre ==

Bonjour.

Vu le travail de traitement des pages et livres abandonnés et suite à une discussion avec @[[Utilisateur:Xhungab|Xhungab]] reprise ci-dessous, j'aimerais soumettre deux idées à la communauté Wikilivres.

'''La première idée''' est de déplacer toutes les pages et livres dont le développement est abandonné depuis longtemps en sous-page de l'auteur principal tout en laissant un message sur sa page de discussion avec un lien pointant vers la sous-page en question. Ce message pouvant faire l'objet d'un modèle.

Avantage : 1. Pas besoin d'être admin pour faire ce genre de maintenance. 2. Pas de risque de frustrer un auteur ni de perdre de vue des informations intéressantes. 3. Ceci dans le but d'améliorer l'apparence de Wikilivres au niveau du contenu visible sur l'espace de nom principal.

Nécessité : 1. Créer un modèle à placer sur la page de discussion de l'auteur principal après déplacement. 2. Définir la durée d'abandon des pages à déplacer.

'''La deuxième idée''' est de donner les outils d'administrateurs à des personnes qui ne veulent pas endosser cette responsabilité à long terme et de manière continue, mais qui sont d'accord d'en faire usage dans le cadre d'un projet de maintenance temporaire. Cela pourrait être utile pour @[[Utilisateur:Fourmidable|Fourmidable]] s'il le souhaite, à moins qu'il se décide à déposer sa candidature pour une nomination définitive. Ce qui serait une bonne idée, je trouve.

Qu'en pensez-vous @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Grondin|Grondin]] ?

Une prise de décision est-elle nécessaire si on décidait une mise en application ?

Bien à vous tous,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 01:50 (CEST)

:Bonjour,
:J'ai proposé une liste de livres à supprimer
:https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate
:Doit-on réellement les garder ? ;) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 10:21 (CEST)
::Quel est l'avantage de la suppression par rapport au déplacement @[[Utilisateur:Xhungab|Xhungab]]? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:56 (CEST)
:::En déterminant un contenu minimum, on peut faire le tri de ce que l'on supprime et ce que l'on déplace. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:58 (CEST)
::::Bonjour,
::::Les droits administrateurs temporaires sont difficiles à gérer : un bureaucrate peut attribuer le status administrateur mais pas le retirer.
::::Concernant les critères suppression ou renommage, je propose :
::::* (cas 1) Une page qui ne contient vraiment aucun texte (ex : seulement des liens rouges) --&gt; suppression
::::* (cas 2) Une page avec quelques phrases significatives récupérables --&gt; soit (a) tenter de fusionner dans un livre qui aborde le même sujet ou sujet connexe, soit (b) renommer en sous-page de l'auteur si aucun livre pour la fusion ne convient
::::* (cas 3) Une page avec plus de contenu que (cas 2) --&gt; conserver
::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 24 août 2026 à 19:33 (CEST)
:::::Salut @[[Utilisateur:DavidL|DavidL]]. Oui, c'est raisonnable. Reste que la fusion, c'est compliqué. J'ai essayé, mais je ne comprends rien. Une vidéo m'aiderait à comprendre, mais j'en ai pas trouvé. Ensuite, si on garde, genre un livre abandonné depuis plus de trois ans avec un chapitre entamé sur cinq prévus, par exemple, on le laisse dans l'espace principal, ou on le déplace vers l'espace utilisateur de l'auteur ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 25 août 2026 à 00:38 (CEST)
::::::Pour ce cas je propose de le fusionner si possible, comme (cas 2)(a) ; sinon le conserver, comme (cas3) afin qu'un utilisateur motivé puisse reprendre le livre.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 25 août 2026 à 08:36 (CEST)
:::::::Ok. Es-tu à l'aise avec la fusion @[[Utilisateur:DavidL|DavidL]] ? Car c'est une solution intéressante, mais je n'y arrive pas. Il y a toujours un message que je ne comprends pas et suite à quoi je préfère arrêter. Serais-tu dispo pour m'expliquer comment faire durant un appel vidéo ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:30 (CEST)
::::::::Bonjour {{Mention|Lionel Scheepmans}}, je suis très favorable à tes deux idées ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 août 2026 à 15:39 (CEST)
:::::::::Ok @[[Utilisateur:Fourmidable|Fourmidable]], je me dis qu'il serait encore bien d'avoir les avis de @[[Utilisateur:JackPotte|JackPotte]], voir de @[[Utilisateur:Grondin|Grondin]], s'ils trouvent le temps nécessaire pour le faire. Et puis, on peut penser tout doucement à créer une page pour fixer des décisions en votant si nécessaire pour confirmer l'adhésion générale ou grandement majoritaire.
:::::::::C'est curieux, je voulais travailler sur Wikiversité et finalement je me trouve plus actif sur Wikilivres. Mais les enjeux sont les mêmes et beaucoup de personnes actives ici le sont aussi sur Wikiversité, y compris parmi les administrateurs. En avançant dans Wikilivres, j'ai donc aussi l'impression que l'on avance sur Wikiversité.
:::::::::Au fait, fourmidable ? Tu ne serais pas intéressé, toi, de prendre un balai dans Wikilivres ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:27 (CEST)

== Demande d'aide pour amélioré Wikbook. Merci ==

* Actuellement j'ai proposé mes services pour améliorer wikibook. J'ai créé un partenariat informel avec des administrateurs, je propose des pages et des livres à supprimer. Ils décident soit de suivre ma demande, soit de la neutraliser. Je les remercie pour leur patience et leur aide.

- https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate


*Certain livres semblent trop avancé pour suivre cette procédure.

- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026

Dans cette page, je propose des livres trop avancés pour être traités rapidement. Il faut un vote pour que les demandes soient acceptées.
Aujourd'hui j'ai besoin de vous pour faire avancer mes propositions, sur des livres peut-être intéressants mais abandonnés depuis plus de trois ans, cinq ans, dix ans, vingt ans.

Si vous appréciez mon dévouement pour Wikibook et que vous souhaitez m'aider, ''il suffit chaque semaine de rajouter la commande'' {{VoteSupprimer}} ''sur les livres que je propose''. '''Entré {{}} puis à l'intérieur des parentthèses VoteSupprimer''' et signer votre accord. Merci pour votre aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 25 août 2026 à 10:33 (CEST)

:Salut @[[Utilisateur:Xhungab|Xhungab]], merci à toi pour ton engagement ! J'ai supprimé les pages qui étaient pratiquement vides dans ta liste. J'ai laissé les autres car la proposition de fusion est invoquée par @[[Utilisateur:DavidL|DavidL]] pour les pages avec du contenu. Malheureusement , je ne comprends pas comment fonctionne l'outil de fusion. J'espère que quelqu'un voudra bien m'expliquer le fonctionnement via un appel vidéo. Car je ne comprends pas les explications écrites. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:53 (CEST)
::Bonjour, Merci pour ton aide.
::.
::* J'ai travaillé sur la liste des pages les plus anciennement modifiées de l'année 2006. J'ai proposé tous les livres en errance à la suppression par vote.
::- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026
::Je vais attendre qu'elle soit traitée. Soit en supprimant ces livres soit en supprimant ma demande. Ensuite je ferai l'année 2007.
::.
::*Tu m'a posé une question.
::Quel est l'avantage de la suppression par rapport au déplacement ?
::Je vais essayer de te répondre dans mon prochain message. (Ce sera juste un délire d'un mois d'août un peu chaud). [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 09:20 (CEST)
:::C'est motivant de voir des gens motivés =)
:::Prend ton temps, il n'y a aucune échéance dans les projets Wikimédia, c'est un processus en continu qui peut s'étendre à plusieurs générations... Et si c'est plus facile pour toi de passer à l'oral, sache que je suis partant pour une discussion audio ou vidéo. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:35 (CEST)

== J'ai fait un rêve. ==

J'ai fait un rêve.

Un lieu où des amateurs passionnés proposeraient de partager leurs travaux avec des étudiants curieux. Pas les meilleurs travaux du monde. Mais pas les pires non plus. Un endroit où les anciens passeraient  le relais à ceux qui présentent leurs avenirs.  

Ce serait une petite bibliothèque avec une cinquantaine de livres disponibles à l'étude. Cinq ou six livres en construction que les étudiants pourraient travailler avec l'auteur. Tous les ans quelques livres supplémentaires viendraient enrichir ce lieu d'étude.

Aujourd'hui, il existe Wikibook. Un lieu où des auteurs malveillants prouvent que le travail collaboratif ne fonctionne pas. Ils créent des livres parfaitement construits de quelques chapitres puis les abandonnent sans scrupule. Ces livres moisissent depuis cinq, dix, quinze, vingt ans.

Wikibook c'est:
* La bibliothèque de livres pédagogiques libres que chacun peut améliorer.
* 569 livres contenant 22 112 pages.
.
* 569 livres dont 450 livres à l'abandon depuis cinq, dix, quinze, vingt ans.


Oui, aujourd'hui Wikibook peut changer. Wikibook va changer. Wikibook pour les étudiants va renaître de ses cendres. Les cendres des vieux livres abandonnés. Les auteurs devront faire honnêtement leur travail, ou les étudiants feront le leur.

Ceci n'est juste qu'un rêve dans un mois d'août un peu plus chaud que d'habitude.

Merci pour m'avoir suivi jusqu'ici. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 10:13 (CEST)

:Je trouve que c'est un très beau rêve @[[Utilisateur:Xhungab|Xhungab]]. Dans ce rêve, on peut voir la partie remplie du verre au lieu de la partie vide. Sur Wikilivres, il y a plus de 100 ouvrages terminés entièrement libres d'usage et toujours améliorables collectivement. Deux fois plus que la cinquantaine de livres dont tu parles dans ton rêve.
:C'est normal d'abandonner un projet d'écriture. La vie est tellement imprévisible. Les ressources en temps et énergie tant limitées. Combien de personnes ont commencé un livre sur papier ou sur leur ordi sans jamais le terminer ?
:C'est pareil sur Wikilivres, sauf que c'est visible aux yeux de tous.
:Quand on commence un truc, c'est jamais dans l'intention de l'arrêter. Si on arrête, c'est qu'il y a des raisons à cela. Je n'ai donc pas envie de voir dans ces abandons des actes de malveillance, ni de critiquer leurs auteurs. J'ai d'ailleurs moi-même des projets que je n'arrive pas à concrétiser (exemple).
:Je pense au contraire que ce n'est pas un problème à partir du moment où nous avons la liberté et les outils (communication, suppression, fusion) qui nous permettent de faire le tri entre ce qui est terminé, voire même ce qui est de qualité, et le reste.
:Ce rêve est donc possible et mes démarches pour devenir wikimédien en résidence à l'université sont une démarche qui va dans ce sens. J'ai d'ailleurs apporté les preuves que l'intégration des projets Wikimédia dans le processus d'apprentissage universitaire est non seulement possible, mais hyper efficace. Malheureusement, j'ai toujours l'impression que cela n'intéresse personne. Ni à l'Unif, ni dans Wikimédia. Mais je ne désespère pas. Les changements de paradigmes sont lents en raison des habitudes. C'est une fatalité chez l'humain. Il faut faire avec.
:Mais donc. Concentrons-nous sur la manière d'organiser notre bibliothèque pour que les visiteurs puissent confortablement voir ce qui s'y trouve en séparant, livres terminés, livres de qualité (cela se fait bien avec les articles de Wikipédia), livres en cours d'édition et livres abandonnés, etc. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:32 (CEST)
::Je pense que nos points de vue sont irréconciliables en toute amitié. Pour moi, Wikibook est une  bibliothèque de livres pédagogiques libres que chacun peut améliorer. Soit on peut mettre un étudiant sur un livre. Soit ce livre est inutile (Je parle de livre de plus de trois ans). 
::.
::Wikibook n'est pas un entrepôt pour les auteurs.  C'est une bibliothèque.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 14:57 (CEST)
:::@[[Utilisateur:Xhungab|Xhungab]], c'est bien que l'on ne soit pas d'accord, car cela permet d'avancer vers une solution que tout le monde pourra approuver. C'est le principe du consensus et cela prend du temps en discussion. C'est normal et sain. En de plus, ce qui est dit ici est tout à fait pertinent pour Wikiversité qui est confronté à des problèmes similaires que Wikilivres.
:::J'exprime mes idées ci-dessous mes idées autrement pour voir si cela peut se rapprocher de ta propre vision des choses.
:::J'imagine la bibliothèque Wikilivres avec trois pièces :
:::# Une pièce principale à l'entrée qui reprend tous les livres terminés et prêts à l'emploi par une personne désireuse de les utiliser dans le cadre d'un apprentissage. Comme dans toutes les bonnes bibliothèques, ces ouvrages sont rangés par thèmes et certains d'entre eux sont mis en évidence en raison de leurs qualités, de leur pertinence par rapport à l'actualité, etc.
:::# Une pièce archives à l'arrière du bâtiment (un espace de nom que l'on pourrait choisir parmi ceux existants ou créer si nécessaire) dans laquelle on entrepose toute une série de livres abandonnés mais dont le contenu est archivé dans le but d'une éventuelle réutilisation. Cette réutilisation, comme le suggère @[[Utilisateur:DavidL|DavidL]], peut s'effectuer dans le cadre d'une fusion du contenu abandonné avec un autre contenu abandonné, ou mieux encore, si cela se présente, avec un livre terminé dans lequel les informations utiles du document abandonné sont manquantes. À noter que cela représente beaucoup de travail, tant pour la relecture que pour la mise en œuvre des fusions, qui, à mes yeux de personne expérimentée dans l'usage de MediaWiki, est un processus compliqué. De plus, il ne peut être fait que par des personnes ayant les outils d'administrateur. C'est-à-dire quatre personnes, dont deux ou trois actives dans ces récentes discussions.
:::# Dans la librairie Wikilivres, il y a ensuite un étage dans lequel chaque personne inscrite peut bénéficier d'un espace personnel, pour se présenter, stocker des informations, mais également travailler sur des projets personnels d'écriture. En tenant compte de ceci, on peut alors aussi imaginer de déplacer les ouvrages inachevés de la pièce principale à l'entrée de la librairie, vers ces différents locaux selon leurs auteurs respectifs.
:::Face à ces trois espaces, la question qu'il reste à se poser est de savoir si et dans quelles condition, on peut déplacer les ouvrages inachevés vers une salle d'archive, ou dans les locaux personnels des auteurs ? Cela en signalant que ce déplacement peut être fait très facilement et par toutes les personnes qui le souhaitent, même sans inscription à la bibliothèque. Ce qui est un grand avantage par rapport à la fusion.
:::Pendant ce temps, à l'accueil de la bibliothèque Wikibook, on invite les visiteurs à parcourir la pièce avec les ouvrages terminés, mais également la pièce archive, où ils peuvent trouver des ouvrages inachevés, au cas où ils veulent poursuivre leurs développements, ou trouver des ressources intéressantes pour leurs travaux personnels. On les informe ensuite aussi qu'avec leur inscription, ils bénéficient d'un local pour leurs activités personnelles et notamment pour y placer les ébauches d'ouvrages qu'ils désirent rédiger.
:::Que penses-tu de mon propre rêve ? Est-il si différent du tien ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:17 (CEST)
::::Et les autres ? @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Fourmidable|Fourmidable]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:Grondin|Grondin]]. Que pensez-vous de nos rêves ? Et, si le mien vous parle, quelles seraient vos propositions pour orienter les déplacements de pages à l'abandon entre un espace d'archivage (qui pourrait être créé) et des espaces utilisateurs ? Le nombre d'octets ? La finalisation d'une section ou d'un chapitre ? Quelles autres possibilités ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:37 (CEST)
::::: Bonjour, a priori ça doit se régler au cas par cas sur [[Wikilivres:Demandes de suppression]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]])

::::Bonjour,
::::La structure de Wikibook est parfaite grâce à sa vitrine.  Pour moi, il y a juste un problème sur les listes sur la droite : Arts, Loisir, Histoire, Langues, Technologie, Informatique, Sciences, Sciences humaines. Ces listes ne devraient donner accès qu'aux livres terminés.
::::Ces listes actuelles pourraient être caché dans un espace création qui pourrait être posé avec le lien Nouveauté en bas de la page.
::::Pour la gestion des livres, il suffirait qu'une ou deux personnes parcourent la bibliothèque et proposent quelques suppressions chaque semaine, pour en quelques mois éclaircir la situation. Je pense que l'on peut faire confiance aux administrateurs pour gérer la situation des livres, ceux qui sont à garder et les autres. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 18:30 (CEST)
:::::@[[Utilisateur:JackPotte|JackPotte]]. Le cas par cas est ce que nous faisons depuis toujours. Cela nous amène à la situation actuelle qui semble ne pas convenir à tous. En tout cas, c'est mon cas. Ici comme sur Wikiversité. Quand, en navigant sur le site, une personne tombe neuf fois sur dix sur des pages presque vides et inachevées, comme c'est le cas sur Wikilivre, elle se dit : c'est quoi ce site ? Elle passe alors à autre chose de plus vivant, genre https://zestedesavoir.com/ ou autre. Sans changements éditoriaux, je pense que la situation évoluera.
:::::@[[Utilisateur:Xhungab|Xhungab]], on peut faire comme tu dis. Cependant, la charge de travail repose sur une double action, la proposition d'abord et le traitement ensuite. Un traitement qui finalement repose sur les épaules des administrateurs. Nous ne sommes que des bénévoles peu nombreux et pas toujours disponibles.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 19:13 (CEST)
:Créer un livre, le ranger, en établir un plan, le catégoriser n'est pas un travail négligeable... Un travail que d'autres personnes intéressées pour écrire sur le sujet n'ont pas à refaire 🤷‍♂️ ...

== Petite proposition indécente à Lionel ==

Bonjour  Lionel,

Je souhaiterais te proposer un petit projet.

a) Dans la page principale de wikibook tu créés une page &quot;Espace pour les auteurs&quot;. Tu insères cette page devant le lien &quot;Nouveautés&quot;.
.

b) Tu copies dans cette page la liste des liens qui se trouvent en haut à droite dans la nouvelle page. (Arts, Loisirs, ...) Tu ne les modifies pas dans la page principale.
.

c) Dans la nouvelle page tu peux écrire un texte du genre.
Dans cette page, vous trouverez la liste de tous les livres disponibles sur Wikibook. Vous trouverez en particulier des livres en construction et vous pourrez entrer en contact avec les auteurs. Vous trouverez aussi des livres en construction sans auteur actif que vous pourrez compléter.


Cela est la première étape, si l'aventure t'intéresse. En fait tu ajoutes juste une page, que tu pourras supprimer si les besoins se font sentir. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 12:25 (CEST)

:La proposition est très décente @[[Utilisateur:Xhungab|Xhungab]] 
:Mais avant toute choses le plus prudent est de lancer une prise dé décision pour s'assurer d'un concesnsus en faveurs des changements dont nous débatons actuellement.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 août 2026 à 15:40 (CEST)
::Toutes ces actions seront réversibles. On ajoute une page. Un problème, on la supprime. 
::On fait rapidement les changements, on attend trois jours. En cas de problème, on supprime tout. Il suffira de s'excuser et de dire que l'on ne savait pas que l'on n'avait pas le droit. 
:: Un espace pour les lecteurs et un espace pour les auteurs séparés.
::[https://fr.wikibooks.org/wiki/Utilisateur:Xhungab Nouvelle page wikibook][[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 16:49 (CEST)
:@[[Utilisateur:Xhungab|Xhungab]] , ma grand mère disait : faire et défaire, c'est toujours travailler. Pour les grand changements, on a coutume de faire un prise de décision composée des propositions, suivies de débats et d'un vote.
:En plus, certaines décisions nécessite un changement technique et ce n'est pas toujours facilement réversible. Comme créer un nouvel espace de nom pour y transfèrer une catégorie de pages  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 28 août 2026 à 03:07 (CEST)
::Merci pour ton aide. Tu comprends maintenant pourquoi toi tu es un administrateur et moi pas.
::.
::'''Oui, aujourd'hui Wikibook peut changer. Wikibook va changer.''' 
::.
::*  '''Le changement c'est Maintenant :''' [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']
::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 28 août 2026 à 08:33 (CEST)
:::Ton enthousiasme fait plaisir @[[Utilisateur:Xhungab|Xhungab]], et je serais en faveur d'un style plus épuré de notre page d'accueil en plus d'une méthodes de classement et de séparation des ouvrages terminé, en cours et abandonnés. Je pense qu'à terme, nous pourrions faire une proposition de changement à soumettre au reste de la communauté. Par chance, nous ne sommes pas nombreux, cela simplifire les discussions et le processus de décision. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 19:26 (CEST)
::::Cette page  [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook'''] propose la vitrine, les livres disponibles, les mini-livres disponibles pour les lecteurs. Les lecteurs ne seront en contact qu'avec les livres terminés.
::::.
::::En bas à côté des nouveautés, il y a l' '''[https://fr.wikibooks.org/wiki/Discussion_utilisateur:Xhungab Espace pour les auteurs]''', avec tous les livres du site rangés par thème ou par niveau d'avancement si on clique sur l'image. Sinon, il y a une liste de catégories art,...
::::.
::::Cette proposition sépare donc deux espaces. Un pour les lecteurs et un pour les auteurs. Il suffirait maintenant plus qu'à nettoyer l'espace auteurs. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 20:22 (CEST)
L'usage des catégories me semble aussi une manière très pratique de trier le contenu de Wikilivre. Malheureusement, ces pages ne sont pas très sexy du coup l'usage de type de code pourrait être utile :

{ {Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={ { #categorytree:Livres terminés|mode=pages} } } }

Avec le rendu ci-dessous :
{{Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={{ #categorytree:Livres terminés|mode=pages}}}}

On pourrait ainsi imaginer d'intégrer directement ce code dans la page d'accueil pour afficher une boite déroulante au lieu d'envoyer le visiteur en dehors de la page d'accueil. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:08 (CEST)

:Tu devrais créer la page Lioneltest01 dans ta page utilisateur. Copier le code de la page principale de wikibook.
:Puis faire les changements que tu juges nécessaires. Tu peux éventuellement faire plusieurs pages. Ensuite, tu mets cette page dans le bistro pour que l'on puisse voir le résultat. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 21:22 (CEST)
::Je devrais, tu devrais, il devrait, nous devrions ... =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:28 (CEST)
:::Chaque chose en son temps.
:::1. Débattre ici des idées de changements.
:::2. Mettre les choses en place pour leur réalisation, comme la mise à jour du modèle:boite déroulante en s'inspirant de celui de Wikipédia ou d'autres sites.
:::3. Quand il n'y a plus de nouvelle idée ici, créer une page genre :[[Wikilivres:Prise de décision/Nouvelle page d'accueil et gestion des abandons]] avec une description précise des projets de changements, et une éventuelle [[Accueil/projet|page de présentation du projet d'un nouvelle page d'accueil]]
:::4. Poursuivre les discussions et propositions si nécessaire.
:::5. Quand on a fait le tour, passer au vote.
:::6. Mettre les décisions en application. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:03 (CEST)
::::Je propose actuellement un projet qui se trouve sur ma page utilisateur. Pourrais-tu lancer une prise de décision sur ce projet. Je ne sais pas comment on fait une telle demande. Je suis prêt à présenter mon projet et à recevoir les critiques. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 22:16 (CEST)
:::::''Aide-toi le ciel t'aidera''. La bureaucratie, c'est pas mon truc. Et puis ça m'irrite un peu que tu enchaines des demandes de faire des choses qui ne demande pas les outils d'administrateurs. Raisons pour lequelles, je pense finalement que l'on gagnerait à appliquer la [[w:Do-ocratie|Do-ocratie]] qui a fait ses preuves dans le monde du libre dont les projets Wikimédia sont issus.
:::::Si tu as une idée et qu'elle ne demande pas des droits de modification que tu n'as pas, fait la et on se retrouve en page de discussion de la page de tes changements en cas de problèmes et pour d'éventuelle commentaire. Sans réaction, pense à ''qui ne dit mot conscent''.
:::::Si tes idées demandes les outils d'administrateurs, tu peux alors demander à un admin de le faire. Libre à lui de le faire ou pas et si ça lui plait, si il a envie, si il prend le temps. Nous sommes bénévoles... Il y a bien des gens payés par la fondation, mais comment dire... Disons qu'ils ne sont pas des plus serviables. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:57 (CEST)
::::::Excuse moi je pensais qu'il faillait être administrateur pour faire une demande de prise de décision. Je vais donc essayer tous seul. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 23:06 (CEST)
:::::::Ok @[[Utilisateur:Xhungab|Xhungab]], pas de soucis. On ne peut pas tout savoir =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 30 août 2026 à 01:45 (CEST)

== Wikilivres:Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''


Merci pour votre participation

[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 30 août 2026 à 00:43 (CEST)

:Bonjour @[[Utilisateur:Xhungab|Xhungab]]. Content de te revoir dans les murs de Wikiversité après nos échanges sur Wikilivres. Je comprends ton sentiment de solitude, je le ressens aussi souvent. Il faut l'accepter et ne pas se décourager pour autant. Nous avons la chance de fonctionner dans une organisation bénévole, dans laquelle personne n'est tenu de répondre à des demandes. De ce fait, les choses évoluent lentement et en fonction des disponibilités. Dis-toi aussi que la période estivale est toujours un moment d'acalmie dans la participation. Moi par exemple, quand il fait bon, je préfère passer du temps sur des occupations extérieures que devant un écran.
:Cela dit, tu dois garder 3 règles implicites qui sont fréquemment appliquées dans les projets Wikimédia.
:1. ''Qui ne dit mot consent''. Si les personnes ne réagissent pas, cela ne veut pas dire qu'elles ne lisent pas. Par économie de temps et pour les personnes trop occupées ou pas assez motivées pour s'investir, ne pas réagir est un signe de consentement implicite.
:2. ''Les absents ont toujours tort.'' Lorsque l'on fait les choses dans les règles de l'art, par exemple comme tu le fais en lançant une prise de décision pour opérer un changement significatif dans Wikilivres, aucune personne absente durant un processus de décision clôturé viendra remettre en cause les choses par la suite.
:3. La doocratie. Les wikis sont des espaces de libertés au niveau de l'amélioration des contenus, mais également de l'organisation et des formes de contenus. En dehors du vandalisme qui est bien contrôlé par des personnes telles que @[[Utilisateur:Crochet.david|Crochet.david]], toute initiative est souvent perçue comme bienvenue. @[[Utilisateur:Fourmidable|Fourmidable]], par exemple, depuis qu'il est administrateur, a fait de nombreuses améliorations dans Wikiversité sans demander l'avis de la communauté. Personne ne lui a reproché son investissement. Si quelque chose qu'il a entrepris ne plaît pas à quelqu'un, une discussion commence entre lui et cette personne pour chercher une entente.
:Voilà tout.
:Je te rejoins aussi sur le fait que ce qui est décidé et mis en place sur Wikilivres peut tout à fait servir d'exemple pour Wikiversité et vice versa. Je ne suis pas le seul à être administrateur dans les deux projets et cela aide beaucoup à la création d'une synergie entre les deux projets qui sont finalement très complémentaires. Cela n'est pas étonnant d'ailleurs lorsque l'on sait que Wikiversité est né de Wikilivres.
:Une belle fin de journée à toi et à tous ceux qui liront ce message. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:30 (CEST)
::Merci. Pour tes explications. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 6 septembre 2026 à 13:50 (CEST)
:::Avec plaisir. Pense aussi qu'il n'y a pas de combat dans les projets Wiki, mais un lent processus évolutif, sans fin programmée, et qui est pour moi l'un des meilleurs que je connaisse. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:57 (CEST)

== Les RAW sont arrivés, la rentrée peut commencer ! ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro de&amp;nbsp;septembre 2026 ({{numéro|296}}) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-09-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;
&lt;/div&gt;

'''C'est la rentrée'''

Après un numéro très dense en août en raison de la Wikimania, celui-ci est un peu plus léger car l'équipe s'est octroyée quelques vacances. Cela n'empêche pas le mouvement de continuer à vivre, avec une rentrée déjà animée ! Du côté des projets francophones, le Wiktionnaire vient de franchir le cap symbolique des sept millions d’entrées, tandis que Wikipédia continue de voir fleurir sondages et discussions sur son fonctionnement.

Une rentrée, donc, placée sous le signe de la construction collective : de nouveaux outils pour contribuer, de nouveaux espaces pour échanger, de nouvelles formes d’organisation… Ce numéro des RAW vous propose de faire le tour de cette actualité, avant de reprendre tranquillement le chemin des projets Wikimédia.

L'équipe de la rédaction a également commencé à réfléchir à un nouveau nom pour remplacer l'énigmatique « RAW ». N'hésitez pas à venir donner votre avis dans la [[:w:Discussion Wikipédia:RAW/Rédaction#Changement de nom|section dédiée]] !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia, des nouveaux outils et des articles de recherche

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : n'hésitez pas à suggérer des sujets ou participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]] !

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 septembre 2026 à 00:17 (CEST)

== Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés ==

J'ai posé une demande de prise de décision concernant le sujet suivant.


[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Modifier_le_contenue_de_l%27espace_Nouveaut%C3%A9s Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés]

Merci pour votre participation [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 9 septembre 2026 à 14:38 (CEST)

== '''Décision''':Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''

'''Décision pour : [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']'''

Résultats : 3 + Pour, un Neutre Neutre et un - Contre soit 60 % de + Pour par rapport au total des votes exprimés : la proposition est adoptée. Quelques propositions de reformulations et de nuances ont été faites qui pourront être prise en compte. Cdlt, VIGNERON * discut. 13 septembre 2026 à 18:27 (CEST)

Merci pour votre participation. Ma première proposition était un peu malhabile, mais grâce à vos interventions je pense que l'on a créé quelque chose de correct. '''Merci à tous''' [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 13 septembre 2026 à 20:22 (CEST)

== Je ne suis donc pas content tous seul. ==
'''Suite à l'installation de la nouvelle page de la Vitrine, je ne suis pas content, j'ai pris 24h pour réfléchir.
'''

J'avais posé une demande de prise de décision concernant le sujet suivant.


'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace auteurs sur la page d'accueil]'''


'''Créer un espace lecteurs''' : Où est l'espace pour les lecteurs?


 Découvrir la bibliothèque
 Livres terminés - Mini Livres - Tous les livres


'''Dans une bibliothèque''', un livre est disponible ou indisponible. C'est chez l'auteur ou chez l'imprimeur qu'un livre est terminé.


'''Je suis un nouveau sur Wikilivre'''. Je vois, &quot;Découvrir la bibliothèque&quot;, je vais directement dans &quot;'''[[Wikilivres:Tous les livres|Tous les livres]]'''&quot;. Je me retrouve dans un labyrinthe qui me balade de répertoires en répertoires pour finir sur une ébauche abandonnée depuis 5, 10, 20 ans.


Je ne suis pas content. J'avais proposé à l'administrateur un changement en 2 minutes. Copier cette page dans la Vitrine, [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab La Nouvelle Vitrine]. Il a décidé de passer plusieurs heures à modifier la prise de décision. Je ne suis pas content. Je suppose que je suis le seul. 


Donc : '''Je ne suis donc pas content tous seul.''' mais je me soigne. Un pan bagnat et une tourte aux blettes.

Merci de m'avoir lu [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 septembre 2026 à 10:51 (CEST)</text>
      <sha1>2plbcw5xt4ov9hjt5m3v5rvnaq1roej</sha1>
    </revision>
    <revision>
      <id>772346</id>
      <parentid>772345</parentid>
      <timestamp>2026-09-17T08:51:47Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <comment>/* Je ne suis donc pas content tous seul. */</comment>
      <origin>772346</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="72886" sha1="8yq8xa7ibtdi6qsp1yiw8piy0fh6v43" xml:space="preserve">&lt;noinclude&gt;{{Wikilivres:Le Bistro/En-tête}}&lt;/noinclude&gt;

== Le meilleur à Wikilivres pour 2026 ! ==

Je crée la page du bistrot 2026 en transmettant mes vœux. Bonne année éditoriale à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 janvier 2026 à 06:05 (CET)
:Merci, meilleurs vœux ! [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 16 janvier 2026 à 09:53 (CET)
::Meilleurs vœux pour 2026 !
::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 janvier 2026 à 20:13 (CET)
:::Meilleurs vœux pour 2026
:::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 janvier 2026 à 11:56 (CET)
::::Bonne année et bonnes lectures et écritures !
::::[[Utilisateur:Matthius|Matthius]]


== Page orpheline du livre : États généraux du multilinguisme dans les outre-mer ==

Bonjour,

Le livre &quot;États généraux du multilinguisme dans les outre-mer&quot; a laissé quelques pages orphelines. Ces pages orphelines ont été recopiées ou regroupé dans le texte du livre. Elles font donc doublons.

Je montre dans ce livre [[Wikilivres:Feuilles dupliquées orphelines]] cette suite de pages orphelines accompagnée par la page où elles ont été recopiées.

Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 10 février 2026 à 19:57 (CET)

:@[[Utilisateur:Xhungab|Xhungab]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], bonjour. Je vois que l'on est en campagne de gestion de pages orphelines et je me pose la question de savoir si on doit les supprimer une fois réintégrées ailleurs ou les supprimer ? Je vois que les deux cas de figure ont été mis en œuvre précédemment. L'avantage de la fusion est de conserver l'historique des modifications, mais je ne suis pas habitué à le faire. Si quelqu'un d'entre vous pouvait m'indiquer une page d'explication, cela m'aiderait à m'y mettre. Ensuite, je me demande si la fusion a vraiment un sens lorsque c'est la même personne qui a créé la page orpheline et la nouvelle au contenu copié collé pour insertion ? Qu'en pensez-vous ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:02 (CET)
:::Ça fait plaisir de voir une personne s'investir dans la maintenance de Wikilivres =). Soit le ou la bienvenu.e. J'attends les avis des autres administrateurs pour te donner mon soutien @[[Utilisateur:Xhungab|Xhungab]]. @ bientôt. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:27 (CET)
:::: @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]] bonjour, je n'ai pas compris en quoi &quot;deux cas de figure ont été mis en œuvre précédemment&quot; : si la page est vide on la supprime et si elle a au moins une phrase valable on la fusionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:26 (CET)
::::Concernant l'auteur pour moi cela importe peu, car on souhaite conserver chaque élément permettant de prouver une primauté du droit d'auteur (par exemple pour ne pas accuser un contributeur d'avoir copié un site miroir de sa page supprimée). [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:30 (CET)
:::::Désolé [[Utilisateur:JackPotte|JackPotte]], je n'avais pas vu que les pages que tu as supprimées étaient vides. La règle est donc supprimer si vide et fusionner si non. Tu peux me conseiller une page d'aide pour oppérer les fusions ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:34 (CET)
::::::Salut,
::::::Pour la fusion d'historique :
::::::* soit [[Wikilivres:Le guide de l'administrateur#Fusionner deux pages|Utiliser la page spéciale pour cela]] (cependant ne fonctionne pas toujours),
::::::* soit [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages utiliser l'ancienne méthode] qui reste toujours valable quand la première ne fonctionne pas.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 13 février 2026 à 19:34 (CET)
:::::::Salut @[[Utilisateur:DavidL|DavidL]]. Je viens de tester l'outil fusionner avec les deux pages suivantes
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes/Contexte]]
:::::::vers
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes]]
:::::::Et j'ai le message suivant :
:::::::« La période spécifiée chevauche les versions préexistantes de la page de destination. »
:::::::Tu peux m'expliquer si tu as le temps ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 00:19 (CET)
::::::::Salut @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]]
::::::::Dans ce cas, j'utilise [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages l'ancienne méthode].
::::::::# Renommer A (page qui n'existera plus) vers B, sans laisser de redirection, et en cochant la case de suppression de B (case qui apparait après 1er clic sur le bouton Renommer) (&amp;rarr; l'historique de A est sur B, celui de B est supprimé)
::::::::# Supprimer B (&amp;rarr; l'historique de A et B sont supprimés)
::::::::# Restaurer B et cocher toutes les cases des versions (bouton &quot;Inverser la sélection&quot;) (&amp;rarr; restaurer l'historique de A et B)
::::::::# Effectuer une modification de la version finale de la page à afficher, trouvée dans l'historique.
::::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 février 2026 à 08:29 (CET)
:::::::::Merci @[[Utilisateur:DavidL|DavidL]]. Ça m'a l'air bien compliqué tout ça. Et avec toute les pages qu'il faut faire, ça risque de prendre un certain temps. Je manque de courage en pensant que c'est juste pour ajouter une ligne dans l'historique des versions. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 14:51 (CET)
::::::::::Finalement, dans l'exemple que j'ai pris, la fusion n'avait aucun sens puisque le contenu du doublon que j'ai finalement supprimé était intégralement repris dans l'autre doublon par le même auteur. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 22 août 2026 à 23:55 (CEST)
:::::::::::Désolé @[[Utilisateur:Xhungab|Xhungab]]. Je ne comprends rien à l'outil de fusion et je ne trouve rien qui me permet de comprendre sur le net. Une vidéo avec exemple des différents cas de figure serait bien, mais je ne trouve pas. Je vais donc laisser ce travail à ceux qui savent utiliser l'outil.
:::::::::::En revanche, j'ai remarqué que certains doublons, comme dit précédemment, ne nécessitent pas de fusion puisqu'il s'agit de pages qui ont été créées sans aucune autre modification, puis, copiées par le même auteur dans une autre page créée avec un autre nom, au lieu de faire un renommage. Il faudrait donc que je prenne le temps de parcourir la liste pour repérer ces cas de figure avant de supprimer le premier doublon. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 01:27 (CEST)
::::::::::::Merci pour ton aide. Actuellement ces pages ont été en quelque sorte neutralisées. Donc fais de ton mieux, mais ne te tracasse pas elles ne posent plus de problème. Encore merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 09:13 (CEST)
:::::::::::::OK @[[Utilisateur:Xhungab|Xhungab]], merci pour l'info. Au fait comment as-tu fais pour les détecter ? En parcourant les pages de la catégorie orphelines et en vérifiant celles qui sont doublons ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 12:36 (CEST)
::::::::::::::Dans la catégorie pages orphelines, il y avait un lien sur une page.
::::::::::::::Je choisissais une phrase et je recherchais avec la fonction recherche de wikibook où se trouvait cette phrase. Si c'était un doublon, j'avais un lien vers la nouvelle page. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 12:48 (CEST)
:::::::::::::::Intelligent. Tu poserais pas ta candidature d'admin !? Ici, avec @[[Utilisateur:Fourmidable|Fourmidable]] et puis sur wikiversité aussi. Ça pourrait aider pour le projet des 20 ans., si tu comote toujours t'investir. On est en sous effectif dans les deux projects et les communautés me semblent plus ouverte que sur Wikipédia. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 13:48 (CEST)
::::::::::::::::Je ne souhaite pas devenir un administrateur. Pourquoi ? Si on me donne du pouvoir, je l'utiliserais. Par la suite, ceux qui m'ont accordé le pouvoir auront le choix entre pleurer, nous quitter ou me mettre en arrêt de travail. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 14:59 (CEST)
:::::::::::::::::Ah ah ah. T'es si foireux que ça !? Ou peut-être as-tu eu des expériences antérieures ? Dans tous les cas, c'est super de ta part de pouvoir t'auto évaluer.
:::::::::::::::::Ceci dit, le système de demander au administrateurs de faire des tâches qu'il faut expliquer est une perte de temps et d'efficacité. On pourrait d'ailleurs penser à attribuer les droits temporairement pour effectuer certaines tâches. Je me demande si ça se fait déja quelque part ? Si oui, on pourrait s'en inspirer pour mettre le système en application sur Wikilibres et Wikobersité. T'en penses quoi @[[Utilisateur:Xhungab|Xhungab]] ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 15:40 (CEST)
::::::::::::::::::Oui, je pourrais obtenir des droits temporaires par rapport à un projet. Par exemple 2 projets
::::::::::::::::::Premier projet :  Supprimer toutes les feuilles volantes. Ce sont des feuilles tests très bien faites mais qui n'appartiennent à aucun livre. Je crois qu'il y a actuellement, Feuilles volantes – 54 P. 
:::::::::::::::::: 
:::::::::::::::::: Deuxième projet : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Pages_anciennes Les pages les plus anciennement modifiées]
::::::::::::::::::Supprimer tous les livres entre 2006 et 2010 qui sont à l'abandon. Parfois il sera possible de sauvegarder un livre en supprimant les chapitres vides, ce qui nous permettra de créer un livre complet. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 16:19 (CEST)
Donc, tu as du temps à consacrer à ce genre de maintenance ? Ce serait bête de ne pas en profiter. Reste à voir à présent si les autres administrateurs et bureaucrates seraient d'accord de t'octroyer les droits, tout en approuvant les deux projets que tu proposes. Cependant, je ne suis pas un grand fan des suppressions, je préfère de loin renommer les pages pour les placer en dehors de l'espace principal de sorte à ce que les auteurs puissent toujours les retrouver. Pour ça, un bon espace, c'est les sous-pages des principaux auteurs. Cela pourrait ainsi s'appliquer aux feuilles volantes et aux projets d'écriture abandonnés qui sont suffisamment développés pour justifier une conservation. L'avantage de cette méthode est qu'elle ne demande pas d'avoir les outils d'administrateurs. Faudrait voir maintenant dans quel cas on supprime et dans quel cas on renomme. On pourrait par exemple définir un nombre d'octets ou de caractères, question d'avoir un critère standard et accepté par tous. Qu'en penses-tu [[Utilisateur:Xhungab|Xhungab]] ?
:En fait je préfère continuer comme actuellement. Proposer mes services  pour améliorer wikibook sans avoir aucun droit. De cette manière, si je propose quelque chose d'incongru, comme cela est déjà arrivé, il suffit de neutraliser ma demande. Merci à ceux qui me suivent sur ce travail.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 01:52 (CEST)

:Je comprends @[[Utilisateur:Xhungab|Xhungab]]. Mais précisément, déplacer une page à l'abandon dans une sous-page l'espace utilisateur de l'auteur principal, cela ne demande justement aucun droit et tout le monde peut le faire, toi en premier puisque tu sembles actif à ce niveau. C'est pour ça que je te demande ton avis : que penses-tu de l'idée de déplacer les pages comme je viens de le décrire, plutôt que de les supprimer ? Je viens de soumettre l'idée dans une nouvelle discussion ci-dessous. Tu peux donner ton avis là-bas si tu veux. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 02:27 (CEST)

== archive.today ==
''Voir [[:w:Wikipédia:Le Bistro/21 février 2026#archive.today]].''

Ce site pose apparemment des problèmes de sécurité, il faudrait le remplacer au plus vite si possible, et sinon désactiver les liens.

[[Utilisateur:SyntaxTerror|SyntaxTerror]] ([[Discussion utilisateur:SyntaxTerror|discussion]]) 21 février 2026 à 13:07 (CET)
:Salut SyntaxTerror,
:* 0 liens vers archive.today : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.today]
:* &lt;s&gt;18&lt;/s&gt; 0 liens vers archive.is [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.is]
:* 0 liens vers archive.li [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.li]
:* 0 liens vers archive.ec [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ec]
:* 0 liens vers archive.ph [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ph]
:* 0 liens vers archive.fo [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.fo]
:* 0 liens vers archive.md [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.md]
:* &lt;s&gt;1&lt;/s&gt; 0 liens vers archive.vn [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.vn]
:* 0 liens vers archive.closed.social [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.closed.social]
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 21 février 2026 à 16:14 (CET)
::Merci pour vos efforts ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:22 (CEST)

== demande aide pour sortir du mode &quot;ébauche&quot; ==

je viens de terminer mon livre ... ci dessous. J'ai compris qu'il fallait le signaler comme n'étant plus au stade &quot;ébauche&quot;  commente faire   Merci

https://fr.wikibooks.org/w/index.php?title=Essai_pour_un_mod%C3%A8le_de_psychisme_objectif&amp;action=info#mw-pageinfo-header-basic [[Utilisateur:Clopeau|Clopeau]] ([[Discussion utilisateur:Clopeau|discussion]]) 17 mars 2026 à 08:20 (CET)
:Bonjour, quand je regarde ''[[Essai pour un modèle de psychisme objectif]]'', sa complétude permettrait en effet de le sortir des ébauches, mais il semble plutôt d'agir d'un travail de recherche que d'un livre pédagogique sur un sujet sourcé comme reconnu.
:Donc en vertu de [[Wikilivres:Principes fondateurs|notre charte]], je propose de le déplacer sur {{WV|Recherche:Accueil}}. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 18 mars 2026 à 09:06 (CET)

== Don à wikipédia depuis wikilivres ==

{{BlocCitation|La Wikimedia Foundation est l’organisation à but non lucratif qui soutient Wikipédia, '''les autres sites de connaissance libre de Wikimédia''', et sa mission de connaissance libre pour tous.|auteur=[https://wikimediafoundation.org/fr/give/donor-frequently-asked-questions/ FAQ], {{g|Qu'est-ce-que la Wikimedia Foundation ?}}}}
Le lien de donation https://donate.wikimedia.org/w/index.php?title=Special:LandingPage&amp;country=FR&amp;uselang=fr&amp;wmf_medium=sidebar&amp;wmf_source=donate&amp;wmf_campaign=fr.wikibooks.org '''ne parle que de wikipédia'''. '''Où sont passés les autres projets ?''' Vont-ils être fermés sauvagement par la fondation comme Wikinews récemment ? La suite au prochain épisode d{{'}}''Highlander-Wikimedia'' : {{g|À la fin, un seul ''projet'' survivra.}} ... &amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 12 mai 2026 à 11:26 (CEST)

:Bonjour,
:Je pense personnellement que les wikis ont des problèmes.
:Il y a une vingtaine d'années, il représentait l'innovation la plus ambitieuse.
:Aujourd'hui, les wikis me semblent dépassés de tous les côtés.
:           wiki = Erreurs 404 (&quot;Page introuvable&quot;)
:Problèmes:
:* 568 livres déclarés. 50 livres terminés (combien sont obsolètes)
:* 21 527 pages déclarées. 20 000 pages orphelines. (Papa t'est où?)
:Solution:
:* Où sont les cours sur YouTube qui utilisent un wikibook comme référence?
:Voilà mon idée sur les wiki.
:* https://fr.wikiversity.org/wiki/Facult%C3%A9:Droit
:* https://fr.wikiversity.org/wiki/D%C3%A9partement:Introduction_au_droit
:&lt;nowiki&gt;~~~~&lt;/nowiki&gt; [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 12 mai 2026 à 13:50 (CEST)
::Ce serait intéressant de mentionner tous les projets actifs oui. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:23 (CEST)
::: En même temps, le message est plutôt franc étant donné que l'argent des dons n'est pas investi dans le développement de Wikilivres (cf [[:meta:Community Wishlist Survey]] et les réponses à nos tickets Phabricator).
::: Par ailleurs, concernant la qualité des contenus, cela a toujours était un sujet depuis le début, et nous disposons tout de même de plusieurs pages spéciales dans [[Wikilivres:Maintenance]] pour y remédier afin que le lecteur n'ait pas la sensation de se faire empapaouter en se retrouvant sur des ébauches bien placées dans Google. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mai 2026 à 08:48 (CEST)

== La catégorie SI est pleine ! ==

Bonjour tous,

Pour info, la [[:Catégorie:Suppressions immédiates demandées]] contient 9 pages.

Wikilivresquement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 14 juin 2026 à 15:36 (CEST)

:Elle est maintenant vide, merci à ceux qui s'y sont collés ! {{Sourire}} [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 24 juin 2026 à 17:17 (CEST)

== Un RAW bien frais pour juillet ==

{| style=&quot;width:100%;&quot;
| valign=&quot;top&quot; align=&quot;center&quot; style=&quot;border:1px gray solid; padding:1em;&quot; |
{| align=&quot;center&quot;
|-
| style=&quot;text-align: center;&quot; | &lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:4.5em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em;text-align:center; color: #fff; font-style:italic;&quot;&gt;Regards sur l’actualité du mouvement Wikimédia.&lt;/div&gt;
&lt;div style=&quot;text-align: center;&quot;&gt;{{#ifeq:{{FULLPAGENAME}}|Wikipédia:RAW/Rédaction}}&lt;/div&gt;
&lt;/div&gt;&lt;br /&gt;
&lt;hr /&gt;
&lt;div style=&quot;font-size:12pt; font-family:Times New Roman; text-align:center;&quot;&gt;[[w:fr:Wikipédia:RAW/2026-07-05|&lt;span style=&quot;color:darkslategray;&quot;&gt;Le numéro de juillet 2026 est sorti.&lt;/span&gt;]]&lt;/div&gt;
&lt;hr /&gt;&lt;br /&gt;

|- style=&quot;text-align: center;&quot;
| &lt;span style=&quot;font-size:12pt; font-family:Times New Roman;&quot;&gt; '''❖ Au menu de ce numéro ❖'''&lt;/span&gt;
|- style=&quot;font-size:10pt; font-family:Times New Roman; text-align:center;&quot;
| &lt;div style=&quot;text-align:center; column-count:1; column-width:28em; vertical-align:top;&quot;&gt;

'''L'Édito'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Édito|Fêtons notre mouvement !]]

'''Échos francophones'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Résidence|Un nouveau vigneron dans la résidence]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Logo_WP25|Wikipédia en français aux couleurs des 25 ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#DAF|Wikipédia dans le ''Dictionnaire de l'Académie française'']]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Millésime_Wiktionnaire|Quelles sont les nouvelles entrées en français sur le Wiktionnaire ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ADS|Relance de l'Article de la semaine]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#sans_pagEs|Le projet des sans pagEs fête ses dix ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#contributions_rémunérées|Faut-il faire évoluer les règles sur les contributions rémunérées ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#wikification|Le mois de la wikification fait son retour pour une septième édition]]

'''Ailleurs dans le mouvement'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Txikipedia|Txikipedia franchit le cap des 10 000 articles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Concours_santé_2026|Un concours sur la santé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Commons_et_IA|Commons se penche sur l'IA]]

'''Nouveautés techniques et outils'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#VIZWP|VIZWP : un outil pour visualiser les lacunes dans les sujets climatiques sur Wikipédia, mais pas que…]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#AI_Source_Verification|Examiner la vérifiabilité grâce à l'IA ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Icônes|Les icônes de l'interface ont changé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Sous-références|Ça y est, les sous-références sont là]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ConvoCompass|ConvoCompass, pour moins d'attaques personnelles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LSV-Tools|LSV-Tools : faciliter la gestion des anecdotes « Le saviez-vous ? »]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LegendAndDot|Semi-automatiser l'ajout de ponctuation dans les légendes d'images]]

'''Du côté de la recherche'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#COMSAV|COMSAV : la contribution à Wikipédia fait-elle d'un ensemble d'individus un ensemble de pairs ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#JourneyMap|Où commence la contribution et où s'arrête-t-elle ?]]

'''Le POV'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Le_POV|Guide survie pour la Wikimania 2026]] par Trizek

'''L'Atelier'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Atelier|Le point sur la diversité de genre dans les articles]] par PAC2

'''L'Analyse'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Analyse|Larry Sanger is back... and fired!]] par Madelgarius, Trizek et Jules*

'''L'interview'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'interview|Pronoia : de Byzance aux réseaux sociaux, un œil sur Wikipédia et le monde]] par Antimuonium

'''Le wik’hit-parade'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Wikit|Articles les plus vus en juin 2026]] par Ælfgar

&lt;/div&gt;
|-
| style=&quot;font-family:Times New Roman; text-align:center; font-size:90%;&quot; | [[w:fr:Wikipédia:RAW/2026-07-05|Lire tout le numéro]]
|-
| valign=&quot;top&quot; colspan=&quot;2&quot; style=&quot;padding:0.5em; font-family:Times New Roman;text-align:center; font-size:100%;&quot; |
Venez rédiger le prochain numéro, y parler de ce qui se fait dans votre communauté : [[w:fr:Discussion_Wikipédia:RAW/Rédaction|Salle de rédaction]].&lt;/br&gt;Les anciens numéros sont retrouvables [[w:fr:Modèle:Palette RAW|ici]].
|-
|}
|}
&lt;div style=&quot;margin-top:10px; font-size:90%; padding-left:5px; font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif;&quot;&gt;[[w:fr:Wikipédia:RAW/Inscription|Abonnez-vous !]] [[Utilisateur:L&amp;#39;embellie|L&amp;#39;embellie]] ([[Discussion utilisateur:L&amp;#39;embellie|discussion]]) 5 juillet 2026 à 01:53 (CEST)&lt;/div&gt;

== Les RAW en mode fiesta sur la Wikimania ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro d'août 2026 (n°295) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-08-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;&lt;/div&gt;

'''Un numéro exceptionnel'''

La conférence Wikimania s'est achevée le 25 juillet. Que vous ressentiez de la frustration (si vous n’avez pas pu y assister) ou du [[:w:Wikipédia:Wikispleen|wikispleen]] (si vous y étiez et que vous avez du mal à digérer que ce soit déjà fini), l’équipe des RAW n’a pas ménagé ses efforts pour vous proposer un numéro XXL qui revient en long, en large et en travers sur cet événement qui le mérite bien. Comptes-rendus, témoignages, entretiens, il y en aura pour tous les goûts ! Le numéro est aussi exceptionnel par le nombre de rédactrices et de rédacteurs qui y ont participé {{incise|merci !|stop}} 

Au-delà de Wikimania, l’actualité wikimédienne est loin d’être paisible cet été. Nous vous proposons donc aussi de revenir en détail sur la crise qui secoue la fondation Wikimédia autour de la reconnaissance du syndicat Wiki Workers United (WWU). Nous aurons probablement l’occasion de couvrir la suite de cette histoire dans le prochain numéro. D’ici là, bonne lecture !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia et des nouveaux outils

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Dossier spécial Wikimania&lt;/span&gt;'''

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les POV&lt;/span&gt;'''&lt;br&gt;— Ma Wikimania : la joie, l'inquiétude et la raison d'être&lt;br&gt;— Témoignages : regards sur la Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;L'Analyse&lt;/span&gt;''' — La crise s'intensifie après le refus de la WMF de reconnaître le syndicat WWU

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Comptes-rendus&lt;/span&gt;'''&lt;br&gt;— Une Wikimania sous le signe de la jeunesse&lt;br&gt;— Sur les conséquences de la définition de « wikimédien·ne »&lt;br&gt;— Petit tour d’horizon de la créativité wikimédienne&lt;br&gt;— CultureStrong : respecter les savoirs des Premières Nations sur les plateformes Wikimédia&lt;br&gt;— Des événements techniques à Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Interviews&lt;/span&gt;'''&lt;br&gt;— Ses goûts, sa Wikimania, sa prochaine tournée... : Baby Globe nous dévoile tout !&lt;br&gt;— Jules*, notre Wikimédien de l'année : comment rendre compte du changement climatique tout en protégeant l'encyclopédie

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : si un sujet vous tient à cœur, n'hésitez pas à proposer une idée d'article ou à participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]]. Toutes les contributions sont les bienvenues, quel que soit votre wiki d'origine ! &lt;span class=&quot;smiley&quot;&gt;[[Image:Face-smile.svg|20px|Sourire|alt=Émoticône sourire]]&lt;/span&gt;

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 août 2026 à 00:28 (CEST)

== Bientôt les 20 ans de Wikiversité ==

Bonjour.

Un petit message de « débauchage » dans le cadre d'un projet d'amélioration de Wikiversité. Comme dit la chanson : « On n'a pas tous les jours vingt ans ! » Plus d'infos [[v:Wikiversité:La_salle_café/août_2026#Améliorer_Wikiversité_pour_ses_vingt_ans_d'existence|dans la salle café du projet]].

Belle fin de journée à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 août 2026 à 00:26 (CEST)

== [[:Catégorie:Suppressions immédiates demandées|Série de demandes de suppression immédiate]] ==

Bonjour,

La [[:Catégorie:Suppressions immédiates demandées]] est de nouveau pleine, mais cette fois, il semble qu'elle ait été remplie par le seul {{U|Xhungab}}.

Cordialement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 16 août 2026 à 14:56 (CEST)
:{{fait}} Bonjour, oui c'était effectivement un ensemble d'ébauches abandonnées. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 17 août 2026 à 10:38 (CEST)
::Merci pour votre aide [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 août 2026 à 14:26 (CEST)

== Deux idées à débattre ==

Bonjour.

Vu le travail de traitement des pages et livres abandonnés et suite à une discussion avec @[[Utilisateur:Xhungab|Xhungab]] reprise ci-dessous, j'aimerais soumettre deux idées à la communauté Wikilivres.

'''La première idée''' est de déplacer toutes les pages et livres dont le développement est abandonné depuis longtemps en sous-page de l'auteur principal tout en laissant un message sur sa page de discussion avec un lien pointant vers la sous-page en question. Ce message pouvant faire l'objet d'un modèle.

Avantage : 1. Pas besoin d'être admin pour faire ce genre de maintenance. 2. Pas de risque de frustrer un auteur ni de perdre de vue des informations intéressantes. 3. Ceci dans le but d'améliorer l'apparence de Wikilivres au niveau du contenu visible sur l'espace de nom principal.

Nécessité : 1. Créer un modèle à placer sur la page de discussion de l'auteur principal après déplacement. 2. Définir la durée d'abandon des pages à déplacer.

'''La deuxième idée''' est de donner les outils d'administrateurs à des personnes qui ne veulent pas endosser cette responsabilité à long terme et de manière continue, mais qui sont d'accord d'en faire usage dans le cadre d'un projet de maintenance temporaire. Cela pourrait être utile pour @[[Utilisateur:Fourmidable|Fourmidable]] s'il le souhaite, à moins qu'il se décide à déposer sa candidature pour une nomination définitive. Ce qui serait une bonne idée, je trouve.

Qu'en pensez-vous @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Grondin|Grondin]] ?

Une prise de décision est-elle nécessaire si on décidait une mise en application ?

Bien à vous tous,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 01:50 (CEST)

:Bonjour,
:J'ai proposé une liste de livres à supprimer
:https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate
:Doit-on réellement les garder ? ;) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 10:21 (CEST)
::Quel est l'avantage de la suppression par rapport au déplacement @[[Utilisateur:Xhungab|Xhungab]]? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:56 (CEST)
:::En déterminant un contenu minimum, on peut faire le tri de ce que l'on supprime et ce que l'on déplace. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:58 (CEST)
::::Bonjour,
::::Les droits administrateurs temporaires sont difficiles à gérer : un bureaucrate peut attribuer le status administrateur mais pas le retirer.
::::Concernant les critères suppression ou renommage, je propose :
::::* (cas 1) Une page qui ne contient vraiment aucun texte (ex : seulement des liens rouges) --&gt; suppression
::::* (cas 2) Une page avec quelques phrases significatives récupérables --&gt; soit (a) tenter de fusionner dans un livre qui aborde le même sujet ou sujet connexe, soit (b) renommer en sous-page de l'auteur si aucun livre pour la fusion ne convient
::::* (cas 3) Une page avec plus de contenu que (cas 2) --&gt; conserver
::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 24 août 2026 à 19:33 (CEST)
:::::Salut @[[Utilisateur:DavidL|DavidL]]. Oui, c'est raisonnable. Reste que la fusion, c'est compliqué. J'ai essayé, mais je ne comprends rien. Une vidéo m'aiderait à comprendre, mais j'en ai pas trouvé. Ensuite, si on garde, genre un livre abandonné depuis plus de trois ans avec un chapitre entamé sur cinq prévus, par exemple, on le laisse dans l'espace principal, ou on le déplace vers l'espace utilisateur de l'auteur ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 25 août 2026 à 00:38 (CEST)
::::::Pour ce cas je propose de le fusionner si possible, comme (cas 2)(a) ; sinon le conserver, comme (cas3) afin qu'un utilisateur motivé puisse reprendre le livre.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 25 août 2026 à 08:36 (CEST)
:::::::Ok. Es-tu à l'aise avec la fusion @[[Utilisateur:DavidL|DavidL]] ? Car c'est une solution intéressante, mais je n'y arrive pas. Il y a toujours un message que je ne comprends pas et suite à quoi je préfère arrêter. Serais-tu dispo pour m'expliquer comment faire durant un appel vidéo ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:30 (CEST)
::::::::Bonjour {{Mention|Lionel Scheepmans}}, je suis très favorable à tes deux idées ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 août 2026 à 15:39 (CEST)
:::::::::Ok @[[Utilisateur:Fourmidable|Fourmidable]], je me dis qu'il serait encore bien d'avoir les avis de @[[Utilisateur:JackPotte|JackPotte]], voir de @[[Utilisateur:Grondin|Grondin]], s'ils trouvent le temps nécessaire pour le faire. Et puis, on peut penser tout doucement à créer une page pour fixer des décisions en votant si nécessaire pour confirmer l'adhésion générale ou grandement majoritaire.
:::::::::C'est curieux, je voulais travailler sur Wikiversité et finalement je me trouve plus actif sur Wikilivres. Mais les enjeux sont les mêmes et beaucoup de personnes actives ici le sont aussi sur Wikiversité, y compris parmi les administrateurs. En avançant dans Wikilivres, j'ai donc aussi l'impression que l'on avance sur Wikiversité.
:::::::::Au fait, fourmidable ? Tu ne serais pas intéressé, toi, de prendre un balai dans Wikilivres ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:27 (CEST)

== Demande d'aide pour amélioré Wikbook. Merci ==

* Actuellement j'ai proposé mes services pour améliorer wikibook. J'ai créé un partenariat informel avec des administrateurs, je propose des pages et des livres à supprimer. Ils décident soit de suivre ma demande, soit de la neutraliser. Je les remercie pour leur patience et leur aide.

- https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate


*Certain livres semblent trop avancé pour suivre cette procédure.

- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026

Dans cette page, je propose des livres trop avancés pour être traités rapidement. Il faut un vote pour que les demandes soient acceptées.
Aujourd'hui j'ai besoin de vous pour faire avancer mes propositions, sur des livres peut-être intéressants mais abandonnés depuis plus de trois ans, cinq ans, dix ans, vingt ans.

Si vous appréciez mon dévouement pour Wikibook et que vous souhaitez m'aider, ''il suffit chaque semaine de rajouter la commande'' {{VoteSupprimer}} ''sur les livres que je propose''. '''Entré {{}} puis à l'intérieur des parentthèses VoteSupprimer''' et signer votre accord. Merci pour votre aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 25 août 2026 à 10:33 (CEST)

:Salut @[[Utilisateur:Xhungab|Xhungab]], merci à toi pour ton engagement ! J'ai supprimé les pages qui étaient pratiquement vides dans ta liste. J'ai laissé les autres car la proposition de fusion est invoquée par @[[Utilisateur:DavidL|DavidL]] pour les pages avec du contenu. Malheureusement , je ne comprends pas comment fonctionne l'outil de fusion. J'espère que quelqu'un voudra bien m'expliquer le fonctionnement via un appel vidéo. Car je ne comprends pas les explications écrites. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:53 (CEST)
::Bonjour, Merci pour ton aide.
::.
::* J'ai travaillé sur la liste des pages les plus anciennement modifiées de l'année 2006. J'ai proposé tous les livres en errance à la suppression par vote.
::- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026
::Je vais attendre qu'elle soit traitée. Soit en supprimant ces livres soit en supprimant ma demande. Ensuite je ferai l'année 2007.
::.
::*Tu m'a posé une question.
::Quel est l'avantage de la suppression par rapport au déplacement ?
::Je vais essayer de te répondre dans mon prochain message. (Ce sera juste un délire d'un mois d'août un peu chaud). [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 09:20 (CEST)
:::C'est motivant de voir des gens motivés =)
:::Prend ton temps, il n'y a aucune échéance dans les projets Wikimédia, c'est un processus en continu qui peut s'étendre à plusieurs générations... Et si c'est plus facile pour toi de passer à l'oral, sache que je suis partant pour une discussion audio ou vidéo. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:35 (CEST)

== J'ai fait un rêve. ==

J'ai fait un rêve.

Un lieu où des amateurs passionnés proposeraient de partager leurs travaux avec des étudiants curieux. Pas les meilleurs travaux du monde. Mais pas les pires non plus. Un endroit où les anciens passeraient  le relais à ceux qui présentent leurs avenirs.  

Ce serait une petite bibliothèque avec une cinquantaine de livres disponibles à l'étude. Cinq ou six livres en construction que les étudiants pourraient travailler avec l'auteur. Tous les ans quelques livres supplémentaires viendraient enrichir ce lieu d'étude.

Aujourd'hui, il existe Wikibook. Un lieu où des auteurs malveillants prouvent que le travail collaboratif ne fonctionne pas. Ils créent des livres parfaitement construits de quelques chapitres puis les abandonnent sans scrupule. Ces livres moisissent depuis cinq, dix, quinze, vingt ans.

Wikibook c'est:
* La bibliothèque de livres pédagogiques libres que chacun peut améliorer.
* 569 livres contenant 22 112 pages.
.
* 569 livres dont 450 livres à l'abandon depuis cinq, dix, quinze, vingt ans.


Oui, aujourd'hui Wikibook peut changer. Wikibook va changer. Wikibook pour les étudiants va renaître de ses cendres. Les cendres des vieux livres abandonnés. Les auteurs devront faire honnêtement leur travail, ou les étudiants feront le leur.

Ceci n'est juste qu'un rêve dans un mois d'août un peu plus chaud que d'habitude.

Merci pour m'avoir suivi jusqu'ici. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 10:13 (CEST)

:Je trouve que c'est un très beau rêve @[[Utilisateur:Xhungab|Xhungab]]. Dans ce rêve, on peut voir la partie remplie du verre au lieu de la partie vide. Sur Wikilivres, il y a plus de 100 ouvrages terminés entièrement libres d'usage et toujours améliorables collectivement. Deux fois plus que la cinquantaine de livres dont tu parles dans ton rêve.
:C'est normal d'abandonner un projet d'écriture. La vie est tellement imprévisible. Les ressources en temps et énergie tant limitées. Combien de personnes ont commencé un livre sur papier ou sur leur ordi sans jamais le terminer ?
:C'est pareil sur Wikilivres, sauf que c'est visible aux yeux de tous.
:Quand on commence un truc, c'est jamais dans l'intention de l'arrêter. Si on arrête, c'est qu'il y a des raisons à cela. Je n'ai donc pas envie de voir dans ces abandons des actes de malveillance, ni de critiquer leurs auteurs. J'ai d'ailleurs moi-même des projets que je n'arrive pas à concrétiser (exemple).
:Je pense au contraire que ce n'est pas un problème à partir du moment où nous avons la liberté et les outils (communication, suppression, fusion) qui nous permettent de faire le tri entre ce qui est terminé, voire même ce qui est de qualité, et le reste.
:Ce rêve est donc possible et mes démarches pour devenir wikimédien en résidence à l'université sont une démarche qui va dans ce sens. J'ai d'ailleurs apporté les preuves que l'intégration des projets Wikimédia dans le processus d'apprentissage universitaire est non seulement possible, mais hyper efficace. Malheureusement, j'ai toujours l'impression que cela n'intéresse personne. Ni à l'Unif, ni dans Wikimédia. Mais je ne désespère pas. Les changements de paradigmes sont lents en raison des habitudes. C'est une fatalité chez l'humain. Il faut faire avec.
:Mais donc. Concentrons-nous sur la manière d'organiser notre bibliothèque pour que les visiteurs puissent confortablement voir ce qui s'y trouve en séparant, livres terminés, livres de qualité (cela se fait bien avec les articles de Wikipédia), livres en cours d'édition et livres abandonnés, etc. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:32 (CEST)
::Je pense que nos points de vue sont irréconciliables en toute amitié. Pour moi, Wikibook est une  bibliothèque de livres pédagogiques libres que chacun peut améliorer. Soit on peut mettre un étudiant sur un livre. Soit ce livre est inutile (Je parle de livre de plus de trois ans). 
::.
::Wikibook n'est pas un entrepôt pour les auteurs.  C'est une bibliothèque.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 14:57 (CEST)
:::@[[Utilisateur:Xhungab|Xhungab]], c'est bien que l'on ne soit pas d'accord, car cela permet d'avancer vers une solution que tout le monde pourra approuver. C'est le principe du consensus et cela prend du temps en discussion. C'est normal et sain. En de plus, ce qui est dit ici est tout à fait pertinent pour Wikiversité qui est confronté à des problèmes similaires que Wikilivres.
:::J'exprime mes idées ci-dessous mes idées autrement pour voir si cela peut se rapprocher de ta propre vision des choses.
:::J'imagine la bibliothèque Wikilivres avec trois pièces :
:::# Une pièce principale à l'entrée qui reprend tous les livres terminés et prêts à l'emploi par une personne désireuse de les utiliser dans le cadre d'un apprentissage. Comme dans toutes les bonnes bibliothèques, ces ouvrages sont rangés par thèmes et certains d'entre eux sont mis en évidence en raison de leurs qualités, de leur pertinence par rapport à l'actualité, etc.
:::# Une pièce archives à l'arrière du bâtiment (un espace de nom que l'on pourrait choisir parmi ceux existants ou créer si nécessaire) dans laquelle on entrepose toute une série de livres abandonnés mais dont le contenu est archivé dans le but d'une éventuelle réutilisation. Cette réutilisation, comme le suggère @[[Utilisateur:DavidL|DavidL]], peut s'effectuer dans le cadre d'une fusion du contenu abandonné avec un autre contenu abandonné, ou mieux encore, si cela se présente, avec un livre terminé dans lequel les informations utiles du document abandonné sont manquantes. À noter que cela représente beaucoup de travail, tant pour la relecture que pour la mise en œuvre des fusions, qui, à mes yeux de personne expérimentée dans l'usage de MediaWiki, est un processus compliqué. De plus, il ne peut être fait que par des personnes ayant les outils d'administrateur. C'est-à-dire quatre personnes, dont deux ou trois actives dans ces récentes discussions.
:::# Dans la librairie Wikilivres, il y a ensuite un étage dans lequel chaque personne inscrite peut bénéficier d'un espace personnel, pour se présenter, stocker des informations, mais également travailler sur des projets personnels d'écriture. En tenant compte de ceci, on peut alors aussi imaginer de déplacer les ouvrages inachevés de la pièce principale à l'entrée de la librairie, vers ces différents locaux selon leurs auteurs respectifs.
:::Face à ces trois espaces, la question qu'il reste à se poser est de savoir si et dans quelles condition, on peut déplacer les ouvrages inachevés vers une salle d'archive, ou dans les locaux personnels des auteurs ? Cela en signalant que ce déplacement peut être fait très facilement et par toutes les personnes qui le souhaitent, même sans inscription à la bibliothèque. Ce qui est un grand avantage par rapport à la fusion.
:::Pendant ce temps, à l'accueil de la bibliothèque Wikibook, on invite les visiteurs à parcourir la pièce avec les ouvrages terminés, mais également la pièce archive, où ils peuvent trouver des ouvrages inachevés, au cas où ils veulent poursuivre leurs développements, ou trouver des ressources intéressantes pour leurs travaux personnels. On les informe ensuite aussi qu'avec leur inscription, ils bénéficient d'un local pour leurs activités personnelles et notamment pour y placer les ébauches d'ouvrages qu'ils désirent rédiger.
:::Que penses-tu de mon propre rêve ? Est-il si différent du tien ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:17 (CEST)
::::Et les autres ? @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Fourmidable|Fourmidable]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:Grondin|Grondin]]. Que pensez-vous de nos rêves ? Et, si le mien vous parle, quelles seraient vos propositions pour orienter les déplacements de pages à l'abandon entre un espace d'archivage (qui pourrait être créé) et des espaces utilisateurs ? Le nombre d'octets ? La finalisation d'une section ou d'un chapitre ? Quelles autres possibilités ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:37 (CEST)
::::: Bonjour, a priori ça doit se régler au cas par cas sur [[Wikilivres:Demandes de suppression]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]])

::::Bonjour,
::::La structure de Wikibook est parfaite grâce à sa vitrine.  Pour moi, il y a juste un problème sur les listes sur la droite : Arts, Loisir, Histoire, Langues, Technologie, Informatique, Sciences, Sciences humaines. Ces listes ne devraient donner accès qu'aux livres terminés.
::::Ces listes actuelles pourraient être caché dans un espace création qui pourrait être posé avec le lien Nouveauté en bas de la page.
::::Pour la gestion des livres, il suffirait qu'une ou deux personnes parcourent la bibliothèque et proposent quelques suppressions chaque semaine, pour en quelques mois éclaircir la situation. Je pense que l'on peut faire confiance aux administrateurs pour gérer la situation des livres, ceux qui sont à garder et les autres. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 18:30 (CEST)
:::::@[[Utilisateur:JackPotte|JackPotte]]. Le cas par cas est ce que nous faisons depuis toujours. Cela nous amène à la situation actuelle qui semble ne pas convenir à tous. En tout cas, c'est mon cas. Ici comme sur Wikiversité. Quand, en navigant sur le site, une personne tombe neuf fois sur dix sur des pages presque vides et inachevées, comme c'est le cas sur Wikilivre, elle se dit : c'est quoi ce site ? Elle passe alors à autre chose de plus vivant, genre https://zestedesavoir.com/ ou autre. Sans changements éditoriaux, je pense que la situation évoluera.
:::::@[[Utilisateur:Xhungab|Xhungab]], on peut faire comme tu dis. Cependant, la charge de travail repose sur une double action, la proposition d'abord et le traitement ensuite. Un traitement qui finalement repose sur les épaules des administrateurs. Nous ne sommes que des bénévoles peu nombreux et pas toujours disponibles.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 19:13 (CEST)
:Créer un livre, le ranger, en établir un plan, le catégoriser n'est pas un travail négligeable... Un travail que d'autres personnes intéressées pour écrire sur le sujet n'ont pas à refaire 🤷‍♂️ ...

== Petite proposition indécente à Lionel ==

Bonjour  Lionel,

Je souhaiterais te proposer un petit projet.

a) Dans la page principale de wikibook tu créés une page &quot;Espace pour les auteurs&quot;. Tu insères cette page devant le lien &quot;Nouveautés&quot;.
.

b) Tu copies dans cette page la liste des liens qui se trouvent en haut à droite dans la nouvelle page. (Arts, Loisirs, ...) Tu ne les modifies pas dans la page principale.
.

c) Dans la nouvelle page tu peux écrire un texte du genre.
Dans cette page, vous trouverez la liste de tous les livres disponibles sur Wikibook. Vous trouverez en particulier des livres en construction et vous pourrez entrer en contact avec les auteurs. Vous trouverez aussi des livres en construction sans auteur actif que vous pourrez compléter.


Cela est la première étape, si l'aventure t'intéresse. En fait tu ajoutes juste une page, que tu pourras supprimer si les besoins se font sentir. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 12:25 (CEST)

:La proposition est très décente @[[Utilisateur:Xhungab|Xhungab]] 
:Mais avant toute choses le plus prudent est de lancer une prise dé décision pour s'assurer d'un concesnsus en faveurs des changements dont nous débatons actuellement.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 août 2026 à 15:40 (CEST)
::Toutes ces actions seront réversibles. On ajoute une page. Un problème, on la supprime. 
::On fait rapidement les changements, on attend trois jours. En cas de problème, on supprime tout. Il suffira de s'excuser et de dire que l'on ne savait pas que l'on n'avait pas le droit. 
:: Un espace pour les lecteurs et un espace pour les auteurs séparés.
::[https://fr.wikibooks.org/wiki/Utilisateur:Xhungab Nouvelle page wikibook][[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 16:49 (CEST)
:@[[Utilisateur:Xhungab|Xhungab]] , ma grand mère disait : faire et défaire, c'est toujours travailler. Pour les grand changements, on a coutume de faire un prise de décision composée des propositions, suivies de débats et d'un vote.
:En plus, certaines décisions nécessite un changement technique et ce n'est pas toujours facilement réversible. Comme créer un nouvel espace de nom pour y transfèrer une catégorie de pages  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 28 août 2026 à 03:07 (CEST)
::Merci pour ton aide. Tu comprends maintenant pourquoi toi tu es un administrateur et moi pas.
::.
::'''Oui, aujourd'hui Wikibook peut changer. Wikibook va changer.''' 
::.
::*  '''Le changement c'est Maintenant :''' [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']
::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 28 août 2026 à 08:33 (CEST)
:::Ton enthousiasme fait plaisir @[[Utilisateur:Xhungab|Xhungab]], et je serais en faveur d'un style plus épuré de notre page d'accueil en plus d'une méthodes de classement et de séparation des ouvrages terminé, en cours et abandonnés. Je pense qu'à terme, nous pourrions faire une proposition de changement à soumettre au reste de la communauté. Par chance, nous ne sommes pas nombreux, cela simplifire les discussions et le processus de décision. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 19:26 (CEST)
::::Cette page  [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook'''] propose la vitrine, les livres disponibles, les mini-livres disponibles pour les lecteurs. Les lecteurs ne seront en contact qu'avec les livres terminés.
::::.
::::En bas à côté des nouveautés, il y a l' '''[https://fr.wikibooks.org/wiki/Discussion_utilisateur:Xhungab Espace pour les auteurs]''', avec tous les livres du site rangés par thème ou par niveau d'avancement si on clique sur l'image. Sinon, il y a une liste de catégories art,...
::::.
::::Cette proposition sépare donc deux espaces. Un pour les lecteurs et un pour les auteurs. Il suffirait maintenant plus qu'à nettoyer l'espace auteurs. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 20:22 (CEST)
L'usage des catégories me semble aussi une manière très pratique de trier le contenu de Wikilivre. Malheureusement, ces pages ne sont pas très sexy du coup l'usage de type de code pourrait être utile :

{ {Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={ { #categorytree:Livres terminés|mode=pages} } } }

Avec le rendu ci-dessous :
{{Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={{ #categorytree:Livres terminés|mode=pages}}}}

On pourrait ainsi imaginer d'intégrer directement ce code dans la page d'accueil pour afficher une boite déroulante au lieu d'envoyer le visiteur en dehors de la page d'accueil. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:08 (CEST)

:Tu devrais créer la page Lioneltest01 dans ta page utilisateur. Copier le code de la page principale de wikibook.
:Puis faire les changements que tu juges nécessaires. Tu peux éventuellement faire plusieurs pages. Ensuite, tu mets cette page dans le bistro pour que l'on puisse voir le résultat. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 21:22 (CEST)
::Je devrais, tu devrais, il devrait, nous devrions ... =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:28 (CEST)
:::Chaque chose en son temps.
:::1. Débattre ici des idées de changements.
:::2. Mettre les choses en place pour leur réalisation, comme la mise à jour du modèle:boite déroulante en s'inspirant de celui de Wikipédia ou d'autres sites.
:::3. Quand il n'y a plus de nouvelle idée ici, créer une page genre :[[Wikilivres:Prise de décision/Nouvelle page d'accueil et gestion des abandons]] avec une description précise des projets de changements, et une éventuelle [[Accueil/projet|page de présentation du projet d'un nouvelle page d'accueil]]
:::4. Poursuivre les discussions et propositions si nécessaire.
:::5. Quand on a fait le tour, passer au vote.
:::6. Mettre les décisions en application. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:03 (CEST)
::::Je propose actuellement un projet qui se trouve sur ma page utilisateur. Pourrais-tu lancer une prise de décision sur ce projet. Je ne sais pas comment on fait une telle demande. Je suis prêt à présenter mon projet et à recevoir les critiques. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 22:16 (CEST)
:::::''Aide-toi le ciel t'aidera''. La bureaucratie, c'est pas mon truc. Et puis ça m'irrite un peu que tu enchaines des demandes de faire des choses qui ne demande pas les outils d'administrateurs. Raisons pour lequelles, je pense finalement que l'on gagnerait à appliquer la [[w:Do-ocratie|Do-ocratie]] qui a fait ses preuves dans le monde du libre dont les projets Wikimédia sont issus.
:::::Si tu as une idée et qu'elle ne demande pas des droits de modification que tu n'as pas, fait la et on se retrouve en page de discussion de la page de tes changements en cas de problèmes et pour d'éventuelle commentaire. Sans réaction, pense à ''qui ne dit mot conscent''.
:::::Si tes idées demandes les outils d'administrateurs, tu peux alors demander à un admin de le faire. Libre à lui de le faire ou pas et si ça lui plait, si il a envie, si il prend le temps. Nous sommes bénévoles... Il y a bien des gens payés par la fondation, mais comment dire... Disons qu'ils ne sont pas des plus serviables. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:57 (CEST)
::::::Excuse moi je pensais qu'il faillait être administrateur pour faire une demande de prise de décision. Je vais donc essayer tous seul. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 23:06 (CEST)
:::::::Ok @[[Utilisateur:Xhungab|Xhungab]], pas de soucis. On ne peut pas tout savoir =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 30 août 2026 à 01:45 (CEST)

== Wikilivres:Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''


Merci pour votre participation

[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 30 août 2026 à 00:43 (CEST)

:Bonjour @[[Utilisateur:Xhungab|Xhungab]]. Content de te revoir dans les murs de Wikiversité après nos échanges sur Wikilivres. Je comprends ton sentiment de solitude, je le ressens aussi souvent. Il faut l'accepter et ne pas se décourager pour autant. Nous avons la chance de fonctionner dans une organisation bénévole, dans laquelle personne n'est tenu de répondre à des demandes. De ce fait, les choses évoluent lentement et en fonction des disponibilités. Dis-toi aussi que la période estivale est toujours un moment d'acalmie dans la participation. Moi par exemple, quand il fait bon, je préfère passer du temps sur des occupations extérieures que devant un écran.
:Cela dit, tu dois garder 3 règles implicites qui sont fréquemment appliquées dans les projets Wikimédia.
:1. ''Qui ne dit mot consent''. Si les personnes ne réagissent pas, cela ne veut pas dire qu'elles ne lisent pas. Par économie de temps et pour les personnes trop occupées ou pas assez motivées pour s'investir, ne pas réagir est un signe de consentement implicite.
:2. ''Les absents ont toujours tort.'' Lorsque l'on fait les choses dans les règles de l'art, par exemple comme tu le fais en lançant une prise de décision pour opérer un changement significatif dans Wikilivres, aucune personne absente durant un processus de décision clôturé viendra remettre en cause les choses par la suite.
:3. La doocratie. Les wikis sont des espaces de libertés au niveau de l'amélioration des contenus, mais également de l'organisation et des formes de contenus. En dehors du vandalisme qui est bien contrôlé par des personnes telles que @[[Utilisateur:Crochet.david|Crochet.david]], toute initiative est souvent perçue comme bienvenue. @[[Utilisateur:Fourmidable|Fourmidable]], par exemple, depuis qu'il est administrateur, a fait de nombreuses améliorations dans Wikiversité sans demander l'avis de la communauté. Personne ne lui a reproché son investissement. Si quelque chose qu'il a entrepris ne plaît pas à quelqu'un, une discussion commence entre lui et cette personne pour chercher une entente.
:Voilà tout.
:Je te rejoins aussi sur le fait que ce qui est décidé et mis en place sur Wikilivres peut tout à fait servir d'exemple pour Wikiversité et vice versa. Je ne suis pas le seul à être administrateur dans les deux projets et cela aide beaucoup à la création d'une synergie entre les deux projets qui sont finalement très complémentaires. Cela n'est pas étonnant d'ailleurs lorsque l'on sait que Wikiversité est né de Wikilivres.
:Une belle fin de journée à toi et à tous ceux qui liront ce message. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:30 (CEST)
::Merci. Pour tes explications. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 6 septembre 2026 à 13:50 (CEST)
:::Avec plaisir. Pense aussi qu'il n'y a pas de combat dans les projets Wiki, mais un lent processus évolutif, sans fin programmée, et qui est pour moi l'un des meilleurs que je connaisse. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:57 (CEST)

== Les RAW sont arrivés, la rentrée peut commencer ! ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro de&amp;nbsp;septembre 2026 ({{numéro|296}}) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-09-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;
&lt;/div&gt;

'''C'est la rentrée'''

Après un numéro très dense en août en raison de la Wikimania, celui-ci est un peu plus léger car l'équipe s'est octroyée quelques vacances. Cela n'empêche pas le mouvement de continuer à vivre, avec une rentrée déjà animée ! Du côté des projets francophones, le Wiktionnaire vient de franchir le cap symbolique des sept millions d’entrées, tandis que Wikipédia continue de voir fleurir sondages et discussions sur son fonctionnement.

Une rentrée, donc, placée sous le signe de la construction collective : de nouveaux outils pour contribuer, de nouveaux espaces pour échanger, de nouvelles formes d’organisation… Ce numéro des RAW vous propose de faire le tour de cette actualité, avant de reprendre tranquillement le chemin des projets Wikimédia.

L'équipe de la rédaction a également commencé à réfléchir à un nouveau nom pour remplacer l'énigmatique « RAW ». N'hésitez pas à venir donner votre avis dans la [[:w:Discussion Wikipédia:RAW/Rédaction#Changement de nom|section dédiée]] !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia, des nouveaux outils et des articles de recherche

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : n'hésitez pas à suggérer des sujets ou participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]] !

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 septembre 2026 à 00:17 (CEST)

== Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés ==

J'ai posé une demande de prise de décision concernant le sujet suivant.


[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Modifier_le_contenue_de_l%27espace_Nouveaut%C3%A9s Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés]

Merci pour votre participation [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 9 septembre 2026 à 14:38 (CEST)

== '''Décision''':Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''

'''Décision pour : [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']'''

Résultats : 3 + Pour, un Neutre Neutre et un - Contre soit 60 % de + Pour par rapport au total des votes exprimés : la proposition est adoptée. Quelques propositions de reformulations et de nuances ont été faites qui pourront être prise en compte. Cdlt, VIGNERON * discut. 13 septembre 2026 à 18:27 (CEST)

Merci pour votre participation. Ma première proposition était un peu malhabile, mais grâce à vos interventions je pense que l'on a créé quelque chose de correct. '''Merci à tous''' [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 13 septembre 2026 à 20:22 (CEST)

== Je ne suis pas content tous seul. ==
'''Suite à l'installation de la nouvelle page de la Vitrine, je ne suis pas content, j'ai pris 24h pour réfléchir.
'''

J'avais posé une demande de prise de décision concernant le sujet suivant.


'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace auteurs sur la page d'accueil]'''


'''Créer un espace lecteurs''' : Où est l'espace pour les lecteurs?


 Découvrir la bibliothèque
 Livres terminés - Mini Livres - Tous les livres


'''Dans une bibliothèque''', un livre est disponible ou indisponible. C'est chez l'auteur ou chez l'imprimeur qu'un livre est terminé.


'''Je suis un nouveau sur Wikilivre'''. Je vois, &quot;Découvrir la bibliothèque&quot;, je vais directement dans &quot;'''[[Wikilivres:Tous les livres|Tous les livres]]'''&quot;. Je me retrouve dans un labyrinthe qui me balade de répertoires en répertoires pour finir sur une ébauche abandonnée depuis 5, 10, 20 ans.


Je ne suis pas content. J'avais proposé à l'administrateur un changement en 2 minutes. Copier cette page dans la Vitrine, [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab La Nouvelle Vitrine]. Il a décidé de passer plusieurs heures à modifier la prise de décision. Je ne suis pas content. Je suppose que je suis le seul. 


Donc : '''Je ne suis donc pas content tous seul.''' mais je me soigne. Un pan bagnat et une tourte aux blettes.

Merci de m'avoir lu [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 septembre 2026 à 10:51 (CEST)</text>
      <sha1>8yq8xa7ibtdi6qsp1yiw8piy0fh6v43</sha1>
    </revision>
    <revision>
      <id>772347</id>
      <parentid>772346</parentid>
      <timestamp>2026-09-17T08:53:26Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <comment>/* Je ne suis pas content tous seul. */</comment>
      <origin>772347</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="72881" sha1="17sr016pbrjvnqw6wx7yo0j98qlqeiq" xml:space="preserve">&lt;noinclude&gt;{{Wikilivres:Le Bistro/En-tête}}&lt;/noinclude&gt;

== Le meilleur à Wikilivres pour 2026 ! ==

Je crée la page du bistrot 2026 en transmettant mes vœux. Bonne année éditoriale à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 janvier 2026 à 06:05 (CET)
:Merci, meilleurs vœux ! [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 16 janvier 2026 à 09:53 (CET)
::Meilleurs vœux pour 2026 !
::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 janvier 2026 à 20:13 (CET)
:::Meilleurs vœux pour 2026
:::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 janvier 2026 à 11:56 (CET)
::::Bonne année et bonnes lectures et écritures !
::::[[Utilisateur:Matthius|Matthius]]


== Page orpheline du livre : États généraux du multilinguisme dans les outre-mer ==

Bonjour,

Le livre &quot;États généraux du multilinguisme dans les outre-mer&quot; a laissé quelques pages orphelines. Ces pages orphelines ont été recopiées ou regroupé dans le texte du livre. Elles font donc doublons.

Je montre dans ce livre [[Wikilivres:Feuilles dupliquées orphelines]] cette suite de pages orphelines accompagnée par la page où elles ont été recopiées.

Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 10 février 2026 à 19:57 (CET)

:@[[Utilisateur:Xhungab|Xhungab]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], bonjour. Je vois que l'on est en campagne de gestion de pages orphelines et je me pose la question de savoir si on doit les supprimer une fois réintégrées ailleurs ou les supprimer ? Je vois que les deux cas de figure ont été mis en œuvre précédemment. L'avantage de la fusion est de conserver l'historique des modifications, mais je ne suis pas habitué à le faire. Si quelqu'un d'entre vous pouvait m'indiquer une page d'explication, cela m'aiderait à m'y mettre. Ensuite, je me demande si la fusion a vraiment un sens lorsque c'est la même personne qui a créé la page orpheline et la nouvelle au contenu copié collé pour insertion ? Qu'en pensez-vous ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:02 (CET)
:::Ça fait plaisir de voir une personne s'investir dans la maintenance de Wikilivres =). Soit le ou la bienvenu.e. J'attends les avis des autres administrateurs pour te donner mon soutien @[[Utilisateur:Xhungab|Xhungab]]. @ bientôt. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:27 (CET)
:::: @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]] bonjour, je n'ai pas compris en quoi &quot;deux cas de figure ont été mis en œuvre précédemment&quot; : si la page est vide on la supprime et si elle a au moins une phrase valable on la fusionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:26 (CET)
::::Concernant l'auteur pour moi cela importe peu, car on souhaite conserver chaque élément permettant de prouver une primauté du droit d'auteur (par exemple pour ne pas accuser un contributeur d'avoir copié un site miroir de sa page supprimée). [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:30 (CET)
:::::Désolé [[Utilisateur:JackPotte|JackPotte]], je n'avais pas vu que les pages que tu as supprimées étaient vides. La règle est donc supprimer si vide et fusionner si non. Tu peux me conseiller une page d'aide pour oppérer les fusions ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:34 (CET)
::::::Salut,
::::::Pour la fusion d'historique :
::::::* soit [[Wikilivres:Le guide de l'administrateur#Fusionner deux pages|Utiliser la page spéciale pour cela]] (cependant ne fonctionne pas toujours),
::::::* soit [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages utiliser l'ancienne méthode] qui reste toujours valable quand la première ne fonctionne pas.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 13 février 2026 à 19:34 (CET)
:::::::Salut @[[Utilisateur:DavidL|DavidL]]. Je viens de tester l'outil fusionner avec les deux pages suivantes
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes/Contexte]]
:::::::vers
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes]]
:::::::Et j'ai le message suivant :
:::::::« La période spécifiée chevauche les versions préexistantes de la page de destination. »
:::::::Tu peux m'expliquer si tu as le temps ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 00:19 (CET)
::::::::Salut @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]]
::::::::Dans ce cas, j'utilise [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages l'ancienne méthode].
::::::::# Renommer A (page qui n'existera plus) vers B, sans laisser de redirection, et en cochant la case de suppression de B (case qui apparait après 1er clic sur le bouton Renommer) (&amp;rarr; l'historique de A est sur B, celui de B est supprimé)
::::::::# Supprimer B (&amp;rarr; l'historique de A et B sont supprimés)
::::::::# Restaurer B et cocher toutes les cases des versions (bouton &quot;Inverser la sélection&quot;) (&amp;rarr; restaurer l'historique de A et B)
::::::::# Effectuer une modification de la version finale de la page à afficher, trouvée dans l'historique.
::::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 février 2026 à 08:29 (CET)
:::::::::Merci @[[Utilisateur:DavidL|DavidL]]. Ça m'a l'air bien compliqué tout ça. Et avec toute les pages qu'il faut faire, ça risque de prendre un certain temps. Je manque de courage en pensant que c'est juste pour ajouter une ligne dans l'historique des versions. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 14:51 (CET)
::::::::::Finalement, dans l'exemple que j'ai pris, la fusion n'avait aucun sens puisque le contenu du doublon que j'ai finalement supprimé était intégralement repris dans l'autre doublon par le même auteur. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 22 août 2026 à 23:55 (CEST)
:::::::::::Désolé @[[Utilisateur:Xhungab|Xhungab]]. Je ne comprends rien à l'outil de fusion et je ne trouve rien qui me permet de comprendre sur le net. Une vidéo avec exemple des différents cas de figure serait bien, mais je ne trouve pas. Je vais donc laisser ce travail à ceux qui savent utiliser l'outil.
:::::::::::En revanche, j'ai remarqué que certains doublons, comme dit précédemment, ne nécessitent pas de fusion puisqu'il s'agit de pages qui ont été créées sans aucune autre modification, puis, copiées par le même auteur dans une autre page créée avec un autre nom, au lieu de faire un renommage. Il faudrait donc que je prenne le temps de parcourir la liste pour repérer ces cas de figure avant de supprimer le premier doublon. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 01:27 (CEST)
::::::::::::Merci pour ton aide. Actuellement ces pages ont été en quelque sorte neutralisées. Donc fais de ton mieux, mais ne te tracasse pas elles ne posent plus de problème. Encore merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 09:13 (CEST)
:::::::::::::OK @[[Utilisateur:Xhungab|Xhungab]], merci pour l'info. Au fait comment as-tu fais pour les détecter ? En parcourant les pages de la catégorie orphelines et en vérifiant celles qui sont doublons ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 12:36 (CEST)
::::::::::::::Dans la catégorie pages orphelines, il y avait un lien sur une page.
::::::::::::::Je choisissais une phrase et je recherchais avec la fonction recherche de wikibook où se trouvait cette phrase. Si c'était un doublon, j'avais un lien vers la nouvelle page. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 12:48 (CEST)
:::::::::::::::Intelligent. Tu poserais pas ta candidature d'admin !? Ici, avec @[[Utilisateur:Fourmidable|Fourmidable]] et puis sur wikiversité aussi. Ça pourrait aider pour le projet des 20 ans., si tu comote toujours t'investir. On est en sous effectif dans les deux projects et les communautés me semblent plus ouverte que sur Wikipédia. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 13:48 (CEST)
::::::::::::::::Je ne souhaite pas devenir un administrateur. Pourquoi ? Si on me donne du pouvoir, je l'utiliserais. Par la suite, ceux qui m'ont accordé le pouvoir auront le choix entre pleurer, nous quitter ou me mettre en arrêt de travail. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 14:59 (CEST)
:::::::::::::::::Ah ah ah. T'es si foireux que ça !? Ou peut-être as-tu eu des expériences antérieures ? Dans tous les cas, c'est super de ta part de pouvoir t'auto évaluer.
:::::::::::::::::Ceci dit, le système de demander au administrateurs de faire des tâches qu'il faut expliquer est une perte de temps et d'efficacité. On pourrait d'ailleurs penser à attribuer les droits temporairement pour effectuer certaines tâches. Je me demande si ça se fait déja quelque part ? Si oui, on pourrait s'en inspirer pour mettre le système en application sur Wikilibres et Wikobersité. T'en penses quoi @[[Utilisateur:Xhungab|Xhungab]] ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 15:40 (CEST)
::::::::::::::::::Oui, je pourrais obtenir des droits temporaires par rapport à un projet. Par exemple 2 projets
::::::::::::::::::Premier projet :  Supprimer toutes les feuilles volantes. Ce sont des feuilles tests très bien faites mais qui n'appartiennent à aucun livre. Je crois qu'il y a actuellement, Feuilles volantes – 54 P. 
:::::::::::::::::: 
:::::::::::::::::: Deuxième projet : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Pages_anciennes Les pages les plus anciennement modifiées]
::::::::::::::::::Supprimer tous les livres entre 2006 et 2010 qui sont à l'abandon. Parfois il sera possible de sauvegarder un livre en supprimant les chapitres vides, ce qui nous permettra de créer un livre complet. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 16:19 (CEST)
Donc, tu as du temps à consacrer à ce genre de maintenance ? Ce serait bête de ne pas en profiter. Reste à voir à présent si les autres administrateurs et bureaucrates seraient d'accord de t'octroyer les droits, tout en approuvant les deux projets que tu proposes. Cependant, je ne suis pas un grand fan des suppressions, je préfère de loin renommer les pages pour les placer en dehors de l'espace principal de sorte à ce que les auteurs puissent toujours les retrouver. Pour ça, un bon espace, c'est les sous-pages des principaux auteurs. Cela pourrait ainsi s'appliquer aux feuilles volantes et aux projets d'écriture abandonnés qui sont suffisamment développés pour justifier une conservation. L'avantage de cette méthode est qu'elle ne demande pas d'avoir les outils d'administrateurs. Faudrait voir maintenant dans quel cas on supprime et dans quel cas on renomme. On pourrait par exemple définir un nombre d'octets ou de caractères, question d'avoir un critère standard et accepté par tous. Qu'en penses-tu [[Utilisateur:Xhungab|Xhungab]] ?
:En fait je préfère continuer comme actuellement. Proposer mes services  pour améliorer wikibook sans avoir aucun droit. De cette manière, si je propose quelque chose d'incongru, comme cela est déjà arrivé, il suffit de neutraliser ma demande. Merci à ceux qui me suivent sur ce travail.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 01:52 (CEST)

:Je comprends @[[Utilisateur:Xhungab|Xhungab]]. Mais précisément, déplacer une page à l'abandon dans une sous-page l'espace utilisateur de l'auteur principal, cela ne demande justement aucun droit et tout le monde peut le faire, toi en premier puisque tu sembles actif à ce niveau. C'est pour ça que je te demande ton avis : que penses-tu de l'idée de déplacer les pages comme je viens de le décrire, plutôt que de les supprimer ? Je viens de soumettre l'idée dans une nouvelle discussion ci-dessous. Tu peux donner ton avis là-bas si tu veux. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 02:27 (CEST)

== archive.today ==
''Voir [[:w:Wikipédia:Le Bistro/21 février 2026#archive.today]].''

Ce site pose apparemment des problèmes de sécurité, il faudrait le remplacer au plus vite si possible, et sinon désactiver les liens.

[[Utilisateur:SyntaxTerror|SyntaxTerror]] ([[Discussion utilisateur:SyntaxTerror|discussion]]) 21 février 2026 à 13:07 (CET)
:Salut SyntaxTerror,
:* 0 liens vers archive.today : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.today]
:* &lt;s&gt;18&lt;/s&gt; 0 liens vers archive.is [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.is]
:* 0 liens vers archive.li [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.li]
:* 0 liens vers archive.ec [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ec]
:* 0 liens vers archive.ph [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ph]
:* 0 liens vers archive.fo [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.fo]
:* 0 liens vers archive.md [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.md]
:* &lt;s&gt;1&lt;/s&gt; 0 liens vers archive.vn [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.vn]
:* 0 liens vers archive.closed.social [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.closed.social]
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 21 février 2026 à 16:14 (CET)
::Merci pour vos efforts ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:22 (CEST)

== demande aide pour sortir du mode &quot;ébauche&quot; ==

je viens de terminer mon livre ... ci dessous. J'ai compris qu'il fallait le signaler comme n'étant plus au stade &quot;ébauche&quot;  commente faire   Merci

https://fr.wikibooks.org/w/index.php?title=Essai_pour_un_mod%C3%A8le_de_psychisme_objectif&amp;action=info#mw-pageinfo-header-basic [[Utilisateur:Clopeau|Clopeau]] ([[Discussion utilisateur:Clopeau|discussion]]) 17 mars 2026 à 08:20 (CET)
:Bonjour, quand je regarde ''[[Essai pour un modèle de psychisme objectif]]'', sa complétude permettrait en effet de le sortir des ébauches, mais il semble plutôt d'agir d'un travail de recherche que d'un livre pédagogique sur un sujet sourcé comme reconnu.
:Donc en vertu de [[Wikilivres:Principes fondateurs|notre charte]], je propose de le déplacer sur {{WV|Recherche:Accueil}}. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 18 mars 2026 à 09:06 (CET)

== Don à wikipédia depuis wikilivres ==

{{BlocCitation|La Wikimedia Foundation est l’organisation à but non lucratif qui soutient Wikipédia, '''les autres sites de connaissance libre de Wikimédia''', et sa mission de connaissance libre pour tous.|auteur=[https://wikimediafoundation.org/fr/give/donor-frequently-asked-questions/ FAQ], {{g|Qu'est-ce-que la Wikimedia Foundation ?}}}}
Le lien de donation https://donate.wikimedia.org/w/index.php?title=Special:LandingPage&amp;country=FR&amp;uselang=fr&amp;wmf_medium=sidebar&amp;wmf_source=donate&amp;wmf_campaign=fr.wikibooks.org '''ne parle que de wikipédia'''. '''Où sont passés les autres projets ?''' Vont-ils être fermés sauvagement par la fondation comme Wikinews récemment ? La suite au prochain épisode d{{'}}''Highlander-Wikimedia'' : {{g|À la fin, un seul ''projet'' survivra.}} ... &amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 12 mai 2026 à 11:26 (CEST)

:Bonjour,
:Je pense personnellement que les wikis ont des problèmes.
:Il y a une vingtaine d'années, il représentait l'innovation la plus ambitieuse.
:Aujourd'hui, les wikis me semblent dépassés de tous les côtés.
:           wiki = Erreurs 404 (&quot;Page introuvable&quot;)
:Problèmes:
:* 568 livres déclarés. 50 livres terminés (combien sont obsolètes)
:* 21 527 pages déclarées. 20 000 pages orphelines. (Papa t'est où?)
:Solution:
:* Où sont les cours sur YouTube qui utilisent un wikibook comme référence?
:Voilà mon idée sur les wiki.
:* https://fr.wikiversity.org/wiki/Facult%C3%A9:Droit
:* https://fr.wikiversity.org/wiki/D%C3%A9partement:Introduction_au_droit
:&lt;nowiki&gt;~~~~&lt;/nowiki&gt; [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 12 mai 2026 à 13:50 (CEST)
::Ce serait intéressant de mentionner tous les projets actifs oui. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:23 (CEST)
::: En même temps, le message est plutôt franc étant donné que l'argent des dons n'est pas investi dans le développement de Wikilivres (cf [[:meta:Community Wishlist Survey]] et les réponses à nos tickets Phabricator).
::: Par ailleurs, concernant la qualité des contenus, cela a toujours était un sujet depuis le début, et nous disposons tout de même de plusieurs pages spéciales dans [[Wikilivres:Maintenance]] pour y remédier afin que le lecteur n'ait pas la sensation de se faire empapaouter en se retrouvant sur des ébauches bien placées dans Google. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mai 2026 à 08:48 (CEST)

== La catégorie SI est pleine ! ==

Bonjour tous,

Pour info, la [[:Catégorie:Suppressions immédiates demandées]] contient 9 pages.

Wikilivresquement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 14 juin 2026 à 15:36 (CEST)

:Elle est maintenant vide, merci à ceux qui s'y sont collés ! {{Sourire}} [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 24 juin 2026 à 17:17 (CEST)

== Un RAW bien frais pour juillet ==

{| style=&quot;width:100%;&quot;
| valign=&quot;top&quot; align=&quot;center&quot; style=&quot;border:1px gray solid; padding:1em;&quot; |
{| align=&quot;center&quot;
|-
| style=&quot;text-align: center;&quot; | &lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:4.5em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em;text-align:center; color: #fff; font-style:italic;&quot;&gt;Regards sur l’actualité du mouvement Wikimédia.&lt;/div&gt;
&lt;div style=&quot;text-align: center;&quot;&gt;{{#ifeq:{{FULLPAGENAME}}|Wikipédia:RAW/Rédaction}}&lt;/div&gt;
&lt;/div&gt;&lt;br /&gt;
&lt;hr /&gt;
&lt;div style=&quot;font-size:12pt; font-family:Times New Roman; text-align:center;&quot;&gt;[[w:fr:Wikipédia:RAW/2026-07-05|&lt;span style=&quot;color:darkslategray;&quot;&gt;Le numéro de juillet 2026 est sorti.&lt;/span&gt;]]&lt;/div&gt;
&lt;hr /&gt;&lt;br /&gt;

|- style=&quot;text-align: center;&quot;
| &lt;span style=&quot;font-size:12pt; font-family:Times New Roman;&quot;&gt; '''❖ Au menu de ce numéro ❖'''&lt;/span&gt;
|- style=&quot;font-size:10pt; font-family:Times New Roman; text-align:center;&quot;
| &lt;div style=&quot;text-align:center; column-count:1; column-width:28em; vertical-align:top;&quot;&gt;

'''L'Édito'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Édito|Fêtons notre mouvement !]]

'''Échos francophones'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Résidence|Un nouveau vigneron dans la résidence]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Logo_WP25|Wikipédia en français aux couleurs des 25 ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#DAF|Wikipédia dans le ''Dictionnaire de l'Académie française'']]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Millésime_Wiktionnaire|Quelles sont les nouvelles entrées en français sur le Wiktionnaire ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ADS|Relance de l'Article de la semaine]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#sans_pagEs|Le projet des sans pagEs fête ses dix ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#contributions_rémunérées|Faut-il faire évoluer les règles sur les contributions rémunérées ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#wikification|Le mois de la wikification fait son retour pour une septième édition]]

'''Ailleurs dans le mouvement'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Txikipedia|Txikipedia franchit le cap des 10 000 articles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Concours_santé_2026|Un concours sur la santé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Commons_et_IA|Commons se penche sur l'IA]]

'''Nouveautés techniques et outils'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#VIZWP|VIZWP : un outil pour visualiser les lacunes dans les sujets climatiques sur Wikipédia, mais pas que…]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#AI_Source_Verification|Examiner la vérifiabilité grâce à l'IA ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Icônes|Les icônes de l'interface ont changé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Sous-références|Ça y est, les sous-références sont là]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ConvoCompass|ConvoCompass, pour moins d'attaques personnelles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LSV-Tools|LSV-Tools : faciliter la gestion des anecdotes « Le saviez-vous ? »]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LegendAndDot|Semi-automatiser l'ajout de ponctuation dans les légendes d'images]]

'''Du côté de la recherche'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#COMSAV|COMSAV : la contribution à Wikipédia fait-elle d'un ensemble d'individus un ensemble de pairs ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#JourneyMap|Où commence la contribution et où s'arrête-t-elle ?]]

'''Le POV'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Le_POV|Guide survie pour la Wikimania 2026]] par Trizek

'''L'Atelier'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Atelier|Le point sur la diversité de genre dans les articles]] par PAC2

'''L'Analyse'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Analyse|Larry Sanger is back... and fired!]] par Madelgarius, Trizek et Jules*

'''L'interview'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'interview|Pronoia : de Byzance aux réseaux sociaux, un œil sur Wikipédia et le monde]] par Antimuonium

'''Le wik’hit-parade'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Wikit|Articles les plus vus en juin 2026]] par Ælfgar

&lt;/div&gt;
|-
| style=&quot;font-family:Times New Roman; text-align:center; font-size:90%;&quot; | [[w:fr:Wikipédia:RAW/2026-07-05|Lire tout le numéro]]
|-
| valign=&quot;top&quot; colspan=&quot;2&quot; style=&quot;padding:0.5em; font-family:Times New Roman;text-align:center; font-size:100%;&quot; |
Venez rédiger le prochain numéro, y parler de ce qui se fait dans votre communauté : [[w:fr:Discussion_Wikipédia:RAW/Rédaction|Salle de rédaction]].&lt;/br&gt;Les anciens numéros sont retrouvables [[w:fr:Modèle:Palette RAW|ici]].
|-
|}
|}
&lt;div style=&quot;margin-top:10px; font-size:90%; padding-left:5px; font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif;&quot;&gt;[[w:fr:Wikipédia:RAW/Inscription|Abonnez-vous !]] [[Utilisateur:L&amp;#39;embellie|L&amp;#39;embellie]] ([[Discussion utilisateur:L&amp;#39;embellie|discussion]]) 5 juillet 2026 à 01:53 (CEST)&lt;/div&gt;

== Les RAW en mode fiesta sur la Wikimania ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro d'août 2026 (n°295) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-08-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;&lt;/div&gt;

'''Un numéro exceptionnel'''

La conférence Wikimania s'est achevée le 25 juillet. Que vous ressentiez de la frustration (si vous n’avez pas pu y assister) ou du [[:w:Wikipédia:Wikispleen|wikispleen]] (si vous y étiez et que vous avez du mal à digérer que ce soit déjà fini), l’équipe des RAW n’a pas ménagé ses efforts pour vous proposer un numéro XXL qui revient en long, en large et en travers sur cet événement qui le mérite bien. Comptes-rendus, témoignages, entretiens, il y en aura pour tous les goûts ! Le numéro est aussi exceptionnel par le nombre de rédactrices et de rédacteurs qui y ont participé {{incise|merci !|stop}} 

Au-delà de Wikimania, l’actualité wikimédienne est loin d’être paisible cet été. Nous vous proposons donc aussi de revenir en détail sur la crise qui secoue la fondation Wikimédia autour de la reconnaissance du syndicat Wiki Workers United (WWU). Nous aurons probablement l’occasion de couvrir la suite de cette histoire dans le prochain numéro. D’ici là, bonne lecture !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia et des nouveaux outils

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Dossier spécial Wikimania&lt;/span&gt;'''

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les POV&lt;/span&gt;'''&lt;br&gt;— Ma Wikimania : la joie, l'inquiétude et la raison d'être&lt;br&gt;— Témoignages : regards sur la Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;L'Analyse&lt;/span&gt;''' — La crise s'intensifie après le refus de la WMF de reconnaître le syndicat WWU

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Comptes-rendus&lt;/span&gt;'''&lt;br&gt;— Une Wikimania sous le signe de la jeunesse&lt;br&gt;— Sur les conséquences de la définition de « wikimédien·ne »&lt;br&gt;— Petit tour d’horizon de la créativité wikimédienne&lt;br&gt;— CultureStrong : respecter les savoirs des Premières Nations sur les plateformes Wikimédia&lt;br&gt;— Des événements techniques à Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Interviews&lt;/span&gt;'''&lt;br&gt;— Ses goûts, sa Wikimania, sa prochaine tournée... : Baby Globe nous dévoile tout !&lt;br&gt;— Jules*, notre Wikimédien de l'année : comment rendre compte du changement climatique tout en protégeant l'encyclopédie

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : si un sujet vous tient à cœur, n'hésitez pas à proposer une idée d'article ou à participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]]. Toutes les contributions sont les bienvenues, quel que soit votre wiki d'origine ! &lt;span class=&quot;smiley&quot;&gt;[[Image:Face-smile.svg|20px|Sourire|alt=Émoticône sourire]]&lt;/span&gt;

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 août 2026 à 00:28 (CEST)

== Bientôt les 20 ans de Wikiversité ==

Bonjour.

Un petit message de « débauchage » dans le cadre d'un projet d'amélioration de Wikiversité. Comme dit la chanson : « On n'a pas tous les jours vingt ans ! » Plus d'infos [[v:Wikiversité:La_salle_café/août_2026#Améliorer_Wikiversité_pour_ses_vingt_ans_d'existence|dans la salle café du projet]].

Belle fin de journée à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 août 2026 à 00:26 (CEST)

== [[:Catégorie:Suppressions immédiates demandées|Série de demandes de suppression immédiate]] ==

Bonjour,

La [[:Catégorie:Suppressions immédiates demandées]] est de nouveau pleine, mais cette fois, il semble qu'elle ait été remplie par le seul {{U|Xhungab}}.

Cordialement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 16 août 2026 à 14:56 (CEST)
:{{fait}} Bonjour, oui c'était effectivement un ensemble d'ébauches abandonnées. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 17 août 2026 à 10:38 (CEST)
::Merci pour votre aide [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 août 2026 à 14:26 (CEST)

== Deux idées à débattre ==

Bonjour.

Vu le travail de traitement des pages et livres abandonnés et suite à une discussion avec @[[Utilisateur:Xhungab|Xhungab]] reprise ci-dessous, j'aimerais soumettre deux idées à la communauté Wikilivres.

'''La première idée''' est de déplacer toutes les pages et livres dont le développement est abandonné depuis longtemps en sous-page de l'auteur principal tout en laissant un message sur sa page de discussion avec un lien pointant vers la sous-page en question. Ce message pouvant faire l'objet d'un modèle.

Avantage : 1. Pas besoin d'être admin pour faire ce genre de maintenance. 2. Pas de risque de frustrer un auteur ni de perdre de vue des informations intéressantes. 3. Ceci dans le but d'améliorer l'apparence de Wikilivres au niveau du contenu visible sur l'espace de nom principal.

Nécessité : 1. Créer un modèle à placer sur la page de discussion de l'auteur principal après déplacement. 2. Définir la durée d'abandon des pages à déplacer.

'''La deuxième idée''' est de donner les outils d'administrateurs à des personnes qui ne veulent pas endosser cette responsabilité à long terme et de manière continue, mais qui sont d'accord d'en faire usage dans le cadre d'un projet de maintenance temporaire. Cela pourrait être utile pour @[[Utilisateur:Fourmidable|Fourmidable]] s'il le souhaite, à moins qu'il se décide à déposer sa candidature pour une nomination définitive. Ce qui serait une bonne idée, je trouve.

Qu'en pensez-vous @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Grondin|Grondin]] ?

Une prise de décision est-elle nécessaire si on décidait une mise en application ?

Bien à vous tous,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 01:50 (CEST)

:Bonjour,
:J'ai proposé une liste de livres à supprimer
:https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate
:Doit-on réellement les garder ? ;) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 10:21 (CEST)
::Quel est l'avantage de la suppression par rapport au déplacement @[[Utilisateur:Xhungab|Xhungab]]? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:56 (CEST)
:::En déterminant un contenu minimum, on peut faire le tri de ce que l'on supprime et ce que l'on déplace. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:58 (CEST)
::::Bonjour,
::::Les droits administrateurs temporaires sont difficiles à gérer : un bureaucrate peut attribuer le status administrateur mais pas le retirer.
::::Concernant les critères suppression ou renommage, je propose :
::::* (cas 1) Une page qui ne contient vraiment aucun texte (ex : seulement des liens rouges) --&gt; suppression
::::* (cas 2) Une page avec quelques phrases significatives récupérables --&gt; soit (a) tenter de fusionner dans un livre qui aborde le même sujet ou sujet connexe, soit (b) renommer en sous-page de l'auteur si aucun livre pour la fusion ne convient
::::* (cas 3) Une page avec plus de contenu que (cas 2) --&gt; conserver
::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 24 août 2026 à 19:33 (CEST)
:::::Salut @[[Utilisateur:DavidL|DavidL]]. Oui, c'est raisonnable. Reste que la fusion, c'est compliqué. J'ai essayé, mais je ne comprends rien. Une vidéo m'aiderait à comprendre, mais j'en ai pas trouvé. Ensuite, si on garde, genre un livre abandonné depuis plus de trois ans avec un chapitre entamé sur cinq prévus, par exemple, on le laisse dans l'espace principal, ou on le déplace vers l'espace utilisateur de l'auteur ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 25 août 2026 à 00:38 (CEST)
::::::Pour ce cas je propose de le fusionner si possible, comme (cas 2)(a) ; sinon le conserver, comme (cas3) afin qu'un utilisateur motivé puisse reprendre le livre.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 25 août 2026 à 08:36 (CEST)
:::::::Ok. Es-tu à l'aise avec la fusion @[[Utilisateur:DavidL|DavidL]] ? Car c'est une solution intéressante, mais je n'y arrive pas. Il y a toujours un message que je ne comprends pas et suite à quoi je préfère arrêter. Serais-tu dispo pour m'expliquer comment faire durant un appel vidéo ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:30 (CEST)
::::::::Bonjour {{Mention|Lionel Scheepmans}}, je suis très favorable à tes deux idées ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 août 2026 à 15:39 (CEST)
:::::::::Ok @[[Utilisateur:Fourmidable|Fourmidable]], je me dis qu'il serait encore bien d'avoir les avis de @[[Utilisateur:JackPotte|JackPotte]], voir de @[[Utilisateur:Grondin|Grondin]], s'ils trouvent le temps nécessaire pour le faire. Et puis, on peut penser tout doucement à créer une page pour fixer des décisions en votant si nécessaire pour confirmer l'adhésion générale ou grandement majoritaire.
:::::::::C'est curieux, je voulais travailler sur Wikiversité et finalement je me trouve plus actif sur Wikilivres. Mais les enjeux sont les mêmes et beaucoup de personnes actives ici le sont aussi sur Wikiversité, y compris parmi les administrateurs. En avançant dans Wikilivres, j'ai donc aussi l'impression que l'on avance sur Wikiversité.
:::::::::Au fait, fourmidable ? Tu ne serais pas intéressé, toi, de prendre un balai dans Wikilivres ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:27 (CEST)

== Demande d'aide pour amélioré Wikbook. Merci ==

* Actuellement j'ai proposé mes services pour améliorer wikibook. J'ai créé un partenariat informel avec des administrateurs, je propose des pages et des livres à supprimer. Ils décident soit de suivre ma demande, soit de la neutraliser. Je les remercie pour leur patience et leur aide.

- https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate


*Certain livres semblent trop avancé pour suivre cette procédure.

- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026

Dans cette page, je propose des livres trop avancés pour être traités rapidement. Il faut un vote pour que les demandes soient acceptées.
Aujourd'hui j'ai besoin de vous pour faire avancer mes propositions, sur des livres peut-être intéressants mais abandonnés depuis plus de trois ans, cinq ans, dix ans, vingt ans.

Si vous appréciez mon dévouement pour Wikibook et que vous souhaitez m'aider, ''il suffit chaque semaine de rajouter la commande'' {{VoteSupprimer}} ''sur les livres que je propose''. '''Entré {{}} puis à l'intérieur des parentthèses VoteSupprimer''' et signer votre accord. Merci pour votre aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 25 août 2026 à 10:33 (CEST)

:Salut @[[Utilisateur:Xhungab|Xhungab]], merci à toi pour ton engagement ! J'ai supprimé les pages qui étaient pratiquement vides dans ta liste. J'ai laissé les autres car la proposition de fusion est invoquée par @[[Utilisateur:DavidL|DavidL]] pour les pages avec du contenu. Malheureusement , je ne comprends pas comment fonctionne l'outil de fusion. J'espère que quelqu'un voudra bien m'expliquer le fonctionnement via un appel vidéo. Car je ne comprends pas les explications écrites. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:53 (CEST)
::Bonjour, Merci pour ton aide.
::.
::* J'ai travaillé sur la liste des pages les plus anciennement modifiées de l'année 2006. J'ai proposé tous les livres en errance à la suppression par vote.
::- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026
::Je vais attendre qu'elle soit traitée. Soit en supprimant ces livres soit en supprimant ma demande. Ensuite je ferai l'année 2007.
::.
::*Tu m'a posé une question.
::Quel est l'avantage de la suppression par rapport au déplacement ?
::Je vais essayer de te répondre dans mon prochain message. (Ce sera juste un délire d'un mois d'août un peu chaud). [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 09:20 (CEST)
:::C'est motivant de voir des gens motivés =)
:::Prend ton temps, il n'y a aucune échéance dans les projets Wikimédia, c'est un processus en continu qui peut s'étendre à plusieurs générations... Et si c'est plus facile pour toi de passer à l'oral, sache que je suis partant pour une discussion audio ou vidéo. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:35 (CEST)

== J'ai fait un rêve. ==

J'ai fait un rêve.

Un lieu où des amateurs passionnés proposeraient de partager leurs travaux avec des étudiants curieux. Pas les meilleurs travaux du monde. Mais pas les pires non plus. Un endroit où les anciens passeraient  le relais à ceux qui présentent leurs avenirs.  

Ce serait une petite bibliothèque avec une cinquantaine de livres disponibles à l'étude. Cinq ou six livres en construction que les étudiants pourraient travailler avec l'auteur. Tous les ans quelques livres supplémentaires viendraient enrichir ce lieu d'étude.

Aujourd'hui, il existe Wikibook. Un lieu où des auteurs malveillants prouvent que le travail collaboratif ne fonctionne pas. Ils créent des livres parfaitement construits de quelques chapitres puis les abandonnent sans scrupule. Ces livres moisissent depuis cinq, dix, quinze, vingt ans.

Wikibook c'est:
* La bibliothèque de livres pédagogiques libres que chacun peut améliorer.
* 569 livres contenant 22 112 pages.
.
* 569 livres dont 450 livres à l'abandon depuis cinq, dix, quinze, vingt ans.


Oui, aujourd'hui Wikibook peut changer. Wikibook va changer. Wikibook pour les étudiants va renaître de ses cendres. Les cendres des vieux livres abandonnés. Les auteurs devront faire honnêtement leur travail, ou les étudiants feront le leur.

Ceci n'est juste qu'un rêve dans un mois d'août un peu plus chaud que d'habitude.

Merci pour m'avoir suivi jusqu'ici. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 10:13 (CEST)

:Je trouve que c'est un très beau rêve @[[Utilisateur:Xhungab|Xhungab]]. Dans ce rêve, on peut voir la partie remplie du verre au lieu de la partie vide. Sur Wikilivres, il y a plus de 100 ouvrages terminés entièrement libres d'usage et toujours améliorables collectivement. Deux fois plus que la cinquantaine de livres dont tu parles dans ton rêve.
:C'est normal d'abandonner un projet d'écriture. La vie est tellement imprévisible. Les ressources en temps et énergie tant limitées. Combien de personnes ont commencé un livre sur papier ou sur leur ordi sans jamais le terminer ?
:C'est pareil sur Wikilivres, sauf que c'est visible aux yeux de tous.
:Quand on commence un truc, c'est jamais dans l'intention de l'arrêter. Si on arrête, c'est qu'il y a des raisons à cela. Je n'ai donc pas envie de voir dans ces abandons des actes de malveillance, ni de critiquer leurs auteurs. J'ai d'ailleurs moi-même des projets que je n'arrive pas à concrétiser (exemple).
:Je pense au contraire que ce n'est pas un problème à partir du moment où nous avons la liberté et les outils (communication, suppression, fusion) qui nous permettent de faire le tri entre ce qui est terminé, voire même ce qui est de qualité, et le reste.
:Ce rêve est donc possible et mes démarches pour devenir wikimédien en résidence à l'université sont une démarche qui va dans ce sens. J'ai d'ailleurs apporté les preuves que l'intégration des projets Wikimédia dans le processus d'apprentissage universitaire est non seulement possible, mais hyper efficace. Malheureusement, j'ai toujours l'impression que cela n'intéresse personne. Ni à l'Unif, ni dans Wikimédia. Mais je ne désespère pas. Les changements de paradigmes sont lents en raison des habitudes. C'est une fatalité chez l'humain. Il faut faire avec.
:Mais donc. Concentrons-nous sur la manière d'organiser notre bibliothèque pour que les visiteurs puissent confortablement voir ce qui s'y trouve en séparant, livres terminés, livres de qualité (cela se fait bien avec les articles de Wikipédia), livres en cours d'édition et livres abandonnés, etc. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:32 (CEST)
::Je pense que nos points de vue sont irréconciliables en toute amitié. Pour moi, Wikibook est une  bibliothèque de livres pédagogiques libres que chacun peut améliorer. Soit on peut mettre un étudiant sur un livre. Soit ce livre est inutile (Je parle de livre de plus de trois ans). 
::.
::Wikibook n'est pas un entrepôt pour les auteurs.  C'est une bibliothèque.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 14:57 (CEST)
:::@[[Utilisateur:Xhungab|Xhungab]], c'est bien que l'on ne soit pas d'accord, car cela permet d'avancer vers une solution que tout le monde pourra approuver. C'est le principe du consensus et cela prend du temps en discussion. C'est normal et sain. En de plus, ce qui est dit ici est tout à fait pertinent pour Wikiversité qui est confronté à des problèmes similaires que Wikilivres.
:::J'exprime mes idées ci-dessous mes idées autrement pour voir si cela peut se rapprocher de ta propre vision des choses.
:::J'imagine la bibliothèque Wikilivres avec trois pièces :
:::# Une pièce principale à l'entrée qui reprend tous les livres terminés et prêts à l'emploi par une personne désireuse de les utiliser dans le cadre d'un apprentissage. Comme dans toutes les bonnes bibliothèques, ces ouvrages sont rangés par thèmes et certains d'entre eux sont mis en évidence en raison de leurs qualités, de leur pertinence par rapport à l'actualité, etc.
:::# Une pièce archives à l'arrière du bâtiment (un espace de nom que l'on pourrait choisir parmi ceux existants ou créer si nécessaire) dans laquelle on entrepose toute une série de livres abandonnés mais dont le contenu est archivé dans le but d'une éventuelle réutilisation. Cette réutilisation, comme le suggère @[[Utilisateur:DavidL|DavidL]], peut s'effectuer dans le cadre d'une fusion du contenu abandonné avec un autre contenu abandonné, ou mieux encore, si cela se présente, avec un livre terminé dans lequel les informations utiles du document abandonné sont manquantes. À noter que cela représente beaucoup de travail, tant pour la relecture que pour la mise en œuvre des fusions, qui, à mes yeux de personne expérimentée dans l'usage de MediaWiki, est un processus compliqué. De plus, il ne peut être fait que par des personnes ayant les outils d'administrateur. C'est-à-dire quatre personnes, dont deux ou trois actives dans ces récentes discussions.
:::# Dans la librairie Wikilivres, il y a ensuite un étage dans lequel chaque personne inscrite peut bénéficier d'un espace personnel, pour se présenter, stocker des informations, mais également travailler sur des projets personnels d'écriture. En tenant compte de ceci, on peut alors aussi imaginer de déplacer les ouvrages inachevés de la pièce principale à l'entrée de la librairie, vers ces différents locaux selon leurs auteurs respectifs.
:::Face à ces trois espaces, la question qu'il reste à se poser est de savoir si et dans quelles condition, on peut déplacer les ouvrages inachevés vers une salle d'archive, ou dans les locaux personnels des auteurs ? Cela en signalant que ce déplacement peut être fait très facilement et par toutes les personnes qui le souhaitent, même sans inscription à la bibliothèque. Ce qui est un grand avantage par rapport à la fusion.
:::Pendant ce temps, à l'accueil de la bibliothèque Wikibook, on invite les visiteurs à parcourir la pièce avec les ouvrages terminés, mais également la pièce archive, où ils peuvent trouver des ouvrages inachevés, au cas où ils veulent poursuivre leurs développements, ou trouver des ressources intéressantes pour leurs travaux personnels. On les informe ensuite aussi qu'avec leur inscription, ils bénéficient d'un local pour leurs activités personnelles et notamment pour y placer les ébauches d'ouvrages qu'ils désirent rédiger.
:::Que penses-tu de mon propre rêve ? Est-il si différent du tien ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:17 (CEST)
::::Et les autres ? @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Fourmidable|Fourmidable]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:Grondin|Grondin]]. Que pensez-vous de nos rêves ? Et, si le mien vous parle, quelles seraient vos propositions pour orienter les déplacements de pages à l'abandon entre un espace d'archivage (qui pourrait être créé) et des espaces utilisateurs ? Le nombre d'octets ? La finalisation d'une section ou d'un chapitre ? Quelles autres possibilités ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:37 (CEST)
::::: Bonjour, a priori ça doit se régler au cas par cas sur [[Wikilivres:Demandes de suppression]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]])

::::Bonjour,
::::La structure de Wikibook est parfaite grâce à sa vitrine.  Pour moi, il y a juste un problème sur les listes sur la droite : Arts, Loisir, Histoire, Langues, Technologie, Informatique, Sciences, Sciences humaines. Ces listes ne devraient donner accès qu'aux livres terminés.
::::Ces listes actuelles pourraient être caché dans un espace création qui pourrait être posé avec le lien Nouveauté en bas de la page.
::::Pour la gestion des livres, il suffirait qu'une ou deux personnes parcourent la bibliothèque et proposent quelques suppressions chaque semaine, pour en quelques mois éclaircir la situation. Je pense que l'on peut faire confiance aux administrateurs pour gérer la situation des livres, ceux qui sont à garder et les autres. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 18:30 (CEST)
:::::@[[Utilisateur:JackPotte|JackPotte]]. Le cas par cas est ce que nous faisons depuis toujours. Cela nous amène à la situation actuelle qui semble ne pas convenir à tous. En tout cas, c'est mon cas. Ici comme sur Wikiversité. Quand, en navigant sur le site, une personne tombe neuf fois sur dix sur des pages presque vides et inachevées, comme c'est le cas sur Wikilivre, elle se dit : c'est quoi ce site ? Elle passe alors à autre chose de plus vivant, genre https://zestedesavoir.com/ ou autre. Sans changements éditoriaux, je pense que la situation évoluera.
:::::@[[Utilisateur:Xhungab|Xhungab]], on peut faire comme tu dis. Cependant, la charge de travail repose sur une double action, la proposition d'abord et le traitement ensuite. Un traitement qui finalement repose sur les épaules des administrateurs. Nous ne sommes que des bénévoles peu nombreux et pas toujours disponibles.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 19:13 (CEST)
:Créer un livre, le ranger, en établir un plan, le catégoriser n'est pas un travail négligeable... Un travail que d'autres personnes intéressées pour écrire sur le sujet n'ont pas à refaire 🤷‍♂️ ...

== Petite proposition indécente à Lionel ==

Bonjour  Lionel,

Je souhaiterais te proposer un petit projet.

a) Dans la page principale de wikibook tu créés une page &quot;Espace pour les auteurs&quot;. Tu insères cette page devant le lien &quot;Nouveautés&quot;.
.

b) Tu copies dans cette page la liste des liens qui se trouvent en haut à droite dans la nouvelle page. (Arts, Loisirs, ...) Tu ne les modifies pas dans la page principale.
.

c) Dans la nouvelle page tu peux écrire un texte du genre.
Dans cette page, vous trouverez la liste de tous les livres disponibles sur Wikibook. Vous trouverez en particulier des livres en construction et vous pourrez entrer en contact avec les auteurs. Vous trouverez aussi des livres en construction sans auteur actif que vous pourrez compléter.


Cela est la première étape, si l'aventure t'intéresse. En fait tu ajoutes juste une page, que tu pourras supprimer si les besoins se font sentir. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 12:25 (CEST)

:La proposition est très décente @[[Utilisateur:Xhungab|Xhungab]] 
:Mais avant toute choses le plus prudent est de lancer une prise dé décision pour s'assurer d'un concesnsus en faveurs des changements dont nous débatons actuellement.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 août 2026 à 15:40 (CEST)
::Toutes ces actions seront réversibles. On ajoute une page. Un problème, on la supprime. 
::On fait rapidement les changements, on attend trois jours. En cas de problème, on supprime tout. Il suffira de s'excuser et de dire que l'on ne savait pas que l'on n'avait pas le droit. 
:: Un espace pour les lecteurs et un espace pour les auteurs séparés.
::[https://fr.wikibooks.org/wiki/Utilisateur:Xhungab Nouvelle page wikibook][[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 16:49 (CEST)
:@[[Utilisateur:Xhungab|Xhungab]] , ma grand mère disait : faire et défaire, c'est toujours travailler. Pour les grand changements, on a coutume de faire un prise de décision composée des propositions, suivies de débats et d'un vote.
:En plus, certaines décisions nécessite un changement technique et ce n'est pas toujours facilement réversible. Comme créer un nouvel espace de nom pour y transfèrer une catégorie de pages  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 28 août 2026 à 03:07 (CEST)
::Merci pour ton aide. Tu comprends maintenant pourquoi toi tu es un administrateur et moi pas.
::.
::'''Oui, aujourd'hui Wikibook peut changer. Wikibook va changer.''' 
::.
::*  '''Le changement c'est Maintenant :''' [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']
::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 28 août 2026 à 08:33 (CEST)
:::Ton enthousiasme fait plaisir @[[Utilisateur:Xhungab|Xhungab]], et je serais en faveur d'un style plus épuré de notre page d'accueil en plus d'une méthodes de classement et de séparation des ouvrages terminé, en cours et abandonnés. Je pense qu'à terme, nous pourrions faire une proposition de changement à soumettre au reste de la communauté. Par chance, nous ne sommes pas nombreux, cela simplifire les discussions et le processus de décision. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 19:26 (CEST)
::::Cette page  [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook'''] propose la vitrine, les livres disponibles, les mini-livres disponibles pour les lecteurs. Les lecteurs ne seront en contact qu'avec les livres terminés.
::::.
::::En bas à côté des nouveautés, il y a l' '''[https://fr.wikibooks.org/wiki/Discussion_utilisateur:Xhungab Espace pour les auteurs]''', avec tous les livres du site rangés par thème ou par niveau d'avancement si on clique sur l'image. Sinon, il y a une liste de catégories art,...
::::.
::::Cette proposition sépare donc deux espaces. Un pour les lecteurs et un pour les auteurs. Il suffirait maintenant plus qu'à nettoyer l'espace auteurs. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 20:22 (CEST)
L'usage des catégories me semble aussi une manière très pratique de trier le contenu de Wikilivre. Malheureusement, ces pages ne sont pas très sexy du coup l'usage de type de code pourrait être utile :

{ {Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={ { #categorytree:Livres terminés|mode=pages} } } }

Avec le rendu ci-dessous :
{{Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={{ #categorytree:Livres terminés|mode=pages}}}}

On pourrait ainsi imaginer d'intégrer directement ce code dans la page d'accueil pour afficher une boite déroulante au lieu d'envoyer le visiteur en dehors de la page d'accueil. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:08 (CEST)

:Tu devrais créer la page Lioneltest01 dans ta page utilisateur. Copier le code de la page principale de wikibook.
:Puis faire les changements que tu juges nécessaires. Tu peux éventuellement faire plusieurs pages. Ensuite, tu mets cette page dans le bistro pour que l'on puisse voir le résultat. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 21:22 (CEST)
::Je devrais, tu devrais, il devrait, nous devrions ... =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:28 (CEST)
:::Chaque chose en son temps.
:::1. Débattre ici des idées de changements.
:::2. Mettre les choses en place pour leur réalisation, comme la mise à jour du modèle:boite déroulante en s'inspirant de celui de Wikipédia ou d'autres sites.
:::3. Quand il n'y a plus de nouvelle idée ici, créer une page genre :[[Wikilivres:Prise de décision/Nouvelle page d'accueil et gestion des abandons]] avec une description précise des projets de changements, et une éventuelle [[Accueil/projet|page de présentation du projet d'un nouvelle page d'accueil]]
:::4. Poursuivre les discussions et propositions si nécessaire.
:::5. Quand on a fait le tour, passer au vote.
:::6. Mettre les décisions en application. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:03 (CEST)
::::Je propose actuellement un projet qui se trouve sur ma page utilisateur. Pourrais-tu lancer une prise de décision sur ce projet. Je ne sais pas comment on fait une telle demande. Je suis prêt à présenter mon projet et à recevoir les critiques. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 22:16 (CEST)
:::::''Aide-toi le ciel t'aidera''. La bureaucratie, c'est pas mon truc. Et puis ça m'irrite un peu que tu enchaines des demandes de faire des choses qui ne demande pas les outils d'administrateurs. Raisons pour lequelles, je pense finalement que l'on gagnerait à appliquer la [[w:Do-ocratie|Do-ocratie]] qui a fait ses preuves dans le monde du libre dont les projets Wikimédia sont issus.
:::::Si tu as une idée et qu'elle ne demande pas des droits de modification que tu n'as pas, fait la et on se retrouve en page de discussion de la page de tes changements en cas de problèmes et pour d'éventuelle commentaire. Sans réaction, pense à ''qui ne dit mot conscent''.
:::::Si tes idées demandes les outils d'administrateurs, tu peux alors demander à un admin de le faire. Libre à lui de le faire ou pas et si ça lui plait, si il a envie, si il prend le temps. Nous sommes bénévoles... Il y a bien des gens payés par la fondation, mais comment dire... Disons qu'ils ne sont pas des plus serviables. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:57 (CEST)
::::::Excuse moi je pensais qu'il faillait être administrateur pour faire une demande de prise de décision. Je vais donc essayer tous seul. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 23:06 (CEST)
:::::::Ok @[[Utilisateur:Xhungab|Xhungab]], pas de soucis. On ne peut pas tout savoir =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 30 août 2026 à 01:45 (CEST)

== Wikilivres:Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''


Merci pour votre participation

[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 30 août 2026 à 00:43 (CEST)

:Bonjour @[[Utilisateur:Xhungab|Xhungab]]. Content de te revoir dans les murs de Wikiversité après nos échanges sur Wikilivres. Je comprends ton sentiment de solitude, je le ressens aussi souvent. Il faut l'accepter et ne pas se décourager pour autant. Nous avons la chance de fonctionner dans une organisation bénévole, dans laquelle personne n'est tenu de répondre à des demandes. De ce fait, les choses évoluent lentement et en fonction des disponibilités. Dis-toi aussi que la période estivale est toujours un moment d'acalmie dans la participation. Moi par exemple, quand il fait bon, je préfère passer du temps sur des occupations extérieures que devant un écran.
:Cela dit, tu dois garder 3 règles implicites qui sont fréquemment appliquées dans les projets Wikimédia.
:1. ''Qui ne dit mot consent''. Si les personnes ne réagissent pas, cela ne veut pas dire qu'elles ne lisent pas. Par économie de temps et pour les personnes trop occupées ou pas assez motivées pour s'investir, ne pas réagir est un signe de consentement implicite.
:2. ''Les absents ont toujours tort.'' Lorsque l'on fait les choses dans les règles de l'art, par exemple comme tu le fais en lançant une prise de décision pour opérer un changement significatif dans Wikilivres, aucune personne absente durant un processus de décision clôturé viendra remettre en cause les choses par la suite.
:3. La doocratie. Les wikis sont des espaces de libertés au niveau de l'amélioration des contenus, mais également de l'organisation et des formes de contenus. En dehors du vandalisme qui est bien contrôlé par des personnes telles que @[[Utilisateur:Crochet.david|Crochet.david]], toute initiative est souvent perçue comme bienvenue. @[[Utilisateur:Fourmidable|Fourmidable]], par exemple, depuis qu'il est administrateur, a fait de nombreuses améliorations dans Wikiversité sans demander l'avis de la communauté. Personne ne lui a reproché son investissement. Si quelque chose qu'il a entrepris ne plaît pas à quelqu'un, une discussion commence entre lui et cette personne pour chercher une entente.
:Voilà tout.
:Je te rejoins aussi sur le fait que ce qui est décidé et mis en place sur Wikilivres peut tout à fait servir d'exemple pour Wikiversité et vice versa. Je ne suis pas le seul à être administrateur dans les deux projets et cela aide beaucoup à la création d'une synergie entre les deux projets qui sont finalement très complémentaires. Cela n'est pas étonnant d'ailleurs lorsque l'on sait que Wikiversité est né de Wikilivres.
:Une belle fin de journée à toi et à tous ceux qui liront ce message. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:30 (CEST)
::Merci. Pour tes explications. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 6 septembre 2026 à 13:50 (CEST)
:::Avec plaisir. Pense aussi qu'il n'y a pas de combat dans les projets Wiki, mais un lent processus évolutif, sans fin programmée, et qui est pour moi l'un des meilleurs que je connaisse. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:57 (CEST)

== Les RAW sont arrivés, la rentrée peut commencer ! ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro de&amp;nbsp;septembre 2026 ({{numéro|296}}) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-09-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;
&lt;/div&gt;

'''C'est la rentrée'''

Après un numéro très dense en août en raison de la Wikimania, celui-ci est un peu plus léger car l'équipe s'est octroyée quelques vacances. Cela n'empêche pas le mouvement de continuer à vivre, avec une rentrée déjà animée ! Du côté des projets francophones, le Wiktionnaire vient de franchir le cap symbolique des sept millions d’entrées, tandis que Wikipédia continue de voir fleurir sondages et discussions sur son fonctionnement.

Une rentrée, donc, placée sous le signe de la construction collective : de nouveaux outils pour contribuer, de nouveaux espaces pour échanger, de nouvelles formes d’organisation… Ce numéro des RAW vous propose de faire le tour de cette actualité, avant de reprendre tranquillement le chemin des projets Wikimédia.

L'équipe de la rédaction a également commencé à réfléchir à un nouveau nom pour remplacer l'énigmatique « RAW ». N'hésitez pas à venir donner votre avis dans la [[:w:Discussion Wikipédia:RAW/Rédaction#Changement de nom|section dédiée]] !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia, des nouveaux outils et des articles de recherche

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : n'hésitez pas à suggérer des sujets ou participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]] !

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 septembre 2026 à 00:17 (CEST)

== Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés ==

J'ai posé une demande de prise de décision concernant le sujet suivant.


[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Modifier_le_contenue_de_l%27espace_Nouveaut%C3%A9s Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés]

Merci pour votre participation [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 9 septembre 2026 à 14:38 (CEST)

== '''Décision''':Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''

'''Décision pour : [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']'''

Résultats : 3 + Pour, un Neutre Neutre et un - Contre soit 60 % de + Pour par rapport au total des votes exprimés : la proposition est adoptée. Quelques propositions de reformulations et de nuances ont été faites qui pourront être prise en compte. Cdlt, VIGNERON * discut. 13 septembre 2026 à 18:27 (CEST)

Merci pour votre participation. Ma première proposition était un peu malhabile, mais grâce à vos interventions je pense que l'on a créé quelque chose de correct. '''Merci à tous''' [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 13 septembre 2026 à 20:22 (CEST)

== Je ne suis pas content tous seul. ==
'''Suite à l'installation de la nouvelle page de la Vitrine, je ne suis pas content, j'ai pris 24h pour réfléchir.
'''

J'avais posé une demande de prise de décision concernant le sujet suivant.


'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace auteurs sur la page d'accueil]'''


'''Créer un espace lecteurs''' : Où est l'espace pour les lecteurs?


 Découvrir la bibliothèque
 Livres terminés - Mini Livres - Tous les livres


'''Dans une bibliothèque''', un livre est disponible ou indisponible. C'est chez l'auteur ou chez l'imprimeur qu'un livre est terminé.


'''Je suis un nouveau sur Wikilivre'''. Je vois, &quot;Découvrir la bibliothèque&quot;, je vais directement dans &quot;'''[[Wikilivres:Tous les livres|Tous les livres]]'''&quot;. Je me retrouve dans un labyrinthe qui me balade de répertoires en répertoires pour finir sur une ébauche abandonnée depuis 5, 10, 20 ans.


Je ne suis pas content. J'avais proposé à l'administrateur un changement en 2 minutes. Copier cette page dans la Vitrine, [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab La Nouvelle Vitrine]. Il a décidé de passer plusieurs heures à modifier la prise de décision. Je ne suis pas content. Je suppose que je suis le seul. 


Donc : '''Je ne suis pas content tous seul.''' Mais je me soigne. Un pan bagnat et une tourte aux blettes.

Merci de m'avoir lu [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 septembre 2026 à 10:51 (CEST)</text>
      <sha1>17sr016pbrjvnqw6wx7yo0j98qlqeiq</sha1>
    </revision>
    <revision>
      <id>772352</id>
      <parentid>772347</parentid>
      <timestamp>2026-09-17T11:20:31Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>/* Je ne suis pas content tous seul. */ Réponse</comment>
      <origin>772352</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="75023" sha1="fcp4q7ab1cs2dwimdbue0mzkr31m8xe" xml:space="preserve">&lt;noinclude&gt;{{Wikilivres:Le Bistro/En-tête}}&lt;/noinclude&gt;

== Le meilleur à Wikilivres pour 2026 ! ==

Je crée la page du bistrot 2026 en transmettant mes vœux. Bonne année éditoriale à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 janvier 2026 à 06:05 (CET)
:Merci, meilleurs vœux ! [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 16 janvier 2026 à 09:53 (CET)
::Meilleurs vœux pour 2026 !
::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 janvier 2026 à 20:13 (CET)
:::Meilleurs vœux pour 2026
:::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 janvier 2026 à 11:56 (CET)
::::Bonne année et bonnes lectures et écritures !
::::[[Utilisateur:Matthius|Matthius]]


== Page orpheline du livre : États généraux du multilinguisme dans les outre-mer ==

Bonjour,

Le livre &quot;États généraux du multilinguisme dans les outre-mer&quot; a laissé quelques pages orphelines. Ces pages orphelines ont été recopiées ou regroupé dans le texte du livre. Elles font donc doublons.

Je montre dans ce livre [[Wikilivres:Feuilles dupliquées orphelines]] cette suite de pages orphelines accompagnée par la page où elles ont été recopiées.

Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 10 février 2026 à 19:57 (CET)

:@[[Utilisateur:Xhungab|Xhungab]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], bonjour. Je vois que l'on est en campagne de gestion de pages orphelines et je me pose la question de savoir si on doit les supprimer une fois réintégrées ailleurs ou les supprimer ? Je vois que les deux cas de figure ont été mis en œuvre précédemment. L'avantage de la fusion est de conserver l'historique des modifications, mais je ne suis pas habitué à le faire. Si quelqu'un d'entre vous pouvait m'indiquer une page d'explication, cela m'aiderait à m'y mettre. Ensuite, je me demande si la fusion a vraiment un sens lorsque c'est la même personne qui a créé la page orpheline et la nouvelle au contenu copié collé pour insertion ? Qu'en pensez-vous ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:02 (CET)
:::Ça fait plaisir de voir une personne s'investir dans la maintenance de Wikilivres =). Soit le ou la bienvenu.e. J'attends les avis des autres administrateurs pour te donner mon soutien @[[Utilisateur:Xhungab|Xhungab]]. @ bientôt. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:27 (CET)
:::: @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]] bonjour, je n'ai pas compris en quoi &quot;deux cas de figure ont été mis en œuvre précédemment&quot; : si la page est vide on la supprime et si elle a au moins une phrase valable on la fusionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:26 (CET)
::::Concernant l'auteur pour moi cela importe peu, car on souhaite conserver chaque élément permettant de prouver une primauté du droit d'auteur (par exemple pour ne pas accuser un contributeur d'avoir copié un site miroir de sa page supprimée). [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:30 (CET)
:::::Désolé [[Utilisateur:JackPotte|JackPotte]], je n'avais pas vu que les pages que tu as supprimées étaient vides. La règle est donc supprimer si vide et fusionner si non. Tu peux me conseiller une page d'aide pour oppérer les fusions ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:34 (CET)
::::::Salut,
::::::Pour la fusion d'historique :
::::::* soit [[Wikilivres:Le guide de l'administrateur#Fusionner deux pages|Utiliser la page spéciale pour cela]] (cependant ne fonctionne pas toujours),
::::::* soit [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages utiliser l'ancienne méthode] qui reste toujours valable quand la première ne fonctionne pas.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 13 février 2026 à 19:34 (CET)
:::::::Salut @[[Utilisateur:DavidL|DavidL]]. Je viens de tester l'outil fusionner avec les deux pages suivantes
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes/Contexte]]
:::::::vers
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes]]
:::::::Et j'ai le message suivant :
:::::::« La période spécifiée chevauche les versions préexistantes de la page de destination. »
:::::::Tu peux m'expliquer si tu as le temps ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 00:19 (CET)
::::::::Salut @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]]
::::::::Dans ce cas, j'utilise [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages l'ancienne méthode].
::::::::# Renommer A (page qui n'existera plus) vers B, sans laisser de redirection, et en cochant la case de suppression de B (case qui apparait après 1er clic sur le bouton Renommer) (&amp;rarr; l'historique de A est sur B, celui de B est supprimé)
::::::::# Supprimer B (&amp;rarr; l'historique de A et B sont supprimés)
::::::::# Restaurer B et cocher toutes les cases des versions (bouton &quot;Inverser la sélection&quot;) (&amp;rarr; restaurer l'historique de A et B)
::::::::# Effectuer une modification de la version finale de la page à afficher, trouvée dans l'historique.
::::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 février 2026 à 08:29 (CET)
:::::::::Merci @[[Utilisateur:DavidL|DavidL]]. Ça m'a l'air bien compliqué tout ça. Et avec toute les pages qu'il faut faire, ça risque de prendre un certain temps. Je manque de courage en pensant que c'est juste pour ajouter une ligne dans l'historique des versions. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 14:51 (CET)
::::::::::Finalement, dans l'exemple que j'ai pris, la fusion n'avait aucun sens puisque le contenu du doublon que j'ai finalement supprimé était intégralement repris dans l'autre doublon par le même auteur. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 22 août 2026 à 23:55 (CEST)
:::::::::::Désolé @[[Utilisateur:Xhungab|Xhungab]]. Je ne comprends rien à l'outil de fusion et je ne trouve rien qui me permet de comprendre sur le net. Une vidéo avec exemple des différents cas de figure serait bien, mais je ne trouve pas. Je vais donc laisser ce travail à ceux qui savent utiliser l'outil.
:::::::::::En revanche, j'ai remarqué que certains doublons, comme dit précédemment, ne nécessitent pas de fusion puisqu'il s'agit de pages qui ont été créées sans aucune autre modification, puis, copiées par le même auteur dans une autre page créée avec un autre nom, au lieu de faire un renommage. Il faudrait donc que je prenne le temps de parcourir la liste pour repérer ces cas de figure avant de supprimer le premier doublon. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 01:27 (CEST)
::::::::::::Merci pour ton aide. Actuellement ces pages ont été en quelque sorte neutralisées. Donc fais de ton mieux, mais ne te tracasse pas elles ne posent plus de problème. Encore merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 09:13 (CEST)
:::::::::::::OK @[[Utilisateur:Xhungab|Xhungab]], merci pour l'info. Au fait comment as-tu fais pour les détecter ? En parcourant les pages de la catégorie orphelines et en vérifiant celles qui sont doublons ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 12:36 (CEST)
::::::::::::::Dans la catégorie pages orphelines, il y avait un lien sur une page.
::::::::::::::Je choisissais une phrase et je recherchais avec la fonction recherche de wikibook où se trouvait cette phrase. Si c'était un doublon, j'avais un lien vers la nouvelle page. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 12:48 (CEST)
:::::::::::::::Intelligent. Tu poserais pas ta candidature d'admin !? Ici, avec @[[Utilisateur:Fourmidable|Fourmidable]] et puis sur wikiversité aussi. Ça pourrait aider pour le projet des 20 ans., si tu comote toujours t'investir. On est en sous effectif dans les deux projects et les communautés me semblent plus ouverte que sur Wikipédia. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 13:48 (CEST)
::::::::::::::::Je ne souhaite pas devenir un administrateur. Pourquoi ? Si on me donne du pouvoir, je l'utiliserais. Par la suite, ceux qui m'ont accordé le pouvoir auront le choix entre pleurer, nous quitter ou me mettre en arrêt de travail. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 14:59 (CEST)
:::::::::::::::::Ah ah ah. T'es si foireux que ça !? Ou peut-être as-tu eu des expériences antérieures ? Dans tous les cas, c'est super de ta part de pouvoir t'auto évaluer.
:::::::::::::::::Ceci dit, le système de demander au administrateurs de faire des tâches qu'il faut expliquer est une perte de temps et d'efficacité. On pourrait d'ailleurs penser à attribuer les droits temporairement pour effectuer certaines tâches. Je me demande si ça se fait déja quelque part ? Si oui, on pourrait s'en inspirer pour mettre le système en application sur Wikilibres et Wikobersité. T'en penses quoi @[[Utilisateur:Xhungab|Xhungab]] ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 15:40 (CEST)
::::::::::::::::::Oui, je pourrais obtenir des droits temporaires par rapport à un projet. Par exemple 2 projets
::::::::::::::::::Premier projet :  Supprimer toutes les feuilles volantes. Ce sont des feuilles tests très bien faites mais qui n'appartiennent à aucun livre. Je crois qu'il y a actuellement, Feuilles volantes – 54 P. 
:::::::::::::::::: 
:::::::::::::::::: Deuxième projet : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Pages_anciennes Les pages les plus anciennement modifiées]
::::::::::::::::::Supprimer tous les livres entre 2006 et 2010 qui sont à l'abandon. Parfois il sera possible de sauvegarder un livre en supprimant les chapitres vides, ce qui nous permettra de créer un livre complet. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 16:19 (CEST)
Donc, tu as du temps à consacrer à ce genre de maintenance ? Ce serait bête de ne pas en profiter. Reste à voir à présent si les autres administrateurs et bureaucrates seraient d'accord de t'octroyer les droits, tout en approuvant les deux projets que tu proposes. Cependant, je ne suis pas un grand fan des suppressions, je préfère de loin renommer les pages pour les placer en dehors de l'espace principal de sorte à ce que les auteurs puissent toujours les retrouver. Pour ça, un bon espace, c'est les sous-pages des principaux auteurs. Cela pourrait ainsi s'appliquer aux feuilles volantes et aux projets d'écriture abandonnés qui sont suffisamment développés pour justifier une conservation. L'avantage de cette méthode est qu'elle ne demande pas d'avoir les outils d'administrateurs. Faudrait voir maintenant dans quel cas on supprime et dans quel cas on renomme. On pourrait par exemple définir un nombre d'octets ou de caractères, question d'avoir un critère standard et accepté par tous. Qu'en penses-tu [[Utilisateur:Xhungab|Xhungab]] ?
:En fait je préfère continuer comme actuellement. Proposer mes services  pour améliorer wikibook sans avoir aucun droit. De cette manière, si je propose quelque chose d'incongru, comme cela est déjà arrivé, il suffit de neutraliser ma demande. Merci à ceux qui me suivent sur ce travail.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 01:52 (CEST)

:Je comprends @[[Utilisateur:Xhungab|Xhungab]]. Mais précisément, déplacer une page à l'abandon dans une sous-page l'espace utilisateur de l'auteur principal, cela ne demande justement aucun droit et tout le monde peut le faire, toi en premier puisque tu sembles actif à ce niveau. C'est pour ça que je te demande ton avis : que penses-tu de l'idée de déplacer les pages comme je viens de le décrire, plutôt que de les supprimer ? Je viens de soumettre l'idée dans une nouvelle discussion ci-dessous. Tu peux donner ton avis là-bas si tu veux. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 02:27 (CEST)

== archive.today ==
''Voir [[:w:Wikipédia:Le Bistro/21 février 2026#archive.today]].''

Ce site pose apparemment des problèmes de sécurité, il faudrait le remplacer au plus vite si possible, et sinon désactiver les liens.

[[Utilisateur:SyntaxTerror|SyntaxTerror]] ([[Discussion utilisateur:SyntaxTerror|discussion]]) 21 février 2026 à 13:07 (CET)
:Salut SyntaxTerror,
:* 0 liens vers archive.today : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.today]
:* &lt;s&gt;18&lt;/s&gt; 0 liens vers archive.is [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.is]
:* 0 liens vers archive.li [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.li]
:* 0 liens vers archive.ec [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ec]
:* 0 liens vers archive.ph [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ph]
:* 0 liens vers archive.fo [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.fo]
:* 0 liens vers archive.md [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.md]
:* &lt;s&gt;1&lt;/s&gt; 0 liens vers archive.vn [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.vn]
:* 0 liens vers archive.closed.social [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.closed.social]
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 21 février 2026 à 16:14 (CET)
::Merci pour vos efforts ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:22 (CEST)

== demande aide pour sortir du mode &quot;ébauche&quot; ==

je viens de terminer mon livre ... ci dessous. J'ai compris qu'il fallait le signaler comme n'étant plus au stade &quot;ébauche&quot;  commente faire   Merci

https://fr.wikibooks.org/w/index.php?title=Essai_pour_un_mod%C3%A8le_de_psychisme_objectif&amp;action=info#mw-pageinfo-header-basic [[Utilisateur:Clopeau|Clopeau]] ([[Discussion utilisateur:Clopeau|discussion]]) 17 mars 2026 à 08:20 (CET)
:Bonjour, quand je regarde ''[[Essai pour un modèle de psychisme objectif]]'', sa complétude permettrait en effet de le sortir des ébauches, mais il semble plutôt d'agir d'un travail de recherche que d'un livre pédagogique sur un sujet sourcé comme reconnu.
:Donc en vertu de [[Wikilivres:Principes fondateurs|notre charte]], je propose de le déplacer sur {{WV|Recherche:Accueil}}. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 18 mars 2026 à 09:06 (CET)

== Don à wikipédia depuis wikilivres ==

{{BlocCitation|La Wikimedia Foundation est l’organisation à but non lucratif qui soutient Wikipédia, '''les autres sites de connaissance libre de Wikimédia''', et sa mission de connaissance libre pour tous.|auteur=[https://wikimediafoundation.org/fr/give/donor-frequently-asked-questions/ FAQ], {{g|Qu'est-ce-que la Wikimedia Foundation ?}}}}
Le lien de donation https://donate.wikimedia.org/w/index.php?title=Special:LandingPage&amp;country=FR&amp;uselang=fr&amp;wmf_medium=sidebar&amp;wmf_source=donate&amp;wmf_campaign=fr.wikibooks.org '''ne parle que de wikipédia'''. '''Où sont passés les autres projets ?''' Vont-ils être fermés sauvagement par la fondation comme Wikinews récemment ? La suite au prochain épisode d{{'}}''Highlander-Wikimedia'' : {{g|À la fin, un seul ''projet'' survivra.}} ... &amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 12 mai 2026 à 11:26 (CEST)

:Bonjour,
:Je pense personnellement que les wikis ont des problèmes.
:Il y a une vingtaine d'années, il représentait l'innovation la plus ambitieuse.
:Aujourd'hui, les wikis me semblent dépassés de tous les côtés.
:           wiki = Erreurs 404 (&quot;Page introuvable&quot;)
:Problèmes:
:* 568 livres déclarés. 50 livres terminés (combien sont obsolètes)
:* 21 527 pages déclarées. 20 000 pages orphelines. (Papa t'est où?)
:Solution:
:* Où sont les cours sur YouTube qui utilisent un wikibook comme référence?
:Voilà mon idée sur les wiki.
:* https://fr.wikiversity.org/wiki/Facult%C3%A9:Droit
:* https://fr.wikiversity.org/wiki/D%C3%A9partement:Introduction_au_droit
:&lt;nowiki&gt;~~~~&lt;/nowiki&gt; [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 12 mai 2026 à 13:50 (CEST)
::Ce serait intéressant de mentionner tous les projets actifs oui. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:23 (CEST)
::: En même temps, le message est plutôt franc étant donné que l'argent des dons n'est pas investi dans le développement de Wikilivres (cf [[:meta:Community Wishlist Survey]] et les réponses à nos tickets Phabricator).
::: Par ailleurs, concernant la qualité des contenus, cela a toujours était un sujet depuis le début, et nous disposons tout de même de plusieurs pages spéciales dans [[Wikilivres:Maintenance]] pour y remédier afin que le lecteur n'ait pas la sensation de se faire empapaouter en se retrouvant sur des ébauches bien placées dans Google. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mai 2026 à 08:48 (CEST)

== La catégorie SI est pleine ! ==

Bonjour tous,

Pour info, la [[:Catégorie:Suppressions immédiates demandées]] contient 9 pages.

Wikilivresquement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 14 juin 2026 à 15:36 (CEST)

:Elle est maintenant vide, merci à ceux qui s'y sont collés ! {{Sourire}} [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 24 juin 2026 à 17:17 (CEST)

== Un RAW bien frais pour juillet ==

{| style=&quot;width:100%;&quot;
| valign=&quot;top&quot; align=&quot;center&quot; style=&quot;border:1px gray solid; padding:1em;&quot; |
{| align=&quot;center&quot;
|-
| style=&quot;text-align: center;&quot; | &lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:4.5em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em;text-align:center; color: #fff; font-style:italic;&quot;&gt;Regards sur l’actualité du mouvement Wikimédia.&lt;/div&gt;
&lt;div style=&quot;text-align: center;&quot;&gt;{{#ifeq:{{FULLPAGENAME}}|Wikipédia:RAW/Rédaction}}&lt;/div&gt;
&lt;/div&gt;&lt;br /&gt;
&lt;hr /&gt;
&lt;div style=&quot;font-size:12pt; font-family:Times New Roman; text-align:center;&quot;&gt;[[w:fr:Wikipédia:RAW/2026-07-05|&lt;span style=&quot;color:darkslategray;&quot;&gt;Le numéro de juillet 2026 est sorti.&lt;/span&gt;]]&lt;/div&gt;
&lt;hr /&gt;&lt;br /&gt;

|- style=&quot;text-align: center;&quot;
| &lt;span style=&quot;font-size:12pt; font-family:Times New Roman;&quot;&gt; '''❖ Au menu de ce numéro ❖'''&lt;/span&gt;
|- style=&quot;font-size:10pt; font-family:Times New Roman; text-align:center;&quot;
| &lt;div style=&quot;text-align:center; column-count:1; column-width:28em; vertical-align:top;&quot;&gt;

'''L'Édito'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Édito|Fêtons notre mouvement !]]

'''Échos francophones'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Résidence|Un nouveau vigneron dans la résidence]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Logo_WP25|Wikipédia en français aux couleurs des 25 ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#DAF|Wikipédia dans le ''Dictionnaire de l'Académie française'']]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Millésime_Wiktionnaire|Quelles sont les nouvelles entrées en français sur le Wiktionnaire ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ADS|Relance de l'Article de la semaine]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#sans_pagEs|Le projet des sans pagEs fête ses dix ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#contributions_rémunérées|Faut-il faire évoluer les règles sur les contributions rémunérées ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#wikification|Le mois de la wikification fait son retour pour une septième édition]]

'''Ailleurs dans le mouvement'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Txikipedia|Txikipedia franchit le cap des 10 000 articles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Concours_santé_2026|Un concours sur la santé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Commons_et_IA|Commons se penche sur l'IA]]

'''Nouveautés techniques et outils'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#VIZWP|VIZWP : un outil pour visualiser les lacunes dans les sujets climatiques sur Wikipédia, mais pas que…]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#AI_Source_Verification|Examiner la vérifiabilité grâce à l'IA ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Icônes|Les icônes de l'interface ont changé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Sous-références|Ça y est, les sous-références sont là]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ConvoCompass|ConvoCompass, pour moins d'attaques personnelles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LSV-Tools|LSV-Tools : faciliter la gestion des anecdotes « Le saviez-vous ? »]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LegendAndDot|Semi-automatiser l'ajout de ponctuation dans les légendes d'images]]

'''Du côté de la recherche'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#COMSAV|COMSAV : la contribution à Wikipédia fait-elle d'un ensemble d'individus un ensemble de pairs ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#JourneyMap|Où commence la contribution et où s'arrête-t-elle ?]]

'''Le POV'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Le_POV|Guide survie pour la Wikimania 2026]] par Trizek

'''L'Atelier'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Atelier|Le point sur la diversité de genre dans les articles]] par PAC2

'''L'Analyse'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Analyse|Larry Sanger is back... and fired!]] par Madelgarius, Trizek et Jules*

'''L'interview'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'interview|Pronoia : de Byzance aux réseaux sociaux, un œil sur Wikipédia et le monde]] par Antimuonium

'''Le wik’hit-parade'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Wikit|Articles les plus vus en juin 2026]] par Ælfgar

&lt;/div&gt;
|-
| style=&quot;font-family:Times New Roman; text-align:center; font-size:90%;&quot; | [[w:fr:Wikipédia:RAW/2026-07-05|Lire tout le numéro]]
|-
| valign=&quot;top&quot; colspan=&quot;2&quot; style=&quot;padding:0.5em; font-family:Times New Roman;text-align:center; font-size:100%;&quot; |
Venez rédiger le prochain numéro, y parler de ce qui se fait dans votre communauté : [[w:fr:Discussion_Wikipédia:RAW/Rédaction|Salle de rédaction]].&lt;/br&gt;Les anciens numéros sont retrouvables [[w:fr:Modèle:Palette RAW|ici]].
|-
|}
|}
&lt;div style=&quot;margin-top:10px; font-size:90%; padding-left:5px; font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif;&quot;&gt;[[w:fr:Wikipédia:RAW/Inscription|Abonnez-vous !]] [[Utilisateur:L&amp;#39;embellie|L&amp;#39;embellie]] ([[Discussion utilisateur:L&amp;#39;embellie|discussion]]) 5 juillet 2026 à 01:53 (CEST)&lt;/div&gt;

== Les RAW en mode fiesta sur la Wikimania ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro d'août 2026 (n°295) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-08-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;&lt;/div&gt;

'''Un numéro exceptionnel'''

La conférence Wikimania s'est achevée le 25 juillet. Que vous ressentiez de la frustration (si vous n’avez pas pu y assister) ou du [[:w:Wikipédia:Wikispleen|wikispleen]] (si vous y étiez et que vous avez du mal à digérer que ce soit déjà fini), l’équipe des RAW n’a pas ménagé ses efforts pour vous proposer un numéro XXL qui revient en long, en large et en travers sur cet événement qui le mérite bien. Comptes-rendus, témoignages, entretiens, il y en aura pour tous les goûts ! Le numéro est aussi exceptionnel par le nombre de rédactrices et de rédacteurs qui y ont participé {{incise|merci !|stop}} 

Au-delà de Wikimania, l’actualité wikimédienne est loin d’être paisible cet été. Nous vous proposons donc aussi de revenir en détail sur la crise qui secoue la fondation Wikimédia autour de la reconnaissance du syndicat Wiki Workers United (WWU). Nous aurons probablement l’occasion de couvrir la suite de cette histoire dans le prochain numéro. D’ici là, bonne lecture !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia et des nouveaux outils

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Dossier spécial Wikimania&lt;/span&gt;'''

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les POV&lt;/span&gt;'''&lt;br&gt;— Ma Wikimania : la joie, l'inquiétude et la raison d'être&lt;br&gt;— Témoignages : regards sur la Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;L'Analyse&lt;/span&gt;''' — La crise s'intensifie après le refus de la WMF de reconnaître le syndicat WWU

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Comptes-rendus&lt;/span&gt;'''&lt;br&gt;— Une Wikimania sous le signe de la jeunesse&lt;br&gt;— Sur les conséquences de la définition de « wikimédien·ne »&lt;br&gt;— Petit tour d’horizon de la créativité wikimédienne&lt;br&gt;— CultureStrong : respecter les savoirs des Premières Nations sur les plateformes Wikimédia&lt;br&gt;— Des événements techniques à Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Interviews&lt;/span&gt;'''&lt;br&gt;— Ses goûts, sa Wikimania, sa prochaine tournée... : Baby Globe nous dévoile tout !&lt;br&gt;— Jules*, notre Wikimédien de l'année : comment rendre compte du changement climatique tout en protégeant l'encyclopédie

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : si un sujet vous tient à cœur, n'hésitez pas à proposer une idée d'article ou à participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]]. Toutes les contributions sont les bienvenues, quel que soit votre wiki d'origine ! &lt;span class=&quot;smiley&quot;&gt;[[Image:Face-smile.svg|20px|Sourire|alt=Émoticône sourire]]&lt;/span&gt;

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 août 2026 à 00:28 (CEST)

== Bientôt les 20 ans de Wikiversité ==

Bonjour.

Un petit message de « débauchage » dans le cadre d'un projet d'amélioration de Wikiversité. Comme dit la chanson : « On n'a pas tous les jours vingt ans ! » Plus d'infos [[v:Wikiversité:La_salle_café/août_2026#Améliorer_Wikiversité_pour_ses_vingt_ans_d'existence|dans la salle café du projet]].

Belle fin de journée à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 août 2026 à 00:26 (CEST)

== [[:Catégorie:Suppressions immédiates demandées|Série de demandes de suppression immédiate]] ==

Bonjour,

La [[:Catégorie:Suppressions immédiates demandées]] est de nouveau pleine, mais cette fois, il semble qu'elle ait été remplie par le seul {{U|Xhungab}}.

Cordialement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 16 août 2026 à 14:56 (CEST)
:{{fait}} Bonjour, oui c'était effectivement un ensemble d'ébauches abandonnées. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 17 août 2026 à 10:38 (CEST)
::Merci pour votre aide [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 août 2026 à 14:26 (CEST)

== Deux idées à débattre ==

Bonjour.

Vu le travail de traitement des pages et livres abandonnés et suite à une discussion avec @[[Utilisateur:Xhungab|Xhungab]] reprise ci-dessous, j'aimerais soumettre deux idées à la communauté Wikilivres.

'''La première idée''' est de déplacer toutes les pages et livres dont le développement est abandonné depuis longtemps en sous-page de l'auteur principal tout en laissant un message sur sa page de discussion avec un lien pointant vers la sous-page en question. Ce message pouvant faire l'objet d'un modèle.

Avantage : 1. Pas besoin d'être admin pour faire ce genre de maintenance. 2. Pas de risque de frustrer un auteur ni de perdre de vue des informations intéressantes. 3. Ceci dans le but d'améliorer l'apparence de Wikilivres au niveau du contenu visible sur l'espace de nom principal.

Nécessité : 1. Créer un modèle à placer sur la page de discussion de l'auteur principal après déplacement. 2. Définir la durée d'abandon des pages à déplacer.

'''La deuxième idée''' est de donner les outils d'administrateurs à des personnes qui ne veulent pas endosser cette responsabilité à long terme et de manière continue, mais qui sont d'accord d'en faire usage dans le cadre d'un projet de maintenance temporaire. Cela pourrait être utile pour @[[Utilisateur:Fourmidable|Fourmidable]] s'il le souhaite, à moins qu'il se décide à déposer sa candidature pour une nomination définitive. Ce qui serait une bonne idée, je trouve.

Qu'en pensez-vous @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Grondin|Grondin]] ?

Une prise de décision est-elle nécessaire si on décidait une mise en application ?

Bien à vous tous,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 01:50 (CEST)

:Bonjour,
:J'ai proposé une liste de livres à supprimer
:https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate
:Doit-on réellement les garder ? ;) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 10:21 (CEST)
::Quel est l'avantage de la suppression par rapport au déplacement @[[Utilisateur:Xhungab|Xhungab]]? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:56 (CEST)
:::En déterminant un contenu minimum, on peut faire le tri de ce que l'on supprime et ce que l'on déplace. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:58 (CEST)
::::Bonjour,
::::Les droits administrateurs temporaires sont difficiles à gérer : un bureaucrate peut attribuer le status administrateur mais pas le retirer.
::::Concernant les critères suppression ou renommage, je propose :
::::* (cas 1) Une page qui ne contient vraiment aucun texte (ex : seulement des liens rouges) --&gt; suppression
::::* (cas 2) Une page avec quelques phrases significatives récupérables --&gt; soit (a) tenter de fusionner dans un livre qui aborde le même sujet ou sujet connexe, soit (b) renommer en sous-page de l'auteur si aucun livre pour la fusion ne convient
::::* (cas 3) Une page avec plus de contenu que (cas 2) --&gt; conserver
::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 24 août 2026 à 19:33 (CEST)
:::::Salut @[[Utilisateur:DavidL|DavidL]]. Oui, c'est raisonnable. Reste que la fusion, c'est compliqué. J'ai essayé, mais je ne comprends rien. Une vidéo m'aiderait à comprendre, mais j'en ai pas trouvé. Ensuite, si on garde, genre un livre abandonné depuis plus de trois ans avec un chapitre entamé sur cinq prévus, par exemple, on le laisse dans l'espace principal, ou on le déplace vers l'espace utilisateur de l'auteur ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 25 août 2026 à 00:38 (CEST)
::::::Pour ce cas je propose de le fusionner si possible, comme (cas 2)(a) ; sinon le conserver, comme (cas3) afin qu'un utilisateur motivé puisse reprendre le livre.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 25 août 2026 à 08:36 (CEST)
:::::::Ok. Es-tu à l'aise avec la fusion @[[Utilisateur:DavidL|DavidL]] ? Car c'est une solution intéressante, mais je n'y arrive pas. Il y a toujours un message que je ne comprends pas et suite à quoi je préfère arrêter. Serais-tu dispo pour m'expliquer comment faire durant un appel vidéo ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:30 (CEST)
::::::::Bonjour {{Mention|Lionel Scheepmans}}, je suis très favorable à tes deux idées ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 août 2026 à 15:39 (CEST)
:::::::::Ok @[[Utilisateur:Fourmidable|Fourmidable]], je me dis qu'il serait encore bien d'avoir les avis de @[[Utilisateur:JackPotte|JackPotte]], voir de @[[Utilisateur:Grondin|Grondin]], s'ils trouvent le temps nécessaire pour le faire. Et puis, on peut penser tout doucement à créer une page pour fixer des décisions en votant si nécessaire pour confirmer l'adhésion générale ou grandement majoritaire.
:::::::::C'est curieux, je voulais travailler sur Wikiversité et finalement je me trouve plus actif sur Wikilivres. Mais les enjeux sont les mêmes et beaucoup de personnes actives ici le sont aussi sur Wikiversité, y compris parmi les administrateurs. En avançant dans Wikilivres, j'ai donc aussi l'impression que l'on avance sur Wikiversité.
:::::::::Au fait, fourmidable ? Tu ne serais pas intéressé, toi, de prendre un balai dans Wikilivres ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:27 (CEST)

== Demande d'aide pour amélioré Wikbook. Merci ==

* Actuellement j'ai proposé mes services pour améliorer wikibook. J'ai créé un partenariat informel avec des administrateurs, je propose des pages et des livres à supprimer. Ils décident soit de suivre ma demande, soit de la neutraliser. Je les remercie pour leur patience et leur aide.

- https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate


*Certain livres semblent trop avancé pour suivre cette procédure.

- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026

Dans cette page, je propose des livres trop avancés pour être traités rapidement. Il faut un vote pour que les demandes soient acceptées.
Aujourd'hui j'ai besoin de vous pour faire avancer mes propositions, sur des livres peut-être intéressants mais abandonnés depuis plus de trois ans, cinq ans, dix ans, vingt ans.

Si vous appréciez mon dévouement pour Wikibook et que vous souhaitez m'aider, ''il suffit chaque semaine de rajouter la commande'' {{VoteSupprimer}} ''sur les livres que je propose''. '''Entré {{}} puis à l'intérieur des parentthèses VoteSupprimer''' et signer votre accord. Merci pour votre aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 25 août 2026 à 10:33 (CEST)

:Salut @[[Utilisateur:Xhungab|Xhungab]], merci à toi pour ton engagement ! J'ai supprimé les pages qui étaient pratiquement vides dans ta liste. J'ai laissé les autres car la proposition de fusion est invoquée par @[[Utilisateur:DavidL|DavidL]] pour les pages avec du contenu. Malheureusement , je ne comprends pas comment fonctionne l'outil de fusion. J'espère que quelqu'un voudra bien m'expliquer le fonctionnement via un appel vidéo. Car je ne comprends pas les explications écrites. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:53 (CEST)
::Bonjour, Merci pour ton aide.
::.
::* J'ai travaillé sur la liste des pages les plus anciennement modifiées de l'année 2006. J'ai proposé tous les livres en errance à la suppression par vote.
::- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026
::Je vais attendre qu'elle soit traitée. Soit en supprimant ces livres soit en supprimant ma demande. Ensuite je ferai l'année 2007.
::.
::*Tu m'a posé une question.
::Quel est l'avantage de la suppression par rapport au déplacement ?
::Je vais essayer de te répondre dans mon prochain message. (Ce sera juste un délire d'un mois d'août un peu chaud). [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 09:20 (CEST)
:::C'est motivant de voir des gens motivés =)
:::Prend ton temps, il n'y a aucune échéance dans les projets Wikimédia, c'est un processus en continu qui peut s'étendre à plusieurs générations... Et si c'est plus facile pour toi de passer à l'oral, sache que je suis partant pour une discussion audio ou vidéo. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:35 (CEST)

== J'ai fait un rêve. ==

J'ai fait un rêve.

Un lieu où des amateurs passionnés proposeraient de partager leurs travaux avec des étudiants curieux. Pas les meilleurs travaux du monde. Mais pas les pires non plus. Un endroit où les anciens passeraient  le relais à ceux qui présentent leurs avenirs.  

Ce serait une petite bibliothèque avec une cinquantaine de livres disponibles à l'étude. Cinq ou six livres en construction que les étudiants pourraient travailler avec l'auteur. Tous les ans quelques livres supplémentaires viendraient enrichir ce lieu d'étude.

Aujourd'hui, il existe Wikibook. Un lieu où des auteurs malveillants prouvent que le travail collaboratif ne fonctionne pas. Ils créent des livres parfaitement construits de quelques chapitres puis les abandonnent sans scrupule. Ces livres moisissent depuis cinq, dix, quinze, vingt ans.

Wikibook c'est:
* La bibliothèque de livres pédagogiques libres que chacun peut améliorer.
* 569 livres contenant 22 112 pages.
.
* 569 livres dont 450 livres à l'abandon depuis cinq, dix, quinze, vingt ans.


Oui, aujourd'hui Wikibook peut changer. Wikibook va changer. Wikibook pour les étudiants va renaître de ses cendres. Les cendres des vieux livres abandonnés. Les auteurs devront faire honnêtement leur travail, ou les étudiants feront le leur.

Ceci n'est juste qu'un rêve dans un mois d'août un peu plus chaud que d'habitude.

Merci pour m'avoir suivi jusqu'ici. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 10:13 (CEST)

:Je trouve que c'est un très beau rêve @[[Utilisateur:Xhungab|Xhungab]]. Dans ce rêve, on peut voir la partie remplie du verre au lieu de la partie vide. Sur Wikilivres, il y a plus de 100 ouvrages terminés entièrement libres d'usage et toujours améliorables collectivement. Deux fois plus que la cinquantaine de livres dont tu parles dans ton rêve.
:C'est normal d'abandonner un projet d'écriture. La vie est tellement imprévisible. Les ressources en temps et énergie tant limitées. Combien de personnes ont commencé un livre sur papier ou sur leur ordi sans jamais le terminer ?
:C'est pareil sur Wikilivres, sauf que c'est visible aux yeux de tous.
:Quand on commence un truc, c'est jamais dans l'intention de l'arrêter. Si on arrête, c'est qu'il y a des raisons à cela. Je n'ai donc pas envie de voir dans ces abandons des actes de malveillance, ni de critiquer leurs auteurs. J'ai d'ailleurs moi-même des projets que je n'arrive pas à concrétiser (exemple).
:Je pense au contraire que ce n'est pas un problème à partir du moment où nous avons la liberté et les outils (communication, suppression, fusion) qui nous permettent de faire le tri entre ce qui est terminé, voire même ce qui est de qualité, et le reste.
:Ce rêve est donc possible et mes démarches pour devenir wikimédien en résidence à l'université sont une démarche qui va dans ce sens. J'ai d'ailleurs apporté les preuves que l'intégration des projets Wikimédia dans le processus d'apprentissage universitaire est non seulement possible, mais hyper efficace. Malheureusement, j'ai toujours l'impression que cela n'intéresse personne. Ni à l'Unif, ni dans Wikimédia. Mais je ne désespère pas. Les changements de paradigmes sont lents en raison des habitudes. C'est une fatalité chez l'humain. Il faut faire avec.
:Mais donc. Concentrons-nous sur la manière d'organiser notre bibliothèque pour que les visiteurs puissent confortablement voir ce qui s'y trouve en séparant, livres terminés, livres de qualité (cela se fait bien avec les articles de Wikipédia), livres en cours d'édition et livres abandonnés, etc. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:32 (CEST)
::Je pense que nos points de vue sont irréconciliables en toute amitié. Pour moi, Wikibook est une  bibliothèque de livres pédagogiques libres que chacun peut améliorer. Soit on peut mettre un étudiant sur un livre. Soit ce livre est inutile (Je parle de livre de plus de trois ans). 
::.
::Wikibook n'est pas un entrepôt pour les auteurs.  C'est une bibliothèque.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 14:57 (CEST)
:::@[[Utilisateur:Xhungab|Xhungab]], c'est bien que l'on ne soit pas d'accord, car cela permet d'avancer vers une solution que tout le monde pourra approuver. C'est le principe du consensus et cela prend du temps en discussion. C'est normal et sain. En de plus, ce qui est dit ici est tout à fait pertinent pour Wikiversité qui est confronté à des problèmes similaires que Wikilivres.
:::J'exprime mes idées ci-dessous mes idées autrement pour voir si cela peut se rapprocher de ta propre vision des choses.
:::J'imagine la bibliothèque Wikilivres avec trois pièces :
:::# Une pièce principale à l'entrée qui reprend tous les livres terminés et prêts à l'emploi par une personne désireuse de les utiliser dans le cadre d'un apprentissage. Comme dans toutes les bonnes bibliothèques, ces ouvrages sont rangés par thèmes et certains d'entre eux sont mis en évidence en raison de leurs qualités, de leur pertinence par rapport à l'actualité, etc.
:::# Une pièce archives à l'arrière du bâtiment (un espace de nom que l'on pourrait choisir parmi ceux existants ou créer si nécessaire) dans laquelle on entrepose toute une série de livres abandonnés mais dont le contenu est archivé dans le but d'une éventuelle réutilisation. Cette réutilisation, comme le suggère @[[Utilisateur:DavidL|DavidL]], peut s'effectuer dans le cadre d'une fusion du contenu abandonné avec un autre contenu abandonné, ou mieux encore, si cela se présente, avec un livre terminé dans lequel les informations utiles du document abandonné sont manquantes. À noter que cela représente beaucoup de travail, tant pour la relecture que pour la mise en œuvre des fusions, qui, à mes yeux de personne expérimentée dans l'usage de MediaWiki, est un processus compliqué. De plus, il ne peut être fait que par des personnes ayant les outils d'administrateur. C'est-à-dire quatre personnes, dont deux ou trois actives dans ces récentes discussions.
:::# Dans la librairie Wikilivres, il y a ensuite un étage dans lequel chaque personne inscrite peut bénéficier d'un espace personnel, pour se présenter, stocker des informations, mais également travailler sur des projets personnels d'écriture. En tenant compte de ceci, on peut alors aussi imaginer de déplacer les ouvrages inachevés de la pièce principale à l'entrée de la librairie, vers ces différents locaux selon leurs auteurs respectifs.
:::Face à ces trois espaces, la question qu'il reste à se poser est de savoir si et dans quelles condition, on peut déplacer les ouvrages inachevés vers une salle d'archive, ou dans les locaux personnels des auteurs ? Cela en signalant que ce déplacement peut être fait très facilement et par toutes les personnes qui le souhaitent, même sans inscription à la bibliothèque. Ce qui est un grand avantage par rapport à la fusion.
:::Pendant ce temps, à l'accueil de la bibliothèque Wikibook, on invite les visiteurs à parcourir la pièce avec les ouvrages terminés, mais également la pièce archive, où ils peuvent trouver des ouvrages inachevés, au cas où ils veulent poursuivre leurs développements, ou trouver des ressources intéressantes pour leurs travaux personnels. On les informe ensuite aussi qu'avec leur inscription, ils bénéficient d'un local pour leurs activités personnelles et notamment pour y placer les ébauches d'ouvrages qu'ils désirent rédiger.
:::Que penses-tu de mon propre rêve ? Est-il si différent du tien ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:17 (CEST)
::::Et les autres ? @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Fourmidable|Fourmidable]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:Grondin|Grondin]]. Que pensez-vous de nos rêves ? Et, si le mien vous parle, quelles seraient vos propositions pour orienter les déplacements de pages à l'abandon entre un espace d'archivage (qui pourrait être créé) et des espaces utilisateurs ? Le nombre d'octets ? La finalisation d'une section ou d'un chapitre ? Quelles autres possibilités ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:37 (CEST)
::::: Bonjour, a priori ça doit se régler au cas par cas sur [[Wikilivres:Demandes de suppression]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]])

::::Bonjour,
::::La structure de Wikibook est parfaite grâce à sa vitrine.  Pour moi, il y a juste un problème sur les listes sur la droite : Arts, Loisir, Histoire, Langues, Technologie, Informatique, Sciences, Sciences humaines. Ces listes ne devraient donner accès qu'aux livres terminés.
::::Ces listes actuelles pourraient être caché dans un espace création qui pourrait être posé avec le lien Nouveauté en bas de la page.
::::Pour la gestion des livres, il suffirait qu'une ou deux personnes parcourent la bibliothèque et proposent quelques suppressions chaque semaine, pour en quelques mois éclaircir la situation. Je pense que l'on peut faire confiance aux administrateurs pour gérer la situation des livres, ceux qui sont à garder et les autres. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 18:30 (CEST)
:::::@[[Utilisateur:JackPotte|JackPotte]]. Le cas par cas est ce que nous faisons depuis toujours. Cela nous amène à la situation actuelle qui semble ne pas convenir à tous. En tout cas, c'est mon cas. Ici comme sur Wikiversité. Quand, en navigant sur le site, une personne tombe neuf fois sur dix sur des pages presque vides et inachevées, comme c'est le cas sur Wikilivre, elle se dit : c'est quoi ce site ? Elle passe alors à autre chose de plus vivant, genre https://zestedesavoir.com/ ou autre. Sans changements éditoriaux, je pense que la situation évoluera.
:::::@[[Utilisateur:Xhungab|Xhungab]], on peut faire comme tu dis. Cependant, la charge de travail repose sur une double action, la proposition d'abord et le traitement ensuite. Un traitement qui finalement repose sur les épaules des administrateurs. Nous ne sommes que des bénévoles peu nombreux et pas toujours disponibles.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 19:13 (CEST)
:Créer un livre, le ranger, en établir un plan, le catégoriser n'est pas un travail négligeable... Un travail que d'autres personnes intéressées pour écrire sur le sujet n'ont pas à refaire 🤷‍♂️ ...

== Petite proposition indécente à Lionel ==

Bonjour  Lionel,

Je souhaiterais te proposer un petit projet.

a) Dans la page principale de wikibook tu créés une page &quot;Espace pour les auteurs&quot;. Tu insères cette page devant le lien &quot;Nouveautés&quot;.
.

b) Tu copies dans cette page la liste des liens qui se trouvent en haut à droite dans la nouvelle page. (Arts, Loisirs, ...) Tu ne les modifies pas dans la page principale.
.

c) Dans la nouvelle page tu peux écrire un texte du genre.
Dans cette page, vous trouverez la liste de tous les livres disponibles sur Wikibook. Vous trouverez en particulier des livres en construction et vous pourrez entrer en contact avec les auteurs. Vous trouverez aussi des livres en construction sans auteur actif que vous pourrez compléter.


Cela est la première étape, si l'aventure t'intéresse. En fait tu ajoutes juste une page, que tu pourras supprimer si les besoins se font sentir. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 12:25 (CEST)

:La proposition est très décente @[[Utilisateur:Xhungab|Xhungab]] 
:Mais avant toute choses le plus prudent est de lancer une prise dé décision pour s'assurer d'un concesnsus en faveurs des changements dont nous débatons actuellement.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 août 2026 à 15:40 (CEST)
::Toutes ces actions seront réversibles. On ajoute une page. Un problème, on la supprime. 
::On fait rapidement les changements, on attend trois jours. En cas de problème, on supprime tout. Il suffira de s'excuser et de dire que l'on ne savait pas que l'on n'avait pas le droit. 
:: Un espace pour les lecteurs et un espace pour les auteurs séparés.
::[https://fr.wikibooks.org/wiki/Utilisateur:Xhungab Nouvelle page wikibook][[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 16:49 (CEST)
:@[[Utilisateur:Xhungab|Xhungab]] , ma grand mère disait : faire et défaire, c'est toujours travailler. Pour les grand changements, on a coutume de faire un prise de décision composée des propositions, suivies de débats et d'un vote.
:En plus, certaines décisions nécessite un changement technique et ce n'est pas toujours facilement réversible. Comme créer un nouvel espace de nom pour y transfèrer une catégorie de pages  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 28 août 2026 à 03:07 (CEST)
::Merci pour ton aide. Tu comprends maintenant pourquoi toi tu es un administrateur et moi pas.
::.
::'''Oui, aujourd'hui Wikibook peut changer. Wikibook va changer.''' 
::.
::*  '''Le changement c'est Maintenant :''' [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']
::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 28 août 2026 à 08:33 (CEST)
:::Ton enthousiasme fait plaisir @[[Utilisateur:Xhungab|Xhungab]], et je serais en faveur d'un style plus épuré de notre page d'accueil en plus d'une méthodes de classement et de séparation des ouvrages terminé, en cours et abandonnés. Je pense qu'à terme, nous pourrions faire une proposition de changement à soumettre au reste de la communauté. Par chance, nous ne sommes pas nombreux, cela simplifire les discussions et le processus de décision. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 19:26 (CEST)
::::Cette page  [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook'''] propose la vitrine, les livres disponibles, les mini-livres disponibles pour les lecteurs. Les lecteurs ne seront en contact qu'avec les livres terminés.
::::.
::::En bas à côté des nouveautés, il y a l' '''[https://fr.wikibooks.org/wiki/Discussion_utilisateur:Xhungab Espace pour les auteurs]''', avec tous les livres du site rangés par thème ou par niveau d'avancement si on clique sur l'image. Sinon, il y a une liste de catégories art,...
::::.
::::Cette proposition sépare donc deux espaces. Un pour les lecteurs et un pour les auteurs. Il suffirait maintenant plus qu'à nettoyer l'espace auteurs. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 20:22 (CEST)
L'usage des catégories me semble aussi une manière très pratique de trier le contenu de Wikilivre. Malheureusement, ces pages ne sont pas très sexy du coup l'usage de type de code pourrait être utile :

{ {Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={ { #categorytree:Livres terminés|mode=pages} } } }

Avec le rendu ci-dessous :
{{Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={{ #categorytree:Livres terminés|mode=pages}}}}

On pourrait ainsi imaginer d'intégrer directement ce code dans la page d'accueil pour afficher une boite déroulante au lieu d'envoyer le visiteur en dehors de la page d'accueil. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:08 (CEST)

:Tu devrais créer la page Lioneltest01 dans ta page utilisateur. Copier le code de la page principale de wikibook.
:Puis faire les changements que tu juges nécessaires. Tu peux éventuellement faire plusieurs pages. Ensuite, tu mets cette page dans le bistro pour que l'on puisse voir le résultat. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 21:22 (CEST)
::Je devrais, tu devrais, il devrait, nous devrions ... =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:28 (CEST)
:::Chaque chose en son temps.
:::1. Débattre ici des idées de changements.
:::2. Mettre les choses en place pour leur réalisation, comme la mise à jour du modèle:boite déroulante en s'inspirant de celui de Wikipédia ou d'autres sites.
:::3. Quand il n'y a plus de nouvelle idée ici, créer une page genre :[[Wikilivres:Prise de décision/Nouvelle page d'accueil et gestion des abandons]] avec une description précise des projets de changements, et une éventuelle [[Accueil/projet|page de présentation du projet d'un nouvelle page d'accueil]]
:::4. Poursuivre les discussions et propositions si nécessaire.
:::5. Quand on a fait le tour, passer au vote.
:::6. Mettre les décisions en application. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:03 (CEST)
::::Je propose actuellement un projet qui se trouve sur ma page utilisateur. Pourrais-tu lancer une prise de décision sur ce projet. Je ne sais pas comment on fait une telle demande. Je suis prêt à présenter mon projet et à recevoir les critiques. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 22:16 (CEST)
:::::''Aide-toi le ciel t'aidera''. La bureaucratie, c'est pas mon truc. Et puis ça m'irrite un peu que tu enchaines des demandes de faire des choses qui ne demande pas les outils d'administrateurs. Raisons pour lequelles, je pense finalement que l'on gagnerait à appliquer la [[w:Do-ocratie|Do-ocratie]] qui a fait ses preuves dans le monde du libre dont les projets Wikimédia sont issus.
:::::Si tu as une idée et qu'elle ne demande pas des droits de modification que tu n'as pas, fait la et on se retrouve en page de discussion de la page de tes changements en cas de problèmes et pour d'éventuelle commentaire. Sans réaction, pense à ''qui ne dit mot conscent''.
:::::Si tes idées demandes les outils d'administrateurs, tu peux alors demander à un admin de le faire. Libre à lui de le faire ou pas et si ça lui plait, si il a envie, si il prend le temps. Nous sommes bénévoles... Il y a bien des gens payés par la fondation, mais comment dire... Disons qu'ils ne sont pas des plus serviables. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:57 (CEST)
::::::Excuse moi je pensais qu'il faillait être administrateur pour faire une demande de prise de décision. Je vais donc essayer tous seul. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 23:06 (CEST)
:::::::Ok @[[Utilisateur:Xhungab|Xhungab]], pas de soucis. On ne peut pas tout savoir =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 30 août 2026 à 01:45 (CEST)

== Wikilivres:Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''


Merci pour votre participation

[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 30 août 2026 à 00:43 (CEST)

:Bonjour @[[Utilisateur:Xhungab|Xhungab]]. Content de te revoir dans les murs de Wikiversité après nos échanges sur Wikilivres. Je comprends ton sentiment de solitude, je le ressens aussi souvent. Il faut l'accepter et ne pas se décourager pour autant. Nous avons la chance de fonctionner dans une organisation bénévole, dans laquelle personne n'est tenu de répondre à des demandes. De ce fait, les choses évoluent lentement et en fonction des disponibilités. Dis-toi aussi que la période estivale est toujours un moment d'acalmie dans la participation. Moi par exemple, quand il fait bon, je préfère passer du temps sur des occupations extérieures que devant un écran.
:Cela dit, tu dois garder 3 règles implicites qui sont fréquemment appliquées dans les projets Wikimédia.
:1. ''Qui ne dit mot consent''. Si les personnes ne réagissent pas, cela ne veut pas dire qu'elles ne lisent pas. Par économie de temps et pour les personnes trop occupées ou pas assez motivées pour s'investir, ne pas réagir est un signe de consentement implicite.
:2. ''Les absents ont toujours tort.'' Lorsque l'on fait les choses dans les règles de l'art, par exemple comme tu le fais en lançant une prise de décision pour opérer un changement significatif dans Wikilivres, aucune personne absente durant un processus de décision clôturé viendra remettre en cause les choses par la suite.
:3. La doocratie. Les wikis sont des espaces de libertés au niveau de l'amélioration des contenus, mais également de l'organisation et des formes de contenus. En dehors du vandalisme qui est bien contrôlé par des personnes telles que @[[Utilisateur:Crochet.david|Crochet.david]], toute initiative est souvent perçue comme bienvenue. @[[Utilisateur:Fourmidable|Fourmidable]], par exemple, depuis qu'il est administrateur, a fait de nombreuses améliorations dans Wikiversité sans demander l'avis de la communauté. Personne ne lui a reproché son investissement. Si quelque chose qu'il a entrepris ne plaît pas à quelqu'un, une discussion commence entre lui et cette personne pour chercher une entente.
:Voilà tout.
:Je te rejoins aussi sur le fait que ce qui est décidé et mis en place sur Wikilivres peut tout à fait servir d'exemple pour Wikiversité et vice versa. Je ne suis pas le seul à être administrateur dans les deux projets et cela aide beaucoup à la création d'une synergie entre les deux projets qui sont finalement très complémentaires. Cela n'est pas étonnant d'ailleurs lorsque l'on sait que Wikiversité est né de Wikilivres.
:Une belle fin de journée à toi et à tous ceux qui liront ce message. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:30 (CEST)
::Merci. Pour tes explications. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 6 septembre 2026 à 13:50 (CEST)
:::Avec plaisir. Pense aussi qu'il n'y a pas de combat dans les projets Wiki, mais un lent processus évolutif, sans fin programmée, et qui est pour moi l'un des meilleurs que je connaisse. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:57 (CEST)

== Les RAW sont arrivés, la rentrée peut commencer ! ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro de&amp;nbsp;septembre 2026 ({{numéro|296}}) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-09-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;
&lt;/div&gt;

'''C'est la rentrée'''

Après un numéro très dense en août en raison de la Wikimania, celui-ci est un peu plus léger car l'équipe s'est octroyée quelques vacances. Cela n'empêche pas le mouvement de continuer à vivre, avec une rentrée déjà animée ! Du côté des projets francophones, le Wiktionnaire vient de franchir le cap symbolique des sept millions d’entrées, tandis que Wikipédia continue de voir fleurir sondages et discussions sur son fonctionnement.

Une rentrée, donc, placée sous le signe de la construction collective : de nouveaux outils pour contribuer, de nouveaux espaces pour échanger, de nouvelles formes d’organisation… Ce numéro des RAW vous propose de faire le tour de cette actualité, avant de reprendre tranquillement le chemin des projets Wikimédia.

L'équipe de la rédaction a également commencé à réfléchir à un nouveau nom pour remplacer l'énigmatique « RAW ». N'hésitez pas à venir donner votre avis dans la [[:w:Discussion Wikipédia:RAW/Rédaction#Changement de nom|section dédiée]] !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia, des nouveaux outils et des articles de recherche

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : n'hésitez pas à suggérer des sujets ou participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]] !

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 septembre 2026 à 00:17 (CEST)

== Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés ==

J'ai posé une demande de prise de décision concernant le sujet suivant.


[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Modifier_le_contenue_de_l%27espace_Nouveaut%C3%A9s Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés]

Merci pour votre participation [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 9 septembre 2026 à 14:38 (CEST)

== '''Décision''':Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''

'''Décision pour : [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']'''

Résultats : 3 + Pour, un Neutre Neutre et un - Contre soit 60 % de + Pour par rapport au total des votes exprimés : la proposition est adoptée. Quelques propositions de reformulations et de nuances ont été faites qui pourront être prise en compte. Cdlt, VIGNERON * discut. 13 septembre 2026 à 18:27 (CEST)

Merci pour votre participation. Ma première proposition était un peu malhabile, mais grâce à vos interventions je pense que l'on a créé quelque chose de correct. '''Merci à tous''' [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 13 septembre 2026 à 20:22 (CEST)

== Je ne suis pas content tous seul. ==
'''Suite à l'installation de la nouvelle page de la Vitrine, je ne suis pas content, j'ai pris 24h pour réfléchir.
'''

J'avais posé une demande de prise de décision concernant le sujet suivant.


'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace auteurs sur la page d'accueil]'''


'''Créer un espace lecteurs''' : Où est l'espace pour les lecteurs?


 Découvrir la bibliothèque
 Livres terminés - Mini Livres - Tous les livres


'''Dans une bibliothèque''', un livre est disponible ou indisponible. C'est chez l'auteur ou chez l'imprimeur qu'un livre est terminé.


'''Je suis un nouveau sur Wikilivre'''. Je vois, &quot;Découvrir la bibliothèque&quot;, je vais directement dans &quot;'''[[Wikilivres:Tous les livres|Tous les livres]]'''&quot;. Je me retrouve dans un labyrinthe qui me balade de répertoires en répertoires pour finir sur une ébauche abandonnée depuis 5, 10, 20 ans.


Je ne suis pas content. J'avais proposé à l'administrateur un changement en 2 minutes. Copier cette page dans la Vitrine, [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab La Nouvelle Vitrine]. Il a décidé de passer plusieurs heures à modifier la prise de décision. Je ne suis pas content. Je suppose que je suis le seul. 


Donc : '''Je ne suis pas content tous seul.''' Mais je me soigne. Un pan bagnat et une tourte aux blettes.

Merci de m'avoir lu [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 septembre 2026 à 10:51 (CEST)

:Bonjour @[[Utilisateur:Xhungab|Xhungab]].
:Nous tentons de fonctionner au consensus dans les projets Wikimédia. On essaie donc de faire les choses avec un consentement général. La prise de décision a été rapide, les discussions inachevées, et certaines personnes n'étaient pas satisfaite de tes propositions. Comme la cloture de la décision a été faite, je me suis mis au travail.
:Il est ensuite important de signaler que dans [[Discussion utilisateur:Lionel Scheepmans#Décision:Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil|une précédente discussion]], je suis resté ouvert à tout changement de la page d'accueil à partir de ce que j'ai considéré être le plus rationnel au regard de tout ce qui existait déjà. C'est-à-dire [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Index?prefix=&amp;namespace=4 de nombreuses pages] créées et améliorées par le passé que nous ne pouvons pas ignorer au risque de créer des doublons.
:Si tu es insatisfait du résultat, je te propose de nous retrouver, comme cela a déjà été proposé aussi dans notre précédente discussion, sur la [[Discussion:Accueil|page de discussion de la page d'accueil]] qui est le meilleurs endroit pour discuter de son contenu tout en étant sûr que ces discussion ne se perdent pas dans un archivage, comme c'est le cas pour le bistro. On peut donc s'y retrouver, avec toutes les autres personnes qui ont des propositions d'améliorations.
:Du reste, nous sommes tous bénévoles ici. Y compris les administrateurs. Pour moi, être bénévole, c'est faire les choses par sa propre volonté et avec bienveillance. Être volontaire bienveillant en quelque sorte. Pour ma part, je reste toujours bienveillant. Ma volonté quant à elle peut changer en fonction de mes convictions et motivations.
:Une belle fin de journée à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 17 septembre 2026 à 13:20 (CEST)</text>
      <sha1>fcp4q7ab1cs2dwimdbue0mzkr31m8xe</sha1>
    </revision>
    <revision>
      <id>772353</id>
      <parentid>772352</parentid>
      <timestamp>2026-09-17T11:29:18Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>/* Je ne suis pas content tous seul. */</comment>
      <origin>772353</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="75018" sha1="lahsqdi3o3tfy4pw2hyy6ojy0xcsnwj" xml:space="preserve">&lt;noinclude&gt;{{Wikilivres:Le Bistro/En-tête}}&lt;/noinclude&gt;

== Le meilleur à Wikilivres pour 2026 ! ==

Je crée la page du bistrot 2026 en transmettant mes vœux. Bonne année éditoriale à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 janvier 2026 à 06:05 (CET)
:Merci, meilleurs vœux ! [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 16 janvier 2026 à 09:53 (CET)
::Meilleurs vœux pour 2026 !
::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 janvier 2026 à 20:13 (CET)
:::Meilleurs vœux pour 2026
:::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 janvier 2026 à 11:56 (CET)
::::Bonne année et bonnes lectures et écritures !
::::[[Utilisateur:Matthius|Matthius]]


== Page orpheline du livre : États généraux du multilinguisme dans les outre-mer ==

Bonjour,

Le livre &quot;États généraux du multilinguisme dans les outre-mer&quot; a laissé quelques pages orphelines. Ces pages orphelines ont été recopiées ou regroupé dans le texte du livre. Elles font donc doublons.

Je montre dans ce livre [[Wikilivres:Feuilles dupliquées orphelines]] cette suite de pages orphelines accompagnée par la page où elles ont été recopiées.

Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 10 février 2026 à 19:57 (CET)

:@[[Utilisateur:Xhungab|Xhungab]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], bonjour. Je vois que l'on est en campagne de gestion de pages orphelines et je me pose la question de savoir si on doit les supprimer une fois réintégrées ailleurs ou les supprimer ? Je vois que les deux cas de figure ont été mis en œuvre précédemment. L'avantage de la fusion est de conserver l'historique des modifications, mais je ne suis pas habitué à le faire. Si quelqu'un d'entre vous pouvait m'indiquer une page d'explication, cela m'aiderait à m'y mettre. Ensuite, je me demande si la fusion a vraiment un sens lorsque c'est la même personne qui a créé la page orpheline et la nouvelle au contenu copié collé pour insertion ? Qu'en pensez-vous ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:02 (CET)
:::Ça fait plaisir de voir une personne s'investir dans la maintenance de Wikilivres =). Soit le ou la bienvenu.e. J'attends les avis des autres administrateurs pour te donner mon soutien @[[Utilisateur:Xhungab|Xhungab]]. @ bientôt. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:27 (CET)
:::: @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]] bonjour, je n'ai pas compris en quoi &quot;deux cas de figure ont été mis en œuvre précédemment&quot; : si la page est vide on la supprime et si elle a au moins une phrase valable on la fusionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:26 (CET)
::::Concernant l'auteur pour moi cela importe peu, car on souhaite conserver chaque élément permettant de prouver une primauté du droit d'auteur (par exemple pour ne pas accuser un contributeur d'avoir copié un site miroir de sa page supprimée). [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:30 (CET)
:::::Désolé [[Utilisateur:JackPotte|JackPotte]], je n'avais pas vu que les pages que tu as supprimées étaient vides. La règle est donc supprimer si vide et fusionner si non. Tu peux me conseiller une page d'aide pour oppérer les fusions ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:34 (CET)
::::::Salut,
::::::Pour la fusion d'historique :
::::::* soit [[Wikilivres:Le guide de l'administrateur#Fusionner deux pages|Utiliser la page spéciale pour cela]] (cependant ne fonctionne pas toujours),
::::::* soit [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages utiliser l'ancienne méthode] qui reste toujours valable quand la première ne fonctionne pas.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 13 février 2026 à 19:34 (CET)
:::::::Salut @[[Utilisateur:DavidL|DavidL]]. Je viens de tester l'outil fusionner avec les deux pages suivantes
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes/Contexte]]
:::::::vers
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes]]
:::::::Et j'ai le message suivant :
:::::::« La période spécifiée chevauche les versions préexistantes de la page de destination. »
:::::::Tu peux m'expliquer si tu as le temps ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 00:19 (CET)
::::::::Salut @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]]
::::::::Dans ce cas, j'utilise [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages l'ancienne méthode].
::::::::# Renommer A (page qui n'existera plus) vers B, sans laisser de redirection, et en cochant la case de suppression de B (case qui apparait après 1er clic sur le bouton Renommer) (&amp;rarr; l'historique de A est sur B, celui de B est supprimé)
::::::::# Supprimer B (&amp;rarr; l'historique de A et B sont supprimés)
::::::::# Restaurer B et cocher toutes les cases des versions (bouton &quot;Inverser la sélection&quot;) (&amp;rarr; restaurer l'historique de A et B)
::::::::# Effectuer une modification de la version finale de la page à afficher, trouvée dans l'historique.
::::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 février 2026 à 08:29 (CET)
:::::::::Merci @[[Utilisateur:DavidL|DavidL]]. Ça m'a l'air bien compliqué tout ça. Et avec toute les pages qu'il faut faire, ça risque de prendre un certain temps. Je manque de courage en pensant que c'est juste pour ajouter une ligne dans l'historique des versions. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 14:51 (CET)
::::::::::Finalement, dans l'exemple que j'ai pris, la fusion n'avait aucun sens puisque le contenu du doublon que j'ai finalement supprimé était intégralement repris dans l'autre doublon par le même auteur. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 22 août 2026 à 23:55 (CEST)
:::::::::::Désolé @[[Utilisateur:Xhungab|Xhungab]]. Je ne comprends rien à l'outil de fusion et je ne trouve rien qui me permet de comprendre sur le net. Une vidéo avec exemple des différents cas de figure serait bien, mais je ne trouve pas. Je vais donc laisser ce travail à ceux qui savent utiliser l'outil.
:::::::::::En revanche, j'ai remarqué que certains doublons, comme dit précédemment, ne nécessitent pas de fusion puisqu'il s'agit de pages qui ont été créées sans aucune autre modification, puis, copiées par le même auteur dans une autre page créée avec un autre nom, au lieu de faire un renommage. Il faudrait donc que je prenne le temps de parcourir la liste pour repérer ces cas de figure avant de supprimer le premier doublon. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 01:27 (CEST)
::::::::::::Merci pour ton aide. Actuellement ces pages ont été en quelque sorte neutralisées. Donc fais de ton mieux, mais ne te tracasse pas elles ne posent plus de problème. Encore merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 09:13 (CEST)
:::::::::::::OK @[[Utilisateur:Xhungab|Xhungab]], merci pour l'info. Au fait comment as-tu fais pour les détecter ? En parcourant les pages de la catégorie orphelines et en vérifiant celles qui sont doublons ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 12:36 (CEST)
::::::::::::::Dans la catégorie pages orphelines, il y avait un lien sur une page.
::::::::::::::Je choisissais une phrase et je recherchais avec la fonction recherche de wikibook où se trouvait cette phrase. Si c'était un doublon, j'avais un lien vers la nouvelle page. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 12:48 (CEST)
:::::::::::::::Intelligent. Tu poserais pas ta candidature d'admin !? Ici, avec @[[Utilisateur:Fourmidable|Fourmidable]] et puis sur wikiversité aussi. Ça pourrait aider pour le projet des 20 ans., si tu comote toujours t'investir. On est en sous effectif dans les deux projects et les communautés me semblent plus ouverte que sur Wikipédia. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 13:48 (CEST)
::::::::::::::::Je ne souhaite pas devenir un administrateur. Pourquoi ? Si on me donne du pouvoir, je l'utiliserais. Par la suite, ceux qui m'ont accordé le pouvoir auront le choix entre pleurer, nous quitter ou me mettre en arrêt de travail. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 14:59 (CEST)
:::::::::::::::::Ah ah ah. T'es si foireux que ça !? Ou peut-être as-tu eu des expériences antérieures ? Dans tous les cas, c'est super de ta part de pouvoir t'auto évaluer.
:::::::::::::::::Ceci dit, le système de demander au administrateurs de faire des tâches qu'il faut expliquer est une perte de temps et d'efficacité. On pourrait d'ailleurs penser à attribuer les droits temporairement pour effectuer certaines tâches. Je me demande si ça se fait déja quelque part ? Si oui, on pourrait s'en inspirer pour mettre le système en application sur Wikilibres et Wikobersité. T'en penses quoi @[[Utilisateur:Xhungab|Xhungab]] ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 15:40 (CEST)
::::::::::::::::::Oui, je pourrais obtenir des droits temporaires par rapport à un projet. Par exemple 2 projets
::::::::::::::::::Premier projet :  Supprimer toutes les feuilles volantes. Ce sont des feuilles tests très bien faites mais qui n'appartiennent à aucun livre. Je crois qu'il y a actuellement, Feuilles volantes – 54 P. 
:::::::::::::::::: 
:::::::::::::::::: Deuxième projet : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Pages_anciennes Les pages les plus anciennement modifiées]
::::::::::::::::::Supprimer tous les livres entre 2006 et 2010 qui sont à l'abandon. Parfois il sera possible de sauvegarder un livre en supprimant les chapitres vides, ce qui nous permettra de créer un livre complet. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 16:19 (CEST)
Donc, tu as du temps à consacrer à ce genre de maintenance ? Ce serait bête de ne pas en profiter. Reste à voir à présent si les autres administrateurs et bureaucrates seraient d'accord de t'octroyer les droits, tout en approuvant les deux projets que tu proposes. Cependant, je ne suis pas un grand fan des suppressions, je préfère de loin renommer les pages pour les placer en dehors de l'espace principal de sorte à ce que les auteurs puissent toujours les retrouver. Pour ça, un bon espace, c'est les sous-pages des principaux auteurs. Cela pourrait ainsi s'appliquer aux feuilles volantes et aux projets d'écriture abandonnés qui sont suffisamment développés pour justifier une conservation. L'avantage de cette méthode est qu'elle ne demande pas d'avoir les outils d'administrateurs. Faudrait voir maintenant dans quel cas on supprime et dans quel cas on renomme. On pourrait par exemple définir un nombre d'octets ou de caractères, question d'avoir un critère standard et accepté par tous. Qu'en penses-tu [[Utilisateur:Xhungab|Xhungab]] ?
:En fait je préfère continuer comme actuellement. Proposer mes services  pour améliorer wikibook sans avoir aucun droit. De cette manière, si je propose quelque chose d'incongru, comme cela est déjà arrivé, il suffit de neutraliser ma demande. Merci à ceux qui me suivent sur ce travail.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 01:52 (CEST)

:Je comprends @[[Utilisateur:Xhungab|Xhungab]]. Mais précisément, déplacer une page à l'abandon dans une sous-page l'espace utilisateur de l'auteur principal, cela ne demande justement aucun droit et tout le monde peut le faire, toi en premier puisque tu sembles actif à ce niveau. C'est pour ça que je te demande ton avis : que penses-tu de l'idée de déplacer les pages comme je viens de le décrire, plutôt que de les supprimer ? Je viens de soumettre l'idée dans une nouvelle discussion ci-dessous. Tu peux donner ton avis là-bas si tu veux. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 02:27 (CEST)

== archive.today ==
''Voir [[:w:Wikipédia:Le Bistro/21 février 2026#archive.today]].''

Ce site pose apparemment des problèmes de sécurité, il faudrait le remplacer au plus vite si possible, et sinon désactiver les liens.

[[Utilisateur:SyntaxTerror|SyntaxTerror]] ([[Discussion utilisateur:SyntaxTerror|discussion]]) 21 février 2026 à 13:07 (CET)
:Salut SyntaxTerror,
:* 0 liens vers archive.today : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.today]
:* &lt;s&gt;18&lt;/s&gt; 0 liens vers archive.is [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.is]
:* 0 liens vers archive.li [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.li]
:* 0 liens vers archive.ec [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ec]
:* 0 liens vers archive.ph [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ph]
:* 0 liens vers archive.fo [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.fo]
:* 0 liens vers archive.md [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.md]
:* &lt;s&gt;1&lt;/s&gt; 0 liens vers archive.vn [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.vn]
:* 0 liens vers archive.closed.social [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.closed.social]
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 21 février 2026 à 16:14 (CET)
::Merci pour vos efforts ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:22 (CEST)

== demande aide pour sortir du mode &quot;ébauche&quot; ==

je viens de terminer mon livre ... ci dessous. J'ai compris qu'il fallait le signaler comme n'étant plus au stade &quot;ébauche&quot;  commente faire   Merci

https://fr.wikibooks.org/w/index.php?title=Essai_pour_un_mod%C3%A8le_de_psychisme_objectif&amp;action=info#mw-pageinfo-header-basic [[Utilisateur:Clopeau|Clopeau]] ([[Discussion utilisateur:Clopeau|discussion]]) 17 mars 2026 à 08:20 (CET)
:Bonjour, quand je regarde ''[[Essai pour un modèle de psychisme objectif]]'', sa complétude permettrait en effet de le sortir des ébauches, mais il semble plutôt d'agir d'un travail de recherche que d'un livre pédagogique sur un sujet sourcé comme reconnu.
:Donc en vertu de [[Wikilivres:Principes fondateurs|notre charte]], je propose de le déplacer sur {{WV|Recherche:Accueil}}. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 18 mars 2026 à 09:06 (CET)

== Don à wikipédia depuis wikilivres ==

{{BlocCitation|La Wikimedia Foundation est l’organisation à but non lucratif qui soutient Wikipédia, '''les autres sites de connaissance libre de Wikimédia''', et sa mission de connaissance libre pour tous.|auteur=[https://wikimediafoundation.org/fr/give/donor-frequently-asked-questions/ FAQ], {{g|Qu'est-ce-que la Wikimedia Foundation ?}}}}
Le lien de donation https://donate.wikimedia.org/w/index.php?title=Special:LandingPage&amp;country=FR&amp;uselang=fr&amp;wmf_medium=sidebar&amp;wmf_source=donate&amp;wmf_campaign=fr.wikibooks.org '''ne parle que de wikipédia'''. '''Où sont passés les autres projets ?''' Vont-ils être fermés sauvagement par la fondation comme Wikinews récemment ? La suite au prochain épisode d{{'}}''Highlander-Wikimedia'' : {{g|À la fin, un seul ''projet'' survivra.}} ... &amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 12 mai 2026 à 11:26 (CEST)

:Bonjour,
:Je pense personnellement que les wikis ont des problèmes.
:Il y a une vingtaine d'années, il représentait l'innovation la plus ambitieuse.
:Aujourd'hui, les wikis me semblent dépassés de tous les côtés.
:           wiki = Erreurs 404 (&quot;Page introuvable&quot;)
:Problèmes:
:* 568 livres déclarés. 50 livres terminés (combien sont obsolètes)
:* 21 527 pages déclarées. 20 000 pages orphelines. (Papa t'est où?)
:Solution:
:* Où sont les cours sur YouTube qui utilisent un wikibook comme référence?
:Voilà mon idée sur les wiki.
:* https://fr.wikiversity.org/wiki/Facult%C3%A9:Droit
:* https://fr.wikiversity.org/wiki/D%C3%A9partement:Introduction_au_droit
:&lt;nowiki&gt;~~~~&lt;/nowiki&gt; [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 12 mai 2026 à 13:50 (CEST)
::Ce serait intéressant de mentionner tous les projets actifs oui. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:23 (CEST)
::: En même temps, le message est plutôt franc étant donné que l'argent des dons n'est pas investi dans le développement de Wikilivres (cf [[:meta:Community Wishlist Survey]] et les réponses à nos tickets Phabricator).
::: Par ailleurs, concernant la qualité des contenus, cela a toujours était un sujet depuis le début, et nous disposons tout de même de plusieurs pages spéciales dans [[Wikilivres:Maintenance]] pour y remédier afin que le lecteur n'ait pas la sensation de se faire empapaouter en se retrouvant sur des ébauches bien placées dans Google. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mai 2026 à 08:48 (CEST)

== La catégorie SI est pleine ! ==

Bonjour tous,

Pour info, la [[:Catégorie:Suppressions immédiates demandées]] contient 9 pages.

Wikilivresquement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 14 juin 2026 à 15:36 (CEST)

:Elle est maintenant vide, merci à ceux qui s'y sont collés ! {{Sourire}} [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 24 juin 2026 à 17:17 (CEST)

== Un RAW bien frais pour juillet ==

{| style=&quot;width:100%;&quot;
| valign=&quot;top&quot; align=&quot;center&quot; style=&quot;border:1px gray solid; padding:1em;&quot; |
{| align=&quot;center&quot;
|-
| style=&quot;text-align: center;&quot; | &lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:4.5em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em;text-align:center; color: #fff; font-style:italic;&quot;&gt;Regards sur l’actualité du mouvement Wikimédia.&lt;/div&gt;
&lt;div style=&quot;text-align: center;&quot;&gt;{{#ifeq:{{FULLPAGENAME}}|Wikipédia:RAW/Rédaction}}&lt;/div&gt;
&lt;/div&gt;&lt;br /&gt;
&lt;hr /&gt;
&lt;div style=&quot;font-size:12pt; font-family:Times New Roman; text-align:center;&quot;&gt;[[w:fr:Wikipédia:RAW/2026-07-05|&lt;span style=&quot;color:darkslategray;&quot;&gt;Le numéro de juillet 2026 est sorti.&lt;/span&gt;]]&lt;/div&gt;
&lt;hr /&gt;&lt;br /&gt;

|- style=&quot;text-align: center;&quot;
| &lt;span style=&quot;font-size:12pt; font-family:Times New Roman;&quot;&gt; '''❖ Au menu de ce numéro ❖'''&lt;/span&gt;
|- style=&quot;font-size:10pt; font-family:Times New Roman; text-align:center;&quot;
| &lt;div style=&quot;text-align:center; column-count:1; column-width:28em; vertical-align:top;&quot;&gt;

'''L'Édito'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Édito|Fêtons notre mouvement !]]

'''Échos francophones'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Résidence|Un nouveau vigneron dans la résidence]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Logo_WP25|Wikipédia en français aux couleurs des 25 ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#DAF|Wikipédia dans le ''Dictionnaire de l'Académie française'']]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Millésime_Wiktionnaire|Quelles sont les nouvelles entrées en français sur le Wiktionnaire ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ADS|Relance de l'Article de la semaine]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#sans_pagEs|Le projet des sans pagEs fête ses dix ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#contributions_rémunérées|Faut-il faire évoluer les règles sur les contributions rémunérées ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#wikification|Le mois de la wikification fait son retour pour une septième édition]]

'''Ailleurs dans le mouvement'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Txikipedia|Txikipedia franchit le cap des 10 000 articles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Concours_santé_2026|Un concours sur la santé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Commons_et_IA|Commons se penche sur l'IA]]

'''Nouveautés techniques et outils'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#VIZWP|VIZWP : un outil pour visualiser les lacunes dans les sujets climatiques sur Wikipédia, mais pas que…]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#AI_Source_Verification|Examiner la vérifiabilité grâce à l'IA ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Icônes|Les icônes de l'interface ont changé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Sous-références|Ça y est, les sous-références sont là]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ConvoCompass|ConvoCompass, pour moins d'attaques personnelles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LSV-Tools|LSV-Tools : faciliter la gestion des anecdotes « Le saviez-vous ? »]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LegendAndDot|Semi-automatiser l'ajout de ponctuation dans les légendes d'images]]

'''Du côté de la recherche'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#COMSAV|COMSAV : la contribution à Wikipédia fait-elle d'un ensemble d'individus un ensemble de pairs ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#JourneyMap|Où commence la contribution et où s'arrête-t-elle ?]]

'''Le POV'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Le_POV|Guide survie pour la Wikimania 2026]] par Trizek

'''L'Atelier'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Atelier|Le point sur la diversité de genre dans les articles]] par PAC2

'''L'Analyse'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Analyse|Larry Sanger is back... and fired!]] par Madelgarius, Trizek et Jules*

'''L'interview'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'interview|Pronoia : de Byzance aux réseaux sociaux, un œil sur Wikipédia et le monde]] par Antimuonium

'''Le wik’hit-parade'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Wikit|Articles les plus vus en juin 2026]] par Ælfgar

&lt;/div&gt;
|-
| style=&quot;font-family:Times New Roman; text-align:center; font-size:90%;&quot; | [[w:fr:Wikipédia:RAW/2026-07-05|Lire tout le numéro]]
|-
| valign=&quot;top&quot; colspan=&quot;2&quot; style=&quot;padding:0.5em; font-family:Times New Roman;text-align:center; font-size:100%;&quot; |
Venez rédiger le prochain numéro, y parler de ce qui se fait dans votre communauté : [[w:fr:Discussion_Wikipédia:RAW/Rédaction|Salle de rédaction]].&lt;/br&gt;Les anciens numéros sont retrouvables [[w:fr:Modèle:Palette RAW|ici]].
|-
|}
|}
&lt;div style=&quot;margin-top:10px; font-size:90%; padding-left:5px; font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif;&quot;&gt;[[w:fr:Wikipédia:RAW/Inscription|Abonnez-vous !]] [[Utilisateur:L&amp;#39;embellie|L&amp;#39;embellie]] ([[Discussion utilisateur:L&amp;#39;embellie|discussion]]) 5 juillet 2026 à 01:53 (CEST)&lt;/div&gt;

== Les RAW en mode fiesta sur la Wikimania ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro d'août 2026 (n°295) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-08-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;&lt;/div&gt;

'''Un numéro exceptionnel'''

La conférence Wikimania s'est achevée le 25 juillet. Que vous ressentiez de la frustration (si vous n’avez pas pu y assister) ou du [[:w:Wikipédia:Wikispleen|wikispleen]] (si vous y étiez et que vous avez du mal à digérer que ce soit déjà fini), l’équipe des RAW n’a pas ménagé ses efforts pour vous proposer un numéro XXL qui revient en long, en large et en travers sur cet événement qui le mérite bien. Comptes-rendus, témoignages, entretiens, il y en aura pour tous les goûts ! Le numéro est aussi exceptionnel par le nombre de rédactrices et de rédacteurs qui y ont participé {{incise|merci !|stop}} 

Au-delà de Wikimania, l’actualité wikimédienne est loin d’être paisible cet été. Nous vous proposons donc aussi de revenir en détail sur la crise qui secoue la fondation Wikimédia autour de la reconnaissance du syndicat Wiki Workers United (WWU). Nous aurons probablement l’occasion de couvrir la suite de cette histoire dans le prochain numéro. D’ici là, bonne lecture !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia et des nouveaux outils

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Dossier spécial Wikimania&lt;/span&gt;'''

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les POV&lt;/span&gt;'''&lt;br&gt;— Ma Wikimania : la joie, l'inquiétude et la raison d'être&lt;br&gt;— Témoignages : regards sur la Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;L'Analyse&lt;/span&gt;''' — La crise s'intensifie après le refus de la WMF de reconnaître le syndicat WWU

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Comptes-rendus&lt;/span&gt;'''&lt;br&gt;— Une Wikimania sous le signe de la jeunesse&lt;br&gt;— Sur les conséquences de la définition de « wikimédien·ne »&lt;br&gt;— Petit tour d’horizon de la créativité wikimédienne&lt;br&gt;— CultureStrong : respecter les savoirs des Premières Nations sur les plateformes Wikimédia&lt;br&gt;— Des événements techniques à Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Interviews&lt;/span&gt;'''&lt;br&gt;— Ses goûts, sa Wikimania, sa prochaine tournée... : Baby Globe nous dévoile tout !&lt;br&gt;— Jules*, notre Wikimédien de l'année : comment rendre compte du changement climatique tout en protégeant l'encyclopédie

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : si un sujet vous tient à cœur, n'hésitez pas à proposer une idée d'article ou à participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]]. Toutes les contributions sont les bienvenues, quel que soit votre wiki d'origine ! &lt;span class=&quot;smiley&quot;&gt;[[Image:Face-smile.svg|20px|Sourire|alt=Émoticône sourire]]&lt;/span&gt;

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 août 2026 à 00:28 (CEST)

== Bientôt les 20 ans de Wikiversité ==

Bonjour.

Un petit message de « débauchage » dans le cadre d'un projet d'amélioration de Wikiversité. Comme dit la chanson : « On n'a pas tous les jours vingt ans ! » Plus d'infos [[v:Wikiversité:La_salle_café/août_2026#Améliorer_Wikiversité_pour_ses_vingt_ans_d'existence|dans la salle café du projet]].

Belle fin de journée à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 août 2026 à 00:26 (CEST)

== [[:Catégorie:Suppressions immédiates demandées|Série de demandes de suppression immédiate]] ==

Bonjour,

La [[:Catégorie:Suppressions immédiates demandées]] est de nouveau pleine, mais cette fois, il semble qu'elle ait été remplie par le seul {{U|Xhungab}}.

Cordialement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 16 août 2026 à 14:56 (CEST)
:{{fait}} Bonjour, oui c'était effectivement un ensemble d'ébauches abandonnées. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 17 août 2026 à 10:38 (CEST)
::Merci pour votre aide [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 août 2026 à 14:26 (CEST)

== Deux idées à débattre ==

Bonjour.

Vu le travail de traitement des pages et livres abandonnés et suite à une discussion avec @[[Utilisateur:Xhungab|Xhungab]] reprise ci-dessous, j'aimerais soumettre deux idées à la communauté Wikilivres.

'''La première idée''' est de déplacer toutes les pages et livres dont le développement est abandonné depuis longtemps en sous-page de l'auteur principal tout en laissant un message sur sa page de discussion avec un lien pointant vers la sous-page en question. Ce message pouvant faire l'objet d'un modèle.

Avantage : 1. Pas besoin d'être admin pour faire ce genre de maintenance. 2. Pas de risque de frustrer un auteur ni de perdre de vue des informations intéressantes. 3. Ceci dans le but d'améliorer l'apparence de Wikilivres au niveau du contenu visible sur l'espace de nom principal.

Nécessité : 1. Créer un modèle à placer sur la page de discussion de l'auteur principal après déplacement. 2. Définir la durée d'abandon des pages à déplacer.

'''La deuxième idée''' est de donner les outils d'administrateurs à des personnes qui ne veulent pas endosser cette responsabilité à long terme et de manière continue, mais qui sont d'accord d'en faire usage dans le cadre d'un projet de maintenance temporaire. Cela pourrait être utile pour @[[Utilisateur:Fourmidable|Fourmidable]] s'il le souhaite, à moins qu'il se décide à déposer sa candidature pour une nomination définitive. Ce qui serait une bonne idée, je trouve.

Qu'en pensez-vous @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Grondin|Grondin]] ?

Une prise de décision est-elle nécessaire si on décidait une mise en application ?

Bien à vous tous,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 01:50 (CEST)

:Bonjour,
:J'ai proposé une liste de livres à supprimer
:https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate
:Doit-on réellement les garder ? ;) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 10:21 (CEST)
::Quel est l'avantage de la suppression par rapport au déplacement @[[Utilisateur:Xhungab|Xhungab]]? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:56 (CEST)
:::En déterminant un contenu minimum, on peut faire le tri de ce que l'on supprime et ce que l'on déplace. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:58 (CEST)
::::Bonjour,
::::Les droits administrateurs temporaires sont difficiles à gérer : un bureaucrate peut attribuer le status administrateur mais pas le retirer.
::::Concernant les critères suppression ou renommage, je propose :
::::* (cas 1) Une page qui ne contient vraiment aucun texte (ex : seulement des liens rouges) --&gt; suppression
::::* (cas 2) Une page avec quelques phrases significatives récupérables --&gt; soit (a) tenter de fusionner dans un livre qui aborde le même sujet ou sujet connexe, soit (b) renommer en sous-page de l'auteur si aucun livre pour la fusion ne convient
::::* (cas 3) Une page avec plus de contenu que (cas 2) --&gt; conserver
::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 24 août 2026 à 19:33 (CEST)
:::::Salut @[[Utilisateur:DavidL|DavidL]]. Oui, c'est raisonnable. Reste que la fusion, c'est compliqué. J'ai essayé, mais je ne comprends rien. Une vidéo m'aiderait à comprendre, mais j'en ai pas trouvé. Ensuite, si on garde, genre un livre abandonné depuis plus de trois ans avec un chapitre entamé sur cinq prévus, par exemple, on le laisse dans l'espace principal, ou on le déplace vers l'espace utilisateur de l'auteur ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 25 août 2026 à 00:38 (CEST)
::::::Pour ce cas je propose de le fusionner si possible, comme (cas 2)(a) ; sinon le conserver, comme (cas3) afin qu'un utilisateur motivé puisse reprendre le livre.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 25 août 2026 à 08:36 (CEST)
:::::::Ok. Es-tu à l'aise avec la fusion @[[Utilisateur:DavidL|DavidL]] ? Car c'est une solution intéressante, mais je n'y arrive pas. Il y a toujours un message que je ne comprends pas et suite à quoi je préfère arrêter. Serais-tu dispo pour m'expliquer comment faire durant un appel vidéo ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:30 (CEST)
::::::::Bonjour {{Mention|Lionel Scheepmans}}, je suis très favorable à tes deux idées ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 août 2026 à 15:39 (CEST)
:::::::::Ok @[[Utilisateur:Fourmidable|Fourmidable]], je me dis qu'il serait encore bien d'avoir les avis de @[[Utilisateur:JackPotte|JackPotte]], voir de @[[Utilisateur:Grondin|Grondin]], s'ils trouvent le temps nécessaire pour le faire. Et puis, on peut penser tout doucement à créer une page pour fixer des décisions en votant si nécessaire pour confirmer l'adhésion générale ou grandement majoritaire.
:::::::::C'est curieux, je voulais travailler sur Wikiversité et finalement je me trouve plus actif sur Wikilivres. Mais les enjeux sont les mêmes et beaucoup de personnes actives ici le sont aussi sur Wikiversité, y compris parmi les administrateurs. En avançant dans Wikilivres, j'ai donc aussi l'impression que l'on avance sur Wikiversité.
:::::::::Au fait, fourmidable ? Tu ne serais pas intéressé, toi, de prendre un balai dans Wikilivres ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:27 (CEST)

== Demande d'aide pour amélioré Wikbook. Merci ==

* Actuellement j'ai proposé mes services pour améliorer wikibook. J'ai créé un partenariat informel avec des administrateurs, je propose des pages et des livres à supprimer. Ils décident soit de suivre ma demande, soit de la neutraliser. Je les remercie pour leur patience et leur aide.

- https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate


*Certain livres semblent trop avancé pour suivre cette procédure.

- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026

Dans cette page, je propose des livres trop avancés pour être traités rapidement. Il faut un vote pour que les demandes soient acceptées.
Aujourd'hui j'ai besoin de vous pour faire avancer mes propositions, sur des livres peut-être intéressants mais abandonnés depuis plus de trois ans, cinq ans, dix ans, vingt ans.

Si vous appréciez mon dévouement pour Wikibook et que vous souhaitez m'aider, ''il suffit chaque semaine de rajouter la commande'' {{VoteSupprimer}} ''sur les livres que je propose''. '''Entré {{}} puis à l'intérieur des parentthèses VoteSupprimer''' et signer votre accord. Merci pour votre aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 25 août 2026 à 10:33 (CEST)

:Salut @[[Utilisateur:Xhungab|Xhungab]], merci à toi pour ton engagement ! J'ai supprimé les pages qui étaient pratiquement vides dans ta liste. J'ai laissé les autres car la proposition de fusion est invoquée par @[[Utilisateur:DavidL|DavidL]] pour les pages avec du contenu. Malheureusement , je ne comprends pas comment fonctionne l'outil de fusion. J'espère que quelqu'un voudra bien m'expliquer le fonctionnement via un appel vidéo. Car je ne comprends pas les explications écrites. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:53 (CEST)
::Bonjour, Merci pour ton aide.
::.
::* J'ai travaillé sur la liste des pages les plus anciennement modifiées de l'année 2006. J'ai proposé tous les livres en errance à la suppression par vote.
::- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026
::Je vais attendre qu'elle soit traitée. Soit en supprimant ces livres soit en supprimant ma demande. Ensuite je ferai l'année 2007.
::.
::*Tu m'a posé une question.
::Quel est l'avantage de la suppression par rapport au déplacement ?
::Je vais essayer de te répondre dans mon prochain message. (Ce sera juste un délire d'un mois d'août un peu chaud). [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 09:20 (CEST)
:::C'est motivant de voir des gens motivés =)
:::Prend ton temps, il n'y a aucune échéance dans les projets Wikimédia, c'est un processus en continu qui peut s'étendre à plusieurs générations... Et si c'est plus facile pour toi de passer à l'oral, sache que je suis partant pour une discussion audio ou vidéo. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:35 (CEST)

== J'ai fait un rêve. ==

J'ai fait un rêve.

Un lieu où des amateurs passionnés proposeraient de partager leurs travaux avec des étudiants curieux. Pas les meilleurs travaux du monde. Mais pas les pires non plus. Un endroit où les anciens passeraient  le relais à ceux qui présentent leurs avenirs.  

Ce serait une petite bibliothèque avec une cinquantaine de livres disponibles à l'étude. Cinq ou six livres en construction que les étudiants pourraient travailler avec l'auteur. Tous les ans quelques livres supplémentaires viendraient enrichir ce lieu d'étude.

Aujourd'hui, il existe Wikibook. Un lieu où des auteurs malveillants prouvent que le travail collaboratif ne fonctionne pas. Ils créent des livres parfaitement construits de quelques chapitres puis les abandonnent sans scrupule. Ces livres moisissent depuis cinq, dix, quinze, vingt ans.

Wikibook c'est:
* La bibliothèque de livres pédagogiques libres que chacun peut améliorer.
* 569 livres contenant 22 112 pages.
.
* 569 livres dont 450 livres à l'abandon depuis cinq, dix, quinze, vingt ans.


Oui, aujourd'hui Wikibook peut changer. Wikibook va changer. Wikibook pour les étudiants va renaître de ses cendres. Les cendres des vieux livres abandonnés. Les auteurs devront faire honnêtement leur travail, ou les étudiants feront le leur.

Ceci n'est juste qu'un rêve dans un mois d'août un peu plus chaud que d'habitude.

Merci pour m'avoir suivi jusqu'ici. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 10:13 (CEST)

:Je trouve que c'est un très beau rêve @[[Utilisateur:Xhungab|Xhungab]]. Dans ce rêve, on peut voir la partie remplie du verre au lieu de la partie vide. Sur Wikilivres, il y a plus de 100 ouvrages terminés entièrement libres d'usage et toujours améliorables collectivement. Deux fois plus que la cinquantaine de livres dont tu parles dans ton rêve.
:C'est normal d'abandonner un projet d'écriture. La vie est tellement imprévisible. Les ressources en temps et énergie tant limitées. Combien de personnes ont commencé un livre sur papier ou sur leur ordi sans jamais le terminer ?
:C'est pareil sur Wikilivres, sauf que c'est visible aux yeux de tous.
:Quand on commence un truc, c'est jamais dans l'intention de l'arrêter. Si on arrête, c'est qu'il y a des raisons à cela. Je n'ai donc pas envie de voir dans ces abandons des actes de malveillance, ni de critiquer leurs auteurs. J'ai d'ailleurs moi-même des projets que je n'arrive pas à concrétiser (exemple).
:Je pense au contraire que ce n'est pas un problème à partir du moment où nous avons la liberté et les outils (communication, suppression, fusion) qui nous permettent de faire le tri entre ce qui est terminé, voire même ce qui est de qualité, et le reste.
:Ce rêve est donc possible et mes démarches pour devenir wikimédien en résidence à l'université sont une démarche qui va dans ce sens. J'ai d'ailleurs apporté les preuves que l'intégration des projets Wikimédia dans le processus d'apprentissage universitaire est non seulement possible, mais hyper efficace. Malheureusement, j'ai toujours l'impression que cela n'intéresse personne. Ni à l'Unif, ni dans Wikimédia. Mais je ne désespère pas. Les changements de paradigmes sont lents en raison des habitudes. C'est une fatalité chez l'humain. Il faut faire avec.
:Mais donc. Concentrons-nous sur la manière d'organiser notre bibliothèque pour que les visiteurs puissent confortablement voir ce qui s'y trouve en séparant, livres terminés, livres de qualité (cela se fait bien avec les articles de Wikipédia), livres en cours d'édition et livres abandonnés, etc. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:32 (CEST)
::Je pense que nos points de vue sont irréconciliables en toute amitié. Pour moi, Wikibook est une  bibliothèque de livres pédagogiques libres que chacun peut améliorer. Soit on peut mettre un étudiant sur un livre. Soit ce livre est inutile (Je parle de livre de plus de trois ans). 
::.
::Wikibook n'est pas un entrepôt pour les auteurs.  C'est une bibliothèque.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 14:57 (CEST)
:::@[[Utilisateur:Xhungab|Xhungab]], c'est bien que l'on ne soit pas d'accord, car cela permet d'avancer vers une solution que tout le monde pourra approuver. C'est le principe du consensus et cela prend du temps en discussion. C'est normal et sain. En de plus, ce qui est dit ici est tout à fait pertinent pour Wikiversité qui est confronté à des problèmes similaires que Wikilivres.
:::J'exprime mes idées ci-dessous mes idées autrement pour voir si cela peut se rapprocher de ta propre vision des choses.
:::J'imagine la bibliothèque Wikilivres avec trois pièces :
:::# Une pièce principale à l'entrée qui reprend tous les livres terminés et prêts à l'emploi par une personne désireuse de les utiliser dans le cadre d'un apprentissage. Comme dans toutes les bonnes bibliothèques, ces ouvrages sont rangés par thèmes et certains d'entre eux sont mis en évidence en raison de leurs qualités, de leur pertinence par rapport à l'actualité, etc.
:::# Une pièce archives à l'arrière du bâtiment (un espace de nom que l'on pourrait choisir parmi ceux existants ou créer si nécessaire) dans laquelle on entrepose toute une série de livres abandonnés mais dont le contenu est archivé dans le but d'une éventuelle réutilisation. Cette réutilisation, comme le suggère @[[Utilisateur:DavidL|DavidL]], peut s'effectuer dans le cadre d'une fusion du contenu abandonné avec un autre contenu abandonné, ou mieux encore, si cela se présente, avec un livre terminé dans lequel les informations utiles du document abandonné sont manquantes. À noter que cela représente beaucoup de travail, tant pour la relecture que pour la mise en œuvre des fusions, qui, à mes yeux de personne expérimentée dans l'usage de MediaWiki, est un processus compliqué. De plus, il ne peut être fait que par des personnes ayant les outils d'administrateur. C'est-à-dire quatre personnes, dont deux ou trois actives dans ces récentes discussions.
:::# Dans la librairie Wikilivres, il y a ensuite un étage dans lequel chaque personne inscrite peut bénéficier d'un espace personnel, pour se présenter, stocker des informations, mais également travailler sur des projets personnels d'écriture. En tenant compte de ceci, on peut alors aussi imaginer de déplacer les ouvrages inachevés de la pièce principale à l'entrée de la librairie, vers ces différents locaux selon leurs auteurs respectifs.
:::Face à ces trois espaces, la question qu'il reste à se poser est de savoir si et dans quelles condition, on peut déplacer les ouvrages inachevés vers une salle d'archive, ou dans les locaux personnels des auteurs ? Cela en signalant que ce déplacement peut être fait très facilement et par toutes les personnes qui le souhaitent, même sans inscription à la bibliothèque. Ce qui est un grand avantage par rapport à la fusion.
:::Pendant ce temps, à l'accueil de la bibliothèque Wikibook, on invite les visiteurs à parcourir la pièce avec les ouvrages terminés, mais également la pièce archive, où ils peuvent trouver des ouvrages inachevés, au cas où ils veulent poursuivre leurs développements, ou trouver des ressources intéressantes pour leurs travaux personnels. On les informe ensuite aussi qu'avec leur inscription, ils bénéficient d'un local pour leurs activités personnelles et notamment pour y placer les ébauches d'ouvrages qu'ils désirent rédiger.
:::Que penses-tu de mon propre rêve ? Est-il si différent du tien ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:17 (CEST)
::::Et les autres ? @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Fourmidable|Fourmidable]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:Grondin|Grondin]]. Que pensez-vous de nos rêves ? Et, si le mien vous parle, quelles seraient vos propositions pour orienter les déplacements de pages à l'abandon entre un espace d'archivage (qui pourrait être créé) et des espaces utilisateurs ? Le nombre d'octets ? La finalisation d'une section ou d'un chapitre ? Quelles autres possibilités ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:37 (CEST)
::::: Bonjour, a priori ça doit se régler au cas par cas sur [[Wikilivres:Demandes de suppression]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]])

::::Bonjour,
::::La structure de Wikibook est parfaite grâce à sa vitrine.  Pour moi, il y a juste un problème sur les listes sur la droite : Arts, Loisir, Histoire, Langues, Technologie, Informatique, Sciences, Sciences humaines. Ces listes ne devraient donner accès qu'aux livres terminés.
::::Ces listes actuelles pourraient être caché dans un espace création qui pourrait être posé avec le lien Nouveauté en bas de la page.
::::Pour la gestion des livres, il suffirait qu'une ou deux personnes parcourent la bibliothèque et proposent quelques suppressions chaque semaine, pour en quelques mois éclaircir la situation. Je pense que l'on peut faire confiance aux administrateurs pour gérer la situation des livres, ceux qui sont à garder et les autres. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 18:30 (CEST)
:::::@[[Utilisateur:JackPotte|JackPotte]]. Le cas par cas est ce que nous faisons depuis toujours. Cela nous amène à la situation actuelle qui semble ne pas convenir à tous. En tout cas, c'est mon cas. Ici comme sur Wikiversité. Quand, en navigant sur le site, une personne tombe neuf fois sur dix sur des pages presque vides et inachevées, comme c'est le cas sur Wikilivre, elle se dit : c'est quoi ce site ? Elle passe alors à autre chose de plus vivant, genre https://zestedesavoir.com/ ou autre. Sans changements éditoriaux, je pense que la situation évoluera.
:::::@[[Utilisateur:Xhungab|Xhungab]], on peut faire comme tu dis. Cependant, la charge de travail repose sur une double action, la proposition d'abord et le traitement ensuite. Un traitement qui finalement repose sur les épaules des administrateurs. Nous ne sommes que des bénévoles peu nombreux et pas toujours disponibles.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 19:13 (CEST)
:Créer un livre, le ranger, en établir un plan, le catégoriser n'est pas un travail négligeable... Un travail que d'autres personnes intéressées pour écrire sur le sujet n'ont pas à refaire 🤷‍♂️ ...

== Petite proposition indécente à Lionel ==

Bonjour  Lionel,

Je souhaiterais te proposer un petit projet.

a) Dans la page principale de wikibook tu créés une page &quot;Espace pour les auteurs&quot;. Tu insères cette page devant le lien &quot;Nouveautés&quot;.
.

b) Tu copies dans cette page la liste des liens qui se trouvent en haut à droite dans la nouvelle page. (Arts, Loisirs, ...) Tu ne les modifies pas dans la page principale.
.

c) Dans la nouvelle page tu peux écrire un texte du genre.
Dans cette page, vous trouverez la liste de tous les livres disponibles sur Wikibook. Vous trouverez en particulier des livres en construction et vous pourrez entrer en contact avec les auteurs. Vous trouverez aussi des livres en construction sans auteur actif que vous pourrez compléter.


Cela est la première étape, si l'aventure t'intéresse. En fait tu ajoutes juste une page, que tu pourras supprimer si les besoins se font sentir. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 12:25 (CEST)

:La proposition est très décente @[[Utilisateur:Xhungab|Xhungab]] 
:Mais avant toute choses le plus prudent est de lancer une prise dé décision pour s'assurer d'un concesnsus en faveurs des changements dont nous débatons actuellement.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 août 2026 à 15:40 (CEST)
::Toutes ces actions seront réversibles. On ajoute une page. Un problème, on la supprime. 
::On fait rapidement les changements, on attend trois jours. En cas de problème, on supprime tout. Il suffira de s'excuser et de dire que l'on ne savait pas que l'on n'avait pas le droit. 
:: Un espace pour les lecteurs et un espace pour les auteurs séparés.
::[https://fr.wikibooks.org/wiki/Utilisateur:Xhungab Nouvelle page wikibook][[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 16:49 (CEST)
:@[[Utilisateur:Xhungab|Xhungab]] , ma grand mère disait : faire et défaire, c'est toujours travailler. Pour les grand changements, on a coutume de faire un prise de décision composée des propositions, suivies de débats et d'un vote.
:En plus, certaines décisions nécessite un changement technique et ce n'est pas toujours facilement réversible. Comme créer un nouvel espace de nom pour y transfèrer une catégorie de pages  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 28 août 2026 à 03:07 (CEST)
::Merci pour ton aide. Tu comprends maintenant pourquoi toi tu es un administrateur et moi pas.
::.
::'''Oui, aujourd'hui Wikibook peut changer. Wikibook va changer.''' 
::.
::*  '''Le changement c'est Maintenant :''' [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']
::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 28 août 2026 à 08:33 (CEST)
:::Ton enthousiasme fait plaisir @[[Utilisateur:Xhungab|Xhungab]], et je serais en faveur d'un style plus épuré de notre page d'accueil en plus d'une méthodes de classement et de séparation des ouvrages terminé, en cours et abandonnés. Je pense qu'à terme, nous pourrions faire une proposition de changement à soumettre au reste de la communauté. Par chance, nous ne sommes pas nombreux, cela simplifire les discussions et le processus de décision. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 19:26 (CEST)
::::Cette page  [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook'''] propose la vitrine, les livres disponibles, les mini-livres disponibles pour les lecteurs. Les lecteurs ne seront en contact qu'avec les livres terminés.
::::.
::::En bas à côté des nouveautés, il y a l' '''[https://fr.wikibooks.org/wiki/Discussion_utilisateur:Xhungab Espace pour les auteurs]''', avec tous les livres du site rangés par thème ou par niveau d'avancement si on clique sur l'image. Sinon, il y a une liste de catégories art,...
::::.
::::Cette proposition sépare donc deux espaces. Un pour les lecteurs et un pour les auteurs. Il suffirait maintenant plus qu'à nettoyer l'espace auteurs. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 20:22 (CEST)
L'usage des catégories me semble aussi une manière très pratique de trier le contenu de Wikilivre. Malheureusement, ces pages ne sont pas très sexy du coup l'usage de type de code pourrait être utile :

{ {Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={ { #categorytree:Livres terminés|mode=pages} } } }

Avec le rendu ci-dessous :
{{Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={{ #categorytree:Livres terminés|mode=pages}}}}

On pourrait ainsi imaginer d'intégrer directement ce code dans la page d'accueil pour afficher une boite déroulante au lieu d'envoyer le visiteur en dehors de la page d'accueil. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:08 (CEST)

:Tu devrais créer la page Lioneltest01 dans ta page utilisateur. Copier le code de la page principale de wikibook.
:Puis faire les changements que tu juges nécessaires. Tu peux éventuellement faire plusieurs pages. Ensuite, tu mets cette page dans le bistro pour que l'on puisse voir le résultat. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 21:22 (CEST)
::Je devrais, tu devrais, il devrait, nous devrions ... =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:28 (CEST)
:::Chaque chose en son temps.
:::1. Débattre ici des idées de changements.
:::2. Mettre les choses en place pour leur réalisation, comme la mise à jour du modèle:boite déroulante en s'inspirant de celui de Wikipédia ou d'autres sites.
:::3. Quand il n'y a plus de nouvelle idée ici, créer une page genre :[[Wikilivres:Prise de décision/Nouvelle page d'accueil et gestion des abandons]] avec une description précise des projets de changements, et une éventuelle [[Accueil/projet|page de présentation du projet d'un nouvelle page d'accueil]]
:::4. Poursuivre les discussions et propositions si nécessaire.
:::5. Quand on a fait le tour, passer au vote.
:::6. Mettre les décisions en application. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:03 (CEST)
::::Je propose actuellement un projet qui se trouve sur ma page utilisateur. Pourrais-tu lancer une prise de décision sur ce projet. Je ne sais pas comment on fait une telle demande. Je suis prêt à présenter mon projet et à recevoir les critiques. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 22:16 (CEST)
:::::''Aide-toi le ciel t'aidera''. La bureaucratie, c'est pas mon truc. Et puis ça m'irrite un peu que tu enchaines des demandes de faire des choses qui ne demande pas les outils d'administrateurs. Raisons pour lequelles, je pense finalement que l'on gagnerait à appliquer la [[w:Do-ocratie|Do-ocratie]] qui a fait ses preuves dans le monde du libre dont les projets Wikimédia sont issus.
:::::Si tu as une idée et qu'elle ne demande pas des droits de modification que tu n'as pas, fait la et on se retrouve en page de discussion de la page de tes changements en cas de problèmes et pour d'éventuelle commentaire. Sans réaction, pense à ''qui ne dit mot conscent''.
:::::Si tes idées demandes les outils d'administrateurs, tu peux alors demander à un admin de le faire. Libre à lui de le faire ou pas et si ça lui plait, si il a envie, si il prend le temps. Nous sommes bénévoles... Il y a bien des gens payés par la fondation, mais comment dire... Disons qu'ils ne sont pas des plus serviables. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:57 (CEST)
::::::Excuse moi je pensais qu'il faillait être administrateur pour faire une demande de prise de décision. Je vais donc essayer tous seul. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 23:06 (CEST)
:::::::Ok @[[Utilisateur:Xhungab|Xhungab]], pas de soucis. On ne peut pas tout savoir =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 30 août 2026 à 01:45 (CEST)

== Wikilivres:Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''


Merci pour votre participation

[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 30 août 2026 à 00:43 (CEST)

:Bonjour @[[Utilisateur:Xhungab|Xhungab]]. Content de te revoir dans les murs de Wikiversité après nos échanges sur Wikilivres. Je comprends ton sentiment de solitude, je le ressens aussi souvent. Il faut l'accepter et ne pas se décourager pour autant. Nous avons la chance de fonctionner dans une organisation bénévole, dans laquelle personne n'est tenu de répondre à des demandes. De ce fait, les choses évoluent lentement et en fonction des disponibilités. Dis-toi aussi que la période estivale est toujours un moment d'acalmie dans la participation. Moi par exemple, quand il fait bon, je préfère passer du temps sur des occupations extérieures que devant un écran.
:Cela dit, tu dois garder 3 règles implicites qui sont fréquemment appliquées dans les projets Wikimédia.
:1. ''Qui ne dit mot consent''. Si les personnes ne réagissent pas, cela ne veut pas dire qu'elles ne lisent pas. Par économie de temps et pour les personnes trop occupées ou pas assez motivées pour s'investir, ne pas réagir est un signe de consentement implicite.
:2. ''Les absents ont toujours tort.'' Lorsque l'on fait les choses dans les règles de l'art, par exemple comme tu le fais en lançant une prise de décision pour opérer un changement significatif dans Wikilivres, aucune personne absente durant un processus de décision clôturé viendra remettre en cause les choses par la suite.
:3. La doocratie. Les wikis sont des espaces de libertés au niveau de l'amélioration des contenus, mais également de l'organisation et des formes de contenus. En dehors du vandalisme qui est bien contrôlé par des personnes telles que @[[Utilisateur:Crochet.david|Crochet.david]], toute initiative est souvent perçue comme bienvenue. @[[Utilisateur:Fourmidable|Fourmidable]], par exemple, depuis qu'il est administrateur, a fait de nombreuses améliorations dans Wikiversité sans demander l'avis de la communauté. Personne ne lui a reproché son investissement. Si quelque chose qu'il a entrepris ne plaît pas à quelqu'un, une discussion commence entre lui et cette personne pour chercher une entente.
:Voilà tout.
:Je te rejoins aussi sur le fait que ce qui est décidé et mis en place sur Wikilivres peut tout à fait servir d'exemple pour Wikiversité et vice versa. Je ne suis pas le seul à être administrateur dans les deux projets et cela aide beaucoup à la création d'une synergie entre les deux projets qui sont finalement très complémentaires. Cela n'est pas étonnant d'ailleurs lorsque l'on sait que Wikiversité est né de Wikilivres.
:Une belle fin de journée à toi et à tous ceux qui liront ce message. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:30 (CEST)
::Merci. Pour tes explications. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 6 septembre 2026 à 13:50 (CEST)
:::Avec plaisir. Pense aussi qu'il n'y a pas de combat dans les projets Wiki, mais un lent processus évolutif, sans fin programmée, et qui est pour moi l'un des meilleurs que je connaisse. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:57 (CEST)

== Les RAW sont arrivés, la rentrée peut commencer ! ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro de&amp;nbsp;septembre 2026 ({{numéro|296}}) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-09-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;
&lt;/div&gt;

'''C'est la rentrée'''

Après un numéro très dense en août en raison de la Wikimania, celui-ci est un peu plus léger car l'équipe s'est octroyée quelques vacances. Cela n'empêche pas le mouvement de continuer à vivre, avec une rentrée déjà animée ! Du côté des projets francophones, le Wiktionnaire vient de franchir le cap symbolique des sept millions d’entrées, tandis que Wikipédia continue de voir fleurir sondages et discussions sur son fonctionnement.

Une rentrée, donc, placée sous le signe de la construction collective : de nouveaux outils pour contribuer, de nouveaux espaces pour échanger, de nouvelles formes d’organisation… Ce numéro des RAW vous propose de faire le tour de cette actualité, avant de reprendre tranquillement le chemin des projets Wikimédia.

L'équipe de la rédaction a également commencé à réfléchir à un nouveau nom pour remplacer l'énigmatique « RAW ». N'hésitez pas à venir donner votre avis dans la [[:w:Discussion Wikipédia:RAW/Rédaction#Changement de nom|section dédiée]] !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia, des nouveaux outils et des articles de recherche

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : n'hésitez pas à suggérer des sujets ou participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]] !

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 septembre 2026 à 00:17 (CEST)

== Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés ==

J'ai posé une demande de prise de décision concernant le sujet suivant.


[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Modifier_le_contenue_de_l%27espace_Nouveaut%C3%A9s Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés]

Merci pour votre participation [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 9 septembre 2026 à 14:38 (CEST)

== '''Décision''':Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''

'''Décision pour : [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']'''

Résultats : 3 + Pour, un Neutre Neutre et un - Contre soit 60 % de + Pour par rapport au total des votes exprimés : la proposition est adoptée. Quelques propositions de reformulations et de nuances ont été faites qui pourront être prise en compte. Cdlt, VIGNERON * discut. 13 septembre 2026 à 18:27 (CEST)

Merci pour votre participation. Ma première proposition était un peu malhabile, mais grâce à vos interventions je pense que l'on a créé quelque chose de correct. '''Merci à tous''' [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 13 septembre 2026 à 20:22 (CEST)

== Je ne suis pas content tous seul. ==
'''Suite à l'installation de la nouvelle page de la Vitrine, je ne suis pas content, j'ai pris 24h pour réfléchir.
'''

J'avais posé une demande de prise de décision concernant le sujet suivant.


'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace auteurs sur la page d'accueil]'''


'''Créer un espace lecteurs''' : Où est l'espace pour les lecteurs?


 Découvrir la bibliothèque
 Livres terminés - Mini Livres - Tous les livres


'''Dans une bibliothèque''', un livre est disponible ou indisponible. C'est chez l'auteur ou chez l'imprimeur qu'un livre est terminé.


'''Je suis un nouveau sur Wikilivre'''. Je vois, &quot;Découvrir la bibliothèque&quot;, je vais directement dans &quot;'''[[Wikilivres:Tous les livres|Tous les livres]]'''&quot;. Je me retrouve dans un labyrinthe qui me balade de répertoires en répertoires pour finir sur une ébauche abandonnée depuis 5, 10, 20 ans.


Je ne suis pas content. J'avais proposé à l'administrateur un changement en 2 minutes. Copier cette page dans la Vitrine, [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab La Nouvelle Vitrine]. Il a décidé de passer plusieurs heures à modifier la prise de décision. Je ne suis pas content. Je suppose que je suis le seul. 


Donc : '''Je ne suis pas content tous seul.''' Mais je me soigne. Un pan bagnat et une tourte aux blettes.

Merci de m'avoir lu [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 septembre 2026 à 10:51 (CEST)

:Bonjour @[[Utilisateur:Xhungab|Xhungab]].
:Nous tentons de fonctionner au consensus dans les projets Wikimédia. On essaie donc de faire les choses avec un consentement général. La prise de décision a été rapide, les discussions inachevées, et certaines personnes n'étaient pas satisfaite de tes propositions. Comme la cloture de la décision a été faite, je me suis mis au travail.
:Il est ensuite important de signaler que dans [[Discussion utilisateur:Lionel Scheepmans#Décision:Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil|une précédente discussion]], je suis resté ouvert à tout changement de la page d'accueil à partir de ce que j'ai considéré être le plus rationnel au regard de tout ce qui existait déjà. C'est-à-dire [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Index?prefix=&amp;namespace=4 de nombreuses pages] créées et améliorées par le passé que nous ne pouvons pas ignorer au risque de créer des doublons.
:Si tu es insatisfait du résultat, je te propose de nous retrouver, comme cela a déjà été proposé aussi dans notre précédente discussion, sur la [[Discussion:Accueil|page de discussion de la page d'accueil]] qui est le meilleurs endroit pour discuter de son contenu tout en étant sûr que ces discussion ne se perdent pas dans un archivage, comme c'est le cas pour le bistro. On peut donc s'y retrouver, avec toutes les autres personnes qui ont des propositions d'améliorations.
:Du reste, nous sommes tous bénévoles ici. Y compris les administrateurs. Pour ma part, être bénévole, c'est faire les choses par sa propre volonté et avec bienveillance. C'est être volontaire bienveillant. Pour ma part, je reste toujours bienveillant. Ma volonté, quant à elle, peut changer en fonction de mes convictions et motivations.
:Une belle fin de journée à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 17 septembre 2026 à 13:20 (CEST)</text>
      <sha1>lahsqdi3o3tfy4pw2hyy6ojy0xcsnwj</sha1>
    </revision>
    <revision>
      <id>772354</id>
      <parentid>772353</parentid>
      <timestamp>2026-09-17T11:31:30Z</timestamp>
      <contributor>
        <username>Lionel Scheepmans</username>
        <id>20012</id>
      </contributor>
      <comment>/* Je ne suis pas content tous seul. */</comment>
      <origin>772354</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="71249" sha1="qzwwm8zp82xag9avp7cn73vmjg06eu4" xml:space="preserve">&lt;noinclude&gt;{{Wikilivres:Le Bistro/En-tête}}&lt;/noinclude&gt;

== Le meilleur à Wikilivres pour 2026 ! ==

Je crée la page du bistrot 2026 en transmettant mes vœux. Bonne année éditoriale à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 janvier 2026 à 06:05 (CET)
:Merci, meilleurs vœux ! [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 16 janvier 2026 à 09:53 (CET)
::Meilleurs vœux pour 2026 !
::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 janvier 2026 à 20:13 (CET)
:::Meilleurs vœux pour 2026
:::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 janvier 2026 à 11:56 (CET)
::::Bonne année et bonnes lectures et écritures !
::::[[Utilisateur:Matthius|Matthius]]


== Page orpheline du livre : États généraux du multilinguisme dans les outre-mer ==

Bonjour,

Le livre &quot;États généraux du multilinguisme dans les outre-mer&quot; a laissé quelques pages orphelines. Ces pages orphelines ont été recopiées ou regroupé dans le texte du livre. Elles font donc doublons.

Je montre dans ce livre [[Wikilivres:Feuilles dupliquées orphelines]] cette suite de pages orphelines accompagnée par la page où elles ont été recopiées.

Merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 10 février 2026 à 19:57 (CET)

:@[[Utilisateur:Xhungab|Xhungab]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], bonjour. Je vois que l'on est en campagne de gestion de pages orphelines et je me pose la question de savoir si on doit les supprimer une fois réintégrées ailleurs ou les supprimer ? Je vois que les deux cas de figure ont été mis en œuvre précédemment. L'avantage de la fusion est de conserver l'historique des modifications, mais je ne suis pas habitué à le faire. Si quelqu'un d'entre vous pouvait m'indiquer une page d'explication, cela m'aiderait à m'y mettre. Ensuite, je me demande si la fusion a vraiment un sens lorsque c'est la même personne qui a créé la page orpheline et la nouvelle au contenu copié collé pour insertion ? Qu'en pensez-vous ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:02 (CET)
:::Ça fait plaisir de voir une personne s'investir dans la maintenance de Wikilivres =). Soit le ou la bienvenu.e. J'attends les avis des autres administrateurs pour te donner mon soutien @[[Utilisateur:Xhungab|Xhungab]]. @ bientôt. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:27 (CET)
:::: @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]] bonjour, je n'ai pas compris en quoi &quot;deux cas de figure ont été mis en œuvre précédemment&quot; : si la page est vide on la supprime et si elle a au moins une phrase valable on la fusionne. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:26 (CET)
::::Concernant l'auteur pour moi cela importe peu, car on souhaite conserver chaque élément permettant de prouver une primauté du droit d'auteur (par exemple pour ne pas accuser un contributeur d'avoir copié un site miroir de sa page supprimée). [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 février 2026 à 16:30 (CET)
:::::Désolé [[Utilisateur:JackPotte|JackPotte]], je n'avais pas vu que les pages que tu as supprimées étaient vides. La règle est donc supprimer si vide et fusionner si non. Tu peux me conseiller une page d'aide pour oppérer les fusions ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 13 février 2026 à 16:34 (CET)
::::::Salut,
::::::Pour la fusion d'historique :
::::::* soit [[Wikilivres:Le guide de l'administrateur#Fusionner deux pages|Utiliser la page spéciale pour cela]] (cependant ne fonctionne pas toujours),
::::::* soit [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages utiliser l'ancienne méthode] qui reste toujours valable quand la première ne fonctionne pas.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 13 février 2026 à 19:34 (CET)
:::::::Salut @[[Utilisateur:DavidL|DavidL]]. Je viens de tester l'outil fusionner avec les deux pages suivantes
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes/Contexte]]
:::::::vers
:::::::[[États généraux du multilinguisme dans les outre-mer/Annexes]]
:::::::Et j'ai le message suivant :
:::::::« La période spécifiée chevauche les versions préexistantes de la page de destination. »
:::::::Tu peux m'expliquer si tu as le temps ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 00:19 (CET)
::::::::Salut @[[Utilisateur:Lionel Scheepmans|Lionel Scheepmans]]
::::::::Dans ce cas, j'utilise [https://fr.wikibooks.org/w/index.php?title=Wikilivres:Le_guide_de_l%27administrateur&amp;oldid=588957#Fusionner_deux_pages l'ancienne méthode].
::::::::# Renommer A (page qui n'existera plus) vers B, sans laisser de redirection, et en cochant la case de suppression de B (case qui apparait après 1er clic sur le bouton Renommer) (&amp;rarr; l'historique de A est sur B, celui de B est supprimé)
::::::::# Supprimer B (&amp;rarr; l'historique de A et B sont supprimés)
::::::::# Restaurer B et cocher toutes les cases des versions (bouton &quot;Inverser la sélection&quot;) (&amp;rarr; restaurer l'historique de A et B)
::::::::# Effectuer une modification de la version finale de la page à afficher, trouvée dans l'historique.
::::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 16 février 2026 à 08:29 (CET)
:::::::::Merci @[[Utilisateur:DavidL|DavidL]]. Ça m'a l'air bien compliqué tout ça. Et avec toute les pages qu'il faut faire, ça risque de prendre un certain temps. Je manque de courage en pensant que c'est juste pour ajouter une ligne dans l'historique des versions. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 février 2026 à 14:51 (CET)
::::::::::Finalement, dans l'exemple que j'ai pris, la fusion n'avait aucun sens puisque le contenu du doublon que j'ai finalement supprimé était intégralement repris dans l'autre doublon par le même auteur. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 22 août 2026 à 23:55 (CEST)
:::::::::::Désolé @[[Utilisateur:Xhungab|Xhungab]]. Je ne comprends rien à l'outil de fusion et je ne trouve rien qui me permet de comprendre sur le net. Une vidéo avec exemple des différents cas de figure serait bien, mais je ne trouve pas. Je vais donc laisser ce travail à ceux qui savent utiliser l'outil.
:::::::::::En revanche, j'ai remarqué que certains doublons, comme dit précédemment, ne nécessitent pas de fusion puisqu'il s'agit de pages qui ont été créées sans aucune autre modification, puis, copiées par le même auteur dans une autre page créée avec un autre nom, au lieu de faire un renommage. Il faudrait donc que je prenne le temps de parcourir la liste pour repérer ces cas de figure avant de supprimer le premier doublon. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 01:27 (CEST)
::::::::::::Merci pour ton aide. Actuellement ces pages ont été en quelque sorte neutralisées. Donc fais de ton mieux, mais ne te tracasse pas elles ne posent plus de problème. Encore merci [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 09:13 (CEST)
:::::::::::::OK @[[Utilisateur:Xhungab|Xhungab]], merci pour l'info. Au fait comment as-tu fais pour les détecter ? En parcourant les pages de la catégorie orphelines et en vérifiant celles qui sont doublons ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 12:36 (CEST)
::::::::::::::Dans la catégorie pages orphelines, il y avait un lien sur une page.
::::::::::::::Je choisissais une phrase et je recherchais avec la fonction recherche de wikibook où se trouvait cette phrase. Si c'était un doublon, j'avais un lien vers la nouvelle page. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 12:48 (CEST)
:::::::::::::::Intelligent. Tu poserais pas ta candidature d'admin !? Ici, avec @[[Utilisateur:Fourmidable|Fourmidable]] et puis sur wikiversité aussi. Ça pourrait aider pour le projet des 20 ans., si tu comote toujours t'investir. On est en sous effectif dans les deux projects et les communautés me semblent plus ouverte que sur Wikipédia. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 13:48 (CEST)
::::::::::::::::Je ne souhaite pas devenir un administrateur. Pourquoi ? Si on me donne du pouvoir, je l'utiliserais. Par la suite, ceux qui m'ont accordé le pouvoir auront le choix entre pleurer, nous quitter ou me mettre en arrêt de travail. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 14:59 (CEST)
:::::::::::::::::Ah ah ah. T'es si foireux que ça !? Ou peut-être as-tu eu des expériences antérieures ? Dans tous les cas, c'est super de ta part de pouvoir t'auto évaluer.
:::::::::::::::::Ceci dit, le système de demander au administrateurs de faire des tâches qu'il faut expliquer est une perte de temps et d'efficacité. On pourrait d'ailleurs penser à attribuer les droits temporairement pour effectuer certaines tâches. Je me demande si ça se fait déja quelque part ? Si oui, on pourrait s'en inspirer pour mettre le système en application sur Wikilibres et Wikobersité. T'en penses quoi @[[Utilisateur:Xhungab|Xhungab]] ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 23 août 2026 à 15:40 (CEST)
::::::::::::::::::Oui, je pourrais obtenir des droits temporaires par rapport à un projet. Par exemple 2 projets
::::::::::::::::::Premier projet :  Supprimer toutes les feuilles volantes. Ce sont des feuilles tests très bien faites mais qui n'appartiennent à aucun livre. Je crois qu'il y a actuellement, Feuilles volantes – 54 P. 
:::::::::::::::::: 
:::::::::::::::::: Deuxième projet : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Pages_anciennes Les pages les plus anciennement modifiées]
::::::::::::::::::Supprimer tous les livres entre 2006 et 2010 qui sont à l'abandon. Parfois il sera possible de sauvegarder un livre en supprimant les chapitres vides, ce qui nous permettra de créer un livre complet. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 23 août 2026 à 16:19 (CEST)
Donc, tu as du temps à consacrer à ce genre de maintenance ? Ce serait bête de ne pas en profiter. Reste à voir à présent si les autres administrateurs et bureaucrates seraient d'accord de t'octroyer les droits, tout en approuvant les deux projets que tu proposes. Cependant, je ne suis pas un grand fan des suppressions, je préfère de loin renommer les pages pour les placer en dehors de l'espace principal de sorte à ce que les auteurs puissent toujours les retrouver. Pour ça, un bon espace, c'est les sous-pages des principaux auteurs. Cela pourrait ainsi s'appliquer aux feuilles volantes et aux projets d'écriture abandonnés qui sont suffisamment développés pour justifier une conservation. L'avantage de cette méthode est qu'elle ne demande pas d'avoir les outils d'administrateurs. Faudrait voir maintenant dans quel cas on supprime et dans quel cas on renomme. On pourrait par exemple définir un nombre d'octets ou de caractères, question d'avoir un critère standard et accepté par tous. Qu'en penses-tu [[Utilisateur:Xhungab|Xhungab]] ?
:En fait je préfère continuer comme actuellement. Proposer mes services  pour améliorer wikibook sans avoir aucun droit. De cette manière, si je propose quelque chose d'incongru, comme cela est déjà arrivé, il suffit de neutraliser ma demande. Merci à ceux qui me suivent sur ce travail.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 01:52 (CEST)

:Je comprends @[[Utilisateur:Xhungab|Xhungab]]. Mais précisément, déplacer une page à l'abandon dans une sous-page l'espace utilisateur de l'auteur principal, cela ne demande justement aucun droit et tout le monde peut le faire, toi en premier puisque tu sembles actif à ce niveau. C'est pour ça que je te demande ton avis : que penses-tu de l'idée de déplacer les pages comme je viens de le décrire, plutôt que de les supprimer ? Je viens de soumettre l'idée dans une nouvelle discussion ci-dessous. Tu peux donner ton avis là-bas si tu veux. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 02:27 (CEST)

== archive.today ==
''Voir [[:w:Wikipédia:Le Bistro/21 février 2026#archive.today]].''

Ce site pose apparemment des problèmes de sécurité, il faudrait le remplacer au plus vite si possible, et sinon désactiver les liens.

[[Utilisateur:SyntaxTerror|SyntaxTerror]] ([[Discussion utilisateur:SyntaxTerror|discussion]]) 21 février 2026 à 13:07 (CET)
:Salut SyntaxTerror,
:* 0 liens vers archive.today : [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.today]
:* &lt;s&gt;18&lt;/s&gt; 0 liens vers archive.is [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.is]
:* 0 liens vers archive.li [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.li]
:* 0 liens vers archive.ec [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ec]
:* 0 liens vers archive.ph [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.ph]
:* 0 liens vers archive.fo [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.fo]
:* 0 liens vers archive.md [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.md]
:* &lt;s&gt;1&lt;/s&gt; 0 liens vers archive.vn [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.vn]
:* 0 liens vers archive.closed.social [https://fr.wikibooks.org/wiki/Sp%C3%A9cial:Recherche_de_lien?target=archive.closed.social]
:--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 21 février 2026 à 16:14 (CET)
::Merci pour vos efforts ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:22 (CEST)

== demande aide pour sortir du mode &quot;ébauche&quot; ==

je viens de terminer mon livre ... ci dessous. J'ai compris qu'il fallait le signaler comme n'étant plus au stade &quot;ébauche&quot;  commente faire   Merci

https://fr.wikibooks.org/w/index.php?title=Essai_pour_un_mod%C3%A8le_de_psychisme_objectif&amp;action=info#mw-pageinfo-header-basic [[Utilisateur:Clopeau|Clopeau]] ([[Discussion utilisateur:Clopeau|discussion]]) 17 mars 2026 à 08:20 (CET)
:Bonjour, quand je regarde ''[[Essai pour un modèle de psychisme objectif]]'', sa complétude permettrait en effet de le sortir des ébauches, mais il semble plutôt d'agir d'un travail de recherche que d'un livre pédagogique sur un sujet sourcé comme reconnu.
:Donc en vertu de [[Wikilivres:Principes fondateurs|notre charte]], je propose de le déplacer sur {{WV|Recherche:Accueil}}. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 18 mars 2026 à 09:06 (CET)

== Don à wikipédia depuis wikilivres ==

{{BlocCitation|La Wikimedia Foundation est l’organisation à but non lucratif qui soutient Wikipédia, '''les autres sites de connaissance libre de Wikimédia''', et sa mission de connaissance libre pour tous.|auteur=[https://wikimediafoundation.org/fr/give/donor-frequently-asked-questions/ FAQ], {{g|Qu'est-ce-que la Wikimedia Foundation ?}}}}
Le lien de donation https://donate.wikimedia.org/w/index.php?title=Special:LandingPage&amp;country=FR&amp;uselang=fr&amp;wmf_medium=sidebar&amp;wmf_source=donate&amp;wmf_campaign=fr.wikibooks.org '''ne parle que de wikipédia'''. '''Où sont passés les autres projets ?''' Vont-ils être fermés sauvagement par la fondation comme Wikinews récemment ? La suite au prochain épisode d{{'}}''Highlander-Wikimedia'' : {{g|À la fin, un seul ''projet'' survivra.}} ... &amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 12 mai 2026 à 11:26 (CEST)

:Bonjour,
:Je pense personnellement que les wikis ont des problèmes.
:Il y a une vingtaine d'années, il représentait l'innovation la plus ambitieuse.
:Aujourd'hui, les wikis me semblent dépassés de tous les côtés.
:           wiki = Erreurs 404 (&quot;Page introuvable&quot;)
:Problèmes:
:* 568 livres déclarés. 50 livres terminés (combien sont obsolètes)
:* 21 527 pages déclarées. 20 000 pages orphelines. (Papa t'est où?)
:Solution:
:* Où sont les cours sur YouTube qui utilisent un wikibook comme référence?
:Voilà mon idée sur les wiki.
:* https://fr.wikiversity.org/wiki/Facult%C3%A9:Droit
:* https://fr.wikiversity.org/wiki/D%C3%A9partement:Introduction_au_droit
:&lt;nowiki&gt;~~~~&lt;/nowiki&gt; [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 12 mai 2026 à 13:50 (CEST)
::Ce serait intéressant de mentionner tous les projets actifs oui. [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 12 mai 2026 à 16:23 (CEST)
::: En même temps, le message est plutôt franc étant donné que l'argent des dons n'est pas investi dans le développement de Wikilivres (cf [[:meta:Community Wishlist Survey]] et les réponses à nos tickets Phabricator).
::: Par ailleurs, concernant la qualité des contenus, cela a toujours était un sujet depuis le début, et nous disposons tout de même de plusieurs pages spéciales dans [[Wikilivres:Maintenance]] pour y remédier afin que le lecteur n'ait pas la sensation de se faire empapaouter en se retrouvant sur des ébauches bien placées dans Google. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 13 mai 2026 à 08:48 (CEST)

== La catégorie SI est pleine ! ==

Bonjour tous,

Pour info, la [[:Catégorie:Suppressions immédiates demandées]] contient 9 pages.

Wikilivresquement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 14 juin 2026 à 15:36 (CEST)

:Elle est maintenant vide, merci à ceux qui s'y sont collés ! {{Sourire}} [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 24 juin 2026 à 17:17 (CEST)

== Un RAW bien frais pour juillet ==

{| style=&quot;width:100%;&quot;
| valign=&quot;top&quot; align=&quot;center&quot; style=&quot;border:1px gray solid; padding:1em;&quot; |
{| align=&quot;center&quot;
|-
| style=&quot;text-align: center;&quot; | &lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:4.5em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em;text-align:center; color: #fff; font-style:italic;&quot;&gt;Regards sur l’actualité du mouvement Wikimédia.&lt;/div&gt;
&lt;div style=&quot;text-align: center;&quot;&gt;{{#ifeq:{{FULLPAGENAME}}|Wikipédia:RAW/Rédaction}}&lt;/div&gt;
&lt;/div&gt;&lt;br /&gt;
&lt;hr /&gt;
&lt;div style=&quot;font-size:12pt; font-family:Times New Roman; text-align:center;&quot;&gt;[[w:fr:Wikipédia:RAW/2026-07-05|&lt;span style=&quot;color:darkslategray;&quot;&gt;Le numéro de juillet 2026 est sorti.&lt;/span&gt;]]&lt;/div&gt;
&lt;hr /&gt;&lt;br /&gt;

|- style=&quot;text-align: center;&quot;
| &lt;span style=&quot;font-size:12pt; font-family:Times New Roman;&quot;&gt; '''❖ Au menu de ce numéro ❖'''&lt;/span&gt;
|- style=&quot;font-size:10pt; font-family:Times New Roman; text-align:center;&quot;
| &lt;div style=&quot;text-align:center; column-count:1; column-width:28em; vertical-align:top;&quot;&gt;

'''L'Édito'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Édito|Fêtons notre mouvement !]]

'''Échos francophones'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Résidence|Un nouveau vigneron dans la résidence]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Logo_WP25|Wikipédia en français aux couleurs des 25 ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#DAF|Wikipédia dans le ''Dictionnaire de l'Académie française'']]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Millésime_Wiktionnaire|Quelles sont les nouvelles entrées en français sur le Wiktionnaire ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ADS|Relance de l'Article de la semaine]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#sans_pagEs|Le projet des sans pagEs fête ses dix ans]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#contributions_rémunérées|Faut-il faire évoluer les règles sur les contributions rémunérées ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#wikification|Le mois de la wikification fait son retour pour une septième édition]]

'''Ailleurs dans le mouvement'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Txikipedia|Txikipedia franchit le cap des 10 000 articles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Concours_santé_2026|Un concours sur la santé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Commons_et_IA|Commons se penche sur l'IA]]

'''Nouveautés techniques et outils'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#VIZWP|VIZWP : un outil pour visualiser les lacunes dans les sujets climatiques sur Wikipédia, mais pas que…]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#AI_Source_Verification|Examiner la vérifiabilité grâce à l'IA ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Icônes|Les icônes de l'interface ont changé]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Sous-références|Ça y est, les sous-références sont là]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#ConvoCompass|ConvoCompass, pour moins d'attaques personnelles]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LSV-Tools|LSV-Tools : faciliter la gestion des anecdotes « Le saviez-vous ? »]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#LegendAndDot|Semi-automatiser l'ajout de ponctuation dans les légendes d'images]]

'''Du côté de la recherche'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#COMSAV|COMSAV : la contribution à Wikipédia fait-elle d'un ensemble d'individus un ensemble de pairs ?]]&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#JourneyMap|Où commence la contribution et où s'arrête-t-elle ?]]

'''Le POV'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Le_POV|Guide survie pour la Wikimania 2026]] par Trizek

'''L'Atelier'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Atelier|Le point sur la diversité de genre dans les articles]] par PAC2

'''L'Analyse'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'Analyse|Larry Sanger is back... and fired!]] par Madelgarius, Trizek et Jules*

'''L'interview'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#L'interview|Pronoia : de Byzance aux réseaux sociaux, un œil sur Wikipédia et le monde]] par Antimuonium

'''Le wik’hit-parade'''&lt;/br&gt;
[[w:fr:Wikipédia:RAW/2026-07-05#Wikit|Articles les plus vus en juin 2026]] par Ælfgar

&lt;/div&gt;
|-
| style=&quot;font-family:Times New Roman; text-align:center; font-size:90%;&quot; | [[w:fr:Wikipédia:RAW/2026-07-05|Lire tout le numéro]]
|-
| valign=&quot;top&quot; colspan=&quot;2&quot; style=&quot;padding:0.5em; font-family:Times New Roman;text-align:center; font-size:100%;&quot; |
Venez rédiger le prochain numéro, y parler de ce qui se fait dans votre communauté : [[w:fr:Discussion_Wikipédia:RAW/Rédaction|Salle de rédaction]].&lt;/br&gt;Les anciens numéros sont retrouvables [[w:fr:Modèle:Palette RAW|ici]].
|-
|}
|}
&lt;div style=&quot;margin-top:10px; font-size:90%; padding-left:5px; font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif;&quot;&gt;[[w:fr:Wikipédia:RAW/Inscription|Abonnez-vous !]] [[Utilisateur:L&amp;#39;embellie|L&amp;#39;embellie]] ([[Discussion utilisateur:L&amp;#39;embellie|discussion]]) 5 juillet 2026 à 01:53 (CEST)&lt;/div&gt;

== Les RAW en mode fiesta sur la Wikimania ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro d'août 2026 (n°295) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-08-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;&lt;/div&gt;

'''Un numéro exceptionnel'''

La conférence Wikimania s'est achevée le 25 juillet. Que vous ressentiez de la frustration (si vous n’avez pas pu y assister) ou du [[:w:Wikipédia:Wikispleen|wikispleen]] (si vous y étiez et que vous avez du mal à digérer que ce soit déjà fini), l’équipe des RAW n’a pas ménagé ses efforts pour vous proposer un numéro XXL qui revient en long, en large et en travers sur cet événement qui le mérite bien. Comptes-rendus, témoignages, entretiens, il y en aura pour tous les goûts ! Le numéro est aussi exceptionnel par le nombre de rédactrices et de rédacteurs qui y ont participé {{incise|merci !|stop}} 

Au-delà de Wikimania, l’actualité wikimédienne est loin d’être paisible cet été. Nous vous proposons donc aussi de revenir en détail sur la crise qui secoue la fondation Wikimédia autour de la reconnaissance du syndicat Wiki Workers United (WWU). Nous aurons probablement l’occasion de couvrir la suite de cette histoire dans le prochain numéro. D’ici là, bonne lecture !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia et des nouveaux outils

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Dossier spécial Wikimania&lt;/span&gt;'''

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les POV&lt;/span&gt;'''&lt;br&gt;— Ma Wikimania : la joie, l'inquiétude et la raison d'être&lt;br&gt;— Témoignages : regards sur la Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;L'Analyse&lt;/span&gt;''' — La crise s'intensifie après le refus de la WMF de reconnaître le syndicat WWU

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Comptes-rendus&lt;/span&gt;'''&lt;br&gt;— Une Wikimania sous le signe de la jeunesse&lt;br&gt;— Sur les conséquences de la définition de « wikimédien·ne »&lt;br&gt;— Petit tour d’horizon de la créativité wikimédienne&lt;br&gt;— CultureStrong : respecter les savoirs des Premières Nations sur les plateformes Wikimédia&lt;br&gt;— Des événements techniques à Wikimania

'''&lt;span style=&quot;margin:0;background:var(--background-color-success-subtle, #dff2eb);padding:3px;color:black&quot;&gt;Les Interviews&lt;/span&gt;'''&lt;br&gt;— Ses goûts, sa Wikimania, sa prochaine tournée... : Baby Globe nous dévoile tout !&lt;br&gt;— Jules*, notre Wikimédien de l'année : comment rendre compte du changement climatique tout en protégeant l'encyclopédie

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : si un sujet vous tient à cœur, n'hésitez pas à proposer une idée d'article ou à participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]]. Toutes les contributions sont les bienvenues, quel que soit votre wiki d'origine ! &lt;span class=&quot;smiley&quot;&gt;[[Image:Face-smile.svg|20px|Sourire|alt=Émoticône sourire]]&lt;/span&gt;

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 août 2026 à 00:28 (CEST)

== Bientôt les 20 ans de Wikiversité ==

Bonjour.

Un petit message de « débauchage » dans le cadre d'un projet d'amélioration de Wikiversité. Comme dit la chanson : « On n'a pas tous les jours vingt ans ! » Plus d'infos [[v:Wikiversité:La_salle_café/août_2026#Améliorer_Wikiversité_pour_ses_vingt_ans_d'existence|dans la salle café du projet]].

Belle fin de journée à tous ! [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 16 août 2026 à 00:26 (CEST)

== [[:Catégorie:Suppressions immédiates demandées|Série de demandes de suppression immédiate]] ==

Bonjour,

La [[:Catégorie:Suppressions immédiates demandées]] est de nouveau pleine, mais cette fois, il semble qu'elle ait été remplie par le seul {{U|Xhungab}}.

Cordialement, [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 16 août 2026 à 14:56 (CEST)
:{{fait}} Bonjour, oui c'était effectivement un ensemble d'ébauches abandonnées. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]]) 17 août 2026 à 10:38 (CEST)
::Merci pour votre aide [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 17 août 2026 à 14:26 (CEST)

== Deux idées à débattre ==

Bonjour.

Vu le travail de traitement des pages et livres abandonnés et suite à une discussion avec @[[Utilisateur:Xhungab|Xhungab]] reprise ci-dessous, j'aimerais soumettre deux idées à la communauté Wikilivres.

'''La première idée''' est de déplacer toutes les pages et livres dont le développement est abandonné depuis longtemps en sous-page de l'auteur principal tout en laissant un message sur sa page de discussion avec un lien pointant vers la sous-page en question. Ce message pouvant faire l'objet d'un modèle.

Avantage : 1. Pas besoin d'être admin pour faire ce genre de maintenance. 2. Pas de risque de frustrer un auteur ni de perdre de vue des informations intéressantes. 3. Ceci dans le but d'améliorer l'apparence de Wikilivres au niveau du contenu visible sur l'espace de nom principal.

Nécessité : 1. Créer un modèle à placer sur la page de discussion de l'auteur principal après déplacement. 2. Définir la durée d'abandon des pages à déplacer.

'''La deuxième idée''' est de donner les outils d'administrateurs à des personnes qui ne veulent pas endosser cette responsabilité à long terme et de manière continue, mais qui sont d'accord d'en faire usage dans le cadre d'un projet de maintenance temporaire. Cela pourrait être utile pour @[[Utilisateur:Fourmidable|Fourmidable]] s'il le souhaite, à moins qu'il se décide à déposer sa candidature pour une nomination définitive. Ce qui serait une bonne idée, je trouve.

Qu'en pensez-vous @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Grondin|Grondin]] ?

Une prise de décision est-elle nécessaire si on décidait une mise en application ?

Bien à vous tous,  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 01:50 (CEST)

:Bonjour,
:J'ai proposé une liste de livres à supprimer
:https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate
:Doit-on réellement les garder ? ;) [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 24 août 2026 à 10:21 (CEST)
::Quel est l'avantage de la suppression par rapport au déplacement @[[Utilisateur:Xhungab|Xhungab]]? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:56 (CEST)
:::En déterminant un contenu minimum, on peut faire le tri de ce que l'on supprime et ce que l'on déplace. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 24 août 2026 à 10:58 (CEST)
::::Bonjour,
::::Les droits administrateurs temporaires sont difficiles à gérer : un bureaucrate peut attribuer le status administrateur mais pas le retirer.
::::Concernant les critères suppression ou renommage, je propose :
::::* (cas 1) Une page qui ne contient vraiment aucun texte (ex : seulement des liens rouges) --&gt; suppression
::::* (cas 2) Une page avec quelques phrases significatives récupérables --&gt; soit (a) tenter de fusionner dans un livre qui aborde le même sujet ou sujet connexe, soit (b) renommer en sous-page de l'auteur si aucun livre pour la fusion ne convient
::::* (cas 3) Une page avec plus de contenu que (cas 2) --&gt; conserver
::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 24 août 2026 à 19:33 (CEST)
:::::Salut @[[Utilisateur:DavidL|DavidL]]. Oui, c'est raisonnable. Reste que la fusion, c'est compliqué. J'ai essayé, mais je ne comprends rien. Une vidéo m'aiderait à comprendre, mais j'en ai pas trouvé. Ensuite, si on garde, genre un livre abandonné depuis plus de trois ans avec un chapitre entamé sur cinq prévus, par exemple, on le laisse dans l'espace principal, ou on le déplace vers l'espace utilisateur de l'auteur ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 25 août 2026 à 00:38 (CEST)
::::::Pour ce cas je propose de le fusionner si possible, comme (cas 2)(a) ; sinon le conserver, comme (cas3) afin qu'un utilisateur motivé puisse reprendre le livre.
::::::--&amp;nbsp;◄&amp;nbsp;[[Utilisateur:DavidL|'''D'''avid&amp;nbsp;'''L''']]&amp;nbsp;•&amp;nbsp;[[Discussion Utilisateur:DavidL|discuter]]&amp;nbsp;► 25 août 2026 à 08:36 (CEST)
:::::::Ok. Es-tu à l'aise avec la fusion @[[Utilisateur:DavidL|DavidL]] ? Car c'est une solution intéressante, mais je n'y arrive pas. Il y a toujours un message que je ne comprends pas et suite à quoi je préfère arrêter. Serais-tu dispo pour m'expliquer comment faire durant un appel vidéo ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:30 (CEST)
::::::::Bonjour {{Mention|Lionel Scheepmans}}, je suis très favorable à tes deux idées ! [[Utilisateur:Fourmidable|Fourmidable]] ([[Discussion utilisateur:Fourmidable|discussion]]) 26 août 2026 à 15:39 (CEST)
:::::::::Ok @[[Utilisateur:Fourmidable|Fourmidable]], je me dis qu'il serait encore bien d'avoir les avis de @[[Utilisateur:JackPotte|JackPotte]], voir de @[[Utilisateur:Grondin|Grondin]], s'ils trouvent le temps nécessaire pour le faire. Et puis, on peut penser tout doucement à créer une page pour fixer des décisions en votant si nécessaire pour confirmer l'adhésion générale ou grandement majoritaire.
:::::::::C'est curieux, je voulais travailler sur Wikiversité et finalement je me trouve plus actif sur Wikilivres. Mais les enjeux sont les mêmes et beaucoup de personnes actives ici le sont aussi sur Wikiversité, y compris parmi les administrateurs. En avançant dans Wikilivres, j'ai donc aussi l'impression que l'on avance sur Wikiversité.
:::::::::Au fait, fourmidable ? Tu ne serais pas intéressé, toi, de prendre un balai dans Wikilivres ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:27 (CEST)

== Demande d'aide pour amélioré Wikbook. Merci ==

* Actuellement j'ai proposé mes services pour améliorer wikibook. J'ai créé un partenariat informel avec des administrateurs, je propose des pages et des livres à supprimer. Ils décident soit de suivre ma demande, soit de la neutraliser. Je les remercie pour leur patience et leur aide.

- https://fr.wikibooks.org/wiki/Wikilivres:Demande_de_suppression_imm%C3%A9diate


*Certain livres semblent trop avancé pour suivre cette procédure.

- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026

Dans cette page, je propose des livres trop avancés pour être traités rapidement. Il faut un vote pour que les demandes soient acceptées.
Aujourd'hui j'ai besoin de vous pour faire avancer mes propositions, sur des livres peut-être intéressants mais abandonnés depuis plus de trois ans, cinq ans, dix ans, vingt ans.

Si vous appréciez mon dévouement pour Wikibook et que vous souhaitez m'aider, ''il suffit chaque semaine de rajouter la commande'' {{VoteSupprimer}} ''sur les livres que je propose''. '''Entré {{}} puis à l'intérieur des parentthèses VoteSupprimer''' et signer votre accord. Merci pour votre aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 25 août 2026 à 10:33 (CEST)

:Salut @[[Utilisateur:Xhungab|Xhungab]], merci à toi pour ton engagement ! J'ai supprimé les pages qui étaient pratiquement vides dans ta liste. J'ai laissé les autres car la proposition de fusion est invoquée par @[[Utilisateur:DavidL|DavidL]] pour les pages avec du contenu. Malheureusement , je ne comprends pas comment fonctionne l'outil de fusion. J'espère que quelqu'un voudra bien m'expliquer le fonctionnement via un appel vidéo. Car je ne comprends pas les explications écrites. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 01:53 (CEST)
::Bonjour, Merci pour ton aide.
::.
::* J'ai travaillé sur la liste des pages les plus anciennement modifiées de l'année 2006. J'ai proposé tous les livres en errance à la suppression par vote.
::- https://fr.wikibooks.org/wiki/Wikilivres:Demandes_de_suppression/2026
::Je vais attendre qu'elle soit traitée. Soit en supprimant ces livres soit en supprimant ma demande. Ensuite je ferai l'année 2007.
::.
::*Tu m'a posé une question.
::Quel est l'avantage de la suppression par rapport au déplacement ?
::Je vais essayer de te répondre dans mon prochain message. (Ce sera juste un délire d'un mois d'août un peu chaud). [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 09:20 (CEST)
:::C'est motivant de voir des gens motivés =)
:::Prend ton temps, il n'y a aucune échéance dans les projets Wikimédia, c'est un processus en continu qui peut s'étendre à plusieurs générations... Et si c'est plus facile pour toi de passer à l'oral, sache que je suis partant pour une discussion audio ou vidéo. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:35 (CEST)

== J'ai fait un rêve. ==

J'ai fait un rêve.

Un lieu où des amateurs passionnés proposeraient de partager leurs travaux avec des étudiants curieux. Pas les meilleurs travaux du monde. Mais pas les pires non plus. Un endroit où les anciens passeraient  le relais à ceux qui présentent leurs avenirs.  

Ce serait une petite bibliothèque avec une cinquantaine de livres disponibles à l'étude. Cinq ou six livres en construction que les étudiants pourraient travailler avec l'auteur. Tous les ans quelques livres supplémentaires viendraient enrichir ce lieu d'étude.

Aujourd'hui, il existe Wikibook. Un lieu où des auteurs malveillants prouvent que le travail collaboratif ne fonctionne pas. Ils créent des livres parfaitement construits de quelques chapitres puis les abandonnent sans scrupule. Ces livres moisissent depuis cinq, dix, quinze, vingt ans.

Wikibook c'est:
* La bibliothèque de livres pédagogiques libres que chacun peut améliorer.
* 569 livres contenant 22 112 pages.
.
* 569 livres dont 450 livres à l'abandon depuis cinq, dix, quinze, vingt ans.


Oui, aujourd'hui Wikibook peut changer. Wikibook va changer. Wikibook pour les étudiants va renaître de ses cendres. Les cendres des vieux livres abandonnés. Les auteurs devront faire honnêtement leur travail, ou les étudiants feront le leur.

Ceci n'est juste qu'un rêve dans un mois d'août un peu plus chaud que d'habitude.

Merci pour m'avoir suivi jusqu'ici. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 10:13 (CEST)

:Je trouve que c'est un très beau rêve @[[Utilisateur:Xhungab|Xhungab]]. Dans ce rêve, on peut voir la partie remplie du verre au lieu de la partie vide. Sur Wikilivres, il y a plus de 100 ouvrages terminés entièrement libres d'usage et toujours améliorables collectivement. Deux fois plus que la cinquantaine de livres dont tu parles dans ton rêve.
:C'est normal d'abandonner un projet d'écriture. La vie est tellement imprévisible. Les ressources en temps et énergie tant limitées. Combien de personnes ont commencé un livre sur papier ou sur leur ordi sans jamais le terminer ?
:C'est pareil sur Wikilivres, sauf que c'est visible aux yeux de tous.
:Quand on commence un truc, c'est jamais dans l'intention de l'arrêter. Si on arrête, c'est qu'il y a des raisons à cela. Je n'ai donc pas envie de voir dans ces abandons des actes de malveillance, ni de critiquer leurs auteurs. J'ai d'ailleurs moi-même des projets que je n'arrive pas à concrétiser (exemple).
:Je pense au contraire que ce n'est pas un problème à partir du moment où nous avons la liberté et les outils (communication, suppression, fusion) qui nous permettent de faire le tri entre ce qui est terminé, voire même ce qui est de qualité, et le reste.
:Ce rêve est donc possible et mes démarches pour devenir wikimédien en résidence à l'université sont une démarche qui va dans ce sens. J'ai d'ailleurs apporté les preuves que l'intégration des projets Wikimédia dans le processus d'apprentissage universitaire est non seulement possible, mais hyper efficace. Malheureusement, j'ai toujours l'impression que cela n'intéresse personne. Ni à l'Unif, ni dans Wikimédia. Mais je ne désespère pas. Les changements de paradigmes sont lents en raison des habitudes. C'est une fatalité chez l'humain. Il faut faire avec.
:Mais donc. Concentrons-nous sur la manière d'organiser notre bibliothèque pour que les visiteurs puissent confortablement voir ce qui s'y trouve en séparant, livres terminés, livres de qualité (cela se fait bien avec les articles de Wikipédia), livres en cours d'édition et livres abandonnés, etc. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 13:32 (CEST)
::Je pense que nos points de vue sont irréconciliables en toute amitié. Pour moi, Wikibook est une  bibliothèque de livres pédagogiques libres que chacun peut améliorer. Soit on peut mettre un étudiant sur un livre. Soit ce livre est inutile (Je parle de livre de plus de trois ans). 
::.
::Wikibook n'est pas un entrepôt pour les auteurs.  C'est une bibliothèque.[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 14:57 (CEST)
:::@[[Utilisateur:Xhungab|Xhungab]], c'est bien que l'on ne soit pas d'accord, car cela permet d'avancer vers une solution que tout le monde pourra approuver. C'est le principe du consensus et cela prend du temps en discussion. C'est normal et sain. En de plus, ce qui est dit ici est tout à fait pertinent pour Wikiversité qui est confronté à des problèmes similaires que Wikilivres.
:::J'exprime mes idées ci-dessous mes idées autrement pour voir si cela peut se rapprocher de ta propre vision des choses.
:::J'imagine la bibliothèque Wikilivres avec trois pièces :
:::# Une pièce principale à l'entrée qui reprend tous les livres terminés et prêts à l'emploi par une personne désireuse de les utiliser dans le cadre d'un apprentissage. Comme dans toutes les bonnes bibliothèques, ces ouvrages sont rangés par thèmes et certains d'entre eux sont mis en évidence en raison de leurs qualités, de leur pertinence par rapport à l'actualité, etc.
:::# Une pièce archives à l'arrière du bâtiment (un espace de nom que l'on pourrait choisir parmi ceux existants ou créer si nécessaire) dans laquelle on entrepose toute une série de livres abandonnés mais dont le contenu est archivé dans le but d'une éventuelle réutilisation. Cette réutilisation, comme le suggère @[[Utilisateur:DavidL|DavidL]], peut s'effectuer dans le cadre d'une fusion du contenu abandonné avec un autre contenu abandonné, ou mieux encore, si cela se présente, avec un livre terminé dans lequel les informations utiles du document abandonné sont manquantes. À noter que cela représente beaucoup de travail, tant pour la relecture que pour la mise en œuvre des fusions, qui, à mes yeux de personne expérimentée dans l'usage de MediaWiki, est un processus compliqué. De plus, il ne peut être fait que par des personnes ayant les outils d'administrateur. C'est-à-dire quatre personnes, dont deux ou trois actives dans ces récentes discussions.
:::# Dans la librairie Wikilivres, il y a ensuite un étage dans lequel chaque personne inscrite peut bénéficier d'un espace personnel, pour se présenter, stocker des informations, mais également travailler sur des projets personnels d'écriture. En tenant compte de ceci, on peut alors aussi imaginer de déplacer les ouvrages inachevés de la pièce principale à l'entrée de la librairie, vers ces différents locaux selon leurs auteurs respectifs.
:::Face à ces trois espaces, la question qu'il reste à se poser est de savoir si et dans quelles condition, on peut déplacer les ouvrages inachevés vers une salle d'archive, ou dans les locaux personnels des auteurs ? Cela en signalant que ce déplacement peut être fait très facilement et par toutes les personnes qui le souhaitent, même sans inscription à la bibliothèque. Ce qui est un grand avantage par rapport à la fusion.
:::Pendant ce temps, à l'accueil de la bibliothèque Wikibook, on invite les visiteurs à parcourir la pièce avec les ouvrages terminés, mais également la pièce archive, où ils peuvent trouver des ouvrages inachevés, au cas où ils veulent poursuivre leurs développements, ou trouver des ressources intéressantes pour leurs travaux personnels. On les informe ensuite aussi qu'avec leur inscription, ils bénéficient d'un local pour leurs activités personnelles et notamment pour y placer les ébauches d'ouvrages qu'ils désirent rédiger.
:::Que penses-tu de mon propre rêve ? Est-il si différent du tien ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:17 (CEST)
::::Et les autres ? @[[Utilisateur:DavidL|DavidL]], @[[Utilisateur:Fourmidable|Fourmidable]], @[[Utilisateur:JackPotte|JackPotte]], @[[Utilisateur:Grondin|Grondin]]. Que pensez-vous de nos rêves ? Et, si le mien vous parle, quelles seraient vos propositions pour orienter les déplacements de pages à l'abandon entre un espace d'archivage (qui pourrait être créé) et des espaces utilisateurs ? Le nombre d'octets ? La finalisation d'une section ou d'un chapitre ? Quelles autres possibilités ? [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 17:37 (CEST)
::::: Bonjour, a priori ça doit se régler au cas par cas sur [[Wikilivres:Demandes de suppression]]. [[Utilisateur:JackPotte|JackPotte]] ([[Discussion utilisateur:JackPotte|&lt;span style=&quot;color:#FF6600&quot;&gt;$&lt;/span&gt;♠]])

::::Bonjour,
::::La structure de Wikibook est parfaite grâce à sa vitrine.  Pour moi, il y a juste un problème sur les listes sur la droite : Arts, Loisir, Histoire, Langues, Technologie, Informatique, Sciences, Sciences humaines. Ces listes ne devraient donner accès qu'aux livres terminés.
::::Ces listes actuelles pourraient être caché dans un espace création qui pourrait être posé avec le lien Nouveauté en bas de la page.
::::Pour la gestion des livres, il suffirait qu'une ou deux personnes parcourent la bibliothèque et proposent quelques suppressions chaque semaine, pour en quelques mois éclaircir la situation. Je pense que l'on peut faire confiance aux administrateurs pour gérer la situation des livres, ceux qui sont à garder et les autres. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 26 août 2026 à 18:30 (CEST)
:::::@[[Utilisateur:JackPotte|JackPotte]]. Le cas par cas est ce que nous faisons depuis toujours. Cela nous amène à la situation actuelle qui semble ne pas convenir à tous. En tout cas, c'est mon cas. Ici comme sur Wikiversité. Quand, en navigant sur le site, une personne tombe neuf fois sur dix sur des pages presque vides et inachevées, comme c'est le cas sur Wikilivre, elle se dit : c'est quoi ce site ? Elle passe alors à autre chose de plus vivant, genre https://zestedesavoir.com/ ou autre. Sans changements éditoriaux, je pense que la situation évoluera.
:::::@[[Utilisateur:Xhungab|Xhungab]], on peut faire comme tu dis. Cependant, la charge de travail repose sur une double action, la proposition d'abord et le traitement ensuite. Un traitement qui finalement repose sur les épaules des administrateurs. Nous ne sommes que des bénévoles peu nombreux et pas toujours disponibles.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 26 août 2026 à 19:13 (CEST)
:Créer un livre, le ranger, en établir un plan, le catégoriser n'est pas un travail négligeable... Un travail que d'autres personnes intéressées pour écrire sur le sujet n'ont pas à refaire 🤷‍♂️ ...

== Petite proposition indécente à Lionel ==

Bonjour  Lionel,

Je souhaiterais te proposer un petit projet.

a) Dans la page principale de wikibook tu créés une page &quot;Espace pour les auteurs&quot;. Tu insères cette page devant le lien &quot;Nouveautés&quot;.
.

b) Tu copies dans cette page la liste des liens qui se trouvent en haut à droite dans la nouvelle page. (Arts, Loisirs, ...) Tu ne les modifies pas dans la page principale.
.

c) Dans la nouvelle page tu peux écrire un texte du genre.
Dans cette page, vous trouverez la liste de tous les livres disponibles sur Wikibook. Vous trouverez en particulier des livres en construction et vous pourrez entrer en contact avec les auteurs. Vous trouverez aussi des livres en construction sans auteur actif que vous pourrez compléter.


Cela est la première étape, si l'aventure t'intéresse. En fait tu ajoutes juste une page, que tu pourras supprimer si les besoins se font sentir. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 12:25 (CEST)

:La proposition est très décente @[[Utilisateur:Xhungab|Xhungab]] 
:Mais avant toute choses le plus prudent est de lancer une prise dé décision pour s'assurer d'un concesnsus en faveurs des changements dont nous débatons actuellement.  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 27 août 2026 à 15:40 (CEST)
::Toutes ces actions seront réversibles. On ajoute une page. Un problème, on la supprime. 
::On fait rapidement les changements, on attend trois jours. En cas de problème, on supprime tout. Il suffira de s'excuser et de dire que l'on ne savait pas que l'on n'avait pas le droit. 
:: Un espace pour les lecteurs et un espace pour les auteurs séparés.
::[https://fr.wikibooks.org/wiki/Utilisateur:Xhungab Nouvelle page wikibook][[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 27 août 2026 à 16:49 (CEST)
:@[[Utilisateur:Xhungab|Xhungab]] , ma grand mère disait : faire et défaire, c'est toujours travailler. Pour les grand changements, on a coutume de faire un prise de décision composée des propositions, suivies de débats et d'un vote.
:En plus, certaines décisions nécessite un changement technique et ce n'est pas toujours facilement réversible. Comme créer un nouvel espace de nom pour y transfèrer une catégorie de pages  [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 28 août 2026 à 03:07 (CEST)
::Merci pour ton aide. Tu comprends maintenant pourquoi toi tu es un administrateur et moi pas.
::.
::'''Oui, aujourd'hui Wikibook peut changer. Wikibook va changer.''' 
::.
::*  '''Le changement c'est Maintenant :''' [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']
::[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 28 août 2026 à 08:33 (CEST)
:::Ton enthousiasme fait plaisir @[[Utilisateur:Xhungab|Xhungab]], et je serais en faveur d'un style plus épuré de notre page d'accueil en plus d'une méthodes de classement et de séparation des ouvrages terminé, en cours et abandonnés. Je pense qu'à terme, nous pourrions faire une proposition de changement à soumettre au reste de la communauté. Par chance, nous ne sommes pas nombreux, cela simplifire les discussions et le processus de décision. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 19:26 (CEST)
::::Cette page  [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook'''] propose la vitrine, les livres disponibles, les mini-livres disponibles pour les lecteurs. Les lecteurs ne seront en contact qu'avec les livres terminés.
::::.
::::En bas à côté des nouveautés, il y a l' '''[https://fr.wikibooks.org/wiki/Discussion_utilisateur:Xhungab Espace pour les auteurs]''', avec tous les livres du site rangés par thème ou par niveau d'avancement si on clique sur l'image. Sinon, il y a une liste de catégories art,...
::::.
::::Cette proposition sépare donc deux espaces. Un pour les lecteurs et un pour les auteurs. Il suffirait maintenant plus qu'à nettoyer l'espace auteurs. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 20:22 (CEST)
L'usage des catégories me semble aussi une manière très pratique de trier le contenu de Wikilivre. Malheureusement, ces pages ne sont pas très sexy du coup l'usage de type de code pourrait être utile :

{ {Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={ { #categorytree:Livres terminés|mode=pages} } } }

Avec le rendu ci-dessous :
{{Boîte déroulante|titre=Cliquez ici pour voir les livres terminés|alignT=left|contenu={{ #categorytree:Livres terminés|mode=pages}}}}

On pourrait ainsi imaginer d'intégrer directement ce code dans la page d'accueil pour afficher une boite déroulante au lieu d'envoyer le visiteur en dehors de la page d'accueil. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:08 (CEST)

:Tu devrais créer la page Lioneltest01 dans ta page utilisateur. Copier le code de la page principale de wikibook.
:Puis faire les changements que tu juges nécessaires. Tu peux éventuellement faire plusieurs pages. Ensuite, tu mets cette page dans le bistro pour que l'on puisse voir le résultat. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 21:22 (CEST)
::Je devrais, tu devrais, il devrait, nous devrions ... =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 21:28 (CEST)
:::Chaque chose en son temps.
:::1. Débattre ici des idées de changements.
:::2. Mettre les choses en place pour leur réalisation, comme la mise à jour du modèle:boite déroulante en s'inspirant de celui de Wikipédia ou d'autres sites.
:::3. Quand il n'y a plus de nouvelle idée ici, créer une page genre :[[Wikilivres:Prise de décision/Nouvelle page d'accueil et gestion des abandons]] avec une description précise des projets de changements, et une éventuelle [[Accueil/projet|page de présentation du projet d'un nouvelle page d'accueil]]
:::4. Poursuivre les discussions et propositions si nécessaire.
:::5. Quand on a fait le tour, passer au vote.
:::6. Mettre les décisions en application. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:03 (CEST)
::::Je propose actuellement un projet qui se trouve sur ma page utilisateur. Pourrais-tu lancer une prise de décision sur ce projet. Je ne sais pas comment on fait une telle demande. Je suis prêt à présenter mon projet et à recevoir les critiques. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 22:16 (CEST)
:::::''Aide-toi le ciel t'aidera''. La bureaucratie, c'est pas mon truc. Et puis ça m'irrite un peu que tu enchaines des demandes de faire des choses qui ne demande pas les outils d'administrateurs. Raisons pour lequelles, je pense finalement que l'on gagnerait à appliquer la [[w:Do-ocratie|Do-ocratie]] qui a fait ses preuves dans le monde du libre dont les projets Wikimédia sont issus.
:::::Si tu as une idée et qu'elle ne demande pas des droits de modification que tu n'as pas, fait la et on se retrouve en page de discussion de la page de tes changements en cas de problèmes et pour d'éventuelle commentaire. Sans réaction, pense à ''qui ne dit mot conscent''.
:::::Si tes idées demandes les outils d'administrateurs, tu peux alors demander à un admin de le faire. Libre à lui de le faire ou pas et si ça lui plait, si il a envie, si il prend le temps. Nous sommes bénévoles... Il y a bien des gens payés par la fondation, mais comment dire... Disons qu'ils ne sont pas des plus serviables. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 29 août 2026 à 22:57 (CEST)
::::::Excuse moi je pensais qu'il faillait être administrateur pour faire une demande de prise de décision. Je vais donc essayer tous seul. Merci pour ton aide. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 29 août 2026 à 23:06 (CEST)
:::::::Ok @[[Utilisateur:Xhungab|Xhungab]], pas de soucis. On ne peut pas tout savoir =) [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 30 août 2026 à 01:45 (CEST)

== Wikilivres:Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''


Merci pour votre participation

[[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 30 août 2026 à 00:43 (CEST)

:Bonjour @[[Utilisateur:Xhungab|Xhungab]]. Content de te revoir dans les murs de Wikiversité après nos échanges sur Wikilivres. Je comprends ton sentiment de solitude, je le ressens aussi souvent. Il faut l'accepter et ne pas se décourager pour autant. Nous avons la chance de fonctionner dans une organisation bénévole, dans laquelle personne n'est tenu de répondre à des demandes. De ce fait, les choses évoluent lentement et en fonction des disponibilités. Dis-toi aussi que la période estivale est toujours un moment d'acalmie dans la participation. Moi par exemple, quand il fait bon, je préfère passer du temps sur des occupations extérieures que devant un écran.
:Cela dit, tu dois garder 3 règles implicites qui sont fréquemment appliquées dans les projets Wikimédia.
:1. ''Qui ne dit mot consent''. Si les personnes ne réagissent pas, cela ne veut pas dire qu'elles ne lisent pas. Par économie de temps et pour les personnes trop occupées ou pas assez motivées pour s'investir, ne pas réagir est un signe de consentement implicite.
:2. ''Les absents ont toujours tort.'' Lorsque l'on fait les choses dans les règles de l'art, par exemple comme tu le fais en lançant une prise de décision pour opérer un changement significatif dans Wikilivres, aucune personne absente durant un processus de décision clôturé viendra remettre en cause les choses par la suite.
:3. La doocratie. Les wikis sont des espaces de libertés au niveau de l'amélioration des contenus, mais également de l'organisation et des formes de contenus. En dehors du vandalisme qui est bien contrôlé par des personnes telles que @[[Utilisateur:Crochet.david|Crochet.david]], toute initiative est souvent perçue comme bienvenue. @[[Utilisateur:Fourmidable|Fourmidable]], par exemple, depuis qu'il est administrateur, a fait de nombreuses améliorations dans Wikiversité sans demander l'avis de la communauté. Personne ne lui a reproché son investissement. Si quelque chose qu'il a entrepris ne plaît pas à quelqu'un, une discussion commence entre lui et cette personne pour chercher une entente.
:Voilà tout.
:Je te rejoins aussi sur le fait que ce qui est décidé et mis en place sur Wikilivres peut tout à fait servir d'exemple pour Wikiversité et vice versa. Je ne suis pas le seul à être administrateur dans les deux projets et cela aide beaucoup à la création d'une synergie entre les deux projets qui sont finalement très complémentaires. Cela n'est pas étonnant d'ailleurs lorsque l'on sait que Wikiversité est né de Wikilivres.
:Une belle fin de journée à toi et à tous ceux qui liront ce message. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:30 (CEST)
::Merci. Pour tes explications. [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 6 septembre 2026 à 13:50 (CEST)
:::Avec plaisir. Pense aussi qu'il n'y a pas de combat dans les projets Wiki, mais un lent processus évolutif, sans fin programmée, et qui est pour moi l'un des meilleurs que je connaisse. [[User:Lionel Scheepmans|Lionel Scheepmans]] &lt;sup&gt;&lt;big&gt;✉&lt;/big&gt; [[User talk:Lionel Scheepmans|Contact]]&lt;/sup&gt; &lt;sub&gt;Désolé pour ma [[w:dysorthographie|dysorthographie]], [[w:dyslexie|dyslexie]] et [[wikt:distraction|&quot;dys&quot;traction]].&lt;/sub&gt; 6 septembre 2026 à 13:57 (CEST)

== Les RAW sont arrivés, la rentrée peut commencer ! ==

&lt;div style=&quot;background-color:#177860; border-radius:.2em;  color:#FFF;padding: 1em;&quot;&gt;
&lt;div style=&quot;font-family: Century Gothic; font-size:3em; line-height:120%;text-align:center;color: #fff;&quot;&gt;RAW&lt;/div&gt;
&lt;div style=&quot;margin-bottom:1.5em; margin-top:1em; text-align:center; color: #fff;&quot;&gt;Le numéro de&amp;nbsp;septembre 2026 ({{numéro|296}}) est sorti.&lt;/div&gt;
&lt;div class=&quot;center&quot;&gt;[[:w:Wikipédia:RAW/2026-09-05|&lt;span class=&quot;cdx-button cdx-button--fake-button cdx-button--fake-button--enabled&quot; style=&quot;white-space:break-spaces; text-align:center; gap:0;&quot;role=&quot;button&quot; aria-disabled=&quot;false&quot;&gt;Lire l'infolettre&lt;/span&gt;]]&lt;/div&gt;
&lt;/div&gt;

'''C'est la rentrée'''

Après un numéro très dense en août en raison de la Wikimania, celui-ci est un peu plus léger car l'équipe s'est octroyée quelques vacances. Cela n'empêche pas le mouvement de continuer à vivre, avec une rentrée déjà animée ! Du côté des projets francophones, le Wiktionnaire vient de franchir le cap symbolique des sept millions d’entrées, tandis que Wikipédia continue de voir fleurir sondages et discussions sur son fonctionnement.

Une rentrée, donc, placée sous le signe de la construction collective : de nouveaux outils pour contribuer, de nouveaux espaces pour échanger, de nouvelles formes d’organisation… Ce numéro des RAW vous propose de faire le tour de cette actualité, avant de reprendre tranquillement le chemin des projets Wikimédia.

L'équipe de la rédaction a également commencé à réfléchir à un nouveau nom pour remplacer l'énigmatique « RAW ». N'hésitez pas à venir donner votre avis dans la [[:w:Discussion Wikipédia:RAW/Rédaction#Changement de nom|section dédiée]] !

----

Au menu de ce numéro :

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;En bref&lt;/span&gt;''' — Des actualités francophones et du mouvement Wikimédia, des nouveaux outils et des articles de recherche

'''&lt;span style=&quot;margin:0;background:var(--color-success, #177860);padding:3px;color:white&quot;&gt;Le wik'hit parade&lt;/span&gt;''' — Une analyse des articles les plus vus le mois dernier

[[Fichier:Toicon-icon-sharp-corners-draw.svg|20px|classe=skin-invert-image]] Les RAW, c'est aussi vous : n'hésitez pas à suggérer des sujets ou participer à la rédaction du [[:w:Wikipédia:RAW/Rédaction|prochain numéro]] !

[[Utilisateur:Antimuonium|Antimuonium]] ([[Discussion utilisateur:Antimuonium|discussion]]) 5 septembre 2026 à 00:17 (CEST)

== Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés ==

J'ai posé une demande de prise de décision concernant le sujet suivant.


[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Modifier_le_contenue_de_l%27espace_Nouveaut%C3%A9s Wikilivres:Prise de décision/Modifier le contenue de l'espace Nouveautés]

Merci pour votre participation [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 9 septembre 2026 à 14:38 (CEST)

== '''Décision''':Prise de décision/Créer un espace lecteurs et un espace auteurs sur la page d'accueil ==

J'ai posé une demande de prise de décision concernant le sujet suivant.

'''[https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Cr%C3%A9er_un_espace_lecteurs_et_un_espace_auteurs_sur_la_page_d%27accueil Créer un espace lecteurs et un espace  Les coulisses de Wikibook]'''

'''Décision pour : [https://fr.wikibooks.org/wiki/Utilisateur:Xhungab  '''Wikibook''']'''

Résultats : 3 + Pour, un Neutre Neutre et un - Contre soit 60 % de + Pour par rapport au total des votes exprimés : la proposition est adoptée. Quelques propositions de reformulations et de nuances ont été faites qui pourront être prise en compte. Cdlt, VIGNERON * discut. 13 septembre 2026 à 18:27 (CEST)

Merci pour votre participation. Ma première proposition était un peu malhabile, mais grâce à vos interventions je pense que l'on a créé quelque chose de correct. '''Merci à tous''' [[Utilisateur:Xhungab|Xhungab]] ([[Discussion utilisateur:Xhungab|discussion]]) 13 septembre 2026 à 20:22 (CEST)</text>
      <sha1>qzwwm8zp82xag9avp7cn73vmjg06eu4</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc initiation/006z</title>
    <ns>0</ns>
    <id>84512</id>
    <revision>
      <id>772335</id>
      <timestamp>2026-09-17T06:42:26Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>772335</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1232" sha1="7va3cwb6s0250hdr9nruphieo8kgu1o" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc initiation (livre)]] 

[[Mathc initiation/a512#* La transformée de Laplace : Multiplication par t^n| Sommaire]] 

{{Partie{{{type|}}}|la Transformée de Laplace : Théorème des valeurs initiales}}
.
* '''Théorème des valeurs initiales : lim t -&gt;0 F(t) = lim s-&gt;oo (s) f(s)''' 
.
       '''L{sin(t)} = 1/(s^2+1)'''        
       lim sin(t) t -&gt;0                         = 0;      
       lim  '''(s) 1/(s^2+1)''' s-&gt;oo = lim s-&gt;oo 1/s = 0
      
  
       '''L{cos(t)} = s/(s^2+1)'''                 
       lim cos(t) t -&gt;0                       = 1;      
       lim  '''(s) s/(s^2+1)''' s-&gt;oo = lim 1 s-&gt;oo = 1
      
  
       '''L{sinh(t)} = 1/(s^2-1)'''  
       lim sinh(t) t -&gt;0                       = 0;      
       lim '''(s) 1/(s^2-1)''' s-&gt;oo = lim 1/s s-&gt;oo = 0
      
  
       '''L{cosh(t)} = s/(s^2-1)'''               
       lim cosh(t) t -&gt;0                       = 1;      
       lim '''(s) s/(s^2-1)'''  s-&gt;oo = lim 1 s-&gt;oo  = 1
      
  
       '''L{exp(t)} = 1/(s-1)'''           
       lim exp(t) t -&gt;0                    = 1;      
       lim '''(s) 1/(s-1)''' s-&gt;oo = lim 1 s-&gt;oo = 1
      
  
 Vérifions avec [https://www.wolframalpha.com/ Mathematica] :

{{AutoCat}}</text>
      <sha1>7va3cwb6s0250hdr9nruphieo8kgu1o</sha1>
    </revision>
  </page>
  <page>
    <title>Source code</title>
    <ns>0</ns>
    <id>84513</id>
    <revision>
      <id>772348</id>
      <timestamp>2026-09-17T09:41:18Z</timestamp>
      <contributor>
        <username>~2026-50370-33</username>
        <id>124566</id>
      </contributor>
      <comment>/</comment>
      <origin>772348</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="12" sha1="kqf6d3a0se6qz6m6wpi39caakgdpibc" xml:space="preserve">/source code</text>
      <sha1>kqf6d3a0se6qz6m6wpi39caakgdpibc</sha1>
    </revision>
  </page>
</mediawiki>