From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31994 invoked from network); 6 Mar 2023 23:10:37 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 6 Mar 2023 23:10:37 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 1E10741213; Tue, 7 Mar 2023 09:10:32 +1000 (AEST) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) by minnie.tuhs.org (Postfix) with ESMTPS id 4ABE54120A for ; Tue, 7 Mar 2023 09:10:24 +1000 (AEST) Received: by mail-vs1-xe30.google.com with SMTP id o2so10744978vss.8 for ; Mon, 06 Mar 2023 15:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678144223; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MdNLw1oPBqPpfPAfJXrjT7jxlm1qW72xKukcWRlnJgA=; b=RooIyM1tWd20aAb++t+3lViL/QJCfMrEpT7ZvBRZKloQKZXYlBGIeUYd3b79XgI7dP gZCJ8vI15qvWdBTQDttShEFnPZX92OCm3ZitRbnsB2Qa8YoSYLSNTSsior+9s/N09Ld0 X3PI16DI4q7Nifw9CCXA9Wke9FIO5blM6s340O35yv8HRUmbj9LIBaBQRT8+WBJC5io5 ep0a+HUni+bGZf97d1wUf8XJ1h89rHFwZIQOIPWnh94kWTWsKvsohXSHvOU1EaAeb1Ph iGiKMZmpXFJhqMYknA+FMDI2OtJ6bZUWVjUNNlsYp+WdCBAAv8fXRBKuonRueP64aog+ McUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678144223; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MdNLw1oPBqPpfPAfJXrjT7jxlm1qW72xKukcWRlnJgA=; b=F/cIg6GBvwSUAm1aM3R10XaeXuwn9H6VwlhS71x2Qx9/Ej9DsjMVwdRPEPi6LGiveT EHTPY7YHwc3MJuTxQ9jemaN3qX+vAUc5FfwxGsUGUBH3mmyb1lZS0Twz5lG1BkQsWfH6 3CwpmaOHcECKeZjFK0yWmXDBCLLYZJDzbAYZbdaxCeIdI58FPEn57kYRbQdVdA7MhowB BTpsAo0R3zvOm0d4tT7WWjpLcPUmiqzMRO0w6U7NmpmCpDiED3rLpGDOH5I6BXH2Zpyg wwr7G/FNO7zIJpb3zQF3hnjBo/SymUJFnNlkwN9a1STsTZ6h5v9niFmu82DKAbS248SK Kq9w== X-Gm-Message-State: AO0yUKXI+Q2wGwrMq/9QApKquG+lZia1oA4HF/sJ7zOciLtRygnyXBfS zAuESE8Hr4mz/K0TU2MZ8Z05ERaDWwCqIW31pCc= X-Google-Smtp-Source: AK7set+50aCJ2D7aeRlFIHbIeBGqMdKzwEHHjxaaty9QNQ/Wuvto0MIkBtNGfmTk9uU7/k8pkSxbQMRsAlqRTi6PrlQ= X-Received: by 2002:a67:72c5:0:b0:402:99ce:1d9f with SMTP id n188-20020a6772c5000000b0040299ce1d9fmr8580161vsc.4.1678144222048; Mon, 06 Mar 2023 15:10:22 -0800 (PST) MIME-Version: 1.0 References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> In-Reply-To: <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> From: Rob Pike Date: Tue, 7 Mar 2023 10:10:11 +1100 Message-ID: To: Paul Ruizendaal Content-Type: multipart/alternative; boundary="0000000000003cb5fb05f643666a" Message-ID-Hash: FJP4XHVCGBXIZHIIESSX6GXV76NHUMMA X-Message-ID-Hash: FJP4XHVCGBXIZHIIESSX6GXV76NHUMMA X-MailFrom: robpike@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "tuhs@tuhs.org" X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Origins of the frame buffer device List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003cb5fb05f643666a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Paul Ruizendaal wrot= e: > 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 t= he > display. > > The wikipedia page with a history of GPU=E2=80=99s 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 direc= t > my attention to ... > > > > > On 6 Mar 2023, at 09:57, Rob Pike 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 > 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=E2=80=99ve now read through SunOS man pages and it would seem that th= e /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 pa= rt > of the SunWindows software. My understanding of the latter is still limit= ed > 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.2BS= D, > 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 thes= e > 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 > 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 > 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=E2=80=99ed to give access t= o the > hardware frame buffer, and ioctl=E2=80=99s to probe and configure the har= dware). Is > that correct, or were these entirely different in nature? > > > > > > Paul > > > > > > > --0000000000003cb5fb05f643666a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 mode= l, but basically we have a powerful, privately managed external "card&= quot; that does the graphics, and we talk to it with one particular mechani= sm. During my work on Plan 9, it got harder over time to try new things bec= ause 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 buf= fer, which I interpret as the mechanism that started this conversation, is = now a historical artifact. Back when, it was a thing to play with.

=
=C2=A0A= s observed by many others, there is far more grunt today in the graphics ca= rd 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, jus= t an observation. The wheel has stopped turning, mostly.

-rob


On T= ue, Mar 7, 2023 at 9:47=E2=80=AFAM Paul Ruizendaal <pnr@planet.nl> wrote:
I had read that paper and I have just read it aga= in. 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 p= rocess repeats

>From this one could imply a third point: we always tend to want displays th= at are at the high end of what is economically feasible, even if that requi= res an architectural wart.

More narrowly it concludes that the compute power behind the display is bet= ter organised as being general to the system than to be dedicated to the di= splay.

The wikipedia page with a history of GPU=E2=80=99s 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 reincarnat= ion" paper, but if you haven't, please do. What fascinates me toda= y is that it seems for about a decade now the bearings on that wheel have r= usted solid, and no one seems interested in lubricating them to get it goin= g 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=E2=80=99ve now read through SunOS man pages and it would seem that t= he /dev/fb file was indeed similar to /dev/fbdev on Linux 15 years later. N= ot quite the same though, as initially it seems to have been tied to the ke= rnel part of the SunWindows software. My understanding of the latter is sti= ll 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 e= xpose the frame buffer (and acceleration) hardware seems to have been a har= d problem. Arguably it still is.
>
>
>
> > On 5 Mar 2023, at 19:25, Kenneth Goodwin <kennethgoodwin56@gmail.com&= gt; wrote:
> >
> > The first frame buffers from Evans and Sutherland were at Univers= ity 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 d= one by=C2=A0 Martin Schaller and=C2=A0 Geert Uytterhoeven (and some input f= rom 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=E2=80=99ed to give access to= the hardware frame buffer, and ioctl=E2=80=99s to probe and configure the = hardware). Is that correct, or were these entirely different in nature?
> >
> > Paul
> >
>

--0000000000003cb5fb05f643666a--