|
From: | >> G-LiTe / |
Subject: | Re: [xougen] Arch specific optimizations [XAA] |
Date: | Thu, 04 Sep 2003 15:23:16 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030902 Mozilla Thunderbird/0.2a |
emmanuel ALLAUD wrote:
Hi all, I've read on this list (was RENDER extension thread) that part of XFree were actually much slower than imlib2 IIRC. The problems boiled down to the fact that imlib2 uses MMX or other x586 specific asm instructions which allowes to be like 3 times faster (this is not an average, I don't think there is a global benchmark). My question is is that feasible (and desirable) to borrow some of this code (perhaps also from others good image manipualtion libs) and use it in XFree. I know this will be more troubles for portability, but if the functions to be arch-specific are well chosen (that's the hard part) ie only a few small functions with well determined purpose, this would give us good optimization without much hassle for the portability (the fallback being the old function if the arch has no specific version of the opt. function). Bye Manu
First of all: slashdot is great, isn't it? ;)Second: x586 is not an architecture, but it should be pretty obvious what you actually meant. ;) And finally: That article was indeed a comparison between Rasterman's IMLib 2 and XRender. The problem, however, was that XRender wasn't accelerated by most video drivers and thus not at all. It doesn't even use architecture specific optimizations, or it would've been as fast as IMLib. If I recall correctly, only nvidia and some other card's drivers have accelerated XRender. It would indeed be very nice to have this accelerated by the video drivers and possibly using OpenGL as described on the wiki somewhere. Architecture specific optimizations sound interesting too. Software XRender is one of the things we can optimize with this, I guess. (for X servers using VESA and the likes) I think we can definitly use some of IMLib's code for that and maybe even ask Rasterman himself to help. Portability shouldn't be a problem: it should be possible to just have it detect the architecture at some point, either at runtime or during the build process. An option for runtime would be nice for distributions.
--
> G-LiTe /
<address@hidden> --
[Prev in Thread] | Current Thread | [Next in Thread] |