UberSignals.jl

Concept for a fast event system, using JIT and GPU acceleration
Popularity
10 Stars
Updated Last
8 Months Ago
Started In
January 2015

HyperSignals

Build Status

Concept for a Signal system, loosely inspired by Reactive.jl

Wanted Features:

  • Inline callback code
  • Transfer entire branches to jitted OpenCL/OpenGL kernels
  • Multithreaded branching
  • Different event sources, like websockets, disc, files, OpenCL-events, IDE-code changes, etc...
  • Different caching methods, for events that are emitted faster than they're being processed
  • Bidirectional signals
  • lazy updates (state changes only get updated when read)

Problems which Hypersignals should make easier

  • creating memory optimal code paths. For example consider loading a video from the hdd, loading it into ram, then transferring it to the GPU to filter it. After the filtering, compress it and send it via a network connection to another client. This should look something like this in Hypersignals:
video = lift(open, "file.mp4") # create a signal from a file
filtered = lift(video) do frame  
  filter!(kernel(:gauss, 4,4), frame)
  hue!(frame, 0.4)
end
compressed = lift(compress, filtered)
lift(compressed) do frame
  sent(socket, frame)
end

This lift should now sent a data stream to socket with this this kind of pseudo code:

video = read_video_from_hdd_into_ram(filepath)
gpu_code = find_gpu_segments(signal) # should recognize, that filter!, hue! 
#and compress is executable on the gpu and can use the same gpu memory.
gpu_kernel = compile(gpu_code)
while !done(video)
  frame = next(video)
  upload_to_gpu(frame)
  frame = execute(gpu_kernel, frame) # shouldn't allocate new memory and reuse both ram and video memory
  sent(socket, frame) # some magic function that serializes the signal and sents it optimally to another client.
end
  • should make it easier to have asynchronous and heterogenous events processed on the GPU and CPU.

First, sketchy sketch of a Scene Graph:

SCeneGraph