Hi Matthew, please, discuss this kind of change before the commit. our cdbs directory affects all KDE4 packages.> Added: > branches/kde4/cdbs/cpu-optimize.mk > Log: > CPU optimization definitions for cdbsi''m not convinced by this change. only rsibreak needs it afaics. cheers, Fathi ps: irc isn''t/must not be our primary way of discussion ;)
On Sat, 02 Feb 08 17:04, Fathi Boudra wrote:> i''m not convinced by this change. > only rsibreak needs it afaics.And one important point is, that we win nothing with this change. When building for i386 we can''t use these Options, because out in the wild are still some old boxes which don''t support MMX (but are officially supported by Debian!). That''s the reason why we have to stick with RT detection of the capabilities of a processor. When building for AMD64 these Options are enabled anyway. No matter what we do. I guess something like this holds true for PPC too. Greetings, Armin
On Saturday 02 February 2008, Armin Berres wrote:> On Sat, 02 Feb 08 17:04, Fathi Boudra wrote: > > i''m not convinced by this change. > > only rsibreak needs it afaics. > > And one important point is, that we win nothing with this change. > When building for i386 we can''t use these Options, because out in the > wild are still some old boxes which don''t support MMX (but are > officially supported by Debian!). That''s the reason why we have to stick > with RT detection of the capabilities of a processor.The patches uses the blitz cpu runtime detection. /Sune -- Do you know how to ping to the case? First you cannot rename the graphic DLL case in order to forward from the shell to a bus. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080202/6a76b367/attachment.pgp
On Sat, 02 Feb 08 19:06, Sune Vuorela wrote:> The patches uses the blitz cpu runtime detection.The patch you mention is completely fine with me. What we are talking about here is branches/kde4/cdbs/cpu-optimize.mk. Cheers, Armin
On Sat, Feb 02, 2008 at 05:04:06PM +0100, Fathi Boudra wrote:> ps: irc isn''t/must not be our primary way of discussion ;) >Full ACK, Ana, who goes in full VAC mode again.
On Saturday 02 February 2008, Armin Berres wrote:> And one important point is, that we win nothing with this change. > When building for i386 we can''t use these Options, because out in the > wild are still some old boxes which don''t support MMX (but are > officially supported by Debian!). That''s the reason why we have to stick > with RT detection of the capabilities of a processor. > When building for AMD64 these Options are enabled anyway. No matter what > we do. > I guess something like this holds true for PPC too.This patch isn''t a replacement for detecing MMX & friends at runtime. Rather, it''s used to check the CPU at build time to avoid building the MMX code paths entirely on archs that don''t support them. It was mostly inspired from the qimageblitz code, take a look at the patch for rsibreak: +#ifdef HAVE_MMX + if(BlitzCPUInfo::haveExtension(BlitzCPUInfo::MMX)) + scanline_blend_mmx(over, m_alpha, under, result, m_image->width); + else +#endif + scanline_blend(over, m_alpha, under, result, m_image->width); I expect we might see more of this kind of optimisation, so I put the rules in a shared location. It isn''t used unless explicitly included, so it won''t affect any packages not using it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080202/a3e8efb4/attachment.pgp
> I expect we might see more of this kind of optimisation, so I put the rules > in a shared location. It isn''t used unless explicitly included, so it won''t > affect any packages not using it.I''ll propose to think about the move to our cdbs shared location when we''ll see more of this kind of optimisation and it''ll become really useful, not before.
reverted. On Feb 2, 2008 9:56 PM, Fathi Boudra <fboudra at gmail.com> wrote:> > I expect we might see more of this kind of optimisation, so I put the > rules > > in a shared location. It isn''t used unless explicitly included, so it > won''t > > affect any packages not using it. > > I''ll propose to think about the move to our cdbs shared location > when we''ll see more of this kind of optimisation and > it''ll become really useful, not before. >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080204/7ecb1a05/attachment.htm