Re: CUDA Wrapper err:module:import_dl
Seth Shelnutt wrote: |Alright, I'm stumped and everyone else is too. Few years ago we did everything we are doing now and it all worked fine. Now using wine 1.2rc2 we can't get a wrapper I compiled to work. What this wrapper does is it translates/wraps the calls made to the cuda runtime dll (cudart.dll or nvcuda.dll, same file different names) and sends it to the linux library. The linux library and windows are identical except for some missing dx functions in the linux library. My sources can be found here. http://shelnutt2.host56.com/cudart/ and http://shelnutt2.host56.com/cufft/ (However we aren't even getting to the second dll yet). Anytime we try to run folding at home in wine, we are getting the following. FAH checks for nvcuda.dll first because that comes with the driver installs on windows, if it doesn't find it, it defaults to cudart.dll which is packaged with fah, or can be installed separately. We have replaced all the cuda dlls with the compiled wrapper or sum linked to the compiled wrapper, just like we use to with the original cuda wrapper that we came up with. err:module:import_dll Loading library nvcuda.dll (which is needed by L"Z:\\home\\sidicas\\.FAHGPU3\\FahCore_11.exe") failed (error c020). err:module:import_dll Loading library cudart.dll (which is needed by L"Z:\\home\\sidicas\\.FAHGPU3\\FahCore_11.exe") failed (error c020). | |sidi...@belldandy:~/.FAHGPU3$ ls -al *.dll -rw-r--r-- 1 sidicas sidicas 1617920 2010-06-03 01:48 amdcalcl.dll -rw-r--r-- 1 sidicas sidicas 2486272 2010-06-03 01:48 amdcalrt.dll -rw-r--r-- 1 sidicas sidicas 124540 2010-06-02 07:50 cudart32_30_14.dll -rw-r--r-- 1 sidicas sidicas 124540 2010-06-02 07:50 cudart.dll -rw-r--r-- 1 sidicas sidicas 82699 2010-06-01 21:39 cufft32_30_14.dll -rw-r--r-- 1 sidicas sidicas 82699 2010-06-01 21:39 cufft.dll lrwxrwxrwx 1 sidicas sidicas 10 2010-06-03 02:12 nvcuda.dll -> cudart.dll sidi...@belldandy:~/.FAHGPU3$ | |sidi...@belldandy:~/.FAHGPU3$ uname -a Linux Belldandy 2.6.26-2-amd64 #1 SMP Sun Jun 21 04:47:08 UTC 2009 x86_64 GNU/Linux sidi...@belldandy:~/.FAHGPU3$ nvcc --version nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2009 NVIDIA Corporation Built on Fri_Feb_19_18:18:31_PST_2010 Cuda compilation tools, release 3.0, V0.2.1221 sidi...@belldandy:~/.FAHGPU3$ ldd ./cudart.dll linux-gate.so.1 => (0xf7ee3000) libcudart.so.3 => /usr/local/cuda/lib/libcudart.so.3 (0xf7e83000) libwine.so.1 => /usr/lib/libwine.so.1 (0xf7d2d000) libm.so.6 => /lib32/libm.so.6 (0xf7d09000) libc.so.6 => /lib32/libc.so.6 (0xf7bb6000) libdl.so.2 => /lib32/libdl.so.2 (0xf7bb2000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7b9b000) librt.so.1 => /lib32/librt.so.1 (0xf7b92000) libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7aa4000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7a97000) /lib/ld-linux.so.2 (0xf7ee4000) sidi...@belldandy:~/.FAHGPU3$ sidi...@belldandy:~/.FAHGPU3$ ldd ./cufft.dll linux-gate.so.1 => (0xf7f29000) libcufft.so.3 => /usr/local/cuda/lib/libcufft.so.3 (0xf7308000) libwine.so.1 => /usr/lib/libwine.so.1 (0xf71b2000) libm.so.6 => /lib32/libm.so.6 (0xf718e000) libc.so.6 => /lib32/libc.so.6 (0xf703b000) libdl.so.2 => /lib32/libdl.so.2 (0xf7037000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf702) libcudart.so.3 => /usr/local/cuda/lib/libcudart.so.3 (0xf6fdf000) libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf6ef1000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf6ee4000) /lib/ld-linux.so.2 (0xf7f2a000) librt.so.1 => /lib32/librt.so.1 (0xf6eda000) sidi...@belldandy:~/.FAHGPU3$ sidi...@belldandy:~/.FAHGPU3$ | More thorugh testing has been done, http://foldingforum.org/viewtopic.php?f=54&t=14673&start=105#p146177 <http://foldingforum.org/viewtopic.php?f=54&t=14673&start=105#p146177> . When we makes reference to gpu2 wrapper, that is our original cuda wrapper designed for cuda 2.0-2.2 built couple years ago. The GPU3 wrapper is what we are having problems with. It is our cuda 3.0 wrapper. The .dll files are in the folder (we even tried in system32), ldd shows they are properly linked, yet it does not work. If we use the old wrapper compile before it works fine with cuda 2.x or with cuda 3.0 we just have to sym link the cuda lib to the old name it's expecting. I've tried compiling the old wrapper and linking it to cuda 2.3 however this fails. So I am thinking that if when I compile the old wrapper which i
CUDA Wrapper err:module:import_dl
Alright, I'm stumped and everyone else is too. Few years ago we did everything we are doing now and it all worked fine. Now using wine 1.2rc2 we can't get a wrapper I compiled to work. What this wrapper does is it translates/wraps the calls made to the cuda runtime dll (cudart.dll or nvcuda.dll, same file different names) and sends it to the linux library. The linux library and windows are identical except for some missing dx functions in the linux library. My sources can be found here. http://shelnutt2.host56.com/cudart/ and http://shelnutt2.host56.com/cufft/(However we aren't even getting to the second dll yet). Anytime we try to run folding at home in wine, we are getting the following. FAH checks for nvcuda.dll first because that comes with the driver installs on windows, if it doesn't find it, it defaults to cudart.dll which is packaged with fah, or can be installed separately. We have replaced all the cuda dlls with the compiled wrapper or sum linked to the compiled wrapper, just like we use to with the original cuda wrapper that we came up with. err:module:import_dll Loading library nvcuda.dll (which is needed by L"Z:\\home\\sidicas\\.FAHGPU3\\FahCore_11.exe") failed (error c020). err:module:import_dll Loading library cudart.dll (which is needed by L"Z:\\home\\sidicas\\.FAHGPU3\\FahCore_11.exe") failed (error c020). sidi...@belldandy:~/.FAHGPU3$ ls -al *.dll -rw-r--r-- 1 sidicas sidicas 1617920 2010-06-03 01:48 amdcalcl.dll -rw-r--r-- 1 sidicas sidicas 2486272 2010-06-03 01:48 amdcalrt.dll -rw-r--r-- 1 sidicas sidicas 124540 2010-06-02 07:50 cudart32_30_14.dll -rw-r--r-- 1 sidicas sidicas 124540 2010-06-02 07:50 cudart.dll -rw-r--r-- 1 sidicas sidicas 82699 2010-06-01 21:39 cufft32_30_14.dll -rw-r--r-- 1 sidicas sidicas 82699 2010-06-01 21:39 cufft.dll lrwxrwxrwx 1 sidicas sidicas 10 2010-06-03 02:12 nvcuda.dll -> cudart.dll sidi...@belldandy:~/.FAHGPU3$ sidi...@belldandy:~/.FAHGPU3$ uname -a Linux Belldandy 2.6.26-2-amd64 #1 SMP Sun Jun 21 04:47:08 UTC 2009 x86_64 GNU/Linux sidi...@belldandy:~/.FAHGPU3$ nvcc --version nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2009 NVIDIA Corporation Built on Fri_Feb_19_18:18:31_PST_2010 Cuda compilation tools, release 3.0, V0.2.1221 sidi...@belldandy:~/.FAHGPU3$ ldd ./cudart.dll linux-gate.so.1 => (0xf7ee3000) libcudart.so.3 => /usr/local/cuda/lib/libcudart.so.3 (0xf7e83000) libwine.so.1 => /usr/lib/libwine.so.1 (0xf7d2d000) libm.so.6 => /lib32/libm.so.6 (0xf7d09000) libc.so.6 => /lib32/libc.so.6 (0xf7bb6000) libdl.so.2 => /lib32/libdl.so.2 (0xf7bb2000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7b9b000) librt.so.1 => /lib32/librt.so.1 (0xf7b92000) libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7aa4000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7a97000) /lib/ld-linux.so.2 (0xf7ee4000) sidi...@belldandy:~/.FAHGPU3$ sidi...@belldandy:~/.FAHGPU3$ ldd ./cufft.dll linux-gate.so.1 => (0xf7f29000) libcufft.so.3 => /usr/local/cuda/lib/libcufft.so.3 (0xf7308000) libwine.so.1 => /usr/lib/libwine.so.1 (0xf71b2000) libm.so.6 => /lib32/libm.so.6 (0xf718e000) libc.so.6 => /lib32/libc.so.6 (0xf703b000) libdl.so.2 => /lib32/libdl.so.2 (0xf7037000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf702) libcudart.so.3 => /usr/local/cuda/lib/libcudart.so.3 (0xf6fdf000) libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf6ef1000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf6ee4000) /lib/ld-linux.so.2 (0xf7f2a000) librt.so.1 => /lib32/librt.so.1 (0xf6eda000) sidi...@belldandy:~/.FAHGPU3$ sidi...@belldandy:~/.FAHGPU3$ More thorugh testing has been done, http://foldingforum.org/viewtopic.php?f=54&t=14673&start=105#p146177 . When we makes reference to gpu2 wrapper, that is our original cuda wrapper designed for cuda 2.0-2.2 built couple years ago. The GPU3 wrapper is what we are having problems with. It is our cuda 3.0 wrapper. The .dll files are in the folder (we even tried in system32), ldd shows they are properly linked, yet it does not work. If we use the old wrapper compile before it works fine with cuda 2.x or with cuda 3.0 we just have to sym link the cuda lib to the old name it's expecting. I've tried compiling the old wrapper and linking it to cuda 2.3 however this fails. So I am thinking that if when I compile the old wrapper which is shown to work (when an old compiled version is used) but does not work when I compile on my funtoo box it must be some weird compiling issue. I have wine installed (without 64bit support), and I installed cuda runtime from nvidia's site as the one in portage installs to /opt/ and I wanted to make sure there wasn't any weird issues linking with that. I do get a few warnings when I compi
CUDA Wrapper and unimplemented functions kernel32
A while back you guys had helped with developing the CUDA wrapper. Some changes in the folding at home GPU2 client core, has caused us the need to update it with newer functions implemented. However it seems now that the wrapper is getting an error, which appears to be related to Wine itself. $ wine ./FahCore_14.exe -suffix 01 -nodelete wine: Call from 0x7edb2a73 to unimplemented function kernel32.dll., aborting err:module:attach_process_dlls "cudart.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"Z:\\home\\daz\\core14test2\\FahCore_14.exe" failed, status 8100 What do you guys make of it? The CUDA wrapper and source can be downloaded from http://www.twomurs.com/seth/patches/new/ . For instructions on how to set it up, see our wiki http://gpu2.twomurs.com/index.php?title=Linux . The only difference is instead of downloading the wrapper linked there, download the one I linked to above. Also to test out the new f...@h core which is causing the update and the subsiquent kernel issue, before you run the f...@hclient, download these two files, and place them in the same directory you have the f...@h cient, - core: http://fah-web.stanford.edu/ihaque/FahCore_14.exe MD5 hash: 4e4621e3cbe1e4069c264c449615c127 - WU: http://fah-web.stanford.edu/ihaque/wudata_01.dat MD5 hash: 8d4e47c17445a8deca403caa52fbcb6f Thanks for the help, Seth Shelnutt
RE: CUDA wrapper
> 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.
Re: CUDA wrapper
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 [EMAIL PROTECTED] 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:0xe000-0xf000) 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.
RE: CUDA wrapper
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Shelnutt Sent: Saturday, July 19, 2008 7:12 AM To: wine-devel@winehq.org 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.
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.
Re: CUDA wrapper
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
RE: CUDA wrapper
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
RE: CUDA wrapper
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Seth Shelnutt
Sent: Monday, July 14, 2008 9:31 PM
To: Michael Karcher; wine-devel@winehq.org
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
[EMAIL PROTECTED]:~/.wine/drive_c/Program
Files/[EMAIL PROTECTED]/[EMAIL PROTECTED] WINEDEBUG=+trace winedbg
[EMAIL PROTECTED]
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,0x), stub!
err:seh:raise_exception Unhandled exception code c005 flags 0 addr
0xf7f80aaf
Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling
it
Process of pid=0016 has terminated
Wine-dbg>quit
[EMAIL PROTECTED]:~/.wine/drive_c/Program
Files/[EMAIL PROTECTED]/[EMAIL PROTECTED] WINEDEBUG=+trace wine [EMAIL
PROTECTED]
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,0x), stub!
err:seh:raise_exception Unhandled exception code c005 flags 0 addr
0xf7fddaaf
[EMAIL PROTECTED]:~/.wine/drive_c/Program
Files/[EMAIL PROTECTED]/[EMAIL PROTECTED]
Thanks,
Seth Shelnutt
On Sun, Jul 13, 2008 at 5:26 AM, Michael Karcher
<[EMAIL PROTECTED]> wrote:
No, thats boring. Your program crahsed at address 0xf7fcaaf. IIRC code
0xc005 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
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 [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/[EMAIL PROTECTED] /[EMAIL PROTECTED] WINEDEBUG=+trace winedbg [EMAIL PROTECTED] 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,0x), stub! err:seh:raise_exception Unhandled exception code c005 flags 0 addr 0xf7f80aaf Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling it Process of pid=0016 has terminated Wine-dbg>quit [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/[EMAIL PROTECTED] /[EMAIL PROTECTED] WINEDEBUG=+trace wine [EMAIL PROTECTED] 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,0x), stub! err:seh:raise_exception Unhandled exception code c005 flags 0 addr 0xf7fddaaf [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/[EMAIL PROTECTED] /[EMAIL PROTECTED] Thanks, Seth Shelnutt On Sun, Jul 13, 2008 at 5:26 AM, Michael Karcher < [EMAIL PROTECTED]> wrote: > No, thats boring. Your program crahsed at address 0xf7fcaaf. IIRC code > 0xc005 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 > >
Re: CUDA wrapper
Am Samstag, den 12.07.2008, 20:52 -0400 schrieb Seth Shelnutt: > [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/[EMAIL PROTECTED]/[EMAIL > PROTECTED] winedbg [EMAIL PROTECTED] > 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,0x), stub! > err:seh:raise_exception Unhandled exception code c005 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 0xc005 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
RE: CUDA wrapper
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Shelnutt Sent: Saturday, July 12, 2008 7:52 PM To: wine-devel@winehq.org 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. [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/[EMAIL PROTECTED]/[EMAIL PROTECTED] winedbg [EMAIL PROTECTED] 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,0x), stub! err:seh:raise_exception Unhandled exception code c005 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Shelnutt Sent: Wednesday, July 09, 2008 7:23 PM To: Juan Lang; wine-devel@winehq.org 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?
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. [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/[EMAIL PROTECTED] /[EMAIL PROTECTED] winedbg [EMAIL PROTECTED] 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,0x), stub! err:seh:raise_exception Unhandled exception code c005 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 <[EMAIL PROTECTED]> 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:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Seth Shelnutt > *Sent:* Wednesday, July 09, 2008 7:23 PM > *To:* Juan Lang; wine-devel@winehq.org > *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? >
RE: CUDA wrapper
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Shelnutt Sent: Wednesday, July 09, 2008 7:23 PM To: Juan Lang; wine-devel@winehq.org 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?
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.sofile? 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?
Re: CUDA wrapper
> [EMAIL PROTECTED]:~/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
Re: CUDA wrapper
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. [EMAIL PROTECTED]:~/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.
Re: CUDA wrapper
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 [EMAIL PROTECTED]:~/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.
Re: CUDA wrapper
I apologise for the simple mistakes. But I only made those spelling errors after the fact and I was trying to get it working, I saw from google one forums post where the U was capitalised so I thought I'd try it, I just had forgot to put it back. I have fixed all the error and now it doesn't complain about any errors with the file but I think my make file is not correct. After I fixed the paths to the linking library libcudart.so.2.0, now it is saying it that the linking isn't done. gcc: /usr/local/cuda/lib/libcudart.so.2.0: linker input file unused because linking not done Also after that I get an error about libcudart.so.2-LhAtfa.o is an empty file. What is that LhAtfa.o? Of course it is an empty file as far as I know that isn't a real file. What is it trying to link to? Thanks, Seth Shelnutt On Mon, Jul 7, 2008 at 5:59 PM, Juan Lang <[EMAIL PROTECTED]> wrote: > > I have #include , maybe I do not have my makefile correct. I've > > attached the makefile, the cudart.c and all the nvidia header's need (14 > of > > them) in one tar.bz2 file. Can someone check my makefile and all? I read > > through the nvidia license and it is ok to redistribute the headers. > > Nothing to do with the makefile. Your includes are wrong. I changed > your includes as follows: > --- cudart.c.orig 2008-07-07 14:54:51.0 -0700 > +++ cudart.c2008-07-07 14:54:57.0 -0700 > @@ -1,8 +1,9 @@ > /*This is a wrapper for cudart.dll and libdudart.so.2.0*/ > > > -#include > #include > +#include > +#include > #include > #include "cuda_runtime.h" > #include "cuda_runtime_api.h" /*I am unsure if both these headers are > needed, both do contain some of the functions*/ > > This gets a lot of the compile errors to go away, but not all of them. > In several places you misspelled GLuint as GLUint. In the future > please be more careful, discussing basic stuff like this gets a little > tedious. > --Juan >
Re: CUDA wrapper
> I have #include , maybe I do not have my makefile correct. I've > attached the makefile, the cudart.c and all the nvidia header's need (14 of > them) in one tar.bz2 file. Can someone check my makefile and all? I read > through the nvidia license and it is ok to redistribute the headers. Nothing to do with the makefile. Your includes are wrong. I changed your includes as follows: --- cudart.c.orig 2008-07-07 14:54:51.0 -0700 +++ cudart.c2008-07-07 14:54:57.0 -0700 @@ -1,8 +1,9 @@ /*This is a wrapper for cudart.dll and libdudart.so.2.0*/ -#include #include +#include +#include #include #include "cuda_runtime.h" #include "cuda_runtime_api.h" /*I am unsure if both these headers are needed, both do contain some of the functions*/ This gets a lot of the compile errors to go away, but not all of them. In several places you misspelled GLuint as GLUint. In the future please be more careful, discussing basic stuff like this gets a little tedious. --Juan
Re: CUDA wrapper
I have #include , maybe I do not have my makefile correct. I've
attached the makefile, the cudart.c and all the nvidia header's need (14 of
them) in one tar.bz2 file. Can someone check my makefile and all? I read
through the nvidia license and it is ok to redistribute the headers.
On Mon, Jul 7, 2008 at 5:29 PM, Juan Lang <[EMAIL PROTECTED]> wrote:
> > cudart.c:261: error: expected ')' before 'bufferObj'
> > cudart.c:265: error: expected declaration specifiers or '...' before
> > 'GLuint'
> >
> > cudaError_t WINAPI wine_cudaGLRegisterBufferObject( GLuint bufferObj ){
>
> Check your includes again. GLuint is defined in here.
> --Juan
>
/*This is a wrapper for cudart.dll and libdudart.so.2.0*/
#include
#include
#include
#include "cuda_runtime.h"
#include "cuda_runtime_api.h" /*I am unsure if both these headers are needed, both do contain some of the functions*/
#include "wine/debug.h"
#include
WINE_DEFAULT_DEBUG_CHANNEL(cuda); /*Can I do this?*/
cudaError_t WINAPI wine_cudaGetDeviceCount( int* count ){
return cudaGetDeviceCount( count );
}
cudaError_t WINAPI wine_cudaSetDevice( int dev ){
return cudaSetDevice( dev );
}
cudaError_t WINAPI wine_cudaGetDevice( int* dev ){
return cudaGetDevice( dev );
}
cudaError_t WINAPI wine_cudaGetDeviceProperties( struct cudaDeviceProp* prop, int dev ){
return cudaGetDeviceProperties( prop, dev );
}
cudaError_t WINAPI wine_cudaChooseDevice( int* dev, const struct cudaDeviceProp* prop ){
return cudaChooseDevice( dev, prop );
}
cudaError_t WINAPI wine_cudaThreadSynchronize( void ){
return cudaThreadSynchronize( );
}
cudaError_t WINAPI wine_cudaThreadExit( void ){
return cudaThreadExit( );
}
cudaError_t WINAPI wine_cudaStreamCreate( cudaStream_t* stream ){
return cudaStreamCreate( stream );
}
cudaError_t WINAPI wine_cudaStreamQuery(cudaStream_t stream){
return cudaStreamQuery( stream );
}
cudaError_t WINAPI wine_cudaStreamSynchronize( cudaStream_t stream ){
return cudaStreamSynchronize( stream );
}
cudaError_t WINAPI wine_cudaStreamDestroy( cudaStream_t stream ){
return cudaStreamDestroy( stream );
}
cudaError_t WINAPI wine_cudaEventCreate( cudaEvent_t* event ){
return cudaEventCreate( event );
}
cudaError_t WINAPI wine_cudaEventRecord( cudaEvent_t event, cudaStream_t stream ){
return cudaEventRecord( event, stream );
}
cudaError_t WINAPI wine_cudaEventQuery( cudaEvent_t event ){
return cudaEventQuery( event );
}
cudaError_t WINAPI wine_cudaEventSynchronize( cudaEvent_t event ){
return cudaEventSynchronize( event );
}
cudaError_t WINAPI wine_cudaEventDestroy( cudaEvent_t event ){
return cudaEventDestroy( event );
}
cudaError_t WINAPI wine_cudaEventElapsedTime( float* time, cudaEvent_t start, cudaEvent_t end ){
return cudaEventElapsedTime( time, start, end );
}
cudaError_t WINAPI wine_cudaMalloc( void** devPtr, size_t count ){
return cudaMalloc( devPtr, count );
}
cudaError_t WINAPI wine_cudaMallocPitch( void** devPtr, size_t* pitch, size_t widthInBytes, size_t height ){
return cudaMallocPitch( devPtr, pitch, widthInBytes, height );
}
cudaError_t WINAPI wine_cudaFree( void* devPtr ){
return cudaFree( devPtr );
}
cudaError_t WINAPI wine_cudaMallocArray( struct cudaArray** array, const struct cudaChannelFormatDesc* desc, size_t width, size_t height ){
return cudaMallocArray( array, desc, width, height);
}
cudaError_t WINAPI wine_cudaFreeArray( struct cudaArray* array ){
return cudaFreeArray( array );
}
cudaError_t WINAPI wine_cudaMallocHost( void** hostPtr, size_t size ){
return cudaMallocHost( hostPtr, size);
}
cudaError_t WINAPI wine_cudaFreeHost( void* hostPtr ){
return cudaFreeHost( hostPtr);
}
cudaError_t WINAPI wine_cudaMemset( void* devPtr, int value, size_t count ){
return cudaMemset( devPtr, value, count);
}
cudaError_t WINAPI wine_cudaMemset2D( void* dstPtr, size_t pitch, int value, size_t width, size_t height ){
return cudaMemset2D( dstPtr, pitch, value, width, height );
}
cudaError_t WINAPI wine_cudaMemcpy( void* dst, const void* src, size_t count, enum cudaMemcpyKind kind ){
return cudaMemcpy( dst, src, count, kind );
}
cudaError_t WINAPI wine_cudaMemcpyAsync( void* dst, const void* src, size_t count, enum cudaMemcpyKind kind, cudaStream_t stream ){
return cudaMemcpyAsync( dst, src, count, kind, stream );
}
cudaError_t WINAPI wine_cudaMemcpy2D( void* dst, size_t dpitch, const void* src, size_t spitch, size_t width, size_t height, enum cudaMemcpyKind kind ){
return cudaMemcpy2D( dst, dpitch, src, spitch, width, height, kind );
}
cudaError_t WINAPI wine_cudaMemcpy2DAsync( void* dst, size_t dpitch, const void* src, size_t spitch, size_t width, size_t height, enum cudaMemcpyKind kind, cudaStream_t stream ){
return cudaMemcpy2DAsync( dst, dpitch, src, spitch, width, height, kind, stream );
}
cudaError_t WINAPI wine_cudaMemcpyToArray( struct cudaArray* dstArray, size_t dstX, size_t dstY, const void* src, size_t count, enum cudaMemcpyKind kind ){
return cudaMemcpyToArray( dstArray, dstX, dstY, src, c
Re: CUDA wrapper
> cudart.c:261: error: expected ')' before 'bufferObj'
> cudart.c:265: error: expected declaration specifiers or '...' before
> 'GLuint'
>
> cudaError_t WINAPI wine_cudaGLRegisterBufferObject( GLuint bufferObj ){
Check your includes again. GLuint is defined in here.
--Juan
CUDA wrapper
I just have a makefile. No makefile.in. Perhaps I used winemaker wrong? I simply did "winemaker --dll cuda". On Mon, Jul 7, 2008 at 5:00 PM, John Klehm <[EMAIL PROTECTED]> wrote: > > > Check the IMPORT variable in Makefile.in and see if everything you > need is listed. > > --John >
Re: CUDA wrapper
On Mon, Jul 7, 2008 at 3:52 PM, Seth Shelnutt <[EMAIL PROTECTED]> wrote: > Ah ok, now I understand. > > I am having a problem with the opengl section of it. It doesn't like GLuint > . I've added the gl.h file to my list of headers as I thought maybe I needed > the header to define it. But it still doesn't like it. Here are the errors, > and one of the lines of code. I've googled it and GLuint is proper. It's > just an unsigned int. It is also "c" code not c++, so I'm not sure what it > is complaining about. Any ideas? > > cudart.c:261: error: expected ')' before 'bufferObj' > cudart.c:265: error: expected declaration specifiers or '...' before > 'GLuint' > > Check the IMPORT variable in Makefile.in and see if everything you need is listed. --John
Re: CUDA wrapper
Ah ok, now I understand.
I am having a problem with the opengl section of it. It doesn't like GLuint
. I've added the gl.h file to my list of headers as I thought maybe I needed
the header to define it. But it still doesn't like it. Here are the errors,
and one of the lines of code. I've googled it and GLuint is proper. It's
just an unsigned int. It is also "c" code not c++, so I'm not sure what it
is complaining about. Any ideas?
cudart.c:261: error: expected ')' before 'bufferObj'
cudart.c:265: error: expected declaration specifiers or '...' before
'GLuint'
cudaError_t WINAPI wine_cudaGLRegisterBufferObject( GLuint bufferObj ){
Thanks
On Mon, Jul 7, 2008 at 1:21 PM, Juan Lang <[EMAIL PROTECTED]> wrote:
> Hi Seth,
>
> > Now are you saying the code should be,
> > retval, WINAPI wine_cudaGetDeviceCount( int* count ){
> > return cudaGetDeviceCount( count );
> > }
> >
> > or should it be
> >
> > retval, WINAPI wine_cudaGetDeviceCount( int* count )
> >
> > or
> >
> > retval = WINAPI wine_cudaGetDeviceCount( int* count ){
> > return cudaGetDeviceCount( retval );
> > }
>
> None of the above. retval was just a standin for a type declaration.
> I don't know what the proper return type is, but Google does: it's
> cudaError_t. So the proper declaration is likely to be:
>
> cudaError_t WINAPI wine_cudaGetDeviceCount(int *count) {
>return cudaGetDeviceCount(count);
> }
>
> --Juan
>
Re: CUDA wrapper
Hi Seth,
> Now are you saying the code should be,
> retval, WINAPI wine_cudaGetDeviceCount( int* count ){
> return cudaGetDeviceCount( count );
> }
>
> or should it be
>
> retval, WINAPI wine_cudaGetDeviceCount( int* count )
>
> or
>
> retval = WINAPI wine_cudaGetDeviceCount( int* count ){
> return cudaGetDeviceCount( retval );
> }
None of the above. retval was just a standin for a type declaration.
I don't know what the proper return type is, but Google does: it's
cudaError_t. So the proper declaration is likely to be:
cudaError_t WINAPI wine_cudaGetDeviceCount(int *count) {
return cudaGetDeviceCount(count);
}
--Juan
Re: CUDA wrapper
> I am also not quite sure about some constructs, like > > "wine_cudaBindTexture( size_t* offset, const struct texture < T, dim, > readMode >& texRef, const void* devPtr, const struct cudaChannelFormatDesc& > desc, size_t size = UINT_MAX )" As far as I know this contains C++ or > Microsoft syntax, which is not valid in pure C. Correct, this is C++. If you're wondering about the const reference, that's only valid in C++. If there is such a declaration as part of the CUDA API, then it's only accessible from C++ callers, and your implementation must be in C++. If you're wondering about the default value for size, that's also C++. Default values are only valid in a function declaration, not in a function definition. Therefore I think you can just omit them from your own implementation. --Juan
CUDA wrapper
The compiler chokes on the C++ coding that you pointed out. I'm not sure
exactly how to handle it, maybe just convert it all to c syntax? For now
I'll just commit out those lines and just work on trying to get something to
compile.
Now are you saying the code should be,
retval, WINAPI wine_cudaGetDeviceCount( int* count ){
return cudaGetDeviceCount( count );
}
or should it be
retval, WINAPI wine_cudaGetDeviceCount( int* count )
or
retval = WINAPI wine_cudaGetDeviceCount( int* count ){
return cudaGetDeviceCount( retval );
}
I've never used retval and going off of
http://www.systhread.net/texts/200612retval.php , it seems that retval is as
simple as returning the value from a function, so I set the input to equal
retval then I can return the function ( retval) and it will have all the
values right? Maybe I am miss understanding it.
On Mon, Jul 7, 2008 at 12:26 PM, Stefan Dösinger <[EMAIL PROTECTED]>
wrote:
> Actually you want something like
>
> retval WINAPI wine_cudaSomething(int a, int etc)
>
> so instead of the void use the return value the function is supposed to
> return
>
>
>
> WINAPI tells the compiler about the calling convention(ie, first parameter
> on the stack, in ecx, or elsewhere, who takes care about cleaning up the
> stack, etc). You'll have to check the calling convention Win32 cuda uses,
> but most likely WINAPI is correct. You don't have to care about the Linux
> cuda calling convention, since the compiler knows about that from the Linux
> cuda headers
>
>
>
> I am also not quite sure about some constructs, like
>
> "wine_cudaBindTexture( size_t* offset, const struct texture < T, dim,
> readMode >& texRef, const void* devPtr, const struct cudaChannelFormatDesc&
> desc, size_t size = UINT_MAX )" As far as I know this contains C++ or
> Microsoft syntax, which is not valid in pure C.
>
>
>
>
>
RE: CUDA wrapper
Actually you want something like retval WINAPI wine_cudaSomething(int a, int etc) so instead of the void use the return value the function is supposed to return WINAPI tells the compiler about the calling convention(ie, first parameter on the stack, in ecx, or elsewhere, who takes care about cleaning up the stack, etc). You'll have to check the calling convention Win32 cuda uses, but most likely WINAPI is correct. You don't have to care about the Linux cuda calling convention, since the compiler knows about that from the Linux cuda headers I am also not quite sure about some constructs, like "wine_cudaBindTexture( size_t* offset, const struct texture < T, dim, readMode >& texRef, const void* devPtr, const struct cudaChannelFormatDesc& desc, size_t size = UINT_MAX )" As far as I know this contains C++ or Microsoft syntax, which is not valid in pure C. From: Seth Shelnutt [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2008 11:01 AM To: Stefan Dösinger Cc: wine-devel@winehq.org Subject: Re: CUDA wrapper I've attached my spec file and my .c file along with the two header files from the nvidia toolkit. I am pretty sure in the .c file I was not suppose to use the "WINAPI" but instead I need "FancyCudaReturnValue" but I don't know what that is. Needless to say after using "winemaker cuda" (I have it in a folder called cuda), it doesn't compile and I get a million and one errors. I'm sure these errors are more or less caused because I didn't quite get it right. If you could just look at it and give me some pointers on where and how I went wrong, it would be appreciated. You've been a big help so far. Thank you for the explanations in the last email it got me this far so far. -Seth Shelnutt
RE: CUDA wrapper
> Ok, please forgive my naivety but this is my first attempt and all,
No worries. This list is here for help in such cases(although I am not that
experienced in that area)
> I am lost and need come guidance, the guide is of some help and so is
looking at the
> opengl files. I am not sure exactly what I am trying to write. What is the
difference
> between a dll form Wine and a dll.so? I know the dll.so end up in your
linux /lib
> folder right? How does a dll communicate to this dll.so?
There are 3 file extensions:
.so: Those are ELF shared object files which Linux uses. Linux apps can link
to them, Windows apps can't due to reasons pointed out earlier
.dll: Those are PE files, which Windows apps can link to, but the Linux
dynamic loader can't parse
.dll.so: Those are Wine DLLs. Technically they are .so files, but with extra
information added for linking them with Windows apps.
A Windows app classically links to .dll and .exe files(.exe is just a .dll
with a main() function in it). Wine can use its own builtin .dll.so
implementations of a DLL. Those libraries are loaded by the Linux dynamic
loader, so a .dll.so can link to other Linux libraries(e.g. libcuda.so).
That way you can write functions that serve as Win32 API entrypoints for
Windows apps and call Linux APIs themselves.
> How am I to write this dll file so that when the fah gpu app calls for a
function the
> cudart.dll file acts as a link to the libcudart.so.2.0? I don't want to
attempt to
> rewrite the entire dll if I don't have to. To me it just seems like I am
not getting
> the picture. I know we can't simply link the two files because they are in
two
> different formats ELF vs PE. Is there a good example on how this is done?
I'm sure
> this has been done before. Again looking to the opengl_norm.c file all it
appears is
> that every functions has been rewritten but with "wine_" in front of the
function
> name. Is that all I need to do with the cudart? That just seem right.
You don't want to rewrite CUDA in the way we rewrite e.g. d3d9.dll, since
that would mean to talk to the GPU or driver directly without Nvidia's
libcudart.so.2.0. You just want to write functions that simply call the
function exported from the Linux library. For example, like in the opengl
stuff:
FancyCudaReturnValue wine_CudaSomeFunc(int a, int b) {
return CudaSumeFunc(a, b);
}
That's not really called a "rewrite"(e.g. look at ole32 to see what would be
considered a "rewrite"), but rather a thunk. Unfortunately it can still be a
a whole lot of typing work, unless you manage to write a script to generate
the thunks.
You have to take if there are some differences between the Linux and Windows
functions, e.g.:
Win32: CudaSomething(HWND window);
Linux: CudaSomething(XWindow window);
In this case you can't just pass the Windows specific data structure
along(Don't ask me how you would solve this exact issue here since only
winex11.drv is supposed to know about the HWND<->XWindow mappings.)
You also have to take care with filenames:
Win32: CudaSomething2(const char *filename);
Linux: CudaSomething2(const char *filename);
The Linux function would not be happy if you pass it a
"C:\Path\to\some\odd\place.txt", and likewise the Windows app will not be
happy if you pass it a "/home/user/my/fancy/location.txt" file returned from
cuda. For cases like these, Wine provides functions to translate paths.
Re: CUDA wrapper
Ok, please forgive my naivety but this is my first attempt and all, I am lost and need come guidance, the guide is of some help and so is looking at the opengl files. I am not sure exactly what I am trying to write. What is the difference between a dll form Wine and a dll.so? I know the dll.so end up in your linux /lib folder right? How does a dll communicate to this dll.so? How am I to write this dll file so that when the fah gpu app calls for a function the cudart.dll file acts as a link to the libcudart.so.2.0? I don't want to attempt to rewrite the entire dll if I don't have to. To me it just seems like I am not getting the picture. I know we can't simply link the two files because they are in two different formats ELF vs PE. Is there a good example on how this is done? I'm sure this has been done before. Again looking to the opengl_norm.c file all it appears is that every functions has been rewritten but with "wine_" in front of the function name. Is that all I need to do with the cudart? That just seem right. I probably should even be messing with this stuff, but the beautify of open source applications is that with a little help from the community I can add in support for things I need (CUDA). If this was a closed source app, I would have to just put in a request for it and maybe in a few months or so they might think about adding support. Thanks for your patience and help On Sun, Jul 6, 2008 at 10:13 PM, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Yes, this guide is reasonable, except probably the building part. You > *may* want to write this DLL as part of Wine, although I am afraid that we > don't have a policy how to deal with non-Windows DLLs(since cuda is an > Nvidia thing, not from MS). Of course the 5.5 part doesn't apply then as > well. > > > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Seth Shelnutt > *Sent:* Sunday, July 06, 2008 6:29 PM > *To:* Michael Karcher > *Cc:* wine-devel@winehq.org > *Subject:* Re: CUDA wrapper > > > > I writing a wrapper, would it be correct to more or less follow this guide, > on winelib dll's? http://www.winehq.org/site/docs/winelib-guide/bindlls > > I've never coded anything for Wine before so I want to make sure I do it > right from the beginning instead of having to go back and make drastic > changes. > > I'll be looking at that opengl32 perl script because there is 102 pages of > functions that cudart.dll and libcudart.so both contain. > > On Sun, Jul 6, 2008 at 6:53 PM, Michael Karcher < > [EMAIL PROTECTED]> wrote: > > This is not going to work. PE style dynamic linking works quite > different from ELF style dynamic linking. Wine can not link native ELF > libraries to windows applications. The .dll.so files from wine are > special in being ELF files but containing extra information that allows > the Wine dynamic linker to link it into PE processes. > > > > > > This is right. You need at least a correct .spec file to make a wine > dll. You still have to implement a wrapper for each function, as Windows > usually uses the stdcall calling convention, whereas linux uses cdecl by > default. There might be some way to automate writing the wrapper > functions. > > Regards, > Michael Karcher > > >
RE: CUDA wrapper
Yes, this guide is reasonable, except probably the building part. You *may* want to write this DLL as part of Wine, although I am afraid that we don't have a policy how to deal with non-Windows DLLs(since cuda is an Nvidia thing, not from MS). Of course the 5.5 part doesn't apply then as well. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Shelnutt Sent: Sunday, July 06, 2008 6:29 PM To: Michael Karcher Cc: wine-devel@winehq.org Subject: Re: CUDA wrapper I writing a wrapper, would it be correct to more or less follow this guide, on winelib dll's? http://www.winehq.org/site/docs/winelib-guide/bindlls I've never coded anything for Wine before so I want to make sure I do it right from the beginning instead of having to go back and make drastic changes. I'll be looking at that opengl32 perl script because there is 102 pages of functions that cudart.dll and libcudart.so both contain. On Sun, Jul 6, 2008 at 6:53 PM, Michael Karcher <[EMAIL PROTECTED]> wrote: This is not going to work. PE style dynamic linking works quite different from ELF style dynamic linking. Wine can not link native ELF libraries to windows applications. The .dll.so files from wine are special in being ELF files but containing extra information that allows the Wine dynamic linker to link it into PE processes. This is right. You need at least a correct .spec file to make a wine dll. You still have to implement a wrapper for each function, as Windows usually uses the stdcall calling convention, whereas linux uses cdecl by default. There might be some way to automate writing the wrapper functions. Regards, Michael Karcher
Re: CUDA wrapper
I writing a wrapper, would it be correct to more or less follow this guide, on winelib dll's? http://www.winehq.org/site/docs/winelib-guide/bindlls I've never coded anything for Wine before so I want to make sure I do it right from the beginning instead of having to go back and make drastic changes. I'll be looking at that opengl32 perl script because there is 102 pages of functions that cudart.dll and libcudart.so both contain. On Sun, Jul 6, 2008 at 6:53 PM, Michael Karcher < [EMAIL PROTECTED]> wrote: > This is not going to work. PE style dynamic linking works quite > different from ELF style dynamic linking. Wine can not link native ELF > libraries to windows applications. The .dll.so files from wine are > special in being ELF files but containing extra information that allows > the Wine dynamic linker to link it into PE processes. > > > This is right. You need at least a correct .spec file to make a wine > dll. You still have to implement a wrapper for each function, as Windows > usually uses the stdcall calling convention, whereas linux uses cdecl by > default. There might be some way to automate writing the wrapper > functions. > > Regards, > Michael Karcher > > >
RE: CUDA wrapper
> This is right. You need at least a correct .spec file to make a wine > dll. You still have to implement a wrapper for each function, as > Windows > usually uses the stdcall calling convention, whereas linux uses cdecl > by > default. There might be some way to automate writing the wrapper > functions. opengl32.dll has a perl script for that I think
Re: CUDA wrapper
Am Sonntag, den 06.07.2008, 18:23 -0400 schrieb Seth Shelnutt: > Is it possible to just symbolicly link the cudart.dll file to the > libcudart.so file? If they are expecting mostly the same function > calls should this not work? They are going to test this now and see. This is not going to work. PE style dynamic linking works quite different from ELF style dynamic linking. Wine can not link native ELF libraries to windows applications. The .dll.so files from wine are special in being ELF files but containing extra information that allows the Wine dynamic linker to link it into PE processes. > I believe the main problem is just that cudart.dll is driving to > access the windows nvidia driver where this is none, but libcudart.so > knows how to access the linux driver. This is right. You need at least a correct .spec file to make a wine dll. You still have to implement a wrapper for each function, as Windows usually uses the stdcall calling convention, whereas linux uses cdecl by default. There might be some way to automate writing the wrapper functions. Regards, Michael Karcher
Re: CUDA wrapper
>From reading the programing guide and reference manual it seems that most of the function are the same as expected between Windows and Linux, in fact the reference manual doesn't differentiate between the two. http://developer.download.nvidia.com/compute/cuda/2.0-Beta2/docs/Programming_Guide_2.0beta2.pdf http://developer.download.nvidia.com/compute/cuda/2.0-Beta2/docs/CudaRefMan_2.0beta2.pdf Is it possible to just symbolicly link the cudart.dll file to the libcudart.so file? If they are expecting mostly the same function calls should this not work? They are going to test this now and see. I believe the main problem is just that cudart.dll is driving to access the windows nvidia driver where this is none, but libcudart.so knows how to access the linux driver.
CUDA wrapper
As a continuation from the question on making the FAH GPU2 Nvidia client run, we have gotten past the detecting the card as we changed Wine's generic output to look like an Nvidia card thanks to a few of you. Now comes the hard part. Even when using the cudart.dll file it does not work. We get an cudastream error about it not being implemented. It then repeats these 5 lines until the client is stopped. Reading file work/wudata_07.tpr, VERSION 3.1.4 (single precision) Reading file work/wudata_07.tpr, VERSION 3.1.4 (single precision) Reading sasa-enabled ir 0 0 Initializing Nvidia gpu library cudaMalloc CUDAStream::Allocate failed feature is not yet implemented Martijn Berger said here ( http://www.winehq.org/pipermail/wine-devel/2008-July/067063.html) that all that should need to be done is right a wrapper to translate the calls from cudart.dll to libcuda.so.2.0. I suppose the place to start would be to download the SDK's and see how much documentation is available on both the Linux and Windows calls. -Seth Shelnutt
