256.29: Jerky VDPAU HD playback in MythTV

[mlord]

Driver betas 256.29 and 256.25 both exhibit jerky playback of 1080i ATSC streams in MythTV here. This is with a fanless GT-240 card that plays the exact same clips smoothly with 195.36.24. 64-bit all around.

It could be an issue with excessive use of the CPU (not GPU), as we've noticed it while MythTV is simultaneously recording HD while playing back HD. It seems less noticeable when only playback is active.

FWIW, 256.29 is slightly better than 256.25, but neither is great.

Back to 195.36.24 again for now.

[piotro]

Hi,

Just my feedback:

256.25 for me is working not worse than 195.36.24 So:

-playback of SD, HD1080p, HD1080i is popper (no any issues encountered since 2 weeks of 256.25 usage on 3 production systems)

-issue with hard freeze Myth on MythNews is still present.

-With 256.25 I have occasionally (once per 10-20 resumes) long resume from S3 (20+ sec when kernel seems to be fully running, but screen is black. After that screen apears and system is working OK)

-256.29 not tested Yet

My sys is: minimyth derivate, Myth 0-23-fixes 24609, 2.6.33.4.

br

[Stephen Warren]

mlord, can you please check the PowerMizer page of nvidia-settings, and see if there's a difference in which PowerMizer level is selected between the good and bad drivers. Thanks.

[mlord]

Originally Posted by Stephen Warren

mlord, can you .. see if there's a difference in which PowerMizer level is selected

Both versions use "adaptive control", and both switch into high-gear for playback, and stay there. So that part is working well, thanks.

But I have another idea: There's an app (which I wrote) managing the VFD display in my Antec case, and it normally queries/displays the GPU temperature every 5-10 seconds and displays it. Here's the query command it uses:

nvidia-settings -q :0.0/GPUCoreTemp

That command seems to take between 130 and 180 milliseconds to invoke/complete each time, and once in a while (every minute or so) this appears to cause a jerkiness in playback with the 256.2x beta drivers, but not with the earlier 195.xx drivers.

Removing the temperature polling seems to smooth things out here with 256.2x, so that's what I've now done.

I wonder if temperature query from commandline (as per above) grabs a mutex or something inside the driver, and holds it a tad long? Or perhaps creates a priority-inversion situation when pre-empted by the mythtv vdpau playback code?

Cheers

[Stephen Warren]

Thanks for isolating that. I can imagine the temperature polling might cause issues. I'll file a bug and see what the relevant people say.

[Stephen Warren]

mlord, I couldn't reproduce this locally. Are you sure it's the nvidia-settings command that's actually causing the issue, not e.g. sending commands to the VFD display with the result, or some other facet or processing the nvidia-settings results?

[mlord]

Originally Posted by Stephen Warren

mlord, I couldn't reproduce this locally. Are you sure it's the nvidia-settings command that's actually causing the issue, not e.g. sending commands to the VFD display with the result, or some other facet or processing the nvidia-settings results?

The app still does all of that other stuff, and no issues result from it. Only when adding the temperature query back in do I see the odd playback glitch. But even more obviously, the VFD's (software-driven) scrolling display is incredibly jerky with the temperature probing, and smooth as silk without it.. That was the first clue to the problem.

The system was also running all of mythfrontend's threads with realtime priorities, which is why I suspect some kind of priority inversion may have been happening. That's not normal for Mythtv -- it usually runs everything in SCHED_OTHER/NORMAL, rather than in realtime SCHED_FIFO. Which could explain difficulty in reproducing it.

Since then, I've fixed the priorities here, so that only a single playback thread in mythfrontend uses SCHED_FIFO now. This might cure the playback w/temperature thingie, though I have not reenabled it yet for retest. The next good opportunity for that is Wednesday evening, during the hockey game (lots of fast motion and high contrast makes any kind of jerkiness obvious).

I'm _very_ happy with 256.29 right now (without the temperature probing).

Good work, guys!

[Stephen Warren]

mlord, could you supply an nvidia-bug-report so that we an try and match your HW configuration more exactly. Thanks.

[mlord]

I'm not sure you'll be able to match it. But I will see if I can figure out the "official" bug-report mechanism.

The hockey game has looked good thus far tonight (now headed for overtime), with the temperature sampling turned off.

This is with everything at normal scheduling priority, except for the one Mythfrontend thread that runs at realtime priority "1".

Mythbackend is recording the game, plus another SD analog show (PVR-250 card, 720x480), and running two commflag jobs, all at the same time that I'm watching the game about half an hour behind real-time.

When I leave all-else alone, and re-enable the temperature probing, I see a glitch every couple of minutes or so.

As a result, I've disabled the probing again. I don't mind that, as it was only needed when I first set up the video card (fanless GT240), so I could ensure it wasn't getting too hot. Mostly the card seems to be in the 56-60C range for temperature.

Cheers

[mlord]

nvidia-bug-report.log.gz attached.

Running latest mythtv-0.23-fixes from svn, built from source locally on the same machine. Base system underneath originally came from Mythbuntu-Intrepid, but a few packages have been upgraded since then.

The USB display app, which used to query the GPU temperature, is available from my web site at http://rtr.ca/vfd_updater/ The temperature probe can be re-enabled by an "#if 1" on line 846 of vfd_updater.c

Cheers

[mlord]

Mmm.. I wonder if the odd glitch with this could be resulting from nvidia-settings experiencing a page-fault while holding a mutex in the userspace portion of the driver?

Or are things clever enough to mlock() all code blocks that might acquire global mutexes?

Along those lines, I may see if I can set up a tmpfs to hold nvidia-settings and everything it uses (libs), thereby locking it all into RAM. If this eliminates the glitches, then disk-based page faults become the prime suspect for glitching in normal usage.

With MythTV as active as it is w.r.t. the disks, there's a reasonably high likelihood that idle pages are being agressively evicted from the page-cache (aka. "RAM"), and that nvidia-settings is partially paged back in each time it is invoked (every three seconds or so by the vfd app).

I'll give this theory a trial on the weekend.

[mlord]

Originally Posted by mlord

may see if I can set up a tmpfs to hold nvidia-settings and everything it uses (libs), thereby locking it all into RAM.

I did this today (with ramfs rather than tmpfs) while watching parts of Brasil vs. Nigeria, but it did not help. Turning on the temperature probing caused immediate jerkiness, turning it off again smoothed everything out as normal.

Oh well. More of a curiosity than anything now, I suppose.

Mind you, I only put the direct dependencies (as listed by ldd) in the ramfs. If the program uses dlopen() to load additional libs, then those got missed, and could be the cause still.