CVS Update: xc (branch: trunk)

[Thomas Winischhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


[Sorry...]

Thomas Winischhofer wrote:
> Thomas Winischhofer wrote:
> 
>>>Thomas Winischhofer wrote:
>>>
>>>
>>>>>Eric Anholt wrote:
>>>>>
>>>>>
>>>>>
>>>>>>>On Sat, 2005-09-17 at 13:02 -0700, Eric Anholt wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>CVSROOT:	/cvs/xorg
>>>>>>>>Module name:	xc
>>>>>>>>Changes by:	anholt at gabe.freedesktop.org	05/09/17 13:02:02
>>>>>>>>
>>>>>>>>Log message:
>>>>>>>>- Don't try to upload 0 byte-per-pixel (PICT_a1) data using
>>>>>>>> RADEONHostDataBlit.
>>>>>>>>- Disable the shortcut for switching from 3d to 3d in radeon_exa.c.  It
>>>>>>>> appears that we do need the cache flush here, thought it's not clear
>>>>>>>> why.  Disable the 2d to 2d shortcut while here, since I'm unsure of
>>>>>>>> what we're doing.  Exposed by the following bit:
>>>>>>>>- Bug #4485: Add a new routine, exaGlyphs, to handle font drawing.
>>>>>>>> Glyphs were being accumulated in from non-migratable scratch pixmaps,
>>>>>>>> causing the destination pixmap to move towards screen but the
>>>>>>>> migration necessary for source never to happen, leading to abysmal
>>>>>>>> performance.  Instead, copy the scratch glyph data into a real pixmap
>>>>>>>> first, then composite from that into the destination, allowing for
>>>>>>>> migration.  time ls -lR from programs/Xserver showed 26.9% (+/- 6.3%)
>>>>>>>> decrease in wall time (n=3).
>>>>>>>>- Create exaDrawableUse* wrapping exaPixmapUse*, but which are aware of
>>>>>>>> windows needing backing store.  Makes migration code prettier, and
>>>>>>>> ensures that composited windows will be migrated as normal when we
>>>>>>>> turn off cw for EXA. (issue brought up by keithp)
>>>>>>>
>>>>>>>
>>>>>>>We had a discussion on IRC about the cost of item 2, disabling the
>>>>>>>shortcut for "switching" from 2d to 2d or 3d to 3d.  I decided to test
>>>>>>>this, using the same ls -lR, against the theoretical best of never
>>>>>>>having to do the syncing (stick a break at the top of
>>>>>>>RADEON_SWITCH_TO_*).  It was clear that fonts were broken when I made
>>>>>>>this change.  At n=7, a=.05, caches hot, there was no statistically
>>>>>>>significant difference.  In this case, I'm quite happy with the code as
>>>>>>>it is and feel no need to try to squeeze hypothetical performance out by
>>>>>>>being stingier with the flushes :)
>>>>>
>>>>>
>>>>>Whatever you did, these changes (glyph stuff supposedly) make scrolling
>>>>>non-AA text (which I use for console and text editor) on sis hardware
>>>>>visibly slower. Scrolling though a text file in the editor (kwrite, in
>>>>>my case) using the scroll bar or the mouse wheel lags *quite* a bit. No
>>>>>good...
>>>
>>>"time cat init301.c init301.c init301.c init301.c" in the console
>>>(konsole) went from 1.3 to 1.5 seconds averagely.
> 
> 
> Nope, the exaGlyph can't be it, since I don't support the composite
> hooks (yet).
> 
> Some migration logic is borked as it seems.
> 
> 

Yupp, that's it: [Hm, perhaps I should update my CVS tree more often...]

- ----
Bugzilla #4226: Change the pixmap migration strategy for the CopyNtoN
case.  Now, if either source or dest were in framebuffer, try to get
both there, but prefer system memory for both otherwise.  Required
making exaasync.c go through the try-acceleration path.  This
significantly improves window resizing under composite, because
previously the pattern of creating a new pixmap and copying default
contents from the screen caused a fallback every time due to the new
destination pixmap being in system memory.
- ----

Reverting this to the old behavior makes everything MUCH faster (not
only text output, but all CopyNtoN cases)

This new strategy is not good for my case (whatever the criteria is, be
it slow hardware, non-DMA up/downloads, etc)

Thomas

- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net          http://www.winischhofer.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDLXWnzydIRAktyUcRAlcYAJ4+hu+oCUy9no2Jx8wpQtuZW2mRKgCgo2i+
TrIs0XhPye909BWqsdYwPOM=
=XkCn
-----END PGP SIGNATURE-----