dri-devel January 2014

dri-devel@lists.freedesktop.org

145 participants
957 discussions

[Bug 35457] [rs690m] Graphics corruption with ati x1200
by bugzilla-daemon＠freedesktop.org 03 Jan '14

03 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #87 from Alex Deucher <agd5f(a)yahoo.com> --- (In reply to comment #86) > I tried the latest kernel 3.13 rc6 that includes this patch. Unfortunately, > this patch don't fix this problem. Please attach your dmesg output both with and without the patch. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 35457] [rs690m] Graphics corruption with ati x1200
by bugzilla-daemon＠freedesktop.org 03 Jan '14

03 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #86 from Programmist11180 <programmer11180(a)programist.ru> --- I tried the latest kernel 3.13 rc6 that includes this patch. Unfortunately, this patch don't fix this problem. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH 5/5] configure.ac: bump version to 2.4.51 for release
by Ben Widawsky 03 Jan '14

03 Jan '14

Provides the parameter for full PPGTT on Intel. Signed-off-by: Ben Widawsky <ben(a)bwidawsk.net> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index c5b8d40..d0d051a 100644 --- a/configure.ac +++ b/configure.ac @@ -20,7 +20,7 @@ AC_PREREQ([2.63]) AC_INIT([libdrm], - [2.4.50], + [2.4.51], [https://bugs.freedesktop.org/enter_bug.cgi?product=DRI], [libdrm]) -- 1.8.5.2

1 0

[PATCH 3/5] intel: Merge latest i915_drm.h
by Ben Widawsky 03 Jan '14

03 Jan '14

This was not done as a straight copy because reset_stats IOCTL landed in libdrm before upstream kernel. (We'll do a similar thing for full PPGTT anyway, so there isn't really a point in syncing exactly). Signed-off-by: Ben Widawsky <ben(a)bwidawsk.net> --- include/drm/i915_drm.h | 113 +++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 100 insertions(+), 13 deletions(-) diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h index c1914d6..2f4eb8c 100644 --- a/include/drm/i915_drm.h +++ b/include/drm/i915_drm.h @@ -27,12 +27,36 @@ #ifndef _I915_DRM_H_ #define _I915_DRM_H_ -#include "drm.h" +#include <drm.h> /* Please note that modifications to all structs defined here are * subject to backwards-compatibility constraints. */ +/** + * DOC: uevents generated by i915 on it's device node + * + * I915_L3_PARITY_UEVENT - Generated when the driver receives a parity mismatch + * event from the gpu l3 cache. Additional information supplied is ROW, + * BANK, SUBBANK, SLICE of the affected cacheline. Userspace should keep + * track of these events and if a specific cache-line seems to have a + * persistent error remap it with the l3 remapping tool supplied in + * intel-gpu-tools. The value supplied with the event is always 1. + * + * I915_ERROR_UEVENT - Generated upon error detection, currently only via + * hangcheck. The error detection event is a good indicator of when things + * began to go badly. The value supplied with the event is a 1 upon error + * detection, and a 0 upon reset completion, signifying no more error + * exists. NOTE: Disabling hangcheck or reset via module parameter will + * cause the related events to not be seen. + * + * I915_RESET_UEVENT - Event is generated just before an attempt to reset the + * the GPU. The value supplied with the event is always 1. NOTE: Disable + * reset via module parameter will cause this event to not be seen. + */ +#define I915_L3_PARITY_UEVENT "L3_PARITY_ERROR" +#define I915_ERROR_UEVENT "ERROR" +#define I915_RESET_UEVENT "RESET" /* Each region is a minimum of 16k, and there are at most 255 of them. */ @@ -195,8 +219,8 @@ typedef struct _drm_i915_sarea { #define DRM_I915_GEM_WAIT 0x2c #define DRM_I915_GEM_CONTEXT_CREATE 0x2d #define DRM_I915_GEM_CONTEXT_DESTROY 0x2e -#define DRM_I915_GEM_SET_CACHEING 0x2f -#define DRM_I915_GEM_GET_CACHEING 0x30 +#define DRM_I915_GEM_SET_CACHING 0x2f +#define DRM_I915_GEM_GET_CACHING 0x30 #define DRM_I915_REG_READ 0x31 #define DRM_I915_GET_RESET_STATS 0x32 @@ -223,8 +247,8 @@ typedef struct _drm_i915_sarea { #define DRM_IOCTL_I915_GEM_PIN DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_PIN, struct drm_i915_gem_pin) #define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin) #define DRM_IOCTL_I915_GEM_BUSY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_BUSY, struct drm_i915_gem_busy) -#define DRM_IOCTL_I915_GEM_SET_CACHEING DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_SET_CACHEING, struct drm_i915_gem_cacheing) -#define DRM_IOCTL_I915_GEM_GET_CACHEING DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHEING, struct drm_i915_gem_cacheing) +#define DRM_IOCTL_I915_GEM_SET_CACHING DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_SET_CACHING, struct drm_i915_gem_caching) +#define DRM_IOCTL_I915_GEM_GET_CACHING DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHING, struct drm_i915_gem_caching) #define DRM_IOCTL_I915_GEM_THROTTLE DRM_IO ( DRM_COMMAND_BASE + DRM_I915_GEM_THROTTLE) #define DRM_IOCTL_I915_GEM_ENTERVT DRM_IO(DRM_COMMAND_BASE + DRM_I915_GEM_ENTERVT) #define DRM_IOCTL_I915_GEM_LEAVEVT DRM_IO(DRM_COMMAND_BASE + DRM_I915_GEM_LEAVEVT) @@ -305,7 +329,14 @@ typedef struct drm_i915_irq_wait { #define I915_PARAM_HAS_LLC 17 #define I915_PARAM_HAS_ALIASING_PPGTT 18 #define I915_PARAM_HAS_WAIT_TIMEOUT 19 -#define I915_PARAM_HAS_VEBOX 22 +#define I915_PARAM_HAS_SEMAPHORES 20 +#define I915_PARAM_HAS_PRIME_VMAP_FLUSH 21 +#define I915_PARAM_HAS_VEBOX 22 +#define I915_PARAM_HAS_SECURE_BATCHES 23 +#define I915_PARAM_HAS_PINNED_BATCHES 24 +#define I915_PARAM_HAS_EXEC_NO_RELOC 25 +#define I915_PARAM_HAS_EXEC_HANDLE_LUT 26 +#define I915_PARAM_HAS_WT 27 typedef struct drm_i915_getparam { int param; @@ -626,7 +657,11 @@ struct drm_i915_gem_exec_object2 { __u64 offset; #define EXEC_OBJECT_NEEDS_FENCE (1<<0) +#define EXEC_OBJECT_NEEDS_GTT (1<<1) +#define EXEC_OBJECT_WRITE (1<<2) +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1) __u64 flags; + __u64 rsvd1; __u64 rsvd2; }; @@ -672,6 +707,34 @@ struct drm_i915_gem_execbuffer2 { /** Resets the SO write offset registers for transform feedback on gen7. */ #define I915_EXEC_GEN7_SOL_RESET (1<<8) +/** Request a privileged ("secure") batch buffer. Note only available for + * DRM_ROOT_ONLY | DRM_MASTER processes. + */ +#define I915_EXEC_SECURE (1<<9) + +/** Inform the kernel that the batch is and will always be pinned. This + * negates the requirement for a workaround to be performed to avoid + * an incoherent CS (such as can be found on 830/845). If this flag is + * not passed, the kernel will endeavour to make sure the batch is + * coherent with the CS before execution. If this flag is passed, + * userspace assumes the responsibility for ensuring the same. + */ +#define I915_EXEC_IS_PINNED (1<<10) + +/** Provide a hint to the kernel that the command stream and auxilliary + * state buffers already holds the correct presumed addresses and so the + * relocation process may be skipped if no buffers need to be moved in + * preparation for the execbuffer. + */ +#define I915_EXEC_NO_RELOC (1<<11) + +/** Use the reloc.handle as an index into the exec object array rather + * than as the per-file handle. + */ +#define I915_EXEC_HANDLE_LUT (1<<12) + +#define __I915_EXEC_UNKNOWN_FLAGS -(I915_EXEC_HANDLE_LUT<<1) + #define I915_EXEC_CONTEXT_ID_MASK (0xffffffff) #define i915_execbuffer2_set_context_id(eb2, context) \ (eb2).rsvd1 = context & I915_EXEC_CONTEXT_ID_MASK @@ -708,21 +771,45 @@ struct drm_i915_gem_busy { __u32 busy; }; -#define I915_CACHEING_NONE 0 -#define I915_CACHEING_CACHED 1 +/** + * I915_CACHING_NONE + * + * GPU access is not coherent with cpu caches. Default for machines without an + * LLC. + */ +#define I915_CACHING_NONE 0 +/** + * I915_CACHING_CACHED + * + * GPU access is coherent with cpu caches and furthermore the data is cached in + * last-level caches shared between cpu cores and the gpu GT. Default on + * machines with HAS_LLC. + */ +#define I915_CACHING_CACHED 1 +/** + * I915_CACHING_DISPLAY + * + * Special GPU caching mode which is coherent with the scanout engines. + * Transparently falls back to I915_CACHING_NONE on platforms where no special + * cache mode (like write-through or gfdt flushing) is available. The kernel + * automatically sets this mode when using a buffer as a scanout target. + * Userspace can manually set this mode to avoid a costly stall and clflush in + * the hotpath of drawing the first frame. + */ +#define I915_CACHING_DISPLAY 2 -struct drm_i915_gem_cacheing { +struct drm_i915_gem_caching { /** - * Handle of the buffer to set/get the cacheing level of. */ + * Handle of the buffer to set/get the caching level of. */ __u32 handle; /** * Cacheing level to apply or return value * - * bits0-15 are for generic cacheing control (i.e. the above defined + * bits0-15 are for generic caching control (i.e. the above defined * values). bits16-31 are reserved for platform-specific variations * (e.g. l3$ caching on gen7). */ - __u32 cacheing; + __u32 caching; }; #define I915_TILING_NONE 0 @@ -962,4 +1049,4 @@ struct drm_i915_reset_stats { __u32 pad; }; -#endif /* _I915_DRM_H_ */ +#endif /* _I915_DRM_H_ */ -- 1.8.5.2

1 0

[PATCH 2/5] intel: Handle malloc fails in context create
by Ben Widawsky 03 Jan '14

03 Jan '14

The previous code would just use the potentially unallocated variable, which is probably okay most of the time, but not very nice to the user of the library. Signed-off-by: Ben Widawsky <ben(a)bwidawsk.net> --- intel/intel_bufmgr_gem.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 3b1f584..ad722dd 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -3020,15 +3020,19 @@ drm_intel_gem_context_create(drm_intel_bufmgr *bufmgr) drm_intel_context *context = NULL; int ret; + context = calloc(1, sizeof(*context)); + if (!context) + return NULL; + VG_CLEAR(create); ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, &create); if (ret != 0) { DBG("DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed: %s\n", strerror(errno)); + free(context); return NULL; } - context = calloc(1, sizeof(*context)); context->ctx_id = create.ctx_id; context->bufmgr = bufmgr; -- 1.8.5.2

1 0

[PATCH 1/5] intel: squash unused variable 'bo_gem'
by Ben Widawsky 03 Jan '14

03 Jan '14

Signed-off-by: Ben Widawsky <ben(a)bwidawsk.net> --- intel/intel_bufmgr_gem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 48ff62e..3b1f584 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -1337,7 +1337,9 @@ int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo) int drm_intel_gem_bo_map_unsynchronized(drm_intel_bo *bo) { drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr; +#ifdef HAVE_VALGRIND drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo; +#endif int ret; /* If the CPU cache isn't coherent with the GTT, then use a -- 1.8.5.2

1 0

[PATCH] drm/radeon: Disable writeback by default on ppc
by Adam Jackson 02 Jan '14

02 Jan '14

At least on an IBM Power 720, this check passes, but several piglit tests will reliably trigger GPU resets due to the ring buffer pointers not being updated. There's probably a better way to limit this to just affected machines though. Signed-off-by: Adam Jackson <ajax(a)redhat.com> --- drivers/gpu/drm/radeon/r600_cp.c | 7 +++++++ drivers/gpu/drm/radeon/radeon_cp.c | 7 +++++++ drivers/gpu/drm/radeon/radeon_device.c | 4 ++-- drivers/gpu/drm/radeon/radeon_drv.c | 2 +- 4 files changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c index 1c51c08..ef28532 100644 --- a/drivers/gpu/drm/radeon/r600_cp.c +++ b/drivers/gpu/drm/radeon/r600_cp.c @@ -552,6 +552,13 @@ static void r600_test_writeback(drm_radeon_private_t *dev_priv) dev_priv->writeback_works = 0; DRM_INFO("writeback test failed\n"); } +#if defined(__ppc__) || defined(__ppc64__) + /* the test might succeed on ppc, but it's usually not reliable */ + if (radeon_no_wb == -1) { + radeon_no_wb = 1; + DRM_INFO("not trusting writeback test due to arch quirk\n"); + } +#endif if (radeon_no_wb == 1) { dev_priv->writeback_works = 0; DRM_INFO("writeback forced off\n"); diff --git a/drivers/gpu/drm/radeon/radeon_cp.c b/drivers/gpu/drm/radeon/radeon_cp.c index efc4f64..a967b33 100644 --- a/drivers/gpu/drm/radeon/radeon_cp.c +++ b/drivers/gpu/drm/radeon/radeon_cp.c @@ -892,6 +892,13 @@ static void radeon_test_writeback(drm_radeon_private_t * dev_priv) dev_priv->writeback_works = 0; DRM_INFO("writeback test failed\n"); } +#if defined(__ppc__) || defined(__ppc64__) + /* the test might succeed on ppc, but it's usually not reliable */ + if (radeon_no_wb == -1) { + radeon_no_wb = 1; + DRM_INFO("not trusting writeback test due to arch quirk\n"); + } +#endif if (radeon_no_wb == 1) { dev_priv->writeback_works = 0; DRM_INFO("writeback forced off\n"); diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 1899738..524046e 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -322,8 +322,8 @@ int radeon_wb_init(struct radeon_device *rdev) /* disable event_write fences */ rdev->wb.use_event = false; /* disabled via module param */ - if (radeon_no_wb == 1) { - rdev->wb.enabled = false; + if (radeon_no_wb != -1) { + rdev->wb.enabled = !!radeon_no_wb; } else { if (rdev->flags & RADEON_IS_AGP) { /* often unreliable on AGP */ diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 094e7e5..04809d4 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -146,7 +146,7 @@ static inline void radeon_register_atpx_handler(void) {} static inline void radeon_unregister_atpx_handler(void) {} #endif -int radeon_no_wb; +int radeon_no_wb = -1; int radeon_modeset = -1; int radeon_dynclks = -1; int radeon_r4xx_atom = 0; -- 1.8.2.1

5 22

[Bug 64891] [snd_hda_codec] BUG: soft lockup - CPU#0 stuck for 22s (when using vgaswitcheroo)
by bugzilla-daemon＠bugzilla.kernel.org 02 Jan '14

02 Jan '14

https://bugzilla.kernel.org/show_bug.cgi?id=64891 --- Comment #44 from Joaquín Aramendía <samsagax(a)gmail.com> --- Created attachment 120671 --> https://bugzilla.kernel.org/attachment.cgi?id=120671&action=edit Nouveau locked dmesg 3.13rc6 patched Ok. Then I got 3.13rc6 with the patch from comment #37. Entering multi-user.target went fine. Then I tried to enter X. Here is the dmesg from that run. It took me almost 15 minutes of lockup. This time it got to print a trace. It seems that is only related to nouveau. Hope this helps -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 70706] Regression in fbconfig
by bugzilla-daemon＠freedesktop.org 02 Jan '14

02 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=70706 --- Comment #13 from Eugene Shalygin <eugene.shalygin+bugzilla.FDO(a)gmail.com> --- X.Org X Server 1.15.0 has the same problem with mesa from git master branch. Glxinfo and KWin run fine if mesa is compiled with --disable-dri3 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

Doubt in gpu driver
by Rashika Kheria 02 Jan '14

02 Jan '14

Hello, I am trying to eliminate missing-prototypes warnings for drivers/gpu/. I noticed that radeon_reg.h and radeon_drv.h conflict due to incompatible definitions therefore making it difficult to add both the headers in a single file. If it is included, then it throws the following error: drivers/gpu/drm/radeon/radeon_drv.h:849:0: warning: "RADEON_RB3D_DSTCACHE_CTLSTAT" redefined [enabled by default] drivers/gpu/drm/radeon/radeon_reg.h:1627:0: note: this is the location of the previous definition drivers/gpu/drm/radeon/radeon_drv.h:1057:0: warning: "R300_CP_RESYNC_ADDR" redefined [enabled by default] drivers/gpu/drm/radeon/radeon_reg.h:3342:0: note: this is the location of the previous definition drivers/gpu/drm/radeon/radeon_drv.h:1058:0: warning: "R300_CP_RESYNC_DATA" redefined [enabled by default] drivers/gpu/drm/radeon/radeon_reg.h:3343:0: note: this is the location of the previous definition I am therefore not able to add prototypes to radeon.h (which includes radeon_reg.h) or radeon_drv.h if a file that needs to include one already includes the other. For eg. If I add the prototype declaration of function r600_cs_legacy_get_tiling_conf to either header file radeon.h or radeon_drv.h, then I have to add the corresponding header file to r600_cp.c or r600_cs.c. Hence, either r600_cp.c or r600_cs.c would end up including both. I wanted to confirm whether it will be fine to remove the redundant and conflicting definitions from either radeon_reg.h or radeon_drv.h or atleast make the definitions match so that the compiler does not complain. Thanks, -- Rashika Kheria B.Tech CSE IIIT Hyderabad

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2014