Hey, > I've pushed the changes. Does it solve the GTX285 case?
thanks, it does! > The policy is : > > - One global GPU fallback (very conservative) > - One global CPU fallback (very conservative) > - One global Accelerator fallback (very conservative) > -One Fallback per architecture family > -------- > if the vendor is not in the database, return the global fallback profile > if the vendor is in the database but the architecture fallback isn't, > return global fallback > if the vendor, architecture is in the database but not the name, test > architecture fallback. If the profile is invalid (work group size not > compatible, too much local size), returns the global fallback. Else, > return the architecture fallback > If everything is fine, return the specific device profile. Looks good to me. Do we want to keep the full device name in the profiles map? With vendor and arch determined, we know pretty much everything we need to know. If we need to match the name 1:1, there may be too many devices which we miss even though the 'faster' profile should work? Oh, and btw: I don't think the profiles map is valgrind-clean... 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 ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
