From: Keith R. J. W. <kr...@op...> - 2003-01-31 18:43:37
|
I need to gather more information so I may submit a bug report to NVidia. So, is anyone out there using (or have tried using) ROX-Filer 1.3.5 (probably 1.3.6 too) with the x86 1.0-4191 linux drivers from nvidia.com? If so, I'm curious as to the performance. Since attempting to us 1.0-4191, ROX-Filer performance was horribly slow (please note that this is with a pinboard only that has a backdrop set & at 1600x1200 res); something as simple as dragging a lasso box around pinboard icons would spike the CPU usage. Pinboard redraws (when switching desktops under icewm) were also considerably slow and CPU intensive. Reverting back to the 1.0-3123 drivers corrects this issue. This is using a GForce2 GTS with the agpgart kernel module (2.4.20) and XFree86 4.2.0. *sigh* I wish NVidia would open their source already so we could fix it. :) -- Keith R. John Warno [k r j w at optonline dot net] "Kindness is a language which the deaf can hear and the blind can read." -- Mark Twain |
From: Olivier F. <fo...@xf...> - 2003-01-31 20:40:50
|
John, Most recent video cards are 3D capable and reserve some amount of onboard memory for 3D. As it seems, with recent NVidia drivers, the amount of memory left for pixmap is fairly small. What happens is that the video image f the backdrop doesn't fit in the video memory (although you might have tons of megs on the card, the fact is that this video memory is kept for 3D) As the pixmap doesn't fit in video memory, XFree has to store it in the main memory and transfers are very slow between video<->system memory. That's why it looks so slow when you drag windows... Thomas, You can easily fix that for the filer by turning off double buffering on the backdrop window. Since it's a gtk window, it has double buffering enabled by default, meaning that twice as much video memory is required (for almost nothing in that case since the window has no chance to be resized). By turning double buffering off, it fixes the problem and greatly improves performance. if (GTK_WIDGET_DOUBLE_BUFFERED(win)) { gtk_widget_set_double_buffered(win, FALSE); } I had the same problem with xfdesktop, xfce4 desktop app similar to ROX desktop, and that fixed the problem for good. Hope that helps, Best regards, -- Olivier Fourdan <fo...@xf...> http://www.xfce.org On Fri, 2003-01-31 at 19:43, Keith R. John Warno wrote: > I need to gather more information so I may submit a bug report to > NVidia. So, is anyone out there using (or have tried using) ROX-Filer > 1.3.5 (probably 1.3.6 too) with the x86 1.0-4191 linux drivers from > nvidia.com? If so, I'm curious as to the performance. Since attempting > to us 1.0-4191, ROX-Filer performance was horribly slow (please note > that this is with a pinboard only that has a backdrop set & at 1600x1200 > res); something as simple as dragging a lasso box around pinboard icons > would spike the CPU usage. Pinboard redraws (when switching desktops > under icewm) were also considerably slow and CPU intensive. Reverting > back to the 1.0-3123 drivers corrects this issue. > > This is using a GForce2 GTS with the agpgart kernel module (2.4.20) and > XFree86 4.2.0. *sigh* I wish NVidia would open their source already so > we could fix it. :) |
From: Keith R. J. W. <kr...@op...> - 2003-01-31 21:25:09
|
* Olivier Fourdan <fo...@xf...> [31/01/2003 1540EST]: > Most recent video cards are 3D capable and reserve some amount of > onboard memory for 3D. As it seems, with recent NVidia drivers, the > amount of memory left for pixmap is fairly small. What happens is that > the video image f the backdrop doesn't fit in the video memory (although > you might have tons of megs on the card, the fact is that this video > memory is kept for 3D) > > As the pixmap doesn't fit in video memory, XFree has to store it in the > main memory and transfers are very slow between video<->system memory. > That's why it looks so slow when you drag windows... [...] Aha. Well I'd certainly consider this to be a design flaw on the part of NVidia. Thanks for the feedback! -- Keith R. John Warno [k r j w at optonline dot net] |
From: Olivier F. <fo...@xf...> - 2003-01-31 21:45:30
|
Hi Keith, On Fri, 2003-01-31 at 22:24, Keith R. John Warno wrote: > Well I'd certainly consider this to be a design flaw on the part > of NVidia. Humm, I wouldn't say that... Firstly, people usually buy NVidia cards for 3D accel. It makes perfectly sense to reserve a large amount of the video memory for that purpose (note that I have no real clue here, I don't work for NVidia :) Secondly I would bet that there must be an option in XF86Config to set the pixmap memory for NVidia drivers (The driver section in XF86Config is indeed driver specific, so there are options that I personnaly ignore because I never took time to dig into it - I know, for example, that there are NVidia specific options to draw a nice alpha shadow under the mouse pointer even in XFree86 < 4.3) Cheers, Olivier. -- Olivier Fourdan <fo...@xf...> http://www.xfce.org |
From: Keith R. J. W. <kr...@op...> - 2003-01-31 22:20:25
|
* Olivier Fourdan <fo...@xf...> [31/01/2003 1645EST]: > Hi Keith, > > On Fri, 2003-01-31 at 22:24, Keith R. John Warno wrote: > > > Well I'd certainly consider this to be a design flaw on the part > > of NVidia. > > Humm, I wouldn't say that... Well, my logic (if anyone can call it logic. hehe) is that even if a person spends a few hundred bucks on a 3D accelerator, she is probably still going to spend *much* more time doing 2D stuff than 3D stuff. The only exceptions may be folks that work with 3D programming or rendering (Maya, maybe?), or the 10 year old twerp who has nothing to do but play q3a and Wolfenstein all day. Maybe I'm "weird" or something but I use the same machine for both work (nearly all only 2D) and play (all 3D) and have a liking for NVidia technology. :-/ > Firstly, people usually buy NVidia cards for 3D accel. It makes > perfectly sense to reserve a large amount of the video memory for that > purpose (note that I have no real clue here, I don't work for NVidia :) Of course it makes sense but it's obviously implemented at the driver level anyway. Why the change from 1.0-3123 to 1.0-4191? Who knows, and I wouldn't be surprised if it's undocumented. > Secondly I would bet that there must be an option in XF86Config to set > the pixmap memory for NVidia drivers (The driver section in XF86Config > is indeed driver specific, so there are options that I personnaly ignore > because I never took time to dig into it - I know, for example, that > there are NVidia specific options to draw a nice alpha shadow under the > mouse pointer even in XFree86 < 4.3) Lol. I use that alpha shadow. :-) grepping for "pixmap" in the README that comes with the nvidia GLX stuff yields one line where they briefly mantion pixmap caching. However the XF86Config has many pixmap-related options, most of them dealing with XAA (X Acceleration Architecture). This is probably where the solution is and I'll do a little experimenting. Once again, thanks for your feedback! krjw. -- Keith R. John Warno [k r j w at optonline dot net] "Now we know why she made her living as a stripper -- her clothes are just too ugly to wear." -- Reuters news article about Anna Nicole Smith |
From: Thomas L. <ta...@ec...> - 2003-02-01 14:45:08
|
On Fri, Jan 31, 2003 at 09:24:37PM +0100, Olivier Fourdan wrote: > John, > > Most recent video cards are 3D capable and reserve some amount of > onboard memory for 3D. As it seems, with recent NVidia drivers, the > amount of memory left for pixmap is fairly small. What happens is that > the video image f the backdrop doesn't fit in the video memory (although > you might have tons of megs on the card, the fact is that this video > memory is kept for 3D) > > As the pixmap doesn't fit in video memory, XFree has to store it in the > main memory and transfers are very slow between video<->system memory. > That's why it looks so slow when you drag windows... > > Thomas, > > You can easily fix that for the filer by turning off double buffering on > the backdrop window. Since it's a gtk window, it has double buffering > enabled by default, meaning that twice as much video memory is required > (for almost nothing in that case since the window has no chance to be > resized). Unfortunately, turning off double buffering also completely messes up the redrawing of the icons. My plan was to break the area down into smaller tiles for drawing (see TODO note in pinboard.c:1493), possibly by intersecting the redraw region with the occupied regions and then redrawing all the rectangles in that. However, since redraw is very fast on my machine, it's difficult to know what will make a difference. I really need someone with a slow machine to implement it ;-) -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Thomas L. <ta...@ec...> - 2003-02-01 17:19:52
|
On Sat, Feb 01, 2003 at 02:43:23PM +0000, Thomas Leonard wrote: [ pinboard double-buffering ] > Unfortunately, turning off double buffering also completely messes up the > redrawing of the icons. My plan was to break the area down into smaller > tiles for drawing (see TODO note in pinboard.c:1493), possibly by > intersecting the redraw region with the occupied regions and then > redrawing all the rectangles in that. Well, I've done some experiments. Drawing each rectangle in the region doesn't work well, because there are sometimes hundreds of 2x1 areas. Dividing the area into tiles also doesn't work, because it's far too slow (you can watch the tiles appearing!). Instead, I've done as Olivier suggested and turned off double buffering. The problems with this approach before turned out to be clipping related (some of the drawing operations don't do their own clipping because they assume the pixmap will get clipped as it's applied). I've tried to work around those problems. The new system might be slightly more flickery, but it should be a lot faster for people with limited video memory (and probably faster for everyone else too). Probably needs lots of testing... -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Jim K. <jmk...@po...> - 2003-02-01 20:11:46
|
Circa 2003-02-01 14:43:23 +0000 dixit Thomas Leonard: : However, since redraw is very fast on my machine, it's difficult to know : what will make a difference. I really need someone with a slow machine to : implement it ;-) You can always run under something like bochs ( http://bochs.sourceforge.net/ ) to slow things down a bit. Alternatively, temporarily turn off accelerated video drawing in your X server (use 'Option "Accel" "off"' in the "Device" section). You can also slow down a system somewhat by reducing the amount of real memory available (anyone know if modern Linux kernels accept the 'mem=3D' option to specify less than the real amount of physical memory?). Cheers. --=20 jim knoble | jmk...@po... | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) "I am non-refutable." --Enik the Altrusian |