On Oct 27, 2009, at 9:51 PM, Casimiro de Almeida Barreto wrote:

> Em 28-10-2009 02:14, Andreas Raab escreveu:
>> Casimiro de Almeida Barreto wrote:
>>> I'm considering to build a package to allow the development of math
>>> using GPUs (NVIDIA). Would like to know about general interest in  
>>> this
>>> topic and some guidelines to put it in squeak trunk.
>>
>> I'm only responding to the trunk question here since I can't speak  
>> for
>> others about their GPGPU interests (I have a floating interest in it
>> but I've never spent much time trying things out).
>>
>> For the trunk inclusion, I think that at this point we're trying to
>> get the trunk smaller rather than larger. Even though we have been
>> adding a few packages, most of them were low-impact and very
>> high-value for the community at large (think syntax highlighting for
>> example). Outside of that we're trying to make things unloadable so
>> that the trunk can actually get smaller instead of larger. From this
>> point of view the inclusion of a GPGPU package seems unlikely.
> The idea is not really "include/put in trunk" (since the idea of trunk
> was so well expressed in above paragraphs and previous discussions in
> this list) but avoiding to create something that brings conflict
> (dependencies, use of deprecated stuff, etc).


As you say below, there should be minimal dependencies on the trunk.

>
> GPGPU stuff is not essential and I don't think it will impact other
> packages except for the need to use FFI or alien. Since CUDA has not  
> MIT
> license and up to the moment OpenCL is "Apple stuff" (regarding to
> license)


It's not "Apple stuff".  Nvidia has a conformant OpenCL 1.0  
implementation (for Windows, and I believe Linux), and AMD has one in  
beta.

There is no licensing issue, any more than there is for OpenGL.   
There's no problem with writing an MIT-licensed program that  
dynamically links (or uses FFI, same thing) against Apple's OpenGL  
implementation.  Croquet does this, as do many other Open Source  
programs.

Of course, depending on the vendor, there may be restrictions on  
redistributing their DLL.  Apple probably wouldn't let you (but they  
wouldn't need to, since OpenCL is always there on 10.6).  Nvidia  
probably would let you, just as they do with "cg.dll" (but you'd have  
to actually look at their OpenCL license; I haven't).

There is a technical issue of how to do the "linking" on Windows.  For  
OpenGL, there is a file "opengl32.dll" that acts as a front-end for  
drivers provided by Nvidia, AMD, etc.  I don't believe that this  
exists yet for OpenCL; for now you'd have to use  
"nvidia_opencl.dll" (or whatever the name actually is) explicitly in  
the FFI spec.  Croquet has code in its FFI binding to OpenGL that can  
be adapted to deal with this.


> and is no more than a framework, one possible approach is to
> use Open GL Mesa/glew/glut to get things done.


Trust me, you don't want to do that.  Especially if you don't know  
that you don't want to do that ;-)

If you don't believe me, first go to gpgpu.org and look in the forums  
for links to old framework code that abstracts away *some* of the pain  
of GPGPU-on-OpenGL (I think that Mark Harris wrote one).  Read that  
code, and some programs that use it.  Then, read the OpenCL 1.0 spec.   
You will be convinced, I promise ;-)

Anyway, it sounds like a cool project.  I hope that you keep us  
updated with your progress!

Cheers,
Josh



> Up to the moment FFI is
> the choice since it works well with trunk. I guess that if FFI keeps  
> ok
> with trunk I'll have no problems.
>
> Well. It's 02:51AM so I guess I'll take a nap... :D
>>
>> However, there is an open question of what set of packages we will
>> redistribute with the next release and how to determine what should  
>> be
>> in that set of packages. We haven't really had this discussion -  
>> there
>> are some open question as to which mechanism to use, so I would say
>> that if you'd like to have your package be ready for distribution  
>> with
>> the next Squeak release you:
>> a) Register the project on http://www.squeaksource.com/
>> b) Develop it and invite others to join you
>> c) Make sure that it works well and that people are aware of it
>>
>> In particular considering the last point, when the time comes to
>> discuss this issue you have something to point to, something that
>> hopefully others use as well, that will be compelling and an obvious
>> choice for distribution.
>>
>> Cheers,
>>  - Andreas
>>
>>
> Cheers,
>
> CdAB
>
>