From: "Christian König" <deathsimple@vodafone.de>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: Re: Include request for reset-rework branch v3
Date: Wed, 02 May 2012 11:04:21 +0200 [thread overview]
Message-ID: <4FA0F895.80701@vodafone.de> (raw)
In-Reply-To: <CAH3drwYUKPrSxcThLtCpS4+zG9MJhj5R4+GgqcZMhr56N=P6=A@mail.gmail.com>
On 02.05.2012 06:04, Jerome Glisse wrote:
> On Wed, May 2, 2012 at 12:00 AM,<j.glisse@gmail.com> wrote:
>> Ok so i reread stuff and the :
>> drm/radeon: add general purpose fence signaled callback
>> is a big NAK actually. It change the paradigm. Moving most of
>> the handling into the irq process which is something i am intimatly
>> convinced we should avoid.
>>
>> Here is the patchset up to ib pool cleanup. I have yet rebase the
>> other patches as i am tracking done some issue in the sa allocation.
>>
>> Cheers,
>> Jerome
>>
> Before i forget, the big issue with doing work from irq handler is that
> we never know in middle of what other part can be. I believe it's lot
> better to have irq process only update fence (signaled/not signaled).
> and have the actual work happening on behalf of the process wether
> through sa alloc path or ttm path.
Disagree.
Why should it be better to delay work outside of the interrupt context
if proper locking can make the driver much more responsive and easier to
implement?
I don't want to call into TTM or stuff like that, just want make it
possible to release the resources acquired for a job immediately after
the job is completed instead of waiting for the next allocation to
happen. Cause then you don't need to check if a bunch of fences might
possible be signaled and instead just get a proper signal that resources
can be deallocated.
Also if you really want to keep the irq context out of the drivers upper
layers, it should be quite easy to modify the code so that the callback
won't happen from there.
Christian.
next prev parent reply other threads:[~2012-05-02 9:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 4:00 Include request for reset-rework branch v3 j.glisse
2012-05-02 4:00 ` [PATCH 01/13] drm/radeon: make radeon_gpu_is_lockup a per ring function j.glisse
2012-05-02 4:00 ` [PATCH 02/13] drm/radeon: replace gpu_lockup with ring->ready flag j.glisse
2012-05-02 4:00 ` [PATCH 03/13] drm/radeon: register ring debugfs handlers on init j.glisse
2012-05-02 4:00 ` [PATCH 04/13] drm/radeon: use central function for IB testing j.glisse
2012-05-02 4:00 ` [PATCH 05/13] drm/radeon: rework gpu lockup detection and processing j.glisse
2012-05-02 4:00 ` [PATCH 06/13] drm/radeon: fix a bug in the SA code j.glisse
2012-05-02 4:00 ` [PATCH 07/13] drm/radeon: add proper locking to the SA j.glisse
2012-05-02 4:00 ` [PATCH 08/13] drm/radeon: add sub allocator debugfs file j.glisse
2012-05-02 4:00 ` [PATCH 09/13] drm/radeon: improve sa allocator v2 j.glisse
2012-05-02 4:00 ` [PATCH 10/13] drm/radeon: return -ENOENT in fence_wait_next v2 j.glisse
2012-05-02 4:00 ` [PATCH 11/13] drm/radeon: rename fence_wait_last to fence_wait_empty j.glisse
2012-05-02 4:00 ` [PATCH 12/13] drm/radeon: don't keep list of created fences j.glisse
2012-05-02 4:00 ` [PATCH 13/13] drm/radeon: add fence and retry to sa allocator v2 j.glisse
2012-05-02 4:04 ` Include request for reset-rework branch v3 Jerome Glisse
2012-05-02 9:04 ` Christian König [this message]
2012-05-02 10:32 ` Dave Airlie
2012-05-02 11:25 ` Christian König
2012-05-02 14:07 ` Jerome Glisse
2012-05-02 16:26 ` Alex Deucher
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=4FA0F895.80701@vodafone.de \
--to=deathsimple@vodafone.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=j.glisse@gmail.com \
/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.