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
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
Arvind R wrote:
On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen p...@iki.fi 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()
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
Poulsbo driver and it turned out that we could save a significant
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 unless we
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
periodically.
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. For VRAM we
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 case
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 seems OK
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_cleanup_refs
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).
Also,
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(next,
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
15 matches
Mail list logo
