Re: GPU-specific code with no GPU-specific features?

Hello Richard,

On "atlas texture": Tomás already explained it well (thanks!), and the
usual term is indeed "texture atlas", my wording was backwards. The
only thing I would add is that each character shape is rasterized once
into that shared image and reused from then on, instead of being
re-rasterized on every redraw.

"Pixel-perfect parity, native Retina/@2x rasterization": parity means
the new code produces output identical to the existing renderer; we
verify this by rendering the same screens with both renderers and
comparing the results pixel by pixel. "Retina/@2x" refers to
high-density displays where each logical pixel is backed by four
physical ones; native rasterization means characters are drawn at the
physical resolution, so they are sharp rather than scaled up.

On the feature disparity between macOS and GNU/Linux: there is none
today. The text you quoted described an earlier state of the work.
The GNU/Linux driver (written after this list asked for one) now
supports everything the macOS one does, through the same shared
drawing code: inline video (decoded by GStreamer, which is free
software), the cross-fade effect, cursor effects, and high-DPI
rendering, on X11 and natively on Wayland. The remaining differences
are performance tuning, not features. macOS came first only because it
was the machine in front of me, not by design.

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. Our whole automated test suite runs that way, on
machines with no usable GPU at all. Every feature, video and effects
included, works in that configuration; a hardware GPU only makes it
faster. So no feature of this work is conditioned on installing
nonfree firmware.

For the same reason, there are no planned features that would work
only on computers with GPUs: anything the backend does also runs on
the free software rasterizer.

I will be happy to answer any further questions!

Richard Stallman <[email protected]> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I am sorry it took me so long to respond.
>
>   > Sure, happy to elaborate. The README covers the high level, but
>   > the short answer is: the GPU backend batches all glyphs in a frame
>   > into a single draw call against an atlas texture,
>
> What does "atlas texture" mean?  I have never heard that term.
>
>                                                       which scales
>   > much better with pixel count. On macOS (Metal) we have
>   > pixel-perfect parity with the NS renderer, native Retina/@2x
>   > rasterization,
>
> Could you please explain what that means?
>
>                    smooth buffer cross-fades, and inline video via
>   > direct GPU texture upload.
>
> Does this mean Emacs would support a feature on MacOS that it does
> not support on the GNU system?
>
> This would be a very bad thing to do.  It would be self-defeating!
>
> Our goal is to replace nonfree (therefore unjust) operating systems
> such as MacOS with free operating systems such as GNU/Linux.
> To give better support to a nonfree system than a free system
> would be an own goal.
>
> From reports I have seen, all the modern GPUs require nonfree firmware
> to be installed (it's not preinstalled in the harware).  This means
> that the use of these GPUs implies suffering an injustice.
>
> To have features that work only if the user installs that nonfree
> firmware would also be working against or goal.  We must not
> downgrade freedom-respecting platforms to second-class status!
>
> These are two separate specific moral issues, both of the same form.
>
>                                On GNU/Linux (OpenGL/EGL) the picture
>   > is more nuanced: full-redraw and scrolling are noticeably faster
>   > than Cairo at high resolutions, but typing throughput is still
>   > behind because glyph batching is not yet complete.
>
> It sounds like you've implemented support for some features on
> MacOS but not on GNU/Linux.
>                                                        The longer-term
>   > bet is that having a GPU abstraction layer opens the door to
>   > compositing and effects that are simply not practical in the CPU
>   > path.
>
> Are you looking at features that would work only on computers with
> GPUs?  We would need to judge them as possible distortion of our
> goals.

--

Andros Fenollosa

https://andros.dev/