[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 --- Comment #9 from Dave Airlie 2011-03-19 22:07:30 --- I'm having trouble reconciling this with the graphics driver. a) you claim it happens with fglrx as well, there is nothing shared between them (so it can't be a common gpu bug) b) nothing is leaking according to that debug info in anywhere obvious. One last test would be unload the gpu stack to see what happens got to runlevel 3 or anywhere X isn't rnunig echo 0 > /sys/class/vtconsole/vtcon1/bind rmmod radeon ttm drm_kms_helper drm see if memory is still gone. maybe you can watch /proc/slabinfo to see where the memory might be going. It might also just be page cache from the pdf loading, does echo 3 > /proc/sys/vm/drop_caches help? -- 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. > On Fri, 18 Mar 2011, Jesse Barnes wrote: >> > 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 Hi A clean solution with int's in a new ioctl() would be certainly nicer. But if we'd define a waitvblank ioctl() v2, we should probably fix other limitations of the old one as well. E.g., the kernel's vblank counter is only 32 bit. The api / oml_sync_control extension / mesa/ x etc. expose a 64 bit vblank counter. At the moment we work around this by masking out the upper 32 bit in the ddx, accepting some small skipped frame glitch every couple of months of uptime when the "64 bit" counter wraps around already at 32 bits. This is something we should probably fix in a ioctl() v2 as well. Take this just as my vote for Ilja's solution as a workable stop-gap measure for fixing an existing problem until we implement a more permanent solution for a new ioctl(). best, -mario
[Bug 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares
https://bugs.freedesktop.org/show_bug.cgi?id=32639 alessandro.sturniolo at gmail.com changed: What|Removed |Added Version|7.8 |7.10 --- Comment #8 from alessandro.sturniolo at gmail.com 2011-03-19 18:13:37 PDT --- Ok, I've enabled gallium with llvm support. Now neverball, from 1 fps with gallium (2 fps with swrast) is jumped to 15 fps, and it is more playable. Thanks :-) But the performance gap with r300 driver without gallium (from Mesa 7.6 sources) is of a factor of about 2~2.5 times and on limited hardware like my Radeon X1200 this is frustrating :-( The fglrx driver, dropped support for this family of video card from March 2009. -- 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, Mar 18, 2011 at 5:58 PM, 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)
>
> Regards,
>
> Ilija
>
>
> Reviewed-by: Mario Kleiner
> Acked-by: Mario Kleiner
Ilija, please add your signed-off-by.
Alex
>
> 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] xf86-video-ati: vblank wait on crtc > 1
On Fri, Mar 18, 2011 at 5:58 PM, 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
>
> regards,
>
> Ilija
>
> Reviewed-by: Mario Kleiner
> Acked-by: Mario Kleiner
Reviewed-by: Alex Deucher
Tested-by: Alex Deucher
>
> 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 {
>
> ? ? RADEONFBLayout ? ?CurrentLayout;
>
> +#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 %
[PATCH] libdrm: vblank wait on crtc > 1
On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
wrote:
>
> 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
Reviewed-by: Alex Deucher
Tested-by: Alex Deucher
>
>
> 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
On Fri, Mar 18, 2011 at 5:58 PM, 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)
>
> Regards,
>
> Ilija
>
>
> Reviewed-by: Mario Kleiner
> Acked-by: Mario Kleiner
Looks good to me.
Reviewed-by: Alex Deucher
Tested-by: Alex Deucher
>
> 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__
>
[Bug 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares
https://bugs.freedesktop.org/show_bug.cgi?id=32639 --- Comment #7 from Alex Deucher 2011-03-19 15:03:59 PDT --- (In reply to comment #6) > I've google a little bit. > The r300g is the gallium driver for r300? > > The problem is that gallium actually is too slow. On my notebook, is much > faster the swrast driver, but if I disable gallium, I get the artifacts. > > At this time, on this kind of hardware (I've a Radeon X1200), gallium is > almost > unusable. enable llvm in your mesa build: --enable-gallium-llvm -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares
https://bugs.freedesktop.org/show_bug.cgi?id=32639 --- Comment #6 from alessandro.sturniolo at gmail.com 2011-03-19 14:54:54 PDT --- I've google a little bit. The r300g is the gallium driver for r300? The problem is that gallium actually is too slow. On my notebook, is much faster the swrast driver, but if I disable gallium, I get the artifacts. At this time, on this kind of hardware (I've a Radeon X1200), gallium is almost unusable. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares
https://bugs.freedesktop.org/show_bug.cgi?id=32639 --- Comment #5 from alessandro.sturniolo at gmail.com 2011-03-19 14:49:17 PDT --- I've recently update my system to openSuSE 11.4, so I've installed recent Mesa 7.10 (RPM package is Mesa-7.10-59.3 from http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.4 repository). The package is compiled with gallium enabled by default, then the artifacts aren't present. Instead when I recompile the package from openSuSE SRPM sources with gallium disabled, the artifacts reappear. I've tested with r300 driver, because I was not able to found and enable r300g on Mesa 7.10. -- 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 Sat, Mar 19, 2011 at 1:30 PM, Mario Kleiner 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. > >> On Fri, 18 Mar 2011, Jesse Barnes wrote: >>> > >> 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 > > Hi > > A clean solution with int's in a new ioctl() would be certainly nicer. But > if we'd define a waitvblank ioctl() v2, we should probably fix other > limitations of the old one as well. > > E.g., the kernel's vblank counter is only 32 bit. The api / oml_sync_control > extension / mesa/ x etc. expose a 64 bit vblank counter. At the moment we > work around this by masking out the upper 32 bit in the ddx, accepting some > small skipped frame glitch every couple of months of uptime when the "64 > bit" counter wraps around already at 32 bits. This is something we should > probably fix in a ioctl() v2 as well. > > Take this just as my vote for Ilja's solution as a workable stop-gap measure > for fixing an existing problem until we implement a more permanent solution > for a new ioctl(). I agree. I think this is a good stop-gap to support >2 crtcs until we design a better ioctl. Alex > > best, > -mario > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[Bug 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 --- Comment #6 from Vaclav Cermak 2011-03-19 12:50:15 PDT --- disnel at infimi:~$ LIBGL_DEBUG=verbose glxgears libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /etc/drirc: No such file or directory. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 304 frames in 5.0 seconds = 60.672 FPS 303 frames in 5.0 seconds = 60.560 FPS 302 frames in 5.0 seconds = 60.368 FPS ^C disnel at infimi:~$ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 --- Comment #5 from Marek Ol??k 2011-03-19 12:42:19 PDT --- (In reply to comment #4) > glxgears does not write anything interesting: > > > disnel at infimi:~$ RADEON_DEBUG=info glxgears > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > 304 frames in 5.0 seconds = 60.708 FPS > 303 frames in 5.0 seconds = 60.565 FPS > ^C > disnel at infimi:~$ > > dmesg attached. Texture has 24bit per pixel. You seem to be using indirect rendering. Please post the output of: LIBGL_DEBUG=verbose glxgears -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Future desktop on dumb frame buffers?
As noone responded to my question in
http://www.spinics.net/lists/dri-devel/msg08851.html
(yes, it was a bit hidden in a thread), I'm asking it here again (and
also on the Wayland
mailing list).
Basically I'm still puzzled about this KMS thing. If the name "Kernel
Mode Setting"
covers it, then how does it compare to plain fbdev? Just additional frame buffer
memory management?
Also, some people may remember we did have kernel messages (e.g. oops, panic)
on graphical consoles with fbdev, until people started not liking them
showing up
on their X desktops...
Furthermore, everybody states that "future desktop" (that's
http://wayland.freedesktop.org/)
will require KMS drivers.
How do/will we handle this on dumb frame buffers? It's not like we can't do
"advanced" things like compositing using the CPU. Transparency may stretch
it a bit on lower end CPUs, but you don't always need that.
Thanks for your answers and comments!
Gr{oetje,eeting}s,
? ? ? ? ? ? ? ? ? ? ? ? Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds
[Bug 35045] BUG at ttm_bo.c:272! (ttm_bo_ref_bug -> ttm_bo_list_ref_sub+0x28/0x30)
https://bugs.freedesktop.org/show_bug.cgi?id=35045 --- Comment #3 from Dave Gilbert 2011-03-19 11:14:22 PDT --- Seems to be gone on todays drm-next (commit c87a8d8dcd2587c203f3dd8a3c5c15d1e128ec0d ) with current ubuntu xorg-edgers; seems to be back to my original bug of *ERROR* Failed to parse relocation -35! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 Alex Deucher changed: What|Removed |Added Attachment #44615|application/octet-stream|text/plain mime type|| Attachment #44615|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Future desktop on dumb frame buffers?
On Sat, Mar 19, 2011 at 6:20 AM, Geert Uytterhoeven
wrote:
> As noone responded to my question in
> http://www.spinics.net/lists/dri-devel/msg08851.html
> (yes, it was a bit hidden in a thread), I'm asking it here again (and
> also on the Wayland
> mailing list).
>
> Basically I'm still puzzled about this KMS thing. If the name "Kernel
> Mode Setting"
> covers it, then how does it compare to plain fbdev? Just additional frame
> buffer
> memory management?
> Also, some people may remember we did have kernel messages (e.g. oops, panic)
> on graphical consoles with fbdev, until people started not liking them
> showing up
> on their X desktops...
The KMS part of DRM has nothing to do with acceleration. So it could
be implemented on a dumb framebuffer. KMS is just about mode-setting,
and configuring framebuffer (memory) that is scanned out to one or
more displays.
BR,
-R
> Furthermore, everybody states that "future desktop" (that's
> http://wayland.freedesktop.org/)
> will require KMS drivers.
> How do/will we handle this on dumb frame buffers? It's not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.
>
> Thanks for your answers and comments!
>
> Gr{oetje,eeting}s,
>
> ? ? ? ? ? ? ? ? ? ? ? ? Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
> linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds
> ___
> dri-devel mailing list
> dri-devel at 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 #8 from Kevin 2011-03-19 09:17:19 --- The attached "debug info" above is output after logging out of X (I still had about ~30MB from root processes). It includes what Dave asked for. FYI, I haven't rebooted since my last post. $ free -m total used free sharedbuffers cached Mem: 5920 4279 1641 0212 2547 -/+ buffers/cache: 1519 4401 Swap: 7998 0 7998 -- 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 #7 from Kevin 2011-03-19 09:15:54 --- Created an attachment (id=51232) --> (https://bugzilla.kernel.org/attachment.cgi?id=51232) debug info -- 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 #6 from Dave Airlie 2011-03-19 07:17:08 --- how about cat /sys/kernel/debug/dri/0/ttm_page_pool and /sys/class/drm/ttm/memory_accounting/*/* -- 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 #5 from Dave Airlie 2011-03-19 07:16:26 --- how about cat /sys/kernel/debug/dri/0/ttm_page_pool -- 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 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 --- Comment #4 from Vaclav Cermak 2011-03-19 06:40:41 PDT --- glxgears does not write anything interesting: disnel at infimi:~$ RADEON_DEBUG=info glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 304 frames in 5.0 seconds = 60.708 FPS 303 frames in 5.0 seconds = 60.565 FPS ^C disnel at infimi:~$ dmesg attached. Texture has 24bit per pixel. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 --- Comment #3 from Vaclav Cermak 2011-03-19 06:39:11 PDT --- Created an attachment (id=44615) --> (https://bugs.freedesktop.org/attachment.cgi?id=44615) dmesg output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 --- Comment #2 from Marek Ol??k 2011-03-19 05:52:03 PDT --- Also please attach your dmesg. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 --- Comment #1 from Marek Ol??k 2011-03-19 05:41:01 PDT --- When the CS space validation fails, it means there is not enough space either in the video memory or in the GPU-accessible system memory. How many bits per pixel does the texture have? 4096x4096 is the maximum hardware limit. Any larger texture is not loaded and OpenGL will return an error to the application (but Blender seems to ignore it), and can draw either a black or white color instead. Please post the output of: RADEON_DEBUG=info glxgears I am interested in the lines beginning with "r300:" -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35446] New: Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 Summary: Problem with Blender and big textures Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: disnel at disnel.com When I try to use a big texture (4096x4096) in blender 2.56beta, I get following error: r300: CS space validation failed. (not enough memory?) Skipping rendering. and no texture is displayed. Smaller textures (tested 2048x2048) works fine. Also with LIBGL_ALWAYS_SOFTWARE=1 it works fine. When I try bigger texture (8000x6048), I get no error, but also no texture and I can see screen corruption with Compiz (bad window shadows, applets on panel, background on 2nd display etc). Blender files with textures and image with corrupted display are here http://devel.disnel.com/tmp/ (I dont'know, how big files can I attach here). I'am using mesa 7.11.0-git2011016+gallium from xorg-edgers with Ubuntu 10.10 x86_64. My graphics card is Radeon X1400. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32911] [RADEON:KMS:MEMCORRUPTION] random memory corruption if using more than 4GiB of RAM on Core i7/P55
https://bugs.freedesktop.org/show_bug.cgi?id=32911 Siarhei Siamashka changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #5 from Siarhei Siamashka 2011-03-19 02:56:03 PDT --- After all, it looks like it is a hardware problem on my side. Experimenting with 'memmap' option simulating 4GiB setup precisely does not help when all 8GiB are installed. Also reducing RAM speed from DDR3-1333 to DDR3-1066 or DDR3-800 makes the problem significantly harder to reproduce, but does not eliminate it completely. And looking around in various hardware forums, reliability with all four DIMM modules installed seems to be a rather common problem. Appears that llvmpipe is just a very good memory checker, putting a lot of stress on all CPU cores and memory controller, exposing problems which don't happen in other use cases. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31412] radeon memory leak
https://bugzilla.kernel.org/show_bug.cgi?id=31412 --- Comment #5 from Dave Airlie airl...@linux.ie 2011-03-19 07:16:26 --- how about cat /sys/kernel/debug/dri/0/ttm_page_pool -- 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 #6 from Dave Airlie airl...@linux.ie 2011-03-19 07:17:08 --- how about cat /sys/kernel/debug/dri/0/ttm_page_pool and /sys/class/drm/ttm/memory_accounting/*/* -- 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 #7 from Kevin kjs...@gmail.com 2011-03-19 09:15:54 --- Created an attachment (id=51232) -- (https://bugzilla.kernel.org/attachment.cgi?id=51232) debug info -- 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 #8 from Kevin kjs...@gmail.com 2011-03-19 09:17:19 --- The attached debug info above is output after logging out of X (I still had about ~30MB from root processes). It includes what Dave asked for. FYI, I haven't rebooted since my last post. $ free -m total used free sharedbuffers cached Mem: 5920 4279 1641 0212 2547 -/+ buffers/cache: 1519 4401 Swap: 7998 0 7998 -- 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 32911] [RADEON:KMS:MEMCORRUPTION] random memory corruption if using more than 4GiB of RAM on Core i7/P55
https://bugs.freedesktop.org/show_bug.cgi?id=32911 Siarhei Siamashka siarhei.siamas...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #5 from Siarhei Siamashka siarhei.siamas...@gmail.com 2011-03-19 02:56:03 PDT --- After all, it looks like it is a hardware problem on my side. Experimenting with 'memmap' option simulating 4GiB setup precisely does not help when all 8GiB are installed. Also reducing RAM speed from DDR3-1333 to DDR3-1066 or DDR3-800 makes the problem significantly harder to reproduce, but does not eliminate it completely. And looking around in various hardware forums, reliability with all four DIMM modules installed seems to be a rather common problem. Appears that llvmpipe is just a very good memory checker, putting a lot of stress on all CPU cores and memory controller, exposing problems which don't happen in other use cases. -- 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 35446] New: Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 Summary: Problem with Blender and big textures Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: dis...@disnel.com When I try to use a big texture (4096x4096) in blender 2.56beta, I get following error: r300: CS space validation failed. (not enough memory?) Skipping rendering. and no texture is displayed. Smaller textures (tested 2048x2048) works fine. Also with LIBGL_ALWAYS_SOFTWARE=1 it works fine. When I try bigger texture (8000x6048), I get no error, but also no texture and I can see screen corruption with Compiz (bad window shadows, applets on panel, background on 2nd display etc). Blender files with textures and image with corrupted display are here http://devel.disnel.com/tmp/ (I dont'know, how big files can I attach here). I'am using mesa 7.11.0-git2011016+gallium from xorg-edgers with Ubuntu 10.10 x86_64. My graphics card is Radeon X1400. -- 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
Future desktop on dumb frame buffers?
As noone responded to my question in
http://www.spinics.net/lists/dri-devel/msg08851.html
(yes, it was a bit hidden in a thread), I'm asking it here again (and
also on the Wayland
mailing list).
Basically I'm still puzzled about this KMS thing. If the name Kernel
Mode Setting
covers it, then how does it compare to plain fbdev? Just additional frame buffer
memory management?
Also, some people may remember we did have kernel messages (e.g. oops, panic)
on graphical consoles with fbdev, until people started not liking them
showing up
on their X desktops...
Furthermore, everybody states that future desktop (that's
http://wayland.freedesktop.org/)
will require KMS drivers.
How do/will we handle this on dumb frame buffers? It's not like we can't do
advanced things like compositing using the CPU. Transparency may stretch
it a bit on lower end CPUs, but you don't always need that.
Thanks for your answers and comments!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 --- Comment #1 from Marek Olšák mar...@gmail.com 2011-03-19 05:41:01 PDT --- When the CS space validation fails, it means there is not enough space either in the video memory or in the GPU-accessible system memory. How many bits per pixel does the texture have? 4096x4096 is the maximum hardware limit. Any larger texture is not loaded and OpenGL will return an error to the application (but Blender seems to ignore it), and can draw either a black or white color instead. Please post the output of: RADEON_DEBUG=info glxgears I am interested in the lines beginning with r300: -- 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 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 --- Comment #2 from Marek Olšák mar...@gmail.com 2011-03-19 05:52:03 PDT --- Also please attach your dmesg. -- 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 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 --- Comment #3 from Vaclav Cermak dis...@disnel.com 2011-03-19 06:39:11 PDT --- Created an attachment (id=44615) -- (https://bugs.freedesktop.org/attachment.cgi?id=44615) dmesg output -- 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 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 --- Comment #4 from Vaclav Cermak dis...@disnel.com 2011-03-19 06:40:41 PDT --- glxgears does not write anything interesting: disnel@infimi:~$ RADEON_DEBUG=info glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 304 frames in 5.0 seconds = 60.708 FPS 303 frames in 5.0 seconds = 60.565 FPS ^C disnel@infimi:~$ dmesg attached. Texture has 24bit per pixel. -- 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: Future desktop on dumb frame buffers?
On Sat, Mar 19, 2011 at 6:20 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
As noone responded to my question in
http://www.spinics.net/lists/dri-devel/msg08851.html
(yes, it was a bit hidden in a thread), I'm asking it here again (and
also on the Wayland
mailing list).
Basically I'm still puzzled about this KMS thing. If the name Kernel
Mode Setting
covers it, then how does it compare to plain fbdev? Just additional frame
buffer
memory management?
Also, some people may remember we did have kernel messages (e.g. oops, panic)
on graphical consoles with fbdev, until people started not liking them
showing up
on their X desktops...
The KMS part of DRM has nothing to do with acceleration. So it could
be implemented on a dumb framebuffer. KMS is just about mode-setting,
and configuring framebuffer (memory) that is scanned out to one or
more displays.
BR,
-R
Furthermore, everybody states that future desktop (that's
http://wayland.freedesktop.org/)
will require KMS drivers.
How do/will we handle this on dumb frame buffers? It's not like we can't do
advanced things like compositing using the CPU. Transparency may stretch
it a bit on lower end CPUs, but you don't always need that.
Thanks for your answers and comments!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like
that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
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, 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. On Fri, 18 Mar 2011, Jesse Barnes wrote: 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 Hi A clean solution with int's in a new ioctl() would be certainly nicer. But if we'd define a waitvblank ioctl() v2, we should probably fix other limitations of the old one as well. E.g., the kernel's vblank counter is only 32 bit. The api / oml_sync_control extension / mesa/ x etc. expose a 64 bit vblank counter. At the moment we work around this by masking out the upper 32 bit in the ddx, accepting some small skipped frame glitch every couple of months of uptime when the 64 bit counter wraps around already at 32 bits. This is something we should probably fix in a ioctl() v2 as well. Take this just as my vote for Ilja's solution as a workable stop-gap measure for fixing an existing problem until we implement a more permanent solution for a new ioctl(). best, -mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #44615|application/octet-stream|text/plain mime type|| Attachment #44615|0 |1 is patch|| -- 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] kernel/drm: vblank wait on crtc 1
On Fri, Mar 18, 2011 at 5:58 PM, 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)
Regards,
Ilija
Reviewed-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
Acked-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
Looks good to me.
Reviewed-by: Alex Deucher alexdeuc...@gmail.com
Tested-by: Alex Deucher alexdeuc...@gmail.com
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
Re: [PATCH] libdrm: vblank wait on crtc 1
On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:
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
Reviewed-by: Alex Deucher alexdeuc...@gmail.com
Tested-by: Alex Deucher alexdeuc...@gmail.com
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
Re: [PATCH] xf86-video-ati: vblank wait on crtc 1
On Fri, Mar 18, 2011 at 5:58 PM, 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
regards,
Ilija
Reviewed-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
Acked-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
Reviewed-by: Alex Deucher alexdeuc...@gmail.com
Tested-by: Alex Deucher alexdeuc...@gmail.com
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 {
RADEONFBLayout CurrentLayout;
+#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) +
[Bug 35446] Problem with Blender and big textures
https://bugs.freedesktop.org/show_bug.cgi?id=35446 --- Comment #6 from Vaclav Cermak dis...@disnel.com 2011-03-19 12:50:15 PDT --- disnel@infimi:~$ LIBGL_DEBUG=verbose glxgears libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /etc/drirc: No such file or directory. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 304 frames in 5.0 seconds = 60.672 FPS 303 frames in 5.0 seconds = 60.560 FPS 302 frames in 5.0 seconds = 60.368 FPS ^C disnel@infimi:~$ -- 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] kernel/drm: vblank wait on crtc 1
On Fri, Mar 18, 2011 at 5:58 PM, 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)
Regards,
Ilija
Reviewed-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
Acked-by: Mario Kleiner mario.kleiner at tuebingen.mpg.de
Ilija, please add your signed-off-by.
Alex
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
[Bug 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares
https://bugs.freedesktop.org/show_bug.cgi?id=32639 --- Comment #5 from alessandro.sturni...@gmail.com 2011-03-19 14:49:17 PDT --- I've recently update my system to openSuSE 11.4, so I've installed recent Mesa 7.10 (RPM package is Mesa-7.10-59.3 from http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.4 repository). The package is compiled with gallium enabled by default, then the artifacts aren't present. Instead when I recompile the package from openSuSE SRPM sources with gallium disabled, the artifacts reappear. I've tested with r300 driver, because I was not able to found and enable r300g on Mesa 7.10. -- 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 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares
https://bugs.freedesktop.org/show_bug.cgi?id=32639 --- Comment #6 from alessandro.sturni...@gmail.com 2011-03-19 14:54:54 PDT --- I've google a little bit. The r300g is the gallium driver for r300? The problem is that gallium actually is too slow. On my notebook, is much faster the swrast driver, but if I disable gallium, I get the artifacts. At this time, on this kind of hardware (I've a Radeon X1200), gallium is almost unusable. -- 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 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares
https://bugs.freedesktop.org/show_bug.cgi?id=32639 --- Comment #7 from Alex Deucher ag...@yahoo.com 2011-03-19 15:03:59 PDT --- (In reply to comment #6) I've google a little bit. The r300g is the gallium driver for r300? The problem is that gallium actually is too slow. On my notebook, is much faster the swrast driver, but if I disable gallium, I get the artifacts. At this time, on this kind of hardware (I've a Radeon X1200), gallium is almost unusable. enable llvm in your mesa build: --enable-gallium-llvm -- 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 #9 from Dave Airlie airl...@linux.ie 2011-03-19 22:07:30 --- I'm having trouble reconciling this with the graphics driver. a) you claim it happens with fglrx as well, there is nothing shared between them (so it can't be a common gpu bug) b) nothing is leaking according to that debug info in anywhere obvious. One last test would be unload the gpu stack to see what happens got to runlevel 3 or anywhere X isn't rnunig echo 0 /sys/class/vtconsole/vtcon1/bind rmmod radeon ttm drm_kms_helper drm see if memory is still gone. maybe you can watch /proc/slabinfo to see where the memory might be going. It might also just be page cache from the pdf loading, does echo 3 /proc/sys/vm/drop_caches help? -- 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 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares
https://bugs.freedesktop.org/show_bug.cgi?id=32639 alessandro.sturni...@gmail.com changed: What|Removed |Added Version|7.8 |7.10 --- Comment #8 from alessandro.sturni...@gmail.com 2011-03-19 18:13:37 PDT --- Ok, I've enabled gallium with llvm support. Now neverball, from 1 fps with gallium (2 fps with swrast) is jumped to 15 fps, and it is more playable. Thanks :-) But the performance gap with r300 driver without gallium (from Mesa 7.6 sources) is of a factor of about 2~2.5 times and on limited hardware like my Radeon X1200 this is frustrating :-( The fglrx driver, dropped support for this family of video card from March 2009. -- 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
