wgfx_stdu.c | 3 +++
> 6 files changed, 15 insertions(+), 9 deletions(-)
>
Acked-by: Thomas Hellstrom
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On 08/13/2018 02:28 PM, Thomas Zimmermann wrote:
Hi
Am 13.08.2018 um 12:33 schrieb Christian König:
Yes, please! I had it on my TODO list to clean that up for an eternity.
On top of these patches, I have a patch set that provides a single
init/release interface for TTM global data. I'll post i
So this is a typical case where a NO_WAIT can indeed become a WAIT
because of the use of a reservation instead of a spinlock.
(See the remove_fence_lock discussion)
/Thomas
On 10/12/2012 05:06 PM, Maarten Lankhorst wrote:
Apart from some code inside ttm itself and nouveau_bo_vma_del,
this is
I need to nak this in its current form.
The TTM design without timeout is intentional.
The fencing system (or the sync objects) is what should control the
progress of the GPU and if it detects a hang, all fences should be
signaled and the gpu should be reset if possible. Error propagation
coul
Arvind R wrote:
On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen wrote:
I'm adding dri-devel@ to CC, since this suggested patch touches
TTM code, and none of the Nouveau code. TTM patches go via
dri-de...@.
Thanks.
This is a NAK in its current form.
First, At mmap() time, the place
Jerome Glisse wrote:
> On Thu, Jan 21, 2010 at 01:59:26PM +0100, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> On Thu, Jan 21, 2010 at 04:49:39AM +0100, Luca Barbieri wrote:
>>>
>>>>> We had to do a similar thing in the
&
Luca Barbieri wrote:
>> At a first glance:
>>
>> 1) We probably *will* need a delayed destroyed workqueue to avoid wasting
>> memory that otherwise should be freed to the system. At the very least, the
>> delayed delete process should optionally be run by a system shrinker.
>>
> You are right.
Jerome Glisse wrote:
> On Thu, Jan 21, 2010 at 04:49:39AM +0100, Luca Barbieri wrote:
>
>>> We had to do a similar thing in the
>>> Poulsbo driver and it turned out that we could save a significant amount of
>>> CPU by using a delayed workqueue, collecting objects and destroying them
>>> periodi
Luca Barbieri wrote:
>> We had to do a similar thing in the
>> Poulsbo driver and it turned out that we could save a significant amount of
>> CPU by using a delayed workqueue, collecting objects and destroying them
>> periodically.
>>
> Yes, indeed, we don't really care about a fence expiring
Luca Barbieri wrote:
> When designing this, we should also keep in mind that some drivers
> (e.g. nouveau) have multiple FIFO channels, and thus we would like a
> buffer to be referenced for reading by multiple channels at once (and
> be destroyed only when all fences are expired, obviously).
> Als
Luca Barbieri wrote:
>> Also note that the delayed delete list is not in fence order but in
>> deletion-time order, which perhaps gives room for more optimizations.
>>
> You are right.
> I think then that ttm_bo_delayed_delete may still need to be changed,
> because it stops when ttm_bo_cleanu
Luca Barbieri wrote:
> Yes it's fine. I sent your patch to Dave with an expanded commit
> comment for merging.
>
> Here is a possible redesign of the mechanism inspired by this issue.
> It seems that what we are racing against is buffer eviction, due to
> delayed deletion buffers being still kept o
Thomas Hellstrom wrote:
Thomas Hellstrom wrote:
Yes, it looks correct. Although it seems a little unintuitive to enter
the loop with the spinlock held, and exit it with the spinlock not held.
I've attached yet another patch to have that fixed. Could you take a
look at whether it see
Thomas Hellstrom wrote:
Yes, it looks correct. Although it seems a little unintuitive to enter
the loop with the spinlock held, and exit it with the spinlock not held.
I've attached yet another patch to have that fixed. Could you take a
look at whether it seems OK with you and, in that
Luca Barbieri wrote:
>> Would nentry=list_first_entry(&entry->ddestroy, ) work?
>>
> Yes, it seems a bit less intuitive, but if that's the accepted
> practice, let's do that instead.
>
>
>> Here nentry may have been removed from the list by another process, which
>> would trigger the u
Luca,
Good catch.
Some comments inline:
Luca Barbieri wrote:
> + entry = list_first_entry(&bdev->ddestroy,
> + struct ttm_buffer_object, ddestroy);
> + kref_get(&entry->list_kref);
>
> - if (next != &bdev->ddestroy) {
> - nentry = list_entry
I've seen something similar with openchrome,
but I think I traced that down to the DMA engines causing memory corruption.
Note that IIRC kmap_atomic may return page_address(page) for a lowmem page.
Any idea what may cause kmap_atomic to behave in this way?
/Thomas
Maarten Maathuis wrote:
> I've
17 matches
Mail list logo
