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.
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?
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.
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
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.