Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 09-13-06, 02:28 PM   #1
xiphmont
Registered User
 
Join Date: Jul 2003
Location: Somerville, MA
Posts: 17
Send a message via AIM to xiphmont
Default Bug report: *terrible* RENDER performance on QuadroFX 330 (8774)

Hello,

The x11perf output included below is representative of the general problem I'm seeing. RENDER operations start out nice and fast, and then it's like a switch gets flipped and everything from there on bogs down (a factor of 100 slowdown! The application never seems to recover). The problem appears entirely deterministic here, and the x11perf test will always trip it; the trapezoid test throughput plummets from 170,000/sec to 1500-2500/sec.

Disabling RENDER (with Option "RenderAccel" "off") 'eliminates' the problem; the Xserver clocks a completely steady 18,000 traps/sec... which is terrible compared to what I should be getting with this card, but still better than the numbers after the wings fall off of the hardware accelerated case.

Of course, x11perf is a synthetic test, but I do see this problem happening in apps (like Audacity); things start out nice and fast and then all of a sudden, *boom*, the application's UI screeches to a halt and never comes back. I am a bit sad that a six-year-old Parhelia eats this card for lunch.

Setup summary: X.Org 7.1, nvidia 8774, QuadroFX 330, Linux 2.6.17, K8WE w/dual Opteron 248s.

x11perf results with RenderAccel on (default):

Quote:
deep-space-bananafish:~> x11perf -aatrap2x10
x11perf - X11 performance program, version 1.5
The X.Org Foundation server version 70100000 on :0.0
from deep-space-bananafish
Thu Sep 14 02:55:54 2006

Sync time adjustment is 0.0257 msecs.

9000 reps @ 0.0060 msec (166000.0/sec): Fill 2x10 aa trap
9000 reps @ 0.0059 msec (170000.0/sec): Fill 2x10 aa trap
9000 reps @ 0.6066 msec ( 1650.0/sec): Fill 2x10 aa trap
9000 reps @ 0.6067 msec ( 1650.0/sec): Fill 2x10 aa trap
9000 reps @ 0.6065 msec ( 1650.0/sec): Fill 2x10 aa trap
45000 trep @ 0.3663 msec ( 2730.0/sec): Fill 2x10 aa trap
x11perf -aatrap2x10 results with RenderAccel off:

Quote:
deep-space-bananafish:~> x11perf -aatrap2x10
x11perf - X11 performance program, version 1.5
The X.Org Foundation server version 70100000 on :0.0
from deep-space-bananafish
Thu Sep 14 03:03:35 2006

Sync time adjustment is 0.0252 msecs.

90000 reps @ 0.0561 msec ( 17800.0/sec): Fill 2x10 aa trap
90000 reps @ 0.0561 msec ( 17800.0/sec): Fill 2x10 aa trap
90000 reps @ 0.0561 msec ( 17800.0/sec): Fill 2x10 aa trap
90000 reps @ 0.0561 msec ( 17800.0/sec): Fill 2x10 aa trap
90000 reps @ 0.0561 msec ( 17800.0/sec): Fill 2x10 aa trap
450000 trep @ 0.0561 msec ( 17800.0/sec): Fill 2x10 aa trap
nvidia-bug-report output to follow...

Monty
xiphmont is offline   Reply With Quote
Old 09-13-06, 02:43 PM   #2
xiphmont
Registered User
 
Join Date: Jul 2003
Location: Somerville, MA
Posts: 17
Send a message via AIM to xiphmont
Default nvidia-bug-report.log

edit: reread the instructions; attached a zip. As a thought, since this is a Linux forum, why not allow .gz?
Attached Files
File Type: zip nvidia-bug-report.zip (23.6 KB, 99 views)

Last edited by xiphmont; 09-13-06 at 02:56 PM.
xiphmont is offline   Reply With Quote
Old 09-13-06, 02:46 PM   #3
piotrq__
Registered User
 
Join Date: Jan 2006
Posts: 193
Default Re: Bug report: *terrible* RENDER performance on QuadroFX 330 (8774)

Well... So maybe ZIP that report then ?
piotrq__ is offline   Reply With Quote
Old 09-13-06, 02:47 PM   #4
xiphmont
Registered User
 
Join Date: Jul 2003
Location: Somerville, MA
Posts: 17
Send a message via AIM to xiphmont
Default nvidia-bug-report.log in parts

Note that this machine has two QuadroFX 330 cards; one is totally idle at the moment. It had been set up with the other in a wide Xinerama display, but has been commented out of the config entirely for testing purposes. The behavior I'm reporting above is with only one card active, as should be apparent in the log file.
Attached Files
File Type: log nvidia-bug-report-part1.log (74.1 KB, 102 views)
File Type: log nvidia-bug-report-part2.log (48.9 KB, 80 views)
xiphmont is offline   Reply With Quote
Old 09-13-06, 02:48 PM   #5
xiphmont
Registered User
 
Join Date: Jul 2003
Location: Somerville, MA
Posts: 17
Send a message via AIM to xiphmont
Default Re: Bug report: *terrible* RENDER performance on QuadroFX 330 (8774)

Quote:
Originally Posted by piotrq__
Well... So maybe ZIP that report then ?
Actually, you have a point, and the instructions do mention that. I'll post a zip.
xiphmont is offline   Reply With Quote
Old 09-13-06, 04:42 PM   #6
netllama
NVIDIA Corporation
 
Join Date: Dec 2004
Posts: 8,763
Default Re: Bug report: *terrible* RENDER performance on QuadroFX 330 (8774)

Bug 254021 has been opened for this problem.

Thanks,
Lonni
netllama is offline   Reply With Quote
Old 09-13-06, 04:44 PM   #7
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default Re: Bug report: *terrible* RENDER performance on QuadroFX 330 (8774)

Hi Monty!

This bug is caused by pixmaps being incorrectly moved to video memory when they should be left in system memory. I've filed bug 254021 on this issue. Note that it should only affect the RENDER triangle and trapezoid requests. Other rendering should not be affected by this problem.

-- Aaron
AaronP is offline   Reply With Quote
Old 09-13-06, 05:44 PM   #8
xiphmont
Registered User
 
Join Date: Jul 2003
Location: Somerville, MA
Posts: 17
Send a message via AIM to xiphmont
Default Re: Bug report: *terrible* RENDER performance on QuadroFX 330 (8774)

Quote:
Originally Posted by AaronP
Hi Monty!

This bug is caused by pixmaps being incorrectly moved to video memory when they should be left in system memory. I've filed bug 254021 on this issue. Note that it should only affect the RENDER triangle and trapezoid requests. Other rendering should not be affected by this problem.

-- Aaron
Thank you for the fast response; the core X folks here had guessed exactly that :-) It is odd that I see what appears to be similar behavior in other RENDER situations, so perhaps there is more than one issue (not necessarily with the nV provided drivers). I will continue testing until I can further characterize the other performance problems (eg, there is a linear performance degredation with aa and non-aa line *length*; doesn't matter how many waypoints or width or total pixels, there is a length/performance relationship that has a tipping point. I can't blame that on the driver yet.)

[edit: n/m the question I had also asked here, the X person sitting across from me said 'duh, of course trapezoids are different, they have to be decomposed into software spans.' :-]

Monty
__________________
'Monty' Montgomery
RedHat Desktop

Last edited by xiphmont; 09-13-06 at 05:56 PM.
xiphmont is offline   Reply With Quote

Old 09-14-06, 03:59 AM   #9
Linuxhippy
Registered User
 
Join Date: Feb 2004
Posts: 585
Default Re: Bug report: *terrible* RENDER performance on QuadroFX 330 (8774)

Quote:
Originally Posted by AaronP
This bug is caused by pixmaps being incorrectly moved to video memory when they should be left in system memory.
Well this implies that XREnder is currently not HW accalarted.
Does this mean we will not see HW accalerated XRender in near future (9xxx drivers)?

Thanks, lg Clemens
Linuxhippy is offline   Reply With Quote
Old 09-14-06, 07:50 AM   #10
zbiggy
Registered User
 
Join Date: Sep 2002
Posts: 623
Default Re: Bug report: *terrible* RENDER performance on QuadroFX 330 (8774)

Quote:
Originally Posted by Linuxhippy
Well this implies that XREnder is currently not HW accalarted.
Does this mean we will not see HW accalerated XRender in near future (9xxx drivers)?

Thanks, lg Clemens
Yes and no. It is known fact that small things in 2D are not worth hw acceleration because hw engine setup and pixmap transmission to GPU memory will take more time and overhead than doing it in software. You can get best performance by leaving small things to software render and big things accelerated in hardware. If something is bigger than human thumb then it is worth accelerating.

This is not true for cursor which should be always accelerated in hardware.

The best thing is to make desktop in 3D and use OpenGL to accelerate everything. Then all textures are in GPU ram so there is no need to transfer them several times. Another plus is driver developers can only take care of OpenGL which also developed for Windows. Less work, more fun. The only problem with OpenGL/Direct3D desktop is context switching. Microsoft pushes on IHVs to solve this so we can benefit too. Every present desktop OS uses multitasking on CPU to run multiple applications. Now it is right time for every modern GPU to follow CPUs way and run multiple 3D applications.
Hardware context switching is known since Intel 80286 (introduced by Intel on February 1, 1982.)

Xrender and exa was designed to help X survive till 3D desktop will be ready. When I look how it makes troubles for driver developers and users (hangs and freezeing) I'm going to think that all efforts should be pushed in OpenGL desktop development than old X reanimation using Xrender.

Last edited by zbiggy; 09-14-06 at 08:05 AM.
zbiggy is offline   Reply With Quote
Old 09-14-06, 12:15 PM   #11
Linuxhippy
Registered User
 
Join Date: Feb 2004
Posts: 585
Default Re: Bug report: *terrible* RENDER performance on QuadroFX 330 (8774)

Your thoughts don't seem to be thought to end:

1.) You have to transport system-ram pixmaps to the GPU sooner or later. If you paint into a pixmap you most likely want to display it which means expensive over-bus copying.
Its right that software rendering is faster for small primitives <~50px, however larger operations are magnitudes slower eating up all that benefit. have a look at your favourite desktop-app, most operations are much larger than 7*7px.

2.) Rendering through OpenGL adds a lot of overhead. This means that your small-primitive rendering will even suffer from more overhead.
Furthermore there is no reason why pixmaps need to be on system ram when using X whereas they can stay in VRAM when using OpenGL.
Even NVidia driver developers don't recommend this way, thats why they push that hard for texture_from_pixmap.

3.) Why should XRender lead to crashes and x-core rendering not *rofl*. With EXA its quite easy to add that kind of stuff, nvidia has as far as I know the same stuff developed on their own.

4.) Xrender is just an API/protocol. WTFK has this to do with OpenGL.

Man it seems you've just got catched by a hype.

lg Clemens
Linuxhippy is offline   Reply With Quote
Old 11-08-06, 11:58 AM   #12
d'Oursse
Registered User
 
Join Date: Dec 2004
Posts: 5
Default Re: Bug report: *terrible* RENDER performance on QuadroFX 330 (8774)

Quote:
Originally Posted by zbiggy
Yes and no. It is known fact that small things in 2D are not worth hw acceleration because hw engine setup and pixmap transmission to GPU memory will take more time and overhead than doing it in software. You can get best performance by leaving small things to software render and big things accelerated in hardware. If something is bigger than human thumb then it is worth accelerating.
I do not agree : the ati with r200 chipset have hardware accelerated xrender routines (xorg >= 6.9 and EXA interface). Evas (a graphic library) has a small benchmark. You can choose software or xrender engine. With xorg >= 6.9 and EXA, the xrender engine is really fast (faster than the engine using the software or opengl backend)
Quote:
This is not true for cursor which should be always accelerated in hardware.

The best thing is to make desktop in 3D and use OpenGL to accelerate everything. Then all textures are in GPU ram so there is no need to transfer them several times. Another plus is driver developers can only take care of OpenGL which also developed for Windows. Less work, more fun. The only problem with OpenGL/Direct3D desktop is context switching. Microsoft pushes on IHVs to solve this so we can benefit too. Every present desktop OS uses multitasking on CPU to run multiple applications. Now it is right time for every modern GPU to follow CPUs way and run multiple 3D applications.
Hardware context switching is known since Intel 80286 (introduced by Intel on February 1, 1982.)

Xrender and exa was designed to help X survive till 3D desktop will be ready. When I look how it makes troubles for driver developers and users (hangs and freezeing) I'm going to think that all efforts should be pushed in OpenGL desktop development than old X reanimation using Xrender.
opengl drivers are not stable. In addition, you loose quality with opengl textures. And 3d desktops are nothing but a demo for a technology. They are NOT usuable for dayly usage.

The only argument I can see and which justify opengl and 3d : games. Only games are justifying the power of video cards, and their sale.

Driver manufacturers should have pushed hardware implementation of xrender routined for years (6 or 7 years). They have preferred the 3d way only for marketing stuff
d'Oursse is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
My UT2003 Tweak Guide DXnfiniteFX Gaming Central 48 10-30-02 11:59 PM

All times are GMT -5. The time now is 07:15 AM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.