On 10 Aug 2003 10:38:31 -0400 Owen Taylor <[EMAIL PROTECTED]> babbled:
> On Sun, 2003-08-10 at 03:22, Carsten Haitzler wrote:
> > On Sat, 9 Aug 2003 22:07:21 -0700 (PDT) Mark Vojkovich
> > <[EMAIL PROTECTED]> babbled:
> >
> > > On Sun, 10 Aug 2003, Carsten Haitzler wrote:
> > >
> > > > Would I be correct in the assumption that the only accelerated path for
> > > > xrender is the identity transform (1:1 scale)? all other transforms are
> > > > done in software? (my initial tests here with xfree86 4.3.0 & nvidia's
> > > > latest drivers(as of about a month ago) seem to indicate as much...)
> > > > (and yes... my drivers are using acceleration... GL definitely is). ?
> > > >
> > >
> > > The NVIDIA drivers fall back to software if the source or mask
> > > have any transform.
> >
> > really? very interesting as i'm getting my own mmx asm bleding routines
> > blending@ 32bpp being 35 times faster than xrender (blending at 1:! scaling,
> > no transform, nearest filter for scaling).
> >
> > display is 24bpp (src picture is 32bpp, with alpha, component alpha set,
> > repeat set to true, dither true). i am not sure.. but a 35 TIMES speed
> > difference with software being the faster... sounds wrong to me.
>
> If you are getting 35x faster, it probably means that you are hitting a
> code path not accelerated in the NVIDIA drivers... one common case where
> this used to happen is if the *source* is in video ram. I know Mark has
> been working on fixing this (at least as part of the XAA rewrite for
> XFree86 5, but it may still be a limitation of the current nvidia
> drivers.
my understanding is that at least the basic 1:1 scale over operations were
accelerated - and that was abysmally slow. apparently now according to mark the
acceleration is disabled as of recent drivers so that explains as above. i
though that the drivers would also be smart enough to realize that if you start
doing xrender ops to a pixmap in video ram an there is no hardware accel, it's
migrate to system ram. apparently not.
> Making the source a SHM pixmap can be a big win, because it forces it
> into system ram. Or it might be the repeat, or dither.
i tried playing with repeate and dither options - though this is 24bpp so i'm
not sure dither really woudl have any effect :) and yeah - i coudl do the
shared pixmap trick, but it gets to the point of doing silly backflips to
attempt to approximate the speed that already exists in client-side
rendering, so why bother when there's alreayd a faster and more portable
system at hand? opengl is really the only solution still it seems for this
kind of thing.
> As for why your software fallbacks are 35x faster than the render
> fallbacks, there are three causes, in rough order of importantance.
>
> - The image is being pushed/pulled over the bus (AGP bus, likely) both
> ways by the video card instead of having 2 PCI transactions per
> pixel. The nvidia drivers in particular do a good job at optimizing
> GetImage.
> - Special casing of the particular formats in your compositing
> routines. The RENDER code is very general, and very slow.
> - MMX acceleration
it'd likely be 1. lack of mxx and 2. bus. maybe 3. too general a pipeline.
> The current plan for addressing the second two is to do it as part of
> the 'libic' library so the same code can be used in the X server and in
> the software fallbacks for Cairo. I think a couple of people have taken
> a look at doing that optimization work, though I'm not sure if anybody
> is working on it actively at this time.
libic? hmmm part of Xr? or Xc? i have handy code to optimize paths when you
need it. For now it happily lurks at the bottom of all my own software
rendering pipelines... :)
> Regards,
> Owen
>
>
> _______________________________________________
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 [EMAIL PROTECTED]
Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
