Bug#519221: libpixman -- bug recently submitted related to your patch
Hey, André; Has anything interesting happened in the last ten days? :) Were you able to get your test setup to reproduce this problem? 2009/3/14 Arren Lex arren...@gmail.com: Hello, Andre: Earlier, I provided my xorg configuration and Xorg.0.log (they were not addressed to you, but you can find them on the bug's page). They may help you to set up an environment. There is no colour depth specified in my xorg configuration, so it's whatever it defaults to -- I guess 24? I have a laptop running debian (intel video drivers) where this bug does not appear. Therefore, it looks like something particular to my configuration. I hope you can reproduce it on your test setup, but if not, I am happy to try anything you suggest or apply any patches. Thanks for all your help, Arren 2009/3/14 André Tupinambá andre...@gmail.com: Hi Arren, The SSE2 code is really faster than C equivalent, but performs better with images larger than 16 pixels wide. Since to get the SSE2 best performance we need to align the destination address in 16 bytes. So all operations are made in three loops, one for the alignment, one for the bulk operation and the last one for operate the last pixels. But with small images, all operations are done within the alignment and tail loops. That is what is going on on this case, I guess. I'm creating and environment to trying to get this bug. Which color depth are you using? Regards. André Tupinambá On Wed, Mar 11, 2009 at 8:06 PM, Arren Lex arren...@gmail.com wrote: Sorry, I left out this piece of possibly useful information: I have a dual-monitor setup -- one is 1280x1024 and one is 1680x1050. I usually run konsole maximized across the larger monitor, and it is terribly slow like that. When I make the konsole window smaller, the problem becomes less noticeable (but even when the window is very small, you can easily tell the problem is still there because the text makes waves as it scrolls). This behaviour leads me to think it might be falling back to software rendering for painting the text now. Is that possible? -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519221: libpixman -- bug recently submitted related to your patch
Hi Arren, The SSE2 code is really faster than C equivalent, but performs better with images larger than 16 pixels wide. Since to get the SSE2 best performance we need to align the destination address in 16 bytes. So all operations are made in three loops, one for the alignment, one for the bulk operation and the last one for operate the last pixels. But with small images, all operations are done within the alignment and tail loops. That is what is going on on this case, I guess. I'm creating and environment to trying to get this bug. Which color depth are you using? Regards. André Tupinambá On Wed, Mar 11, 2009 at 8:06 PM, Arren Lex arren...@gmail.com wrote: Sorry, I left out this piece of possibly useful information: I have a dual-monitor setup -- one is 1280x1024 and one is 1680x1050. I usually run konsole maximized across the larger monitor, and it is terribly slow like that. When I make the konsole window smaller, the problem becomes less noticeable (but even when the window is very small, you can easily tell the problem is still there because the text makes waves as it scrolls). This behaviour leads me to think it might be falling back to software rendering for painting the text now. Is that possible? -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519221: libpixman -- bug recently submitted related to your patch
Hello, Andre: Earlier, I provided my xorg configuration and Xorg.0.log (they were not addressed to you, but you can find them on the bug's page). They may help you to set up an environment. There is no colour depth specified in my xorg configuration, so it's whatever it defaults to -- I guess 24? I have a laptop running debian (intel video drivers) where this bug does not appear. Therefore, it looks like something particular to my configuration. I hope you can reproduce it on your test setup, but if not, I am happy to try anything you suggest or apply any patches. Thanks for all your help, Arren 2009/3/14 André Tupinambá andre...@gmail.com: Hi Arren, The SSE2 code is really faster than C equivalent, but performs better with images larger than 16 pixels wide. Since to get the SSE2 best performance we need to align the destination address in 16 bytes. So all operations are made in three loops, one for the alignment, one for the bulk operation and the last one for operate the last pixels. But with small images, all operations are done within the alignment and tail loops. That is what is going on on this case, I guess. I'm creating and environment to trying to get this bug. Which color depth are you using? Regards. André Tupinambá On Wed, Mar 11, 2009 at 8:06 PM, Arren Lex arren...@gmail.com wrote: Sorry, I left out this piece of possibly useful information: I have a dual-monitor setup -- one is 1280x1024 and one is 1680x1050. I usually run konsole maximized across the larger monitor, and it is terribly slow like that. When I make the konsole window smaller, the problem becomes less noticeable (but even when the window is very small, you can easily tell the problem is still there because the text makes waves as it scrolls). This behaviour leads me to think it might be falling back to software rendering for painting the text now. Is that possible? -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519221: libpixman -- bug recently submitted related to your patch
On Don, 2009-03-12 at 09:46 -0600, Arren Lex wrote: The files you requested (plus some related ones that might be useful) are attached. [...] Screen 0: minimum 320 x 200, current 2960 x 1050, maximum 2960 x 1280 This is likely your first problem. The 3D engine of your card can only handle coordinates up to 2560x2560. As your screen is wider than that, any operations on the screen which would need the 3D engine for acceleration will fall back to software. If you aren't using a compositing manager yet, doing so might help, but otherwise you'll probably need to fit the screen size within the limit somehow. However, due to peculiarities in the way KDE/Qt4 render text, I suspect you may still be hitting other fallback paths which have only been fixed in newer xserver upstream. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519221: libpixman -- bug recently submitted related to your patch
Hello, Michel; This is likely your first problem. The 3D engine of your card can only handle coordinates up to 2560x2560. I don't understand how this could be a factor. I am well aware that part of my screen is out of the 3D engine's domain, but this is not a problem for me as I don't do anything that requires 3D acceleration. The 2D acceleration engine supports a 4096x4096 desktop and I am well within that limit. Also, I don't see why using a terminal emulator should depend on 3D acceleration. Furthermore, this setup worked perfectly before that pixman patch. If it is related to my 3D virtual desktop size, why is it that an sse2 patch in pixman triggered the problem? However, due to peculiarities in the way KDE/Qt4 render text, I suspect you may still be hitting other fallback paths which have only been fixed in newer xserver upstream. I am using kde3 at the moment. Thanks, Arren -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519221: libpixman -- bug recently submitted related to your patch
I forgot to CC the bug in this conversation. The following is Michel's response and my reply: The 2D acceleration engine supports a 4096x4096 desktop and I am well within that limit. Also, I don't see why using a terminal emulator should depend on 3D acceleration. For text rendering, which these days is usually implemented using a RENDER extension Composite operation. Furthermore, this setup worked perfectly before that pixman patch. If it is related to my 3D virtual desktop size, why is it that an sse2 patch in pixman triggered the problem? It didn't; apparently the software rendering speed was just good enough for you before. I'm just saying that you might get even better performance than before with hardware acceleration, but of course the pixman performance regression should be addressed regardless. Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer Ah, I misunderstood the intent of your reply. I am quite content with what I had before; if we can fix the pixman regression and I can have a snappy console again, I will be happy, regardless of what is doing the rendering. :) I have never experienced performance problems and would much rather continue to work as I have than to run below native resolution of my monitors to fit in the 3D desktop buffer, purchase a new video card, or rearrange my monitor setup. Arren -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519221: libpixman -- bug recently submitted related to your patch
On Mit, 2009-03-11 at 17:06 -0600, Arren Lex wrote: I have a dual-monitor setup -- one is 1280x1024 and one is 1680x1050. I usually run konsole maximized across the larger monitor, and it is terribly slow like that. When I make the konsole window smaller, the problem becomes less noticeable (but even when the window is very small, you can easily tell the problem is still there because the text makes waves as it scrolls). This behaviour leads me to think it might be falling back to software rendering for painting the text now. Is that possible? Yes, otherwise pixman (the software rendering library) shouldn't matter for performance. So the question is why it's falling back to software rendering, but there are many possibilities. If you provide the full Xorg.0.log and the output of xrandr, that might be a good start for ideas. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519221: libpixman -- bug recently submitted related to your patch
Hi Arren, This is a old patch, about add SSE2 implementation for many compose operations. This code was first released in pixman 0.12.0. I really don't know what is going on, I need to investigate this. Just in case, a good test is run the pixman configure with --disable-sse2, to disable this code, keeping all other pixman implementation and modifications. BTW, I care about :) []'s André Tupinambá PS: Sorry about any English mistakes, I'm Brazillian and English isn't my first language. On Wed, Mar 11, 2009 at 12:11 AM, Arren Lex arren...@gmail.com wrote: Hello; I have recently submitted a libpixman bug introduced by a regression caused by one of your patches. The bug report is available here -- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519221 I don't know if you care about this; I was just hoping you may have had some insight as to what causes it, or ideas how to fix it. :) I want my terminal back! If you want, you can comment on the bug report by emailing responses to 519...@bugs.debian.org Thanks a lot for your time, Arren Lex -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519221: libpixman -- bug recently submitted related to your patch
Thank you for your response. I have compiled the latest git of pixman with the --disable-sse2 flag and it works perfectly. The problems are gone when I disable that flag. Here is some more information about my system in case any of it is helpful: - AMD Opteron dual-core CPU, 2.4 GHz, supporting with flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy. - I am running a 32-bit OS, although the CPU supports 64. - ATI X300SE PCI-E video card, using the free and open-source radeon driver for 3D acceleration. I believe this driver only supports some of openGL 1.2. - Kernel 2.6.26 - 1GB ram - Terminal emulator is konsole from KDE 3.5; pseudo-transparency is turned on (that is, it paints the desktop background as the terminal background to make it appear transparent) I hope we can find the source of this problem. :) Is it possible to take out only some of the sse2 modifications so we can determine which optimization is causing problems? Thanks for your time, Arren 2009/3/11 André Tupinambá andre...@gmail.com: Hi Arren, This is a old patch, about add SSE2 implementation for many compose operations. This code was first released in pixman 0.12.0. I really don't know what is going on, I need to investigate this. Just in case, a good test is run the pixman configure with --disable-sse2, to disable this code, keeping all other pixman implementation and modifications. BTW, I care about :) []'s André Tupinambá PS: Sorry about any English mistakes, I'm Brazillian and English isn't my first language. On Wed, Mar 11, 2009 at 12:11 AM, Arren Lex arren...@gmail.com wrote: Hello; I have recently submitted a libpixman bug introduced by a regression caused by one of your patches. The bug report is available here -- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519221 I don't know if you care about this; I was just hoping you may have had some insight as to what causes it, or ideas how to fix it. :) I want my terminal back! If you want, you can comment on the bug report by emailing responses to 519...@bugs.debian.org Thanks a lot for your time, Arren Lex -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519221: libpixman -- bug recently submitted related to your patch
Sorry, I left out this piece of possibly useful information: I have a dual-monitor setup -- one is 1280x1024 and one is 1680x1050. I usually run konsole maximized across the larger monitor, and it is terribly slow like that. When I make the konsole window smaller, the problem becomes less noticeable (but even when the window is very small, you can easily tell the problem is still there because the text makes waves as it scrolls). This behaviour leads me to think it might be falling back to software rendering for painting the text now. Is that possible? -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
