[mythtv-users] Help debugging XvMC freezes

[Scott D. Davilla]

>Scott D. Davilla wrote:
>>>  Hmmm, interesting thought!  I tried underclocking it from 450 MHz to
>>>  400 MHz, but got another freeze not too far in.  So I'm tending to
>>>  think this is a nvidia driver issue.  (happy happy joy joy...   why
>>>  did I buy this card again?)
>>>
>>>  Actually, second thought...  did you underclock the GPU, or the
>>>  memory? I've been focusing on the GPU, maybe I should underclock the
>>>  graphics card's memory?
>>>
>>>  I'll have to do some more playing around, see if I hit pay dirt with
>>>  anything.
>>
>  > I went from 360Mhz on the GPU to 200MHz, and to compensate a little
>>  also when from 720MHz on VRAM to 800MHz. This drastic decrease in GPU
>>  clock did not effect XvMC very much. My testing show it was more
>>  sensitive to VRAM clock than GPU clock. At it is, this setting added
>>  5 percent or less to the CPU when doing XvMC decode of 1080i mpeg2.
>>  So in addition to solving the hang/video glitch I has quite happy
>>  that I still had the ponies to do 1080i mpeg2 decode.
>
>Well, I did some playing...  I clocked the GPU back from 450 to 300 MHz, and
>the GPU RAM from 650 down to 500 MHz.  Then I made a playlist of about 90
>minutes of 1080i material (far longer than I've ever gone before XvMC would
>die)....
>
>Success!  Interestingly the GPU core temp rose from 55 to 59C...  maybe I
>just wasn't successfully running XvMC long enough before to get it to raise
>temperature.
>
>I'm going to try the same test with the GPU at 400 MHz and the memory still
>at 500 MHz.  If the video still holds steady, then I'll see if the stock GPU
>speed (450) but reduced memory speed (650 -> 500) does the trick.  Then I'll
>queue up 12 hours of 1080i mpeg2 and give it a good long pounding.  (oo,
>that sounds dirty.)
>
>>  make sure the under-clock was taken
>>
>>  nvidia-settings -q all
>>
>>  should show the new setting.
>
>That's what's weird.  I'm using nvclock to set/query the video board, and it
>seems to work correctly.  It reports the amount of ram on board correctly,
>what chipset is running, bios info, stock clocks, current clocks, and
>basically does everything *right*.
>
>nvidia-settings -q all, by way of comparison, does not!  nvidia-settings
>*insists* that the board has 512MB of ram on board (it has 128), for
>example.  If I set the GPU or memory clocks with nvclock and re-run
>nvidia-settings, it doesn't report a change.  But there most definitely *is*
>a change, because I've never been able to run XvMC more than a few minutes
>without it locking up on the standard clocks, much less for 90 minutes
>straight!
>
>nvclock does say that it's using 'low level nv4 settings' voodoo, so maybe
>that's where the discrepency comes in.  Food for thought, at any rate.
>
>
>On a nice point, now that XvMC is working, when decoding 1080i content the
>cpu is sitting at 92% idle according to top!  Maybe it's time to turn
>speedstep back on & save a few watts?  :)
>

One can use nvclock (the recent version) to control the clock. In my 
case nvclock caused a big video upset when the gpu clock was diddled, 
so I used  nvidia-settings because I figured surely nvidia knows what 
they are doing;)

Also with nvidia-settings you need the magic

options "Coolbits" "1" in xorg.conf or it will ignore changes.

Glad this worked out, it took me months to find it under the AppleTV.

I'll bet $1 that VARM clock does not matter and GPU clock does;)

I ran continuous 1080i LiveTV display for three days before I 
confident it was fixed.