> What kind of hardware did you test by the way? And how did you calculate
> memory
> bandwidth percentage (it may be a bit tricky because this operation is kind of
> asymmetric and reads 5 bytes per pixel, while only writing 2)?
Those particular numbers are from a 3GHz C2D. Unfortunately x86 is
On Thursday 12 August 2010 19:59:29 Koen Kooi wrote:
> On 12-08-10 12:24, Soeren Sandmann wrote:
> > Andrea Canciani writes:
> >> If we can't assume that we have a (fast) FPU,
> >
> > There is a fairly common misconception that ARM CPUs never have
> > hardware floating point; that may be part of
On Monday 23 August 2010 15:39:00 Jonathan Morton wrote:
> > > > I suspect using floats would be *much* better than the existing
> > > > fixeds on modern x86_64 systems. But fixed will remain important on
> > > > smaller, lighter systems for some time to come.
> > >
> > > I believe so too, and I
Since you are showing that even *pixel operations* can be faster in
floating point, I think this is a pretty good proof that doing the
*coordinates* in floating point will be a huge win.
Jonathan Morton wrote:
I suspect using floats would be *much* better than the existing fixeds
on modern x86
> > > I suspect using floats would be *much* better than the existing fixeds
> > > on modern x86_64 systems. But fixed will remain important on smaller,
> > > lighter systems for some time to come.
> >
> > I believe so too, and I have some actual numbers to back it up.
> You forgot to attach the
On Tue, 17 Aug 2010, Jonathan Morton wrote:
> On Tue, 2010-08-17 at 11:42 -0400, James Cloos wrote:
> > I suspect using floats would be *much* better than the existing fixeds
> > on modern x86_64 systems. But fixed will remain important on smaller,
> > lighter systems for some time to come.
>
>
One thing to consider is instruction mix. By switching from fixeds to
floats pixman changes the overall instruction mix of the application it
is being used in. If application itself makes significant use of FPU the
overall result may be a slowdown rather than speedup.
Whatever you do, guys - pleas
On Tue, 2010-08-17 at 11:42 -0400, James Cloos wrote:
> I suspect using floats would be *much* better than the existing fixeds
> on modern x86_64 systems. But fixed will remain important on smaller,
> lighter systems for some time to come.
I believe so too, and I have some actual numbers to back
> "KK" == Krzysztof Kosiński writes:
KK> So what is the bottom line? Should we have two versions of all code,
KK> one using float and one using pixman_fixed_t, or is replacing
KK> pixman_fixed_t with float sufficient?
The typical thing done in the audio world is to have both float and
fixed
Krzysztof Kosiński writes:
> So what is the bottom line? Should we have two versions of all code,
> one using float and one using pixman_fixed_t, or is replacing
> pixman_fixed_t with float sufficient?
As far as I am concerned, using floating point is fine. I have not
heard otherwise from anybod
So what is the bottom line? Should we have two versions of all code,
one using float and one using pixman_fixed_t, or is replacing
pixman_fixed_t with float sufficient?
How much slower is softfloat - a factor of 5, 15 or 500?
Another thing we have to take into account is that new versions of
Cair
On Thu, 2010-08-12 at 17:12 +0200, Jean-Claude Repetto wrote:
> Only high-end ARM processors of the most recent family (ARM-11) have a
> FPU.
Even that is not an accurate statement:
FPU co-processor cores are available all the way back to at least ARMv3
(ARM6 family) which is virtually prehistori
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12-08-10 12:24, Soeren Sandmann wrote:
> Andrea Canciani writes:
>
>> If we can't assume that we have a (fast) FPU,
>
> There is a fairly common misconception that ARM CPUs never have
> hardware floating point; that may be part of why some peopl
Le 12/08/2010 12:24, Soeren Sandmann a écrit :
Andrea Canciani writes:
If we can't assume that we have a (fast) FPU,
There is a fairly common misconception that ARM CPUs never have
hardware floating point; that may be part of why some people are
worried.
However, until we hear from someone
Andrea Canciani writes:
> If we can't assume that we have a (fast) FPU,
There is a fairly common misconception that ARM CPUs never have
hardware floating point; that may be part of why some people are
worried.
However, until we hear from someone who can credibly claim that he is
going to ship
On Thu, 2010-08-12 at 10:06 +0200, Andrea Canciani wrote:
> >> (I would *really* love if int128_t was actually available!)
> >
> > It's available on most 64bit systems (at least x86_64) with gcc as
> > __int128_t and __uint128_t. I use this:
> >
> > #if defined(HAVE___UINT128_T) and !defined(HAVE_
On Thu, 2010-08-12 at 09:54 +0200, Andrea Canciani wrote:
> (I would *really* love if int128_t was actually available!)
It's available on most 64bit systems (at least x86_64) with gcc as
__int128_t and __uint128_t. I use this:
#if defined(HAVE___UINT128_T) and !defined(HAVE_UINT128_T)
typedef __u
On Thu, 12 Aug 2010 10:06:22 +0200, Andrea Canciani wrote:
> If we can't assume that we have a (fast) FPU, we probably can't assume
> that we are on a 64 bits architecture (even less on x86_64).
> :(
But we can at least do a compile time check for a 64-bit ABI and not
unnecessarily penalise 64-bi
On Thu, Aug 12, 2010 at 10:02 AM, Mathieu Lacage
wrote:
> On Thu, 2010-08-12 at 09:54 +0200, Andrea Canciani wrote:
>> (I would *really* love if int128_t was actually available!)
>
> It's available on most 64bit systems (at least x86_64) with gcc as
> __int128_t and __uint128_t. I use this:
>
> #i
2010/8/12 Arjen Nienhuis :
> 2010/8/11 Krzysztof Kosiński
>>
>> The 16.16 limitation on gradient coordinates and transformation
>> matrices is insufficient and causes glitches when rendering gradients
>> and bitmaps at 40x zoom, and in certain cases even at 1x zoom. It
>> would be best if gradient
2010/8/11 Krzysztof Kosiński
> The 16.16 limitation on gradient coordinates and transformation
> matrices is insufficient and causes glitches when rendering gradients
> and bitmaps at 40x zoom, and in certain cases even at 1x zoom. It
> would be best if gradients could use the full precision of d
W dniu 12 sierpnia 2010 00:50 użytkownik Arjen Nienhuis
napisał:
> The gradients in your test case
> (https://bugs.freedesktop.org/show_bug.cgi?id=29470) can be rendered fine
> with just 16.16 fixed point math. It's just that the implementation in
> pixman is not very accurate. I guess it's accumu
On Wed, 11 Aug 2010, Soeren Sandmann wrote:
> For the matrix in pixman_image_t, I think we need to just move to
> single precision floating point unconditionally. There are several
> cases where 16.16 fixed point simply doesn't have enough either range
> or precision.
[snip]
Before deciding on t
W dniu 11 sierpnia 2010 04:06 użytkownik Soeren Sandmann
napisał:
> How large are the images that inkscape needs to deal with? There is
> currently a limitation in cairo of +/- 2^23, which is about +/- 8.3
> million. This is also about the approximate range of integers that can
> be stored exactly
Krzysztof Kosiński writes:
> There are several bugs in the Cairo port of Inkscape that are caused
> by the 16.16 fixed point coordinate format in Pixman. We can't switch
> to Cairo until this is resolved, mainly because Inkscape is used to
> render OpenStreetMap tiles and must be able to cope wit
25 matches
Mail list logo
