On 11/28/2010 10:55 PM, Francisco Jerez wrote:
Thomas Hellstrom writes:
On 11/28/2010 05:11 PM, Francisco Jerez wrote:
Francisco Jerez writes:
Thomas Hellstrom writes:
Ben,
I'm looking at a way to make TTM memory management asynchronous with
the CPU. The
h a certain command before progressing?)
>
Yep, that's what nouveau_fence_sync() does.
> Needless to say, drivers need not activate async operation if they
> don't want to, but for single-channel hardware it will hopefully be
> very simple.
>
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101128/7f5e5869/attachment.pgp>
On 11/28/2010 05:11 PM, Francisco Jerez wrote:
> Francisco Jerez writes:
>
>
>> Thomas Hellstrom 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 mem
pciep_wreg is totally unused, rreg has only one caller and
already checks whether it's an r600 or later chip.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/r300.c|3 ++-
drivers/gpu/drm/radeon/r600.c|8
drivers/gpu/drm/radeon/radeon.h |4
Used in a macro with only a single call-site for each.
IHMO that's a bit too much indirection. Fold them in.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h| 22 --
drivers/gpu/drm/radeon/radeon_device.c | 16
2 files changed, 12
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h | 13 -
drivers/gpu/drm/radeon/radeon_asic.h | 13 +
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5fff6bf..
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_asic.h |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index cf7a8f6..c7cbba3 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
Only adds noise.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h |6 +-
drivers/gpu/drm/radeon/radeon_asic.h | 150 +-
2 files changed, 77 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/rad
Now all the asic specific stuff ist mostly hid in radeon_asic.*
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/r600_audio.c |1 +
drivers/gpu/drm/radeon/r600_hdmi.c |1 +
drivers/gpu/drm/radeon/radeon.h | 61 ++
drivers/gpu/drm/radeon/ra
Move them to radeon_asic.h together with the other asic
specific stuff.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h | 59 --
drivers/gpu/drm/radeon/radeon_asic.h | 53 --
2 files changed, 50 insertions(+),
Hi all,
This is the second part of the header cleanup I've done a few months back
(already merged way back then). Somehow my wish-fairy let me down and this
didn't happen on it's own ;)
I've tacked two let's-kill-some-indirection patches on top of it.
As usual, tested on my agp rv570. Comments h
On 11/28/2010 04:13 PM, Daniel Vetter wrote:
> Hi Thomas,
>
> On Sun, Nov 28, 2010 at 03:19:50PM +0100, Thomas Hellstrom wrote:
>
>> I'm not saying that the current gem code is incorrect. In
>> particular, the gem name system allows upping the handle_count even
>> if it's zero and the name is j
;> /Thomas
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101128/d42bc1be/attachment.pgp>
Hi Thomas,
On Sun, Nov 28, 2010 at 03:19:50PM +0100, Thomas Hellstrom wrote:
> I'm not saying that the current gem code is incorrect. In
> particular, the gem name system allows upping the handle_count even
> if it's zero and the name is just about to be destroyed. I see that
> more as a curiosity
On 11/28/2010 02:35 PM, Daniel Vetter wrote:
> On Sun, Nov 28, 2010 at 01:32:27PM +0100, Thomas Hellstrom wrote:
>
>> This is racy, in that the kref_get() can hit a zero refcount. I
>> think an ideal thing here would be to add a kref_get_unless_zero()
>> for this situation, that returns an erro
e: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101128/9c2a2fa2/attachment.pgp>
On Sun, Nov 28, 2010 at 01:32:27PM +0100, Thomas Hellstrom wrote:
> This is racy, in that the kref_get() can hit a zero refcount. I
> think an ideal thing here would be to add a kref_get_unless_zero()
> for this situation, that returns an error if the refcount was indeed
> zero. I don't think that
Thomas Hellstrom writes:
> On 11/28/2010 05:11 PM, Francisco Jerez wrote:
>> Francisco Jerez writes:
>>
>>
>>> Thomas Hellstrom writes:
>>>
>>>
Ben,
I'm looking at a way to make TTM memory management asynchronous with
the CPU. The idea is that you should basically
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.
While doing that I looked a bit at the
On 11/25/2010 11:38 PM, Dave Airlie wrote:
> On Thu, 2010-11-25 at 21:40 +, Chris Wilson wrote:
>
>> For a deferred-free cache of unreferenced bound objects, a simple
>> reference count is required without the baggage of kref.
>>
> eh?
>
> you've just out of lined kref for no real gai
On 11/28/2010 05:11 PM, Francisco Jerez wrote:
Francisco Jerez writes:
Thomas Hellstrom 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
pciep_wreg is totally unused, rreg has only one caller and
already checks whether it's an r600 or later chip.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/r300.c|3 ++-
drivers/gpu/drm/radeon/r600.c|8
drivers/gpu/drm/radeon/radeon.h |4
Used in a macro with only a single call-site for each.
IHMO that's a bit too much indirection. Fold them in.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h| 22 --
drivers/gpu/drm/radeon/radeon_device.c | 16
2 files changed, 12
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h | 13 -
drivers/gpu/drm/radeon/radeon_asic.h | 13 +
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5fff6bf..
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_asic.h |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index cf7a8f6..c7cbba3 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
Only adds noise.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h |6 +-
drivers/gpu/drm/radeon/radeon_asic.h | 150 +-
2 files changed, 77 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/rad
Now all the asic specific stuff ist mostly hid in radeon_asic.*
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/r600_audio.c |1 +
drivers/gpu/drm/radeon/r600_hdmi.c |1 +
drivers/gpu/drm/radeon/radeon.h | 61 ++
drivers/gpu/drm/radeon/ra
Move them to radeon_asic.h together with the other asic
specific stuff.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h | 59 --
drivers/gpu/drm/radeon/radeon_asic.h | 53 --
2 files changed, 50 insertions(+),
Hi all,
This is the second part of the header cleanup I've done a few months back
(already merged way back then). Somehow my wish-fairy let me down and this
didn't happen on it's own ;)
I've tacked two let's-kill-some-indirection patches on top of it.
As usual, tested on my agp rv570. Comments h
On 11/28/2010 04:13 PM, Daniel Vetter wrote:
Hi Thomas,
On Sun, Nov 28, 2010 at 03:19:50PM +0100, Thomas Hellstrom wrote:
I'm not saying that the current gem code is incorrect. In
particular, the gem name system allows upping the handle_count even
if it's zero and the name is just about to
Francisco Jerez writes:
> Thomas Hellstrom 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
Hi Thomas,
On Sun, Nov 28, 2010 at 03:19:50PM +0100, Thomas Hellstrom wrote:
> I'm not saying that the current gem code is incorrect. In
> particular, the gem name system allows upping the handle_count even
> if it's zero and the name is just about to be destroyed. I see that
> more as a curiosity
On 11/28/2010 02:35 PM, Daniel Vetter wrote:
On Sun, Nov 28, 2010 at 01:32:27PM +0100, Thomas Hellstrom wrote:
This is racy, in that the kref_get() can hit a zero refcount. I
think an ideal thing here would be to add a kref_get_unless_zero()
for this situation, that returns an error if the r
On Sun, Nov 28, 2010 at 01:32:27PM +0100, Thomas Hellstrom wrote:
> This is racy, in that the kref_get() can hit a zero refcount. I
> think an ideal thing here would be to add a kref_get_unless_zero()
> for this situation, that returns an error if the refcount was indeed
> zero. I don't think that
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.
While doing that I looked a bit at t
On 11/25/2010 11:38 PM, Dave Airlie wrote:
On Thu, 2010-11-25 at 21:40 +, Chris Wilson wrote:
For a deferred-free cache of unreferenced bound objects, a simple
reference count is required without the baggage of kref.
eh?
you've just out of lined kref for no real gain.
the whole
Hi Daniel,
I have tested this upgraded patchset again with linux-next
(next-20101126), they work fine.
Can you next time label the complete series as "v2": [PATCH 0/3 v2]
embed drm_gem_object into radeon_bo (don't ask me if git can create
this automatically for you).
Feel free to add:
Test
37 matches
Mail list logo
