I realize this question has been asked before, but, when can it be expected to release an x64 beta driver?
I am trying to evalute this technolgy but the lack of 64bit support would be a deal breaker. The software I work on requires large amounts of data (2D/3D/4D medical imaging).
Is there a beta program I can join? I tried registering through the web site but to no avail? Is there an NDA I can get my hands on?
Thanks,
George
BTW - At a minimum, a time frame for the x64 release would be nice.
Okay 0.9 added 64-bit linux support? Why no 64-bit xp? Is it a academia thing? ;-) Is there any plan in the near future to support x64 xp? (that is me asking ever so politley)
Thanks,
george
BTW- Great job on the latest release. I was able to switch back to my structs with member functions and get it to work. This is great stuff.
At some point in the future 64bit WINXP support will be added, however it will not be in the upcoming release.
Thanks. I think…
In case a perception that there’s not much interest in Windows x64 has led to this and may lead to putting this off further, I just want to registering my disappointment in the lack of Windows x64 support.
Thanks,
– Mike
I would second that. Windows X64 along with the Visual Studio 2005 is a stable and great platform for advanced 64 bit application development and debugging. Having Win X64 version of CUDA would help tremendously, since all the Intel Tools and Microsoft tools work really well on that platform.
Having the 64 bit Linux support for CUDA is a great start, since working on 32 bit platforms was not getting us anywhere on development of applications that use technologies like CUDA, they are all much better suited for 64 bit systems.
Thanks
I would be the third.
My work is about 3D tomography and visualization, 32bit is not enough to deal with the huge data.
Look forward X64 CUDA!
Thanks
Haiquan
I would be the 4th- and I know a 5th too :(
monks
I’m also looking forward for x64 support!!
bump - Still interested
i want the x64 too :P
I also can’t understand why nVidia doesn’t support XP x64.
We’ve got an all than little server farm for our on-the-fly created map graphics for our web services which could for sure take advantage of GPGPU support. To stay compatible to our other Microsoft based servers we’ve chosen XP 64 to manange the 16 GBs of data.
And I’m sure there are hundreds of companies, private people and institutions out there who’ve got the same problem and didn’t or won’t buy Tesla, the 8800 or the upcoming G90 because of missing support.
Taking just 100 companies… and I’m sure it are more… with 50 servers average each, 2 cards per server and 300$ per sold GPU nVidia would make millions of loss just because they seem to don’t take XP 64 serious enough… I absolutely don’t get it.
We’re currently using GF 6900 and 7900 cards in our servers for rendering acceleration and made very good experiences with them and so with nVidia till now. So I hope nVidia will wake up… or hurry… so that we won’t all have to change the boat instead of waiting till 2009.
Michael
I’m would also like to use CUDA and i’m really disappointed to see that nVidia doesn’t support Windows XP 64bit. Is there a certain date when we can expect that the 64bit driver is available?
Thanks,
Tobias
Hi everybody,
is there meanwhile a kind of schedule for a WinXP 64 bit release of CUDA? I’m highly interested in running CUDA on 64 bit Windows.
Best regards,
Christoph
Also the Vista x64 pls
Thanks for all the requests. This does help.
We’re expecting to have XP64 support in CUDA 1.1. Currently planning to release in November.
That’s great news, although I wish it would be sooner than November. This is a long post since I think the information (released here ahead of any other venue) is important.
Manifold Release 8, coming out this month, will be the first GIS package to have built-in use of CUDA for complex computations. This will be available in all Manifold editions from $245 Personal on up. Initial support is for several dozen functions involving raster surfaces. Manifold will automatically detect CUDA-capable cards when installed and will seamlessly run numerous functions within CUDA for faster (at times, astonishingly faster) performance. In the months ahead we will add many more uses for CUDA.
That’s relevant to x64 XP CUDA for several reasons:
GIS is an ideal application for CUDA. Typical raster data sets like images and terrain elevation surfaces are easily gigabytes in size and the sorts of operations one would like to do with such raster data are a perfect use of CUDA and parallel stream processing. Note that with the emergence of image servers being built into GIS (Manifold can use image servers like Virtual Earth, NASA World Wind, Yahoo, TerraServer, Google Earth, OGC WMS, etc.), it is now routine for all users, even individual hobbyists, to be working with data sets over a gigabyte in size. So the demand for CUDA is there throughout GIS.
GIS is a much larger volume software market than anything else being sold today for CUDA, reaching into the tens of millions of users with mainstream software like Manifold. It’s easily one of the biggest single markets for CUDA-capable NVIDIA products. [Folks only familar with legacy, 1990’s GIS might not realize how big the new market has become.]
Manifold has run 64-bit native in x64 Windows for years, since the first Windows x64 betas, and continues to be the only big-time GIS that delivers a native x64 Windows product as well as the only GIS that runs multi-core / multi-processor. Running 64-bit Windows multi-core is the only way to get reliability in Windows and performance required for larger jobs. As a result, many Manifold users have long ago switched to 64-bit Windows operation using lots of RAM and multi-core processors. They will be very happy to hear Manifold can use CUDA but will be shocked to learn that doing so will require a huge step backwards to 32-bit Windows, wasting the investments they have already made in modern, 64-bit hardware and software.
Because of the high feature set and low price, on a unit volume basis Manifold outsells all other GIS packages put together. In certain markets, such as the largest one of Microsoft Office users entering GIS, we outsell the legacy companies by about 100 to 1. Manifold costs only $245, about a factor of 40 less than the legacy products, while delivering profoundly more capability, performance and reliability. For only $395 you can run Manifold Enterprise, which allows thousands of people to simultaneously work with terabyte data sets in enterprise DBMS clusters. This is big software for GIS applications from individual hobbyists up to the largest enterprises. And it is now CUDA-enabled.
I’m not citing those prices as a sales pitch but because NVIDIA folks know exactly what that means for unit volume and the resultant potential for CUDA demand. All of us working with CUDA should be interested in increased unit volumes because we all benefit from economy of scale.
Having an extensive, best-of-breed application that does something genuinely worthwhile with CUDA that’s needed by millions of people, and pricing it at only $245 with CUDA built-in is going to generate a lot more visibility for CUDA than any $24,500 application or any exotic, open-source, scientific application of interest to at most a few thousand people. It will also leave a lot more money in the pockets of customers to load up their machines with multiple 8800GTX cards! Yeah! :-)
However important it may be from a technical perspective, the mass volume opportunity is not a handful of guys buying a systems package from NVIDIA for some one-off Linux application, it’s going to happen just the way it has happened in gaming, from mainstream Windows users for mainstream Windows applications. The only way you get millions of units sold is to millions of people out there buying a couple of 8800GTX cards from newegg.com for use in their hot new quad-core ASUS motherboard, to help make those everyday, garden variety, large volume, mainstream applications like GIS run faster. And setting a good Windows example with an application like Manifold is the way to get other Windows applications to see they need CUDA to be competitive.
Based on reactions from beta testers the biggest demand for CUDA we see in GIS comes from people who are all using 64-bit XP or Vista. No surprises, there, but I was somewhat surprised at the visceral rejection of CUDA when people hear they have to go back to 32-bit Windows to use it. There will be some folks who will dual-boot so they can run 32-bit XP when they want to do something CUDA and then switch back to 64-bit Windows for their regular work, but most people won’t do that because it does not solve the problem of 32-bit Windows being too unreliable in large process settings.
There is also the issue that CUDA is computationally very fast but large jobs involving gigabytes of data are data-access-bound, not computation-bound. It is possible to make CUDA hardware look disappointing if you artificially strangle it with 32-bit Windows.
When gigabytes of data are in play, 64-bit Windows using quad-core processors equipped with lots of RAM will do a very credible job, actually competitive with CUDA in some cases, when running native 64-bit code that is well parallelized for multicore work (as ours is).
Manifold has evolved sophisticated means to get lots of data off disk, through memory and into multiple cores for fast computation. For example, it is the only GIS that in all editions can directly interact with spatial DBMS and sophisticated spatial indices, tiles and pyramids to fetch data as fast as possible for multi-gigabyte data sets, and the only mainstream GIS that can render image libraries or access DBMS storage through multiple cores/threads. We know what it takes to keep all those stream processors fed with data.
32-bit Windows is terribly slow and doesn’t use RAM and gets in the way of using CUDA effectively. Using inexpensive 2GB sticks, even with consumer hardware 64-bit Windows can easily be loaded up with 8 GB of RAM (or more) to provide much faster data access. Our customers already often have 64-bit systems loaded with plenty of RAM so that is their metric and is a real comparison already being made.
The 32-bit limitation means that CUDA today is useful mainly for computationally intensive jobs that are relatively small. That is a disappointment, since usually people want to apply it in computationally intensive jobs that are very large. But with the expectation of future progress to x64 Windows we nonetheless put CUDA support into the new Manifold release.
I could be wrong about this, but I think this is one of those “strike while the iron is hot” deals where you want to make the best impression possible during the initial phase as large numbers of people have their first real opportunity to use CUDA in a real-world, truly mature, mainstream Windows application. The best way to do that is to get rid of the bottleneck of 32-bit Windows so CUDA can be all it can be. We need 64-bit x64 XP CUDA as soon as possible, sooner than November if possible.
I therefore would urge NVIDIA to put a full-court press onto getting 64-bit CUDA support for at least XP x64.
Manifold would be happy to help out at no charge. We’ve ported millions of lines of code into 64-bit Windows and we got our start doing the massively parallel math code for Intel’s supercomputer projects in the '90’s, so our engineering folks are very good at parallel algorithms. Anything we can do to help bring forward 64-bit XP CUDA we’re ready to contribute.
In the meantime, if November is the date that is what we will eagerly anticipate. CUDA is totally paradigm-breaking technology and we are all really excited to be able to use it. Congrats to NVIDIA for kicking off a new wave in computing!
Regards to all,
Dimitri
BUMP…
Yes, i do support this request too. XP64 support is a fig fish that NVidia should manage as soon as possible, and November is too late. It means we won’t be able to distribute solutions before 2008Q1…
Some forum (in linux environment) implies that 64bit support means 64 pointers inside the kernel code. Much slower because it means twice register usages, hence half occupancy. Which is strange because there is (currently) only 1.5GB onboard. So what is needed is 64bit pointers only on the host-side of cudaMemcpy()…
We should at least have beta 64bit toolkit sooner, to test its consequence on kernel code speed, and weather it is worth waiting 6 more months…
The 64-bit pointers in 64-bit mode are so that device and host structures containing pointers are identical and can be memcpy’d to each other. My kernels are only ~2% slower under 64-bit linux compared to 32-bit windows.
CUDA appears to work for me under WinXP x64 (Build 3790 SP2), in that I’ve compiled all of the examples from scratch and all in the Release directory pass their tests.
The simpleGL waves and postProcessGL teapot are both real-time so I guess maybe it is executing on the GPU.
I’m using CUDA release 1.0 and NVIDIA beta driver 163.44 (I do some gaming ;))
Card is a 8800 GTS 640MB.
Here be my bandwidth tests:
Quick Mode
Host to Device Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 1683.6
Quick Mode
Device to Host Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 1635.4
Quick Mode
Device to Device Bandwidth
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 47681.6
&&&& Test PASSED
Press ENTER to exit…
Quick Mode
Host to Device Bandwidth for Pinned memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 3131.5
Quick Mode
Device to Host Bandwidth for Pinned memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 2954.8
Quick Mode
Device to Device Bandwidth
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 47685.0
&&&& Test PASSED
Press ENTER to exit…