On Tue, Oct 23, 2012 at 12:06 AM, johannes hanika <[email protected]> wrote: > On Tue, Oct 23, 2012 at 7:03 AM, Pascal de Bruijn <[email protected]> > wrote: >> On Mon, Oct 22, 2012 at 6:00 PM, Pascal de Bruijn <[email protected]> >> wrote: >>> On Sun, Oct 21, 2012 at 12:47 PM, Pascal de Bruijn <[email protected]> >>> wrote: >>>> Hi, >>>> >>>> I've recently got a (second-hand) netbook, it's an Asus 1215P, which >>>> has a 12" display (1366x768) and a dual core Atom CPU 1.5ghz. >>>> >>>> Because it's not a 10" model (1024x600) Darktable is quite usable on >>>> it, except that it's not superfast, but still bearable to an extent. >>>> >>>> However, I've noticed the demosaicing option is rather important: >>>> >>>> "demosaicing for zoomed out darkroom mode" >>>> >>>> always bilinear ~ 5 seconds to load >>>> at most ppg ~ 10 seconds to load >>>> >>>> So this has a rather big impact on this little CPU that couldn't :) >>>> >>>> That said, I think our new default (at most ppg) is fine for modern >>>> proper computers. Still it would be rather cool if we could do some >>>> simply CPU type detection, where (at first start) we look for what CPU >>>> is present in the system, and if it is an Atom CPU we default to >>>> always bilinear instead: >>> >>> And cutting through the noise... >>> >>> I think I'll be looking into this: >>> http://savannah.nongnu.org/projects/proccpuinfo >> >> Ok, so that might be a bit much... >> >> I've just cobbled together a >> not-so-portable-but-should-fail-gracefully test routine. >> >> gcc main.c >> ./a.out Intel >> ./a.out AMD >> >> (for example) >> >> When it's run on a platform that doesn't have /proc/cpuinfo it simply >> fails to detect said string, which isn't a problem for this use-case >> as it doesn't entail a major failure. It just means a default >> performance optimization will be missing (which we don't have now >> anyways). >> >> That said, are there any big concerns I might be missing? The source >> might need some prettification... >> >> Should this go into src/common/utility.c? >> >> And where should I hook in the detection routine? As we only want to >> check this when Darktable's database is initially generated (so only >> for new installs)... > > you're looking for void dt_configure_defaults() > (src/common/darktable.c:843) which is called once before darktablerc > is created, and never again (until you delete it). the accompanying > header comes with a memory detection function which parses > /proc/meminfo or does platform specific stuff. > > not sure what youre trying to achieve? get the number of teraflops in > the current machine?
No much simpler, just detect if it's an Atom (as detailed in my first mail)... And if so, degrade to bilinear demosaicing... > pulling in an additional library sounds overkill > just to parse cpuinfo to me, but i may be wrong. Yeah I know... Which is where the code snippet comes in (check the previously attached main.c). Regards, Pascal de Bruijn ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ darktable-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-devel
