dri-devel September 2014

dri-devel@lists.freedesktop.org

173 participants
1045 discussions

Using a HD 4670 still possible?
by Christoph Brill 17 Sep '14

17 Sep '14

Hi list, I'm currently trying to get a HD 4670 aka RV730 XT to work against X.org 1.16, xf86-video-ati 7.4.0 on a Linux 3.16.1. Can anyone tell me: Should this card be able to handle an average Gnome desktop? The problem was: 3D rendering did not work at all. Starting gdm lead to hanging Xorg. Calling glxgears on a twm session just rendered a black window, which stayed even if the process was killed by CTRL+C. I managed to get glxgears do do its job by setting "vblank_mode=0". I guessed my card does not like to play along with vsync at all. So I went ahead to disable vsyncing (tearing is still better than no display at all). Setting it globally in /etc/drirc seems to get glxgears running. Testing Xonotic on twm showed, that the card was now able to handle 3D. But: gdm still was extremely sluggish and eventually froze. Starting gnome-shell directly from startx gets me to the desktop, but any action freezes the process. Is there still hope for this card or should I get rid of it? Best wishes, Christoph

4 5

[PATCH] drm/radeon: fix AGP userptr handling
by Christian König 17 Sep '14

17 Sep '14

From: Christian König <christian.koenig(a)amd.com> AGP mappings are not cache coherent, so userptr support won't work. Additional to that the AGP implementation uses a different ttm_tt container structure so we run into problems if we cast the pointer without checking if it's the right type. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/radeon/radeon_ttm.c | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index eca2ce6..d73ea9c 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -675,10 +675,17 @@ static struct ttm_tt *radeon_ttm_tt_create(struct ttm_bo_device *bdev, return &gtt->ttm.ttm; } +static struct radeon_ttm_tt *radeon_ttm_tt_to_gtt(struct ttm_tt *ttm) +{ + if (!ttm || ttm->func != &radeon_backend_func) + return NULL; + return (struct radeon_ttm_tt *)ttm; +} + static int radeon_ttm_tt_populate(struct ttm_tt *ttm) { + struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm); struct radeon_device *rdev; - struct radeon_ttm_tt *gtt = (void *)ttm; unsigned i; int r; bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG); @@ -686,7 +693,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm) if (ttm->state != tt_unpopulated) return 0; - if (gtt->userptr) { + if (gtt && gtt->userptr) { ttm->sg = kcalloc(1, sizeof(struct sg_table), GFP_KERNEL); if (!ttm->sg) return -ENOMEM; @@ -741,11 +748,11 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm) static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm) { struct radeon_device *rdev; - struct radeon_ttm_tt *gtt = (void *)ttm; + struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm); unsigned i; bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG); - if (gtt->userptr) { + if (gtt && gtt->userptr) { kfree(ttm->sg); ttm->page_flags &= ~TTM_PAGE_FLAG_SG; return; @@ -782,7 +789,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm) int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr, uint32_t flags) { - struct radeon_ttm_tt *gtt = (void *)ttm; + struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm); if (gtt == NULL) return -EINVAL; @@ -795,7 +802,7 @@ int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr, bool radeon_ttm_tt_has_userptr(struct ttm_tt *ttm) { - struct radeon_ttm_tt *gtt = (void *)ttm; + struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm); if (gtt == NULL) return false; @@ -805,7 +812,7 @@ bool radeon_ttm_tt_has_userptr(struct ttm_tt *ttm) bool radeon_ttm_tt_is_readonly(struct ttm_tt *ttm) { - struct radeon_ttm_tt *gtt = (void *)ttm; + struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm); if (gtt == NULL) return false; -- 1.8.3.2

2 1

radeon/radeon_bios.c: clean up coding style differences in radeon_get_bios()
by Wilfried Klaebe 17 Sep '14

17 Sep '14

radeon/radeon_bios.c: clean up coding style differences in radeon_get_bios() Signed-off-by: Wilfried Klaebe <w-lkml(a)lebenslange-mailadresse.de> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c index 6a03624..63ccb8f 100644 --- a/drivers/gpu/drm/radeon/radeon_bios.c +++ b/drivers/gpu/drm/radeon/radeon_bios.c @@ -658,12 +658,10 @@ bool radeon_get_bios(struct radeon_device *rdev) r = igp_read_bios_from_vram(rdev); if (r == false) r = radeon_read_bios(rdev); - if (r == false) { + if (r == false) r = radeon_read_disabled_bios(rdev); - } - if (r == false) { + if (r == false) r = radeon_read_platform_bios(rdev); - } if (r == false || rdev->bios == NULL) { DRM_ERROR("Unable to locate a BIOS ROM\n"); rdev->bios = NULL;

1 0

[Bug 82588] New: X fails to start with linus-tip or drm-next
by bugzilla-daemon＠freedesktop.org 17 Sep '14

17 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=82588 Priority: medium Bug ID: 82588 Assignee: dri-devel(a)lists.freedesktop.org Summary: X fails to start with linus-tip or drm-next Severity: normal Classification: Unclassified OS: All Reporter: mike(a)fireburn.co.uk Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI Created attachment 104590 --> https://bugs.freedesktop.org/attachment.cgi?id=104590&action=edit DRM Next I've not had a chance to diagnose this issue yet or bisect -- You are receiving this mail because: You are the assignee for the bug.

1 27

[PATCH] drm/radeon: Disable HDP flush before every CS again for < r600
by Michel Dänzer 17 Sep '14

17 Sep '14

From: Michel Dänzer <michel.daenzer(a)amd.com> It was causing display corruption with R300 generation GPUs at least. Reported-and-Tested-by: Mikael Pettersson <mikpelinux(a)gmail.com> Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com> --- drivers/gpu/drm/radeon/r100.c | 28 ++++++++++++++-------------- drivers/gpu/drm/radeon/radeon_asic.c | 2 -- drivers/gpu/drm/radeon/radeon_asic.h | 3 +-- drivers/gpu/drm/radeon/radeon_drv.c | 2 +- 4 files changed, 16 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 4c5ec44..b0098e7 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -821,6 +821,20 @@ u32 r100_get_vblank_counter(struct radeon_device *rdev, int crtc) return RREG32(RADEON_CRTC2_CRNT_FRAME); } +/** + * r100_ring_hdp_flush - flush Host Data Path via the ring buffer + * rdev: radeon device structure + * ring: ring buffer struct for emitting packets + */ +static void r100_ring_hdp_flush(struct radeon_device *rdev, struct radeon_ring *ring) +{ + radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0)); + radeon_ring_write(ring, rdev->config.r100.hdp_cntl | + RADEON_HDP_READ_BUFFER_INVALIDATE); + radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0)); + radeon_ring_write(ring, rdev->config.r100.hdp_cntl); +} + /* Who ever call radeon_fence_emit should call ring_lock and ask * for enough space (today caller are ib schedule and buffer move) */ void r100_fence_ring_emit(struct radeon_device *rdev, @@ -1056,20 +1070,6 @@ void r100_gfx_set_wptr(struct radeon_device *rdev, (void)RREG32(RADEON_CP_RB_WPTR); } -/** - * r100_ring_hdp_flush - flush Host Data Path via the ring buffer - * rdev: radeon device structure - * ring: ring buffer struct for emitting packets - */ -void r100_ring_hdp_flush(struct radeon_device *rdev, struct radeon_ring *ring) -{ - radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0)); - radeon_ring_write(ring, rdev->config.r100.hdp_cntl | - RADEON_HDP_READ_BUFFER_INVALIDATE); - radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0)); - radeon_ring_write(ring, rdev->config.r100.hdp_cntl); -} - static void r100_cp_load_microcode(struct radeon_device *rdev) { const __be32 *fw_data; diff --git a/drivers/gpu/drm/radeon/radeon_asic.c b/drivers/gpu/drm/radeon/radeon_asic.c index eeeeabe..2dd5847 100644 --- a/drivers/gpu/drm/radeon/radeon_asic.c +++ b/drivers/gpu/drm/radeon/radeon_asic.c @@ -185,7 +185,6 @@ static struct radeon_asic_ring r100_gfx_ring = { .get_rptr = &r100_gfx_get_rptr, .get_wptr = &r100_gfx_get_wptr, .set_wptr = &r100_gfx_set_wptr, - .hdp_flush = &r100_ring_hdp_flush, }; static struct radeon_asic r100_asic = { @@ -332,7 +331,6 @@ static struct radeon_asic_ring r300_gfx_ring = { .get_rptr = &r100_gfx_get_rptr, .get_wptr = &r100_gfx_get_wptr, .set_wptr = &r100_gfx_set_wptr, - .hdp_flush = &r100_ring_hdp_flush, }; static struct radeon_asic r300_asic = { diff --git a/drivers/gpu/drm/radeon/radeon_asic.h b/drivers/gpu/drm/radeon/radeon_asic.h index 275a5dc..7756bc1 100644 --- a/drivers/gpu/drm/radeon/radeon_asic.h +++ b/drivers/gpu/drm/radeon/radeon_asic.h @@ -148,8 +148,7 @@ u32 r100_gfx_get_wptr(struct radeon_device *rdev, struct radeon_ring *ring); void r100_gfx_set_wptr(struct radeon_device *rdev, struct radeon_ring *ring); -void r100_ring_hdp_flush(struct radeon_device *rdev, - struct radeon_ring *ring); + /* * r200,rv250,rs300,rv280 */ diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index a773830..ef5b60a 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -83,7 +83,7 @@ * CIK: 1D and linear tiling modes contain valid PIPE_CONFIG * 2.39.0 - Add INFO query for number of active CUs * 2.40.0 - Add RADEON_GEM_GTT_WC/UC, flush HDP cache before submitting - * CS to GPU + * CS to GPU on >= r600 */ #define KMS_DRIVER_MAJOR 2 #define KMS_DRIVER_MINOR 40 -- 2.1.0

2 1

[Bug 82828] New: Regression: Crash in 3Dmark2001
by bugzilla-daemon＠freedesktop.org 17 Sep '14

17 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=82828 Priority: medium Bug ID: 82828 Assignee: dri-devel(a)lists.freedesktop.org Summary: Regression: Crash in 3Dmark2001 Severity: normal Classification: Unclassified OS: All Reporter: stefandoesinger(a)gmx.at Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa Created attachment 104921 --> https://bugs.freedesktop.org/attachment.cgi?id=104921&action=edit Backtrace Since commit e78a01d5e6f77e075fe667a0f0ccb10d89c0dd58 3DMark2001 crashes in the Nature test when it is run in Wine with the ARB shader backend on r300g. The 3DMark2001 download can be found here: http://www.futuremark.com/benchmarks/legacy I used Wine 1.7.22 for testing, but I am certain that the bug can be reproduced with newer Wine releases because the ARB shader code hasn't been changed in a white. My GPU is a Radeon X1600. To reproduce the bug you have to enable the ARB shader backend by starting Wine's regedit and setting HKEY_CURRENT_USER/Software/Wine/Direct3D/UseGLSL to disabled. Create the Direct3D key and UseGLSL string value if needed. I do not see the crash on r600g (Tested with 9a071e33, Radeon HD 5770). A backtrace is attached. The backtrace was generated with Mesa 1c4f141a. -- You are receiving this mail because: You are the assignee for the bug.

1 24

[PATCH 0/9] drm/exynos: initialization/deinitialization fixes
by Andrzej Hajda 17 Sep '14

17 Sep '14

This set of patches contains fixes of initialization and deinitialization code of exynos_drm core and components. It is based on exynos-drm-next branch. Patchset has been tested on trats and universal_c210 platforms. Regards Andrzej Andrzej Hajda (9): drm/exynos/ipp: traverse ipp drivers list safely drm/exynos: fix drm driver de-initialization order drm/exynos/fbdev: fix fbdev gem object cleanup drm/exynos/fb: free exynos framebuffer on error drm/exynos/crtc: fix framebuffer reference sequence drm/exynos/dsi: unregister connector on removal drm/exynos/dpi: unregister connector and panel on removal drm/exynos/dp: unregister connector on removal drm/exynos/hdmi: unregister connector on removal drivers/gpu/drm/exynos/exynos_dp_core.c | 4 +++- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++++++ drivers/gpu/drm/exynos/exynos_drm_dpi.c | 6 +++++- drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 ++++---- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 ++++++--- drivers/gpu/drm/exynos/exynos_drm_fb.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 ++-- drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +++- 9 files changed, 30 insertions(+), 15 deletions(-) -- 1.9.1

3 18

Re: [Intel-gfx] [PATCH] intel: Add support for userptr objects
by Damien Lespiau 17 Sep '14

17 Sep '14

On Thu, Jun 19, 2014 at 03:52:03PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> > > Allow userptr objects to be created and used via libdrm_intel. > > At the moment tiling and mapping to GTT aperture is not supported > due hardware limitations across different generations and uncertainty > about its usefulness. > > v2: Improved error handling in feature detection per review comments. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> > --- Reviewed-by: Damien Lespiau <damien.lespiau(a)intel.com> Pushed a slightly modified version of this patch as libdrm now has explicit symbol visibility. -- Damien > intel/intel_bufmgr.c | 13 ++++ > intel/intel_bufmgr.h | 5 ++ > intel/intel_bufmgr_gem.c | 163 +++++++++++++++++++++++++++++++++++++++++++++- > intel/intel_bufmgr_priv.h | 12 +++- > 4 files changed, 191 insertions(+), 2 deletions(-) > > diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c > index 905556f..7f3d795 100644 > --- a/intel/intel_bufmgr.c > +++ b/intel/intel_bufmgr.c > @@ -60,6 +60,19 @@ drm_intel_bo *drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr, > return bufmgr->bo_alloc_for_render(bufmgr, name, size, alignment); > } > > +drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr, > + const char *name, void *addr, > + uint32_t tiling_mode, > + uint32_t stride, > + unsigned long size, > + unsigned long flags) > +{ > + if (bufmgr->bo_alloc_userptr) > + return bufmgr->bo_alloc_userptr(bufmgr, name, addr, tiling_mode, > + stride, size, flags); > + return NULL; > +} > + > drm_intel_bo * > drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name, > int x, int y, int cpp, uint32_t *tiling_mode, > diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h > index 9383c72..be83a56 100644 > --- a/intel/intel_bufmgr.h > +++ b/intel/intel_bufmgr.h > @@ -113,6 +113,11 @@ drm_intel_bo *drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr, > const char *name, > unsigned long size, > unsigned int alignment); > +drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr, > + const char *name, > + void *addr, uint32_t tiling_mode, > + uint32_t stride, unsigned long size, > + unsigned long flags); > drm_intel_bo *drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, > const char *name, > int x, int y, int cpp, > diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c > index 007a6d8..6dd3986 100644 > --- a/intel/intel_bufmgr_gem.c > +++ b/intel/intel_bufmgr_gem.c > @@ -182,6 +182,11 @@ struct _drm_intel_bo_gem { > void *mem_virtual; > /** GTT virtual address for the buffer, saved across map/unmap cycles */ > void *gtt_virtual; > + /** > + * Virtual address of the buffer allocated by user, used for userptr > + * objects only. > + */ > + void *user_virtual; > int map_count; > drmMMListHead vma_list; > > @@ -221,6 +226,11 @@ struct _drm_intel_bo_gem { > bool idle; > > /** > + * Boolean of whether this buffer was allocated with userptr > + */ > + bool is_userptr; > + > + /** > * Size in bytes of this buffer and its relocation descendents. > * > * Used to avoid costly tree walking in > @@ -847,6 +857,80 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name, > tiling, stride); > } > > +static drm_intel_bo * > +drm_intel_gem_bo_alloc_userptr(drm_intel_bufmgr *bufmgr, > + const char *name, > + void *addr, > + uint32_t tiling_mode, > + uint32_t stride, > + unsigned long size, > + unsigned long flags) > +{ > + drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr; > + drm_intel_bo_gem *bo_gem; > + int ret; > + struct drm_i915_gem_userptr userptr; > + > + /* Tiling with userptr surfaces is not supported > + * on all hardware so refuse it for time being. > + */ > + if (tiling_mode != I915_TILING_NONE) > + return NULL; > + > + bo_gem = calloc(1, sizeof(*bo_gem)); > + if (!bo_gem) > + return NULL; > + > + bo_gem->bo.size = size; > + > + VG_CLEAR(userptr); > + userptr.user_ptr = (__u64)((unsigned long)addr); > + userptr.user_size = size; > + userptr.flags = flags; > + > + ret = drmIoctl(bufmgr_gem->fd, > + DRM_IOCTL_I915_GEM_USERPTR, > + &userptr); > + if (ret != 0) { > + DBG("bo_create_userptr: " > + "ioctl failed with user ptr %p size 0x%lx, " > + "user flags 0x%lx\n", addr, size, flags); > + free(bo_gem); > + return NULL; > + } > + > + bo_gem->gem_handle = userptr.handle; > + bo_gem->bo.handle = bo_gem->gem_handle; > + bo_gem->bo.bufmgr = bufmgr; > + bo_gem->is_userptr = true; > + bo_gem->bo.virtual = addr; > + /* Save the address provided by user */ > + bo_gem->user_virtual = addr; > + bo_gem->tiling_mode = I915_TILING_NONE; > + bo_gem->swizzle_mode = I915_BIT_6_SWIZZLE_NONE; > + bo_gem->stride = 0; > + > + DRMINITLISTHEAD(&bo_gem->name_list); > + DRMINITLISTHEAD(&bo_gem->vma_list); > + > + bo_gem->name = name; > + atomic_set(&bo_gem->refcount, 1); > + bo_gem->validate_index = -1; > + bo_gem->reloc_tree_fences = 0; > + bo_gem->used_as_reloc_target = false; > + bo_gem->has_error = false; > + bo_gem->reusable = false; > + > + drm_intel_bo_gem_set_in_aperture_size(bufmgr_gem, bo_gem); > + > + DBG("bo_create_userptr: " > + "ptr %p buf %d (%s) size %ldb, stride 0x%x, tile mode %d\n", > + addr, bo_gem->gem_handle, bo_gem->name, > + size, stride, tiling_mode); > + > + return &bo_gem->bo; > +} > + > /** > * Returns a drm_intel_bo wrapping the given buffer object handle. > * > @@ -1173,6 +1257,12 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable) > struct drm_i915_gem_set_domain set_domain; > int ret; > > + if (bo_gem->is_userptr) { > + /* Return the same user ptr */ > + bo->virtual = bo_gem->user_virtual; > + return 0; > + } > + > pthread_mutex_lock(&bufmgr_gem->lock); > > if (bo_gem->map_count++ == 0) > @@ -1241,6 +1331,9 @@ map_gtt(drm_intel_bo *bo) > drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo; > int ret; > > + if (bo_gem->is_userptr) > + return -EINVAL; > + > if (bo_gem->map_count++ == 0) > drm_intel_gem_bo_open_vma(bufmgr_gem, bo_gem); > > @@ -1385,13 +1478,18 @@ int drm_intel_gem_bo_map_unsynchronized(drm_intel_bo *bo) > > static int drm_intel_gem_bo_unmap(drm_intel_bo *bo) > { > - drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr; > + drm_intel_bufmgr_gem *bufmgr_gem; > drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo; > int ret = 0; > > if (bo == NULL) > return 0; > > + if (bo_gem->is_userptr) > + return 0; > + > + bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr; > + > pthread_mutex_lock(&bufmgr_gem->lock); > > if (bo_gem->map_count <= 0) { > @@ -1449,6 +1547,9 @@ drm_intel_gem_bo_subdata(drm_intel_bo *bo, unsigned long offset, > struct drm_i915_gem_pwrite pwrite; > int ret; > > + if (bo_gem->is_userptr) > + return -EINVAL; > + > VG_CLEAR(pwrite); > pwrite.handle = bo_gem->gem_handle; > pwrite.offset = offset; > @@ -1501,6 +1602,9 @@ drm_intel_gem_bo_get_subdata(drm_intel_bo *bo, unsigned long offset, > struct drm_i915_gem_pread pread; > int ret; > > + if (bo_gem->is_userptr) > + return -EINVAL; > + > VG_CLEAR(pread); > pread.handle = bo_gem->gem_handle; > pread.offset = offset; > @@ -2460,6 +2564,12 @@ drm_intel_gem_bo_set_tiling(drm_intel_bo *bo, uint32_t * tiling_mode, > drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo; > int ret; > > + /* Tiling with userptr surfaces is not supported > + * on all hardware so refuse it for time being. > + */ > + if (bo_gem->is_userptr) > + return -EINVAL; > + > /* Linear buffers have no stride. By ensuring that we only ever use > * stride 0 with linear buffers, we simplify our code. > */ > @@ -3181,6 +3291,53 @@ drm_intel_bufmgr_gem_set_aub_annotations(drm_intel_bo *bo, > bo_gem->aub_annotation_count = count; > } > > +static bool > +has_userptr(drm_intel_bufmgr_gem *bufmgr_gem) > +{ > + int ret; > + void *ptr; > + long pgsz; > + struct drm_i915_gem_userptr userptr; > + struct drm_gem_close close_bo; > + > + pgsz = sysconf(_SC_PAGESIZE); > + assert(pgsz > 0); > + > + ret = posix_memalign(&ptr, pgsz, pgsz); > + if (ret) { > + DBG("Failed to get a page (%ld) for userptr detection!\n", > + pgsz); > + return false; > + } > + > + memset(&userptr, 0, sizeof(userptr)); > + userptr.user_ptr = (__u64)(unsigned long)ptr; > + userptr.user_size = pgsz; > + > +retry: > + ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_USERPTR, &userptr); > + if (ret) { > + if (errno == ENODEV && userptr.flags == 0) { > + userptr.flags = I915_USERPTR_UNSYNCHRONIZED; > + goto retry; > + } > + free(ptr); > + return false; > + } > + > + close_bo.handle = userptr.handle; > + ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_GEM_CLOSE, &close_bo); > + if (ret == 0) { > + free(ptr); > + } else { > + fprintf(stderr, "Failed to release test userptr object! (%d) " > + "i915 kernel driver may not be sane!\n", errno); > + return false; > + } > + > + return true; > +} > + > /** > * Initializes the GEM buffer manager, which uses the kernel to allocate, map, > * and manage map buffer objections. > @@ -3273,6 +3430,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size) > ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp); > bufmgr_gem->has_relaxed_fencing = ret == 0; > > + if (has_userptr(bufmgr_gem)) > + bufmgr_gem->bufmgr.bo_alloc_userptr = > + drm_intel_gem_bo_alloc_userptr; > + > gp.param = I915_PARAM_HAS_WAIT_TIMEOUT; > ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp); > bufmgr_gem->has_wait_timeout = ret == 0; > diff --git a/intel/intel_bufmgr_priv.h b/intel/intel_bufmgr_priv.h > index 2592d42..3aa1abb 100644 > --- a/intel/intel_bufmgr_priv.h > +++ b/intel/intel_bufmgr_priv.h > @@ -60,7 +60,17 @@ struct _drm_intel_bufmgr { > const char *name, > unsigned long size, > unsigned int alignment); > - > + /** > + * Allocate a buffer object from an existing user accessible > + * address malloc'd with the provided size. > + * Alignment is used when mapping to the gtt. > + * Flags may be I915_VMAP_READ_ONLY or I915_USERPTR_UNSYNCHRONIZED > + */ > + drm_intel_bo *(*bo_alloc_userptr)(drm_intel_bufmgr *bufmgr, > + const char *name, void *addr, > + uint32_t tiling_mode, uint32_t stride, > + unsigned long size, > + unsigned long flags); > /** > * Allocate a tiled buffer object. > * > -- > 1.9.3 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx

1 0

[PATCH 0/9 linux-next] drivers/gpu/drm: use container_of where possible
by Fabian Frederick 17 Sep '14

17 Sep '14

Small patchset using container_of instead of casting on first structure member address. Fabian Frederick (9): drm/cirrus: use container_of to resolve cirrus_fbdev from drm_fb_helper drm/mgag200: use container_of to resolve mga_fbdev from drm_fb_helper drm/radeon: use container_of to resolve radeon_fbdev from drm_fb_helper drm/nouveau: use container_of to resolve nouveau_fbdev from drm_fb_helper drm/nouveau: use container_of to resolve nouveau_plane from drm_plane drm/qxl: use container_of to resolve qxl_fbdev from drm_fb_helper drm/gma500: use container_of to resolve psb_fbdev from drm_fb_helper drm/ast: use container_of to resolve ast_fbdev from drm_fb_helper drm/udl: use container_of to resolve udl_fbdev from drm_fb_helper drivers/gpu/drm/ast/ast_fb.c | 3 ++- drivers/gpu/drm/cirrus/cirrus_fbdev.c | 3 ++- drivers/gpu/drm/gma500/framebuffer.c | 3 ++- drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ++- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 15 ++++++++++----- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 ++- drivers/gpu/drm/qxl/qxl_fb.c | 3 ++- drivers/gpu/drm/radeon/radeon_fb.c | 3 ++- drivers/gpu/drm/udl/udl_fb.c | 3 ++- 9 files changed, 26 insertions(+), 13 deletions(-) -- 1.9.1

3 13

-next mostly closed, what have I missed?
by Dave Airlie 17 Sep '14

17 Sep '14

Okay so I'm pretty sure I'm close to not taking anything major for next, I'm not sure I've gotten an exynos tree yet, so hopefully that appears before -rc6, Please continue to send fixes for -next pulls, and I'm kinda open to new hw support depending on how intrusive it is to other code. Now we have a strange new time of a few weeks where maybe we should go fix some regressions or something! any other trees I've missed? Dave.

5 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2014