RFC: Removal of some mutexes from the radeon driver

Jerome Glisse j.glisse at gmail.com
Mon May 14 08:14:34 PDT 2012


On Fri, May 11, 2012 at 7:54 AM, Christian König
<deathsimple at vodafone.de> wrote:
> 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.
>

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


More information about the dri-devel mailing list