CUDA and MinGW compilation trouble

[bART Janssens-2]

Hi all,

I have been trying to build the CUDA module on Win32 again. From the
CUDA side, things are simple, in theory, and there are two options:

1. Pass "--foreign" to nvcc. This will attempt to use gcc on win32 insead of cl.
2. Use nvcc to compile, i.e. pass "-c" instead of "-cuda" to nvcc.
This uses MSVC to compile.

In practice, of course, things are complicated :)

Using 1, the cudafe.exe distributed with CUDA crashes, and I have no idea why.
Using 2, the cuda_entry_points.obj file can not be linked to the rest
of the module, because it is built with Visual Studio (see dump at the
end of this mail). Anyone know of any Visual Studio or MinGW magic to
fix this? From what I understand, MinGW can somehow link to (some?)
native win32 libs.

-----------------------------------------------
[ 44%] Generating cuda_entry_points.obj
cd C:\workspace\k3d\build-release\modules\cuda_bitmap &&
C:\CUDA\bin\nvcc.exe -c -I C:/workspace/k3d -I
C:/workspace/k3d/k3dsdk/gil -I C:/workspace/k3d/build-release/k3dsdk
-I c:/boost/include/boost_1_34_1 -I C:/gtk/include/glibmm-2.4 -I
C:/gtk/lib/glibmm-2.4/include -I C:/gtk/include/sigc++-2.0 -I
C:/gtk/lib/sigc++-2.0/include -I C:/gtk/include/glib-2.0 -I
C:/gtk/lib/glib-2.0/include -I c:/gtk/include -I C:/CUDA/include -I
"C:/Program Files/NVIDIA Corporation/NVIDIA CUDA SDK/common/inc" -o
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj
C:/workspace/k3d/modules/cuda_bitmap/cuda_entry_points.cu
cuda_entry_points.cu
tmpxft_00000600_00000000-3_cuda_entry_points.cudafe1.gpu
tmpxft_00000600_00000000-8_cuda_entry_points.cudafe2.gpu
tmpxft_00000600_00000000-3_cuda_entry_points.cudafe1.cpp
tmpxft_00000600_00000000-12_cuda_entry_points.ii
Scanning dependencies of target k3d-cuda-bitmap
"C:\Program Files\CMake 2.4\bin\cmake.exe" -E cmake_depends "MinGW
Makefiles" C:\workspace\k3d C:\workspace\k3d\modules\cuda_bitmap
C:\workspace\k3d\build-release
C:\workspace\k3d\build-release\modules\cuda_bitmap
C:\workspace\k3d\build-release\modules\cuda_bitmap\CMakeFiles\k3d-cuda-bitmap.dir\DependInfo.cmake
make[2]: Leaving directory `C:/workspace/k3d/build-release'
make -f modules/cuda_bitmap/CMakeFiles/k3d-cuda-bitmap.dir/build.make
modules/cuda_bitmap/CMakeFiles/k3d-cuda-bitmap.dir/build
make[2]: Entering directory `C:/workspace/k3d/build-release'
Linking CXX shared library ../../lib/k3d/plugins/k3d-cuda-bitmap.module
cd C:\workspace\k3d\build-release\modules\cuda_bitmap && "C:\Program
Files\CMake 2.4\bin\cmake.exe" -P
CMakeFiles\k3d-cuda-bitmap.dir\cmake_clean_target.cmake
cd C:\workspace\k3d\build-release\modules\cuda_bitmap && "C:\Program
Files\CMake 2.4\bin\cmake.exe" -E cmake_link_script
CMakeFiles\k3d-cuda-bitmap.dir\link.txt --verbose=1
C:\mingw\bin\g++.exe   -Wl,--enable-runtime-pseudo-reloc
-Wl,--export-all-symbols -shared -o
..\..\lib\k3d\plugins\k3d-cuda-bitmap.module
-Wl,--out-implib,../../lib/k3d/plugins/libk3d-cuda-bitmap.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
"CMakeFiles/k3d-cuda-bitmap.dir/cuda_add.obj"
"CMakeFiles/k3d-cuda-bitmap.dir/module.obj"
"C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj"
-LC:\Boost\lib -LC:\GTK\lib -LC:\workspace\k3d\build-release\bin
-LC:\CUDA\bin -LC:\PROGRA~1\NVIDIA~1\NVIDIA~1\common\lib -lk3dsdk
-lintl -lcudart -lcutil32 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0
-lglib-2.0 -liconv -lsigc-2.0 -lxml2 -lz -lk3dsdk-half
-lk3dsdk-sgi-tesselator -lk3dsdk-glew -lopengl32 -lglu32
-lk3dsdk-parallel -lole32 -lws2_32
Info: resolving vtable for k3d::plugin_factoryby linking to
__imp___ZTVN3k3d14plugin_factoryE (auto-import)
Info: resolving VTT for k3d::plugin_factory by linking to
__imp___ZTTN3k3d14plugin_factoryE (auto-import)
Creating library file: ../../lib/k3d/plugins/libk3d-cuda-bitmap.dll.a
Warning: .drectve `/DEFAULTLIB:"libcpmt" /DEFAULTLIB:"LIBCMT"
/DEFAULTLIB:"OLDNAMES" ' unrecognized
Cannot export ??$cudaLaunch@D@@YA?AW4cudaError@@PAD@Z: symbol not found
Cannot export ??0dim3@@QAE@III@Z: symbol not found
Cannot export ?iDivUp@@YAHHH@Z: symbol not found
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x3a):
undefined reference to `__security_cookie'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x48):
undefined reference to `cudaGetDeviceCount@4'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x58):
undefined reference to `__iob_func'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x95):
undefined reference to `cudaGetDeviceProperties@8'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0xb4):
undefined reference to `__iob_func'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0xd2):
undefined reference to `cudaSetDevice@4'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0xf4):
undefined reference to `cudaMalloc@8'
make[2]: Leaving directory `C:/workspace/k3d/build-release'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x107):
undefined reference to `cudaMemcpy@16'
make[1]: Leaving directory `C:/workspace/k3d/build-release'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x172):
undefined reference to `cudaConfigureCall@32'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x1a6):
undefined reference to `cudaMemcpy@16'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x1af):
undefined reference to `cudaFree@4'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x1b9):
undefined reference to `@__security_check_cookie@4'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x1da):
undefined reference to `__cudaUnregisterFatBinary@4'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x1f6):
undefined reference to `cudaSetupArgument@12'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x210):
undefined reference to `cudaSetupArgument@12'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x22a):
undefined reference to `cudaSetupArgument@12'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x244):
undefined reference to `cudaSetupArgument@12'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x279):
undefined reference to `__cudaRegisterFatBinary@4'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text+0x2a4):
undefined reference to `__cudaRegisterFunction@40'
C:/workspace/k3d/build-release/modules/cuda_bitmap/cuda_entry_points.obj:(.text[??$cudaLaunch@D@@YA?AW4cudaError@@PAD@Z]+0x8):
undefined reference to `cudaLaunch@4'
collect2: ld returned 1 exit status
-----------------------------------------------------

Cheers,

--
Bart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Mon, Apr 28, 2008 at 10:44 PM, Bart Janssens
<bart.janssens@...> wrote:
>  I have been trying to build the CUDA module on Win32 again. From the
>  CUDA side, things are simple, in theory, and there are two options:
>
>  1. Pass "--foreign" to nvcc. This will attempt to use gcc on win32 insead of cl.
>  2. Use nvcc to compile, i.e. pass "-c" instead of "-cuda" to nvcc.
>  This uses MSVC to compile.

Good news! Evan's CUDA module builds on Win32 now and can be linked to
K-3D using MinGW. Basically, the steps are as follows:
1. Put all functions that use CUDA in a .h/.c file, declaring them
using __declspec(dllexport) in the .h file.
2. Create a dll that exports these functions, using nvcc --shared
<flags, includes, ...> -o somelib.dll <.c and .cu source files>. This
way of calling nvcc invokes MSVC, and I think you need version 8.
3. Create a mingw import lib, using "pexports somelib.dll >
somelib.def" and then "dlltool -d somelib.def -l libsomelib.a
4. Build the rest of the module normally, linking in the import
library using -lsomelib and an -L that points to its dir

I have attached a badly hacked together patch that does this for the
cuda_bitmap module. The somelib.dll should find it's way into the path
somehow. The INSTALL command I added in my patch does nothing for some
reason, so you need to copy it manually.

For a more elegant solution, I suggest putting the cuda library of
step 2 in a subdir of k3dsdk, i.e. k3dsdk/cuda. That way, any modules
that want to use CUDA can simply include it in the
TARGET_LINK_LIBRARIES command. I think this has to be a C library,
otherwise the exported symbols are mangled in a way MinGW can't read.

While testing the resulting binary, I also turned off the
CUDA_EMULATION option. Apparently, on Win32 the hardware does get
used, so I must be having driver problems on linux. The result of
running the current dashboard test for a 3008x2000 file is 14.8s for
the CUDA version, versus 17.5s for the CPU BitmapAdd filter.

Cheers,

--
Bart


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:
> Good news! Evan's CUDA module builds on Win32 now and can be linked to
> K-3D using MinGW. Basically, the steps are as follows:
> 1. Put all functions that use CUDA in a .h/.c file, declaring them
> using __declspec(dllexport) in the .h file.
This would need to be conditional based on the platform, que no?

> For a more elegant solution, I suggest putting the cuda library of
> step 2 in a subdir of k3dsdk, i.e. k3dsdk/cuda. That way, any modules
> that want to use CUDA can simply include it in the
> TARGET_LINK_LIBRARIES command. I think this has to be a C library,
> otherwise the exported symbols are mangled in a way MinGW can't read.
>  
How could this be part of the SDK?  These are the plugin-specific
implementations we're talking-about, right?

Cheers,
Tim


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Fri, May 2, 2008 at 5:31 AM, Timothy M. Shead <tshead@...> wrote:
>  > 1. Put all functions that use CUDA in a .h/.c file, declaring them
>  > using __declspec(dllexport) in the .h file.
>  This would need to be conditional based on the platform, que no?

Yes, we need to wrap it in a macro that evaluates to nothing on
non-win32 platforms.

>  > For a more elegant solution, I suggest putting the cuda library of
>  > step 2 in a subdir of k3dsdk, i.e. k3dsdk/cuda. That way, any modules
>  > that want to use CUDA can simply include it in the
>  > TARGET_LINK_LIBRARIES command. I think this has to be a C library,
>  > otherwise the exported symbols are mangled in a way MinGW can't read.
>  >
>  How could this be part of the SDK?  These are the plugin-specific
>  implementations we're talking-about, right?

Well, I was thinking we could put generic methods in this lib, such as:
bitmap_to_device(const k3d bitmap, pointer to device memory)
bitmap_add_constant(pointer  to device memory, const scalar)
bitmap_to_host(const pointer to device memory, k3d bitmap)

Later on, we can add some operations for meshes, like point linear
transformation and so on.

This would mean we only need one k3dsdk-cuda.dll on windows. The
alternative (win32 only) would be to have one dll that has to be in
the search path for each module, often duplicating a lot of code. This
is purely a consequence of MinGW not being able to link in the objects
generated by nvcc, or compile its C output.

The advantage, even on linux, is that operations to move K-3D
structures to and from the device only need to be defined once.

regards,

--
Bart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Evan Lezar]

Hi Bart

Glad to hear you got it working. I dont have a decent internet
connection at the moment (I'm sending this from my mobile) but should
be back online by Saturday evening.

I have not had the chance to test under windows yet. I was slightly
put off by wendy's troubles :) but at least you get a slight speedup
(although that is quite a large dataset) it may be that other
operations give more improvement and there is still much tuning that
can be done.

I will have a look at your hack tomorrow.

Evan

On 5/2/08, Bart Janssens <bart.janssens@...> wrote:

> On Fri, May 2, 2008 at 5:31 AM, Timothy M. Shead <tshead@...> wrote:
> >  > 1. Put all functions that use CUDA in a .h/.c file, declaring them
> >  > using __declspec(dllexport) in the .h file.
> >  This would need to be conditional based on the platform, que no?
>
> Yes, we need to wrap it in a macro that evaluates to nothing on
> non-win32 platforms.
>
> >  > For a more elegant solution, I suggest putting the cuda library of
> >  > step 2 in a subdir of k3dsdk, i.e. k3dsdk/cuda. That way, any modules
> >  > that want to use CUDA can simply include it in the
> >  > TARGET_LINK_LIBRARIES command. I think this has to be a C library,
> >  > otherwise the exported symbols are mangled in a way MinGW can't read.
> >  >
> >  How could this be part of the SDK?  These are the plugin-specific
> >  implementations we're talking-about, right?
>
> Well, I was thinking we could put generic methods in this lib, such as:
> bitmap_to_device(const k3d bitmap, pointer to device memory)
> bitmap_add_constant(pointer  to device memory, const scalar)
> bitmap_to_host(const pointer to device memory, k3d bitmap)
>
> Later on, we can add some operations for meshes, like point linear
> transformation and so on.
>
> This would mean we only need one k3dsdk-cuda.dll on windows. The
> alternative (win32 only) would be to have one dll that has to be in
> the search path for each module, often duplicating a lot of code. This
> is purely a consequence of MinGW not being able to link in the objects
> generated by nvcc, or compile its C output.
>
> The advantage, even on linux, is that operations to move K-3D
> structures to and from the device only need to be defined once.
>
> regards,
>
> --
> Bart
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> K3d-development mailing list
> K3d-development@...
> https://lists.sourceforge.net/lists/listinfo/k3d-development
>

--
visit http://randomestrandom.blogspot.com

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Fri, May 2, 2008 at 11:47 AM, Evan Lezar <evanlezar@...> wrote:
>  I have not had the chance to test under windows yet. I was slightly
>  put off by wendy's troubles :) but at least you get a slight speedup

Yes, about those troubles: I have tried to make a "Debug" build on
Win32 since, and the k3dsdk-python failed to link because I didn't
have enough RAM (I have 2GB). You probably should disable debugging,
at least for that module, if you want to build on Win32. That said, I
like the linux environment a lot better for developing on K-3D. If you
work on the linux side, I don't mind adding the win32 tweaks. I'd
still at least try to install the win32 Nvidia drivers though, to be
sure your hardware is functioning properly.

>  (although that is quite a large dataset) it may be that other
>  operations give more improvement and there is still much tuning that
>  can be done.

Yes, it's not bad for a proof-of-concept!

Cheers,

--
Bart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

>>  > For a more elegant solution, I suggest putting the cuda library of
>>  > step 2 in a subdir of k3dsdk, i.e. k3dsdk/cuda. That way, any modules
>>  > that want to use CUDA can simply include it in the
>>  > TARGET_LINK_LIBRARIES command. I think this has to be a C library,
>>  > otherwise the exported symbols are mangled in a way MinGW can't read.
>>  >
>>  How could this be part of the SDK?  These are the plugin-specific
>>  implementations we're talking-about, right?
>>    
>
> This would mean we only need one k3dsdk-cuda.dll on windows. The
> alternative (win32 only) would be to have one dll that has to be in
> the search path for each module, often duplicating a lot of code. This
> is purely a consequence of MinGW not being able to link in the objects
> generated by nvcc, or compile its C output.
>  

My point was that the plugin-specific code *also* has to be compiled
separately by nvcc and stuck in a separate DLL ... or am I missing
something?

Cheers,
Tim


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On 5/3/08, Timothy M. Shead <tshead@...> wrote:
> My point was that the plugin-specific code *also* has to be compiled
> separately by nvcc and stuck in a separate DLL ... or am I missing
> something?

No. But maybe with careful design, most or all CUDA code could be in
the "main" CUDA dll? It seems cumbersome to have 2 dlls for each CUDA
module.

Regards,

--
Bart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On 5/3/08, Timothy M. Shead <tshead@...> wrote:
>  
>> My point was that the plugin-specific code *also* has to be compiled
>> separately by nvcc and stuck in a separate DLL ... or am I missing
>> something?
>>    
>
> No. But maybe with careful design, most or all CUDA code could be in
> the "main" CUDA dll? It seems cumbersome to have 2 dlls for each CUDA
> module.
>  

For the purposes of the project, my strong recommendation would be that
all CUDA-related plugins be deployed in a single CUDA module.  That is
consistent with all of our other modules that have dependencies on
third-party software.  If CUDA-related plugins start sweeping the
nation, we can split them up appropriately at that time.  *Even then*,
I'll make the point that code shared between modules, doesn't
automatically belong in the SDK.  Keep in mind that everything in the
SDK gets loaded at startup all-the-time, whether it's used or not -
stuffing functionality in the SDK offsets the value of on-demand
plugins.  There is nothing preventing two plugin modules from sharing a
dependency on a third library.

Cheers,
Tim




-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On 5/6/08, Timothy M. Shead <tshead@...> wrote:
> For the purposes of the project, my strong recommendation would be that
> all CUDA-related plugins be deployed in a single CUDA module.  That is
> consistent with all of our other modules that have dependencies on
> third-party software.  If CUDA-related plugins start sweeping the

Agreed! We should then simply look into creating a shared C library
(or at least a library exporting only extern "C" symbols) from the
cuda module dir, compiled by nvcc. This library should be installed so
the dynamic linker can find it at runtime (bin on win32, lib on linux,
I guess).

> nation, we can split them up appropriately at that time.  *Even then*,
> I'll make the point that code shared between modules, doesn't
> automatically belong in the SDK.  Keep in mind that everything in the
> SDK gets loaded at startup all-the-time, whether it's used or not -
> stuffing functionality in the SDK offsets the value of on-demand
> plugins.  There is nothing preventing two plugin modules from sharing a
> dependency on a third library.

OK, the idea was to put it in a subdirectory of k3dsdk, like the
subdivision_surface code. Unless I missed something, this only gets
loaded when the first plugin that uses it gets loaded, right?

Cheers,

--
Bart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:
> OK, the idea was to put it in a subdirectory of k3dsdk, like the
> subdivision_surface code. Unless I missed something, this only gets
> loaded when the first plugin that uses it gets loaded, right?
>  
Point well-taken, I misunderstood your suggestion.  Having said that, my
point remains - the goal is to keep as much functionality in plugins and
out of the SDK as possible.

Cheers,
Tim


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development