Is there really such a huge difference in the way the compiler functions from version to version, from your usage perspective, to warrant such strong version tie-ins; such a tie also inhibits the usage of Intel and other compilers I assume?
Also, will this be a trend with Visual Studio releases? We tend to upgrade fairly soon after a release (we have SA licences); If Nvidia are always going to be late and playing catch up that will be detremental to commercial developments that need to be cutting edge (which we thought was kind of the idea of utilising CUDA).
I think a lot of people using CUDA do not want to be cutting edge. If a bug is found in your cutting edge compiler, and it means you have to redo large simulations, people will NOT be happy.
I think it is very smart if NVIDIA will wait until the first SP releases before adding support.
Well it comes across as latent primary tool chain support to me and that’s a very bad thing.
Your argument is sound but only from the perspective of your own deliverables cycle. If you have a critical deliverable then you make the choice yourself not to upgrade tools; having that forced upon you by non-availability of a key component cannot be desirable, if Nvidia hold off supporting primary tools then they themselves become the risk. When Visual Studio 2008 reaches a release SP1 then those who have not used it may gain confidence to adopt it knowning it’s had a major update; however, if Nvidia postpone support till the SP1 is released then they themselves are the new un-proven software in the tool chain; it’s much better if tools mature together.
Incidentially, Visual Studio 2008 was a leap in stability compared to Visual Studio 2005 SP1 (which isn’t the usual trend but seems to be something Microsoft are going for with Visual Studio lately) so from that perspective Nvidia are forcing the use of a tool that is known to have bugs that have been addressed in a subsequent release.
Latent support of a primary tool (VS2008) also comes across as Nvidia not being fully invested in supporting the CUDA technology (limited development resources thus having to make compromises); being as the adoption of CUDA involves a certain amount of vendor lock-in (i.e. we can’t switch to ATI/AMD if they produce a better GPU chip as that would involve significant re-development) then they have to demonstrate full commitment to the developers and businesses that basically make the technology fly by using it.
Agreed. And we’re at SP1 now…what’s the deal? -David
It will be supported in the next CUDA release.
I have Visual Studio 2008 Team System… it works great with VC++ 2005 Express Edition…
I just tried it… it works great, I just had to add to the path of VS2005 the directory \Microsoft SDKs where the libraries are and include files for OpenGL…
Hallo, I used VC++2005 until few days ago, then I switched to
VC++ 2008 and I got this discussed ‘compatibility’ problem.
Although I tested the suggested fix (i.e. by telling nvcc to use the old
2005 cl compiler, that luckily enough I did not uninstall…) I still
have a problem, because of some conflicts in '05/'08 included libraries.
So the trick of changing the configuration file for nvcc did not work
for me: finally I had to compile my .cu sources by opening the
command-line shell of VC 2005 and executing the nvcc command
from there. This was ok, but I canot afford this workaround forever,
because my build system is based on make/nmake …
So I hope that a new CUDA release will soon fix this VC2008
compatibility problem…
regards,
Alessandro Tasora
[quote name=‘netllama’ date=‘Jun 17 2008, 03:18 PM’]
We are currently tentatively planning to add VC9 support in the next CUDA release after 2.0. The timeframe of that release is currently not solid enough to provide an estimate.
############################################
Netllama, I just wanted to add my 2 cents and to re-emphasize the urgency of support for 2008. Undoubtedly there are many users like me who are stuck with version 1.0 of CUDA because it is the only version of CUDA that integrates well with VS 2008 (yet unsupported officially).
We are unable to move to higher end series of boards because they are not supported in CUDA above version 1.0.
Initially support for Visual Studio 2008 was tied to SP1. Well, at the time we believed it, waited patiently and adjusted our plans accordingly. Now the timeframe is redefined as “not solid enough” which sounds more like “don’t expect it in the foreseeable future”.
Well, please pass my message of frustration to those at NVidia who are in the position to make the plans more concrete and share them with the anxious customers.
Thanks for your understanding and help.
Once VS2008 SP1 officially came out, we could start working on it. Of course it’s not going to come out at exactly the same time as SP1.
With that said, a CUDA version that supports VS2008 should be out before the end of the year, and hopefully significantly before that.
I have to add my voice to this, “before the end of the year” is not going to cut it, my entire firm is presently moving into VS team system, based on vs 2008, my current montecarlo project that i have to add GPU support to, is already converted to 2008, and what i am seeing is i will have to roll the project backwards to be able to use cuda.
not good, i agree wholeheartedly with Johngla.
I was just wonderining if there might be any news on the VS 2008 compatibility issue?
Cuda 2.1 will be compatible. The beta will be out soon as far as can be read on the forums (I guess later this month)
It is out now.