Nouveau - Jun 2008 - [Bug 16375] New: Xv frame rate > refresh rate causes 100% CPU usage

http://bugs.freedesktop.org/show_bug.cgi?id=16375

           Summary: Xv frame rate > refresh rate causes 100% CPU usage
           Product: xorg
           Version: git
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
        AssignedTo: nouveau at lists.freedesktop.org
        ReportedBy: drzeus-bugzilla at drzeus.cx
         QAContact: xorg-team at lists.x.org


This bug is about the issue where playing some videos causes X to eat 100% CPU
for no apparent reason. It was known early that the cause was nouveau spinning
on DMA notifiers, but it wasn't really known why. After an evening of
debugging, I was able to explore the problem.

The issue occurs when PutImage() is called at a faster rate than images are
transferred by the hardware. I.e. you get a backlog of frames you want to DMA.
So the driver is doing exactly what it was supposed to do, it waits for a DMA
notifier to become available.

Now the bad assumption here was that waiting for a DMA notifier was a rare
occurance. Unfortunately it can be provoked under quite normal circumstances:

1. Input video is a NTSC video at 30 FPS

2. Monitor is running at 60 Hz

3. The video is interlaced, and the deinterlacer is one that outputs an image
each field, not each frame, effectively doubling the frame rate.

4. The driver is waiting for vsync between each frame to avoid tearing.

The result is a Xv stream at 60 Hz, which has very good odds of drowning the
(vsync-locked) DMA engine.

So you can't really solve the basic problem of the player wanting to output
frames faster than is possible (again, because of the vsync restriction). What
can be done is to make sure that waiting for a DMA notifier is done without
hogging the CPU.

For comparison, the radeon engine seems to do a blocking DRM call as its means
of throttling. The driver uses a different design, but from what I can tell the
throttling point is where it allocates FIFO space for the Xv image.



Related to this issue is the fact that you can get incorrect frame orders on
screen (the output tends to flicker a bit). This is an inherent effect of the
racy design of libXv (and possibly the Xv protocol itself). When using
XvShmPutImage(), there is no notifier that the server has had time to process
the image. If it takes to long, your player will start overwriting the buffer
with the next frame. With double buffring players (like mplayer), this will in
most cases have the effect of frames getting displayed in the wrong order.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=16375





--- Comment #1 from Arthur Huillet <arthur.huillet at free.Fr>  2008-06-16
04:31:58 PST ---
Since this person forgot to mention it (I'm wondering why this deliberate
lack
of precision), this concerns the blitter and texture adapter. There are reasons
to believe the overlay does not have this problem, though nothing was proven at
this point.

Some design changes may be necessary to fix this, I'm leaving it to anybody
interested because I have not investigated the issue and do not intend to.

The suggestion of adding a sleep in notifier waits does not fix this problem
but a very partly related issue (eating CPU when waiting), and has already been
discussed in the past and considered incorrect due to insufficient precision of
the wait (and maybe other things, I happen not to remember).

Thanks for the comment at the end which - despite being only partly related
again - explains the strange behavior all of us have observed on all adapters
whenever the card was really too slow. Is there a possible fix here?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=16375





--- Comment #2 from Pierre Ossman <drzeus-bugzilla at drzeus.cx> 
2008-06-16 05:23:52 PST ---
Right, sorry. I live in my own little world where I don't have any overlay
support. :)

Sleeping is probably incorrect, yes. But a blocking DRM call might be the best
long term solution. The kernel could use interrupts instead of polling the
notifier.


As for Xv, that could always be fixed with a new protocol revision. It might be
fixable just be modifying libXv, but looking at the protocol spec, I don't
think that's possible.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=16375

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Ilia Mirkin <imirkin at alum.mit.edu> ---
It appears that this bug report has laid dormant for quite a while. Sorry we
haven't gotten to it. Since we fix bugs all the time, chances are pretty
good
that your issue has been fixed with the latest software. Please give it a shot.
(Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git
versions.) If upgrading to the latest isn't an option for you, your
distro's
bugzilla is probably the right destination for your bug report.

In an effort to clean up our bug list, we're pre-emptively closing all bugs
that haven't seen updates since 2011. If the original issue remains, please
make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/
for what we need to see, and re-open this one.

Thanks,

The Nouveau Team

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130818/a409081f/attachment-0001.html>