From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> 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,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id B107026A31 for ; Mon, 5 Aug 2024 10:34:54 +0200 (CEST) Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Mon Aug 5 04:32:06 -0400 2024 Received: from mimir.eigenstate.org (localhost [127.0.0.1]) by mimir.eigenstate.org (OpenSMTPD) with ESMTP id 35f926a7 for <9front@9front.org>; Mon, 5 Aug 2024 01:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eigenstate.org; h= message-id:to:subject:date:from:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=l8StcVPmP529 vKjAeAvQYRYRoh4=; b=YVLno3LjGaipZeFgmK/PL49H171MtEbjjEjygPMVYg/Z LNJUHPhe0J0rrnjG7tseUjUXOq+Wx9xvNlNzyY21L8gQjx1BgBfxOjC3Kat5cnGq hvlZujSQXm/w1uGAGoQBtRfyRYrr3BXx0R0BqFywdfNfF2onyir+3eNn7ejjpoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eigenstate.org; h=message-id :to:subject:date:from:in-reply-to:mime-version:content-type :content-transfer-encoding; q=dns; s=mail; b=CN1i8OGpIA0HK2bYalT l6IN/lEHCDbX29o/d52MIV/lFdqWaPMi87Lv00K5jgXsxrwS74THICV/xc1M+tyR PHJ+LULrL0zSm2G2YXEFdhxEM4AnNHcfDx8MiYWM7fe/XH0hlMLoOo8pnLB6nUdx uAqGfqKefWMe3X2jN/8Vm600= Received: from chainsaw.dev ( [172.58.27.41]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 346fc1f5 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Mon, 5 Aug 2024 01:32:04 -0700 (PDT) Message-ID: To: 9front@9front.org Date: Mon, 05 Aug 2024 04:29:21 -0400 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: social encrypted ActivityPub enhancement-oriented session optimizer Subject: Re: [9front] Thoughts on Wayland? Reply-To: 9front@9front.org Precedence: bulk shared memory just isn't a very good model for distributed systems. devdraw is more or less what you get if you make a slimmed down cairo the native drawing model, and talk to it over a pipe for rpcs, but your musings are gradually reinventing devdraw :) Quoth Willow Liquorice : > I gave this some more thought, and "just shim Cairo" has a lot of > potential footguns, and it comes down to memory (again). What if you > tried using one of the functions in memory(2) – common to both OSs – on > a piece of memory that is touched by Cairo (and is, therefore, remote). cairo supports many backends; a devdraw backend would not be that difficult; shared memory is not necessary. A good one would be harder, but even so it would not be that bad; devdraw's model is still a reasonable fit for cairo -- there are several missing features, but the model matches. Specifically, off the top of my head, cairo would need: * scaling matrices * antialiasing * gradients as devdraw rpcs, and then cairo could do all of the heavy lifting in devdraw. > On 04/08/2024 22:10, Willow Liquorice wrote: > > It sounds like the "shared memory" concept Wayland uses is the tricky > > bit, then, because you can't put the same RAM stick in two different > > machines. > > > > Though, if I'm understanding pipe(3) correctly, it reads like the right > > tool to talk to the compositor. > > > > Thinking about it, I guess the compositor and the in-use graphics > > resources (hardware, software, data) ought to be resident on the same > > physical system: a "GPU server", by analogy with a CPU server, though > > "composition server" is probably a more accurate term. > > > > Thinking about it even more, if *all* graphics resources, in use or not, > > are resident on the GPU server, you don't have to shove huge fonts or > > textures over the network, just the rendered images (or diffs!) and some > > RPCs to a process resident on the GPU server to get it drawing what you > > want. > > > > How on earth that makes a program that uses Pango+Cairo, or something > > like that, play nicely on 9 I have no idea… more shims for client programs? > > > > I suppose every terminal is, in and of itself, a GPU server. Maybe I'm > > overthinking it. > > > > On 04/08/2024 20:59, Eli Cohen wrote: > >> actually, drawing fast locally (and GPU stuff especially for > >> computation) is definitely a plan 9 concept too and is also being > >> worked on separately from wayland, and possibly on linux... so... plan > >> 9 is an OS for networks that may include plan 9 machines, linux > >> machines, iPhones, etc... it's a "unix made out of a network of > >> computers" not a "network made out of unix computers" > >> > >> On Sun, Aug 4, 2024 at 12:54 PM Eli Cohen wrote: > >>> > >>> always better to be a willow that bends than the strongest oak in a > >>> storm :) > >>> > >>> there's a common misconception that plan 9 is an OS for a computer. > >>> plan 9 is an OS for a network. drawing fast locally is not a plan 9 > >>> concept. plan 9 is a 9P multiplexer. a wayland shim for > >>> linux/mac/bsd/etc that renders to draw somewhere else on the network > >>> would be good and appreciated and a relevant plan 9 concept and > >>> people are working on it... but for a fast local wayland > >>> implementation, that's what linux is, and linux can be and is a part > >>> of plan 9 which is an OS for a network > >>> > >>> On Sun, Aug 4, 2024, 12:46 PM Stuart Morrow > >>> wrote: > >>>> > >>>> How do you share memory over rcpu?