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.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26327 invoked from network); 7 Mar 2023 12:08:47 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 7 Mar 2023 12:08:47 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id DD17141203; Tue, 7 Mar 2023 22:08:41 +1000 (AEST) Received: from freefriends.org (freefriends.org [96.88.95.60]) by minnie.tuhs.org (Postfix) with ESMTPS id 7FC0941202 for ; Tue, 7 Mar 2023 22:08:33 +1000 (AEST) X-Envelope-From: arnold@skeeve.com Received: from freefriends.org (freefriends.org [96.88.95.60]) by freefriends.org (8.14.7/8.14.7) with ESMTP id 327C8NaQ026059 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Mar 2023 05:08:23 -0700 Received: (from arnold@localhost) by freefriends.org (8.14.7/8.14.7/Submit) id 327C8Lgw026058; Tue, 7 Mar 2023 05:08:21 -0700 From: arnold@skeeve.com Message-Id: <202303071208.327C8Lgw026058@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: arnold set sender to arnold@skeeve.com using -f Date: Tue, 07 Mar 2023 05:08:21 -0700 To: norman@oclsc.org, lm@mcvoy.com References: <8BD57BAB138946830AF560E17376A63B.for-standards-violators@oclsc.org> <20230306232429.GL5398@mcvoy.com> In-Reply-To: <20230306232429.GL5398@mcvoy.com> User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID-Hash: HLVIS3KBDVTSHTRXSBW3RRS2RCKVFLWU X-Message-ID-Hash: HLVIS3KBDVTSHTRXSBW3RRS2RCKVFLWU X-MailFrom: arnold@skeeve.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: Larry McVoy wrote: > It's funny because back in my day those GPUs would have been called vector > processors, at least I think they would. It seems like somewhere along > the way, vector processors became a dirty word but GPUS are fine. > > Color me confused. I think vector processing is used for things like for (i = 0; i < SOME_CONSTANT; i++) a[i] = b[i] + c[i] that is, vectoring general purpose code. GPUS are pretty specialized SIMD machines which sort of happen to be useful for certain kinds of parallelizable general computations, like password cracking. Today there are both standardized and proprietary ways of programming them. > About the only reason I can see to keep things divided between the CPU > and the GPU is battery power, or power consumption in general. From > what little I know, it seems like GPUs are pretty power thirsty so > maybe they keep them as optional devices so people who don't need them > don't pay the power budget. > > But even that seems suspect, I would think they could put some logic > in there that just doesn't feed power to the GPU if you aren't using > it but maybe that's harder than I think. You're on target, not just in the GPU world but also in the CPU world. Modern Intel CPUS have a lot of circuits for turning power consumption up and down dynamically. Modern-day CPU development is much harder than we software types generally realize. I worked at Intel as a software guy (bad juju there, let me tell you!) and learned a lot about it, from the outside. For a given x86 microarchitecture, from planning until it's in the box in the store is like a 5+ year journey. These days maybe even more, as I left Intel 7.5 years ago. Arnold