Re: [PATCH] drm/radeon/kms: fix coherency issues on AGP cards.
On Thu, Oct 29, 2009 at 11:32 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> When we are evicting from VRAM->RAM we allocate the ttm object,
> but we don't set the caching policy on it before blitting into it.
> This means on AGP we end up blitting into cached pages, and
> the CPU later flushes out on top of them. This was mostly seen as
> font corruption.
>
While we are here, are the PT snoop bits and caching set properly on
pages in non-AGP gart?
Alex
> The other question is why we don't evict VRAM->GTT in a lot of cases,
> this would save us some cache transitions since a lot of objects
> that are evicted from VRAM will probably end up being pulled back in
> a few operations later, and evicting them to system memory involves
> 2 unnecessary cache transitions.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 6 ++
> drivers/gpu/drm/ttm/ttm_tt.c | 1 +
> 2 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index c729cd1..f489c0d 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -295,6 +295,12 @@ static int radeon_move_vram_ram(struct ttm_buffer_object
> *bo,
> if (unlikely(r)) {
> return r;
> }
> +
> + r = ttm_tt_set_placement_caching(bo->ttm, tmp_mem.placement);
> + if (unlikely(r)) {
> + goto out_cleanup;
> + }
> +
> r = ttm_tt_bind(bo->ttm, &tmp_mem);
> if (unlikely(r)) {
> goto out_cleanup;
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index a55ee1a..7bcb89f 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -279,6 +279,7 @@ int ttm_tt_set_placement_caching(struct ttm_tt *ttm,
> uint32_t placement)
>
> return ttm_tt_set_caching(ttm, state);
> }
> +EXPORT_SYMBOL(ttm_tt_set_placement_caching);
>
> static void ttm_tt_free_alloced_pages(struct ttm_tt *ttm)
> {
> --
> 1.6.5.1
>
>
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fix coherency issues on AGP cards.
On Sat, Oct 31, 2009 at 12:39 AM, Alex Deucher wrote: > On Thu, Oct 29, 2009 at 11:32 PM, Dave Airlie wrote: >> From: Dave Airlie >> >> When we are evicting from VRAM->RAM we allocate the ttm object, >> but we don't set the caching policy on it before blitting into it. >> This means on AGP we end up blitting into cached pages, and >> the CPU later flushes out on top of them. This was mostly seen as >> font corruption. >> > > While we are here, are the PT snoop bits and caching set properly on > pages in non-AGP gart? > They should be, however there is another bit in PCIE that decides whether to use these bits, I'm not 100% sure on its status. Dave. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fix coherency issues on AGP cards.
On Fri, 2009-10-30 at 13:32 +1000, Dave Airlie wrote:
>
> The other question is why we don't evict VRAM->GTT in a lot of cases,
> this would save us some cache transitions since a lot of objects
> that are evicted from VRAM will probably end up being pulled back in
> a few operations later, and evicting them to system memory involves
> 2 unnecessary cache transitions.
I think the patch below should allow VRAM->GTT eviction. I'm not sure
it's an overall improvement right now though, I think BOs might get
stuck in GTT after eviction there.
commit c9367db23470c5035bf52667a1daa4176d926024
Author: Michel Dänzer
Date: Wed Nov 4 08:41:25 2009 +0100
drm/radeon: Tweak TTM eviction flags to include GTT for eviction from VRAM.
Signed-off-by: Michel Dänzer
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index e116a15..0e76fcc 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -199,13 +199,12 @@ static int radeon_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
static uint32_t radeon_evict_flags(struct ttm_buffer_object *bo)
{
- uint32_t cur_placement = bo->mem.placement & ~TTM_PL_MASK_MEMTYPE;
-
- switch (bo->mem.mem_type) {
- default:
- return (cur_placement & ~TTM_PL_MASK_CACHING) |
- TTM_PL_FLAG_SYSTEM |
- TTM_PL_FLAG_CACHED;
+ if ((bo->mem.placement & TTM_PL_MASK_MEMTYPE) == TTM_PL_FLAG_VRAM) {
+ return (bo->mem.placement & ~TTM_PL_MASK_MEMTYPE) |
+ TTM_PL_FLAG_TT | TTM_PL_FLAG_SYSTEM |
TTM_PL_MASK_CACHING;
+ } else {
+ return (bo->mem.placement & ~TTM_PL_MASK_MEMTYPE) |
+ TTM_PL_FLAG_SYSTEM | TTM_PL_MASK_CACHING;
}
}
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
