Hi hi,
2013/7/30 Karl Rupp
> Hi Phil,
>
>
> > The generator code is pushed on the master branch.
>
> Cool, thanks. I actually wasn't expecting this to arrive in master today
> :-)
>
Haha, it's already more than one week late!
> I commented the commit on github. The short summary is:
>
> 1.)
Hi Phil,
> The generator code is pushed on the master branch.
Cool, thanks. I actually wasn't expecting this to arrive in master today
:-)
I commented the commit on github. The short summary is:
1.) I don't quite know/see why we need SYMBOLIC_*, since a true symbolic
operation could equally
Hi again !
The generator code is pushed on the master branch.
2013/7/28 Karl Rupp
> Hey,
>
>
>
> My preferred option is to pad by default and either to make the
>> padding a multiple of four or sixteen. However, we need to maintain
>> a full set of unpadded operations, because us
Hey,
> My preferred option is to pad by default and either to make the
> padding a multiple of four or sixteen. However, we need to maintain
> a full set of unpadded operations, because user-provided buffers
> need not be padded (and a subsequent padding may be too expensive)
>
>
Hi,
2013/7/28 Karl Rupp
> Hey,
>
>
> I'm proud to announce that after about 3weeks, I've recoded from scratch
>> the OpenCL code generator to integrate it fully with
>> viennacl::scheduler::**statement.
>>
>
> hurray :-) With the changes to the generator I pushed yesterday there is
> now a cle
Hey,
> I'm proud to announce that after about 3weeks, I've recoded from scratch
> the OpenCL code generator to integrate it fully with
> viennacl::scheduler::statement.
hurray :-) With the changes to the generator I pushed yesterday there is
now a clear spot on where to hand the expression over
