Hi,
> 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?
{vendor, generation} is the natural format for the handling the profile
internally, yes. This will presumably involve string parsing of the
device name, yes :-(
However, the local memory available might vary between devices of the
same generation (think of desktop vs. mobile), so probably we extend it to:
{vendor, generation, min_local_mem_required}
If the device does not have enough local memory even though it is mapped
correctly to a certain generation, we simply fall back to a legacy
profile which stays within the 16kB.
Best regards,
Karli
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
