Bug report: *terrible* RENDER performance on QuadroFX 330 (8774)

[xiphmont]

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):

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:

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]

edit: reread the instructions; attached a zip. As a thought, since this is a Linux forum, why not allow .gz?

[piotrq__]

Well... So maybe ZIP that report then ?

[xiphmont]

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.

[xiphmont]

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.

[netllama]

Bug 254021 has been opened for this problem.

Thanks,
Lonni

[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

[xiphmont]

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

[Linuxhippy]

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

[zbiggy]

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.

[Linuxhippy]

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

[d'Oursse]

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)

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