RFC: Removal of some mutexes from the radeon driver
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
>>> and so are something very experimental. The first three just move what I
>>> to be still critical into the protection of the ring mutex, and the other
>>> actually remove the mutexs.
>>> Interestingly it still survives a couple of hours running the following
>>> while true
>>> for (( x = 10, y = 45, i = 0; $i< 144; i = $i + 1 ))
>>> glxgears -geometry 100x100+$x+$y> /dev/null 2>&1&
>>> x=$(expr $x + 120)
>>> if [ $x -gt 1920 ]
>>> y=$(expr $y + 110)
>>> sleep 30
>>> killall glxgears
>>> So the mutexes doesn't seem to protected something so critical and I'm
>>> wondering why we still have them so widely locked.
>>> 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.
The first 3 looks good, i need to test and read more carefully the cs
-> vm mutex one but it looks good too.
More information about the dri-devel