I've held off putting this into 7.2 for now. It turns out that detecting the CPU instruction set is only half of the problem.
We are in the process of getting an updated toolchain for building on Windows which will allow us to detect if the OS is properly saving/restoring the new registers on a thread context switch. ----- Rom -----Original Message----- From: boinc_dev [mailto:[email protected]] On Behalf Of Juha Sent: Wednesday, July 24, 2013 5:10 PM To: David Anderson (BOINC) Cc: BOINC Developers Mailing List Subject: Re: [boinc_dev] : BOINC (windows) doesn't report avx processorfeature And that answers my question. Thank you. -Juha On 25 July 2013 00:00, David Anderson <[email protected]> wrote: > BOINC's approach is to collect as much info as possible in the client, > and to use this info in the server to make scheduling decisions. > > We recently added code in the client to detect AVX; this will appear > in the next client release. > > -- David > > > On 24-Jul-2013 1:38 PM, Juha wrote: > >> What's going on is: >> >> I think the best place to check for supported (=hardware+software) >> processor features is on the client--side. >> >> Everybody else thinks I'm being stupid for thinking that this could >> be a problem later on. And even if it turns out to be a problem they >> think the best place to check for the support is on the server-side >> and every project can code their own checks. >> >> -Juha >> >> >> On 24 July 2013 00:53, Wolfgang Schwieger <[email protected]> wrote: >> >> Maybe I am to stupid to understand what's going on, but..... >>> >>> BOINC reports a cpu feature (AVX) which the cpu has/or has not. >>> (that is what we need!) BOINC !_also_! reports the OS, the OS >>> version/kernel version, !_and_! the installed service pack (for >>> windows). >>> >>> So, if a project has an application with AVX code, the project (!!!) >>> has to decide if/or if not this application will run under an >>> "older" OS. >>> >>> BOINC just reports the feature, the project admin configures what >>> has to be configured. >>> >>> Wolfgang >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Juha >>> [mailto:juha.sointusalo@gmail.**com<[email protected]> >>> ] >>> Gesendet: Dienstag, 23. Juli 2013 22:58 >>> An: BOINC Developers Mailing List >>> Betreff: Re: [boinc_dev] [SPAM] Re: : BOINC (windows) doesn't report >>> avx processor feature >>> >>> On 23 July 2013 04:41, Michael Goetz <[email protected]> wrote: >>> >>> I'm not very worried about lock of OS support for AVX, at least as >>> far >>>> as PrimeGrid is concerned. >>>> >>>> * It's unlikely anyone has bought a pre-configured computer with an >>>> AVX capable CPU that came with a version of Windows that doesn't >>>> support >>>> >>> AVX. >>> >>>> >>>> * People who built their own systems and loaded XP?!?! on it are >>>> certainly able to load and run Linux if they wish to, and if they >>>> loaded Win 7 without SP1 they can load SP1. >>>> >>>> * It's unclear to me why anyone would buy, sell, or build a >>>> computer with an AVX CPU with an operating system that doesn't >>>> support the instruction set. It's possible, but unlikely. >>>> >>>> >>> Well, someone could have upgraded to a newer CPU, or replaced a >>> broken component without upgrading the OS at the same time. Or they >>> might be stuck with an older OS because they have some device for >>> which there's drivers only for, say, XP. Or they are forced for some >>> other reasons to keep using an older OS. There are reasons once you >>> start looking for them. >>> >>> And even if none of those hold, people still have the right to be >>> silly and keep using XP. >>> >>> >>> * There's about a 40% increase in speed with the AVX version of >>> that >>>> application, so if there's anyone participating in that subproject >>>> with such a computer, they probably will want to upgrade or switch >>>> their OS to take advantage of the increased performance. >>>> >>>> >>> That's a very nice speed-up. But you are assuming that: >>> 1. People are paying attention (to such details). Maybe at PrimeGrid >>> that's true but I doubt that's true generally speaking. At least at >>> Seti@homethere are people turning in thousands and thousands of >>> invalids so obviously they don't pay any attention to what their >>> computer does. >>> 2. People are buying or configuring their systems to crunch numbers. >>> True for some people but I think the majority buys computers for >>> some other reason and install BOINC to have something for the >>> computer to do while they read their emails. >>> >>> >>> * After all that, if there's actually someone who wants to run >>> their >>>> fancy new CPU with an OS that cripples its capabilities, I can >>>> always change the plan class to restrict the OS to versions that do >>>> support AVX. >>>> >>>> >>> There's one problem with that approach. Every project that releases >>> AVX application would need to add those restrictions. Wasn't BOINC >>> supposed to handle everything that's common to all projects so that >>> projects can then concentrate on doing whatever science they do? So >>> IMHO reliable information of host's capabilities is something that >>> BOINC should provide, one way or the other. >>> >>> So either the client should report only those processor features >>> that the OS supports or the scheduler should have a function >>> does_host_support_avx() that checks both the reported features and >>> the OS version. >>> >>> (Generally speaking. There's one benefit for the server side check. >>> If the host has support for feature X in hardware but not in >>> software, the server could tell the user "Your host has support for >>> feature X and we have an application that can take advantage of it. >>> But you need to install Y first." >>> Similar to what the server currently does with at least NVIDIA >>> drivers.) >>> >>> In short, while this is a theoretical problem, I don't think the >>> lack of >>> >>>> AVX support in old versions of Windows is a significant real world >>>> >>> problem. >>> >>>> >>>> >>> That may very well be true, but I still see it as something that >>> could be done better, if not even as a bug. >>> >>> -Juha >>> >>> >>> >>> ______________________________**_________________ >> boinc_dev mailing list >> [email protected] >> http://lists.ssl.berkeley.edu/**mailman/listinfo/boinc_dev<http://lis >> ts.ssl.berkeley.edu/mailman/listinfo/boinc_dev> >> To unsubscribe, visit the above URL and (near bottom of page) enter >> your email address. >> >> ______________________________**_________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/**mailman/listinfo/boinc_dev<http://list > s.ssl.berkeley.edu/mailman/listinfo/boinc_dev> > To unsubscribe, visit the above URL and (near bottom of page) enter > your email address. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
