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.
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.
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.
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!
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.