Bug 36090 - [NV34] [NV49] terminal's visual bell is very slow with nouveau
Summary: [NV34] [NV49] terminal's visual bell is very slow with nouveau
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-08 16:26 UTC by Harald Judt
Modified: 2019-12-04 08:25 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Harald Judt 2011-04-08 16:26:25 UTC
In xterm or mlterm, the visual bell is very slow. In mlterm, you can sometimes see the lines drawing, in xterm it is not always visible. In both cases, the visual bell blocks the terminal for approximately 3 seconds. Any keyboard input during that time will still be remembered, though.

This is specific to the nouveau driver and does not occur with radeon etc.

linux-2.6.38.

lspci -vvv -s 01:00.0:
----------------------------------------------------------------------------
01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7800 GS] (rev a2) (prog-if 00 [VGA controller])
        Subsystem: nVidia Corporation Device 037c
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at e8000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Region 2: Memory at e9000000 (32-bit, non-prefetchable) [size=16M]
        [virtual] Expansion ROM at ea000000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [44] AGP version 3.0
                Status: RQ=256 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
                Command: RQ=32 ArqSz=2 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x8
        Kernel driver in use: nouveau
----------------------------------------------------------------------------


nvclock -i:
----------------------------------------------------------------------------
Xlib:  extension "NV-CONTROL" missing on display ":0.0".
-- General info --
Card:           nVidia Geforce 7800GS
Architecture:   NV49/G71 A2
PCI id:         0xf5
GPU clock:      275.000 MHz
Bustype:        AGP (BR02)

-- Pipeline info --
Pixel units: 4x4 (010111b)
Vertex units: 6x1 (00111111b)
HW masked units: pixel 100011b vertex 00000000b
SW masked units: pixel 101000b vertex 11000000b

-- Memory info --
Amount:         256 MB
Type:           256 bit DDR3
Clock:          599.400 MHz

-- Sensor info --
Sensor: National Semiconductor LM99
Board temperature: 33C
GPU temperature: 46C

-- VideoBios information --
Version: 05.71.22.21.11
Signon message: GeForce 7800 GS AGP VGA BIOS
Performance level 0: gpu 275MHz/memory 600MHz/1.10V/50%
Performance level 1: gpu 375MHz/memory 600MHz/1.10V/55%
VID mask: 3
Voltage level 0: 1.05V, VID: 0
Voltage level 1: 1.10V, VID: 1
Voltage level 2: 1.20V, VID: 2
----------------------------------------------------------------------------
Comment 1 aebenjam 2012-01-30 08:34:15 UTC
Also experienced with:

01:00.0 VGA compatible controller: nVidia Corporation NV34GL [Quadro FX 500/600 PCI] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: nVidia Corporation Device 01ba
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Expansion ROM at fd000000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: nouveau
        Kernel modules: nouveau
Comment 2 Ilia Mirkin 2013-08-20 02:14:00 UTC
Could you retest with a newer kernel/DDX? This feels like the sort of thing that probably got fixed over the past couple of years.

Note to the NV49 user, there's currently a bug in 3.11-rcX that will cause nouveau to crash on start (for nv49 and nv4e). Either use 3.10, the nouveau/master tree, or cherry pick http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=42f186b6af54b82dcee926a35440b74dbabe1623 (this will hopefully make the final 3.11 release).
Comment 3 Harald Judt 2013-08-20 08:33:37 UTC
Thanks for your suggestion, but I can no longer call me owner of such a card and therefore am unable to test this.
Comment 4 Ilia Mirkin 2013-09-21 17:55:42 UTC
No response to retest request in a month. Closing as invalid.
Comment 5 aebenjam 2013-09-23 19:32:24 UTC
Problem still exists with:

# uname -a
Linux panda.opentext.com 3.10.12-100.fc18.i686 #1 SMP Mon Sep 16 13:25:43 UTC 2013 i686 i686 i386 GNU/Linux

VGA compatible controller: NVIDIA Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1) (prog-if 00 [VGA controller])

Let me know if you need more information.

Adam
Comment 6 Ilia Mirkin 2013-09-23 19:38:14 UTC
Are you on a recent version of the ddx? (xf86-video-nouveau) Also, what card do you have (G72M means nothing to me... what does nouveau say as the "Chipset" in dmesg)?
Comment 7 aebenjam 2013-09-23 19:55:54 UTC
I'm not sure how to answer your question about the ddx... is this what you mean?

rpm -qa |grep -i nouveau
xorg-x11-drv-nouveau-1.0.7-1.fc18.i686

Re: the card, dmidecode suggests it is:

Quadro NVS 110M

Let me know if you need more.

Thanks,

Adam
Comment 8 Ilia Mirkin 2013-09-23 20:08:37 UTC
dmesg | grep -i chipset

sounds like your ddx is new enough though.

Can you provide detailed repro steps? I'm not even sure how to enable visual bell.
Comment 9 aebenjam 2013-09-23 20:12:44 UTC
#dmesg | grep -i chipset
[    1.887251] nouveau  [  DEVICE][0000:01:00.0] Chipset: G72 (NV46)

Reproduction:

You can fire up an xterm with -vb to request the visual bell.  You can also use control + middle-mouse-button to bring up a menu which allows you to enable/disable the visual bell.

Let me know if you need more.

Thanks,

Adam
Comment 10 Ilia Mirkin 2013-09-24 02:53:17 UTC
Hmmm... FWIW I couldn't reproduce any oddness with a NV42 card, kernel 3.11, and xf86-video-nouveau 1.0.9 both with and without xcompmgr running. Without a compositor, it _is_ a bit on the slow side, but like a half-second, nothing like the 3s delay mentioned in the original description.

Anything else odd about your setup?
Comment 11 aebenjam 2013-09-24 15:44:55 UTC
Interesting.  So, I'm a Fedora (currently v18) user.  I created a stock account, logged in to a standard Gnome environment, and fired up an xterm with visual bell running, and it doesn't have the same problem.  In fact, I couldn't even SEE a visual bell. Odd.  All I could tell was that the audible bell went away when I enabled the visual bell.

Now, that's not my usual scenario. My usual is using fvwm2 as my window manager.  And while it might take a second or so for the visual bell to run on a reasonable sized xterm, when I full-screen it, it really does take multiple seconds to complete.  Running xcompmgr didn't speed that up, but instead of the bell visually progressing up/down the screeen (watching each line draw) it drew it all at once, then waited, then removed it all at once.  Same (or, at least, similar) delay, but visually different.

Note that whatever is going right/wrong didn't used to happen using the nvidia provided driver.  I've been using the nouveau driver, and am happy to do so, but it does have this one interesting downside.

Interesting fact.  If I run the program, "screen", it changes things somehow.  I'm not sure how... but all of a sudden the visual bell becomes reasonable again.  Exiting back out of screen reverts to the undesired behaviour.

I hope that helps.

Adam
Comment 12 Ilia Mirkin 2013-09-25 17:39:12 UTC
OK, by increasing the terminal size, I do indeed see that the visual bell is really rather slow. During that time, X is using up 100% CPU, so it's probably something highly unoptimal happening in the DDX.

It seems like almost all of that CPU time is going into fbSolid() from libfb, but sadly perf isn't telling me where it's getting called from for some reason. I'll try to look into it later, but wanted to record this observation in case I don't get to it.
Comment 13 Ilia Mirkin 2014-01-23 18:33:37 UTC
Looking into EXA a bit, there's a EXASolid impl shared by all pre-nv50 cards. One of the things it apparently doesn't handle are 32-bit visuals with solid draws that include a fancy "op", which I assume the visual bell would, like xor or whatever. I have a hard time believing this restriction holds, so I'm going to try removing it on some cards I have (at some point).

If you guys want to play around with it, I'm talking about the

		if (ppix->drawable.bitsPerPixel == 32)
			return FALSE;

in NV04EXASetROP. Something causing NV04EXAPrepareSolid to return false would definitely explain the fallback to fbSolid.
Comment 14 Martin Peres 2019-12-04 08:25:49 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/16.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.