All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.