Bug#648222: Significant 2D performance regression with ColorTiling
Wow, I can only second this. I've been wondering what part of the last upgrade made my desktop so glacially slow and finally found that flipping the ColorTiling option to false makes a big difference. Everything feels at least an order of magnitude faster now. With ColorTiling enabled I had problems like: - Laggy window movements in fluxbox - Can see the chrome titlebar redraw - full-screen xterm takes about a second to render when switching desktops (In 2560x1440) With ColorTiling disabled everything is back to normal: - Window movement can always keep up with my mouse - No more annoying chrome titlebar flicker - xterm redraws in a split-second To illustrate this: ColorTiling enabled Moving a window in fluxbox: http://youtu.be/e__5dKZobxA xterm redraw/scroll speed: http://youtu.be/zx7K5213R7o ColorTiling disabled Moving a window in fluxbox:http://youtu.be/FSiQ34OHDbA xterm redraw/scroll speed: http://youtu.be/li9CTseCUqU Cheers, -- Tobias PGP: http://8ef7ddba.uguu.de ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#648222: Significant 2D performance regression with ColorTiling
Hi, I have experienced this same issue; same symptoms and ColorTiling workaround as Iustin reported. (I was complaining about this in 639621, though at the time I didn't know this was the issue; I have an r300 card: X1300.) Just a couple more thoughts: On Sun, Nov 13, 2011 at 1:34 PM, Iustin Pop wrote: > > I've tested further and this seems to be a problem specific to xterm > (and possibly other software? not sure how to test e.g. firefox's UI > speed): Fluxbox also appears to be severely impacted by this while moving and resizing windows. It's hard to give a quantitative benchmark for such a thing, but the resizing/moving can easily not keep up with the resize/move requests if done quickly enough. I'm not sure how similar this is to openbox; fluxbox displays the window position/size in the center of the screen while moving/resizing... it may just be updating that part of the display that causes the delay. This issue I find is also very difficult to find; I was only able to figure out anything wrt this by flipping random options in xorg.conf, until flipping ColorTiling made a difference. If you consider this to just be a bug in the relevant applications and the default should not be changed, I still would have found it immensely helpful to have some kind of indication to the user that ColorTiling is a switch that they may want to flip. Would mentioning this in the radeon man page sound acceptable? -- Andrew Deason adea...@dson.org ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#648222: Significant 2D performance regression with ColorTiling
On Thu, Nov 10, 2011 at 06:15:43PM +0100, Michel Dänzer wrote: > On Don, 2011-11-10 at 18:01 +0100, Michal Suchanek wrote: > > On 10 November 2011 17:46, Alex Deucher wrote: > > > On Wed, Nov 9, 2011 at 12:36 PM, Iustin Pop wrote: > > >> > > >> The recent upgrade of xserver-xorg-video-radeon from 1:6.14.2-2 to > > >> 1:6.14.3-1 enabled ColorTiling for my card, which in turn caused a > > >> significant performance degradation in 2D (yes, I understand it should > > >> make 3D faster, but I didn't know it should slow down 2D applications). > > >> > > >> I'm using plain 2D environment (openbox, no compositing, anything) and > > >> plain xterm (bitmap fonts, no AA, etc.). The speed of display text has > > >> changed significantly enough that I can "see" my mutt refreshing the > > >> inbox and drawing the lines. > > > > > > Tiling will speed up all rendering (2D and 3D). However, it sounds > > > like you are using an environment that is mostly software rendering. > > > As such in order for the CPU to access tiled buffers, the GPU has to > > > copy them to a linear buffer before CPU can access it properly. > > > > FWIW I have color tiling enabled and have no speed issues in urxvt - > > TrueType fonts, AA enabled, etc. > > > > Unlike xterm urxvt (rxvt-unicode) uses some special font-rendering > > libraries, however. > > > > If I understand it correctly xterm would use the in-server bitmap font > > rendering which the X server can accelerate as much as it wants. > > Core bitmap fonts are completely unaccelerated so far with EXA. xterm > can also use Xft for font rendering via the -fa option though, which is > well accelerated. Hi all, thanks for the replies. I've tested further and this seems to be a problem specific to xterm (and possibly other software? not sure how to test e.g. firefox's UI speed): Test file: ~20K lines. I've chosen the font sizes so as to have the same number of lines in full-screen. The timing is simply "time cat file". ColorTiling disabled: xterm -fn fixed: ~3.3s xterm -fa Mono -fs 8: ~8.6s rxvt-unicode -fn fixed: ~0.07s rxvt-unicode -fn xft:Mono:pixelsize=11: ~0.05s ColorTiling enabled: xterm -fn fixed: ~21s xterm -fa Mono -fs 8: ~7.8s rxvt-unicode -fn fixed: ~0.6s usually, sometimes ~0.1s?? rxvt-unicode -fn xft:Mono:pixelsize=11: ~0.05s So it seems to me that: a) whatever xterm does, it is very sub-optimal b) while xterm's -fa mode is indeed sped up by ColorTiling, it's still many times slower than with ColorTiling disabled and using core fonts c) also rxvt-unicode with core fonts is slowed down by color tiling, sometimes very much so (10x) Based on this I think this is mostly an xterm bug (-fa should/could be much faster), but I wonder if it also applies to other purely software 2D rendering. thanks, iustin signature.asc Description: Digital signature ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#648222: Significant 2D performance regression with ColorTiling
On Sun, Nov 13, 2011 at 1:34 PM, Iustin Pop wrote: > On Thu, Nov 10, 2011 at 06:15:43PM +0100, Michel Dänzer wrote: >> On Don, 2011-11-10 at 18:01 +0100, Michal Suchanek wrote: >> > On 10 November 2011 17:46, Alex Deucher wrote: >> > > On Wed, Nov 9, 2011 at 12:36 PM, Iustin Pop wrote: >> > >> >> > >> The recent upgrade of xserver-xorg-video-radeon from 1:6.14.2-2 to >> > >> 1:6.14.3-1 enabled ColorTiling for my card, which in turn caused a >> > >> significant performance degradation in 2D (yes, I understand it should >> > >> make 3D faster, but I didn't know it should slow down 2D applications). >> > >> >> > >> I'm using plain 2D environment (openbox, no compositing, anything) and >> > >> plain xterm (bitmap fonts, no AA, etc.). The speed of display text has >> > >> changed significantly enough that I can "see" my mutt refreshing the >> > >> inbox and drawing the lines. >> > > >> > > Tiling will speed up all rendering (2D and 3D). However, it sounds >> > > like you are using an environment that is mostly software rendering. >> > > As such in order for the CPU to access tiled buffers, the GPU has to >> > > copy them to a linear buffer before CPU can access it properly. >> > >> > FWIW I have color tiling enabled and have no speed issues in urxvt - >> > TrueType fonts, AA enabled, etc. >> > >> > Unlike xterm urxvt (rxvt-unicode) uses some special font-rendering >> > libraries, however. >> > >> > If I understand it correctly xterm would use the in-server bitmap font >> > rendering which the X server can accelerate as much as it wants. >> >> Core bitmap fonts are completely unaccelerated so far with EXA. xterm >> can also use Xft for font rendering via the -fa option though, which is >> well accelerated. > > Hi all, thanks for the replies. > > I've tested further and this seems to be a problem specific to xterm > (and possibly other software? not sure how to test e.g. firefox's UI > speed): > > Test file: ~20K lines. I've chosen the font sizes so as to have the same > number of lines in full-screen. The timing is simply "time cat file". > > ColorTiling disabled: > > xterm -fn fixed: ~3.3s > xterm -fa Mono -fs 8: ~8.6s > rxvt-unicode -fn fixed: ~0.07s > rxvt-unicode -fn xft:Mono:pixelsize=11: ~0.05s > > ColorTiling enabled: > > xterm -fn fixed: ~21s > xterm -fa Mono -fs 8: ~7.8s > rxvt-unicode -fn fixed: ~0.6s usually, sometimes ~0.1s?? > rxvt-unicode -fn xft:Mono:pixelsize=11: ~0.05s > > So it seems to me that: > > a) whatever xterm does, it is very sub-optimal > b) while xterm's -fa mode is indeed sped up by ColorTiling, it's still > many times slower than with ColorTiling disabled and using core > fonts > c) also rxvt-unicode with core fonts is slowed down by color tiling, > sometimes very much so (10x) > > Based on this I think this is mostly an xterm bug (-fa should/could be > much faster), but I wonder if it also applies to other purely software > 2D rendering. It likely does. We optimize the accelerated paths rather than the slow paths. Alex ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#648222: Significant 2D performance regression with ColorTiling
On Don, 2011-11-10 at 18:01 +0100, Michal Suchanek wrote: > On 10 November 2011 17:46, Alex Deucher wrote: > > On Wed, Nov 9, 2011 at 12:36 PM, Iustin Pop wrote: > >> > >> The recent upgrade of xserver-xorg-video-radeon from 1:6.14.2-2 to > >> 1:6.14.3-1 enabled ColorTiling for my card, which in turn caused a > >> significant performance degradation in 2D (yes, I understand it should > >> make 3D faster, but I didn't know it should slow down 2D applications). > >> > >> I'm using plain 2D environment (openbox, no compositing, anything) and > >> plain xterm (bitmap fonts, no AA, etc.). The speed of display text has > >> changed significantly enough that I can "see" my mutt refreshing the > >> inbox and drawing the lines. > > > > Tiling will speed up all rendering (2D and 3D). However, it sounds > > like you are using an environment that is mostly software rendering. > > As such in order for the CPU to access tiled buffers, the GPU has to > > copy them to a linear buffer before CPU can access it properly. > > FWIW I have color tiling enabled and have no speed issues in urxvt - > TrueType fonts, AA enabled, etc. > > Unlike xterm urxvt (rxvt-unicode) uses some special font-rendering > libraries, however. > > If I understand it correctly xterm would use the in-server bitmap font > rendering which the X server can accelerate as much as it wants. Core bitmap fonts are completely unaccelerated so far with EXA. xterm can also use Xft for font rendering via the -fa option though, which is well accelerated. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#648222: Significant 2D performance regression with ColorTiling
On 10 November 2011 17:46, Alex Deucher wrote: > On Wed, Nov 9, 2011 at 12:36 PM, Iustin Pop wrote: >> Package: xserver-xorg-video-radeon >> >> Version: 1:6.14.3-1 >> Severity: minor >> >> Hi, >> >> The recent upgrade of xserver-xorg-video-radeon from 1:6.14.2-2 to >> 1:6.14.3-1 enabled ColorTiling for my card, which in turn caused a >> significant performance degradation in 2D (yes, I understand it should >> make 3D faster, but I didn't know it should slow down 2D applications). >> >> I'm using plain 2D environment (openbox, no compositing, anything) and >> plain xterm (bitmap fonts, no AA, etc.). The speed of display text has >> changed significantly enough that I can "see" my mutt refreshing the >> inbox and drawing the lines. >> >> Cat-ing a big (~4K lines of text) file on a full-screen xterm is: >> >> - 6.14.2-2 (low power profile): ~0.8s >> - 6.14.3 (high power) : ~3.1s >> - 6.14.3 (low power) : ~5.0s >> >> So it's more than 5x time slower, which makes it "unpleasant". >> >> Simply disabling ColorTiling makes the problem go away, and 6.14.3 is as >> fast as 6.14.2. >> > > Tiling will speed up all rendering (2D and 3D). However, it sounds > like you are using an environment that is mostly software rendering. > As such in order for the CPU to access tiled buffers, the GPU has to > copy them to a linear buffer before CPU can access it properly. FWIW I have color tiling enabled and have no speed issues in urxvt - TrueType fonts, AA enabled, etc. Unlike xterm urxvt (rxvt-unicode) uses some special font-rendering libraries, however. If I understand it correctly xterm would use the in-server bitmap font rendering which the X server can accelerate as much as it wants. Thanks Michal ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#648222: Significant 2D performance regression with ColorTiling
On Wed, Nov 9, 2011 at 12:36 PM, Iustin Pop wrote: > Package: xserver-xorg-video-radeon > > Version: 1:6.14.3-1 > Severity: minor > > Hi, > > The recent upgrade of xserver-xorg-video-radeon from 1:6.14.2-2 to > 1:6.14.3-1 enabled ColorTiling for my card, which in turn caused a > significant performance degradation in 2D (yes, I understand it should > make 3D faster, but I didn't know it should slow down 2D applications). > > I'm using plain 2D environment (openbox, no compositing, anything) and > plain xterm (bitmap fonts, no AA, etc.). The speed of display text has > changed significantly enough that I can "see" my mutt refreshing the > inbox and drawing the lines. > > Cat-ing a big (~4K lines of text) file on a full-screen xterm is: > > - 6.14.2-2 (low power profile): ~0.8s > - 6.14.3 (high power) : ~3.1s > - 6.14.3 (low power) : ~5.0s > > So it's more than 5x time slower, which makes it "unpleasant". > > Simply disabling ColorTiling makes the problem go away, and 6.14.3 is as > fast as 6.14.2. > Tiling will speed up all rendering (2D and 3D). However, it sounds like you are using an environment that is mostly software rendering. As such in order for the CPU to access tiled buffers, the GPU has to copy them to a linear buffer before CPU can access it properly. Alex ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
