Thanks for your detailed analysis!
My answer was about why the work would not end up in librustzcash.
I’m not sure I understand:
since the crate has a dependency on it.
Do you mean it doesn’t use the derive macro or that the dependency is unnecessary?
It doesn’t use the derive macro. All of our curve crates have their own finite field implementations. The ff dependency is most definitely necessary for its traits!
As I said above, what I anticipate would be the cleanest integration, is that any general finite field GPU logic could potentially live in the ff crate (behind a feature flag). Having looked at the Filecoin crates, it seems like the ec-gpu traits might be what get leveraged in that generic code, and then the concrete OpenCL logic would be generated in the individual curve crates (maybe via ec-cpu-gen, maybe via another mobile-specific backend).
This is hard for a layperson to follow. @hanh, how does this affect your proposal?
It is aligned with the proposal, i.e. the code would not be pushed into librustzcash directly.
Hi @hanh any new on gpu accelerating pasta ?
The proposal was for Sapling (Orchard was not released at the time).
It wasn’t accepted.
I ended up doing it later on jubjub (everything needed for trial decryption). afair, on desktop with cuda and a rtx, it was 1000x faster but on mobile it wasn’t worth it.
But it seems that there’s lots of Hardware out there for ethereum mining or some older Hardware that might be useful I’m looking at the kimchi library from Mina and wondering if we can speed it up