From: Francisco Jerez <currojerez@gmail.com>
To: Thomas Hellstrom <thomas@shipmail.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: Nouveau fences?
Date: Sun, 28 Nov 2010 17:11:11 +0100 [thread overview]
Message-ID: <87y68dl97k.fsf@gmail.com> (raw)
In-Reply-To: <87k4jxmta8.fsf@riseup.net> (Francisco Jerez's message of "Sun, 28 Nov 2010 15:12:15 +0100")
[-- Attachment #1.1.1: Type: text/plain, Size: 1839 bytes --]
Francisco Jerez <currojerez@riseup.net> writes:
> Thomas Hellstrom <thomas@shipmail.org> writes:
>
>> Ben,
>>
>> I'm looking at a way to make TTM memory management asynchronous with
>> the CPU. The idea is that you should basically be able to DMA data to
>> and from memory regions without waiting for idle, as long as the GPU
>> has a means to provide operation ordering.
>>
> Sounds good. I guess you're mainly dealing with BO eviction
> synchronization? The only problem I see on our side is that calls to our
> move() hook aren't guaranteed to be carried out in order (because of the
> multiple hardware channels). I'm thinking that move() could be extended
> with an optional sync_obj argument, that way move() would be able to
> make sure that evictions are strictly ordered with respect to the fence
> specified.
>
>> While doing that I looked a bit at the Nouveau fencing. It appears
>> like waiting for fences is polling only (no irq to signal fences)? Is
>> that correct?
>>
> That's right, nvidia hardware has no nice way to schedule a fence-like
> interrupt we could selectively turn on and off around the sync_obj_wait
> hook. There's a bunch of (more or less) chipset-specific hacks that
> could be used to get an equivalent effect, but polling has seemed good
> enough so far (in the typical case we only take the "lazy" path so CPU
> usage is still OK).
>
> Unconditional PFIFO CACHE interrupts might be an option too, but, I'm a
> bit afraid of the PFIFO stalls and useless IRQ storms some applications
> could trigger.
>
Meh, apparently this one couldn't make it through, some spam filter has
decided I'm a spammer for some reason...
>> /Thomas
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[-- Attachment #1.2: Type: application/pgp-signature, Size: 229 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2010-11-28 16:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-28 12:39 Nouveau fences? Thomas Hellstrom
2010-11-28 14:12 ` Francisco Jerez
2010-11-28 16:11 ` Francisco Jerez [this message]
2010-11-28 20:37 ` Thomas Hellstrom
2010-11-28 21:55 ` Francisco Jerez
2010-11-29 7:28 ` Thomas Hellstrom
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=87y68dl97k.fsf@gmail.com \
--to=currojerez@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=thomas@shipmail.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.