Open soufianekhiat opened 3 years ago
@soufianekhiat this proposal makes a lot of sense as a future development goal. When we created proximal it was envisioned more as an exploratory toolbox, and so the dependency on Python is there to make it easy to try out different approaches. But a more "production" use case would be very interesting as well.
@SteveDiamond revisiting the proposal 1 year later, may I suggest changing the issue heading from "Component Level Specification" to "Generating halide-optimized routine from K.fwd and K.adj" ?
Here, K means the Proximal generated mapping z = K x
. Feel free to paraphrase the title so it makes sense.
The first impression is that the mapping K
, being a CompGraph
, contains subgraphs that cannot be converted into halide code. So, the CompGraph
will need to have graph query and manipulation algorithms to fuse individual halide-friendly sub-graphs into the corresponding (single) node.
I see that these graph algorithms, in proximal.utils.cuda_codegen.CudaSubgraph
, are already implemented and bundled with pycuda_codegen
. Is there a possibility to turn the code into a base class? So that both pycuda_codegen
and halide_codegen
can derive from the base class?
Otherwise, it sound too much code bloat to me.
Another idea: call external library Networkx
to create, query, and manipulate our CompGraph
. How much effort is required?
Post PR #65 update:
This issue is regarding how to modify proximal
to implement the following code, namely K.halide_forward_graph.gen_code()
and K.halide_adjoint_graph.gen_code()
.
Fork from other discussion: Component level specification
I suggest that we fork out a separate Github issue to discuss this. @jrk and @SteveDiamond can chime in as well.
My first thought is that ProxImaL, just like FlexISP, generates a cyclic compute graph. The lack of compute cycles in Halide is a fundamental strength to customize the compute schedule (or weakness in your use-case?).
As the authors suggested in the original article, I think the ProxImaL project can still grow by
proximal.linops.*
nodes in theproximal.CompGraph
into a single Halide pipeline; andBut eventually the Halide-generate code will have to hand back control to the ADMM
while
-loop to complete the "cycle". Whether thewhile
-loop has to be coded in C++ or to remain in Python, I do not know.Originally posted by @antonysigma in https://github.com/comp-imaging/ProxImaL/issues/57#issuecomment-811969044