CUDA wrapper

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
I think I am using winemaker wrong. It does not give me a .res file as the winelib user's guide says I need, and the guide says I should be getting a Makefile.in and configure script. When I try to use it and link to the libcudart.so.2.0 file it acts like the target directory is libcudart.so.2.0

shelnutt@Ubuntu32-L:~/wine/patches/cuda$ winemaker --nosource-fix --dll -Ldir /usr/local/cuda/lib/ -library libcudart.so.2.0
error: the work directory, "libcudart.so.2.0", has already been specified (was "/usr/local/cuda/lib/")

I'm not sure if just the winelib guide is out of date, it says many of the parts are, or if I'm not understanding it right. I've also looked at the man page for  winemaker and I guess I just don't get how to specify which files to link to.


Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
I've spent the whole day reading different things and I'm just not sure why it is creating an empty file. I'm still getting the same error messages even when using winemaker correctly.

shelnutt@Ubuntu32-L:~/wine/patches/cuda$ make
winegcc -shared cuda.dll.spec -mno-cygwin -o cuda.dll.so cudart.o     /usr/local/cuda/lib/libcudart.so.2.0  -lodbc32 -lole32 -loleaut32 -lwinspool -luuid -lcudart
gcc: /usr/local/cuda/lib/libcudart.so.2.0: linker input file unused because linking not done
winebuild: libcudart.so.2-jP21n2.o is an empty file
winegcc: winebuild failed
make: *** [cuda.dll.so] Error 2

Can someone at least point me in the right direction? Google gives me nothing and I can't find anything about this.
 I know the linking part is just saying that there is no need to link in this file.

Now I thought it might be because I don't have a proper .res file as winemaker didn't set it up to build one. I used winebuild
 winebuild --dll -fPIC -o -spec -Ecuda.dll.spec

and now I the -spec file which has some interesting code but I have no clue what to do with it. I think I need to use wrc to compile a .res file but it wants a .res file as input.

My coding is good, now I'm just trying to figure out how to get wine to compile the damn thing.


Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Juan Lang-4
> shelnutt@Ubuntu32-L:~/wine/patches/cuda$ make
> winegcc -shared cuda.dll.spec -mno-cygwin -o cuda.dll.so cudart.o
> /usr/local/cuda/lib/libcudart.so.2.0  -lodbc32 -lole32 -loleaut32 -lwinspool
> -luuid -lcudart
> gcc: /usr/local/cuda/lib/libcudart.so.2.0: linker input file unused because
> linking not done
> winebuild: libcudart.so.2-jP21n2.o is an empty file
> winegcc: winebuild failed
> make: *** [cuda.dll.so] Error 2

Why do you need to link explicitly to libcudart.so.2.0?  Try omitting
that to see what happens.
--Juan


Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
Well at least it compiled, but it isn't working. We are still getting the message that the function isn't implemented.

Initializing Nvidia gpu library
cudaMalloc CUDAStream::Allocate failed feature is not yet implemented


Now both cudamalloc and all four cuda stream's, cudaStreamCreate, Destroy, Query and Synchronize were implemented.
I thought maybe it was because in the spec file I had the cudaStream's as pointers (ptr) so I switched them to long but ti didn't make a difference. Originally the argument was "stream" but I can't get any argument but ptr and long to pass the winegcc for spec files.

http://shelnutt.twomurs.com/patches/cuda/cuda.dll.spec

Does wine need to somehow be made aware of the presence of the cudart.dll.so file? We tried putting it in both the system32 and the lib folder but it seems also that maybe WINE needs to be made aware of it?


Reply | Threaded
Open this post in threaded view
|

RE: CUDA wrapper

Stefan Dösinger-2

Wine links against cudart.dll.so from /usr/lib/ or wherever it is. You don't have to put it in C:\windows\... .

 

You can put a TRACE or ERR into the cudaMalloc(or whatever) function implementation in your code to write a message to check if the functions are properly called. I suspect they are, and that libcudart.so writes those errors. This would then mean that the Windows and Linux cuda libraries are different, and some features are missing in the Linux version. If that is true, the only thing you can do is to contact Nvidia and ask them for help

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Seth Shelnutt
Sent: Wednesday, July 09, 2008 7:23 PM
To: Juan Lang; [hidden email]
Subject: Re: CUDA wrapper

 

Well at least it compiled, but it isn't working. We are still getting the message that the function isn't implemented.

Initializing Nvidia gpu library
cudaMalloc CUDAStream::Allocate failed feature is not yet implemented


Now both cudamalloc and all four cuda stream's, cudaStreamCreate, Destroy, Query and Synchronize were implemented.
I thought maybe it was because in the spec file I had the cudaStream's as pointers (ptr) so I switched them to long but ti didn't make a difference. Originally the argument was "stream" but I can't get any argument but ptr and long to pass the winegcc for spec files.

http://shelnutt.twomurs.com/patches/cuda/cuda.dll.spec

Does wine need to somehow be made aware of the presence of the cudart.dll.so file? We tried putting it in both the system32 and the lib folder but it seems also that maybe WINE needs to be made aware of it?



Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
OK, I've fixed a few mistakes in the .spec file and we are getting further, but I tried debugging the output but I am not sure what it all means.

zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$ winedbg [hidden email]
WineDbg starting on pid 0024
start_process () at /media/md0/wine/wine/dlls/kernel32/process.c:904
0x7b877d02 start_process+0xc2 [/media/md0/wine/wine/dlls/kernel32/process.c:904] in kernel32: movl %esi,0x0(%esp)
904 ExitThread( entry( peb ) );
Wine-dbg>n
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x33f40c,0x00000000), stub!
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf7facaaf
Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling it
Process of pid=0024 has terminated
Wine-dbg>

I believe the key line is Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling it . But what exactly that means I am not sure, I mean I don't know which function it is saying is missing or messed up. Also from the documentation and from the nvidia forums it seems that both libraries are exactly the same, and it is said that there is no difference in writing a program for Linux vs. Windows, but I assume that is minus the direct3d functions, which I know the folding at home program doesn't use.

On Thu, Jul 10, 2008 at 12:01 AM, Stefan Dösinger <[hidden email]> wrote:

Wine links against cudart.dll.so from /usr/lib/ or wherever it is. You don't have to put it in C:\windows\... .

 

You can put a TRACE or ERR into the cudaMalloc(or whatever) function implementation in your code to write a message to check if the functions are properly called. I suspect they are, and that libcudart.so writes those errors. This would then mean that the Windows and Linux cuda libraries are different, and some features are missing in the Linux version. If that is true, the only thing you can do is to contact Nvidia and ask them for help

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Seth Shelnutt
Sent: Wednesday, July 09, 2008 7:23 PM
To: Juan Lang; [hidden email]
Subject: Re: CUDA wrapper

 

Well at least it compiled, but it isn't working. We are still getting the message that the function isn't implemented.



Initializing Nvidia gpu library
cudaMalloc CUDAStream::Allocate failed feature is not yet implemented


Now both cudamalloc and all four cuda stream's, cudaStreamCreate, Destroy, Query and Synchronize were implemented.
I thought maybe it was because in the spec file I had the cudaStream's as pointers (ptr) so I switched them to long but ti didn't make a difference. Originally the argument was "stream" but I can't get any argument but ptr and long to pass the winegcc for spec files.

http://shelnutt.twomurs.com/patches/cuda/cuda.dll.spec

Does wine need to somehow be made aware of the presence of the cudart.dll.so file? We tried putting it in both the system32 and the lib folder but it seems also that maybe WINE needs to be made aware of it?



Reply | Threaded
Open this post in threaded view
|

RE: CUDA wrapper

Stefan Dösinger-2

I have no idea regarding that crash, but from the rest of the log it seems that the app is initializing a d3d device; This means you'll probably have to implement cuda<->d3d communication

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Seth Shelnutt
Sent: Saturday, July 12, 2008 7:52 PM
To: [hidden email]
Subject: Re: CUDA wrapper

 

OK, I've fixed a few mistakes in the .spec file and we are getting further, but I tried debugging the output but I am not sure what it all means.

zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$ winedbg [hidden email]
WineDbg starting on pid 0024
start_process () at /media/md0/wine/wine/dlls/kernel32/process.c:904
0x7b877d02 start_process+0xc2 [/media/md0/wine/wine/dlls/kernel32/process.c:904] in kernel32: movl %esi,0x0(%esp)
904 ExitThread( entry( peb ) );
Wine-dbg>n
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x33f40c,0x00000000), stub!
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf7facaaf
Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling it
Process of pid=0024 has terminated
Wine-dbg>

I believe the key line is Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling it . But what exactly that means I am not sure, I mean I don't know which function it is saying is missing or messed up. Also from the documentation and from the nvidia forums it seems that both libraries are exactly the same, and it is said that there is no difference in writing a program for Linux vs. Windows, but I assume that is minus the direct3d functions, which I know the folding at home program doesn't use.

On Thu, Jul 10, 2008 at 12:01 AM, Stefan Dösinger <[hidden email]> wrote:

Wine links against cudart.dll.so from /usr/lib/ or wherever it is. You don't have to put it in C:\windows\... .

 

You can put a TRACE or ERR into the cudaMalloc(or whatever) function implementation in your code to write a message to check if the functions are properly called. I suspect they are, and that libcudart.so writes those errors. This would then mean that the Windows and Linux cuda libraries are different, and some features are missing in the Linux version. If that is true, the only thing you can do is to contact Nvidia and ask them for help

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Seth Shelnutt
Sent: Wednesday, July 09, 2008 7:23 PM
To: Juan Lang; [hidden email]
Subject: Re: CUDA wrapper

 

Well at least it compiled, but it isn't working. We are still getting the message that the function isn't implemented.



Initializing Nvidia gpu library
cudaMalloc CUDAStream::Allocate failed feature is not yet implemented


Now both cudamalloc and all four cuda stream's, cudaStreamCreate, Destroy, Query and Synchronize were implemented.
I thought maybe it was because in the spec file I had the cudaStream's as pointers (ptr) so I switched them to long but ti didn't make a difference. Originally the argument was "stream" but I can't get any argument but ptr and long to pass the winegcc for spec files.

http://shelnutt.twomurs.com/patches/cuda/cuda.dll.spec

Does wine need to somehow be made aware of the presence of the cudart.dll.so file? We tried putting it in both the system32 and the lib folder but it seems also that maybe WINE needs to be made aware of it?

 



Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Michael Karcher-5
In reply to this post by Seth Shelnutt-2
Am Samstag, den 12.07.2008, 20:52 -0400 schrieb Seth Shelnutt:

> zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$ winedbg [hidden email]
> WineDbg starting on pid 0024
> start_process () at /media/md0/wine/wine/dlls/kernel32/process.c:904
> 0x7b877d02 start_process+0xc2 [/media/md0/wine/wine/dlls/kernel32/process.c:904] in kernel32: movl %esi,0x0(%esp)
> 904 ExitThread( entry( peb ) );
> Wine-dbg>n
> fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers
> fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
> fixme:win:EnumDisplayDevicesW ((null),0,0x33f40c,0x00000000), stub!
> err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf7facaaf
> Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling it
> Process of pid=0024 has terminated
> Wine-dbg>
>
> I believe the key line is Invalid address (0x7b877d07 start_process
> +0xc7) for breakpoint 0, disabling it.
No, thats boring. Your program crahsed at address 0xf7fcaaf. IIRC code
0xc0000005 is a general protection fault. After your program has
crashed, the breakpoint wine automatically sets to catch program startup
is not valid anymore (there is no program to break anymore), that causes
the message you quoted.

Whats strange is that the debugger does not catch the exception. While
the first-chance event can be disabled, you should get a last-chance
exception catch right before the program dies. See
http://www.winehq.org/site/docs/winedev-guide/dbg-config for more info
about configuring the debugger.

Have you tried a relay trace yet?

Regards,
  Michael Karcher



Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
We have tried to get the trace, many different ways, but to no avail. I've read through everything on running a trace of it and I've tried it with different files and it works fine but when we try it with the folding client we don't get any trace. The cudart.dll.so which is placed in the /usr/local/lib/wine folder is being recognized by wine as we are not longer getting the not implemented error but now it is just a matter of determining what function it isn't liking. I've double check all the functions and they all seem to be fine minus the 4 direct3d functions and 6 functions which contain c++ coding. The 6 functions though involve copying memory, symbol size, and channel format. They don't involve anything that would be needed to start the folding client, they are all things that would cause a fault after the GPU has started calculations, or so I am lead to believe.

As always the latest code is available at http://shelnutt.twomurs.com/patches/cuda/ and a 7z of it all at http://shelnutt.twomurs.com/patches/cuda.7z

zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$ WINEDEBUG=+trace winedbg [hidden email]
WineDbg starting on pid 0016
start_process () at /media/md0/wine/wine/dlls/kernel32/process.c:904
0x7b877d02 start_process+0xc2 [/media/md0/wine/wine/dlls/kernel32/process.c:904] in kernel32: movl %esi,0x0(%esp)
Unable to open file ''
Wine-dbg>n
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x33f40c,0x00000000), stub!
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf7f80aaf
Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling it
Process of pid=0016 has terminated
Wine-dbg>quit
zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$ WINEDEBUG=+trace wine [hidden email]
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x32f40c,0x00000000), stub!
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf7fddaaf
zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$


Thanks,

Seth Shelnutt

On Sun, Jul 13, 2008 at 5:26 AM, Michael Karcher <[hidden email]> wrote:
No, thats boring. Your program crahsed at address 0xf7fcaaf. IIRC code
0xc0000005 is a general protection fault. After your program has
crashed, the breakpoint wine automatically sets to catch program startup
is not valid anymore (there is no program to break anymore), that causes
the message you quoted.

Whats strange is that the debugger does not catch the exception. While
the first-chance event can be disabled, you should get a last-chance
exception catch right before the program dies. See
http://www.winehq.org/site/docs/winedev-guide/dbg-config for more info
about configuring the debugger.

Have you tried a relay trace yet?

Regards,
 Michael Karcher




Reply | Threaded
Open this post in threaded view
|

RE: CUDA wrapper

Stefan Dösinger-2

WINEDEBUG=+trace doesn't really do anything. using WINEDEBUG=trace+all (or just +all) will enable *lots* of debug output.

 

However, what you want to do is to add something like this to your cuda wrapper:

 

At the beginning of the file, after the includes:

WINE_DEFAULT_DEBUG_CHANNEL(cuda);

 

Then in each function:

void cudaSomething(int a, const char *b) {

                TRACE("(%d, %s)\n", a, b);

}

 

Then run your app with WINEDEBUG=+cuda

 

That will give you some information how far the app gets in talking to your wrapper and the native lib

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Seth Shelnutt
Sent: Monday, July 14, 2008 9:31 PM
To: Michael Karcher; [hidden email]
Subject: Re: CUDA wrapper

 

We have tried to get the trace, many different ways, but to no avail. I've read through everything on running a trace of it and I've tried it with different files and it works fine but when we try it with the folding client we don't get any trace. The cudart.dll.so which is placed in the /usr/local/lib/wine folder is being recognized by wine as we are not longer getting the not implemented error but now it is just a matter of determining what function it isn't liking. I've double check all the functions and they all seem to be fine minus the 4 direct3d functions and 6 functions which contain c++ coding. The 6 functions though involve copying memory, symbol size, and channel format. They don't involve anything that would be needed to start the folding client, they are all things that would cause a fault after the GPU has started calculations, or so I am lead to believe.

As always the latest code is available at http://shelnutt.twomurs.com/patches/cuda/ and a 7z of it all at http://shelnutt.twomurs.com/patches/cuda.7z

zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$ WINEDEBUG=+trace winedbg [hidden email]
WineDbg starting on pid 0016
start_process () at /media/md0/wine/wine/dlls/kernel32/process.c:904
0x7b877d02 start_process+0xc2 [/media/md0/wine/wine/dlls/kernel32/process.c:904] in kernel32: movl %esi,0x0(%esp)
Unable to open file ''
Wine-dbg>n
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x33f40c,0x00000000), stub!
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf7f80aaf
Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling it
Process of pid=0016 has terminated
Wine-dbg>quit
zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$ WINEDEBUG=+trace wine [hidden email]
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x32f40c,0x00000000), stub!
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf7fddaaf
zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$


Thanks,

Seth Shelnutt

On Sun, Jul 13, 2008 at 5:26 AM, Michael Karcher <[hidden email]> wrote:

No, thats boring. Your program crahsed at address 0xf7fcaaf. IIRC code
0xc0000005 is a general protection fault. After your program has
crashed, the breakpoint wine automatically sets to catch program startup
is not valid anymore (there is no program to break anymore), that causes
the message you quoted.

Whats strange is that the debugger does not catch the exception. While
the first-chance event can be disabled, you should get a last-chance
exception catch right before the program dies. See
http://www.winehq.org/site/docs/winedev-guide/dbg-config for more info
about configuring the debugger.

Have you tried a relay trace yet?

Regards,
 Michael Karcher

 



Reply | Threaded
Open this post in threaded view
|

RE: CUDA wrapper

Michael Karcher-5
Am Montag, den 14.07.2008, 23:18 -0500 schrieb Stefan Dösinger:
> WINEDEBUG=+trace doesn't really do anything. using WINEDEBUG=trace+all
> (or just +all) will enable *lots* of debug output.
Right.

> However, what you want to do is to add something like this to your
> cuda wrapper:
> At the beginning of the file, after the includes:
> WINE_DEFAULT_DEBUG_CHANNEL(cuda);
> Then in each function:
>
> void cudaSomething(int a, const char *b) {
>                 TRACE("(%d, %s)\n", a, b);
> }
This would be the long-term goal, probably, but WINEDEBUG=+relay should
automatically generate thunks in memory that do this printing (but not
only for cuda, of course, except if configured appropriately). In the
short term, this should yield a hint where to start searching more
quickly.

Regards,
  Michael Karcher



Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
Ok, I'm pretty sure I've got a working wrapper. Still need to implement a few functions and the direct3d calls but nearly everything is there. If anyone would like to test out different CUDA apps with this and report any feedback it would be much appreciate. I don't have a CUDA enabled card so I can't test anything.

The source files are viewable here,
http://shelnutt.twomurs.com/patches/cuda/

and as a 7z file.
http://shelnutt.twomurs.com/patches/cuda.7z

Binary file is available under
http://shelnutt.twomurs.com/patches/cuda/bin/


Thanks,

Seth Shelnutt



Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
It seems when using this wrapper and a cuda enabled program, it causes the program/wine to use 100% of a CPU core, while running in windows the FaH GPU client only takes around 10-15% at most of a CPU core. Any ideas why the sudden jump to 100% use? It makes the systems most unusable in the normal sense, as a desktop.


Reply | Threaded
Open this post in threaded view
|

RE: CUDA wrapper

Stefan Dösinger-2

You could use oprofile to find out where the CPU time is spent - this behavior can be caused by a lot of issues.

 

Does the Cuda client work now? If so, it would be cool if we could include the wrapper in Wine, or get it into a shape to make it easilly redistributable and installable next to Wine.

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Seth Shelnutt
Sent: Saturday, July 19, 2008 7:12 AM
To: [hidden email]
Subject: Re: CUDA wrapper

 

It seems when using this wrapper and a cuda enabled program, it causes the program/wine to use 100% of a CPU core, while running in windows the FaH GPU client only takes around 10-15% at most of a CPU core. Any ideas why the sudden jump to 100% use? It makes the systems most unusable in the normal sense, as a desktop.



Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Bugzilla from zerix01@gmail.com
In reply to this post by Seth Shelnutt-2
Sorry if I posted this wrong, I'm new to mailing lists.

*You could use oprofile to find out where the CPU time is spent - this
*behavior can be caused by a lot of issues.


*Does the Cuda client work now? If so, it would be cool if we could include
*the wrapper in Wine, or get it into a shape to make it easilly
*redistributable and installable next to Wine.

I have been testing this out with Seth. Yes the wrapper is up and
running. I have been able to run the folding@home GPU client for about
a week now with comparable performance to the same hardware running
under Windows. The main problem as stated before is that both cores
(dual core system) are running at 100% and the system is not usable
until the client is killed. In Windows this client only uses about 20%
or less of a single core to feed the GPU leaving the second core free.

I ran oprofile (first time, never heard of it before) while the client
was running.

213932 54.7876 wine-preloader
        CPU_CLK_UNHALT...|
          samples|      %|
        ------------------
          1970113 88.9871 libcuda.so.177.13
           160796  7.2629 FahCore_11.exe
            30056  1.3576 libc-2.7.so
            10169  0.4593 libpthread-2.7.so
             9143  0.4130 libcudart.so.2.0
             8473  0.3827 libfreetype.so.6.3.16
             5065  0.2288 kernel32.dll.so
             4726  0.2135 ntdll.dll.so
             3578  0.1616 [vdso] (tgid:19882
range:0xffffe000-0xfffff000)
             3458  0.1562 cudart.dll.so

I have attached the full output.

I assume this says that libcuda is using 88% of the CPU and
FahCore_11.exe is using 7%. When I watch the processes in the KDE
system monitor it shows FahCore_11.exe using ~50% (one full core) and
Xorg using ~50% (second core). I don't see from oprofile how and why
xorg is using a whole core.


Reply | Threaded
Open this post in threaded view
|

RE: CUDA wrapper

Stefan Dösinger-2
> I assume this says that libcuda is using 88% of the CPU and
> FahCore_11.exe is using 7%. When I watch the processes in the KDE
> system monitor it shows FahCore_11.exe using ~50% (one full core) and
> Xorg using ~50% (second core). I don't see from oprofile how and why
> xorg is using a whole core.
oprofile doesn't care too much about processes like top does, it rather
lists the modules and functions in which CPU time is spent. Your result
shows that the CPU time is spent in the Cuda driver(on behalf of both the
FAH and X11 processes). I am afraid I can't help you with that. I recommend
you to contact Nvidia on this issue.




12