Vlákno názorů k článku
Do Waylandu možná zamíří podpora zabezpečení výstupu à la HDCP od hu - Prosimvás, rozumíte někdo Linuxovýmu DRI stacku? Od X/W...

Prosimvás, rozumíte někdo Linuxovýmu DRI stacku? Od X/W až po kernel. Nejsem schopen najít ucelenej, up-to-date tutorial:-(

Od čeho je to opensource, když ty zdrojáky nikdo nečte?

Mno všichni si říkají: "To přeci zkontrolovali jiní, to dělat nebudu, je to ztráta času" a nebo tomu jednoduše nerozumí. Přiznejme si že těch programovacích jazyků je poměrně hodně a pořad někdo vymýšlí nové... není asi v silách programátorů, natož pak systémových správců, znát všechny.
Jinak si asi ten easter-egg v manu (viz https://www.root.cz/zpravicky/man-po-pulnoci-pise-gimme-gimme-gimme-jako-vzpominku-na-abba/), těžko vyzvětlíme :)

V kernelu je "DRM modul" (sdílený "DRM core" a modul specifickej pro danej HW: amdgpu/etnaviv/i915/msm­/nouveau/rade­on/v3d/vc4/..­.), kterej přímo spravuje GPU (to znamená multiplexuje přístup, spravuje VRAM a řídí power management). V "DRM core" je sdílená infrastruktura jako správce VRAM (GEM, kterej se hodí spíš pro iGPU a univerzálnější, ale složitější TTM), GPU scheduler, EDID parser atd. Ve skutečnosti poskytuje "DRM" do user space 2 API: DRM ("direct rendering") a KMS ("řízení zobrazení"), protože to jsou 2 různý HW bloky ("graphics engine" a "display controller") a v "embedded" jsou to typicky SIP od různejch výrobců (takže GPU vykresluje do sdílený paměti a řadič displaye to odtud hrne na obrazovku - jako na desktopu s Enduro/Optimus "hybridní grafikou", kde je přímo k výstupum připojený jiný GPU než to, který vykresluje).
Nad nim je "libdrm" knihovna v user space, která zapouzdřuje ioctl(), read() a write() operace s danym /dev/dri/card? rozhranim (volitelně, protože některý DRI drivery dělají potřebný syscally přímo). libdrm má zase sdílenou a pro danej HW specifickou část.
Nad tim sedí "DRI driver" (Mesa) a "DDX" (X.Org), který generujou a buď přímo nebo pomocí libdrm posílají "command stream" (změny "stavu GPU" a "shadery") a data (geometrie, textury, ...). DDX má na starosti "HW akceleraci 2D" vykreslování (GUI a video) pro X11 a DRI zase "3D".
Jako DDX se může používat buď modul specifický pro dané GPU (xserver-xorg-video-*) nebo obecný "Glamor" (vykresluje 2D pomocí OpenGL).
Mesa používá buď "klasický" (i965 a kdysi "legacy") nebo "Gallium" (všechno ostatní) DRI drivery, který mimo jiný kompilujou shadery (často pomocí LLVM) a rozdíl je v tom, kolik vrstev Mesa danej driver implementuje (hlavně pokud jde o správu "stavu GPU") - klasický jsou těsně svázaný s OpenGL a se stavem pracujou víceméně přímo, ale Gallium poskytuje interface zhruba na úrovni Vulkanu a stav dostává "předžvejkanej" od společnýho "state trackeru", specifickýho pro daný API (OpenGL, OpenVG, OpenCL, Direct3D, ...).
Vulkan drivery (anv a radv) jsou sice taky v Mesa, ale nemaj s Galliem nic společnýho.

Vlastně bych za ten "ucelenej a poměrně aktuální přehled" klidně považoval tohle.
Kenneth Graunke letos na XDC představil "Iris" (prototyp Gallium3D driveru pro nejnovější generace Intel iGPU) a celkem hezky popisuje rozdíly mezi "klasickou" a "Gallium3D" architekturou DRI driverů v Mesa.