On 01/05/11 16:47, Ralf Corsepius wrote: Yes, I still have VSs bug (514991) regarding opt flags still open. So, for the lesser CPU problem, does that mean I just suggest, rebuild srpm on their machine ? Can I add that minimum CPU requirement to package description ? If a user wanted to rebuild srpm for their CPU, would it be acceptable to place some sort of conditional in the spec make line, so that the local CPU build could use a suitable Instruction Set ? Would it still be worth adding a CPU detect script to avoid abrt traces from non-compatible CPU machines. In this case, could it just exit, or leave a message to suggest the user to obtain and rebuild the srpm ?

On 01/05/11 17:41, Hans de Goede wrote: Where is that stated currently, and for older releases ? Though it comes at the cost of audio lag/latency increase when we are trying to achieve near real time (eg live guitar input to sound effect generation output). Even on the my machine (4x core amd 3Ghz), the calculations the app performs for difficult presets (convolution) can cause jack to abort because rakarrack didn't finish it's calculations before it was required to deliver data. Should I be suggesting to upstream to attempt to detect CPU before running non-available instructions, eg as part of app startup ? Can that even be done (reliably) ? Thanks for your input.

Am 01.05.2011 09:56, schrieb David Timms: ffmpeg has since years a option "--enable-runtime-cpudetect" what makes the binary a little larger but let it run on all CPUs with good performance so yes, it is possible

David Timms wrote: Yes, this is the ONLY solution that's acceptable for binary packaging in distributions. Otherwise, we can only build the most generic version. (The current packages which enable whatever happens to be supported on the build system are completely broken and shouldn't have passed review.) Yes, all the packages which have WORKING support for SSE etc. in Fedora do that. See e.g. https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master... https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master... https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master... for the implementation Solid (in kdelibs) uses. Kevin Kofler

On Mon, May 02, 2011 at 08:50:48AM +1000, David Timms wrote: This isn't possible in general. Disassembling the code (objdump -d) will give you a subset of instructions that it could possibly execute, but no indication (without considerable extra manual work) of what instructions it would actually execute. Plus you'd then need to sit there with the Intel and AMD PRMs trying to work out which instruction corresponds to which CPU feature. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v

On 02/05/11 11:01, Reindl Harald wrote: OK, thanks all responders for clear logic and possible solutions.

Jan Kratochvil wrote: Are there any caveats (initialization order or so) when using this feature? E.g. would one get away with calling something like http://api.kde.org/4.0-api/kdelibs-apidocs/solid/html/tutorial3.html (i.e. Solid::Processor::instructionSets) in the ifunc or would trying to call such C++ classes lead to errors or unpredictable behavior? And I presume this is available on ELF glibc targets only, isn't it? Kevin Kofler

Hi, On 05/01/2011 09:56 AM, David Timms wrote: I was hoping someone who knows the exact answer knows... All I can give you is: http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/index.ht... Which is not really exact... As already answered by others ideal would be one binary, which runtime chooses between normal C and mmx/sse#/whatever variants based on CPU capabilities. This is definitely something to ask to upstream, as this won't be trivial. In the mean time, you need to patch the build-system so that you can control what cpu features it will enable, then you can build a number of variants, install them as /usr/libexec/%{name}-$cpufeaturepostfix And make /usr/bin/%{name} a shell script which checks /cpu/procinfo for features and then executes the right binary (passing through all cmdline args using the "$@" magic var for proper quoting) For which variants it makes sense to build, you would need to talk to someone who is more of a cpu head then me, try starting a new thread, with an appropriate $subject. Note that all of this is only really needed on 32 bits, on 64 bit I believe (*) all cpu's have at least sse2, so unless you want to use sse3 you'll only need 1 binary there. Which brings us to a simpler alternative, build a no cpu specific optimizations 32 bit version and use sse2 on x86_64, which is nice and simple. You could then add a README.fedora advising people to use the 64 bit version. Regards, Hans *) Still no CPU head, better verify this with someone who is.