CUDA wrapper

Stefan Dösinger stefan at codeweavers.com
Sun Jul 6 22:04:09 CDT 2008


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





More information about the wine-devel mailing list