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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 836 invoked from network); 6 Mar 2023 23:20:41 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 6 Mar 2023 23:20:41 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 354D041240; Tue, 7 Mar 2023 09:20:36 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1678144836; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=WSRUEzyTwMMKn8QVxqio48FlDOq5fDpbMb+5w2nSlFg=; b=byS1AlOLnUXdD7c8VRkCniIQcLHxuhuc0KqcxZ/K4D/kmrah/E9270rGkqypEFxY/vI7dN 43eqVxpmlaXAtrbQ7eUosAhvZVLz9gMFEJ/w9V0xf6LUFYjJWakU7fbqTffwMf4AtL46h3 IV8bfkSrYkK7ya6XKs3+YH64dsShbDw= Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by minnie.tuhs.org (Postfix) with ESMTPS id A3BEB41223 for ; Tue, 7 Mar 2023 09:20:31 +1000 (AEST) Date: Mon, 06 Mar 2023 23:20:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1678144828; x=1678404028; bh=WSRUEzyTwMMKn8QVxqio48FlDOq5fDpbMb+5w2nSlFg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=qq6XVboOqTei8n6Q9i/nesz9OaaHTFuaWeOkHAule/TSVzEqsv+sf8V7mymp6ki+h UohoIQFmF+lZbp8p4dnjlIdTS2V9YkhRLY+hl2CCIIOZZrXo+VJCiEunYrsSz1K+ab XyoMLvy8HlVUKnaIJcojclr8clX1AqDjSqrJ0rQhKKe4Uy9adWg8qFia+1ZeD10+qI tu8sWL3kyxQd3TXzvy6UJah0bMhazBlPCtxzBTlLNfipCU8Sqc4tmSr1kVTu+evtN/ XPDznrhQ2eVvkYWbTH+eTQjDkNkR1Vj21LyVNGyh+qFIo8be1reZXe1jBrL6qeoMbb NsAhmoXr6KGaw== To: Paul Ruizendaal Message-ID: <4nTxKwDpHfGp_UnVOUXR9bqHYa4KaRjXKfM_-KyDU-AQFFwNnN8vcsq85l8_bVWwyzKP8dcO6kUikL0t4LXlrGDDrrSVgZrcCTnpEQGfaFA=@protonmail.com> In-Reply-To: <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> Feedback-ID: 35591162:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 24PTPCKLKGNFZ2IUMIB4B3RINAB2ZELJ X-Message-ID-Hash: 24PTPCKLKGNFZ2IUMIB4B3RINAB2ZELJ X-MailFrom: segaloco@protonmail.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: From: segaloco via TUHS Reply-To: segaloco I don't know if this is what Rob was getting at, but I've also been thinkin= g about the relative homogenization of the display technologies field in re= cent years. Massively-parallel vector engines calculating vertices, geomet= ry, tesselation, and pixel color after rasterization are pretty much the on= ly game in town these days. Granted, we're finding new and exciting ways t= o *use* the data these technologies generate, but put pixels on a surface i= nside a VR headset, on a flat-panel monitor in front of my face, or on a li= ttle bundle of plastic, glass, and silicon in my pocket, and the general be= havior is still the same: I'm going to give the card a bunch of vertices an= d 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 2= D 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 pu= t in a depth buffer, pixels are masked accordingly, and the application pas= tes a 2D rasterized image of the content over the camera display every 1/60= th 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 th= at 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 gu= ess I just answered my own quandary, that one would just disable depth cull= ing and display the results before the rasterizer, but still, there's impli= cations 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 t= oo late, is 2D acceleration ala 80's arcade hardware. Galaxian is allegedl= y the first, at least as held in lore, to provide a chip in which the scrol= ling background was based on a constantly updating coordinate into a scroll= plane and the individual moving graphics were implemented as hardware sprit= es. 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 t= hat has been overlooked in the wake of 3D graphics and GPUs. Given that ma= ny, many computer users don't really tax the 3D capabilities of their machi= ne, they'd probably benefit from the lower costs and complexity involved wi= th 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 thin= g, that's potentially a lot of extra processing of flat geometric stuff int= o vertices to feed a GPU, then in the GPU back into pixels, when the 2D gra= phics already exist and could easily be moved around by coordinate using a = scrolling/spriting chip. Granted the "thesis" on my thoughts on 2D scrolli= ng vs GPU efficiency is half-baked, it's something I think about every so o= ften. 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/dis= play technology comes up. Anything that is just another variation on putti= ng 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 c= ertainly 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 com= ing 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 wrote: > I had read that paper and I have just read it again. I am not sure I unde= rstand the point you are making. >=20 > My take away from the paper -- reading beyond its 1969 vista -- was that = it made two points: >=20 > 1. We put ever more compute power behind our displays >=20 > 2. The compute power tends to grow by first adding special purpose hardwa= re for some core tasks, that then develops into a generic processor and the= process repeats >=20 > 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 req= uires an architectural wart. >=20 > More narrowly it concludes that the compute power behind the display is b= etter organised as being general to the system than to be dedicated to the = display. >=20 > 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 decad= e after decade. >=20 > However, the above observations are probably not what you wanted to direc= t my attention to ... >=20 >=20 > > On 6 Mar 2023, at 09:57, Rob Pike robpike@gmail.com wrote: > >=20 > > 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. > >=20 > > -rob > >=20 > > On Mon, Mar 6, 2023 at 7:52 PM Paul Ruizendaal via TUHS tuhs@tuhs.org w= rote: > > Thanks for this. > >=20 > > My question was unclear: I wasn't thinking of the hardware, but of the = software abstraction, i.e. the device files living in /dev > >=20 > > 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. No= t quite the same though, as initially it seems to have been tied to the ker= nel part of the SunWindows software. My understanding of the latter is stil= l 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 o= f 4.2BSD, but was not implemented at that time). Maybe at the time of the S= un-1 and Sun-2 it worked differently. > >=20 > > The frame buffer hardware is exposed differently in Plan9. Here there a= re device files (initially /dev/bit/screen and /dev/bit/bitblt) but these a= re not designed around mmap(), which does not exist on Plan9 by design. It = later develops into the /dev/draw/... files. However, my understanding of g= raphics in Plan9 is also still limited. > >=20 > > All in all, finding a conceptually clean but still performant way to ex= pose the frame buffer (and acceleration) hardware seems to have been a hard= problem. Arguably it still is. > >=20 > > > On 5 Mar 2023, at 19:25, Kenneth Goodwin kennethgoodwin56@gmail.com w= rote: > > >=20 > > > The first frame buffers from Evans and Sutherland were at University = of Utah, DOD SITES and NYIT CGL as I recall. > > >=20 > > > Circa 1974 to 1978. > > >=20 > > > They were 19 inch RETMA racks. > > > Took three to get decent RGB. > > >=20 > > > 8 bits per pixel per FB. > > >=20 > > > 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. > > >=20 > > > On Linux, it seems that /dev/fbdev originated in 1999 from work done = by Martin Schaller and Geert Uytterhoeven (and some input from Fabrice Bell= ard?). > > >=20 > > > However, it would seem at first glance that early SunOS also had a fr= ame buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nat= ure (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 hard= ware). Is that correct, or were these entirely different in nature? > > >=20 > > > Paul