From: "Christian König" <deathsimple@vodafone.de>
To: Dave Airlie <airlied@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: RFC: Removal of some mutexes from the radeon driver
Date: Fri, 11 May 2012 13:54:33 +0200 [thread overview]
Message-ID: <4FACFDF9.3050008@vodafone.de> (raw)
In-Reply-To: <CAPM=9tzCmpYUPdXOKRhgkQzyiZ2vcr3HUqCKjA_H6Tuk4KzZ9A@mail.gmail.com>
On 11.05.2012 12:12, Dave Airlie wrote:
> On Fri, May 11, 2012 at 11:10 AM, Christian König
> <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 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.
next prev parent reply other threads:[~2012-05-11 11:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-11 10:10 RFC: Removal of some mutexes from the radeon driver Christian König
2012-05-11 10:10 ` [PATCH 1/5] drm/radeon: remove radeon_fence_create Christian König
2012-05-11 10:10 ` [PATCH 2/5] drm/radeon: add infrastructure for advanced ring synchronization Christian König
2012-05-11 10:10 ` [PATCH 3/5] drm/radeon: rework ring syncing code Christian König
2012-05-11 10:10 ` [PATCH 4/5] drm/radeon: WIP remove cs_mutex Christian König
2012-05-11 10:10 ` [PATCH 5/5] drm/radeon: WIP remove vmram_mutex Christian König
2012-05-11 14:41 ` Jerome Glisse
2012-05-11 14:44 ` Jerome Glisse
2012-05-11 15:12 ` Christian König
2012-05-11 10:12 ` RFC: Removal of some mutexes from the radeon driver Dave Airlie
2012-05-11 11:54 ` Christian König [this message]
2012-05-14 15:14 ` Jerome Glisse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FACFDF9.3050008@vodafone.de \
--to=deathsimple@vodafone.de \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.