Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <YeG8ydoJNWWkGrTb@ls3530> <c48ad8ae-aea5-43fa-882f-dccb90dde9a4@suse.de>
 <87bl0amc6s.fsf@x1.stackframe.org> <20220118103323.4bae3a7d@eldfell>
 <20220118095352.xsb6fqacw4p276c5@sirius.home.kraxel.org> <CAMuHMdWV+-+Jr7HggbfH_GEDcdep4pJLiMG+15jxBvQ91BCS0w@mail.gmail.com>
In-Reply-To: <CAMuHMdWV+-+Jr7HggbfH_GEDcdep4pJLiMG+15jxBvQ91BCS0w@mail.gmail.com>
From:   Daniel Vetter <daniel@ffwll.ch>
Date:   Thu, 20 Jan 2022 12:32:58 +0100
Message-ID: <CAKMK7uEOFg3z2btFERQ5XBQ7hqex6bXCb9X=SdwCjeLfX_SdFw@mail.gmail.com>
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
To:     Geert Uytterhoeven <geert@linux-m68k.org>
Cc:     Gerd Hoffmann <kraxel@redhat.com>,
        Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
        Helge Deller <deller@gmx.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        DRI Development <dri-devel@lists.freedesktop.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Sven Schnelle <svens@stackframe.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Gerd,
>
> On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > > On Mon, 17 Jan 2022 19:47:39 +0100
> > > Sven Schnelle <svens@stackframe.org> wrote:
> > >
> > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > > x11, i measure 22ms. This might be unfair because encoding might be
> > > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > > blitting' point. I think if that would be the case, no-one would care
> > > > about 2D acceleration.
> > >
> > > I think that is an extremely unfair comparison, because a graphical
> > > terminal app is not going to render every line of text streamed to it.
> > > It probably renders only the final view alone if you simply run
> > > 'dmesg', skipping the first 800-900 lines completely.
> >
> > Probably more like "render on every vblank", but yes, unlike fbcon it
> > surely wouldn't render every single character sent to the terminal.
> >
> > Also acceleration on modern hardware is more like "compose window
> > content using the 3d engine" than "use 2d blitter to scroll the window".
> >
> > > Maybe fbcon should do the same when presented with a flood of text,
> > > but I don't know how or why it works like it works.
> >
> > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > doing it synchronously.
>
> Hopefully only the parts of the screen which need a redraw?
>
> Not all displays can be updated that fast. For a "modern" example, see
> https://patchwork.freedesktop.org/series/93070/.

drm does damage tracking throughout the stack, e.g.

https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties

And unlike fbdev, it's explicit (so less overhead since userspace
generally knows what it's drawn) and doesn't rely on page fault
intercepting and fun stuff like that.

Like do people actually know what drm can and cannot do, or would that
take out all the fun?
-Daniel

> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch