Guidance Wanted : Processor x Consumer Strangling GPU buffer ring hypotesis

Logos
, ,
1

Hi, I’m posting at Logos, but so far I’m only sure I can use the messaging ( Waku ) and this is an ask for guidance / discussion. ( I read the updates, the migration and all, but I’m not experienced with the protocol).

My knowledge on crypto developing stops at building dapps, basically on the front-end part.

I’m developing a protocol for shared GPU ring buffering to rendering ~50ns delay, 200ms latency tolerable graphics.

In terms of transport I’m locked with messages (waku) with TCP or QUIC.

But I’m curions / intrigued if it makes any sense implementing a SPSC buffer entirely over logos.

SPSC composed of :

Consumer running in the client that basically does nothing, runs video, tackles transport, handles keys

Server that does the proof of service and clusters the GPU, memory and akins. (In the theory, surely this becomes 1000 things running full logos).

I can only but understand the concepts of zks rollups and etc, but I think spending like who knows how much time studying might be easier just asking lol

Engineering speaking it is a leap, I’m sure. Because it is one thing to simple hook a centralized machine with the dma and all, provide the buffers etc.

I have no idea on how to “look/visualize” the concept working into the zkev <> custom drivers and mathematical proofs. How far I have to hook, if I can use cuda, etc.

Also, this One I’m very convinced is a yes, but asking to double check :

Logos - If I were to create an Client over logos that simple put just receives video from the said Server (The single consumer), and kept my backend running in traditional linux gpu interaction, would the logos execution environment work to host the Consumer part? (This one I basically know the answer.)

2

i think there are a few different concepts getting mixed together in the post, which makes it a bit hard to tell what the intended architecture actually is.

the biggest issue imo is the idea of stretching an SPSC/GPU ring buffer abstraction across a distributed network.

a local ring buffer works because producer and consumer have extremely cheap communication, predictable ordering and basically shared-memory semantics. once producer + consumer are on different machines, that abstraction stops being particularly useful. now you have bandwidth limits, latency, jitter, packet loss, reordering, congestion, backpressure, clock sync etc.

at that point this is much closer to a realtime media/data transport problem than a ring buffer problem.

and if the expectation is to actually push rendered frames/video through Logos Messaging, i don’t think that’s realistic for the latency/bandwidth requirements being described here. Messaging has relatively limited bandwidth and significantly higher latency than what you would normally expect for interactive graphics streaming.

i’ve worked with webrtc before and a lot of the problems here are basically the same ones the realtime media stack already has to solve.

imo Logos Messaging + blockchain could make sense for the surrounding control plane: discovery, signalling, auth, payments, proofs/reciepts.

but the actual rendered data probably needs to be pulled over a much more direct path (WebRTC/UDP?), while Logos Messaging handles coordination around that connection.

or maybe i’m still misunderstanding the proposal - op, are you expecting the actual rendered frames to travel through Logos Messaging, or only using Messaging to establish/coordinate the producer-consumer connection?

3

Also, for video, you might UDP-like semantics where reliability is optimistic and passively solved for instead of packets waiting for acknowledgement

4

Waku (Logos Delivery) uses a broadcast model and rate limit (number of messages over time) for several reasons so it’s not realistic to have “tolerable graphics” over delivery (assuming you want to stream).

to transfer a video over Logo, you would need to:

  1. Push the video on Logos Storage
  2. Send the CID over Logos Chat or Logos Delivery
  3. Use the CID to retrieve the video

Not sure I get your architecture as “client” and “backend” seem to be used interchangeably.

Both ends can use Logos - either via basecamp (desktop) or core headless (daemon/node).

Does it help?