On 11.05.2012 12:12, Dave Airlie wrote: > On Fri, May 11, 2012 at 11:10 AM, Christian K?nig > <deathsimple at vodafone.de> wrote: >> Hi everybody, >> >> well the following patches remove the cs and vram mutex from the radeon >> driver >> and so are something very experimental. The first three just move what I know >> to be still critical into the protection of the ring mutex, and the other two >> actually remove the mutexs. >> >> Interestingly it still survives a couple of hours running the following >> script: >> >> while true >> do >> for (( x = 10, y = 45, i = 0; $i< 144; i = $i + 1 )) >> do >> glxgears -geometry 100x100+$x+$y> /dev/null 2>&1& >> x=$(expr $x + 120) >> if [ $x -gt 1920 ] >> then >> x=10 >> y=$(expr $y + 110) >> fi >> done >> >> sleep 30 >> >> killall glxgears >> done >> >> So the mutexes doesn't seem to protected something so critical and I'm >> wondering why we still have them so widely locked. >> >> Cheers, >> Christian. >> >> PS: I'm away for the next week or so don't expect any response soon. > The vram mutex is to block access to the VRAM during reclocking. > > So if you reclocks a lot while running stuff you might notice.
Ah, thx for that info it suddenly starts to make sense. Also not using an APU for testing might also help triggering the problem, but in turn that means we can avoid taking that lock on APUs. Cheers, Christian.
