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:

On Mon, Mar 06, 2023 at 06:09:22AM -0500, Henry Bent wrote: A PDF of the paper is available here: http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-disp…

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(a)planet.nl> wrote:

On Wed, Mar 8, 2023 at 7:53 AM Paul Ruizendaal <pnr(a)planet.nl> wrote: I wouldn't try to be too rigid in your terms here. The term "workstation" was probably never well-defined; it had more of an intuitive connotation of a machine that was more powerful than something you could get on the consumer market (like a PC or 8-bit microcomputer), but wasn't a minicomputer or mainframe/supercomputer. By the early 90s this was understood to mean a single-user machine in a desktop or deskside form factor with a graphics display, and a more advanced operating system than something you'd get on a consumer-grade machine. But the term probably predated that. Generally, workstations were machines marketed towards science/engineering/technology applications, and so intended for a person doing "work", as opposed to home computing or large scale business data-processing. Would a Tek 4014 connected to a VAX count? Maybe? I mean, bicycles have saddles, but we also put saddles on horses, so sure, in the late 70s or early 80s, why not. By the 1990s, maybe not so much. - Dan C.

On Wed, Mar 8, 2023 at 10:06 AM Paul Ruizendaal <pnr(a)planet.nl> wrote: I don't think it's nonsense. I do think it is reaching a bit to draw an analogy that was probably unconsidered at the time, but that's ok. I think the study of history turns up such things all the time. - Dan C.

On Wed, Mar 8, 2023 at 11:55 AM Theodore Ts'o <tytso(a)mit.edu> wrote: CMU's SPICE proposal was for a 3M machine at under $5K by 1985. But you are right $10-15K was typical in those days. ᐧ

I've always liked the "Workbench" terminology that AT&T used, it summons to mind a more communal environment than the idea of a "workstation" does. The former makes me think of my time in the lab "at the bench" with my coworkers, whereas the latter makes me think of my current remote programming job where my break room chat is limited to the cat. It's a shame we all have multiple timesharing systems in our homes, pockets, etc. these days but a dearth of communal computing environments. That said, it's understandable given how many bad actors there are out there, a computing utility would be a frequent target...curse the crackers for ruining that along with the term hacking.... - Matt G. ------- Original Message ------- On Wednesday, March 8th, 2023 at 9:45 AM, Clem Cole <clemc(a)ccc.com> wrote:

On Wed, Mar 8, 2023, 1:21 PM Larry McVoy <lm(a)mcvoy.com> wrote: You could all create those videos. How to"s The histories Evolution. Working with the Legends of Computer Science Insights into working on the R&D side Give them an insight into the problems you faced and how you approached finding a solution. Teaches critical thinking, how to approach the impossible problem From a personal perspective. The emotional side of great research The eureka moments in your lives. Teach inspire The olde Geezer Geeks Educational Video Series for Young Minds and New Hackers.

On Wed, Mar 8, 2023 at 1:21 PM Larry McVoy <lm(a)mcvoy.com> wrote: Amen bro.. Funny Guy Almes and I were chatting about this last week WRT to some CMU history. I've observed that the theory could be learned in lectures and reading books, but the art is taught to an apprentice by a master - carefully looking over her/his shoulder, trying it yourself, being self-critical of your work, as well as taking advice/critical observations from others -- then little by little learning to appreciate what works. That was all so much easier in a terminal room. Or as I sometimes have said to students: "Hacking is done in the privacy of your office between you and your computer terminal. Programming may start in private, but needs the public transparency of the other eyes and thoughts if you want it to be useful for a long time." ᐧ

I don't know if this is what Rob was getting at, but I've also been thinking about the relative homogenization of the display technologies field in recent years. Massively-parallel vector engines calculating vertices, geometry, tesselation, and pixel color after rasterization are pretty much the only game in town these days. Granted, we're finding new and exciting ways to *use* the data these technologies generate, but put pixels on a surface inside a VR headset, on a flat-panel monitor in front of my face, or on a little bundle of plastic, glass, and silicon in my pocket, and the general behavior is still the same: I'm going to give the card a bunch of vertices and data, it's going to then convert that data into a bunch of parallel jobs that eventually land as individual pixels on my screen. One area I am actually interested to see how it develops though is hologram-type stuff. VR is one thing, you're still creating what is ultimately a 2D image composed of individual samples (pixels) that capture a sampling of the state of a hypothetical 3D environment maintained in your application. With AR, you're a little closer, basing depth on the physical environment around you, but I wouldn't be surprised if that same depth is still just put in a depth buffer, pixels are masked accordingly, and the application pastes a 2D rasterized image of the content over the camera display every 1/60th of a second (or whatever absurd refresh rates we're using now.) However, a hologram must maintain the concept of 3D space, at least well enough that if multiple objects were projected, they wouldn't simply disappear from view because one was "behind" another from just one viewpoint, the way the painters algorithm for most depth culling in 3D stuff works. Although I guess I just answered my own quandary, that one would just disable depth culling and display the results before the rasterizer, but still, there's implications beyond just sample this 3D "scene" into a 2D matrix of pixels. Another area that I wish there was more development in, but it's probably too late, is 2D acceleration ala 80's arcade hardware. Galaxian is allegedly the first, at least as held in lore, to provide a chip in which the scrolling background was based on a constantly updating coordinate into a scrollplane and the individual moving graphics were implemented as hardware sprites. I haven't researched much further back on scrollplane 2D acceleration, but I personally see it as still a very valid and useful technology, one that has been overlooked in the wake of 3D graphics and GPUs. Given that many, many computer users don't really tax the 3D capabilities of their machine, they'd probably benefit from the lower costs and complexity involved with accelerating the movement of windows and visual content via this kind of hardware instead of GPUs based largely on vertex arrays. Granted, I don't know how a modern windowing system leverages GPU technology to provide for window acceleration, but if it's using vertex arrays and that sort of thing, that's potentially a lot of extra processing of flat geometric stuff into vertices to feed a GPU, then in the GPU back into pixels, when the 2D graphics already exist and could easily be moved around by coordinate using a scrolling/spriting chip. Granted the "thesis" on my thoughts on 2D scrolling vs GPU efficiency is half-baked, it's something I think about every so often. Anywho, not sure if that's what you meant by things seeming to have rusted a bit, but that's my general line of thought when the state of graphics/display technology comes up. Anything that is just another variation on putting a buffer of vertex properties on a 2k+-core vector engine to spit out a bunch of pixels isn't really pushing into new territory. I don't care how many more triangles it can do nor how many of those pixels there are, and certainly not how close those pixels are to my eyeballs, it's still the same technology just keeping up with Moore's Law. That all said, GPGPU on the other hand is such an interesting field and I hope to learn more in the coming years and start working compute shading into projects in earnest... - Matt G. ------- Original Message ------- On Monday, March 6th, 2023 at 2:47 PM, Paul Ruizendaal via TUHS <tuhs(a)tuhs.org> wrote:

On 3/6/23 12:51 AM, Paul Ruizendaal via TUHS wrote: /dev/fb was a basic device-independent interface that indirected to the hardware that was actually installed for operations like open(), ioctl(), and mmap(). Through those the window systems figured out what they were actually working with. The (4S) man pages had entries for each of the frame buffers and graphics processors if you're able to find them. Sunview did have some kernel support but /dev/fb and the support of mmap() were more generic and used by the non-kernel parts of the window systems (as well as diagnostics). Sun had quite a collection of frame buffers through the years, including oscillating usage of graphics accelerators that might be viewed as wobbles in the wheel rather than true rotation per Sutherland's paper. (Cultural note: the Computer History Museum published a 2-part oral history with Ivan Sutherland, and its home page currently features the interviews. The first part can be found at https://youtu.be/Bjr7qLeyvlw. Each part is several hours long.) On 3/6/23 12:51 AM, Paul Ruizendaal via TUHS wrote: mmap() was in SunOS starting (I believe) with the BSD-derived SunOS 1.x. Prior to 4.0 it could be used with character devices that supported being mapped into an address space: frame buffers, graphics accelerators, and the bus address spaces of VME or Multibus being possible sources. There might have been others that I'm not recalling now. The implementation had a number of restrictions from the BSD specification. All mappings had to be MAP_SHARED. The caller had to specify (page-aligned) addresses within its data segment as the process address space had the traditional text, data, and stack segments vs. being available as a vector of pages.

On Wed, Mar 8, 2023, 4:51 AM Paul Ruizendaal via TUHS <tuhs(a)tuhs.org> wrote: Mapping /dev/mem was good enough for SVGA cards. No surprise there: just be lazy. Warner