On Tue, 27 Jan 2004, Sottek, Matthew J wrote:
> > I didn't remove anything. There was never any support for
> >componentAlpha. I just made XAA aware that it didn't support
> >it.
>
> You removed the ability for a driver to support accelerated component
> alpha on a XFree 4.4.0 binary. If this
> I didn't remove anything. There was never any support for
>componentAlpha. I just made XAA aware that it didn't support
>it.
You removed the ability for a driver to support accelerated component
alpha on a XFree 4.4.0 binary. If this is now the most common case
then why wouldn't a driver wan
Mark Vojkovich wrote:
On Mon, 26 Jan 2004, Thomas Winischhofer wrote:
Sottek, Matthew J wrote:
a) is used for aa text; however, sometimes (haven't yet found out why)
the alphaType argument to this is not PICT_a8 as one would expect, but
PICT_a8r8g8b8.
I don't quite get the logic behind this. Wha
On Mon, 26 Jan 2004, Sottek, Matthew J wrote:
> >I am given a constant r, g and b as each a separate parameter, and an
> >a8r8g8b8 texture which by Mark's explanation is for providing an alpha
> >value for each of the r, g, b components. But the format is _a8_r8g8b8;
> >if the components' alphas a
>I am given a constant r, g and b as each a separate parameter, and an
>a8r8g8b8 texture which by Mark's explanation is for providing an alpha
>value for each of the r, g, b components. But the format is _a8_r8g8b8;
>if the components' alphas are in the r8g8b8 part, what's to happen with
>the a8 p
On Mon, 26 Jan 2004, Thomas Winischhofer wrote:
> Sottek, Matthew J wrote:
> >>a) is used for aa text; however, sometimes (haven't yet found out why)
> >>the alphaType argument to this is not PICT_a8 as one would expect, but
> >>PICT_a8r8g8b8.
> >>
> >>I don't quite get the logic behind this. What
> On Mon, 26 Jan 2004, Thomas Winischhofer wrote:
>
> > I do now understand that r, g, b can contain separate alpha values for
> > each component (which I easily could support in my driver since I first
> > need to build an accelerator-suitable texture anyway). What is supposed
> > to happen wi
Sottek, Matthew J wrote:
a) is used for aa text; however, sometimes (haven't yet found out why)
the alphaType argument to this is not PICT_a8 as one would expect, but
PICT_a8r8g8b8.
I don't quite get the logic behind this. What's the CPUToScreenTexture
hook for if CPUToScreenAlphaTexture should be
Mark Vojkovich wrote:
What if some hardware supported this? Wouldn't it be better to set a
flag in the Flags field submitted to the driver's SetUpCPU...()
function? Or/and perhaps let the driver specify a flag in the
CPUToScreenAlphaTextureFlags, like XAA_RENDER_COMPONENT?
If you want to te
>a) is used for aa text; however, sometimes (haven't yet found out why)
>the alphaType argument to this is not PICT_a8 as one would expect, but
>PICT_a8r8g8b8.
>
>I don't quite get the logic behind this. What's the CPUToScreenTexture
>hook for if CPUToScreenAlphaTexture should be able to deal with
On Mon, 26 Jan 2004, Thomas Winischhofer wrote:
> Mark Vojkovich wrote:
> > On Mon, 26 Jan 2004, Thomas Winischhofer wrote:
> >
> >
> >>Can anyone explain the meaning of a8r8g8b8 "pure" alpha textures?
> >
> >
> >It's probably a bug that XAA is letting those through.
> > a8r8g8b8 alpha mas
Mark Vojkovich wrote:
On Mon, 26 Jan 2004, Thomas Winischhofer wrote:
Can anyone explain the meaning of a8r8g8b8 "pure" alpha textures?
It's probably a bug that XAA is letting those through.
a8r8g8b8 alpha masks mean one of two things:
1) If componentAlpha is set, it's 4 alpha masks which ac
On Mon, 26 Jan 2004, Thomas Winischhofer wrote:
> Can anyone explain the meaning of a8r8g8b8 "pure" alpha textures?
It's probably a bug that XAA is letting those through.
a8r8g8b8 alpha masks mean one of two things:
1) If componentAlpha is set, it's 4 alpha masks which act separately
on th
Can anyone explain the meaning of a8r8g8b8 "pure" alpha textures?
The two hooks for render acceleration are
a) CPUToScreenAlphaTexture (should be PICT_a8)
b) CPUToScreenTexture (like eg PICT_a8r8g8b8)
a) is used for aa text; however, sometimes (haven't yet found out why)
the alphaType argument t
> "Mark" == Mark Vojkovich <[EMAIL PROTECTED]> writes:
Mark> I'm getting the suspicion that aliased fonts are getting
Mark> substituted for antialiased fonts in some of these benchmarks
Mark> people are posting.
The problem is that x11perf asks for:
charter:antialias=true:rgba=0:pixelsize=10
--- Thomas Winischhofer <[EMAIL PROTECTED]> a
écrit : > Carsten Haitzler (The Rasterman) wrote:
> >>That is strange. Without acceleration, I get
> >>
> >>9.7
> >>1.7
> >>2.3
> >>
> >>Seems imlib uses the video RAM.
> >
> > definitely not. imlib2 only uses system ram - all
> its buffers are a dire
Carsten Haitzler (The Rasterman) wrote:
>>That is strange. Without acceleration, I get
>>
>>9.7
>>1.7
>>2.3
>>
>>Seems imlib uses the video RAM.
>
> definitely not. imlib2 only uses system ram - all its buffers are a direct
> result of malloc() :) imlib2 has no clue that video hardware exists :)
On Friday 29 of August 2003 03:03, Rafał Rzepecki wrote:
> On Friday 29 of August 2003 02:51, Rafał Rzepecki wrote:
> > On Friday 29 of August 2003 02:34, Mark Vojkovich wrote:
> > > On Fri, 29 Aug 2003, [utf-8] Rafał Rzepecki wrote:
> > > > On Thursday 28 of August 2003 15:58, Thomas Winischhofer
On Friday 29 of August 2003 02:51, Rafał Rzepecki wrote:
> On Friday 29 of August 2003 02:34, Mark Vojkovich wrote:
> > On Fri, 29 Aug 2003, [utf-8] Rafał Rzepecki wrote:
> > > On Thursday 28 of August 2003 15:58, Thomas Winischhofer wrote:
> > > > What's a "normal" result for -aa24text on Intel h
On Friday 29 of August 2003 02:34, Mark Vojkovich wrote:
> On Fri, 29 Aug 2003, [utf-8] Rafał Rzepecki wrote:
> > On Thursday 28 of August 2003 15:58, Thomas Winischhofer wrote:
> > > What's a "normal" result for -aa24text on Intel hardware with, say,
> > > nvidia or radeon?
> > >
> > > Anyone?
>
On Fri, 29 Aug 2003, [utf-8] RafaÅ Rzepecki wrote:
> On Thursday 28 of August 2003 15:58, Thomas Winischhofer wrote:
> > What's a "normal" result for -aa24text on Intel hardware with, say,
> > nvidia or radeon?
> >
> > Anyone?
>
> Celeron Coppermine [EMAIL PROTECTED], NVidia TNT2 M64:
>
> 64000
On Thu, 28 Aug 2003 12:47:26 +0200 Thomas Winischhofer <[EMAIL PROTECTED]>
(Bbabbled:
(B
(B> Carsten Haitzler (The Rasterman) wrote:
(B> > ah shared framebuffer. ok. then i can understand some of the "hurt" :)
(B> >
(B> >
(B> >>What values do you get on your hardware? (Unscaled only, t
On Thursday 28 of August 2003 15:58, Thomas Winischhofer wrote:
> What's a "normal" result for -aa24text on Intel hardware with, say,
> nvidia or radeon?
>
> Anyone?
Celeron Coppermine [EMAIL PROTECTED], NVidia TNT2 M64:
640 reps @ 0.0013 msec (755000.0/sec): Char in 30-char aa line (Charte
Mark Vojkovich wrote:
On Thu, 28 Aug 2003, Thomas Winischhofer wrote:
Michel Dänzer wrote:
[stripped]
( 3180.0/sec): 500x500 rectangle
( 1920.0/sec): 500x500 tiled rectangle (17x15 tile)
( 139.0/sec): ShmPutImage 500x500 square
Here (P4 Celeron, 2.0Ghz, SiSM650, DDR266) it's
2500/sec fo
On Thu, 28 Aug 2003, Thomas Winischhofer wrote:
> Michel Dänzer wrote:
> [stripped]
> > ( 3180.0/sec): 500x500 rectangle
> >
> > ( 1920.0/sec): 500x500 tiled rectangle (17x15 tile)
> >
> > ( 139.0/sec): ShmPutImage 500x500 square
>
> Here (P4 Celeron, 2.0Ghz, SiSM650, DDR266) it's
> Michel Dänzer wrote:
> >>Text drawing (x11perf -aa24text) went from 25000 to 105000, which is
> >>more than factor 4. I am satisfied.
> >
> > Err, I get without acceleration on a 1 Ghz TiBook:
> >
> > 960 reps @ 0.0006 msec (154.0/sec): Char in 30-char aa line
> > (Charter 24)
T
On Thu, 2003-08-28 at 16:51, Thomas Winischhofer wrote:
> Michel Dänzer wrote:
> [stripped]
> > ( 3180.0/sec): 500x500 rectangle
> >
> > ( 1920.0/sec): 500x500 tiled rectangle (17x15 tile)
> >
> > ( 139.0/sec): ShmPutImage 500x500 square
>
> Here (P4 Celeron, 2.0Ghz, SiSM650, DDR266
Soeren Sandmann wrote:
FWIW, I get numbers comparable to Thomas' with an Nvidia Geforce 2,
a 1GHz CPU, and a stock Red Hat 9 server using the free driver:
96000 reps @ 0.0628 msec ( 15900.0/sec): Char in 30-char aa line
(Charter 24)
Well, now I feel good again with my 105000/sec here :)
Thank
Michel Dänzer <[EMAIL PROTECTED]> writes:
> > Text drawing (x11perf -aa24text) went from 25000 to 105000, which is
> > more than factor 4. I am satisfied.
>
> Err, I get without acceleration on a 1 Ghz TiBook:
>
> 960 reps @ 0.0006 msec (154.0/sec): Char in 30-char aa line
> (Charter
Ar an 28ú lá de mí 8, scríobh Thomas Winischhofer :
> What's a "normal" result for -aa24text on Intel hardware with, say,
> nvidia or radeon?
>
> Anyone?
96000 reps @ 0.0743 msec ( 13500.0/sec): Char in 30-char aa line
Pentium 4, 2.2GHz, Radeon Mobility M7, for a baseline.
--
"These
Michel Dänzer wrote:
[stripped]
( 3180.0/sec): 500x500 rectangle
( 1920.0/sec): 500x500 tiled rectangle (17x15 tile)
( 139.0/sec): ShmPutImage 500x500 square
Here (P4 Celeron, 2.0Ghz, SiSM650, DDR266) it's
2500/sec for rect500
1100/sec for oddtilerect500
717/sec for shmput500
Seems y
On Thu, 2003-08-28 at 15:58, Thomas Winischhofer wrote:
> Michel Dänzer wrote:
> >>Text drawing (x11perf -aa24text) went from 25000 to 105000, which is
> >>more than factor 4. I am satisfied.
> >
> > Err, I get without acceleration on a 1 Ghz TiBook:
> >
> > 960 reps @ 0.0006 msec (154
Michel Dänzer wrote:
Text drawing (x11perf -aa24text) went from 25000 to 105000, which is
more than factor 4. I am satisfied.
Err, I get without acceleration on a 1 Ghz TiBook:
960 reps @ 0.0006 msec (154.0/sec): Char in 30-char aa line
(Charter 24)
Interesting. What do
-shmput500
-rec
On Thu, 2003-08-28 at 03:30, Thomas Winischhofer wrote:
>
> I need to copy the texture to video RAM once, unless somebody tells me
> it already is there (I could use the 2D accelerator for this, too, then.
> In this case I just wonder why the mga driver doesn't do it this way.).
Because the mga d
Carsten Haitzler (The Rasterman) wrote:
> ah shared framebuffer. ok. then i can understand some of the "hurt" :)
>
>
>>What values do you get on your hardware? (Unscaled only, the rest is
>>entirely depending on the CPU)
>
>
> for the benchmarker:
> *** ROUND 1 ***
> ---
On Thu, 28 Aug 2003 03:30:18 +0200 Thomas Winischhofer <[EMAIL PROTECTED]>
(Bbabbled:
(B
(B> Carsten Haitzler (The Rasterman) wrote:
(B> >>The non-scaled onscreen XRender went from 9.7 to 0.7 seconds... :)
(B> >>(imlib is at 2.3 seconds). The scaled versions are not accelerated, and
(B> >>the
Carsten Haitzler (The Rasterman) wrote:
>>The non-scaled onscreen XRender went from 9.7 to 0.7 seconds... :)
>>(imlib is at 2.3 seconds). The scaled versions are not accelerated, and
>>they all are much slower than Xrender...
>
> cool. though 0.7 vs 2.3 for imlib2 still isn't that good. i'd expect
On Wed, 27 Aug 2003 10:24:40 +0200 Thomas Winischhofer <[EMAIL PROTECTED]>
(Bbabbled:
(B
(B> Carsten Haitzler (The Rasterman) wrote:
(B> > please please please PLEASE! accelerate everythig you can :)
(B> >
(B> > http://www.rasterman.com/files/render_bench.tar.gz
(B> > http://www.rasterman.
On Wed, 27 Aug 2003 20:21:37 +0200 Thomas Winischhofer <[EMAIL PROTECTED]>
(Bbabbled:
(B
(B> Carsten Haitzler (The Rasterman) wrote:
(B> > please please please PLEASE! accelerate everythig you can :)
(B> >
(B> > http://www.rasterman.com/files/render_bench.tar.gz
(B>
(B> Is it correct to
Carsten Haitzler (The Rasterman) wrote:
> please please please PLEASE! accelerate everythig you can :)
>
> http://www.rasterman.com/files/render_bench.tar.gz
Is it correct to assume, that the image I see over a rainbow-like
background is the result of RENDER, and over a grey-shaded background
fr
Carsten Haitzler (The Rasterman) wrote:
> please please please PLEASE! accelerate everythig you can :)
>
> http://www.rasterman.com/files/render_bench.tar.gz
> http://www.rasterman.com/files/imlib2-1.1.0.tar.gz
> this might be handy for you as a way of 1. measuring correctness (well so it
> "look
On Tue, 26 Aug 2003 15:50:46 +0200 Thomas Winischhofer <[EMAIL PROTECTED]>
(Bbabbled:
(B
(B> Since I recently found out that SiS hardware _does_ support per-pixel
(B> alpha-blended bitblits, I could finish the (yet disabled) render
(B> acceleration.
(B>
(B> The only problem I encountered:
Sorry for replying to my own post:
Since I have found only one application triggering calls to the
accelerated RENDER functions (openoffice), I wonder under what
circumstances these functions are called as regards anti-aliased text?
Why isn't for example Qt (which I use in version 3.1.1 here) o
Since I recently found out that SiS hardware _does_ support per-pixel
alpha-blended bitblits, I could finish the (yet disabled) render
acceleration.
The only problem I encountered: The functions that I provide
(SetupFor/SubsequentCPUToScreen[Alpha]Texture) are never called as it
seems
How
Keith Packard wrote:
Around 0 o'clock on Feb 28, Thomas Winischhofer wrote:
The hardware I am dealing with does not support ARGB textures (at least
not in 2D level, and I don't want to mess with DRI), but "alpha blended
bit blits".
Using the '3D' hardware needn't entail dealing with DRI. The
Around 0 o'clock on Feb 28, Thomas Winischhofer wrote:
> The hardware I am dealing with does not support ARGB textures (at least
> not in 2D level, and I don't want to mess with DRI), but "alpha blended
> bit blits".
Using the '3D' hardware needn't entail dealing with DRI. The MGA driver
does
On Fri, 28 Feb 2003, Thomas Winischhofer wrote:
> The hardware I am dealing with does not support ARGB textures (at least
> not in 2D level, and I don't want to mess with DRI), but "alpha blended
> bit blits".
>
> The difference being: While ARGB textures contain an alpha value for
> each pixe
The hardware I am dealing with does not support ARGB textures (at least
not in 2D level, and I don't want to mess with DRI), but "alpha blended
bit blits".
The difference being: While ARGB textures contain an alpha value for
each pixel, the "alpha blended bit blits" render with a static alpha
48 matches
Mail list logo
