Can you elucidate the distinctions between Nile and Gezira? Based on the (undocumented) code, I guess that Nile is more of a process model (queues, heaps, threads) and Gezira is more of the rendering. In that case, it may be Gezira I was thinking would compile well to shaders on a GPU.
OpenCL is certainly one approach to leveraging a GPGPU to a reasonable degree. Might be worth pursuing that route. But I've been surprised what can be done with just the rendering pipelines. Pure functional graphics convert to shaders + uniforms quite well. Regards, Dave On Tue, Nov 8, 2011 at 3:38 PM, Dan Amelang <[email protected]>wrote: > Hi David, > > On Tue, Nov 8, 2011 at 12:09 PM, David Barbour <[email protected]> > wrote: > > I would like to see dedicated papers or links on Gezira and Nile - > enough to > > re-implement them in another language. > > I see you've already been given links to the code in the github > repositories, so there's that. Unfortunately, a lot of code with > almost zero-documentation isn't too helpful, and I don't have any > papers I can point you to. > > Reimplementing Nile is tough, as all we have right now is the > OMeta-based compiler. And that compiler doesn't document the language > too well because the compiler has a lot of left-over cruft from early > prototyping. And several intended language features weren't > implemented in that compiler. > > I'm slowly working on a new, Maru-based Nile compiler. The parsing is > complete, and I'm working on the type inference phase now. > Unfortunately, I only have about a day a week to work on it, and I'm > still learning my way around Maru, so the going is slow. > > That said, you can ask me specific questions here about Nile or Gezira > and I will try to answer them. > > > I expect techniques as used in Vertigo [1] or GPipe [2] could put Nile > > directly on a GPU, via pixel and geometry shaders. > > I'd go the OpenCL route, as it is more general than OpenGL. > Regardless, the main difficultly is that Nile provides a different > model of computation than the GPU does. Only a subset of Nile programs > would be both possible and efficient to execute on a GPU. And this is > assuming that the data set is large enough to make the transfer > to/from the GPU worth it. > > That said, one could write a Nile-to-OpenCL compiler that statically > detects the parts of the program that might benefit from GPU > execution, and compiles just those parts. I've thought about how to go > about this quite a bit. But I need to finish my dissertation first. > > > This would be a far > > better proof-of-concept, IMO, than relying on user threads across 40 > cores > > to get a 30x speedup. > > Depends on what concept you're trying to prove :) Our main focus with > STEPS is expressive software systems. The parallelism proof-of-concept > was only to demonstrate that Nile's model of computation allows for > parallel execution, nothing more. > > Regards, > > Dan > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
