![]() ![]() |
Nov 16 2009, 06:13 PM
Post
#41
|
|
![]() ![]() ![]() ![]() ![]() Group: Members Posts: 165 Joined: 7-November 07 Member No.: 77,477 Org.: Université de Perpignan |
The above is pure speculation based entirely on the names of the new intrinsics. Come on, guys... Don't tell me you didn't even try to compile with -arch=sm_20 and look at the PTX. ;-) -------------------- |
|
|
|
Nov 16 2009, 10:52 PM
Post
#42
|
|
![]() ![]() Group: Members Posts: 24 Joined: 5-June 07 From: Foster City, CA Member No.: 56,261 Org.: Life Technologies |
What's the expected compatibility between different versions of cuda-gdb and different driver versions? I assumed it was like the toolkit, but when I try to start the 2.3 debugger with the 195.17 driver I get an API version error:
CUDA GDB could not access debug API version 20090511 and is incompatible with the installed CUDA driver. |
|
|
|
Nov 17 2009, 10:49 PM
Post
#43
|
|
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Group: NVIDIA Employees Posts: 2,072 Joined: 3-June 08 From: Santa Clara, CA Member No.: 106,363 Org.: NVIDIA |
What's the expected compatibility between different versions of cuda-gdb and different driver versions? I assumed it was like the toolkit, but when I try to start the 2.3 debugger with the 195.17 driver I get an API version error: CUDA GDB could not access debug API version 20090511 and is incompatible with the installed CUDA driver. cuda-gdb isn't compatible across major driver revisions. I'm not sure if apps compiled with nvcc 2.3 and -g -G will work with cuda-gdb 3.0, either; worth a try, though. |
|
|
|
Nov 18 2009, 11:07 AM
Post
#44
|
|
![]() ![]() ![]() ![]() Group: Members Posts: 89 Joined: 9-November 08 Member No.: 125,244 Org.: OptiTex |
I also have the problem of severe performance degradation when moving to the 195.39 driver (booth with CUDA 2.3 and 3.0), this is on xp 32 bit. on windows 7 i don't see such a performance hit. but it runs slower on 7 any ways ...
|
|
|
|
Nov 18 2009, 12:29 PM
Post
#45
|
|
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Group: Extranet Users Posts: 2,289 Joined: 23-March 07 Member No.: 46,425 Org.: University of Michigan |
I also have the problem of severe performance degradation when moving to the 195.39 driver (booth with CUDA 2.3 and 3.0), this is on xp 32 bit. on windows 7 i don't see such a performance hit. but it runs slower on 7 any ways ... I get no performance degradation on linux 32-bit or on Mac OS X. I haven't tried windows yet, will check tomorrow. |
|
|
|
Nov 18 2009, 08:35 PM
Post
#46
|
|
![]() ![]() ![]() ![]() Group: Members Posts: 78 Joined: 22-June 09 Member No.: 160,462 |
There seems to be a problem with the cublas function cublas_ZGERC.
It generates a lot of print " CUBLAS_ZGERC stub" which is indicating an error. That is the only cublas function doing this. |
|
|
|
Nov 19 2009, 07:21 AM
Post
#47
|
|
![]() ![]() ![]() ![]() Group: Members Posts: 89 Joined: 9-November 08 Member No.: 125,244 Org.: OptiTex |
with driver 195.55 the performance drop i get is around 24% compared to 50% in the 195.33 this is with CUDA 2.3, with CUDA 3.0 there is another drop in performance to around 40%. i will check specific kernel times with the visual profiler. this is still on winxp pro sp3 32bit.
|
|
|
|
Nov 19 2009, 12:28 PM
Post
#48
|
|
![]() ![]() ![]() ![]() Group: Members Posts: 78 Joined: 22-June 09 Member No.: 160,462 |
|
|
|
|
Nov 22 2009, 07:44 AM
Post
#49
|
|
![]() ![]() ![]() ![]() Group: Members Posts: 89 Joined: 9-November 08 Member No.: 125,244 Org.: OptiTex |
it seems that there is some overhead created with the new driver. when i look at the visual proflier the times seem to be identical, but when looking at the times on the cpu they grow substantially.
|
|
|
|
Yesterday, 11:42 AM
Post
#50
|
|
![]() ![]() ![]() ![]() ![]() Group: Members Posts: 145 Joined: 7-November 08 Member No.: 125,063 Org.: Georgia Institue of Technology |
QUOTE (tmurray) CUDA C/C++ kernels are now compiled to standard ELF format Could someone elaborate a little bit about exactly what this means? Does this mean that the native GPU binary format is now based on ELF, or does it mean that NVCC actually produces an ELF object for the CUDA kernels and then uses the native c/c++ compiler to generate another ELF object for the CPU code before linking them both together? It looks to me like nvcc still just does source to source translation to generate an intermediate .cpp file with the device code inlined that is passed directly to the native compiler. This post has been edited by Gregory Diamos: Yesterday, 05:19 PM |
|
|
|
Yesterday, 09:46 PM
Post
#51
|
|
![]() ![]() ![]() ![]() ![]() Group: Members Posts: 174 Joined: 13-December 04 Member No.: 1,673 |
Could someone elaborate a little bit about exactly what this means? Does this mean that the native GPU binary format is now based on ELF, or does it mean that NVCC actually produces an ELF object for the CUDA kernels and then uses the native c/c++ compiler to generate another ELF object for the CPU code before linking them both together? It looks to me like nvcc still just does source to source translation to generate an intermediate .cpp file with the device code inlined that is passed directly to the native compiler. I assumed it was referring to the cubin and fat cubin files, but I'll agree it's quite vague. |
|
|
|
Yesterday, 10:07 PM
Post
#52
|
|
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Group: NVIDIA Employees Posts: 2,072 Joined: 3-June 08 From: Santa Clara, CA Member No.: 106,363 Org.: NVIDIA |
Yeah, compare a cubin from 3.0 with a cubin from pre-3.0. Very different!
|
|
|
|
![]() ![]() |
| Copyright 2008 NVIDIA Corporation. Terms of Use | Legal Info | Privacy Policy | Time is now: 24th November 2009 - 12:50 AM |