Hi ho,
> However, my question was rather about packing multiple operations
> together, and specifically scoping the necessary kernel generator object
> (or more generally scoping the std::vector<statement> that has to be
> packed together for generation/execution)
> *bool code_generator::add(statement)*
> returns false if the statement is unsupported (or could not be packed).
> That way, if the generator does not support an operation, we can flush
> the queue first (to ensure that as many operations as possible were
> packed together), and then recurse further.The generation should be
> triggered when the scheduler's queue is flushed... which means that
> viennacl::ocl::flush();
So far the scheduler does not yet deal with multiple statements. I need
to get it stable for a single statement before experimenting with
multiple statements. This will happen carefully throughout the 1.5.x
series, it's too early for this now.
The flushes happen mostly implicitly: Either whenever the scheduler is
disabled (something like viennacl::scheduler::disable()), when data
needs to be copied back (flush on viennacl::copy()), or possibly also
whenever a reduction operation is encountered (inner_prod()). The latter
needs a more careful consideration in order not to run into
unstable/undefined situations, and on the other hand not to be too
pessimistic and thus give away optimization potential.
> Here is what I think would be appropriate
>
> -> Have some
> namespace viennacl{ namespace ocl{ generator::kernel_generator*
> kernel_generator; } }
> What should be its scope? We cannot really make it global since we're
> header-only and making it static global will create an independent
> kernel_generator in each compilation unit ...
I think there are two things to distinguish: One is a generator for just
a single statement (like custom_operation in earlier versions), and the
second is a larger instance managing previously generated kernels as
well. This larger instance should reside in viennacl::ocl::context, so
we can at least support per-context multithreading.
> -> viennacl::ocl::flush() should be rewritten into something like :
> if(kernel_generator)
> viennacl::generator::enqueue(*kernel_generator); //triggers
> generation, backend checking, and calls viennacl::ocl::enqueue on all
> the kernel.
> clFlush();
>
> However, this looks not really ideal to me... any other idea?
viennacl::ocl::flush() should not do anything other than call OpenCL's
flush(), everything else would be unexpected. Instead, we need to extend
viennacl::backend::finish() to flush the scheduler, so this could also
take care of flushing the generator.
Best regards,
Karli
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
