* [PATCH 0/3] embed drm_gem_object into radeon_bo
@ 2010-11-13 20:57 Daniel Vetter
2010-11-13 20:57 ` [PATCH 1/3] drm/radeon: embed struct drm_gem_object Daniel Vetter
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Daniel Vetter @ 2010-11-13 20:57 UTC (permalink / raw)
To: dri-devel; +Cc: Daniel Vetter
Hi all,
This patch series embeds drm_gem_object into struct radeon_bo and adjusts
any references. I've decided against embedding the gem stuff into struct
ttm_bo because
- vmwgfx doesn't use gem and
- ttm is used for implementing the memory management, whereas gem provides
the userspace interface (I know, there's some overlap there, but that's
not really a new problem).
Please review and consider merging for -next.
Yours, Daniel
Daniel Vetter (3):
drm/radeon: embed struct drm_gem_object
drm/radeon: introduce gem_to_radeon_bo helper
drm/radeon: kill radeon_bo->gobj pointer
drivers/gpu/drm/radeon/atombios_crtc.c | 8 ++--
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 2 +-
drivers/gpu/drm/radeon/r600.c | 2 +-
drivers/gpu/drm/radeon/r600_blit_kms.c | 2 +-
drivers/gpu/drm/radeon/radeon.h | 3 +-
drivers/gpu/drm/radeon/radeon_benchmark.c | 4 +-
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 4 +-
drivers/gpu/drm/radeon/radeon_fb.c | 10 +++---
drivers/gpu/drm/radeon/radeon_gart.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 43 ++++++++++++---------------
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 4 +-
drivers/gpu/drm/radeon/radeon_object.c | 24 +++++++--------
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_ring.c | 4 +-
drivers/gpu/drm/radeon/radeon_test.c | 4 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/radeon/rv770.c | 2 +-
18 files changed, 59 insertions(+), 65 deletions(-)
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH 1/3] drm/radeon: embed struct drm_gem_object 2010-11-13 20:57 [PATCH 0/3] embed drm_gem_object into radeon_bo Daniel Vetter @ 2010-11-13 20:57 ` Daniel Vetter 2010-11-13 20:57 ` [PATCH 2/3] drm/radeon: introduce gem_to_radeon_bo helper Daniel Vetter ` (2 subsequent siblings) 3 siblings, 0 replies; 14+ messages in thread From: Daniel Vetter @ 2010-11-13 20:57 UTC (permalink / raw) To: dri-devel; +Cc: Daniel Vetter Unconditionally initialize the drm gem object - it's not worth the trouble not to for the few kernel objects. This patch only changes the place of the drm gem object, access is still done via pointers. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/radeon/evergreen_blit_kms.c | 2 +- drivers/gpu/drm/radeon/r600.c | 2 +- drivers/gpu/drm/radeon/r600_blit_kms.c | 2 +- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_benchmark.c | 4 ++-- drivers/gpu/drm/radeon/radeon_device.c | 2 +- drivers/gpu/drm/radeon/radeon_gart.c | 2 +- drivers/gpu/drm/radeon/radeon_gem.c | 22 +++++++++------------- drivers/gpu/drm/radeon/radeon_object.c | 16 +++++++++------- drivers/gpu/drm/radeon/radeon_object.h | 2 +- drivers/gpu/drm/radeon/radeon_ring.c | 4 ++-- drivers/gpu/drm/radeon/radeon_test.c | 4 ++-- drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- drivers/gpu/drm/radeon/rv770.c | 2 +- 14 files changed, 33 insertions(+), 34 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c b/drivers/gpu/drm/radeon/evergreen_blit_kms.c index ac3b6dd..f8b4b1b 100644 --- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c +++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c @@ -459,7 +459,7 @@ int evergreen_blit_init(struct radeon_device *rdev) obj_size += evergreen_ps_size * 4; obj_size = ALIGN(obj_size, 256); - r = radeon_bo_create(rdev, NULL, obj_size, true, RADEON_GEM_DOMAIN_VRAM, + r = radeon_bo_create(rdev, obj_size, true, RADEON_GEM_DOMAIN_VRAM, &rdev->r600_blit.shader_obj); if (r) { DRM_ERROR("evergreen failed to allocate shader\n"); diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index 33952a1..82376b2 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -2723,7 +2723,7 @@ static int r600_ih_ring_alloc(struct radeon_device *rdev) /* Allocate ring buffer */ if (rdev->ih.ring_obj == NULL) { - r = radeon_bo_create(rdev, NULL, rdev->ih.ring_size, + r = radeon_bo_create(rdev, rdev->ih.ring_size, true, RADEON_GEM_DOMAIN_GTT, &rdev->ih.ring_obj); diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c b/drivers/gpu/drm/radeon/r600_blit_kms.c index 8362974..c9cb553 100644 --- a/drivers/gpu/drm/radeon/r600_blit_kms.c +++ b/drivers/gpu/drm/radeon/r600_blit_kms.c @@ -501,7 +501,7 @@ int r600_blit_init(struct radeon_device *rdev) obj_size += r6xx_ps_size * 4; obj_size = ALIGN(obj_size, 256); - r = radeon_bo_create(rdev, NULL, obj_size, true, RADEON_GEM_DOMAIN_VRAM, + r = radeon_bo_create(rdev, obj_size, true, RADEON_GEM_DOMAIN_VRAM, &rdev->r600_blit.shader_obj); if (r) { DRM_ERROR("r600 failed to allocate shader\n"); diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 73f600d..e2409b9 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -256,6 +256,7 @@ struct radeon_bo { /* Constant after initialization */ struct radeon_device *rdev; struct drm_gem_object *gobj; + struct drm_gem_object gem_base; }; struct radeon_bo_list { diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c b/drivers/gpu/drm/radeon/radeon_benchmark.c index 7932dc4..1bdf3cc 100644 --- a/drivers/gpu/drm/radeon/radeon_benchmark.c +++ b/drivers/gpu/drm/radeon/radeon_benchmark.c @@ -41,7 +41,7 @@ void radeon_benchmark_move(struct radeon_device *rdev, unsigned bsize, size = bsize; n = 1024; - r = radeon_bo_create(rdev, NULL, size, true, sdomain, &sobj); + r = radeon_bo_create(rdev, size, true, sdomain, &sobj); if (r) { goto out_cleanup; } @@ -53,7 +53,7 @@ void radeon_benchmark_move(struct radeon_device *rdev, unsigned bsize, if (r) { goto out_cleanup; } - r = radeon_bo_create(rdev, NULL, size, true, ddomain, &dobj); + r = radeon_bo_create(rdev, size, true, ddomain, &dobj); if (r) { goto out_cleanup; } diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 8adfedf..6ac28ee 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -180,7 +180,7 @@ int radeon_wb_init(struct radeon_device *rdev) int r; if (rdev->wb.wb_obj == NULL) { - r = radeon_bo_create(rdev, NULL, RADEON_GPU_PAGE_SIZE, true, + r = radeon_bo_create(rdev, RADEON_GPU_PAGE_SIZE, true, RADEON_GEM_DOMAIN_GTT, &rdev->wb.wb_obj); if (r) { dev_warn(rdev->dev, "(%d) create WB bo failed\n", r); diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index e65b903..344fe82 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -78,7 +78,7 @@ int radeon_gart_table_vram_alloc(struct radeon_device *rdev) int r; if (rdev->gart.table.vram.robj == NULL) { - r = radeon_bo_create(rdev, NULL, rdev->gart.table_size, + r = radeon_bo_create(rdev, rdev->gart.table_size, true, RADEON_GEM_DOMAIN_VRAM, &rdev->gart.table.vram.robj); if (r) { diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index d1e595d..9873a96 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -32,7 +32,8 @@ int radeon_gem_object_init(struct drm_gem_object *obj) { - /* we do nothings here */ + BUG(); + return 0; } @@ -44,9 +45,6 @@ void radeon_gem_object_free(struct drm_gem_object *gobj) if (robj) { radeon_bo_unref(&robj); } - - drm_gem_object_release(gobj); - kfree(gobj); } int radeon_gem_object_create(struct radeon_device *rdev, int size, @@ -54,29 +52,27 @@ int radeon_gem_object_create(struct radeon_device *rdev, int size, bool discardable, bool kernel, struct drm_gem_object **obj) { - struct drm_gem_object *gobj; struct radeon_bo *robj; int r; *obj = NULL; - gobj = drm_gem_object_alloc(rdev->ddev, size); - if (!gobj) { - return -ENOMEM; - } /* At least align on page size */ if (alignment < PAGE_SIZE) { alignment = PAGE_SIZE; } - r = radeon_bo_create(rdev, gobj, size, kernel, initial_domain, &robj); + r = radeon_bo_create(rdev, size, kernel, initial_domain, &robj); if (r) { if (r != -ERESTARTSYS) DRM_ERROR("Failed to allocate GEM object (%d, %d, %u, %d)\n", size, initial_domain, alignment, r); - drm_gem_object_unreference_unlocked(gobj); return r; } - gobj->driver_private = robj; - *obj = gobj; + *obj = &robj->gem_base; + + mutex_lock(&rdev->gem.mutex); + list_add_tail(&robj->list, &rdev->gem.objects); + mutex_unlock(&rdev->gem.mutex); + return 0; } diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index d7ab914..30a2d54 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -54,6 +54,7 @@ static void radeon_ttm_bo_destroy(struct ttm_buffer_object *tbo) list_del_init(&bo->list); mutex_unlock(&bo->rdev->gem.mutex); radeon_bo_clear_surface_reg(bo); + drm_gem_object_release(&bo->gem_base); kfree(bo); } @@ -85,7 +86,7 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain) rbo->placement.num_busy_placement = c; } -int radeon_bo_create(struct radeon_device *rdev, struct drm_gem_object *gobj, +int radeon_bo_create(struct radeon_device *rdev, unsigned long size, bool kernel, u32 domain, struct radeon_bo **bo_ptr) { @@ -105,8 +106,14 @@ int radeon_bo_create(struct radeon_device *rdev, struct drm_gem_object *gobj, bo = kzalloc(sizeof(struct radeon_bo), GFP_KERNEL); if (bo == NULL) return -ENOMEM; + r = drm_gem_object_init(rdev->ddev, &bo->gem_base, size); + if (unlikely(r)) { + kfree(bo); + return r; + } bo->rdev = rdev; - bo->gobj = gobj; + bo->gobj = &bo->gem_base; + bo->gem_base.driver_private = bo; bo->surface_reg = -1; INIT_LIST_HEAD(&bo->list); @@ -131,11 +138,6 @@ retry: return r; } *bo_ptr = bo; - if (gobj) { - mutex_lock(&bo->rdev->gem.mutex); - list_add_tail(&bo->list, &rdev->gem.objects); - mutex_unlock(&bo->rdev->gem.mutex); - } return 0; } diff --git a/drivers/gpu/drm/radeon/radeon_object.h b/drivers/gpu/drm/radeon/radeon_object.h index 3481bc7..c3dd268 100644 --- a/drivers/gpu/drm/radeon/radeon_object.h +++ b/drivers/gpu/drm/radeon/radeon_object.h @@ -137,7 +137,7 @@ static inline int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type, } extern int radeon_bo_create(struct radeon_device *rdev, - struct drm_gem_object *gobj, unsigned long size, + unsigned long size, bool kernel, u32 domain, struct radeon_bo **bo_ptr); extern int radeon_bo_kmap(struct radeon_bo *bo, void **ptr); diff --git a/drivers/gpu/drm/radeon/radeon_ring.c b/drivers/gpu/drm/radeon/radeon_ring.c index 6ea798c..750e965 100644 --- a/drivers/gpu/drm/radeon/radeon_ring.c +++ b/drivers/gpu/drm/radeon/radeon_ring.c @@ -175,7 +175,7 @@ int radeon_ib_pool_init(struct radeon_device *rdev) return 0; INIT_LIST_HEAD(&rdev->ib_pool.bogus_ib); /* Allocate 1M object buffer */ - r = radeon_bo_create(rdev, NULL, RADEON_IB_POOL_SIZE*64*1024, + r = radeon_bo_create(rdev, RADEON_IB_POOL_SIZE*64*1024, true, RADEON_GEM_DOMAIN_GTT, &rdev->ib_pool.robj); if (r) { @@ -332,7 +332,7 @@ int radeon_ring_init(struct radeon_device *rdev, unsigned ring_size) rdev->cp.ring_size = ring_size; /* Allocate ring buffer */ if (rdev->cp.ring_obj == NULL) { - r = radeon_bo_create(rdev, NULL, rdev->cp.ring_size, true, + r = radeon_bo_create(rdev, rdev->cp.ring_size, true, RADEON_GEM_DOMAIN_GTT, &rdev->cp.ring_obj); if (r) { diff --git a/drivers/gpu/drm/radeon/radeon_test.c b/drivers/gpu/drm/radeon/radeon_test.c index 313c96b..8d7bdd6 100644 --- a/drivers/gpu/drm/radeon/radeon_test.c +++ b/drivers/gpu/drm/radeon/radeon_test.c @@ -52,7 +52,7 @@ void radeon_test_moves(struct radeon_device *rdev) goto out_cleanup; } - r = radeon_bo_create(rdev, NULL, size, true, RADEON_GEM_DOMAIN_VRAM, + r = radeon_bo_create(rdev, size, true, RADEON_GEM_DOMAIN_VRAM, &vram_obj); if (r) { DRM_ERROR("Failed to create VRAM object\n"); @@ -71,7 +71,7 @@ void radeon_test_moves(struct radeon_device *rdev) void **gtt_start, **gtt_end; void **vram_start, **vram_end; - r = radeon_bo_create(rdev, NULL, size, true, + r = radeon_bo_create(rdev, size, true, RADEON_GEM_DOMAIN_GTT, gtt_obj + i); if (r) { DRM_ERROR("Failed to create GTT object %d\n", i); diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index fe95bb3..0c19928 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -529,7 +529,7 @@ int radeon_ttm_init(struct radeon_device *rdev) DRM_ERROR("Failed initializing VRAM heap.\n"); return r; } - r = radeon_bo_create(rdev, NULL, 256 * 1024, true, + r = radeon_bo_create(rdev, 256 * 1024, true, RADEON_GEM_DOMAIN_VRAM, &rdev->stollen_vga_memory); if (r) { diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c index 245374e..0eb74f6 100644 --- a/drivers/gpu/drm/radeon/rv770.c +++ b/drivers/gpu/drm/radeon/rv770.c @@ -914,7 +914,7 @@ static int rv770_vram_scratch_init(struct radeon_device *rdev) u64 gpu_addr; if (rdev->vram_scratch.robj == NULL) { - r = radeon_bo_create(rdev, NULL, RADEON_GPU_PAGE_SIZE, + r = radeon_bo_create(rdev, RADEON_GPU_PAGE_SIZE, true, RADEON_GEM_DOMAIN_VRAM, &rdev->vram_scratch.robj); if (r) { -- 1.7.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 2/3] drm/radeon: introduce gem_to_radeon_bo helper 2010-11-13 20:57 [PATCH 0/3] embed drm_gem_object into radeon_bo Daniel Vetter 2010-11-13 20:57 ` [PATCH 1/3] drm/radeon: embed struct drm_gem_object Daniel Vetter @ 2010-11-13 20:57 ` Daniel Vetter 2010-11-13 20:57 ` [PATCH 3/3] drm/radeon: kill radeon_bo->gobj pointer Daniel Vetter 2010-11-15 7:25 ` [PATCH 0/3] embed drm_gem_object into radeon_bo Thomas Hellstrom 3 siblings, 0 replies; 14+ messages in thread From: Daniel Vetter @ 2010-11-13 20:57 UTC (permalink / raw) To: dri-devel; +Cc: Daniel Vetter ... and switch it to container_of upcasting. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/radeon/atombios_crtc.c | 8 ++++---- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_cs.c | 2 +- drivers/gpu/drm/radeon/radeon_device.c | 2 +- drivers/gpu/drm/radeon/radeon_fb.c | 10 +++++----- drivers/gpu/drm/radeon/radeon_gem.c | 21 ++++++++++----------- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 4 ++-- drivers/gpu/drm/radeon/radeon_object.c | 3 +-- 8 files changed, 25 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index df2b6f2..7ecb154 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -978,7 +978,7 @@ static int evergreen_crtc_do_set_base(struct drm_crtc *crtc, * just update base pointers */ obj = radeon_fb->obj; - rbo = obj->driver_private; + rbo = gem_to_radeon_bo(obj); r = radeon_bo_reserve(rbo, false); if (unlikely(r != 0)) return r; @@ -1086,7 +1086,7 @@ static int evergreen_crtc_do_set_base(struct drm_crtc *crtc, if (!atomic && fb && fb != crtc->fb) { radeon_fb = to_radeon_framebuffer(fb); - rbo = radeon_fb->obj->driver_private; + rbo = gem_to_radeon_bo(radeon_fb->obj); r = radeon_bo_reserve(rbo, false); if (unlikely(r != 0)) return r; @@ -1131,7 +1131,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc, } obj = radeon_fb->obj; - rbo = obj->driver_private; + rbo = gem_to_radeon_bo(obj); r = radeon_bo_reserve(rbo, false); if (unlikely(r != 0)) return r; @@ -1240,7 +1240,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc, if (!atomic && fb && fb != crtc->fb) { radeon_fb = to_radeon_framebuffer(fb); - rbo = radeon_fb->obj->driver_private; + rbo = gem_to_radeon_bo(radeon_fb->obj); r = radeon_bo_reserve(rbo, false); if (unlikely(r != 0)) return r; diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index e2409b9..239eba7 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -258,6 +258,7 @@ struct radeon_bo { struct drm_gem_object *gobj; struct drm_gem_object gem_base; }; +#define gem_to_radeon_bo(gobj) container_of((gobj), struct radeon_bo, gem_base) struct radeon_bo_list { struct list_head list; diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index 6d64a27..64096f3 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -75,7 +75,7 @@ int radeon_cs_parser_relocs(struct radeon_cs_parser *p) return -ENOENT; } p->relocs_ptr[i] = &p->relocs[i]; - p->relocs[i].robj = p->relocs[i].gobj->driver_private; + p->relocs[i].robj = gem_to_radeon_bo(p->relocs[i].gobj); p->relocs[i].lobj.bo = p->relocs[i].robj; p->relocs[i].lobj.rdomain = r->read_domains; p->relocs[i].lobj.wdomain = r->write_domain; diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 6ac28ee..3f42760 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -851,7 +851,7 @@ int radeon_suspend_kms(struct drm_device *dev, pm_message_t state) if (rfb == NULL || rfb->obj == NULL) { continue; } - robj = rfb->obj->driver_private; + robj = gem_to_radeon_bo(rfb->obj); /* don't unpin kernel fb objects */ if (!radeon_fbdev_robj_is_fb(rdev, robj)) { r = radeon_bo_reserve(robj, false); diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index efa2118..99712b3 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -90,7 +90,7 @@ static int radeon_align_pitch(struct radeon_device *rdev, int width, int bpp, bo static void radeonfb_destroy_pinned_object(struct drm_gem_object *gobj) { - struct radeon_bo *rbo = gobj->driver_private; + struct radeon_bo *rbo = gem_to_radeon_bo(gobj); int ret; ret = radeon_bo_reserve(rbo, false); @@ -128,7 +128,7 @@ static int radeonfb_create_pinned_object(struct radeon_fbdev *rfbdev, aligned_size); return -ENOMEM; } - rbo = gobj->driver_private; + rbo = gem_to_radeon_bo(gobj); if (fb_tiled) tiling_flags = RADEON_TILING_MACRO; @@ -202,7 +202,7 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev, mode_cmd.depth = sizes->surface_depth; ret = radeonfb_create_pinned_object(rfbdev, &mode_cmd, &gobj); - rbo = gobj->driver_private; + rbo = gem_to_radeon_bo(gobj); /* okay we have an object now allocate the framebuffer */ info = framebuffer_alloc(0, device); @@ -405,14 +405,14 @@ int radeon_fbdev_total_size(struct radeon_device *rdev) struct radeon_bo *robj; int size = 0; - robj = rdev->mode_info.rfbdev->rfb.obj->driver_private; + robj = gem_to_radeon_bo(rdev->mode_info.rfbdev->rfb.obj); size += radeon_bo_size(robj); return size; } bool radeon_fbdev_robj_is_fb(struct radeon_device *rdev, struct radeon_bo *robj) { - if (robj == rdev->mode_info.rfbdev->rfb.obj->driver_private) + if (robj == gem_to_radeon_bo(rdev->mode_info.rfbdev->rfb.obj)) return true; return false; } diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index 9873a96..072d21c 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -39,9 +39,8 @@ int radeon_gem_object_init(struct drm_gem_object *obj) void radeon_gem_object_free(struct drm_gem_object *gobj) { - struct radeon_bo *robj = gobj->driver_private; + struct radeon_bo *robj = gem_to_radeon_bo(gobj); - gobj->driver_private = NULL; if (robj) { radeon_bo_unref(&robj); } @@ -79,7 +78,7 @@ int radeon_gem_object_create(struct radeon_device *rdev, int size, int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain, uint64_t *gpu_addr) { - struct radeon_bo *robj = obj->driver_private; + struct radeon_bo *robj = gem_to_radeon_bo(obj); int r; r = radeon_bo_reserve(robj, false); @@ -92,7 +91,7 @@ int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain, void radeon_gem_object_unpin(struct drm_gem_object *obj) { - struct radeon_bo *robj = obj->driver_private; + struct radeon_bo *robj = gem_to_radeon_bo(obj); int r; r = radeon_bo_reserve(robj, false); @@ -110,7 +109,7 @@ int radeon_gem_set_domain(struct drm_gem_object *gobj, int r; /* FIXME: reeimplement */ - robj = gobj->driver_private; + robj = gem_to_radeon_bo(gobj); /* work out where to validate the buffer to */ domain = wdomain; if (!domain) { @@ -224,7 +223,7 @@ int radeon_gem_set_domain_ioctl(struct drm_device *dev, void *data, if (gobj == NULL) { return -ENOENT; } - robj = gobj->driver_private; + robj = gem_to_radeon_bo(gobj); r = radeon_gem_set_domain(gobj, args->read_domains, args->write_domain); @@ -243,7 +242,7 @@ int radeon_gem_mmap_ioctl(struct drm_device *dev, void *data, if (gobj == NULL) { return -ENOENT; } - robj = gobj->driver_private; + robj = gem_to_radeon_bo(gobj); args->addr_ptr = radeon_bo_mmap_offset(robj); drm_gem_object_unreference_unlocked(gobj); return 0; @@ -262,7 +261,7 @@ int radeon_gem_busy_ioctl(struct drm_device *dev, void *data, if (gobj == NULL) { return -ENOENT; } - robj = gobj->driver_private; + robj = gem_to_radeon_bo(gobj); r = radeon_bo_wait(robj, &cur_placement, true); switch (cur_placement) { case TTM_PL_VRAM: @@ -292,7 +291,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void *data, if (gobj == NULL) { return -ENOENT; } - robj = gobj->driver_private; + robj = gem_to_radeon_bo(gobj); r = radeon_bo_wait(robj, NULL, false); /* callback hw specific functions if any */ if (robj->rdev->asic->ioctl_wait_idle) @@ -313,7 +312,7 @@ int radeon_gem_set_tiling_ioctl(struct drm_device *dev, void *data, gobj = drm_gem_object_lookup(dev, filp, args->handle); if (gobj == NULL) return -ENOENT; - robj = gobj->driver_private; + robj = gem_to_radeon_bo(gobj); r = radeon_bo_set_tiling_flags(robj, args->tiling_flags, args->pitch); drm_gem_object_unreference_unlocked(gobj); return r; @@ -331,7 +330,7 @@ int radeon_gem_get_tiling_ioctl(struct drm_device *dev, void *data, gobj = drm_gem_object_lookup(dev, filp, args->handle); if (gobj == NULL) return -ENOENT; - rbo = gobj->driver_private; + rbo = gem_to_radeon_bo(gobj); r = radeon_bo_reserve(rbo, false); if (unlikely(r != 0)) goto out; diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c index ace2e63..ee76d29 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c @@ -415,7 +415,7 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc, /* Pin framebuffer & get tilling informations */ obj = radeon_fb->obj; - rbo = obj->driver_private; + rbo = gem_to_radeon_bo(obj); r = radeon_bo_reserve(rbo, false); if (unlikely(r != 0)) return r; @@ -520,7 +520,7 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc, if (!atomic && fb && fb != crtc->fb) { radeon_fb = to_radeon_framebuffer(fb); - rbo = radeon_fb->obj->driver_private; + rbo = gem_to_radeon_bo(radeon_fb->obj); r = radeon_bo_reserve(rbo, false); if (unlikely(r != 0)) return r; diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 30a2d54..99efe4a 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -113,7 +113,7 @@ int radeon_bo_create(struct radeon_device *rdev, } bo->rdev = rdev; bo->gobj = &bo->gem_base; - bo->gem_base.driver_private = bo; + bo->gem_base.driver_private = NULL; bo->surface_reg = -1; INIT_LIST_HEAD(&bo->list); @@ -266,7 +266,6 @@ void radeon_bo_force_delete(struct radeon_device *rdev) list_del_init(&bo->list); mutex_unlock(&bo->rdev->gem.mutex); radeon_bo_unref(&bo); - gobj->driver_private = NULL; drm_gem_object_unreference(gobj); mutex_unlock(&rdev->ddev->struct_mutex); } -- 1.7.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 3/3] drm/radeon: kill radeon_bo->gobj pointer 2010-11-13 20:57 [PATCH 0/3] embed drm_gem_object into radeon_bo Daniel Vetter 2010-11-13 20:57 ` [PATCH 1/3] drm/radeon: embed struct drm_gem_object Daniel Vetter 2010-11-13 20:57 ` [PATCH 2/3] drm/radeon: introduce gem_to_radeon_bo helper Daniel Vetter @ 2010-11-13 20:57 ` Daniel Vetter 2010-11-15 7:25 ` [PATCH 0/3] embed drm_gem_object into radeon_bo Thomas Hellstrom 3 siblings, 0 replies; 14+ messages in thread From: Daniel Vetter @ 2010-11-13 20:57 UTC (permalink / raw) To: dri-devel; +Cc: Daniel Vetter Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/radeon/radeon.h | 1 - drivers/gpu/drm/radeon/radeon_object.c | 9 +++------ 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 239eba7..9464100 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -255,7 +255,6 @@ struct radeon_bo { int surface_reg; /* Constant after initialization */ struct radeon_device *rdev; - struct drm_gem_object *gobj; struct drm_gem_object gem_base; }; #define gem_to_radeon_bo(gobj) container_of((gobj), struct radeon_bo, gem_base) diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 99efe4a..18db45f 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -112,7 +112,6 @@ int radeon_bo_create(struct radeon_device *rdev, return r; } bo->rdev = rdev; - bo->gobj = &bo->gem_base; bo->gem_base.driver_private = NULL; bo->surface_reg = -1; INIT_LIST_HEAD(&bo->list); @@ -250,7 +249,6 @@ int radeon_bo_evict_vram(struct radeon_device *rdev) void radeon_bo_force_delete(struct radeon_device *rdev) { struct radeon_bo *bo, *n; - struct drm_gem_object *gobj; if (list_empty(&rdev->gem.objects)) { return; @@ -258,15 +256,14 @@ void radeon_bo_force_delete(struct radeon_device *rdev) dev_err(rdev->dev, "Userspace still has active objects !\n"); list_for_each_entry_safe(bo, n, &rdev->gem.objects, list) { mutex_lock(&rdev->ddev->struct_mutex); - gobj = bo->gobj; dev_err(rdev->dev, "%p %p %lu %lu force free\n", - gobj, bo, (unsigned long)gobj->size, - *((unsigned long *)&gobj->refcount)); + &bo->gem_base, bo, (unsigned long)bo->gem_base.size, + *((unsigned long *)&bo->gem_base.refcount)); mutex_lock(&bo->rdev->gem.mutex); list_del_init(&bo->list); mutex_unlock(&bo->rdev->gem.mutex); radeon_bo_unref(&bo); - drm_gem_object_unreference(gobj); + drm_gem_object_unreference(&bo->gem_base); mutex_unlock(&rdev->ddev->struct_mutex); } } -- 1.7.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 0/3] embed drm_gem_object into radeon_bo 2010-11-13 20:57 [PATCH 0/3] embed drm_gem_object into radeon_bo Daniel Vetter ` (2 preceding siblings ...) 2010-11-13 20:57 ` [PATCH 3/3] drm/radeon: kill radeon_bo->gobj pointer Daniel Vetter @ 2010-11-15 7:25 ` Thomas Hellstrom 2010-11-15 18:45 ` Daniel Vetter 3 siblings, 1 reply; 14+ messages in thread From: Thomas Hellstrom @ 2010-11-15 7:25 UTC (permalink / raw) To: Daniel Vetter; +Cc: dri-devel Hi, Daniel, My main concerns previously for embedding GEM objects as user-space references for TTM has been twofold and implementation specific. 1) The locking has been using global mutexes where local spin- or RCU locks have been more appropriate. It looks like this has finally been / is finally going to be addressed. 2) The gem object is too specialized for general purpose use: a) The shmem member has no natural use with TTM except possibly as a persistent swap storage, but in an ideal world, TTM would talk to the swap cache directly so in the longer term there is no need for the shmem object at all. b) Implementations may want to use other user-space visible objects than buffer objects: For example fence objects or CPU synchronization objects. The common traits of / operations on these are user-space visibility, inter-process visibility, refcounting and destruction when the relevant file is closed. Hence a class that provides only the user-space handles, naming (flink), refcounting and registering with a file handle would be the best choice of a "base" class. Traditional Gem objects could derive from those and provide any extra *generic* members needed for buffer objects. This doesn't really affect your work though. Just some comments on why vmwgfx don't use GEM objects by default and how they could be made optimal for TTM-aware drivers. Thanks, /Thomas On 11/13/2010 09:57 PM, Daniel Vetter wrote: > Hi all, > > This patch series embeds drm_gem_object into struct radeon_bo and adjusts > any references. I've decided against embedding the gem stuff into struct > ttm_bo because > - vmwgfx doesn't use gem and > - ttm is used for implementing the memory management, whereas gem provides > the userspace interface (I know, there's some overlap there, but that's > not really a new problem). > > Please review and consider merging for -next. > > Yours, Daniel > > Daniel Vetter (3): > drm/radeon: embed struct drm_gem_object > drm/radeon: introduce gem_to_radeon_bo helper > drm/radeon: kill radeon_bo->gobj pointer > > drivers/gpu/drm/radeon/atombios_crtc.c | 8 ++-- > drivers/gpu/drm/radeon/evergreen_blit_kms.c | 2 +- > drivers/gpu/drm/radeon/r600.c | 2 +- > drivers/gpu/drm/radeon/r600_blit_kms.c | 2 +- > drivers/gpu/drm/radeon/radeon.h | 3 +- > drivers/gpu/drm/radeon/radeon_benchmark.c | 4 +- > drivers/gpu/drm/radeon/radeon_cs.c | 2 +- > drivers/gpu/drm/radeon/radeon_device.c | 4 +- > drivers/gpu/drm/radeon/radeon_fb.c | 10 +++--- > drivers/gpu/drm/radeon/radeon_gart.c | 2 +- > drivers/gpu/drm/radeon/radeon_gem.c | 43 ++++++++++++--------------- > drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 4 +- > drivers/gpu/drm/radeon/radeon_object.c | 24 +++++++-------- > drivers/gpu/drm/radeon/radeon_object.h | 2 +- > drivers/gpu/drm/radeon/radeon_ring.c | 4 +- > drivers/gpu/drm/radeon/radeon_test.c | 4 +- > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- > drivers/gpu/drm/radeon/rv770.c | 2 +- > 18 files changed, 59 insertions(+), 65 deletions(-) > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/3] embed drm_gem_object into radeon_bo 2010-11-15 7:25 ` [PATCH 0/3] embed drm_gem_object into radeon_bo Thomas Hellstrom @ 2010-11-15 18:45 ` Daniel Vetter 2010-11-15 20:48 ` Thomas Hellstrom 0 siblings, 1 reply; 14+ messages in thread From: Daniel Vetter @ 2010-11-15 18:45 UTC (permalink / raw) To: Thomas Hellstrom; +Cc: Daniel Vetter, dri-devel Hi Thomas, Thanks for your comments about ttm and vmwgfx. Some of my own ideas about where this might all be heading below. On Mon, Nov 15, 2010 at 08:25:16AM +0100, Thomas Hellstrom wrote: > Hi, Daniel, > > My main concerns previously for embedding GEM objects as user-space > references for TTM has been twofold and implementation specific. > > 1) The locking has been using global mutexes where local spin- or > RCU locks have been more appropriate. It looks like this has finally > been / is finally going to be addressed. gem object lookup / insert has always (iirc) been protected by a spinlock. drm/i915 is just a bit inefficient with lookups, hence this spinlock showing up in profiling. > 2) The gem object is too specialized for general purpose use: > a) The shmem member has no natural use with TTM except possibly as a > persistent swap storage, but in an ideal world, TTM would talk to > the swap cache directly so in the longer term there is no need for > the shmem object at all. Chris Wilson is working on a gem_vm for i915 that employs a address_space per bo and directly manages swap entries and has its own page allocator (actualy cflushed page cache). I haven't yet looked into this closely (especially the ttm part), but this might (at least in parts) be shareable between i915 and ttm. At least it gets rid of the shmfs inode in struct drm_gem_object! > b) Implementations may want to use other user-space visible objects > than buffer objects: > For example fence objects or CPU synchronization objects. The common > traits of / operations on these are user-space visibility, > inter-process visibility, refcounting and destruction when the > relevant file is closed. > > Hence a class that provides only the user-space handles, naming > (flink), refcounting and registering with a file handle would be the > best choice of a "base" class. Traditional Gem objects could derive > from those and provide any extra *generic* members needed for buffer > objects. > > This doesn't really affect your work though. Just some comments on > why vmwgfx don't use GEM objects by default and how they could be > made optimal for TTM-aware drivers. Yeah, I've noticed that vmwgfx is the (sometimes) sole user of many of the more fancy stuff in ttm. And I also don't like the duplication between gem and ttm. My plan (i.e. wishful thinking) is to have a common set of helper functions that can be shared between i915, radeon and nouveau and any other driver with a gem-like interface (i.e. buffer-objects + execbuffer, gpu<->cpu sync abstracted away by the kernel). Leaving the cracy stuff for drivers that need it (vmwgfx). Nothing concrete though (besides a new testing rig to start hacking on nouveau), I'll intend to simply plow along, hunting for common patterns. > Thanks, > /Thomas Yours, Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/3] embed drm_gem_object into radeon_bo 2010-11-15 18:45 ` Daniel Vetter @ 2010-11-15 20:48 ` Thomas Hellstrom 0 siblings, 0 replies; 14+ messages in thread From: Thomas Hellstrom @ 2010-11-15 20:48 UTC (permalink / raw) To: Daniel Vetter; +Cc: Daniel Vetter, dri-devel On 11/15/2010 07:45 PM, Daniel Vetter wrote: > Hi Thomas, > > Thanks for your comments about ttm and vmwgfx. Some of my own ideas about > where this might all be heading below. > > On Mon, Nov 15, 2010 at 08:25:16AM +0100, Thomas Hellstrom wrote: > >> Hi, Daniel, >> >> My main concerns previously for embedding GEM objects as user-space >> references for TTM has been twofold and implementation specific. >> >> 1) The locking has been using global mutexes where local spin- or >> RCU locks have been more appropriate. It looks like this has finally >> been / is finally going to be addressed. >> > gem object lookup / insert has always (iirc) been protected by a spinlock. > drm/i915 is just a bit inefficient with lookups, hence this spinlock > showing up in profiling. > > >> 2) The gem object is too specialized for general purpose use: >> a) The shmem member has no natural use with TTM except possibly as a >> persistent swap storage, but in an ideal world, TTM would talk to >> the swap cache directly so in the longer term there is no need for >> the shmem object at all. >> > Chris Wilson is working on a gem_vm for i915 that employs a address_space > per bo and directly manages swap entries and has its own page allocator > (actualy cflushed page cache). I haven't yet looked into this closely > (especially the ttm part), but this might (at least in parts) be shareable > between i915 and ttm. At least it gets rid of the shmfs inode in struct > drm_gem_object! > > >> b) Implementations may want to use other user-space visible objects >> than buffer objects: >> For example fence objects or CPU synchronization objects. The common >> traits of / operations on these are user-space visibility, >> inter-process visibility, refcounting and destruction when the >> relevant file is closed. >> >> Hence a class that provides only the user-space handles, naming >> (flink), refcounting and registering with a file handle would be the >> best choice of a "base" class. Traditional Gem objects could derive >> from those and provide any extra *generic* members needed for buffer >> objects. >> >> This doesn't really affect your work though. Just some comments on >> why vmwgfx don't use GEM objects by default and how they could be >> made optimal for TTM-aware drivers. >> > Yeah, I've noticed that vmwgfx is the (sometimes) sole user of many of the > more fancy stuff in ttm. And I also don't like the duplication between gem > and ttm. My plan (i.e. wishful thinking) is to have a common set of helper > functions that can be shared between i915, radeon and nouveau and any > other driver with a gem-like interface (i.e. buffer-objects + execbuffer, > gpu<->cpu sync abstracted away by the kernel). Leaving the cracy stuff for > drivers that need it (vmwgfx). Nothing concrete though (besides a new > testing rig to start hacking on nouveau), I'll intend to simply plow > along, hunting for common patterns. > Sounds good. I actually think the only thing which is currently vmwgfx-specific are the ttm_objects and the ttm_locks. TTM objects could really be replaced by gem objects with the bo-specific part stripped, as discussed above. And then there is the ttm lock to allow concurrent execbufs running. /Thomas > >> Thanks, >> /Thomas >> > Yours, Daniel > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/3] embed drm_gem_object into radeon_bo
@ 2010-11-15 10:20 Sedat Dilek
0 siblings, 0 replies; 14+ messages in thread
From: Sedat Dilek @ 2010-11-15 10:20 UTC (permalink / raw)
To: DRI; +Cc: daniel.vetter
Hi Daniel,
I have tried this patchset on a RV250 with linux-next (next-20101115)
in combination w/ patchset from "[PATCH 0/9] make struct drm_mm_node
embeddable" [1].
glxgears works nice.
2nd test-case is Eric Anholt's OpenArena benchmark.
The screen gets blank and system is unusable (cold start, poweroff-button).
Mesa is from master GIT branch:
$ cd ~/src/mesa
$ grep -A4 "git log" mesa.log
+ git log --pretty=short -1
commit 9cf25b3d1cd2910ae33e1faafa04629638bff0fe
Author: Marek Olšák <maraeo@gmail.com>
r300g: return shader caps from Draw for SWTCL vertex shaders
Daniel requested me to bisect:
bad: 3-3-drm-radeon-kill-radeon_bo--gobj-pointer.patch +
2-3-drm-radeon-introduce-gem_to_radeon_bo-helper.patch
good: 1-3-drm-radeon-embed-struct-drm_gem_object.patch
$cd ~/src/linux-2.6/linux-2.6.37-rc1/debian/build/source_i386_none
$ cat .pc/applied-patches
danvet-embed-drm_gem_object-into-radeon_bo/1-3-drm-radeon-embed-struct-drm_gem_object.patch
Looks like patch #2 is culprit according to Daniel.
Kind Regards,
- Sedat -
[1] http://lists.freedesktop.org/archives/dri-devel/2010-November/005420.html
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 0/3] embed drm_gem_object into radeon_bo
@ 2010-11-16 17:05 Sedat Dilek
2010-11-16 17:30 ` Daniel Vetter
0 siblings, 1 reply; 14+ messages in thread
From: Sedat Dilek @ 2010-11-16 17:05 UTC (permalink / raw)
To: DRI; +Cc: daniel.vetter, Arnd Bergmann
[ CCing Arnd Bergmann ]
Hi,
I have tested both patchsets from Daniel (see [1] and [2]) again on a
Radeon RV250 in a none-BKL-config and it looks like
agd5f-pflip/0002-drm-radeon-kms-add-pageflip-ioctl-support.patch
is the culprit in combination with the below listed drm patches.
I have switched to a "normal" DDX (w/o pageflip-support).
The OpenArena benchmarks is now between 17.5 - 18.6 [fps] @1024x768 resolution.
( w/o below patchset: 840 frames 50.6 seconds 16.6 fps 12.0/60.2/267.0/21.3 ms )
Kind Regards,
- Sedat -
[1] http://lists.freedesktop.org/archives/dri-devel/2010-November/005420.html
[2] http://lists.freedesktop.org/archives/dri-devel/2010-November/005441.html
$ cd $HOME/src/linux-2.6/linux-2.6.37-rc2/debian/build/source_i386_none/
$ cat .pc/applied-patches
danvet-drm-for-sedat-dilek/0001-drm-nouveau-don-t-munge-in-drm_mm-internals.patch
danvet-drm-for-sedat-dilek/0002-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
danvet-drm-for-sedat-dilek/0003-drm-mm-track-free-areas-implicitly.patch
danvet-drm-for-sedat-dilek/0004-drm-mm-extract-node-insert-helper-functions.patch
danvet-drm-for-sedat-dilek/0005-drm-mm-add-api-for-embedding-struct-drm_mm_node.patch
danvet-drm-for-sedat-dilek/0006-drm-mm-add-helper-to-unwind-scan-state.patch
danvet-embed-drm_gem_object-into-radeon_bo/1-3-drm-radeon-embed-struct-drm_gem_object.patch
danvet-embed-drm_gem_object-into-radeon_bo/2-3-drm-radeon-introduce-gem_to_radeon_bo-helper.patch
danvet-embed-drm_gem_object-into-radeon_bo/3-3-drm-radeon-kill-radeon_bo--gobj-pointer.patch
drm-vblank-timestamping/0001-drm-vblank-Add-support-for-precise-vblank-timestampi.patch
drm-vblank-timestamping/0002-drm-radeon-Add-support-for-precise-vblank-timestampi.patch
for-drm-radeon-testing/drm-radeon-kms-enable-writeback-on-radeon-AGP-boards.patch
$ cd $HOME/src/mesa/
$ ./scripts/run_openarena-benchmark.sh
840 frames 46.5 seconds 18.1 fps 10.0/55.3/147.0/18.9 ms
$ grep OK LATEST_linux-2.6/logs/setup_linux-2.6_git0.sd.1.log
(+) OK bkl-config/0002-drm-i810-remove-the-BKL.patch
(+) OK bkl-config/0003-staging-stradis-mark-as-depends-on-BKL.patch
(+) OK bkl-config/0004-BKL-remove-extraneous-include-smp_lock.h.patch
(+) OK bkl-config/0005-BKL-remove-references-to-lock_kernel-from-comments.patch
(+) OK bkl-config/0006-BKL-disable-by-default.patch
(+) OK bkl-config/0007-BKL-mark-lock_kernel-as-deprecated.patch
(+) OK bkl-config/0008-BKL-move-CONFIG_BKL-to-staging.patch
(+) OK debian/version.patch
(+) OK debian/kernelvariables-2.6.37.patch
(+) OK debian/doc-build-parallel.patch
(+) OK bugfix/ia64/hardcode-arch-script-output.patch
(+) OK bugfix/mips/disable-advansys.patch
(+) OK bugfix/arm/disable-scsi_acard.patch
(+) OK debian/mips-disable-werror.patch
(+) OK bugfix/powerpc/lpar-console.patch
(+) OK features/all/i915-autoload-without-CONFIG_DRM_I915_KMS.patch
(+) OK debian/arch-sh4-fix-uimage-build.patch
(+) OK bugfix/mips/mips-ide-flush-dcache.patch
(+) OK bugfix/all/qla4xxx-Fix-build-on-some-architectures-lacking-64-bit-I-O.patch
(+) OK bugfix/x86/Skip-looking-for-ioapic-overrides-when-ioapics-are-not-present.patch
( NOTE: bkl-config/0001-preempt-fix-kernel-build-with-CONFIG_BKL.patch
is already in Linux 2.6.37-rc2 )
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 0/3] embed drm_gem_object into radeon_bo 2010-11-16 17:05 Sedat Dilek @ 2010-11-16 17:30 ` Daniel Vetter 2010-11-16 19:37 ` Sedat Dilek 0 siblings, 1 reply; 14+ messages in thread From: Daniel Vetter @ 2010-11-16 17:30 UTC (permalink / raw) To: sedat.dilek; +Cc: daniel.vetter, Arnd Bergmann, DRI On Tue, Nov 16, 2010 at 06:05:25PM +0100, Sedat Dilek wrote: > I have tested both patchsets from Daniel (see [1] and [2]) again on a > Radeon RV250 in a none-BKL-config and it looks like > > agd5f-pflip/0002-drm-radeon-kms-add-pageflip-ioctl-support.patch > > is the culprit in combination with the below listed drm patches. Likely a gem_bo->driver_private access. My patches set this to NULL to catch conversion bugs. -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/3] embed drm_gem_object into radeon_bo 2010-11-16 17:30 ` Daniel Vetter @ 2010-11-16 19:37 ` Sedat Dilek 2010-11-16 19:54 ` Sedat Dilek 0 siblings, 1 reply; 14+ messages in thread From: Sedat Dilek @ 2010-11-16 19:37 UTC (permalink / raw) To: Daniel Vetter; +Cc: daniel.vetter, Arnd Bergmann, DRI [-- Attachment #1: Type: text/plain, Size: 2280 bytes --] On Tue, Nov 16, 2010 at 6:30 PM, Daniel Vetter <daniel@ffwll.ch> wrote: > On Tue, Nov 16, 2010 at 06:05:25PM +0100, Sedat Dilek wrote: >> I have tested both patchsets from Daniel (see [1] and [2]) again on a >> Radeon RV250 in a none-BKL-config and it looks like >> >> agd5f-pflip/0002-drm-radeon-kms-add-pageflip-ioctl-support.patch >> >> is the culprit in combination with the below listed drm patches. > Likely a gem_bo->driver_private access. My patches set this to NULL to > catch conversion bugs. > -Daniel > -- > Daniel Vetter > Mail: daniel@ffwll.ch > Mobile: +41 (0)79 365 57 48 > [ CCing Alex Deucher ] With the attached diff to the original patch from [1], OpenArena works with pageflip-support for radeon-KMS. Unfortunately, there is a drop in fps from 18.5 down to 13.5. - Sedat - [1] http://people.freedesktop.org/~agd5f/pflip/0002-drm-radeon-kms-add-pageflip-ioctl-support.patch $ cd ~/src/linux-2.6/linux-2.6.37-rc2/debian/build/source_i386_none/ $ cat .pc/applied-patches danvet-drm-for-sedat-dilek/0001-drm-nouveau-don-t-munge-in-drm_mm-internals.patch danvet-drm-for-sedat-dilek/0002-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch danvet-drm-for-sedat-dilek/0003-drm-mm-track-free-areas-implicitly.patch danvet-drm-for-sedat-dilek/0004-drm-mm-extract-node-insert-helper-functions.patch danvet-drm-for-sedat-dilek/0005-drm-mm-add-api-for-embedding-struct-drm_mm_node.patch danvet-drm-for-sedat-dilek/0006-drm-mm-add-helper-to-unwind-scan-state.patch danvet-embed-drm_gem_object-into-radeon_bo/1-3-drm-radeon-embed-struct-drm_gem_object.patch danvet-embed-drm_gem_object-into-radeon_bo/2-3-drm-radeon-introduce-gem_to_radeon_bo-helper.patch danvet-embed-drm_gem_object-into-radeon_bo/3-3-drm-radeon-kill-radeon_bo--gobj-pointer.patch drm-vblank-timestamping/0001-drm-vblank-Add-support-for-precise-vblank-timestampi.patch drm-vblank-timestamping/0002-drm-radeon-Add-support-for-precise-vblank-timestampi.patch for-drm-radeon-testing/drm-radeon-kms-enable-writeback-on-radeon-AGP-boards.patch agd5f-pflip/0002-drm-radeon-kms-add-pageflip-ioctl-support-for-danvet-v2.patch $ cd ~/src/mesa/ $ ./scripts/run_openarena-benchmark.sh 840 frames 62.6 seconds 13.4 fps 16.0/74.5/224.0/19.7 ms [-- Attachment #2: agd5f-pflip.diff --] [-- Type: text/x-diff, Size: 841 bytes --] diff -Naur 0002-drm-radeon-kms-add-pageflip-ioctl-support.patch 0002-drm-radeon-kms-add-pageflip-ioctl-support-for-danvet-v2.patch --- 0002-drm-radeon-kms-add-pageflip-ioctl-support.patch 2010-10-31 18:53:38.000000000 +0100 +++ 0002-drm-radeon-kms-add-pageflip-ioctl-support-for-danvet-v2.patch 2010-11-16 20:07:12.380393000 +0100 @@ -1319,7 +1319,7 @@ + new_radeon_fb = to_radeon_framebuffer(fb); + /* schedule unpin of the old buffer */ + obj = old_radeon_fb->obj; -+ rbo = obj->driver_private; ++ rbo = gem_to_radeon_bo(obj); + work->old_rbo = rbo; + INIT_WORK(&work->work, radeon_unpin_work_func); + @@ -1338,7 +1338,7 @@ + + /* pin the new buffer */ + obj = new_radeon_fb->obj; -+ rbo = obj->driver_private; ++ rbo = gem_to_radeon_bo(obj); + r = radeon_bo_reserve(rbo, false); + if (unlikely(r != 0)) + goto pflip_cleanup; [-- Attachment #3: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/3] embed drm_gem_object into radeon_bo 2010-11-16 19:37 ` Sedat Dilek @ 2010-11-16 19:54 ` Sedat Dilek 0 siblings, 0 replies; 14+ messages in thread From: Sedat Dilek @ 2010-11-16 19:54 UTC (permalink / raw) To: Daniel Vetter; +Cc: daniel.vetter, Arnd Bergmann, DRI [-- Attachment #1: Type: text/plain, Size: 2532 bytes --] On Tue, Nov 16, 2010 at 8:37 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: > On Tue, Nov 16, 2010 at 6:30 PM, Daniel Vetter <daniel@ffwll.ch> wrote: >> On Tue, Nov 16, 2010 at 06:05:25PM +0100, Sedat Dilek wrote: >>> I have tested both patchsets from Daniel (see [1] and [2]) again on a >>> Radeon RV250 in a none-BKL-config and it looks like >>> >>> agd5f-pflip/0002-drm-radeon-kms-add-pageflip-ioctl-support.patch >>> >>> is the culprit in combination with the below listed drm patches. >> Likely a gem_bo->driver_private access. My patches set this to NULL to >> catch conversion bugs. >> -Daniel >> -- >> Daniel Vetter >> Mail: daniel@ffwll.ch >> Mobile: +41 (0)79 365 57 48 >> > > [ CCing Alex Deucher ] > > With the attached diff to the original patch from [1], OpenArena works > with pageflip-support for radeon-KMS. > Unfortunately, there is a drop in fps from 18.5 down to 13.5. > > - Sedat - > > [1] http://people.freedesktop.org/~agd5f/pflip/0002-drm-radeon-kms-add-pageflip-ioctl-support.patch > > $ cd ~/src/linux-2.6/linux-2.6.37-rc2/debian/build/source_i386_none/ > > $ cat .pc/applied-patches > danvet-drm-for-sedat-dilek/0001-drm-nouveau-don-t-munge-in-drm_mm-internals.patch > danvet-drm-for-sedat-dilek/0002-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch > danvet-drm-for-sedat-dilek/0003-drm-mm-track-free-areas-implicitly.patch > danvet-drm-for-sedat-dilek/0004-drm-mm-extract-node-insert-helper-functions.patch > danvet-drm-for-sedat-dilek/0005-drm-mm-add-api-for-embedding-struct-drm_mm_node.patch > danvet-drm-for-sedat-dilek/0006-drm-mm-add-helper-to-unwind-scan-state.patch > danvet-embed-drm_gem_object-into-radeon_bo/1-3-drm-radeon-embed-struct-drm_gem_object.patch > danvet-embed-drm_gem_object-into-radeon_bo/2-3-drm-radeon-introduce-gem_to_radeon_bo-helper.patch > danvet-embed-drm_gem_object-into-radeon_bo/3-3-drm-radeon-kill-radeon_bo--gobj-pointer.patch > drm-vblank-timestamping/0001-drm-vblank-Add-support-for-precise-vblank-timestampi.patch > drm-vblank-timestamping/0002-drm-radeon-Add-support-for-precise-vblank-timestampi.patch > for-drm-radeon-testing/drm-radeon-kms-enable-writeback-on-radeon-AGP-boards.patch > agd5f-pflip/0002-drm-radeon-kms-add-pageflip-ioctl-support-for-danvet-v2.patch > > $ cd ~/src/mesa/ > > $ ./scripts/run_openarena-benchmark.sh > 840 frames 62.6 seconds 13.4 fps 16.0/74.5/224.0/19.7 ms > Attached are all the patches I used with quilt-series file and kernel-config. - Sedat - [-- Attachment #2: for-danvet_patches.tar.xz --] [-- Type: application/octet-stream, Size: 39512 bytes --] [-- Attachment #3: for-danvet_patches.tar.xz.sha256sum --] [-- Type: application/octet-stream, Size: 92 bytes --] 626533723a3828b5d54303216fe81e5e28bb9fa8a5b30dd9cd1fb63d37df04ed for-danvet_patches.tar.xz [-- Attachment #4: bkl-config.tar.xz --] [-- Type: application/octet-stream, Size: 40432 bytes --] [-- Attachment #5: bkl-config.tar.xz.sha256sum --] [-- Type: application/octet-stream, Size: 84 bytes --] e8ccf66b3eda0a33c87bf025491493a7600a3234c7ce0db77a8856faeb818157 bkl-config.tar.xz [-- Attachment #6: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 0/3] embed drm_gem_object into radeon_bo @ 2010-11-27 9:47 Daniel Vetter 0 siblings, 0 replies; 14+ messages in thread From: Daniel Vetter @ 2010-11-27 9:47 UTC (permalink / raw) To: airlied; +Cc: Daniel Vetter, dri-devel Hi Dave, As promised rebased on top of latest drm-next to resolve a conflict the pageflipping code. Tested on my agp rv570. Please review and consider merging for -next. Thanks, Daniel Daniel Vetter (3): drm/radeon: embed struct drm_gem_object drm/radeon: introduce gem_to_radeon_bo helper drm/radeon: kill radeon_bo->gobj pointer drivers/gpu/drm/radeon/atombios_crtc.c | 8 ++-- drivers/gpu/drm/radeon/evergreen_blit_kms.c | 2 +- drivers/gpu/drm/radeon/r600.c | 2 +- drivers/gpu/drm/radeon/r600_blit_kms.c | 2 +- drivers/gpu/drm/radeon/radeon.h | 3 +- drivers/gpu/drm/radeon/radeon_benchmark.c | 4 +- drivers/gpu/drm/radeon/radeon_cs.c | 2 +- drivers/gpu/drm/radeon/radeon_device.c | 4 +- drivers/gpu/drm/radeon/radeon_display.c | 4 +- drivers/gpu/drm/radeon/radeon_fb.c | 10 +++--- drivers/gpu/drm/radeon/radeon_gart.c | 2 +- drivers/gpu/drm/radeon/radeon_gem.c | 43 ++++++++++++--------------- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 4 +- drivers/gpu/drm/radeon/radeon_object.c | 24 +++++++-------- drivers/gpu/drm/radeon/radeon_object.h | 7 ++-- drivers/gpu/drm/radeon/radeon_ring.c | 4 +- drivers/gpu/drm/radeon/radeon_test.c | 4 +- drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- drivers/gpu/drm/radeon/rv770.c | 2 +- 19 files changed, 63 insertions(+), 70 deletions(-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 0/3] embed drm_gem_object into radeon_bo
@ 2010-11-28 0:29 Sedat Dilek
0 siblings, 0 replies; 14+ messages in thread
From: Sedat Dilek @ 2010-11-28 0:29 UTC (permalink / raw)
To: daniel.vetter, DRI
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:
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Unfortunately, with
drm-radeon-kms-improve-pflip-precision-on-r1xx-r4xx.patch from [1] in
addition and running Eric Anholt's OpenArena benchmark... it is really
smoother with pflip now but after benchmark I cannot return to
desktop.
That is a problem not of your patchset, Daniel. I already reported on
IRC to Alex.
Hope to see also your embed-gtt-space patchset soonish in drm-next (I
have still the patches from [2] in my kernel patch-series).
Kind Regards,
- Sedat -
[1] https://patchwork.kernel.org/patch/348981/
[2] http://cgit.freedesktop.org/~danvet/drm/log/?h=for-sedat-dilek
$ cd src/linux-2.6/linux-2.6.37-rc3/debian/build/source_i386_none/
$ cat .pc/applied-patches
danvet-embed-drm_gem_object-into-radeon_bo/1-3-drm-radeon-embed-struct-drm_gem_object.patch
danvet-embed-drm_gem_object-into-radeon_bo/2-3-drm-radeon-introduce-gem_to_radeon_bo-helper.patch
danvet-embed-drm_gem_object-into-radeon_bo/3-3-drm-radeon-kill-radeon_bo--gobj-pointer.patch
$ ls -l patches/danvet-embed-drm_gem_object-into-radeon_bo/insgesamt 32
-rw-r--r-- 1 sd sd 12520 28. Nov 00:51
1-3-drm-radeon-embed-struct-drm_gem_object.patch
-rw-r--r-- 1 sd sd 11560 28. Nov 00:53
2-3-drm-radeon-introduce-gem_to_radeon_bo-helper.patch
-rw-r--r-- 1 sd sd 2556 28. Nov 00:53
3-3-drm-radeon-kill-radeon_bo--gobj-pointer.patch
^ permalink raw reply [flat|nested] 14+ messages in threadend of thread, other threads:[~2010-11-28 0:29 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-11-13 20:57 [PATCH 0/3] embed drm_gem_object into radeon_bo Daniel Vetter 2010-11-13 20:57 ` [PATCH 1/3] drm/radeon: embed struct drm_gem_object Daniel Vetter 2010-11-13 20:57 ` [PATCH 2/3] drm/radeon: introduce gem_to_radeon_bo helper Daniel Vetter 2010-11-13 20:57 ` [PATCH 3/3] drm/radeon: kill radeon_bo->gobj pointer Daniel Vetter 2010-11-15 7:25 ` [PATCH 0/3] embed drm_gem_object into radeon_bo Thomas Hellstrom 2010-11-15 18:45 ` Daniel Vetter 2010-11-15 20:48 ` Thomas Hellstrom 2010-11-15 10:20 Sedat Dilek 2010-11-16 17:05 Sedat Dilek 2010-11-16 17:30 ` Daniel Vetter 2010-11-16 19:37 ` Sedat Dilek 2010-11-16 19:54 ` Sedat Dilek 2010-11-27 9:47 Daniel Vetter 2010-11-28 0:29 Sedat Dilek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).