Unity e GNOME3 hanno di recente scelto un approccio molto drastico nei confronti di quelle situazioni in cui gli utenti non abbiano a disposizione un driver video dotato di accelerazione grafica. La prossima release di Ubuntu, Quantal Quetzal, non includerà più la versione di Unity priva del compositing OpenGL, nota come Unity 2D; GNOME Shell già da due release ha introdotto la possibilità di non dover ricorrere al fallback mode anche in assenza di un driver accelerato. Per entrambi la soluzione tecnica è la stessa: LLVMPipe.
Si tratta di un moderno e ultra-ottimizzato software rasterizer, ovvero un driver grafico che espone le funzionalità OpenGL necessarie per il compositing 3D di cui i desktop environment moderni fanno ampio uso, e le esegue sfruttando la potenza di calcolo della CPU, consentendo quindi di eseguire Unity e GNOME Shell col 100% delle funzionalità anche in assenza di supporto 3D da parte della GPU. Una situazione niente affatto rara, specie per chi vuole far girare Linux su un PC o laptop dotato di schede grafiche recentissime.
E KDE? Martin Gräßlin, il principale sviluppatore di KWin, ha sollevato la questione di recente. Le sue conclusioni sono che KDE è soddisfatta con gli attuali metodi di fallback, che consistono nell´uso dell´estensione XRender del server grafico o nella disattivazione completa del compositing. Di conseguenza, non ci sono programmi per implementare il supporto a LLVMPipe in KDE.
Il vantaggio principale che LLVMpipe da agli sviluppatori è quello di non dover mantenere la base di codice relativa ad altri metodi di compositing o all´assenza di esso, ma comunque raggiungere la base di utenti priva di supporto 3D. Girando però completamente sulla CPU, questo significa aver bisogno di hardware particolarmente recente e processori multi-core, e questo solo per un uso tradizionale: LLVMpipe non è una soluzione praticabile per le necessità di gaming.
Il ragionamento di Gräßlin è che in molti dei casi d´uso tipici per un compositing basato su LLVMPipe, come hardware datato, dispositivi embedded per cui non siano disponibili driver, e virtualizzazione, è assai probabile che la potenza di calcolo a disposizione sia comunque troppo bassa per rendere la soluzione decentemente usabile. Negli altri due, relativi ad hardware bleeding-edge e rifiuto all´utilizzo di blob binari, Gräßlin argomenta che non si tratti di niente che non possa essere risolto scegliendo accuratamente l´hardware da acquistare.
Martin ha tuttavia lodato LLVMpipe come strumento di sviluppo: permettendo di usufruire delle funzionalità OpenGL in maniera indipendente dall´hardware costituisce un preziosissimo tool di debug per il desktop Linux.