CUDA wrapper

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

CUDA wrapper

Seth Shelnutt-2
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


Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
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.


Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Michael Karcher-5
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




Reply | Threaded
Open this post in threaded view
|

RE: CUDA wrapper

Stefan Dösinger-2
> 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





Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
In reply to this post by Michael Karcher-5
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 <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

RE: CUDA wrapper

Stefan Dösinger-2

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: [hidden email] [mailto:[hidden email]] On Behalf Of Seth Shelnutt
Sent: Sunday, July 06, 2008 6:29 PM
To: Michael Karcher
Cc: [hidden email]
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 <[hidden email]> 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

 



Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Seth Shelnutt
Sent: Sunday, July 06, 2008 6:29 PM
To: Michael Karcher
Cc: [hidden email]
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 <[hidden email]> 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

 




Reply | Threaded
Open this post in threaded view
|

RE: CUDA wrapper

Stefan Dösinger-2

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




Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2

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



cudart.dll.spec (11K) Download Attachment
cudart.c (14K) Download Attachment
cuda_runtime.h (16K) Download Attachment
cuda_runtime_api.h (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: CUDA wrapper

Stefan Dösinger-2

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:[hidden email]]
Sent: Monday, July 07, 2008 11:01 AM
To: Stefan Dösinger
Cc: [hidden email]
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



Reply | Threaded
Open this post in threaded view
|

CUDA wrapper

Seth Shelnutt-2

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 <[hidden email]> 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.

 





Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Juan Lang-4
In reply to this post by Stefan Dösinger-2
> 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


Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Juan Lang-4
In reply to this post by Seth Shelnutt-2
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


Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

John Klehm
On Mon, Jul 7, 2008 at 3:52 PM, Seth Shelnutt <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

CUDA wrapper

Seth Shelnutt-2
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 <[hidden email]> wrote:


Check the IMPORT variable in Makefile.in and see if everything you
need is listed.

--John




Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Juan Lang-4
In reply to this post by Seth Shelnutt-2
> 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 <GL/gl.h> here.
--Juan


Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
I have #include <GL/gl.h>, 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 <[hidden email]> 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 <GL/gl.h> here.
--Juan




cudart.c (15K) Download Attachment
cudart.dll.spec (11K) Download Attachment
Makefile (3K) Download Attachment
cuda-headers.tar.bz2 (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Juan Lang-4
> I have #include <GL/gl.h>, 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.000000000 -0700
+++ cudart.c    2008-07-07 14:54:57.000000000 -0700
@@ -1,8 +1,9 @@
 /*This is a wrapper for cudart.dll and libdudart.so.2.0*/


-#include <GL/gl.h>
 #include <stdlib.h>
+#include <windows.h>
+#include <GL/gl.h>
 #include <string.h>
 #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


Reply | Threaded
Open this post in threaded view
|

Re: CUDA wrapper

Seth Shelnutt-2
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 <[hidden email]> wrote:
> I have #include <GL/gl.h>, 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.000000000 -0700
+++ cudart.c    2008-07-07 14:54:57.000000000 -0700
@@ -1,8 +1,9 @@
 /*This is a wrapper for cudart.dll and libdudart.so.2.0*/


-#include <GL/gl.h>
 #include <stdlib.h>
+#include <windows.h>
+#include <GL/gl.h>
 #include <string.h>
 #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



12