Hi Zack,

1) agreed. OpencCL is a complete different project and should exist in
a different repository.
1.1) Well use Gallium as CPU backend is a software dilemma:
"All problems in computer science can be solved by another level of
indirection...except for the problem of too many layers of
indirection"
But in my opinion we can use Gallium for CPU operations too, using
gallium as a backend for all device types we maintain a code
consistency.

2)Well the project live in a different repository, so we could use
CMake instead of SCons. Personally i prefer CMake, it is lot of fast
to generate Makefiles and easy to use.

3)I prefer C++ but as you said it could cause militant schism because
it is a complex language and many people do not like it. But i do not
care if we use C instead of C++ :).

Igor

On Wed, Dec 9, 2009 at 3:08 PM, Zack Rusin <za...@vmware.com> wrote:
> On Wednesday 09 December 2009 13:29:05 Igor Oliveira wrote:
>> These patchs implements and implements stub context methods in OpenCL.
>> Almost all operation in OpenCL use a context.
>> The patch implements the gallium3d context and implements the methods
>>  below:
>>
>> -clCreateContext
>> -clCreateContexFromType
>> -clRetainContext
>> -clReleaseContext
>>
>> ps: probably i show break it in 2 patchs
>
> Hi Igor,
>
> the patch looks ok. Thanks.
>
> we're just working on adding support for compute to Gallium so I'd probably
> wait a bit so that we can nail down the framework underneath before anything
> else. Also we have to decide the following issues before doing really
> anything:
>
> 1) should the opencl state tracker live in a repository of its own or should
> it live withing mesa3d repo like the other state trackers. The thing that
> makes the opencl state tracker a bit different is that it has to work on raw
> cpu (which is really subquestion to 1: should the opencl state tracker be able
> to work without gallium when working on top of a cpu). i didn't really feel
> like creating another branch of mesa and be merging things in initially which
> is why there is a separate repo right now.
>
> 2) should the opencl state tracker be using cmake or scons. originally i
> picked cmake because it generates actual makefile's and that's incredibly
> useful.
>
> 3) the language selection. it's using c++ because llvm is using c++ and
> because i dig c++, which is good enough for me but i guess it might cause
> militant schism.
>
> i'd also like to rename it to "coal" to make it fit better with the mesa and
> gallium naming.
>
> opinions?
>
> z
>

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to