7 Mar
2023
7 Mar
'23
4:47 a.m.
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(a)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(a)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(a)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(a)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