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 2274326757 for ; Mon, 5 Aug 2024 11:05:17 +0200 (CEST) Received: from srv1.howhill.co.uk ([85.95.36.12]) by 9front; Mon Aug 5 05:03:29 -0400 2024 Received: from [192.168.1.223] (Ellychnia-corrusca.howhill.co.uk [192.168.1.223]) (Authenticated sender: willow) by srv1.howhill.co.uk (Postfix) with ESMTPSA id 840553A04E2D for <9front@9front.org>; Mon, 5 Aug 2024 10:03:26 +0100 (BST) DKIM-Filter: OpenDKIM Filter v2.11.0 srv1.howhill.co.uk 840553A04E2D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=howhill.com; s=default; t=1722848607; bh=3dLEmsXOjlM6WdYPhLbDL7XdwmQkV6InYJuDoV1zp10=; h=Date:Subject:To:References:From:In-Reply-To:From; b=qr04LDhObaGoTi0GlDMBiDTo8N/GDpsnLJUGgy5d4ASQhdfUucVSt+wDyy/RneMUJ idnsLTXmGsj9vqfrBNc8uRKReHdZfZ541PmzJjzfA/uqm26PrWCkaYNGJlWdL2aCnI X9ry/FpjtmzmaqXfYkgC7JHDNg8vVuHUB+nOy36P+y4m4J85JVwVIydxTcveXAwbpn 0Lqmv6BleFCH2suljGm4Hpb6CpvAJGAnqeA/nB7pIpCYbaIID1imUA2lQ20mIKcx6E vustW3BfMqm9re2OOlw2qur0wMT90Khvt13i3KZsMtv8RzvpfqwWh8+0bcGuZ9CCTL cPaIzm6qZ1Vbw== Message-ID: <8e4c02c5-ddf6-4455-8e2c-a0ecb598a05c@howhill.com> Date: Mon, 5 Aug 2024 10:03:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: <7003a121-ae98-4a24-b0dc-778c3b086310@sirjofri.de> Content-Language: en-GB From: Willow Liquorice In-Reply-To: <7003a121-ae98-4a24-b0dc-778c3b086310@sirjofri.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-2.62 / 20.00]; BAYES_HAM(-2.86)[99.39%]; SUBJECT_ENDS_QUESTION(1.00)[]; GENERIC_REPUTATION(-0.67)[-0.67254178592779]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1] X-Rspamd-Queue-Id: 840553A04E2D X-Rspamd-Server: srv1.howhill.co.uk List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: private non-blocking hardware Subject: Re: [9front] Thoughts on Wayland? Reply-To: 9front@9front.org Precedence: bulk I read about gpufs in the latest IWP9 proceedings (once I found it, the Foundation didn't put it in their news section). Exciting stuff! On 05/08/2024 09:52, sirjofri wrote: > 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