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 906D121183 for ; Mon, 5 Aug 2024 14:40:11 +0200 (CEST) Received: from sirjofri.de ([5.45.105.127]) by 9front; Mon Aug 5 08:35:54 -0400 2024 Received: from dummy.faircode.eu ([31.16.254.19]) by sirjofri.de; Mon Aug 5 14:35:51 +0200 2024 Date: Mon, 5 Aug 2024 14:35:49 +0200 (GMT+02:00) From: sirjofri To: 9front@9front.org Message-ID: <62544097-939d-431b-b344-ba45f7d28ae1@sirjofri.de> In-Reply-To: References: <7003a121-ae98-4a24-b0dc-778c3b086310@sirjofri.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: <62544097-939d-431b-b344-ba45f7d28ae1@sirjofri.de> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: compliant encrypted SVG cloud realtime database Subject: Re: [9front] Thoughts on Wayland? Reply-To: 9front@9front.org Precedence: bulk 05.08.2024 13:48:41 hiro <23hiro@gmail.com>: >> That's what I like about GPUs: they have dedicated memory and you have t= o upload manually. No synchronization issues, just what you upload is there= . It's basically a different machine. > > whether you call it upload or synchronization makes no difference in prac= tice. > devdraw also has dedicated memory and you upload images into it > manually. it doesn't only behave as if it was a different machine, but > it is inspired by the difficulties that arose from having to run it on > a dedicated terminal machine. > from the point of view of devdraw and the whole development toolchain > a gpu is a step back, bec. gpus aren't real computers, so the > compilers stop working (i.e. the hardware target differs, just like > the original blit). unlike with other cpu archs it's probably not > worth getting our compilers ported into shaderland. It surely isn't worth it, and I'd also not recommend it. It's a special cas= e. I'd more think about compiling the shaders "from source, on demand", which = is common since the application cannot know which hardware the shader is ru= n on. Gpufs is based around vulkan, so you would compile your high level shader p= rogram to the SPIR-V intermediate language and just upload that to the file= system. This cannot be run, but has to be compiled to the actual architectu= re of the GPU. With that, in an ideal world, a host computer (cpu) runs and exports the gp= ufs and does the compilation of the shaders at this last stage, all bundled= in the gpufs. My plan is to extend drawterm to do that, but it could also = be just a single linux process, or a native plan 9 machine (if we ever get = drivers). >> With complex applications with hungry code and hungry graphics (many pri= mitive 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 g= et fancy graphics, because the hungry primitive drawing routines happens on= the devdraw server side. > > i'm not sure why you care so much. mostly devdraw is a bandwidth > optimization (preloaded textures). > the primitives we have are more than enough to display 2D content > efficiently. what usecase are you unable to implement with the given > technique? I'm a professional game developer working with Unreal. I could tell more, b= ut I think that's enough. >> 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 gpu= fs, you have to download the resulting image, and load that into devdraw. O= ver network, it means a loss of performance, but I'm thinking about some ki= nd of coupling, so that some devdraw-images are automatically linked with g= pufs image buffers. At least on integrated systems like drawterm that shoul= d be possible. Still not perfect, but better than network round-trips. > > what are the ratios here? current perceived number of roundtrips for > example graphical interaction, vs. theoretical minimum number of > roundtrips=C2=A0 vs. your optimized -1 roundtrip? Since this is early research, I don't have numbers. In the end, it can be a= ll or nothing. As long as I'm unable to profile it, I can only speculate an= d say that there could be issues. In a perfect world, the CPU sees an address and the GPU already knows the d= ata, but that's magic, not engineering. sirjofri