Normally I'd agree, but in this case it might be worth it... for windows ce
specifically, jeff muizelaar wrote a decompiler a while ago that could generate
msvc assembly from compiled gcc code, which seemed to be a good way to go.
MSVC doesn't do inline assembly on ARM anyway, so it would need
On Tue, 2010-03-16 at 19:22 +0100, Alexander Larsson wrote:
> On Tue, 2010-03-16 at 20:17 +0200, Siarhei Siamashka wrote:
> > On Tuesday 16 March 2010, Siarhei Siamashka wrote:
> > > On Tuesday 16 March 2010, Alexander Larsson wrote:
> > > > On Tue, 2010-03-16 at 16:51 +0200, Siarhei Siamashka wrot
On Tue, 2010-03-16 at 20:17 +0200, Siarhei Siamashka wrote:
> On Tuesday 16 March 2010, Siarhei Siamashka wrote:
> > On Tuesday 16 March 2010, Alexander Larsson wrote:
> > > On Tue, 2010-03-16 at 16:51 +0200, Siarhei Siamashka wrote:
> > > > Regarding the alex's branch and performance, I already me
On Tuesday 16 March 2010, Siarhei Siamashka wrote:
> On Tuesday 16 March 2010, Alexander Larsson wrote:
> > On Tue, 2010-03-16 at 16:51 +0200, Siarhei Siamashka wrote:
> > > Regarding the alex's branch and performance, I already mentioned that
> > > it was
> > > much slower for over__0565 case
From: Søren Sandmann Pedersen
These macros hide the various types of thread local support. On Linux
and Unix, they expand to just __thread. On Microsoft Visual C++, they
expand to __declspec(thread).
On OS X and other systems that don't have __thread, they expand to a
complicated concoction that
From: Søren Sandmann Pedersen
OS X does not support __thread, so we have to check for it before
using it. It does however support pthread_get/setspecific(), so if we
don't have __thread, check if those are available.
---
configure.ac | 80
So apparently OS X does not support __thread which means current
pixman does not compile there. See this:
http://tinderbox.x.org/builds/2010-03-16-0022/logs/pixman/#build
The following patches add some macros that expand to various types of
thread local support. On Linux, Unix, and Windows
On Tuesday 16 March 2010, Alexander Larsson wrote:
> On Tue, 2010-03-16 at 16:51 +0200, Siarhei Siamashka wrote:
> > Regarding the alex's branch and performance, I already mentioned that
> > it was
> > much slower for over__0565 case in my benchmark when compared
> > against my
> > branch on AR
On Tue, 2010-03-16 at 16:51 +0200, Siarhei Siamashka wrote:
>
> Regarding the alex's branch and performance, I already mentioned that
> it was
> much slower for over__0565 case in my benchmark when compared
> against my
> branch on ARM Cortex-A8 (the other cases of scaling are ok). I'm using
>
On Tuesday 16 March 2010, Alexander Larsson wrote:
> On Tue, 2010-03-16 at 13:26 +0100, Soeren Sandmann wrote:
> > * This chunk:
> >
> > if (unit_x >= 0)
> > while ...
> > else
> > while ...
> >
> > is repeated multiple times.
> >
> > Would it be possible
On Tue, 2010-03-16 at 13:26 +0100, Soeren Sandmann wrote:
> Hi,
>
> > On Mon, 2010-03-15 at 03:25 +0200, Siarhei Siamashka wrote:
> >
> > > But before it gets committed, some problems with potential fixed
> point
> > > overflows when dealing with large images need to be addressed. I
> have
> > >
On Tue, 2010-03-16 at 13:26 +0100, Soeren Sandmann wrote:
> Hi,
>
> > On Mon, 2010-03-15 at 03:25 +0200, Siarhei Siamashka wrote:
> >
> > > But before it gets committed, some problems with potential fixed
> point
> > > overflows when dealing with large images need to be addressed. I
> have
> > >
Hi,
> On Mon, 2010-03-15 at 03:25 +0200, Siarhei Siamashka wrote:
>
> > But before it gets committed, some problems with potential fixed point
> > overflows when dealing with large images need to be addressed. I have
> > made a test program which can expose some of these problems:
> > http://cgit
On Tue, 2010-03-16 at 12:10 +0200, Siarhei Siamashka wrote:
>
> Also gcc shows the following warnings:
>
> pixman-fast-path.c: In
> function ‘fast_composite_scaled_nearest_x888_565_SRC_none’:
> pixman-fast-path.c:1560: warning: integer constant is too large for
> ‘long’ type
Hehe... I didn't b
On Tue, 2010-03-16 at 12:10 +0200, Siarhei Siamashka wrote:
> On Monday 15 March 2010, Alexander Larsson wrote:
> > On Mon, 2010-03-15 at 03:25 +0200, Siarhei Siamashka wrote:
> > > But before it gets committed, some problems with potential fixed
> point
> > > overflows when dealing with large imag
On Tue, 2010-03-16 at 12:10 +0200, Siarhei Siamashka wrote:
> On Monday 15 March 2010, Alexander Larsson wrote:
> > On Mon, 2010-03-15 at 03:25 +0200, Siarhei Siamashka wrote:
> > > But before it gets committed, some problems with potential fixed
> point
> > > overflows when dealing with large imag
On Sunday 14 March 2010, Loïc Minier wrote:
> On Wed, Mar 10, 2010, Siarhei Siamashka wrote:
> > I would prefer a bit more descriptive comment (with the details copied
> > from that launchpad page).
>
> I see you pushed this now; thanks! Yeah, it's not obvious why one
> needs to try with the too
On Monday 15 March 2010, Alexander Larsson wrote:
> On Mon, 2010-03-15 at 03:25 +0200, Siarhei Siamashka wrote:
> > But before it gets committed, some problems with potential fixed point
> > overflows when dealing with large images need to be addressed. I have
> > made a test program which can expo
On Tuesday 16 March 2010, Alexander Larsson wrote:
> On Tue, 2010-03-16 at 09:49 +0200, Siarhei Siamashka wrote:
> > On Monday 15 March 2010, Alexander Larsson wrote:
> > > On Mon, 2010-03-15 at 17:05 +0200, Siarhei Siamashka wrote:
> > > > Really good performance improvements for bilinear scaling
On Tue, 2010-03-16 at 09:49 +0200, Siarhei Siamashka wrote:
> On Monday 15 March 2010, Alexander Larsson wrote:
> > On Mon, 2010-03-15 at 17:05 +0200, Siarhei Siamashka wrote:
> > > Really good performance improvements for bilinear scaling are
> going to
> > > come
> > > from SIMD optimizations. To
On Monday 15 March 2010, Alexander Larsson wrote:
> On Mon, 2010-03-15 at 17:05 +0200, Siarhei Siamashka wrote:
> > Really good performance improvements for bilinear scaling are going to
> > come
> > from SIMD optimizations. To make it happen, scaler core needs to be
> > isolated
> > into a small s
21 matches
Mail list logo