Re: GPU-specific code with no GPU-specific features?
"Andros Fenollosa" <[email protected]> Thu, 30 Jul 2026 15:38:33 +0200
| Newsgroups | gmane.emacs.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Johan, thank you for the correction, you are right and I stated it too loosely. llvmpipe shows the code has no hard dependency on a GPU (it builds and runs without one, yes), and I agree it is mainly useful for testing and debugging (my status); practical hardware acceleration on a modern card does require the nonfree, often signed firmware Richard is concerned about. I don't dispute that, it is fine. I just want to clarify, gently, as we already agreed, that this is a separate fork and will not be included in GNU Emacs. Nothing here is currently under review, so I wouldn't want it to take up more space than necessary in the list. I sincerely appreciate the technical correction. Andros On Thu, Jul 30, 2026, at 07:28, Johan Myréen wrote: >> On nonfree firmware, two points which I hope address the concern. >> >> The GNU/Linux backend does not in fact require a GPU or any >> nonfree firmware. It runs on Mesa, which is free software, and it >> works on Mesa's software rasterizer (llvmpipe), which executes >> entirely on the CPU. > > This answer misses the point. First of all, with llvmpipe you get an emulated GPU, which is slow as hell. Nobody wants that. It may be useful for debugging and tests. Secondly, the "graphics drivers" needed by modern graphics cards that are included in Mesa are free software, and the low level drivers for cards from the "big three" manufacturers are free software too, if you choose your card wisely. > > What Richard is talking about is the non-free firmware that has to be loaded into the graphics card to be reasonably usable, unlocking hardware acceleration, and this applies to all modern cards from Nvidia, AMD, and Intel too. The firmware is often also digitally signed, and the signature is checked by the card. This means a clean-room implementation of the firmware based on reverse engineering the hardware is not possible. >