On Fri, May 11, 2012 at 7:54 AM, Christian König <deathsimple@xxxxxxxxxxx> wrote: > On 11.05.2012 12:12, Dave Airlie wrote: >> >> On Fri, May 11, 2012 at 11:10 AM, Christian König >> <deathsimple@xxxxxxxxxxx> 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. > The first 3 looks good, i need to test and read more carefully the cs -> vm mutex one but it looks good too. Cheers, Jerome _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
