[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 --- Comment #4 from Kevin 2011-03-18 21:25:15 --- The problem occurred in 2.6.37 also. Logging out of X doesn't get the memory back. I'm also not sure if just scrolling a lot causes the problem. It seems to be easier for me to consume memory by opening many .pdf files. Here is some output after logging out of X (I still had about ~30MB from root processes): $ free -m total used free sharedbuffers cached Mem: 5920 2668 3252 0 96 1088 -/+ buffers/cache: 1484 4436 Swap: 7998 0 7998 $ cat /sys/kernel/debug/dri/0/radeon_vram_mm 0x-0x0040: 0x0040: used 0x0040-0x0140: 0x0100: used 0x0140-0x0141: 0x0001: used 0x0141-0x092a: 0x07e9: used 0x092a-0x0004: 0x0003f6d6: free total: 262144, used 2346 free 259798 $ cat /sys/kernel/debug/dri/0/radeon_gtt_mm 0x-0x0001: 0x0001: used 0x0001-0x0011: 0x0010: used 0x0011-0x0111: 0x0100: used 0x0111-0x0211: 0x0100: used 0x0211-0x0002: 0x0001fdef: free total: 131072, used 529 free 130543 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 Dave Airlie changed: What|Removed |Added CC||airlied at linux.ie --- Comment #3 from Dave Airlie 2011-03-18 21:01:21 --- 1df6a2ebd75067aefbdf07482bf8e3d0584e04ee was the fix for the original problem, which was in 2.6.37. Unless something we've done since is causing it or another race to happen. So logging out of X doesn't get the memory back? can you attach the contents of /sys/kernel/debug/dri/0/radeon_vram_mm and radeon_gtt_mm? (after mounting debugfs). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 --- Comment #2 from Kevin 2011-03-18 20:47:01 --- It's not a regression. I also experienced the problem with 2.6.37 and 2.6.36. I haven't tested any other kernel versions; I got my laptop in December. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 Andrew Morton changed: What|Removed |Added CC||akpm at linux-foundation.org --- Comment #1 from Andrew Morton 2011-03-18 20:31:35 --- It's a little unclear - is this a regression? If so, is it a 2.6.37 -> 2.6.38 regression? Thanks. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 Andrew Morton changed: What|Removed |Added Component|Other |Video(DRI - non Intel) AssignedTo|akpm at linux-foundation.org |drivers_video-dri at kernel-bu ||gs.osdl.org Product|Memory Management |Drivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] kernel/drm: vblank wait on crtc > 1
On Fri, 18 Mar 2011, Jesse Barnes wrote: > > I like the new param check, but I'd still prefer a new ioctl to abusing > the old one. > It's not "abusing" it but extending the interface in a backwards-compatible manner. Introducing a new one would result in two ioctls that essentially do the same thing, which I don't like. -- Ilija
[PATCH] xf86-video-ati: vblank wait on crtc > 1
On Fri, 18 Mar 2011, Jesse Barnes wrote:
>
> The duplicated code in each function is begging to get pulled out into
> a separate function...
>
How about this then ?
diff --git a/src/radeon.h b/src/radeon.h
index a6d20d7..1a746c7 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -931,6 +931,9 @@ typedef struct {
RADEONFBLayoutCurrentLayout;
+#ifdef RADEON_DRI2
+Bool high_crtc_works;
+#endif
#ifdef XF86DRI
Bool directRenderingEnabled;
Bool directRenderingInited;
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index 66df03c..c461469 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -771,6 +771,24 @@ cleanup:
free(event);
}
+static drmVBlankSeqType populate_vbl_request_type(RADEONInfoPtr info, int crtc)
+{
+int high_crtc = 0;
+drmVBlankSeqType type = 0;
+
+if (crtc == 1)
+type |= DRM_VBLANK_SECONDARY;
+else if (crtc > 1) {
+ if (info->high_crtc_works) {
+ high_crtc = (crtc << DRM_VBLANK_HIGH_CRTC_SHIFT) &
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else
+ type |= DRM_VBLANK_SECONDARY;
+}
+type |= high_crtc;
+return type;
+}
+
/*
* Get current frame count and frame count timestamp, based on drawable's
* crtc.
@@ -791,8 +809,7 @@ static int radeon_dri2_get_msc(DrawablePtr draw, CARD64
*ust, CARD64 *msc)
return TRUE;
}
vbl.request.type = DRM_VBLANK_RELATIVE;
-if (crtc > 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = 0;
ret = drmWaitVBlank(info->dri2.drm_fd, );
@@ -855,8 +872,7 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
/* Get current count */
vbl.request.type = DRM_VBLANK_RELATIVE;
-if (crtc > 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = 0;
ret = drmWaitVBlank(info->dri2.drm_fd, );
if (ret) {
@@ -882,8 +898,7 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
if (current_msc >= target_msc)
target_msc = current_msc;
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
-if (crtc > 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+ vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = target_msc;
vbl.request.signal = (unsigned long)wait_info;
ret = drmWaitVBlank(info->dri2.drm_fd, );
@@ -903,8 +918,7 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
* so we queue an event that will satisfy the divisor/remainder equation.
*/
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
-if (crtc > 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = current_msc - (current_msc % divisor) +
remainder;
@@ -1068,8 +1082,7 @@ static int radeon_dri2_schedule_swap(ClientPtr client,
DrawablePtr draw,
/* Get current count */
vbl.request.type = DRM_VBLANK_RELATIVE;
-if (crtc > 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = 0;
ret = drmWaitVBlank(info->dri2.drm_fd, );
if (ret) {
@@ -,8 +1124,7 @@ static int radeon_dri2_schedule_swap(ClientPtr client,
DrawablePtr draw,
*/
if (flip == 0)
vbl.request.type |= DRM_VBLANK_NEXTONMISS;
-if (crtc > 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+ vbl.request.type |= populate_vbl_request_type(info, crtc);
/* If target_msc already reached or passed, set it to
* current_msc to ensure we return a reasonable value back
@@ -1145,8 +1157,7 @@ static int radeon_dri2_schedule_swap(ClientPtr client,
DrawablePtr draw,
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
if (flip == 0)
vbl.request.type |= DRM_VBLANK_NEXTONMISS;
-if (crtc > 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = current_msc - (current_msc % divisor) +
remainder;
@@ -1217,6 +1228,7 @@ radeon_dri2_screen_init(ScreenPtr pScreen)
DRI2InfoRec dri2_info = { 0 };
#ifdef USE_DRI2_SCHEDULING
const char *driverNames[1];
+uint64_t cap_value;
#endif
if (!info->useEXA) {
@@ -1248,6 +1260,7 @@ radeon_dri2_screen_init(ScreenPtr pScreen)
#endif
dri2_info.CopyRegion = radeon_dri2_copy_region;
+info->high_crtc_works = FALSE;
#ifdef USE_DRI2_SCHEDULING
if (info->dri->pKernelDRMVersion->version_minor >= 4) {
dri2_info.version = 4;
@@ -1261,6 +1274,20 @@
[PATCH] xf86-video-ati: vblank wait on crtc > 1
Hi Alex,
Below is a patch against the master branch of xf86-video-ati that adds
support for waits on vblank events on CRTCs that are greater than 1 (and
thus cannot be represented using current primary/secondary flags
interface). The patch makes use of GET_CAP ioctl to check whether
vblanks on crtc > 1 are supported by the kernel. If they are not
falls back to legacy behavior. Otherwise, it uses correct crtc numbers
when waiting on vblank and thus corrects the problem seen in certain
multiscreen configurations.
The issue was discussed on the dri-devel list in these two threads
http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html
http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html
regards,
Ilija
Reviewed-by: Mario Kleiner
Acked-by: Mario Kleiner
diff --git a/src/radeon.h b/src/radeon.h
index a6d20d7..1a746c7 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -931,6 +931,9 @@ typedef struct {
RADEONFBLayoutCurrentLayout;
+#ifdef RADEON_DRI2
+Bool high_crtc_works;
+#endif
#ifdef XF86DRI
Bool directRenderingEnabled;
Bool directRenderingInited;
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index 66df03c..ed27dad 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -783,6 +783,7 @@ static int radeon_dri2_get_msc(DrawablePtr draw, CARD64
*ust, CARD64 *msc)
drmVBlank vbl;
int ret;
int crtc = radeon_dri2_drawable_crtc(draw);
+int high_crtc = 0;
/* Drawable not displayed, make up a value */
if (crtc == -1) {
@@ -791,8 +792,16 @@ static int radeon_dri2_get_msc(DrawablePtr draw, CARD64
*ust, CARD64 *msc)
return TRUE;
}
vbl.request.type = DRM_VBLANK_RELATIVE;
-if (crtc > 0)
+if (crtc == 1)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+else if (crtc > 1) {
+ if (info->high_crtc_works) {
+ high_crtc = (crtc << DRM_VBLANK_HIGH_CRTC_SHIFT) &
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
+}
+vbl.request.type |= high_crtc;
vbl.request.sequence = 0;
ret = drmWaitVBlank(info->dri2.drm_fd, );
@@ -825,6 +834,7 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
drmVBlank vbl;
int ret, crtc = radeon_dri2_drawable_crtc(draw);
CARD64 current_msc;
+int high_crtc = 0;
/* Truncate to match kernel interfaces; means occasional overflow
* misses, but that's generally not a big deal */
@@ -855,8 +865,16 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
/* Get current count */
vbl.request.type = DRM_VBLANK_RELATIVE;
-if (crtc > 0)
+if (crtc == 1)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+else if (crtc > 1) {
+ if (info->high_crtc_works) {
+ high_crtc = (crtc << DRM_VBLANK_HIGH_CRTC_SHIFT) &
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
+}
+vbl.request.type |= high_crtc;
vbl.request.sequence = 0;
ret = drmWaitVBlank(info->dri2.drm_fd, );
if (ret) {
@@ -882,8 +900,16 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
if (current_msc >= target_msc)
target_msc = current_msc;
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
-if (crtc > 0)
+if (crtc == 1)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+ else if (crtc > 1) {
+ if (info->high_crtc_works) {
+ high_crtc = (crtc << DRM_VBLANK_HIGH_CRTC_SHIFT) &
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
+ }
+ vbl.request.type |= high_crtc;
vbl.request.sequence = target_msc;
vbl.request.signal = (unsigned long)wait_info;
ret = drmWaitVBlank(info->dri2.drm_fd, );
@@ -903,8 +929,16 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
* so we queue an event that will satisfy the divisor/remainder equation.
*/
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
-if (crtc > 0)
+if (crtc == 1)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+else if (crtc > 1) {
+ if (info->high_crtc_works) {
+ high_crtc = (crtc << DRM_VBLANK_HIGH_CRTC_SHIFT) &
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
+}
+vbl.request.type |= high_crtc;
vbl.request.sequence = current_msc - (current_msc % divisor) +
remainder;
@@ -1029,6 +1063,7 @@ static int radeon_dri2_schedule_swap(ClientPtr client,
DrawablePtr draw,
CARD64 current_msc;
BoxRec box;
RegionRec region;
+int high_crtc = 0;
/* Truncate to match kernel interfaces; means occasional
[PATCH] libdrm: vblank wait on crtc > 1
Hi Alex,
Below is a patch against the master branch of libdrm that adds support
for waits for vblank events on CRTCs that are greater than 1 (and thus
cannot be represented using current primary/secondary flags interface).
The patch adds a new DRM_CAP so that the application can check whether the
new vblank interface is supported and also adds the new DRM_VBLANK mask
and shift value so that the application can construct vblank_wait ioctls
that refer to crtc > 1
The issue was discussed on the dri-devel list in these two threads
http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html
http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html
Regards,
Ilija
Reviewed-by: Mario Kleiner
Acked-by: Mario Kleiner
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 416673a..10afaf1 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -755,6 +755,7 @@ struct drm_event_vblank {
};
#define DRM_CAP_DUMB_BUFFER 0x1
+#define DRM_CAP_HIGH_CRTC 0x2
/* typedef area */
typedef struct drm_clip_rect drm_clip_rect_t;
diff --git a/xf86drm.h b/xf86drm.h
index bf0d5df..e2bea06 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -302,6 +302,8 @@ typedef enum {
DRM_VBLANK_SECONDARY = 0x2000,/**< Secondary display
controller */
DRM_VBLANK_SIGNAL = 0x4000 /* Send signal instead of blocking */
} drmVBlankSeqType;
+#define DRM_VBLANK_HIGH_CRTC_SHIFT 16
+#define DRM_VBLANK_HIGH_CRTC_MASK 0x001F
typedef struct _drmVBlankReq {
drmVBlankSeqType type;
[PATCH] kernel/drm: vblank wait on crtc > 1
Hi Dave,
Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds
the capability to wait on vblank events for CRTCs that are greater than 1
and thus cannot be represented with primary/secondary flags in the legacy
interface. It was discussed on the dri-devel list in these two threads:
http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html
http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html
This patch extends the interface to drm_wait_vblank ioctl so that crtc>1
can be represented. It also adds a new capability to drm_getcap ioctl so
that the user space can check whether the new interface to drm_wait_vblank
is supported (and fall back to the legacy interface if not)
Regards,
Ilija
Reviewed-by: Mario Kleiner
Acked-by: Mario Kleiner
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 7f6912a..3617b4c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -280,6 +280,9 @@ int drm_getcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
if (dev->driver->dumb_create)
req->value = 1;
break;
+ case DRM_CAP_HIGH_CRTC:
+ req->value = 1;
+ break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index a34ef97..c725088 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1125,7 +1125,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
{
union drm_wait_vblank *vblwait = data;
int ret = 0;
- unsigned int flags, seq, crtc;
+ unsigned int flags, seq, crtc, high_crtc;
if ((!drm_dev_to_irq(dev)) || (!dev->irq_enabled))
return -EINVAL;
@@ -1134,16 +1134,21 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
return -EINVAL;
if (vblwait->request.type &
- ~(_DRM_VBLANK_TYPES_MASK | _DRM_VBLANK_FLAGS_MASK)) {
+ ~(_DRM_VBLANK_TYPES_MASK | _DRM_VBLANK_FLAGS_MASK |
+ _DRM_VBLANK_HIGH_CRTC_MASK)) {
DRM_ERROR("Unsupported type value 0x%x, supported mask 0x%x\n",
vblwait->request.type,
- (_DRM_VBLANK_TYPES_MASK | _DRM_VBLANK_FLAGS_MASK));
+ (_DRM_VBLANK_TYPES_MASK | _DRM_VBLANK_FLAGS_MASK |
+ _DRM_VBLANK_HIGH_CRTC_MASK));
return -EINVAL;
}
flags = vblwait->request.type & _DRM_VBLANK_FLAGS_MASK;
- crtc = flags & _DRM_VBLANK_SECONDARY ? 1 : 0;
-
+ high_crtc = (vblwait->request.type & _DRM_VBLANK_HIGH_CRTC_MASK);
+ if (high_crtc)
+ crtc = high_crtc >> _DRM_VBLANK_HIGH_CRTC_SHIFT;
+ else
+ crtc = flags & _DRM_VBLANK_SECONDARY ? 1 : 0;
if (crtc >= dev->num_crtcs)
return -EINVAL;
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 9ac4313..99cd074 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -469,6 +469,8 @@ enum drm_vblank_seq_type {
_DRM_VBLANK_SECONDARY = 0x2000, /**< Secondary display
controller */
_DRM_VBLANK_SIGNAL = 0x4000 /**< Send signal instead of blocking,
unsupported */
};
+#define _DRM_VBLANK_HIGH_CRTC_SHIFT 16
+#define _DRM_VBLANK_HIGH_CRTC_MASK 0x001F
#define _DRM_VBLANK_TYPES_MASK (_DRM_VBLANK_ABSOLUTE | _DRM_VBLANK_RELATIVE)
#define _DRM_VBLANK_FLAGS_MASK (_DRM_VBLANK_EVENT | _DRM_VBLANK_SIGNAL | \
@@ -753,6 +755,7 @@ struct drm_event_vblank {
};
#define DRM_CAP_DUMB_BUFFER 0x1
+#define DRM_CAP_HIGH_CRTC 0x2
/* typedef area */
#ifndef __KERNEL__
[PATCH] kernel/drm: vblank wait on crtc > 1
On Fri, 18 Mar 2011 18:13:11 -0500 (CDT) Ilija Hadzic wrote: > > > On Fri, 18 Mar 2011, Jesse Barnes wrote: > > > > > I like the new param check, but I'd still prefer a new ioctl to abusing > > the old one. > > > > It's not "abusing" it but extending the interface in a > backwards-compatible manner. Introducing a new one would result in two > ioctls that essentially do the same thing, which I don't like. Yes abusing was a strong word; I just don't like encoding crtc numbers in a bitfield, when we just use ints everywhere else. Not a big deal, Dave will make the final call. Thanks for doing this work. -- Jesse Barnes, Intel Open Source Technology Center
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures + sporadic junk being displayed
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #2 from Andy Furniss 2011-03-18 15:18:40 PDT --- (In reply to comment #0) > A few pictures of what I'm seeing are attached. > > Environment: > Linux kernel (Linus' current git with s3tc support) > libdrm, xf86-video-ati, mesa @ current git > > RV770 [Radeon HD 4850] > [ 153.910] (II) RADEON(0): KMS Color Tiling: enabled > [ 153.910] (II) RADEON(0): KMS Pageflipping: enabled > [ 153.910] (II) RADEON(0): SwapBuffers wait for vsync: enabled I also see the corrupted ground on both rv670 and rv790. Running d-r-t kernel I haven't seen any other corruption yet. Starting in spectator mode the ground is OK until moving around, when patches/strips become corrupted. It is possible for corrupted ground to become normal again when viewed from a different place. I have tested with the above settings disabled and with various in game settings - it makes no difference. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] kernel/drm: vblank wait on crtc > 1
On Fri, 18 Mar 2011 16:58:04 -0500 (CDT) Ilija Hadzic wrote: > > Hi Dave, > > Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds > the capability to wait on vblank events for CRTCs that are greater than 1 > and thus cannot be represented with primary/secondary flags in the legacy > interface. It was discussed on the dri-devel list in these two threads: > > http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html > http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html > > This patch extends the interface to drm_wait_vblank ioctl so that crtc>1 > can be represented. It also adds a new capability to drm_getcap ioctl so > that the user space can check whether the new interface to drm_wait_vblank > is supported (and fall back to the legacy interface if not) I like the new param check, but I'd still prefer a new ioctl to abusing the old one. -- Jesse Barnes, Intel Open Source Technology Center
[PATCH] xf86-video-ati: vblank wait on crtc > 1
On Fri, 18 Mar 2011 16:58:39 -0500 (CDT) Ilija Hadzic wrote: > > Hi Alex, > > Below is a patch against the master branch of xf86-video-ati that adds > support for waits on vblank events on CRTCs that are greater than 1 (and > thus cannot be represented using current primary/secondary flags > interface). The patch makes use of GET_CAP ioctl to check whether > vblanks on crtc > 1 are supported by the kernel. If they are not > falls back to legacy behavior. Otherwise, it uses correct crtc numbers > when waiting on vblank and thus corrects the problem seen in certain > multiscreen configurations. > > The issue was discussed on the dri-devel list in these two threads > > http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html > http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html > The duplicated code in each function is begging to get pulled out into a separate function... -- Jesse Barnes, Intel Open Source Technology Center
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures + sporadic junk being displayed
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #1 from Brian Paterni 2011-03-18 14:17:22 PDT --- correction: Images [1] and [2] are located elsewhere due to bug tracker attachment limitation. [1] http://imgur.com/k8NNA# bad ground textures example [2] http://imgur.com/fDkmc# junk example -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35434] New: [RADEON:KMS:R600G] etqw: broken ground textures + sporadic junk being displayed
https://bugs.freedesktop.org/show_bug.cgi?id=35434 Summary: [RADEON:KMS:R600G] etqw: broken ground textures + sporadic junk being displayed Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: bpaterni at gmail.com A few pictures of what I'm seeing are attached. Environment: Linux kernel (Linus' current git with s3tc support) libdrm, xf86-video-ati, mesa @ current git RV770 [Radeon HD 4850] [ 153.910] (II) RADEON(0): KMS Color Tiling: enabled [ 153.910] (II) RADEON(0): KMS Pageflipping: enabled [ 153.910] (II) RADEON(0): SwapBuffers wait for vsync: enabled -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Radeon jittery post 2.6.35
On 03/16/11 21:09, Anders Eriksson wrote: > On 03/15/11 22:46, Alex Deucher wrote: > > Try booting with radeon.audio=0 on 2.6.38rc, some TVs have problems > > with the hdmi packets we send by default. disabling audio will treat > > the hdmi like dvi. > > > > Alex > You seem to be on to something there. radeon.audio=0 removes > what appears to be all of the jitter. I say "appear", because during > my many test runs today, I've come across moments where my brain > goes "wasn't what I just noticed on the TV something abnormal?" Both > in fb mode (post KMS), and in X11. It's definetly improved from useless > for family use, to perfectly ok though. > I was too early on this one. Yesterday (.38) , and today (38-rc8), are both jittery in post-KMS fb mode and in X, even though I use radeon.audio=0. A power cycling of the TV stabilizes it though. I'd be more than happy to test out any patches or ideas you might have. -A
[Bug 35425] New: Instanced drawing: not implemented
https://bugs.freedesktop.org/show_bug.cgi?id=35425 Summary: Instanced drawing: not implemented Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: enhancement Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: s3734770 at mail.zih.tu-dresden.de The follwing output is from the Unigine Heaven Demo: 0:171(53): error: `gl_InstanceID' undeclared 0:171(76): error: Operands to arithmetic operators must be numeric 0:171(76): error: Operands to arithmetic operators must be numeric 0:199(39): error: `gl_InstanceID' undeclared 0:199(42): error: Operands to arithmetic operators must be numeric 0:199(19): error: cannot construct `ivec3' from a non-numeric data type 0:199(58): error: Operands to arithmetic operators must be numeric GLShader::loadVertex(): error in "core/shaders/meshes/vertex_base.shader" file defines: UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,USE_SRGB,USE_DEFERRED,USE_PARALLAX,USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,HAS_ARB_DRAW_INSTANCED,BASE_LIGHT_OMNI,OMNI,SHADOW,PHONG_RIM (This also occurs on software rendering) I know that instancing is not implemented in mesa yet. Can you please start designing the interface for mesa/gallium's drivers to enable starting to write the drivers for it? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34972] [nouveau] Screen blinking on dualhead
https://bugs.freedesktop.org/show_bug.cgi?id=34972 --- Comment #2 from Gy?rgy Ball? 2011-03-18 08:18:42 PDT --- I think it's a duplicate of bug 34220. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Radeon jittery post 2.6.35
On 03/16/11 21:09, Anders Eriksson wrote: On 03/15/11 22:46, Alex Deucher wrote: Try booting with radeon.audio=0 on 2.6.38rc, some TVs have problems with the hdmi packets we send by default. disabling audio will treat the hdmi like dvi. Alex You seem to be on to something there. radeon.audio=0 removes what appears to be all of the jitter. I say appear, because during my many test runs today, I've come across moments where my brain goes wasn't what I just noticed on the TV something abnormal? Both in fb mode (post KMS), and in X11. It's definetly improved from useless for family use, to perfectly ok though. I was too early on this one. Yesterday (.38) , and today (38-rc8), are both jittery in post-KMS fb mode and in X, even though I use radeon.audio=0. A power cycling of the TV stabilizes it though. I'd be more than happy to test out any patches or ideas you might have. -A ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34972] [nouveau] Screen blinking on dualhead
https://bugs.freedesktop.org/show_bug.cgi?id=34972 --- Comment #2 from György Balló ball...@freestart.hu 2011-03-18 08:18:42 PDT --- I think it's a duplicate of bug 34220. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35425] New: Instanced drawing: not implemented
https://bugs.freedesktop.org/show_bug.cgi?id=35425 Summary: Instanced drawing: not implemented Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: enhancement Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: s3734...@mail.zih.tu-dresden.de The follwing output is from the Unigine Heaven Demo: 0:171(53): error: `gl_InstanceID' undeclared 0:171(76): error: Operands to arithmetic operators must be numeric 0:171(76): error: Operands to arithmetic operators must be numeric 0:199(39): error: `gl_InstanceID' undeclared 0:199(42): error: Operands to arithmetic operators must be numeric 0:199(19): error: cannot construct `ivec3' from a non-numeric data type 0:199(58): error: Operands to arithmetic operators must be numeric GLShader::loadVertex(): error in core/shaders/meshes/vertex_base.shader file defines: UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,USE_SRGB,USE_DEFERRED,USE_PARALLAX,USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,HAS_ARB_DRAW_INSTANCED,BASE_LIGHT_OMNI,OMNI,SHADOW,PHONG_RIM (This also occurs on software rendering) I know that instancing is not implemented in mesa yet. Can you please start designing the interface for mesa/gallium's drivers to enable starting to write the drivers for it? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 Andrew Morton a...@linux-foundation.org changed: What|Removed |Added Component|Other |Video(DRI - non Intel) AssignedTo|a...@linux-foundation.org |drivers_video-dri@kernel-bu ||gs.osdl.org Product|Memory Management |Drivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 Andrew Morton a...@linux-foundation.org changed: What|Removed |Added CC||a...@linux-foundation.org --- Comment #1 from Andrew Morton a...@linux-foundation.org 2011-03-18 20:31:35 --- It's a little unclear - is this a regression? If so, is it a 2.6.37 - 2.6.38 regression? Thanks. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 --- Comment #2 from Kevin kjs...@gmail.com 2011-03-18 20:47:01 --- It's not a regression. I also experienced the problem with 2.6.37 and 2.6.36. I haven't tested any other kernel versions; I got my laptop in December. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 Dave Airlie airl...@linux.ie changed: What|Removed |Added CC||airl...@linux.ie --- Comment #3 from Dave Airlie airl...@linux.ie 2011-03-18 21:01:21 --- 1df6a2ebd75067aefbdf07482bf8e3d0584e04ee was the fix for the original problem, which was in 2.6.37. Unless something we've done since is causing it or another race to happen. So logging out of X doesn't get the memory back? can you attach the contents of /sys/kernel/debug/dri/0/radeon_vram_mm and radeon_gtt_mm? (after mounting debugfs). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35434] New: [RADEON:KMS:R600G] etqw: broken ground textures + sporadic junk being displayed
https://bugs.freedesktop.org/show_bug.cgi?id=35434 Summary: [RADEON:KMS:R600G] etqw: broken ground textures + sporadic junk being displayed Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: bpate...@gmail.com A few pictures of what I'm seeing are attached. Environment: Linux kernel (Linus' current git with s3tc support) libdrm, xf86-video-ati, mesa @ current git RV770 [Radeon HD 4850] [ 153.910] (II) RADEON(0): KMS Color Tiling: enabled [ 153.910] (II) RADEON(0): KMS Pageflipping: enabled [ 153.910] (II) RADEON(0): SwapBuffers wait for vsync: enabled -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures + sporadic junk being displayed
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #1 from Brian Paterni bpate...@gmail.com 2011-03-18 14:17:22 PDT --- correction: Images [1] and [2] are located elsewhere due to bug tracker attachment limitation. [1] http://imgur.com/k8NNA# bad ground textures example [2] http://imgur.com/fDkmc# junk example -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 --- Comment #4 from Kevin kjs...@gmail.com 2011-03-18 21:25:15 --- The problem occurred in 2.6.37 also. Logging out of X doesn't get the memory back. I'm also not sure if just scrolling a lot causes the problem. It seems to be easier for me to consume memory by opening many .pdf files. Here is some output after logging out of X (I still had about ~30MB from root processes): $ free -m total used free sharedbuffers cached Mem: 5920 2668 3252 0 96 1088 -/+ buffers/cache: 1484 4436 Swap: 7998 0 7998 $ cat /sys/kernel/debug/dri/0/radeon_vram_mm 0x-0x0040: 0x0040: used 0x0040-0x0140: 0x0100: used 0x0140-0x0141: 0x0001: used 0x0141-0x092a: 0x07e9: used 0x092a-0x0004: 0x0003f6d6: free total: 262144, used 2346 free 259798 $ cat /sys/kernel/debug/dri/0/radeon_gtt_mm 0x-0x0001: 0x0001: used 0x0001-0x0011: 0x0010: used 0x0011-0x0111: 0x0100: used 0x0111-0x0211: 0x0100: used 0x0211-0x0002: 0x0001fdef: free total: 131072, used 529 free 130543 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] kernel/drm: vblank wait on crtc 1
Hi Dave,
Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds
the capability to wait on vblank events for CRTCs that are greater than 1
and thus cannot be represented with primary/secondary flags in the legacy
interface. It was discussed on the dri-devel list in these two threads:
http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html
http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html
This patch extends the interface to drm_wait_vblank ioctl so that crtc1
can be represented. It also adds a new capability to drm_getcap ioctl so
that the user space can check whether the new interface to drm_wait_vblank
is supported (and fall back to the legacy interface if not)
Regards,
Ilija
Reviewed-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
Acked-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 7f6912a..3617b4c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -280,6 +280,9 @@ int drm_getcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
if (dev-driver-dumb_create)
req-value = 1;
break;
+ case DRM_CAP_HIGH_CRTC:
+ req-value = 1;
+ break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index a34ef97..c725088 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1125,7 +1125,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
{
union drm_wait_vblank *vblwait = data;
int ret = 0;
- unsigned int flags, seq, crtc;
+ unsigned int flags, seq, crtc, high_crtc;
if ((!drm_dev_to_irq(dev)) || (!dev-irq_enabled))
return -EINVAL;
@@ -1134,16 +1134,21 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
return -EINVAL;
if (vblwait-request.type
- ~(_DRM_VBLANK_TYPES_MASK | _DRM_VBLANK_FLAGS_MASK)) {
+ ~(_DRM_VBLANK_TYPES_MASK | _DRM_VBLANK_FLAGS_MASK |
+ _DRM_VBLANK_HIGH_CRTC_MASK)) {
DRM_ERROR(Unsupported type value 0x%x, supported mask 0x%x\n,
vblwait-request.type,
- (_DRM_VBLANK_TYPES_MASK | _DRM_VBLANK_FLAGS_MASK));
+ (_DRM_VBLANK_TYPES_MASK | _DRM_VBLANK_FLAGS_MASK |
+ _DRM_VBLANK_HIGH_CRTC_MASK));
return -EINVAL;
}
flags = vblwait-request.type _DRM_VBLANK_FLAGS_MASK;
- crtc = flags _DRM_VBLANK_SECONDARY ? 1 : 0;
-
+ high_crtc = (vblwait-request.type _DRM_VBLANK_HIGH_CRTC_MASK);
+ if (high_crtc)
+ crtc = high_crtc _DRM_VBLANK_HIGH_CRTC_SHIFT;
+ else
+ crtc = flags _DRM_VBLANK_SECONDARY ? 1 : 0;
if (crtc = dev-num_crtcs)
return -EINVAL;
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 9ac4313..99cd074 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -469,6 +469,8 @@ enum drm_vblank_seq_type {
_DRM_VBLANK_SECONDARY = 0x2000, /** Secondary display
controller */
_DRM_VBLANK_SIGNAL = 0x4000 /** Send signal instead of blocking,
unsupported */
};
+#define _DRM_VBLANK_HIGH_CRTC_SHIFT 16
+#define _DRM_VBLANK_HIGH_CRTC_MASK 0x001F
#define _DRM_VBLANK_TYPES_MASK (_DRM_VBLANK_ABSOLUTE | _DRM_VBLANK_RELATIVE)
#define _DRM_VBLANK_FLAGS_MASK (_DRM_VBLANK_EVENT | _DRM_VBLANK_SIGNAL | \
@@ -753,6 +755,7 @@ struct drm_event_vblank {
};
#define DRM_CAP_DUMB_BUFFER 0x1
+#define DRM_CAP_HIGH_CRTC 0x2
/* typedef area */
#ifndef __KERNEL__
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] libdrm: vblank wait on crtc 1
Hi Alex,
Below is a patch against the master branch of libdrm that adds support
for waits for vblank events on CRTCs that are greater than 1 (and thus
cannot be represented using current primary/secondary flags interface).
The patch adds a new DRM_CAP so that the application can check whether the
new vblank interface is supported and also adds the new DRM_VBLANK mask
and shift value so that the application can construct vblank_wait ioctls
that refer to crtc 1
The issue was discussed on the dri-devel list in these two threads
http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html
http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html
Regards,
Ilija
Reviewed-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
Acked-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 416673a..10afaf1 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -755,6 +755,7 @@ struct drm_event_vblank {
};
#define DRM_CAP_DUMB_BUFFER 0x1
+#define DRM_CAP_HIGH_CRTC 0x2
/* typedef area */
typedef struct drm_clip_rect drm_clip_rect_t;
diff --git a/xf86drm.h b/xf86drm.h
index bf0d5df..e2bea06 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -302,6 +302,8 @@ typedef enum {
DRM_VBLANK_SECONDARY = 0x2000, /** Secondary display controller */
DRM_VBLANK_SIGNAL = 0x4000 /* Send signal instead of blocking */
} drmVBlankSeqType;
+#define DRM_VBLANK_HIGH_CRTC_SHIFT 16
+#define DRM_VBLANK_HIGH_CRTC_MASK 0x001F
typedef struct _drmVBlankReq {
drmVBlankSeqType type;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] xf86-video-ati: vblank wait on crtc 1
Hi Alex,
Below is a patch against the master branch of xf86-video-ati that adds
support for waits on vblank events on CRTCs that are greater than 1 (and
thus cannot be represented using current primary/secondary flags
interface). The patch makes use of GET_CAP ioctl to check whether
vblanks on crtc 1 are supported by the kernel. If they are not
falls back to legacy behavior. Otherwise, it uses correct crtc numbers
when waiting on vblank and thus corrects the problem seen in certain
multiscreen configurations.
The issue was discussed on the dri-devel list in these two threads
http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html
http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html
regards,
Ilija
Reviewed-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
Acked-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
diff --git a/src/radeon.h b/src/radeon.h
index a6d20d7..1a746c7 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -931,6 +931,9 @@ typedef struct {
RADEONFBLayoutCurrentLayout;
+#ifdef RADEON_DRI2
+Bool high_crtc_works;
+#endif
#ifdef XF86DRI
Bool directRenderingEnabled;
Bool directRenderingInited;
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index 66df03c..ed27dad 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -783,6 +783,7 @@ static int radeon_dri2_get_msc(DrawablePtr draw, CARD64
*ust, CARD64 *msc)
drmVBlank vbl;
int ret;
int crtc = radeon_dri2_drawable_crtc(draw);
+int high_crtc = 0;
/* Drawable not displayed, make up a value */
if (crtc == -1) {
@@ -791,8 +792,16 @@ static int radeon_dri2_get_msc(DrawablePtr draw, CARD64
*ust, CARD64 *msc)
return TRUE;
}
vbl.request.type = DRM_VBLANK_RELATIVE;
-if (crtc 0)
+if (crtc == 1)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+else if (crtc 1) {
+ if (info-high_crtc_works) {
+ high_crtc = (crtc DRM_VBLANK_HIGH_CRTC_SHIFT)
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
+}
+vbl.request.type |= high_crtc;
vbl.request.sequence = 0;
ret = drmWaitVBlank(info-dri2.drm_fd, vbl);
@@ -825,6 +834,7 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
drmVBlank vbl;
int ret, crtc = radeon_dri2_drawable_crtc(draw);
CARD64 current_msc;
+int high_crtc = 0;
/* Truncate to match kernel interfaces; means occasional overflow
* misses, but that's generally not a big deal */
@@ -855,8 +865,16 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
/* Get current count */
vbl.request.type = DRM_VBLANK_RELATIVE;
-if (crtc 0)
+if (crtc == 1)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+else if (crtc 1) {
+ if (info-high_crtc_works) {
+ high_crtc = (crtc DRM_VBLANK_HIGH_CRTC_SHIFT)
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
+}
+vbl.request.type |= high_crtc;
vbl.request.sequence = 0;
ret = drmWaitVBlank(info-dri2.drm_fd, vbl);
if (ret) {
@@ -882,8 +900,16 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
if (current_msc = target_msc)
target_msc = current_msc;
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
-if (crtc 0)
+if (crtc == 1)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+ else if (crtc 1) {
+ if (info-high_crtc_works) {
+ high_crtc = (crtc DRM_VBLANK_HIGH_CRTC_SHIFT)
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
+ }
+ vbl.request.type |= high_crtc;
vbl.request.sequence = target_msc;
vbl.request.signal = (unsigned long)wait_info;
ret = drmWaitVBlank(info-dri2.drm_fd, vbl);
@@ -903,8 +929,16 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
* so we queue an event that will satisfy the divisor/remainder equation.
*/
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
-if (crtc 0)
+if (crtc == 1)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+else if (crtc 1) {
+ if (info-high_crtc_works) {
+ high_crtc = (crtc DRM_VBLANK_HIGH_CRTC_SHIFT)
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
+}
+vbl.request.type |= high_crtc;
vbl.request.sequence = current_msc - (current_msc % divisor) +
remainder;
@@ -1029,6 +1063,7 @@ static int radeon_dri2_schedule_swap(ClientPtr client,
DrawablePtr draw,
CARD64 current_msc;
BoxRec box;
RegionRec region;
+int high_crtc = 0;
/* Truncate to match kernel interfaces; means
Re: [PATCH] xf86-video-ati: vblank wait on crtc 1
On Fri, 18 Mar 2011 16:58:39 -0500 (CDT) Ilija Hadzic ihad...@research.bell-labs.com wrote: Hi Alex, Below is a patch against the master branch of xf86-video-ati that adds support for waits on vblank events on CRTCs that are greater than 1 (and thus cannot be represented using current primary/secondary flags interface). The patch makes use of GET_CAP ioctl to check whether vblanks on crtc 1 are supported by the kernel. If they are not falls back to legacy behavior. Otherwise, it uses correct crtc numbers when waiting on vblank and thus corrects the problem seen in certain multiscreen configurations. The issue was discussed on the dri-devel list in these two threads http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html The duplicated code in each function is begging to get pulled out into a separate function... -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] kernel/drm: vblank wait on crtc 1
On Fri, 18 Mar 2011 16:58:04 -0500 (CDT) Ilija Hadzic ihad...@research.bell-labs.com wrote: Hi Dave, Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the capability to wait on vblank events for CRTCs that are greater than 1 and thus cannot be represented with primary/secondary flags in the legacy interface. It was discussed on the dri-devel list in these two threads: http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html This patch extends the interface to drm_wait_vblank ioctl so that crtc1 can be represented. It also adds a new capability to drm_getcap ioctl so that the user space can check whether the new interface to drm_wait_vblank is supported (and fall back to the legacy interface if not) I like the new param check, but I'd still prefer a new ioctl to abusing the old one. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures + sporadic junk being displayed
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #2 from Andy Furniss li...@andyfurniss.entadsl.com 2011-03-18 15:18:40 PDT --- (In reply to comment #0) A few pictures of what I'm seeing are attached. Environment: Linux kernel (Linus' current git with s3tc support) libdrm, xf86-video-ati, mesa @ current git RV770 [Radeon HD 4850] [ 153.910] (II) RADEON(0): KMS Color Tiling: enabled [ 153.910] (II) RADEON(0): KMS Pageflipping: enabled [ 153.910] (II) RADEON(0): SwapBuffers wait for vsync: enabled I also see the corrupted ground on both rv670 and rv790. Running d-r-t kernel I haven't seen any other corruption yet. Starting in spectator mode the ground is OK until moving around, when patches/strips become corrupted. It is possible for corrupted ground to become normal again when viewed from a different place. I have tested with the above settings disabled and with various in game settings - it makes no difference. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] xf86-video-ati: vblank wait on crtc 1
On Fri, 18 Mar 2011, Jesse Barnes wrote:
The duplicated code in each function is begging to get pulled out into
a separate function...
How about this then ?
diff --git a/src/radeon.h b/src/radeon.h
index a6d20d7..1a746c7 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -931,6 +931,9 @@ typedef struct {
RADEONFBLayoutCurrentLayout;
+#ifdef RADEON_DRI2
+Bool high_crtc_works;
+#endif
#ifdef XF86DRI
Bool directRenderingEnabled;
Bool directRenderingInited;
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index 66df03c..c461469 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -771,6 +771,24 @@ cleanup:
free(event);
}
+static drmVBlankSeqType populate_vbl_request_type(RADEONInfoPtr info, int crtc)
+{
+int high_crtc = 0;
+drmVBlankSeqType type = 0;
+
+if (crtc == 1)
+type |= DRM_VBLANK_SECONDARY;
+else if (crtc 1) {
+ if (info-high_crtc_works) {
+ high_crtc = (crtc DRM_VBLANK_HIGH_CRTC_SHIFT)
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else
+ type |= DRM_VBLANK_SECONDARY;
+}
+type |= high_crtc;
+return type;
+}
+
/*
* Get current frame count and frame count timestamp, based on drawable's
* crtc.
@@ -791,8 +809,7 @@ static int radeon_dri2_get_msc(DrawablePtr draw, CARD64
*ust, CARD64 *msc)
return TRUE;
}
vbl.request.type = DRM_VBLANK_RELATIVE;
-if (crtc 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = 0;
ret = drmWaitVBlank(info-dri2.drm_fd, vbl);
@@ -855,8 +872,7 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
/* Get current count */
vbl.request.type = DRM_VBLANK_RELATIVE;
-if (crtc 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = 0;
ret = drmWaitVBlank(info-dri2.drm_fd, vbl);
if (ret) {
@@ -882,8 +898,7 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
if (current_msc = target_msc)
target_msc = current_msc;
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
-if (crtc 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+ vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = target_msc;
vbl.request.signal = (unsigned long)wait_info;
ret = drmWaitVBlank(info-dri2.drm_fd, vbl);
@@ -903,8 +918,7 @@ static int radeon_dri2_schedule_wait_msc(ClientPtr client,
DrawablePtr draw,
* so we queue an event that will satisfy the divisor/remainder equation.
*/
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
-if (crtc 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = current_msc - (current_msc % divisor) +
remainder;
@@ -1068,8 +1082,7 @@ static int radeon_dri2_schedule_swap(ClientPtr client,
DrawablePtr draw,
/* Get current count */
vbl.request.type = DRM_VBLANK_RELATIVE;
-if (crtc 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = 0;
ret = drmWaitVBlank(info-dri2.drm_fd, vbl);
if (ret) {
@@ -,8 +1124,7 @@ static int radeon_dri2_schedule_swap(ClientPtr client,
DrawablePtr draw,
*/
if (flip == 0)
vbl.request.type |= DRM_VBLANK_NEXTONMISS;
-if (crtc 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+ vbl.request.type |= populate_vbl_request_type(info, crtc);
/* If target_msc already reached or passed, set it to
* current_msc to ensure we return a reasonable value back
@@ -1145,8 +1157,7 @@ static int radeon_dri2_schedule_swap(ClientPtr client,
DrawablePtr draw,
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
if (flip == 0)
vbl.request.type |= DRM_VBLANK_NEXTONMISS;
-if (crtc 0)
-vbl.request.type |= DRM_VBLANK_SECONDARY;
+vbl.request.type |= populate_vbl_request_type(info, crtc);
vbl.request.sequence = current_msc - (current_msc % divisor) +
remainder;
@@ -1217,6 +1228,7 @@ radeon_dri2_screen_init(ScreenPtr pScreen)
DRI2InfoRec dri2_info = { 0 };
#ifdef USE_DRI2_SCHEDULING
const char *driverNames[1];
+uint64_t cap_value;
#endif
if (!info-useEXA) {
@@ -1248,6 +1260,7 @@ radeon_dri2_screen_init(ScreenPtr pScreen)
#endif
dri2_info.CopyRegion = radeon_dri2_copy_region;
+info-high_crtc_works = FALSE;
#ifdef USE_DRI2_SCHEDULING
if (info-dri-pKernelDRMVersion-version_minor = 4) {
dri2_info.version = 4;
@@ -1261,6 +1274,20 @@ radeon_dri2_screen_init(ScreenPtr pScreen)
Re: [PATCH] kernel/drm: vblank wait on crtc 1
On Fri, 18 Mar 2011, Jesse Barnes wrote: I like the new param check, but I'd still prefer a new ioctl to abusing the old one. It's not abusing it but extending the interface in a backwards-compatible manner. Introducing a new one would result in two ioctls that essentially do the same thing, which I don't like. -- Ilija ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] kernel/drm: vblank wait on crtc 1
On Fri, 18 Mar 2011 18:13:11 -0500 (CDT) Ilija Hadzic ihad...@research.bell-labs.com wrote: On Fri, 18 Mar 2011, Jesse Barnes wrote: I like the new param check, but I'd still prefer a new ioctl to abusing the old one. It's not abusing it but extending the interface in a backwards-compatible manner. Introducing a new one would result in two ioctls that essentially do the same thing, which I don't like. Yes abusing was a strong word; I just don't like encoding crtc numbers in a bitfield, when we just use ints everywhere else. Not a big deal, Dave will make the final call. Thanks for doing this work. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
