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,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 5E85B22DF0 for ; Mon, 5 Aug 2024 13:48:43 +0200 (CEST) Received: from mail-oa1-f42.google.com ([209.85.160.42]) by 9front; Mon Aug 5 07:47:19 -0400 2024 Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-268d0979e90so132547fac.3 for <9front@9front.org>; Mon, 05 Aug 2024 04:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722858438; x=1723463238; darn=9front.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=W30Z5ag12GwD/HAYP0NK6vSNsGHqhVd9XWFFsipApYY=; b=WZydLHIFJanHBS3c1N6+vZVGtTbogteC40sHjG6URwRwqxE9OwR84tRwidSH9tUHu+ 6tFZgXAXvbzPKztK266WxuMEYtHOPhJUft7mm9QCYl96IFrHypAg80f+yjxQqJWdI4YC kA7sHFQT0hJ1cECTmz7RcDbFwmO+UGFaqAycn02bSXWCkfVTpWSJYaOWlyOkxLW7zXHl BlJpuSPcXEPGryAdi/3jVRQlBE7r3m+lSrdQ1wskk6wY9tAeYnmsA96UvfCB7dUumFDT GqU21a7/kFMgAQZBYSov3Nb4qNhOO55Gq3tsWoshzl8HX6Hw3ctgiX9AY/kzu4nS9wV2 zCtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722858438; x=1723463238; h=content-transfer-encoding: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=W30Z5ag12GwD/HAYP0NK6vSNsGHqhVd9XWFFsipApYY=; b=c7xeZ7fwUgFM7OXCVP/he9oqorKNQLDeiL04lf74ixmxa+ZLnk69adRn9thcx/Z1Qw SXthtUJKsTEYG4YkozFjEpjF0SrWLSbSt1K8srxiRcXfsxrRCWMS82Oom9ZiRZm7DILE fLhwrkWH0i42IYQt0k3MO9IEGZvbPFcxX47Oj9xrevYmbB3dYfn9DPC/yQpGhOJlWFzY tVNCQJ+hjEXanYD4TcWMGq80EFsKlkFzx6jk3KmafUq/eWo3unV4n/lALqCLXnmZkquo c31/LWbkWNYhJhowc53Y2nYo83Fi0yHDGh0PPQ6jcWBBxhuOR38LQ/aIGBGtnHA2Ycj6 xi8Q== X-Gm-Message-State: AOJu0Yz32KOCH1CJdqo1hmy32yIEZFCfq1/nD9DY9amgRmAYt31U6z6z ypPtH1lJRM5BDu30+ZXugFh79Sf4wIX6PxZ9uJzz8J+dFHFYBaGelIhDNhKKv54DEQw/wQouRRN tm3g0o1PVoult1PwJS5jsXeD2CkCyo0ahFbo= X-Google-Smtp-Source: AGHT+IHrXF06oUnIkcixUafvmwBJKnp9Cn2TElINRt/KoXbb0GPhrgnj7QSlTts/siQgEut9ylIRXrWhrIWlamN88Sk= X-Received: by 2002:a05:6871:338c:b0:25e:44b9:b2ee with SMTP id 586e51a60fabf-26891aa626amr6573152fac.2.1722858438307; Mon, 05 Aug 2024 04:47:18 -0700 (PDT) MIME-Version: 1.0 References: <7003a121-ae98-4a24-b0dc-778c3b086310@sirjofri.de> In-Reply-To: <7003a121-ae98-4a24-b0dc-778c3b086310@sirjofri.de> From: hiro <23hiro@gmail.com> Date: Mon, 5 Aug 2024 13:47:06 +0200 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: GPU configuration out-scaling manager Subject: Re: [9front] Thoughts on Wayland? Reply-To: 9front@9front.org Precedence: bulk > 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. whether you call it upload or synchronization makes no difference in practi= ce. 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. > With complex applications with hungry code and hungry graphics (many prim= itive draws) it would be a win-win: the hungry code gets more time on the c= lient, because the client doesn't have to draw primitives, and you still ge= t 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? > 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 gpuf= s, you have to download the resulting image, and load that into devdraw. Ov= er network, it means a loss of performance, but I'm thinking about some kin= d of coupling, so that some devdraw-images are automatically linked with gp= ufs image buffers. At least on integrated systems like drawterm that should= 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 vs. your optimized -1 roundtrip?