9front - general discussion about 9front
 help / color / mirror / Atom feed
From: hiro <23hiro@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] Thoughts on Wayland?
Date: Mon, 5 Aug 2024 13:47:06 +0200	[thread overview]
Message-ID: <CAFSF3XPj94+hez+ECWk=t4_OKMY-d-2KtQ=se4WB4zHN9exo2Q@mail.gmail.com> (raw)
In-Reply-To: <7003a121-ae98-4a24-b0dc-778c3b086310@sirjofri.de>

> 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 practice.
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 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.

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 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.

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?

  parent reply	other threads:[~2024-08-05 11:48 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-04 19:26 Willow Liquorice
2024-08-04 19:44 ` Stuart Morrow
2024-08-04 19:49   ` Willow Liquorice
2024-08-04 19:54   ` Eli Cohen
2024-08-04 19:59     ` Eli Cohen
2024-08-04 20:04       ` Eli Cohen
2024-08-04 20:05         ` Eli Cohen
2024-08-04 20:09         ` Willow Liquorice
2024-08-04 20:29           ` Eli Cohen
2024-08-04 21:23           ` ori
2024-08-04 21:43             ` ori
2024-08-04 22:00               ` David Leimbach
2024-08-04 22:22                 ` ori
2024-08-04 22:42                   ` David Leimbach
2024-08-04 22:57                     ` ori
2024-08-04 21:10       ` Willow Liquorice
2024-08-04 21:24         ` ori
2024-08-04 21:25         ` Eli Cohen
2024-08-05  8:13         ` Willow Liquorice
2024-08-05  8:29           ` ori
2024-08-05  8:52             ` sirjofri
2024-08-05  8:57               ` Noam Preil
2024-08-05  9:12                 ` sirjofri
2024-08-05 11:51                 ` hiro
2024-08-05  9:03               ` Willow Liquorice
2024-08-05 11:05               ` Shawn Rutledge
2024-08-05 12:01                 ` hiro
2024-08-05 12:26                 ` sirjofri
2024-08-05 11:15               ` David Arnold
2024-08-05 11:47               ` hiro [this message]
2024-08-05 12:35                 ` sirjofri
2024-08-04 20:01     ` Willow Liquorice
2024-08-04 21:23       ` sirjofri
2024-08-04 20:08     ` mkf9
2024-08-04 20:35       ` Willow Liquorice
2024-08-04 20:32 ` Pavel Renev
2024-08-04 21:31 ` ori
2024-08-05  6:09   ` Noam Preil
2024-08-05  8:02     ` hiro
2024-08-05 11:51       ` Shawn Rutledge
2024-08-06 16:37         ` hiro
2024-08-06 17:57           ` sirjofri
2024-08-07  9:27           ` Steve simon
2024-08-07 11:47             ` hiro
2024-08-05 12:54   ` Willow Liquorice
2024-08-05 13:13     ` [9front] Fortune worthy Steve simon
2024-08-05 20:06     ` [9front] Thoughts on Wayland? Jon Sharp
2024-08-06  0:07       ` Eli Cohen
2024-08-06  0:09         ` Eli Cohen
2024-08-06  1:57           ` Michael Misch
2024-08-06 13:01         ` Emil Tomczyk
2024-08-04 22:27 ` Dave MacFarlane
2024-08-05  6:10   ` Noam Preil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFSF3XPj94+hez+ECWk=t4_OKMY-d-2KtQ=se4WB4zHN9exo2Q@mail.gmail.com' \
    --to=23hiro@gmail.com \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).