nouveau slower than nv and vesa on quadro 135M

nouveau slower than nv and vesa on quadro 135M

[Helge Hafting]

I followed the advice at
http://nouveau.freedesktop.org/wiki/DebianInstall
in order to test nouveau with debian.

I found that nouveau works well with the laptop where I occationally
connect another monitor. The xrandr stuff is perfect.

But performance is low for some uses:
* I first noticed that the default X background (a pattern) was painted
   rather slowly. A solid color background is much faster though. The
   vesa driver does this pattern visibly faster. With nouveau,
   one sees the pattern coming down the screen. With vesa,
   it just appears.

* The car navigation program "navit" is unuseable with nouveau. I paints
   a map every second (due to gps updates.) However, it locks X 	
   completely for 10-15 seconds before the map appear. Nothing at
   all happens on screen. I can move the mouse, but no windows update
   at all. Then the map suddenly appears, and the load meter update,
   showing that one cpu core was 100% busy during those 10 seconds.

   Navit paints maps using polylines, filled polygons, and occational
   bitmaps. An extremely small window works, anything big enough for
   navigation is way too much. Vesa has no problems though.

The machine is a Dell latitude D830 laptop, with a core2duo in 64-bit 
mode. I use debian testing, with various X packages from 
unstable/experimental as needed.
The graphics card identifies itself as:
VGA compatible controller: nVidia Corporation Quadro NVS 135M (rev a1)

I also found that nouveau needs X 1.4.2, it fails with X 1.5.0. That is 
ok, but the performance problems makes it unuseable.

Helge Hafting

Re: nouveau slower than nv and vesa on quadro 135M

[Maarten Maathuis]

On Sun, Sep 14, 2008 at 12:17 PM, Helge Hafting
<helge.hafting-i5bjtSbraLbLX0NG8FE4ug@public.gmane.org> wrote:
> I followed the advice at
> http://nouveau.freedesktop.org/wiki/DebianInstall
> in order to test nouveau with debian.
>
> I found that nouveau works well with the laptop where I occationally
> connect another monitor. The xrandr stuff is perfect.
>
> But performance is low for some uses:
> * I first noticed that the default X background (a pattern) was painted
>   rather slowly. A solid color background is much faster though. The
>   vesa driver does this pattern visibly faster. With nouveau,
>   one sees the pattern coming down the screen. With vesa,
>   it just appears.

Known xserver/exa problem, fixed in master (from what i was told), but
xserver-1.6.0 will the first release to contain it.

>
> * The car navigation program "navit" is unuseable with nouveau. I paints
>   a map every second (due to gps updates.) However, it locks X
>   completely for 10-15 seconds before the map appear. Nothing at
>   all happens on screen. I can move the mouse, but no windows update
>   at all. Then the map suddenly appears, and the load meter update,
>   showing that one cpu core was 100% busy during those 10 seconds.
>
>   Navit paints maps using polylines, filled polygons, and occational
>   bitmaps. An extremely small window works, anything big enough for
>   navigation is way too much. Vesa has no problems though.

If this is what i think it is, then this should be better in xserver
1.5.0, but if not, some profiling should reveal the problem.

>
> The machine is a Dell latitude D830 laptop, with a core2duo in 64-bit
> mode. I use debian testing, with various X packages from
> unstable/experimental as needed.
> The graphics card identifies itself as:
> VGA compatible controller: nVidia Corporation Quadro NVS 135M (rev a1)
>
> I also found that nouveau needs X 1.4.2, it fails with X 1.5.0. That is
> ok, but the performance problems makes it unuseable.

Why does 1.5.0 fail? A xorg log would be nice.

>
> Helge Hafting
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>

Out of curiosity, could you use check the gpu and memory clock
frequencies with nvclock?

Re: nouveau slower than nv and vesa on quadro 135M

[Helge Hafting]

Maarten Maathuis wrote:
> On Sun, Sep 14, 2008 at 12:17 PM, Helge Hafting
> <helge.hafting-i5bjtSbraLbLX0NG8FE4ug@public.gmane.org> wrote:
>> I followed the advice at
>> http://nouveau.freedesktop.org/wiki/DebianInstall
>> in order to test nouveau with debian.
>>
>> I found that nouveau works well with the laptop where I occationally
>> connect another monitor. The xrandr stuff is perfect.
>>
>> But performance is low for some uses:
>> * I first noticed that the default X background (a pattern) was painted
>>   rather slowly. A solid color background is much faster though. The
>>   vesa driver does this pattern visibly faster. With nouveau,
>>   one sees the pattern coming down the screen. With vesa,
>>   it just appears.
> 
> Known xserver/exa problem, fixed in master (from what i was told), but
> xserver-1.6.0 will the first release to contain it.
> 
>> * The car navigation program "navit" is unuseable with nouveau. I paints
>>   a map every second (due to gps updates.) However, it locks X
>>   completely for 10-15 seconds before the map appear. Nothing at
>>   all happens on screen. I can move the mouse, but no windows update
>>   at all. Then the map suddenly appears, and the load meter update,
>>   showing that one cpu core was 100% busy during those 10 seconds.
>>
>>   Navit paints maps using polylines, filled polygons, and occational
>>   bitmaps. An extremely small window works, anything big enough for
>>   navigation is way too much. Vesa has no problems though.
> 
> If this is what i think it is, then this should be better in xserver
> 1.5.0, but if not, some profiling should reveal the problem.

It is better, but not solved. A full screen map with few details now
paints in 2s instead of 10s.  Definitely improvement, but not yet
useable for me.
> 
>> The machine is a Dell latitude D830 laptop, with a core2duo in 64-bit
>> mode. I use debian testing, with various X packages from
>> unstable/experimental as needed.
>> The graphics card identifies itself as:
>> VGA compatible controller: nVidia Corporation Quadro NVS 135M (rev a1)
>>
>> I also found that nouveau needs X 1.4.2, it fails with X 1.5.0. That is
>> ok, but the performance problems makes it unuseable.
> 
> Why does 1.5.0 fail? A xorg log would be nice.

My fault, I built with the 1.4.2 dev library. After correcting that,
nouveau works with X 1.5.0.

Firefox and such is fine, but the car navigation program is still too slow.

Helge Hafting

Re: nouveau slower than nv and vesa on quadro 135M

[Maarten Maathuis]

On Sun, Sep 14, 2008 at 2:50 PM, Helge Hafting
<helge.hafting-i5bjtSbraLbLX0NG8FE4ug@public.gmane.org> wrote:
> Maarten Maathuis wrote:
>>
>> On Sun, Sep 14, 2008 at 12:17 PM, Helge Hafting
>> <helge.hafting-i5bjtSbraLbLX0NG8FE4ug@public.gmane.org> wrote:
>>>
>>> I followed the advice at
>>> http://nouveau.freedesktop.org/wiki/DebianInstall
>>> in order to test nouveau with debian.
>>>
>>> I found that nouveau works well with the laptop where I occationally
>>> connect another monitor. The xrandr stuff is perfect.
>>>
>>> But performance is low for some uses:
>>> * I first noticed that the default X background (a pattern) was painted
>>>  rather slowly. A solid color background is much faster though. The
>>>  vesa driver does this pattern visibly faster. With nouveau,
>>>  one sees the pattern coming down the screen. With vesa,
>>>  it just appears.
>>
>> Known xserver/exa problem, fixed in master (from what i was told), but
>> xserver-1.6.0 will the first release to contain it.
>>
>>> * The car navigation program "navit" is unuseable with nouveau. I paints
>>>  a map every second (due to gps updates.) However, it locks X
>>>  completely for 10-15 seconds before the map appear. Nothing at
>>>  all happens on screen. I can move the mouse, but no windows update
>>>  at all. Then the map suddenly appears, and the load meter update,
>>>  showing that one cpu core was 100% busy during those 10 seconds.
>>>
>>>  Navit paints maps using polylines, filled polygons, and occational
>>>  bitmaps. An extremely small window works, anything big enough for
>>>  navigation is way too much. Vesa has no problems though.
>>
>> If this is what i think it is, then this should be better in xserver
>> 1.5.0, but if not, some profiling should reveal the problem.
>
> It is better, but not solved. A full screen map with few details now
> paints in 2s instead of 10s.  Definitely improvement, but not yet
> useable for me.

A profile of running this application would be useful (with nouveau
and xorg symbols). I have some suspicions as to the cause,
but some facts would be nice to have. Either oprofile or sysprof will
do, for oprofile we have a wiki page:
http://nouveau.freedesktop.org/wiki/OProfile

>>
>>> The machine is a Dell latitude D830 laptop, with a core2duo in 64-bit
>>> mode. I use debian testing, with various X packages from
>>> unstable/experimental as needed.
>>> The graphics card identifies itself as:
>>> VGA compatible controller: nVidia Corporation Quadro NVS 135M (rev a1)
>>>
>>> I also found that nouveau needs X 1.4.2, it fails with X 1.5.0. That is
>>> ok, but the performance problems makes it unuseable.
>>
>> Why does 1.5.0 fail? A xorg log would be nice.
>
> My fault, I built with the 1.4.2 dev library. After correcting that,
> nouveau works with X 1.5.0.
>
> Firefox and such is fine, but the car navigation program is still too slow.
>
> Helge Hafting
>
>

Re: nouveau slower than nv and vesa on quadro 135M

[Helge Hafting]

Maarten Maathuis wrote:

> A profile of running this application would be useful (with nouveau
> and xorg symbols). I have some suspicions as to the cause,
> but some facts would be nice to have. Either oprofile or sysprof will
> do, for oprofile we have a wiki page:
> http://nouveau.freedesktop.org/wiki/OProfile
> 
That wiki page doesn't list the first necessary step,
which is "opcontrol --init". Adding that might be useful for newbies.

I profiled two apps that are too slow with this driver.
* navit (map navigation), slowly panning the map across a city. This
   panning redraws the map each time, which is instantaneous with the
   vesa driver.

* lyx (word processor), typing text into a table. The pc could not
   keep up with keyboard autorepeat, giving me one to three characters
   per second. Each keypress redraws the table lines and the text
   in the table cell.

I am not sure if I have all the symbols needed. I used nouveau compiled
per the instructions for debian. The X server consist of packages from 
debian unstable/experimental. Please tell if there is anything I can do 
to improve on this.

It'd be great to get this driver closer to vesa performance, for
vesa doesn't handle dual screens. You probably have higher goals than 
that. :-)

navit profile data:
http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport
http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport-l
http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport--callgraph

lyx profile data:
http://www.aitel.hist.no/~helgehaf/oprofile/lyx16/opreport
http://www.aitel.hist.no/~helgehaf/oprofile/lyx16/opreport-1

Helge Hafting

Re: nouveau slower than nv and vesa on quadro 135M

[Maarten Maathuis]

On Mon, Sep 15, 2008 at 1:12 PM, Helge Hafting
<helge.hafting-i5bjtSbraLbLX0NG8FE4ug@public.gmane.org> wrote:
> Maarten Maathuis wrote:
>
>> A profile of running this application would be useful (with nouveau
>> and xorg symbols). I have some suspicions as to the cause,
>> but some facts would be nice to have. Either oprofile or sysprof will
>> do, for oprofile we have a wiki page:
>> http://nouveau.freedesktop.org/wiki/OProfile
>>
> That wiki page doesn't list the first necessary step,
> which is "opcontrol --init". Adding that might be useful for newbies.
>
> I profiled two apps that are too slow with this driver.
> * navit (map navigation), slowly panning the map across a city. This
>  panning redraws the map each time, which is instantaneous with the
>  vesa driver.
>
> * lyx (word processor), typing text into a table. The pc could not
>  keep up with keyboard autorepeat, giving me one to three characters
>  per second. Each keypress redraws the table lines and the text
>  in the table cell.
>
> I am not sure if I have all the symbols needed. I used nouveau compiled
> per the instructions for debian. The X server consist of packages from
> debian unstable/experimental. Please tell if there is anything I can do to
> improve on this.
>
> It'd be great to get this driver closer to vesa performance, for
> vesa doesn't handle dual screens. You probably have higher goals than that.
> :-)
>
> navit profile data:
> http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport
> http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport-l
> http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport--callgraph
>
> lyx profile data:
> http://www.aitel.hist.no/~helgehaf/oprofile/lyx16/opreport
> http://www.aitel.hist.no/~helgehaf/oprofile/lyx16/opreport-1
>
> Helge Hafting
>

While the traces lack a lot of symbols (xserver's and pixman), i do
have a hunch as to the cause of the problem.

Could you add to your device section:

Option "EXAOptimizeMigration" "1"

This option seems to default to off for 1.5 (while it's on by default
for post-1.5).

If this doesn't help, then you need to get symbols for the xserver and
libpixman.

Maarten.

Re: nouveau slower than nv and vesa on quadro 135M

[Helge Hafting]

Maarten Maathuis wrote:
> On Mon, Sep 15, 2008 at 1:12 PM, Helge Hafting
> <helge.hafting-i5bjtSbraLbLX0NG8FE4ug@public.gmane.org> wrote:
>> Maarten Maathuis wrote:
>>
>>> A profile of running this application would be useful (with nouveau
>>> and xorg symbols). I have some suspicions as to the cause,
>>> but some facts would be nice to have. Either oprofile or sysprof will
>>> do, for oprofile we have a wiki page:
>>> http://nouveau.freedesktop.org/wiki/OProfile
>>>
>> That wiki page doesn't list the first necessary step,
>> which is "opcontrol --init". Adding that might be useful for newbies.
>>
>> I profiled two apps that are too slow with this driver.
>> * navit (map navigation), slowly panning the map across a city. This
>>  panning redraws the map each time, which is instantaneous with the
>>  vesa driver.
>>
>> * lyx (word processor), typing text into a table. The pc could not
>>  keep up with keyboard autorepeat, giving me one to three characters
>>  per second. Each keypress redraws the table lines and the text
>>  in the table cell.
>>
>> I am not sure if I have all the symbols needed. I used nouveau compiled
>> per the instructions for debian. The X server consist of packages from
>> debian unstable/experimental. Please tell if there is anything I can do to
>> improve on this.
>>
>> It'd be great to get this driver closer to vesa performance, for
>> vesa doesn't handle dual screens. You probably have higher goals than that.
>> :-)
>>
>> navit profile data:
>> http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport
>> http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport-l
>> http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport--callgraph
>>
>> lyx profile data:
>> http://www.aitel.hist.no/~helgehaf/oprofile/lyx16/opreport
>> http://www.aitel.hist.no/~helgehaf/oprofile/lyx16/opreport-1
>>
>> Helge Hafting
>>
> 
> While the traces lack a lot of symbols (xserver's and pixman), i do
> have a hunch as to the cause of the problem.
> 
> Could you add to your device section:
> 
> Option "EXAOptimizeMigration" "1"
> 
> This option seems to default to off for 1.5 (while it's on by default
> for post-1.5).
> 
> If this doesn't help, then you need to get symbols for the xserver and
> libpixman.

I added that option, and it did not help.
So I installed debug packages for xserver-xorg-core and libpixman. Here
are the new results:

navit profile data:
http://www.aitel.hist.no/~helgehaf/oprofile/navit2/opreport
http://www.aitel.hist.no/~helgehaf/oprofile/navit2/opreport
http://www.aitel.hist.no/~helgehaf/oprofile/navit2/opreport

LyX profile data:
http://www.aitel.hist.no/~helgehaf/oprofile/lyx2/opreport
http://www.aitel.hist.no/~helgehaf/oprofile/lyx2/opreport-l
(No --callgraph, error msg. about an invalid filename.)

Helge Hafting

Re: nouveau slower than nv and vesa on quadro 135M

[Maarten Maathuis]

On Mon, Sep 15, 2008 at 2:04 PM, Helge Hafting
<helge.hafting-i5bjtSbraLbLX0NG8FE4ug@public.gmane.org> wrote:
> Maarten Maathuis wrote:
>>
>> On Mon, Sep 15, 2008 at 1:12 PM, Helge Hafting
>> <helge.hafting-i5bjtSbraLbLX0NG8FE4ug@public.gmane.org> wrote:
>>>
>>> Maarten Maathuis wrote:
>>>
>>>> A profile of running this application would be useful (with nouveau
>>>> and xorg symbols). I have some suspicions as to the cause,
>>>> but some facts would be nice to have. Either oprofile or sysprof will
>>>> do, for oprofile we have a wiki page:
>>>> http://nouveau.freedesktop.org/wiki/OProfile
>>>>
>>> That wiki page doesn't list the first necessary step,
>>> which is "opcontrol --init". Adding that might be useful for newbies.
>>>
>>> I profiled two apps that are too slow with this driver.
>>> * navit (map navigation), slowly panning the map across a city. This
>>>  panning redraws the map each time, which is instantaneous with the
>>>  vesa driver.
>>>
>>> * lyx (word processor), typing text into a table. The pc could not
>>>  keep up with keyboard autorepeat, giving me one to three characters
>>>  per second. Each keypress redraws the table lines and the text
>>>  in the table cell.
>>>
>>> I am not sure if I have all the symbols needed. I used nouveau compiled
>>> per the instructions for debian. The X server consist of packages from
>>> debian unstable/experimental. Please tell if there is anything I can do
>>> to
>>> improve on this.
>>>
>>> It'd be great to get this driver closer to vesa performance, for
>>> vesa doesn't handle dual screens. You probably have higher goals than
>>> that.
>>> :-)
>>>
>>> navit profile data:
>>> http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport
>>> http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport-l
>>> http://www.aitel.hist.no/~helgehaf/oprofile/navit/opreport--callgraph
>>>
>>> lyx profile data:
>>> http://www.aitel.hist.no/~helgehaf/oprofile/lyx16/opreport
>>> http://www.aitel.hist.no/~helgehaf/oprofile/lyx16/opreport-1
>>>
>>> Helge Hafting
>>>
>>
>> While the traces lack a lot of symbols (xserver's and pixman), i do
>> have a hunch as to the cause of the problem.
>>
>> Could you add to your device section:
>>
>> Option "EXAOptimizeMigration" "1"
>>
>> This option seems to default to off for 1.5 (while it's on by default
>> for post-1.5).
>>
>> If this doesn't help, then you need to get symbols for the xserver and
>> libpixman.
>
> I added that option, and it did not help.
> So I installed debug packages for xserver-xorg-core and libpixman. Here
> are the new results:
>
> navit profile data:
> http://www.aitel.hist.no/~helgehaf/oprofile/navit2/opreport
> http://www.aitel.hist.no/~helgehaf/oprofile/navit2/opreport
> http://www.aitel.hist.no/~helgehaf/oprofile/navit2/opreport
>
> LyX profile data:
> http://www.aitel.hist.no/~helgehaf/oprofile/lyx2/opreport
> http://www.aitel.hist.no/~helgehaf/oprofile/lyx2/opreport-l
> (No --callgraph, error msg. about an invalid filename.)
>
> Helge Hafting
>

The 1st and the 2nd problem are different. Let's focus on the first initially.

I think for a callgraph you need to specify a depth, --callgraph=5 for
example, please experiment with that to see if you can actually see
who is calling those pixman functions (for the navit case). Currently
it just points to itself which is a (rather poor) way of showing that
it doesn't know.

If you could attach an xorg log, that would allow me to check if
things are as i expect them to be.

Maarten.

Re: nouveau slower than nv and vesa on quadro 135M

[Helge Hafting]

Maarten Maathuis wrote:

> The 1st and the 2nd problem are different. Let's focus on the first initially.
> 
ok.
> I think for a callgraph you need to specify a depth, --callgraph=5 for
> example, please experiment with that to see if you can actually see
> who is calling those pixman functions (for the navit case). Currently
> it just points to itself which is a (rather poor) way of showing that
> it doesn't know.
> 
I have no luck with this. I started out with --callgraph=6, like the 
example in the wiki.  I tried increasing to 10 and then to 16, that 
didn't seem to help.  There is very little documentation for this 
option, such as what numbers are supported.
I tried --callgraph=25, and then opreport -c gave me error messages only.

> If you could attach an xorg log, that would allow me to check if
> things are as i expect them to be.

Here are files from my attempts with --callgraph=16
http://www.aitel.hist.no/~helgehaf/oprofile/navit5/opreport-c
http://www.aitel.hist.no/~helgehaf/oprofile/navit5/opreport-l
http://www.aitel.hist.no/~helgehaf/oprofile/navit5/Xorg.0.log

Many calls is not unexpected. A city map has lots of roads, divided into
hundreds and hundreds of straight line segments. These are typically 
painted twice with slightly different width, so as to get a road with 
edges. There are also a lot of filled polygons (buildings, parks, river,...)

Painting a big map quickly is sometimes too much for weak processors 
like a phone with gps. It is normally not a problem for a PC, even
with unaccelerated framebuffer graphics.

Helge Hafting