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.0 required=5.0 tests=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 6EFAA28A59 for ; Mon, 5 Aug 2024 10:55:07 +0200 (CEST) Received: from sirjofri.de ([5.45.105.127]) by 9front; Mon Aug 5 04:53:05 -0400 2024 Received: from dummy.faircode.eu ([31.16.254.19]) by sirjofri.de; Mon Aug 5 10:53:01 +0200 2024 Date: Mon, 5 Aug 2024 10:52:58 +0200 (GMT+02:00) From: sirjofri To: 9front@9front.org Message-ID: <7003a121-ae98-4a24-b0dc-778c3b086310@sirjofri.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Correlation-ID: <7003a121-ae98-4a24-b0dc-778c3b086310@sirjofri.de> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: stable just-in-time cloud Subject: Re: [9front] Thoughts on Wayland? Reply-To: 9front@9front.org Precedence: bulk 05.08.2024 10:34:45 ori@eigenstate.org: > 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 :) That's what I like about GPUs: they have dedicated memory and you have to upload manually. No synchronization issues, just what you upload is there. It's basically a different machine. Also, the design is extremely similar to devdraw, just that you can upload programs and arbitrary data. Imagine all your graphics routines are executed on the devdraw server side, and you just kick off those programs from the client. That would mean fluent animations with many frames, and the cpu that runs the client application can just relax. With complex applications with hungry code and hungry graphics (many primitive draws) it would be a win-win: the hungry code gets more time on the client, because the client doesn't have to draw primitives, and you still get fancy graphics, because the hungry primitive drawing routines happens on the devdraw server side. My current plan for gpufs needs another round trip yet, because it doesn't integrate with devdraw at all. You'd have to kick off the drawing in gpufs, you have to download the resulting image, and load that into devdraw. Over network, it means a loss of performance, but I'm thinking about some kind of coupling, so that some devdraw-images are automatically linked with gpufs image buffers. At least on integrated systems like drawterm that should be possible. Still not perfect, but better than network round-trips. Anyways, early research. sirjofri