[Intel-gfx] [BUG] Minecraft graphics issues
Hi! What about adding Minecraft to the officially tested games list for the released graphics package? It's one of the most played games on Linux i think, and a lot of users are experiencing graphical problems that don't occur in windows or mac. Two screenshots of my Minecraft graphics issue: http://img7.imagebanana.com/img/5900nd4k/20111206_08.34.06.png http://img6.imagebanana.com/img/2pl3w1ky/20111206_08.39.38.png The color of the error equals the skybox color. After taking the screenshot, the errors are gone for ~10 seconds and FPS increase noticeably. Then it comes back and looks awful again. The error occures in fullscreen and windowed mode. Maybe this is the relevant bug in launchpad: https://bugs.launchpad.net/mesa/+bug/829086 Another thing is that my Minecraft on view distance short has about 20-30 fps, a friend's Macbook Pro (core i5-2420M) renders Minecraft at 40-50 fps with view distance far. (We have both the exactly same graphics chip (HD3000) and my CPU is even better) My system: core i5-2520M with HD3000 IGP 8GB RAM (how much graphics memory is shared then?) 1366x786 LVDS IPS display Software: linux 3.1.4-1 mesa 7.11.2-1 xf86-video-intel 2.17.0-2 libdrm 2.4.27-1 libva 1.0.15-1 libva-driver-intel 1.0.15-1 Minecraft 1.0.0 Jonas Jelten On 12/06/2011 02:03 AM, Eugeni Dodonov wrote: Hi, We'd like to announce Intel 2011Q4 graphics package, focused on performance and stability improvements in the Intel Linux Graphics stack. Please check http://intellinuxgraphics.org/2011Q4.html for the recommended stack, list of new features and known issues. I'd also like to thank all the developers, community, our users and testers for helping us to improve the drivers. Thanks a lot for all your work, help and support! And as usual, if you find any new issues, please let as know by filing bugs following the http://intellinuxgraphics.org/how_to_report_bug.html guidelines. Thanks, Eugeni Dodonov Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Force sync command ordering (Gen6+)
On Sat, 22 Oct 2011 19:41:24 -0700, Ben Widawsky b...@bwidawsk.net wrote: The docs say this is required for Gen7, and since the bit was added for Gen6, we are also setting it there pit pf paranoia. Particularly as Chris points out, if PIPE_CONTROL counts as a 3d state packet. This was found through doc inspection by Ken and applies to Gen6+; Cc: Keith Packard kei...@keithp.com Reported-by: Kenneth Graunke kenn...@whitecape.org Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Eric Anholt e...@anholt.net however, it doesn't appear to help Ivybridge IRQ troubles. pgpSiTXZXmlNJ.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Force sync command ordering (Gen6+)
On Wed, 07 Dec 2011 10:35:45 -0800
Eric Anholt e...@anholt.net wrote:
On Sat, 22 Oct 2011 19:41:24 -0700, Ben Widawsky b...@bwidawsk.net wrote:
The docs say this is required for Gen7, and since the bit was added for
Gen6, we are also setting it there pit pf paranoia. Particularly as
Chris points out, if PIPE_CONTROL counts as a 3d state packet.
This was found through doc inspection by Ken and applies to Gen6+;
Cc: Keith Packard kei...@keithp.com
Reported-by: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Eric Anholt e...@anholt.net
however, it doesn't appear to help Ivybridge IRQ troubles.
You could try something like the below to force the use of PIPE_NOTIFY
instead. Only lightly tested on IVB when we had lots of other bugs, so
I'm not sure if it works at all.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 60e4b9e..ce045a8 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -62,7 +62,7 @@ module_param_named(semaphores, i915_semaphores, int, 0600);
MODULE_PARM_DESC(semaphores,
Use semaphores for inter-ring sync (default: false));
-unsigned int i915_enable_rc6 __read_mostly = 1;
+unsigned int i915_enable_rc6 __read_mostly = 0;
module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600);
MODULE_PARM_DESC(i915_enable_rc6,
Enable power-saving render C-state 6 (default: true));
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 02f96fd..4ab2e90 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -568,7 +568,7 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
atomic_inc(dev_priv-irq_received);
if (IS_GEN6(dev))
- bsd_usr_interrupt = GT_GEN6_BSD_USER_INTERRUPT;
+ bsd_usr_interrupt = GT_GEN6_BSD_USER_INTERRUPT | GT_PIPE_NOTIFY;
/* disable master interrupt before clearing iir */
de_ier = I915_READ(DEIER);
@@ -602,7 +602,7 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
notify_ring(dev, dev_priv-ring[RCS]);
if (gt_iir bsd_usr_interrupt)
notify_ring(dev, dev_priv-ring[VCS]);
- if (gt_iir GT_BLT_USER_INTERRUPT)
+ if (gt_iir (GT_BLT_USER_INTERRUPT | GT_PIPE_NOTIFY))
notify_ring(dev, dev_priv-ring[BCS]);
if (de_iir DE_GSE)
@@ -1810,7 +1810,8 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
render_irqs =
GT_USER_INTERRUPT |
GT_GEN6_BSD_USER_INTERRUPT |
- GT_BLT_USER_INTERRUPT;
+ GT_BLT_USER_INTERRUPT |
+ GT_PIPE_NOTIFY;
else
render_irqs =
GT_USER_INTERRUPT |
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 47b9b27..0a67334 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -292,8 +292,7 @@ static int init_render_ring(struct intel_ring_buffer *ring)
I915_WRITE(MI_MODE, mode);
}
- if (INTEL_INFO(dev)-gen = 6) {
- } else if (IS_GEN5(dev)) {
+ if (INTEL_INFO(dev)-gen = 5) {
ret = init_pipe_control(ring);
if (ret)
return ret;
@@ -411,10 +410,13 @@ pc_render_add_request(struct intel_ring_buffer *ring,
* incoherence by flushing the 6 PIPE_NOTIFY buffers out to
* memory before requesting an interrupt.
*/
- ret = intel_ring_begin(ring, 32);
+ ret = intel_ring_begin(ring, 38);
if (ret)
return ret;
+ update_semaphore(ring, 0, seqno);
+ update_semaphore(ring, 1, seqno);
+
intel_ring_emit(ring, GFX_OP_PIPE_CONTROL | PIPE_CONTROL_QW_WRITE |
PIPE_CONTROL_WC_FLUSH | PIPE_CONTROL_TC_FLUSH);
intel_ring_emit(ring, pc-gtt_offset | PIPE_CONTROL_GLOBAL_GTT);
@@ -1289,12 +1291,10 @@ int intel_init_render_ring_buffer(struct drm_device
*dev)
struct intel_ring_buffer *ring = dev_priv-ring[RCS];
*ring = render_ring;
- if (INTEL_INFO(dev)-gen = 6) {
- ring-add_request = gen6_add_request;
+ if (INTEL_INFO(dev)-gen = 5) {
+ ring-add_request = pc_render_add_request;
ring-irq_get = gen6_render_ring_get_irq;
ring-irq_put = gen6_render_ring_put_irq;
- } else if (IS_GEN5(dev)) {
- ring-add_request = pc_render_add_request;
ring-get_seqno = pc_render_get_seqno;
}
signature.asc
Description: PGP signature
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Force sync command ordering (Gen6+)
On Wed, 7 Dec 2011 10:38:41 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 07 Dec 2011 10:35:45 -0800 Eric Anholt e...@anholt.net wrote: On Sat, 22 Oct 2011 19:41:24 -0700, Ben Widawsky b...@bwidawsk.net wrote: The docs say this is required for Gen7, and since the bit was added for Gen6, we are also setting it there pit pf paranoia. Particularly as Chris points out, if PIPE_CONTROL counts as a 3d state packet. This was found through doc inspection by Ken and applies to Gen6+; Cc: Keith Packard kei...@keithp.com Reported-by: Kenneth Graunke kenn...@whitecape.org Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Eric Anholt e...@anholt.net however, it doesn't appear to help Ivybridge IRQ troubles. You could try something like the below to force the use of PIPE_NOTIFY instead. Only lightly tested on IVB when we had lots of other bugs, so I'm not sure if it works at all. Though if it's the blit ring hanging, you'd have to try using a flush_dw notify (if such a thing exists) instead... I don't think the BLT ring gets much exercise outside Linux so there could well be some bugs. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: add SNB and IVB video sprite support v2
On Fri, 18 Nov 2011 08:53:30 +0800 Lan, Hai hai@intel.com wrote: + /* +* We can take a larger source and scale it down, but +* only so much... 16x is the max on SNB. +*/ + if (((src_w * src_h) / (crtc_w * crtc_h)) intel_plane-max_downscale) + return -EINVAL; + [Lan, Hai] if crtc_w or crtc_h = 0, the drm driver will crash. Pulled this in with a couple of changes; please check out the latest code and make sure it's ok. Thanks, -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Plane support for SNB and IVB
I think the core support is ready now, but I'd like feedback on the color key ioctl. It would be good to have a way to disable it at runtime (w/o color keying enabled, the sprite will always sit on top of the primary), and potentially add alpha support at some point. Would 0 as the color key work well enough as a disable flag? Or should I add a separate field to the ioctl? Anyone have a preference? Thanks, Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: track sprite coverage and disable primary plane if possible
To save power when the sprite is full screen, we can disable the primary
plane on the same pipe. Track the sprite status and enable/disable the
primary opportunistically.
v2: remove primary plane enable/disable hooks; they're identical
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h|1 +
drivers/gpu/drm/i915/intel_sprite.c | 41 +++
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e0407cd..0340b4c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -180,6 +180,7 @@ struct intel_plane {
struct drm_plane base;
enum pipe pipe;
struct drm_i915_gem_object *obj;
+ bool primary_disabled;
int max_downscale;
u32 lut_r[1024], lut_g[1024], lut_b[1024];
void (*update_plane)(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index a51edc9..976eee3 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -329,6 +329,28 @@ snb_get_destkey(struct drm_plane *plane)
return value;
}
+static void
+intel_enable_primary(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int reg = DSPCNTR(intel_crtc-plane);
+
+ I915_WRITE(reg, I915_READ(reg) | DISPLAY_PLANE_ENABLE);
+}
+
+static void
+intel_disable_primary(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int reg = DSPCNTR(intel_crtc-plane);
+
+ I915_WRITE(reg, I915_READ(reg) ~DISPLAY_PLANE_ENABLE);
+}
+
static int
intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
struct drm_framebuffer *fb, int crtc_x, int crtc_y,
@@ -415,9 +437,23 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
intel_plane-obj = obj;
+ /*
+* Be sure to re-enable the primary before the sprite is no longer
+* covering it fully.
+*/
+ if (!disable_primary intel_plane-primary_disabled) {
+ intel_enable_primary(crtc);
+ intel_plane-primary_disabled = false;
+ }
+
intel_plane-update_plane(plane, fb, obj, crtc_x, crtc_y,
crtc_w, crtc_h, x, y, src_w, src_h);
+ if (disable_primary) {
+ intel_disable_primary(crtc);
+ intel_plane-primary_disabled = true;
+ }
+
/* Unpin old obj after new one is active to avoid ugliness */
if (old_obj) {
/*
@@ -447,6 +483,11 @@ intel_disable_plane(struct drm_plane *plane)
struct intel_plane *intel_plane = to_intel_plane(plane);
int ret = 0;
+ if (intel_plane-primary_disabled) {
+ intel_enable_primary(plane-crtc);
+ intel_plane-primary_disabled = false;
+ }
+
intel_plane-disable_plane(plane);
if (!intel_plane-obj)
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: add destination color key support
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
v2: remove unnecessary mutex acquire/release around reg accesses
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_drv.h|8 ++
drivers/gpu/drm/i915/intel_sprite.c | 138 +++
include/drm/i915_drm.h | 16
5 files changed, 166 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a9533c5..bc7ee4f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2295,6 +2295,8 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl,
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_SET_SPRITE_DESTKEY, intel_sprite_set_destkey,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GET_SPRITE_DESTKEY, intel_sprite_get_destkey,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
};
int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a2ce411..860b250 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2738,6 +2738,8 @@
#define DVSSIZE(pipe) _PIPE(pipe, _DVSASIZE, _DVSBSIZE)
#define DVSSCALE(pipe) _PIPE(pipe, _DVSASCALE, _DVSBSCALE)
#define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF)
+#define DVSKEYVAL(pipe) _PIPE(pipe, _DVSAKEYVAL, _DVSBKEYVAL)
+#define DVSKEYMSK(pipe) _PIPE(pipe, _DVSAKEYMSK, _DVSBKEYMSK)
#define _SPRA_CTL 0x70280
#define SPRITE_ENABLE(131)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 089cdde..e0407cd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -190,6 +190,8 @@ struct intel_plane {
uint32_t x, uint32_t y,
uint32_t src_w, uint32_t src_h);
void (*disable_plane)(struct drm_plane *plane);
+ int (*update_destkey)(struct drm_plane *plane, u32 value);
+ u32 (*get_destkey)(struct drm_plane *plane);
};
#define to_intel_crtc(x) container_of(x, struct intel_crtc, base)
@@ -412,4 +414,10 @@ extern void sandybridge_update_wm(struct drm_device *dev);
extern void intel_update_sprite_watermarks(struct drm_device *dev, int pipe,
uint32_t sprite_width,
int pixel_size);
+
+extern int intel_sprite_set_destkey(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
+extern int intel_sprite_get_destkey(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
+
#endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 18eb7b8..a51edc9 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -96,6 +96,7 @@ ivb_update_plane(struct drm_plane *plane, struct
drm_framebuffer *fb,
/* must disable */
sprctl |= SPRITE_TRICKLE_FEED_DISABLE;
sprctl |= SPRITE_ENABLE;
+ sprctl |= SPRITE_DEST_KEY;
/* Sizes are 0 based */
src_w--;
@@ -154,6 +155,41 @@ ivb_disable_plane(struct drm_plane *plane)
POSTING_READ(SPRSURF(pipe));
}
+static int
+ivb_update_destkey(struct drm_plane *plane, u32 value)
+{
+ struct drm_device *dev = plane-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_plane *intel_plane;
+ int ret = 0;
+
+ if (value 0xff)
+ return -EINVAL;
+
+ intel_plane = to_intel_plane(plane);
+
+ I915_WRITE(SPRKEYVAL(intel_plane-pipe), value);
+ I915_WRITE(SPRKEYMSK(intel_plane-pipe), 0xff);
+ POSTING_READ(SPRKEYMSK(intel_plane-pipe));
+
+ return ret;
+}
+
+static u32
+ivb_get_destkey(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_plane *intel_plane;
+ u32 value;
+
+ intel_plane = to_intel_plane(plane);
+
+ value = I915_READ(SPRKEYVAL(intel_plane-pipe));
+
+ return value;
+}
+
static void
snb_update_plane(struct drm_plane *plane, struct drm_framebuffer *fb,
struct drm_i915_gem_object *obj, int crtc_x, int crtc_y,
@@ -259,6 +295,41 @@
[Intel-gfx] [PATCH 1/3] drm/i915: add SNB and IVB video sprite support v5
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
sprite support functions.
v2: use drm specific fourcc header and defines
v3: address Daniel's comments:
- don't take struct mutex around register access (only needed for
regs in the GT power well)
- don't hold struct mutex across vblank waits
- fix up update_plane API (pass obj instead of GTT offset)
- add interlaced defines for sprite regs
- drop unnecessary 'reg' variables
- comment double buffered reg flushing
Also fix w/h confusion when writing the scaling reg.
v4: more fixes, address more comments from Daniel, and include Hai's fix
- prevent divide by zero in scaling calculation (Hai Lan)
- update to Ville's new DRM_FORMAT_* types
- fix sprite watermark handling (calc based on CRTC size, separate
from normal display wm)
- remove private refcounts now that the fb cleanups handles things
v5: add linear surface support
For this version, I tested DPMS since it came up in the last review;
DPMS off/on works ok when a video player is working under X, but for
power saving we'll probably want to do something smarter. I'll leave
that for a separate patch on top. Likewise with the refcounting/fb
layer handling, which are really separate cleanups.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_drv.h |3 +
drivers/gpu/drm/i915/i915_reg.h | 133 ++
drivers/gpu/drm/i915/intel_display.c | 174 +-
drivers/gpu/drm/i915/intel_drv.h | 28 ++
drivers/gpu/drm/i915/intel_fb.c |6 +
drivers/gpu/drm/i915/intel_sprite.c | 452 ++
7 files changed, 790 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_sprite.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0ae6a7c..808b255 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -28,6 +28,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_dvo.o \
intel_ringbuffer.o \
intel_overlay.o \
+ intel_sprite.o \
intel_opregion.o \
dvo_ch7xxx.o \
dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4a9c1b9..0c3078c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -206,6 +206,8 @@ struct drm_i915_display_funcs {
int (*get_display_clock_speed)(struct drm_device *dev);
int (*get_fifo_size)(struct drm_device *dev, int plane);
void (*update_wm)(struct drm_device *dev);
+ void (*update_sprite_wm)(struct drm_device *dev, int pipe,
+uint32_t sprite_width, int pixel_size);
int (*crtc_mode_set)(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode,
@@ -347,6 +349,7 @@ typedef struct drm_i915_private {
/* overlay */
struct intel_overlay *overlay;
+ bool sprite_scaling_enabled;
/* LVDS info */
int backlight_level; /* restore backlight to this value */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b080cc8..a2ce411 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2459,6 +2459,8 @@
#define WM3_LP_ILK 0x45110
#define WM3_LP_EN (131)
#define WM1S_LP_ILK0x45120
+#define WM2S_LP_IVB0x45124
+#define WM3S_LP_IVB0x45128
#define WM1S_LP_EN(131)
/* Memory latency timer register */
@@ -2675,6 +2677,137 @@
#define _DSPBSURF 0x7119C
#define _DSPBTILEOFF 0x711A4
+/* Sprite A control */
+#define _DVSACNTR 0x72180
+#define DVS_ENABLE (131)
+#define DVS_GAMMA_ENABLE (130)
+#define DVS_PIXFORMAT_MASK (325)
+#define DVS_FORMAT_YUV422(025)
+#define DVS_FORMAT_RGBX101010(125)
+#define DVS_FORMAT_RGBX888 (225)
+#define DVS_FORMAT_RGBX161616(325)
+#define DVS_SOURCE_KEY (122)
+#define DVS_RGB_ORDER_RGBX (120)
+#define DVS_YUV_BYTE_ORDER_MASK (316)
+#define DVS_YUV_ORDER_YUYV (016)
+#define DVS_YUV_ORDER_UYVY (116)
+#define DVS_YUV_ORDER_YVYU (216)
+#define DVS_YUV_ORDER_VYUY (316)
+#define DVS_DEST_KEY (12)
+#define DVS_TRICKLE_FEED_DISABLE (114)
+#define DVS_TILED(110)
+#define _DVSALINOFF0x72184
+#define _DVSASTRIDE0x72188
+#define _DVSAPOS 0x7218c
+#define _DVSASIZE 0x72190
+#define _DVSAKEYVAL0x72194
+#define _DVSAKEYMSK0x72198
+#define _DVSASURF 0x7219c
+#define _DVSAKEYMAXVAL 0x721a0
+#define _DVSATILEOFF 0x721a4
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Force sync command ordering (Gen6+)
On Wed, 7 Dec 2011 11:58:05 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 7 Dec 2011 10:38:41 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 07 Dec 2011 10:35:45 -0800 Eric Anholt e...@anholt.net wrote: On Sat, 22 Oct 2011 19:41:24 -0700, Ben Widawsky b...@bwidawsk.net wrote: The docs say this is required for Gen7, and since the bit was added for Gen6, we are also setting it there pit pf paranoia. Particularly as Chris points out, if PIPE_CONTROL counts as a 3d state packet. This was found through doc inspection by Ken and applies to Gen6+; Cc: Keith Packard kei...@keithp.com Reported-by: Kenneth Graunke kenn...@whitecape.org Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Eric Anholt e...@anholt.net however, it doesn't appear to help Ivybridge IRQ troubles. You could try something like the below to force the use of PIPE_NOTIFY instead. Only lightly tested on IVB when we had lots of other bugs, so I'm not sure if it works at all. Though if it's the blit ring hanging, you'd have to try using a flush_dw notify (if such a thing exists) instead... Yeah, MI_FLUSH_DW as opposed to MI_STORE_DW + MI_USER_INTERRUPT. pgpmqixHsFldZ.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] Minecraft graphics issues
On Wed, Dec 7, 2011 at 16:15, Jonas Jelten jel...@in.tum.de wrote: Hi! What about adding Minecraft to the officially tested games list for the released graphics package? It's one of the most played games on Linux i think, and a lot of users are experiencing graphical problems that don't occur in windows or mac. Two screenshots of my Minecraft graphics issue: http://img7.imagebanana.com/img/5900nd4k/20111206_08.34.06.png http://img6.imagebanana.com/img/2pl3w1ky/20111206_08.39.38.png Could you try the workaround at https://bugs.freedesktop.org/show_bug.cgi?id=39730#c48 for this problem? -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Force sync command ordering (Gen6+)
On Wed, 07 Dec 2011 12:54:07 -0800 Eric Anholt e...@anholt.net wrote: On Wed, 7 Dec 2011 11:58:05 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 7 Dec 2011 10:38:41 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 07 Dec 2011 10:35:45 -0800 Eric Anholt e...@anholt.net wrote: On Sat, 22 Oct 2011 19:41:24 -0700, Ben Widawsky b...@bwidawsk.net wrote: The docs say this is required for Gen7, and since the bit was added for Gen6, we are also setting it there pit pf paranoia. Particularly as Chris points out, if PIPE_CONTROL counts as a 3d state packet. This was found through doc inspection by Ken and applies to Gen6+; Cc: Keith Packard kei...@keithp.com Reported-by: Kenneth Graunke kenn...@whitecape.org Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Eric Anholt e...@anholt.net however, it doesn't appear to help Ivybridge IRQ troubles. You could try something like the below to force the use of PIPE_NOTIFY instead. Only lightly tested on IVB when we had lots of other bugs, so I'm not sure if it works at all. Though if it's the blit ring hanging, you'd have to try using a flush_dw notify (if such a thing exists) instead... Yeah, MI_FLUSH_DW as opposed to MI_STORE_DW + MI_USER_INTERRUPT. Looks like there is a notify option, bit 8 of MI_FLUSH_DW. It's a long shot, but does anyone want to give it a try? -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] xf86-video-intel: change order of DPMS operations
The operations when setting dpms on should be in the order opposite
of what's done when setting dpms off.
This is because of potentially conflicting effects:
~ drmModeConnectoSetProperty() enables/disables the backlight driver.
Some backlight drivers such as intel_backlight set the backlight to 0
when disabled and to max when enabled.
~ intel_output_dpms_backlight() saves the backlight value when turning
DPMS off and restores it when turning DPMS on.
Here's the current order of operations:
xset dpms force off (backlight is nonzero)
drmModeConnectoSetProperty(DPMSModeOff)
kernel: disable backlight, backlight=0
intel_output_dpms_backlight(DPMSModeOff)
save backlight value (0) -- it has been set to 0 by kernel
set backlight to 0
xset dpms force on
drmModeConnectoSetProperty(DPMSModeOn)
kernel: enable backlight, backlight=max
intel_output_dpms_backlight(DPMSModeOn)
set backlight to saved value (0)
The correct way to do this would be to reverse the operations during
xset dpms force off:
intel_output_dpms_backlight(DPMSModeOff)
save backlight value (nonzero)
set backlight to 0
drmModeConnectoSetProperty(DPMSModeOff)
kernel: enable backlight, backlight=0
This restores the saved nonzero backlight value during the force on.
Signed-off-by: Simon Que s...@chromium.org
---
src/intel_display.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/intel_display.c b/src/intel_display.c
index 2183f4d..2a989d1 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -944,13 +944,19 @@ intel_output_dpms(xf86OutputPtr output, int dpms)
continue;
if (!strcmp(props-name, DPMS)) {
+ /* Make sure to reverse the order between on and off. */
+ if (dpms == DPMSModeOff)
+ intel_output_dpms_backlight(output,
+
intel_output-dpms_mode,
+ dpms);
drmModeConnectorSetProperty(mode-fd,
intel_output-output_id,
props-prop_id,
dpms);
- intel_output_dpms_backlight(output,
- intel_output-dpms_mode,
- dpms);
+ if (dpms != DPMSModeOff)
+ intel_output_dpms_backlight(output,
+
intel_output-dpms_mode,
+ dpms);
intel_output-dpms_mode = dpms;
drmModeFreeProperty(props);
return;
--
1.7.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Plane support for SNB and IVB
2011/12/8 Jesse Barnes jbar...@virtuousgeek.org I think the core support is ready now, but I'd like feedback on the color key ioctl. It would be good to have a way to disable it at runtime (w/o color keying enabled, the sprite will always sit on top of the primary), and potentially add alpha support at some point. Would 0 as the color key work well enough as a disable flag? Or should I add a separate field to the ioctl? Anyone have a preference? Do you mean whether to use colorkey value 0 as a disabled flag? I don't think we can use 0 as disabled colorkey because sometimes we need to set the colorkey as 0. So I think it's better to use a separate field of ioctl. Thanks and best regards. Hai Lan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
