The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Rob Pike <robpike@gmail.com>
To: Paul Ruizendaal <pnr@planet.nl>
Cc: "tuhs@tuhs.org" <tuhs@tuhs.org>
Subject: [TUHS] Re: Origins of the frame buffer device
Date: Tue, 7 Mar 2023 10:10:11 +1100	[thread overview]
Message-ID: <CAKzdPgw0fx7Fr=1fkTWv4pPQeDtN9pF7U_a9788HMmXEW7Vnjw@mail.gmail.com> (raw)
In-Reply-To: <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl>

[-- Attachment #1: Type: text/plain, Size: 5189 bytes --]

Through the 1970s and 1980s, there was a continuous invention in how
graphics, computing, and software interacted. With the dominance of the PC
and the VGA card, we now have a largely fixed architecture for graphics in
personal computers. There is some playing around with the software model,
but basically we have a powerful, privately managed external "card" that
does the graphics, and we talk to it with one particular mechanism. During
my work on Plan 9, it got harder over time to try new things because the
list of ways to talk to the card was shrinking, and other than the blessed
ones, slower and slower.

For example, a shared-memory frame buffer, which I interpret as the
mechanism that started this conversation, is now a historical artifact.
Back when, it was a thing to play with.

 As observed by many others, there is far more grunt today in the graphics
card than the CPU, which in Sutherland's timeline would mean it was time to
push that power back to the CPU. But no.

Not a value judgement, just an observation. The wheel has stopped turning,
mostly.

-rob


On Tue, Mar 7, 2023 at 9:47 AM Paul Ruizendaal <pnr@planet.nl> wrote:

> I had read that paper and I have just read it again. I am not sure I
> understand the point you are making.
>
> My take away from the paper -- reading beyond its 1969 vista -- was that
> it made two points:
>
> 1. We put ever more compute power behind our displays
>
> 2. The compute power tends to grow by first adding special purpose
> hardware for some core tasks, that then develops into a generic processor
> and the process repeats
>
> From this one could imply a third point: we always tend to want displays
> that are at the high end of what is economically feasible, even if that
> requires an architectural wart.
>
> More narrowly it concludes that the compute power behind the display is
> better organised as being general to the system than to be dedicated to the
> display.
>
> The wikipedia page with a history of GPU’s since 1970 (
> https://en.wikipedia.org/wiki/Graphics_processing_unit) shows the wheel
> rolling decade after decade.
>
> However, the above observations are probably not what you wanted to direct
> my attention to ...
>
>
>
> > On 6 Mar 2023, at 09:57, Rob Pike <robpike@gmail.com> wrote:
> >
> > I would think you have read Sutherland's "wheel of reincarnation" paper,
> but if you haven't, please do. What fascinates me today is that it seems
> for about a decade now the bearings on that wheel have rusted solid, and no
> one seems interested in lubricating them to get it going again.
> >
> > -rob
> >
> >
> > On Mon, Mar 6, 2023 at 7:52 PM Paul Ruizendaal via TUHS <tuhs@tuhs.org>
> wrote:
> > Thanks for this.
> >
> > My question was unclear: I wasn't thinking of the hardware, but of the
> software abstraction, i.e. the device files living in /dev
> >
> > I’ve now read through SunOS man pages and it would seem that the /dev/fb
> file was indeed similar to /dev/fbdev on Linux 15 years later. Not quite
> the same though, as initially it seems to have been tied to the kernel part
> of the SunWindows software. My understanding of the latter is still limited
> though. The later Linux usage is designed around mmap() and I am not sure
> when that arrived in SunOS (the mmap call exists in the manpages of 4.2BSD,
> but was not implemented at that time). Maybe at the time of the Sun-1 and
> Sun-2 it worked differently.
> >
> > The frame buffer hardware is exposed differently in Plan9. Here there
> are device files (initially /dev/bit/screen and /dev/bit/bitblt) but these
> are not designed around mmap(), which does not exist on Plan9 by design. It
> later develops into the /dev/draw/... files. However, my understanding of
> graphics in Plan9 is also still limited.
> >
> > All in all, finding a conceptually clean but still performant way to
> expose the frame buffer (and acceleration) hardware seems to have been a
> hard problem. Arguably it still is.
> >
> >
> >
> > > On 5 Mar 2023, at 19:25, Kenneth Goodwin <kennethgoodwin56@gmail.com>
> wrote:
> > >
> > > The first frame buffers from Evans and Sutherland were at University
> of Utah, DOD SITES and NYIT CGL as I recall.
> > >
> > > Circa 1974 to 1978.
> > >
> > > They were 19 inch RETMA racks.
> > > Took three to get decent RGB.
> > >
> > > 8 bits per pixel per FB.
> > >
> > > On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS <tuhs@tuhs.org>
> wrote:
> > > I am confused on the history of the frame buffer device.
> > >
> > > On Linux, it seems that /dev/fbdev originated in 1999 from work done
> by  Martin Schaller and  Geert Uytterhoeven (and some input from Fabrice
> Bellard?).
> > >
> > > However, it would seem at first glance that early SunOS also had a
> frame buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in
> nature (a character device that could be mmap’ed to give access to the
> hardware frame buffer, and ioctl’s to probe and configure the hardware). Is
> that correct, or were these entirely different in nature?
> > >
> > > Paul
> > >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 6754 bytes --]

  reply	other threads:[~2023-03-06 23:10 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-05 15:01 [TUHS] " Paul Ruizendaal via TUHS
2023-03-05 17:29 ` [TUHS] " Grant Taylor via TUHS
2023-03-05 18:25 ` Kenneth Goodwin
2023-03-06  8:51   ` Paul Ruizendaal via TUHS
2023-03-06  8:57     ` Rob Pike
2023-03-06 11:09       ` Henry Bent
2023-03-06 16:02         ` Theodore Ts'o
2023-03-06 22:47       ` Paul Ruizendaal via TUHS
2023-03-06 23:10         ` Rob Pike [this message]
2023-03-08 12:53           ` Paul Ruizendaal
2023-03-08 14:23             ` Dan Cross
2023-03-08 15:06               ` Paul Ruizendaal
2023-03-08 19:35                 ` Dan Cross
2023-03-08 16:55               ` Theodore Ts'o
2023-03-08 17:46                 ` Clem Cole
2023-03-08 17:45               ` Clem Cole
2023-03-08 18:12                 ` segaloco via TUHS
2023-03-08 18:21                   ` Larry McVoy
2023-03-08 18:43                     ` Kenneth Goodwin
2023-03-08 18:45                     ` Steffen Nurpmeso
2023-03-08 22:44                     ` Clem Cole
2023-03-09 14:42                 ` Paul Winalski
2023-03-06 23:20         ` segaloco via TUHS
2023-03-07  1:24     ` Kenneth Goodwin
2023-03-08  3:07     ` Rob Gingell
2023-03-08 12:51       ` Paul Ruizendaal via TUHS
2023-03-08 13:05         ` Warner Losh
2023-03-08 13:17         ` Arno Griffioen via TUHS
2023-03-07  1:54 ` Kenneth Goodwin
2023-03-05 18:52 Noel Chiappa
2023-03-05 20:43 ` Rob Pike
2023-03-06 10:43   ` Jonathan Gray
2023-03-07  1:21 ` Kenneth Goodwin
2023-03-08  5:43 ` Lars Brinkhoff
2023-03-09 23:24   ` emanuel stiebler
2023-03-10  1:44     ` Lawrence Stewart
2023-03-06 23:16 Norman Wilson
2023-03-06 23:24 ` Larry McVoy
2023-03-07 12:08   ` arnold
2023-03-07 16:42   ` Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKzdPgw0fx7Fr=1fkTWv4pPQeDtN9pF7U_a9788HMmXEW7Vnjw@mail.gmail.com' \
    --to=robpike@gmail.com \
    --cc=pnr@planet.nl \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).