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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 F12F3225D5 for ; Sun, 4 Aug 2024 23:27:43 +0200 (CEST) Received: from mail-pj1-f52.google.com ([209.85.216.52]) by 9front; Sun Aug 4 17:25:13 -0400 2024 Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-2cb510cd097so7416925a91.1 for <9front@9front.org>; Sun, 04 Aug 2024 14:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722806712; x=1723411512; darn=9front.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=f4rcf3/ow5NL3D3bhHlUC53X7Jf1osbdtU04YpDq1QQ=; b=RW/6N7k0+Mtz4luyG41J2JZ/wM/Ki96CH3MOgjMMlNA+VIqNFlfgk48QvMNbAlMOOR jPgQJc9WRkxnPUQNURgLEHXo6R5mZtuqLfAPkG7OSS1zzHmuIA2rk7INqwYKge/twqNV wvTvbaFouDkbiBYUSt1ySOxEAFM+0ylBE7A33oMV/xOgqmPT47mc15aWLl5VgvzLe4Mf tY3pxx/9fpWHzpmWe6KZjelih9mdBNGbz4H5s0PiMZezwNJGbEhIyP0JrQkkETE9aDCn JMkpwQtnkVqJzlOb3saoJGviqFrKsRgUoE9YeMQzqftQv8Ag4nbcU+H74a4ACQ4m917q MREw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722806712; x=1723411512; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=f4rcf3/ow5NL3D3bhHlUC53X7Jf1osbdtU04YpDq1QQ=; b=RZLby9ZFF196zkLHrpNgcbbNlphszgqZUU7nyVGGlvi4AEy73T4vZyylbIknm0RMo6 N3/PImvXc1cRPYsPOQEBeXQO21Rl/sqZ8dnfpmnagARwyOPQe67qwBaANfSU5NW8E8Oj t9lpR5wRlhAFUqZwH8GZMOMR/rc/ygdfeenI3pruIitUXX0WkJJsjQlXJAaF7PDLkGPg hsVuAHgzd/POtVROjRet4miQo/7CqJcSih8aRKoaaTWuJedkiDR0ulA1dw+WtvlMIi4R eIEiISi6YqHDVpYQUepbJZf0I+gmjZMLpVkreGBslGBa4U815HIWMRYElEhQjeXbNxTH dkXg== X-Gm-Message-State: AOJu0YyDxxzHYl9VZUb+Cj0q1DeOXV7dbzYwcj3Gh6iEjOU7MByrxpax cZJnGCOoZi7VSRFx4urEHl9A395OlqODS5BgtCZ9WY0psNsDsIAnHd+dSOQQRJ0+YkugZ/oXtGv M/FmjPmw4epsG+UXARewnuLPcs/4Ukw== X-Google-Smtp-Source: AGHT+IFGIaauLPsxkpO1dcD/J3JpRg3kUAAEIO7RKUCAXIof/Bgmhrub7kTzJadnkUrKhNNMPXnUWI7J0qlaaAmv8Zg= X-Received: by 2002:a17:90a:7c0c:b0:2c9:719f:b04b with SMTP id 98e67ed59e1d1-2cff9523844mr11565163a91.29.1722806712033; Sun, 04 Aug 2024 14:25:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eli Cohen Date: Sun, 4 Aug 2024 14:25:00 -0700 Message-ID: To: 9front@9front.org Content-Type: multipart/alternative; boundary="000000000000166bf7061ee232c6" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: proven scripting base engine-based configuration-aware backend Subject: Re: [9front] Thoughts on Wayland? Reply-To: 9front@9front.org Precedence: bulk --000000000000166bf7061ee232c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable well, ok, the topic here is kind of that a wayland implementation opens us to more things that use wayland. and this is actually already true on linux... and linux already exists and already does all of this. and Plan 9 networks can (and in my personal opinion, (only speaking for myself though) should) include linux machines. so if a wayland compositor is a draw program at the bottom framebuffer or whatever we're calling it, and draw is at the bottom, then it can interoperate well with Plan 9 draw displays anywhere on the network. or pango, cairo, x11, etc... if they draw to a draw display it can be anywhere on the Plan 9 network. the display and the program don't have to be on the same computer but they can be. for a program that already runs on linux, in my personal opinion, just use linux... but if it draws to draw, that would be awesome for a Plan 9 networ= k On Sun, Aug 4, 2024, 2:15=E2=80=AFPM 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=E2=80=A6 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=E2=80=AFPM 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=E2=80=AFPM Stuart Morrow > wrote: > >>> > >>> How do you share memory over rcpu? > --000000000000166bf7061ee232c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
well, ok, the topic here is kind of that a wayland impleme= ntation opens us to more things that use wayland. and this is actually alre= ady true on linux... and linux already exists and already does all of this.= and Plan 9 networks can (and in my personal opinion, (only speaking for my= self though) should) include linux machines. so if a wayland compositor is = a draw program at the bottom framebuffer or whatever we're calling it, = and draw is at the bottom, then it can interoperate well with Plan 9 draw d= isplays anywhere on the network. or pango, cairo, x11, etc... if they draw = to a draw display it can be anywhere on the Plan 9 network. the display and= the program don't have to be on the same computer but they can be. for= a program that already runs on linux, in my personal opinion, just use lin= ux... but if it draws to draw, that would be awesome for a Plan 9 network

On Sun, Aug 4, 2024, 2:15=E2=80=AFPM Willow Liquorice <willow@howhill.com> wrote:<= br>
It sounds like t= he "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, th= ough
"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 <= br> 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=E2=80=A6 more shims for client p= rograms?

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=E2=80=AFPM Eli Cohen <echoline@gmail.c= om> 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 comp= uter. plan 9 is an OS for a network. drawing fast locally is not a plan 9 c= oncept. plan 9 is a 9P multiplexer. a wayland shim for linux/mac/bsd/etc th= at renders to draw somewhere else on the network would be good and apprecia= ted 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=E2=80=AFPM Stuart Morrow <morro= w.stuart@gmail.com> wrote:
>>>
>>> How do you share memory over rcpu?
--000000000000166bf7061ee232c6--