TIGRE
TIGRE copied to clipboard
CERN
Conda recipe
I've created a conda recipe for TIGRE. Actually 2 ways of doing it:
- https://github.com/paskino/TIGRE/tree/conda_recipe integrates the recipe in this repo
- https://github.com/paskino/TIGRE-conda will download the TIGRE source from github and patch it to compile
IMHO, it'd be better to integrate into this repo. However, I think we should think of tackling the following:
- currently the compute capability are in a big list and what can be built depends on the actual CUDA SDK at build time. I'd suggest to create different lists for different SDK.
- I forgot what I wanted to say... :D
Let me know what you think.
Hum the problem of course is that CUDA+MSVS+MATLAB are a dangerous number combination.
My current approach is to just make the users tune their install. I guess something like cmake that grabs the libraries etc would make sense, but I am going to be honest here and say that I'd would like to avoid that, from experience from SIRF.... It just has added more problems than it has solved for me.
I may be able to create a couple of them, one for old CUDAs and another one with the most updated CUDA. Which SDK you want me to target for the old one, 8.0?
Of course. In CIL we'd like to have a binary package for TIGRE to be able to install from conda.
I understand your approach. So we may as well do 2. which would allow us to create a binary package from this repo without "polluting" it.
Sounds good! I also agree that its best if I have the conda packages integrated in this repo, but you may need to give me a hand with that because I have no idea what is needed there
This is the whole reason why I created this issue, but I understood you didn't want to do it. I'm fine with both approaches.
With a binary package (I think) one aims a covering 80% of its users.
The difference between TIGRE's repo and my fork is very little and all in setup.py. I think we should try to find 2 settings for high end and low end users which will satisfy the most.
Additionally in CIL we use conda and have a myriad of unittests. You have some tests here but I didn't get them working on my machine as some data was missing.
Regarding CMake, sure its role is not to simplify your life, rather the user's!
Mmmm I think if we find a way to have a couple of options, i.e. latest CUDA vs some old CUDA, that should be fine to have here.
I suspect we may not even need two setup.py, the CUDA SDK version should be available at run-time, so we should be able to just drop whichever flags are needed, as the source is already working for most CUDA/GPUs. Seeing your setup.py, we just need to conditionally concatenate/fill that COMPUTE_CAPABILITY_ARGS variable, that is enough to simply have 1 conda build.
When you say binary package, you mean something else than the conda install?
Sorry, I am being mostly vague because I did not write any of the python-compiling stuff, meaning I have little idea how it works.
Unittests: I have nooone and its terrible! Shame on me! Simply, I am the sole maintainer of TIGRE (well, aside wonderful people making PRs), and my current job contains zero hours of "TIGRE" on it, so all this is my own time. I just don't have the time to write tests.... My current plan to cover it is to do #219. In MATLAB, I have a demo/example of how to use most features of TIGRE. If that runs, its some sort of unit test. Maybe it runs badly, but hey, it runs. I was meant to just try to replicate all those on python, so they double down as documentation and tests, but yeah, one of my large tasks to do in my large list of large tasks ....
Hehe CMake should simplify users life, but my experience is that either you know how to fully configure it and how it works, or it doesn't. Many TIGRE users don't know what "compiling" a software is, I can't even imagine them playing with CMake... I have cumulatively spend over a month of full time work this year uniquely trying to make CMake work, as a user.
@paskino the latest commit https://github.com/CERN/TIGRE/commit/4eca27945c42d8aa0944eca014ce0fdc9d6d8b0d should edit the compiler flags by reading your CUDA version and removing the unsupported ones. I don;t have the hardware to test this properly, but in theory this simplifies the problem, only 1 build needed.
To redistribute compiled binaries though, that will require, as you said, multiple builds, as newer CUDA does not support old GPUs, older CUDA does not support new GPUs.
In the short term we'll use the second approach, https://github.com/paskino/TIGRE-conda but I hope we could eventually integrate it in TIGRE.
Happy to try to add alternative ways of compiling and building TIGRE. if conda and CMake are a thing people want, I guess I'll get flexible 👍
I have no idea how to make them, so please do make a PR, point me out on how I can help, or we can actually have a call or something.