On Tue, Oct 23, 2012 at 9:08 AM, Pascal de Bruijn <[email protected]> wrote: > 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).
So, I got it to work: https://github.com/darktable-org/darktable/commit/42afafa8cdb676dd216428f2ba71ad54fcc606a0 So I added the option to the already existing very conservative defaults detection. This code would trigger anyhow on older type Atoms (32bit only/single core). But newer type Atoms are 64bit dual-core and hyperthreaded. 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
