Re: Solved! (was Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?)
On Thu, 2009-02-05 at 00:29 +, Nix wrote: augh! blasted --disable-builtin-fonts, why isn't it the default? It's gone in Git master, the builtins are always available as a fallback for the real FontPath now. There's discussion about merging this nice solution for 1.6. but the most significant change from my perspective is that the crude little 4-entry glyph cache has raised the performance of font rendering by about an order of magnitude. Yeah, that matches my experience. (The performance reduction for non-antialiased client-side fonts is probably down to xterm: with konsole, they're equally fast.) Yeah, it could be that xterm hits one of the cases the glyph cache doesn't handle well yet. Or maybe it renders each glyph separately instead of at least a whole line (or as much of it as possible anyway) at once? So it looks like I'm going to be using prerelease X servers, and I owe Owen Taylor a beer for implementing the glyph cache and Michel Dänzer another beer for making it work with non-antialiased fonts :) :) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Solved! (was Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?)
'Twas brillig, and Michel Dänzer at 05/02/09 08:15 did gyre and gimble: On Thu, 2009-02-05 at 00:29 +, Nix wrote: augh! blasted --disable-builtin-fonts, why isn't it the default? It's gone in Git master, the builtins are always available as a fallback for the real FontPath now. There's discussion about merging this nice solution for 1.6. +1 Both Fedora and Mandriva are shipping this patch on top of their 1.6 packages you know it makes sense KP ;) -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Solved! (was Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?)
On 3 Feb 2009, Dan Nicholson uttered the following: The output isn't quite what I'd expect, but I think this is because it's using the builtin fonts only. Try rebuilding the server with --disable-builtin-fonts, or apply this patch that's a candidate for augh! blasted --disable-builtin-fonts, why isn't it the default? (More to the point, where did the option go? I was passing it to configure when I built 1.5.x, did it edit itself out of my configure-switches file? ;) ) With that done, I've been able to get more crude not-a-benchmark results, and they are *vastly* better. Here are the 1.5 and 1.6 results, with a bit of extra info to show how much time the pathological megascrolling app (cat in a tight loop) is getting to run rather than being blocked by its scrolling xterm (this is really crude because of course the fonts I'm using are rather different sizes, but it gives you the gist: I've used piles of stars to give a visual cue as well): XAA first, then EXA, leaving the best till last: 1.5: XAA, 16, AA: fbCompositeSolidMask_nxx0565Cmmx 59.25 (X: 90.12) 1.5: XAA, 24, AA: fbCompositeSolidMask_nxxCmmx 57.12 (X: 85.03) 1.6: XAA, 16, AA: fbCompositeSolidMask_nxx0565Cmmx 58.41 (X: 84.70) speed of underlying painting app on arbitrary scale (forks of cat per second): 10 ** 1.6: XAA, 24, AA: fbCompositeSolidMask_nxxCmmx 58.14 (X: 85.27) App speed: 10 ** 1.5: XAA, 16, non-AA: fbFetch_a1 12.43 (X: 79.96) 1.5: XAA, 24, non-AA: fbFetch_a1 14.51 (X: 87.60) 1.6: XAA, 16, non-AA: fbFetch_a1 14.34 (X: 80.23); app speed: 7 *** 1.6: XAA, 24, non-AA: fbFetch_a1 12.23 (X: 82.12); app speed: 15 *** 1.5: XAA, 16, core: cat, bash, xterm; CPU load nearly nil; screen a blur far too fast to read highest consumer in X, at 1s, DrawTETextScanlineWidth7() 1.5: XAA, 24, core: as above 1.6: XAA, 16, core: highest consumer in X, at 1.5s, DrawTETextScanlineWidth7() app speed: 150 ** ** ** 1.6: XAA, 24, core: as above; max-X, @1.63s, DrawTETextScanlineWidth7() app speed: 140 ** ** So far, so mostly unchanged and boring: XAA hasn't changed much. The good stuff, as Michel suggested, is in EXA. 1.5: EXA, 16, AA: dixLookupPrivate 23.17 generally much faster than XAA, occasionally degrades to XAA speed 1.5: EXA, 24, AA: dixLookupPrivate 26.83 1.6: EXA, 16, AA: exaBufferGlyph 5.74 (X: 49.42); xterm: 9.48; kernel: 20.10 * *** 1.6: EXA, 24, AA: exaBufferGlyph 4.82 (X: 57.88); xterm: 7.09, kernel: 33.5 App speed: 50, considerably slower than 16bpp. X seems to be spending longer in the kernel. ** 1.5: EXA, 16, non-AA: fbFetch_r5g6b5 53.40, fbFetch_a1 5.75 (X: 95.88) horrendously, impossibly slow, 10s for a single screen repaint 1.5: EXA, 24, non-AA: fbFetch_a1 12.40 (X: 89.34) 1.6: EXA, 16, non-AA: exaBufferGlyph 6.41 (X: 49.89); xterm: 28.91; kernel: 17 App speed: 80. ** ** 1.6: EXA, 24, non-AA: exaBufferGlyph 6.31 (X: 52.58); xterm: 26.35; kernel: 20.81. App speed: 50. ** 1.5: EXA, 16, core: pixman_fill_mmx 22.17, fbGlyph16 15.83 (X: 62.58) 1.5: EXA, 24, core: pixman_fill_mmx 37.51, fbGlyph32 13.63 (X: 69.48) 1.6: EXA, 16, core: pixman_fill_mmx 21.28, fbGlyph16 15.71 (X: 59.59). App speed: 60, slower than non-core fonts, as expected, and much slower than XAA, as expected. Figures basically identical to 1.5 core fonts. ** ** 1.6: EXA, 24, core: pixman_fill_mmx 30.17, fbGlyph32 11.69 (X: 65.14) App speed: 40. The changes between EXA and XAA are interesting. Core fonts are somewhat slower; 24bpp has
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On 31 Jan 2009, Michel Dänzer said: On Fri, 2009-01-30 at 21:59 +, Nix wrote: On 30 Jan 2009, Michel Dänzer stated: Trying current xf86-video-ati Git might be good, but my main suggestion would be to try xserver Git server-1.6-branch with EXA. OK. Do I need to upgrade Mesa or anything related at the same time? (I'm currently on libdrm 2.4.1, Mesa a few commits past 7.2.0). I think that should be fine; if anything 3D related breaks though, you can always try upgrading to Mesa 7.3. :) I dug out from under the pile of crud caused by being the only person in the company who made it to work when the staggering total of 10cm of snow fell on south-eastern England (10cm! imagine that! enough to drown a garden gnome!), and tried it. I pulled util/macros, proto/randr, proto/input and pixman to git head so the X server (1.6-branch head) would build and... it doesn't work as well as I might have hoped: [dix] Could not init font path element /usr/local/share/fonts, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts, removing from list! [dix] Could not init font path element /usr/share/fonts/override, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/100dpi, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/75dpi, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/freefont, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/jmk, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/local, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/mathematica, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/misc, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/mozilla, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/SillyNamesForAdobeFonts, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/Speedo, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/TeX, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/TTF, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/Type1, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/cyrillic, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/OTF, removing from list! It's hard to check the scrolling behaviour of antialiased and fixed-point text when the only font you have is 'fixed' :) My X.org log is below (just ignore the version mismatches: yes, the kbd and mouse drivers didn't load, but I can easily fix that by rebuilding them --- but there's not much point if all my fonts go missing, and I doubt they went missing because of the missing mouse driver somehow.) Ideas? _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/hades:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the xorg product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.5.99.902 (1.6.0 RC 2) Release Date: 2009-1-30 X Protocol Version 11, Revision 0 Build Operating System: GNU/Linux Nix Current Operating System: Linux hades 2.6.28.3-dirty #2 PREEMPT Tue Feb 3 21:54:25 GMT 2009 i686 Build Date: 03 February 2009 09:10:30PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.0.log, Time: Tue Feb 3 22:40:21 2009 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout MainServer (**) |--Screen Primary Screen (0) (**) | |--Monitor Samsung SyncMaster 223BW (**) | |--Device Radeon 9250 (**) |--Input Device Mouse (**) |--Input Device Keyboard (**) Option DontZap true (**) Option AllowEmptyInput false (**) Option AutoAddDevices false (**) Option AutoEnableDevices false (**) Not automatically adding devices (**) Not automatically enabling devices (WW) `fonts.dir' not found (or not valid) in /usr/share/fonts. Entry deleted from font path. (Run 'mkfontdir' on /usr/share/fonts). (==) Including the default font path built-ins. (**) FontPath set to: /usr/local/share/fonts, /usr/lib/X11/fonts, /usr/share/fonts/override, /usr/lib/X11/fonts/100dpi,
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On Tue, Feb 3, 2009 at 3:26 PM, Nix n...@esperi.org.uk wrote: On 31 Jan 2009, Michel Dänzer said: On Fri, 2009-01-30 at 21:59 +, Nix wrote: On 30 Jan 2009, Michel Dänzer stated: Trying current xf86-video-ati Git might be good, but my main suggestion would be to try xserver Git server-1.6-branch with EXA. OK. Do I need to upgrade Mesa or anything related at the same time? (I'm currently on libdrm 2.4.1, Mesa a few commits past 7.2.0). I think that should be fine; if anything 3D related breaks though, you can always try upgrading to Mesa 7.3. :) I dug out from under the pile of crud caused by being the only person in the company who made it to work when the staggering total of 10cm of snow fell on south-eastern England (10cm! imagine that! enough to drown a garden gnome!), and tried it. I pulled util/macros, proto/randr, proto/input and pixman to git head so the X server (1.6-branch head) would build and... it doesn't work as well as I might have hoped: [dix] Could not init font path element /usr/local/share/fonts, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts, removing from list! [dix] Could not init font path element /usr/share/fonts/override, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/100dpi, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/75dpi, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/freefont, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/jmk, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/local, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/mathematica, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/misc, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/mozilla, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/SillyNamesForAdobeFonts, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/Speedo, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/TeX, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/TTF, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/Type1, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/cyrillic, removing from list! [dix] Could not init font path element /usr/lib/X11/fonts/OTF, removing from list! It's hard to check the scrolling behaviour of antialiased and fixed-point text when the only font you have is 'fixed' :) My X.org log is below (just ignore the version mismatches: yes, the kbd and mouse drivers didn't load, but I can easily fix that by rebuilding them --- but there's not much point if all my fonts go missing, and I doubt they went missing because of the missing mouse driver somehow.) Ideas? The output isn't quite what I'd expect, but I think this is because it's using the builtin fonts only. Try rebuilding the server with --disable-builtin-fonts, or apply this patch that's a candidate for 1.6: http://cgit.freedesktop.org/xorg/xserver/commit/?id=49b93df8a3002db7196aa3fc1fd8dca1c12a55d6 I suspect that will get your fixed fonts back. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On Tue, 2009-02-03 at 23:26 +, Nix wrote: [dix] Could not init font path element /usr/lib/X11/fonts/OTF, removing from list! It's hard to check the scrolling behaviour of antialiased and fixed-point text when the only font you have is 'fixed' :) Well, FWIW this only affects core fonts, not client-side fonts. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On 31 Jan 2009, Michel Dänzer outgrape: On Fri, 2009-01-30 at 21:59 +, Nix wrote: On 30 Jan 2009, Michel Dänzer stated: Trying current xf86-video-ati Git might be good, but my main suggestion would be to try xserver Git server-1.6-branch with EXA. OK. Do I need to upgrade Mesa or anything related at the same time? (I'm currently on libdrm 2.4.1, Mesa a few commits past 7.2.0). I think that should be fine; if anything 3D related breaks though, you can always try upgrading to Mesa 7.3. :) I'll give it a try. This was a profile with XAA, not EXA. Here's a more comprehensive set of results [...] Ah, so some of those hotspots might indeed be direct VRAM access. With EXA, does it help if you run a compositing manager, even just xcompmgr -a? I'll give that a try as well :) I must say, looking at these crude benchmark results I'm wondering if this client-side font thing wasn't an appealing diversion. Yes, they're pretty, and more flexible than core fonts: but all of a sudden simply simply redrawing the screen has become so CPU-intensive that a screen scroller can peg the CPU without any real effort :( The EXA glyph cache introduced in xserver 1.6 greatly improves rendering of client side fonts - some people have reported in excess of 5 million glyphs/s on beefy Radeons. Unfortunately there are still a couple of cases it doesn't support well in xserver 1.6, hopefully we can fix those for 1.7. Excellent! :) To avoid a1 pictures, you could try using anti-aliasing everywhere, i.e. don't choose any bitmap fonts and don't disable anti-aliasing for small font sizes. [..] I think a big part of the motivation for client side fonts was indeed anti-aliasing, so if you don't want AA and core fonts are faster for you, just use core fonts? That's Not really practical, because they involve different APIs, different font matching mechanisms, and so forth: they aren't really interchangeable. I don't think an attempt to convince the KDE hackers to allow konsole to use core fonts would go very far, not least because core fonts are generally seen as obsolescent (`fix the slow X server', they'd chorus). And I'm not aware of any decent tabbing terminal emulators that use core fonts: certainly none that also allow DCOP automation, which I use all the time... Jim's comments here are, as ever, apposite :) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
Le dimanche 01 février 2009 à 12:54 +, Nix a écrit : On 31 Jan 2009, Michel Dänzer outgrape: I think a big part of the motivation for client side fonts was indeed anti-aliasing, so if you don't want AA and core fonts are faster for you, just use core fonts? That's Not really practical, because they involve different APIs, different font matching mechanisms, and so forth: they aren't really interchangeable. I don't think an attempt to convince the KDE hackers to allow konsole to use core fonts would go very far, not least because core fonts are generally seen as obsolescent From a distribution point of view, apps which use fontconfig almost never present problems (because fontconfig will do all kinds of smart stuff like substituting missing fonts transparently), while apps that use core fonts have a long continuing history of crashing at the slightest opportunity (with users complaining at the distribution instead of upstream). For Fedora 11 we've trying to move all our fonts in fontconfig space, with symlinks to other parts of the filesystem for apps that do not use fontconfig http://fedoraproject.org/wiki/Features/Repackaging_of_Fedora_fonts I think the Fedora 12 cycle will probably start by mass bug-filling against apps that need those symlinks. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On 1 Feb 2009, Nicolas Mailhot uttered the following: From a distribution point of view, apps which use fontconfig almost never present problems (because fontconfig will do all kinds of smart stuff like substituting missing fonts transparently), while apps that use core fonts have a long continuing history of crashing at the slightest opportunity (with users complaining at the distribution instead of upstream). Seconded :/ I think the Fedora 12 cycle will probably start by mass bug-filling against apps that need those symlinks. The annoying pedant in me looks at the 'exposing all our fonts' goal and wonders how you're planning to expose metafont fonts in fontconfig ;) but I guess if you define 'fonts' to be 'fonts that freetype can understand' this is a reasonable goal. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On Fri, 2009-01-30 at 21:59 +, Nix wrote: On 30 Jan 2009, Michel Dänzer stated: Trying current xf86-video-ati Git might be good, but my main suggestion would be to try xserver Git server-1.6-branch with EXA. OK. Do I need to upgrade Mesa or anything related at the same time? (I'm currently on libdrm 2.4.1, Mesa a few commits past 7.2.0). I think that should be fine; if anything 3D related breaks though, you can always try upgrading to Mesa 7.3. :) X: fbFetch_a1 10.92 dixLookupPrivate 7.04 fbStore_a1 3.70 mmxCombineAddU 3.06 pixman_image_composite 2.58 [...] So it looks like we *are* doing huge numbers of fetches from VRAM, judging by the massive time spent in calls upon pixman's fbFetch(). No, at least with EXA, fb*_a1 can't access video RAM directly, as the EXA core currently never migrates pixmaps of bpp 8 to video RAM. This was a profile with XAA, not EXA. Here's a more comprehensive set of results [...] Ah, so some of those hotspots might indeed be direct VRAM access. With EXA, does it help if you run a compositing manager, even just xcompmgr -a? I must say, looking at these crude benchmark results I'm wondering if this client-side font thing wasn't an appealing diversion. Yes, they're pretty, and more flexible than core fonts: but all of a sudden simply simply redrawing the screen has become so CPU-intensive that a screen scroller can peg the CPU without any real effort :( The EXA glyph cache introduced in xserver 1.6 greatly improves rendering of client side fonts - some people have reported in excess of 5 million glyphs/s on beefy Radeons. Unfortunately there are still a couple of cases it doesn't support well in xserver 1.6, hopefully we can fix those for 1.7. To avoid a1 pictures, you could try using anti-aliasing everywhere, i.e. don't choose any bitmap fonts and don't disable anti-aliasing for small font sizes. The benchmarks show that this would indeed speed things up. It would also eliminate every font I use day-to-day and give me piercing headaches. No thanks, let's find another way. :) I think a big part of the motivation for client side fonts was indeed anti-aliasing, so if you don't want AA and core fonts are faster for you, just use core fonts? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On Sat, 2009-01-31 at 15:58 +0100, Michel Dänzer wrote: I think a big part of the motivation for client side fonts was indeed anti-aliasing, so if you don't want AA and core fonts are faster for you, just use core fonts? Actually, the data showed that start up time was terribly affected when getting font metrics, and the logistics of deploying new server side font technology was horrific (you got to upgrade both sides of the wire at the same time, which is very tough). The more fonts, the worse it got. The observed fact was that the font metadata had shifted five times over X's history, and we were still stuck on the original broken model. The other issue is subtle: if programmers had to support two code paths in their applications, and AA support is server side only, you get a chicken and egg problem. We were asking app programmers to do additonal work *and* have a long term maintenance headache, while the installed base of those who could take advantage of AA fonts were small. This strategy demonstrably hadn't worked. So keithp wrote Xft so that it would work whether there was server support for glyph caching available or not (screen scraping if necessary). Then app/toolkit writers get to make one set of code modifications, there is a single code path for long term maintenance (*and *from the app/toolkit developers point of view, their testing problems are not multiplied by two). So that strategy was a much easier sell, (not to mention keithp wandering through many of the important projects and proving patches), and the rest, they say, was history. And we are future proofed against the next innovation in font meta data, and got rid of the application start up round trip disaster. See: http://keithp.com/~keithp/talks/usenix2003/ for a fuller explanation and data. - Jim -- Jim Gettys j...@freedesktop.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On Thu, 2009-01-29 at 21:16 +, Nix wrote: I'm posting this here rather than reporting this on bz mainly because something very similar has been reported on this list by at least one other person in the past few months[1]: at the time, the assumption was that this was Intel-card- related. It doesn't seem to be, because I see it too, with a Radeon 9250 using AGP, xf86-drivers-ati 902eaf768142c6c7dcc487e10775027b84cd1f9a, and pixman 95f2af9584f8f4327ddf6d6948dee17ab48ad8b3. (I can upgrade to head if need be: this just happens to be what was head when I upgraded. I can do profile runs and the like on demand, as well.) Trying current xf86-video-ati Git might be good, but my main suggestion would be to try xserver Git server-1.6-branch with EXA. Both Konsole 3.5.9 (without a background pixmap) and a recent xterm are equally sluggish; xterm uses core fonts by default, did you configure it differently? X: fbFetch_a1 10.92 dixLookupPrivate 7.04 fbStore_a1 3.70 mmxCombineAddU 3.06 pixman_image_composite 2.58 [...] So it looks like we *are* doing huge numbers of fetches from VRAM, judging by the massive time spent in calls upon pixman's fbFetch(). No, at least with EXA, fb*_a1 can't access video RAM directly, as the EXA core currently never migrates pixmaps of bpp 8 to video RAM. To avoid a1 pictures, you could try using anti-aliasing everywhere, i.e. don't choose any bitmap fonts and don't disable anti-aliasing for small font sizes. And why's this only started happening in 1.5.x? Not sure, there were many changes between 1.4 and 1.5 in all of EXA, XAA and fb. (++) RADEON(0): Depth 16, (--) framebuffer bpp 16 (II) RADEON(0): Pixel depth = 16 bits stored in 2 bytes (16 bpp pixmaps) Is it any better in depth 24, or even worse? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On 30 Jan 2009, Michel Dänzer stated: Trying current xf86-video-ati Git might be good, but my main suggestion would be to try xserver Git server-1.6-branch with EXA. OK. Do I need to upgrade Mesa or anything related at the same time? (I'm currently on libdrm 2.4.1, Mesa a few commits past 7.2.0). Both Konsole 3.5.9 (without a background pixmap) and a recent xterm are equally sluggish; xterm uses core fonts by default, did you configure it differently? I just used -fa/-fs to force client-side fonts. X: fbFetch_a1 10.92 dixLookupPrivate 7.04 fbStore_a1 3.70 mmxCombineAddU 3.06 pixman_image_composite 2.58 [...] So it looks like we *are* doing huge numbers of fetches from VRAM, judging by the massive time spent in calls upon pixman's fbFetch(). No, at least with EXA, fb*_a1 can't access video RAM directly, as the EXA core currently never migrates pixmaps of bpp 8 to video RAM. This was a profile with XAA, not EXA. Here's a more comprehensive set of results (using xterm at all times, 'non-AA' forced by using my preferred terminal font, the bitmap font Neep Alt), started and stopped by hand so it's all quite crude, roughly 60s per benchmark run (so I can't explain sysprof's saying that some runs spent 90s in X: on a single core that seems quite unlikely): XAA, 16, AA: fbCompositeSolidMask_nxx0565Cmmx 59.25 (time in X, 90.12) XAA, 24, AA: fbCompositeSolidMask_nxxCmmx 57.12 (time in X, 85.03) EXA, 16, AA: dixLookupPrivate 23.17 visually much faster than XAA, occasionally degrades to XAA speed EXA, 24, AA: dixLookupPrivate 26.83 XAA, 16, non-AA: fbFetch_a1 12.43 %time in X, 79.96) XAA, 24, non-AA: fbFetch_a1 14.51 (time in X, 87.60) (v. slow in konsole, very slightly faster-seeming in xterm but profile results identical so this is just an artifact of differing repaint strategies) EXA, 16, non-AA: fbFetch_r5g6b5 53.40, fbFetch_a1 5.75 (time in X, 95.88) horrendously, impossibly slow, 10s for a single screen repaint EXA, 24, non-AA: fbFetch_a1 12.40 (89.34s in X) much better than the abominable depth 16 results, back to XAA speed XAA, 16, core: cat, bash, xterm; CPU load nearly nil; screen a blur far too fast to read highest consumer in X, at 1s, DrawTETextScanlineWidth7() XAA, 24, core: cat, bash, xterm; CPU load nearly nil; screen a blur far too fast to read; highest consumer in X, at 1s, DrawTETextScanlineWidth7() EXA, 16, core: pixman_fill_mmx 22.17, fbGlyph16 15.83, CPU still pegged by X, in sharp contrast to non-EXA; (time in X, 62.58) EXA, 24, core: pixman_fill_mmx 37.51, fbGlyph32 13.63 (time in X, 69.48) better than anything else bar core XAA In general, core fonts much faster than client-side fonts, 24-bit as fast or faster than 16-bit (this has changed in the about eight years since I paid any attention to it last, and DRI no longer stops working in 24-bit mode: maybe I'll switch), XAA faster than EXA with the single exception of anti-aliased fonts, which I don't use in terminals and text editors because I like my text small enough that antialiasing is uglier than not. I must say, looking at these crude benchmark results I'm wondering if this client-side font thing wasn't an appealing diversion. Yes, they're pretty, and more flexible than core fonts: but all of a sudden simply simply redrawing the screen has become so CPU-intensive that a screen scroller can peg the CPU without any real effort :( isn't X supposed to use *less* CPU time than the apps that call on it? :((( To avoid a1 pictures, you could try using anti-aliasing everywhere, i.e. don't choose any bitmap fonts and don't disable anti-aliasing for small font sizes. The benchmarks show that this would indeed speed things up. It would also eliminate every font I use day-to-day and give me piercing headaches. No thanks, let's find another way. :) (++) RADEON(0): Depth 16, (--) framebuffer bpp 16 (II) RADEON(0): Pixel depth = 16 bits stored in 2 bytes (16 bpp pixmaps) Is it any better in depth 24, or even worse? (See above.) Better under EXA: sometimes better, sometimes worse under XAA (better for antialiased fonts only, all others worse, or too fast to tell in the case of core fonts). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On Thu, Jan 29, 2009 at 4:16 PM, Nix n...@esperi.org.uk wrote: I'm posting this here rather than reporting this on bz mainly because something very similar has been reported on this list by at least one other person in the past few months[1]: at the time, the assumption was that this was Intel-card- related. It doesn't seem to be, because I see it too, with a Radeon 9250 using AGP, xf86-drivers-ati 902eaf768142c6c7dcc487e10775027b84cd1f9a, and pixman 95f2af9584f8f4327ddf6d6948dee17ab48ad8b3. (I can upgrade to head if need be: this just happens to be what was head when I upgraded. I can do profile runs and the like on demand, as well.) [1] in http://lists.freedesktop.org/archives/xorg/2008-December/041503.html I'm using an LCD at native res, 1680x1050. I'm *not* using a compositing manager. Both XAA and EXA are equally slow. The problem appears to be attributable to client-side fonts: using core fonts, scrolling text flashes past far too fast to see, even at this resolution. Using client-side fonts with no background pixmap, it takes about a second to scroll text up the screen and out of sight (assuming that the screen is full of text and that the scrolling is such that the content changes, so repainting is required). Using a background pixmap in Konsole is even slower, with scrolling up consisting of waves of visible repainting proceeding down the screen from the top. While scrolling, the X server pegs the (Athlon IV single-core) CPU: if the CPU is loaded by other things, scrolling is even slower, sometimes taking half a minute or more to scroll text as far as the top of the screen (in a dozen or so whole-screen repaint waves: I do not claim that konsole 3.x is particularly efficient at scrolling). Both Konsole 3.5.9 (without a background pixmap) and a recent xterm are equally sluggish; gnome-terminal appears to work around the sluggishness by virtue of repainting only about once a second, which is hardly ideal (but this may be a configuration error: I hardly ever use gnome-terminal.) You might wish to blame Konsole here, but with xserver 1.4.2 and xf86-video-ati 6.9.0, Konsole with and without a background pixmap was equally fast, and did not peg the CPU. If the Konsole window is hidden, CPU consumption plunges back to normal levels, with X's consumption a few percent at most. Are you using the same version of kde on both systems? IIRC kde 4 switched to using a1 surfaces for font rendering which isn't currently accelerated by EXA. Notice the _a1 fetch below. Alex Jamie Lokier suggested (in a still-subscribers-only LWN post's comment thread) that perhaps the problem was massive reads from video memory because there is no shadow fb. A sysprof run agrees with this: in an 80s run, X uses 67s and konsole 11s: the top time users are: X: fbFetch_a1 10.92 dixLookupPrivate 7.04 fbStore_a1 3.70 mmxCombineAddU 3.06 pixman_image_composite 2.58 konsole: memmove 5.37 [everything else far subsecond] (alas, sysprof returns [?] as the callers for all of these. I have no clue why: it only appears unwilling to provide caller info for the X server. Perhaps it has something to do with dlopen()...) So it looks like we *are* doing huge numbers of fetches from VRAM, judging by the massive time spent in calls upon pixman's fbFetch(). The question is, why? And why's this only started happening in 1.5.x? Is it a configuration error, as Jamie suggested? I've got 128Mb of VRAM, which should be heaps for this, but seemingly we're thrashing between VRAM and main memory all the time. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On 29 Jan 2009, Alex Deucher uttered the following: Are you using the same version of kde on both systems? IIRC kde 4 switched to using a1 surfaces for font rendering which isn't currently accelerated by EXA. Notice the _a1 fetch below. No change there: KDE 3.5.9 across the board, although ironically one of my try-this-and-see-if-it-fixes-it attempts was going to be a KDE upgrade to 4.2, good thing I didn't try... (in fact there is only one system.) (Plus, that's a sysprof trace from a system using XAA :) I'd expect this use of Render to be accelerated on this card: it was under 1.4.2. Or at least it was very much faster.) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
Are you using the same version of kde on both systems? IIRC kde 4 switched to using a1 surfaces for font rendering which isn't currently accelerated by EXA. Notice the _a1 fetch below. I've seen quite many different reports about slow EXA which turned out to be caused by the A1 mask format (I haven't seen anybody using A4). Wouldn't it be possible to re-direct A1 allocation to an A8 pixmap, and convert at up- and downloading? At least for text, where pixmaps can't be accessed anyway? Thanks, Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On Thu, 2009-01-29 at 23:02 +0100, Clemens Eisserer wrote: Are you using the same version of kde on both systems? IIRC kde 4 switched to using a1 surfaces for font rendering which isn't currently accelerated by EXA. Notice the _a1 fetch below. I've seen quite many different reports about slow EXA which turned out to be caused by the A1 mask format (I haven't seen anybody using A4). Wouldn't it be possible to re-direct A1 allocation to an A8 pixmap, and convert at up- and downloading? At least for text, where pixmaps can't be accessed anyway? The EXA glyph cache code in the upcoming xserver 1.6 does precisely that when possible. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
