Hi hi,
2013/8/13 Karl Rupp <r...@iue.tuwien.ac.at>
> Hi,
>
> > On GPUs with 16kB of shared memory (e.g. GTX 285), the generated
> > GEMM kernels now exceed the available memory:
> >
> > Log: ptxas error : Entry function 'kernel_0x207f4b0_0' uses too
> > much shared data (0x40a0 bytes + 0x10 bytes system, 0x4000 max)
> >
> > This is because of
> > __local float lhs_buf[4128];
> > which is more than the total 16kB of shared memory (already ignoring
> > some overhead for kernel parameters, etc.). Phil, could you please
> > cut this default down to only half the work group size, i.e. half
> > the shared memory?
> >
> > I also got a CL_INVALID_WORK_GROUP_SIZE in
> > blas3_prod_double-test-opencl, but this may be a follow-up issue.
> >
> >
> >
> > Okay, I will do that :) This brings back another thing I wanted to
> > discuss. Since any device for a given vendor can have 16kB of shared
> > memory, this means that the vendor defaults will actually have to be
> > very conservative. A way to solve this issue is to have some "generation
> > defaults"... the problem is that it is pretty difficult to achieve
> > without parsing the device name, which is a bit dirty in my opinion...
> > Do you think this is a good idea?
>
> We can directly query the available local device memory (which is the
> reason why I added all this buffering to the device class). Am I missing
> something?
>
Yes, we could. But having the combination {vendor, local memory} seems a
bit weird to me, I think {vendor, generation} makes more sense, don't you
think?
Best regards,
Philippe
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
