From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?ISO-8859-1?Q?Christian_K=F6nig?= <deathsimple@vodafone.de>
Subject: Re: RFC: Removal of some mutexes from the radeon driver
Date: Fri, 11 May 2012 13:54:33 +0200
Message-ID: <4FACFDF9.3050008@vodafone.de>
References: <1336731029-30365-1-git-send-email-deathsimple@vodafone.de>
	<CAPM=9tzCmpYUPdXOKRhgkQzyiZ2vcr3HUqCKjA_H6Tuk4KzZ9A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Content-Transfer-Encoding: quoted-printable
Return-path: <dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org>
Received: from outgoing.email.vodafone.de (outgoing.email.vodafone.de
	[139.7.28.128])
	by gabe.freedesktop.org (Postfix) with ESMTP id C361D9E95F
	for <dri-devel@lists.freedesktop.org>;
	Fri, 11 May 2012 04:54:37 -0700 (PDT)
In-Reply-To: <CAPM=9tzCmpYUPdXOKRhgkQzyiZ2vcr3HUqCKjA_H6Tuk4KzZ9A@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: Dave Airlie <airlied@gmail.com>
Cc: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org

On 11.05.2012 12:12, Dave Airlie wrote:
> On Fri, May 11, 2012 at 11:10 AM, Christian K=F6nig
> <deathsimple@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 othe=
r two
>> actually remove the mutexs.
>>
>> Interestingly it still survives a couple of hours running the following =
script:
>>
>> while true
>> do
>>         for (( x =3D 10, y =3D 45, i =3D 0; $i<  144; i =3D $i + 1 ))
>>         do
>>                 glxgears -geometry 100x100+$x+$y>  /dev/null 2>&1&
>>                 x=3D$(expr $x + 120)
>>                 if [ $x -gt 1920 ]
>>                 then
>>                         x=3D10
>>                         y=3D$(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.