Can anyone say anything about whether or not 2.3 comes with an updated specification for PTX?
Even a CUDA compiler focused on a single core would be wonderful. All I need is some sort of optimized CPU path! I’m double precision complex, so no need for regular SIMD in my case.
Hell, even a single core x387 CUDA non-vectorizing compiler would be great for me.
Windows driver downloads should be fixed.
That was more or less my reaction. If you want to help, we are trying to build one here: http://code.google.com/p/gpuocelot/
It now works :)
And the updated FFT is definitely faster !
Errr… How do I become a registered developer?
Wowowow. This is very interesting. I noticed this in a forum post a while back, but I thought you guys were going for December or so this year for proof-of-concept like code.
I dug around the site but didn’t see any source.
Is it working in some sort of compatibility mode now? Proof of concept code is exactly what I need. I would normally wait until June 27, but the sooner this gets seen, the better. It doesn’t have to work flawlessly.
I’ve got the beta, but I’m having trouble with the OpenGL examples in the SDK. When compiling them, I get
/usr/bin/ld: cannot find -lGLEW_x86_64
I can see this file in the directory for the 2.2 release (/usr/local/cuda/2.2/sdk/common/lib/linux/libGLEW_x86_64.a), but the 2.3beta doesn’t seem to include it. This is on Fedora 10 (x86_64). Also, the SDK installer neglected to ask where the toolkit was installed, and promptly got confused by the 2.2 installation… could that be related? I changed the CUDA_INSTALL_PATH in common.mk to fix this, but did I miss something else?
Basically where we are right now is a set of tools for doing basic compiler analysis on PTX programs and a fully functional emulator that runs on x86 but takes a 40x or so performance hit. The goal by december is to have a basic back end code generator for x86. There are actually only a few tasks that need to be accomplished to finish a prototype back end compiler, but most of the people working on this are grad students who do internships over the summer, so we can’t work full time on this again until mid august.
All of the code for the analysis modules and emulator is done, but I have to wait until I officially get permission to release it. I filed the paperwork last week and have been told there is a week turn around time on it, so it should be posted very soon.
If you don’t necessarily care about high performance at the start, it would be possible to run everything on the emulator and then switch over to the compiler as soon as it is finished.
tmurray, did you guys end up re-enabling device emulation for C++ in 2.3?
Uhhhh that’s a good question, let me find out. (the answer for 2.3 final is “yes with one interesting caveat” but I’m not sure if that’s in beta)
Can you share the “interesting caveat”?
After updating to 2.3 beta drivers and toolkit, I no longer get the
message when compiling for emudebug.
I do however get a warning…but it looks like nothing major…
Windows XP 32 bit
Visual Studio 2008
Basically the functions are in a special namespace when compiled with -deviceemu, but it doesn’t matter from VS or other GUI-based debuggers (only gdb, I think). Double checking to make sure I know what the namespace actually is…
Ah, sounds good (except for the paperwork part ).
I anxiously await the source release! Great work!
yeah, it’s __cuda_emu::function if you need to break from gdb.
I get many warnings like this:
cuda\include\vector_types.h(180) : warning C4408: anonymous union did not declare any data members
I’m using visual studio 2008
Can this be fixed please ?
I don’t know about Visual Studio, but for gcc there is an option to specify the directory cuda/include as a directory containing system headers. This will make the compiler suppress such warnings. I am pretty sure there is a similar feature for Visual Studio.
I don’t prefer suppressing warnings by default.