Re: [Intel-gfx] [PATCH] drm/i915: Fixed VS thread distribution between slices
On 04/09/2012 09:10 PM, Ben Widawsky wrote: From: "bernard.r.kilarski" Full disclosure: my IVB hangs on nexuiz both before, and after this patch, and I haven't done any debug This patch was given to me by Bernard, by way of Daniel. The patch came with very little description, and I haven't really spent too much time in the spec to make much sense out of it. The improvement (IVB only) with my nexuiz configuration is almost unbelievable. It has a more humble improvement on OpenArena. I'll throw other tests at it, and try to debug the hangs a bit, but given the nexuiz results, I was compelled to post this sooner, rather than later. I see about a 2% improvement on OA and about a 40$% improvement on nexuiz CC: Daniel Vetter Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_reg.h |3 +++ drivers/gpu/drm/i915/intel_display.c |3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index cb55444..755bdff 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -682,6 +682,9 @@ #define GEN6_BSD_RNCID0x12198 +#define GEN7_FF_THREAD_MODE0x20a0 +#define GEN7_FF_THREAD_SIMPLE_SCHED0x28a00010 + /* * Framebuffer compression (915+ only) */ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 6ec81b4..bbd5f46 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8893,6 +8893,9 @@ static void ivybridge_init_clock_gating(struct drm_device *dev) DISPPLANE_TRICKLE_FEED_DISABLE); intel_flush_display_plane(dev_priv, pipe); } + + /* Fix vertex load balancing */ + I915_WRITE(GEN7_FF_THREAD_MODE,GEN7_FF_THREAD_SIMPLE_SCHED); } static void valleyview_init_clock_gating(struct drm_device *dev) I definitely approve of this patch. It appears to make the hardware use a simple scheduler, as opposed to a complex one which is default. The default scheduler has this lovely comment: "Note: this will cause possible corruption if input handles are reused due to instancing or topologies that reuse vertices (i.e. strips and fans)". That is frightening. We use instancing, tristrips, and trifans all the time. While I haven't observed a problem, I don't want this to come back and bite us later. The other scheduling options in VS Thread Dispatch Mode are useless. Simple scheduling appears to be the only option that's safe. And apparently it performs well too :) So, as is, I think this qualifies for a: Cc: sta...@kernel.org Reviewed-by: Kenneth Graunke However! I would like to be more paranoid and program it to 0x28a0. In other words, the IVB default minus bit 4 and bit 12: 0x28a01010 & ~(1 << 4 | 1 << 12) Bit 12 is the VS Thread Dispatch Override, which Bernard's patch cleared. Bit 4 is the equivalent bit for DS (Domain Shaders). It also has the scary comment about instancing and strips/fans not working. Likewise, bit 16 also should be off (but is already off by default). Since domain shaders are an OpenGL 4.0 feature, this shouldn't matter in the short term...but I doubt any of us will remember to come back here and change these bits when we eventually need them. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: [GEN7] Use HW scheduler for fixed function shaders
On 04/14/2012 06:41 PM, Ben Widawsky wrote: This originally started as a patch from Bernard as a way of simply setting the VS scheduler. After submitting the RFC patch, we decided to also modify the DS scheduler. To be most explicit, I've made the patch explicitly set all scheduler modes, and included the defines for other modes (in case someone feels frisky later). The rest of the story gets a bit weird. The first version of the patch showed an almost unbelievable performance improvement. Since rebasing my branch it appears the performance improvement has gone, unfortunately. But setting these bits seem to be the right thing to do given that the docs describe corruption that can occur with the default settings. In summary, I am seeing no more perf improvements (or regressions) in my limited testing, but we believe this should be set to prevent rendering corruption, therefore cc stable. v1: Clear bit 4 also (Ken + Eugeni) Do a full clear + set of the bits we want (Me). Cc: Bernard Kilarski Cc: stable Reviewed-by (RFC): Kenneth Graunke Signed-off-by: Ben Widawsky Looks good! I like how you've reworked this. It looks like we don't want to do this on Haswell. Reviewed-by: Kenneth Graunke (I haven't tested it, though.) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] drm/i915: Move the STC LRA eviction policy workaround after ring init.
Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in OpenGL programs such as Google MapsGL, Google Earth, and gzdoom. While commit 09be664ecc77d58 introduced the workaround, the register write didn't actually stick: a printk and I915_READ immediately after the write would return the new value, but a second one would show that it had reverted to the original value...even with no intervening code. The hardware documentation mentions that the ring must be idle before writing CACHE_MODE_0. This provided a clue that it might be necessary to initialize the rings before attempting to program the register. Sure enough, moving the write after ring initialization makes it stick. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535 Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_dma.c |7 +++ drivers/gpu/drm/i915/intel_pm.c |4 2 files changed, 7 insertions(+), 4 deletions(-) Here's a horrible patch---putting that one workaround bit directly inside i915_load_modeset_init is clearly a terrible idea. There will obviously be many more, and per-generation. I suspect that many more of the workaround bits we're setting in init_clock_gating may need to be moved later in the init process too...but I haven't checked to see which ones are failing to stick. So I guess there's a couple questions: * Does it make sense to move ALL the init_clock_gating stuff to this point in time? Or are there some registers that need to be done early, where they are today? (If we can move them all, we could just move the call to init_clock_gating and be done with it...) Apparently CACHE_MODE_0 is a context-specific register, while some others are not. I like having all the workaround bits in one place, but that may or may not be feasible... * Do we want to make an intel_apply_workarounds() function or such? Perhaps use a function pointer that gets filled in on a per-chipset basis? * Is this the best time to set it? Later? Elsewhere? * What should the code look like long-term, and what would be easiest for backporting to stable kernels? diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index e2983a9..532c8cf 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1128,6 +1128,13 @@ static int i915_load_modeset_init(struct drm_device *dev) intel_modeset_gem_init(dev); + /* Apply workaround bits. These need to be done after ring init. */ + if (IS_GEN6(dev)) { + /* clear masked bit */ + I915_WRITE(CACHE_MODE_0, + CM0_STC_EVICT_DISABLE_LRA_SNB << CM0_MASK_SHIFT); + } + ret = drm_irq_install(dev); if (ret) goto cleanup_gem; diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 0552058..070ab27 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2663,10 +2663,6 @@ static void gen6_init_clock_gating(struct drm_device *dev) I915_WRITE(WM2_LP_ILK, 0); I915_WRITE(WM1_LP_ILK, 0); - /* clear masked bit */ - I915_WRITE(CACHE_MODE_0, - CM0_STC_EVICT_DISABLE_LRA_SNB << CM0_MASK_SHIFT); - I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) | GEN6_BLBUNIT_CLOCK_GATE_DISABLE | -- 1.7.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.
Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when using separate stencil buffers. Without it, the GPU tries to use the LRA eviction policy, which isn't supported. This was supposed to be off by default, but seems to be on for many machines. This cannot be done in gen6_init_clock_gating with most of the other workaround bits; the render ring needs to exist. Otherwise, the register write gets dropped on the floor (one printk will show it changed, but a second printk immediately following shows the value reverts to the old one). Cc: sta...@kernel.org Cc: Rob Castle Cc: Eric Appleman Cc: aaron...@gmx.net Cc: Keith Packard Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535 Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_ringbuffer.c |8 2 files changed, 9 insertions(+) Note that this patch applies against Daniel's drm-intel-fixes tree. In drm-intel-next-queued, it may conflict with commit 009be664ecc77d58d3c27fb22347b969745a329a. diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index b4bb1ef..9d24d65 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -568,6 +568,7 @@ #define CM0_MASK_SHIFT 16 #define CM0_IZ_OPT_DISABLE (1<<6) #define CM0_ZR_OPT_DISABLE (1<<5) +#define CM0_STC_EVICT_DISABLE_LRA_SNB (1<<5) #define CM0_DEPTH_EVICT_DISABLE (1<<4) #define CM0_COLOR_EVICT_DISABLE (1<<3) #define CM0_DEPTH_WRITE_DISABLE (1<<1) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index f75806e..80fce51 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -401,6 +401,14 @@ static int init_render_ring(struct intel_ring_buffer *ring) if (INTEL_INFO(dev)->gen >= 6) { I915_WRITE(INSTPM, INSTPM_FORCE_ORDERING << 16 | INSTPM_FORCE_ORDERING); + + /* From the Sandybridge PRM, volume 1 part 3, page 24: +* "If this bit is set, STCunit will have LRA as replacement +* policy. [...] This bit must be reset. LRA replacement +* policy is not supported." +*/ + I915_WRITE(CACHE_MODE_0, + CM0_STC_EVICT_DISABLE_LRA_SNB << CM0_MASK_SHIFT); } return ret; -- 1.7.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.
Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when using separate stencil buffers. Without it, the GPU tries to use the LRA eviction policy, which isn't supported. This was supposed to be off by default, but seems to be on for many machines. This cannot be done in gen6_init_clock_gating with most of the other workaround bits; the render ring needs to exist. Otherwise, the register write gets dropped on the floor (one printk will show it changed, but a second printk immediately following shows the value reverts to the old one). v2: Don't write the Gen6 registers on Gen7+. Cc: sta...@kernel.org Cc: Rob Castle Cc: Eric Appleman Cc: aaron...@gmx.net Cc: Keith Packard Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535 Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++ 2 files changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index b4bb1ef..9d24d65 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -568,6 +568,7 @@ #define CM0_MASK_SHIFT 16 #define CM0_IZ_OPT_DISABLE (1<<6) #define CM0_ZR_OPT_DISABLE (1<<5) +#define CM0_STC_EVICT_DISABLE_LRA_SNB (1<<5) #define CM0_DEPTH_EVICT_DISABLE (1<<4) #define CM0_COLOR_EVICT_DISABLE (1<<3) #define CM0_DEPTH_WRITE_DISABLE (1<<1) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index f75806e..af76723 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -398,6 +398,16 @@ static int init_render_ring(struct intel_ring_buffer *ring) return ret; } + if (IS_GEN6(dev)) { + /* From the Sandybridge PRM, volume 1 part 3, page 24: +* "If this bit is set, STCunit will have LRA as replacement +* policy. [...] This bit must be reset. LRA replacement +* policy is not supported." +*/ + I915_WRITE(CACHE_MODE_0, + CM0_STC_EVICT_DISABLE_LRA_SNB << CM0_MASK_SHIFT); + } + if (INTEL_INFO(dev)->gen >= 6) { I915_WRITE(INSTPM, INSTPM_FORCE_ORDERING << 16 | INSTPM_FORCE_ORDERING); -- 1.7.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel HD3000 Graphics + i3-2330M CPU
On 04/29/2012 06:32 AM, Torsten Brieskorn wrote: hello list, i use a Lenovo G770 with Intel HD3000 Graphics and i3-2330M CPU. A standard Linux installation does not install my graphic card correctly. I tried Ubuntu 12.04, openSuse 12.1 and the newest Knoppix. Hi Torsten, Could you please elaborate? What exactly is wrong? You get no display? Wrong resolution? Backlight issues? Multi-head problems? X doesn't start? No 3D...? On http://intellinuxgraphics.org I read that Intel HD3000 with i5 and i7 CPU running without problems. Is there a way to run this driver also for my configuration (Intel HD3000 Graphics + i3-2330M CPU)? You don't actually want to get a driver from there...the one in your distribution ought to work. Shell output: lshw -C video *-display description: VGA compatible controller product: 2nd Generation Core Processor Family Integrated Graphics Controller vendor: Intel Corporation physical id: 2 bus info:pci@:00:02.0 version: 09 width: 64 bits clock: 33MHz capabilities: msi pm vga_controller bus_master cap_list rom configuration:driver=i915latency=0 resources: irq:42 memory:d000-d03f memory:c000-cfff ioport:3000(size=64) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] how to install xf86-video-intel.
On 04/28/2012 11:50 PM, jeffsoft wrote: hi, man, I am a new user for Ubuntu, I can't install the driver for the hp G45. the type is hp dx2810. You shouldn't need to install any drivers. Ubuntu already includes drivers for the G45. Everything should just work. So unless you're trying to solve a specific problem, I wouldn't bother. I had get the install package, and already reading the README file, but i don't to install the driver. so, i need you help me to finished it. and I am a Chinese user, the English is very bad. if you can use the Chinese return to me, I be very happy. please don't tease me. thanks! Jeff 2012-4-29 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix gen4 gpu reset
On 05/02/2012 12:33 PM, Daniel Vetter wrote: While trying to fix up gen4 gpu reset in commit f49f0586191fe16140410db0a46d43bdc690d6af Author: Kenneth Graunke Date: Sat Sep 11 01:19:14 2010 -0700 drm/i915: Actually set the reset bit in i965_reset a little confusion about when wait_for times out has been introduced - wait for loops _until_ the condition is true. This fixes gpu reset on my gm45, testing with my hangman code shows that it's now fairly reliable - it only died after well over 100 reset cycles. Cc: Kenneth Graunke Cc: Eric Anholt Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 133f101..77b7a50 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -707,7 +707,7 @@ static int i965_reset_complete(struct drm_device *dev) { u8 gdrst; pci_read_config_byte(dev->pdev, I965_GDRST,&gdrst); - return gdrst& 0x1; + return (gdrst& GRDOM_RESET_ENABLE) == 0; } static int i965_do_reset(struct drm_device *dev) How embarassing :) Ironlake also has the same bug and IIRC hasn't been resetting properly for me. I can test that if you'd like. Reviewed-by: Kenneth Graunke I might also Cc: sta...@kernel.org an equivalent of this...but, up to you. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 00/25] i915 HW context support
On 06/04/2012 10:53 PM, Dave Airlie wrote: >> >> I've run these on various workloads and saw nothing worth mentioning. > > Nothing at all? no speedups, slowdowns, etc > > why should we merge all this code then :-) > > Dave. Preserving hardware state across batches is going to be necessary for: * Transform feedback in the presence of geometry shaders Right now, Mesa counts the number of primitives emitted on the CPU, relies on the kernel resetting the register to 0, and offset values in software. With GS, we obviously can't count primitives on the CPU. * Primitive restart in hardware and seems to be increasingly necessary for new features as we move forward. So we'd like to get it in place; we can cut more state uploads and tune Mesa further once it's there. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 00/25] i915 HW context support
On 06/04/2012 02:42 PM, Ben Widawsky wrote: > Setting myself up for a late night crying session once again. Most of the > people reading this probably know the history and reasons for the patches. If > not, you can search the intel-gfx mailing list to try to learn more. I won't > recap the whole thing here, and instead let the patches speak for themselves. > > Instead a brief review of what's here, and what's happened. Mostly, > these badly need testing and review. I've carried these around for so > long now, and seen so many different failures, I'm quite paranoid they > still aren't perfect. Also, I've spent almost all of the time working on > this in the kernel, so there is bound to be simple errors in the other > stuff. > > I've run these on various workloads and saw nothing worth mentioning. > > > 0-16: kernel patches > 17-21: libdrm patches (wait render patch is temporary) Patches 17-21 look fine. Reviewed-by: Kenneth Graunke > 22-24: intel-gpu-tools > 25: mesa Patch 25 looks fine too. Feel free to apply some combination of: Reviewed-by: Kenneth Graunke Signed-off-by: Kenneth Graunke I do like Paul's comment updates, so I suggest merging those. > kernel > git://people.freedesktop.org/~bwidawsk/drm-intel context_support_rev2 > > libdrm > git://people.freedesktop.org/~bwidawsk/drm context_support_rev2 > > i-g-t > git://people.freedesktop.org/~bwidawsk/intel-gpu-tools context_support ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] i965: Add hardware context support.
With fixes and updates from Ben Widawsky and comments from Paul Berry. This should not be pushed until libdrm 2.4.36 is released with Ben's hardware context support. I haven't hooked up the context destroy function yet as I'm not entirely sure about tear-down, but they will be freed on fd close, so it should only be a problem for long running processes that open and destroy many GL contexts. Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Kenneth Graunke Signed-off-by: Ben Widawsky --- configure.ac |2 +- src/mesa/drivers/dri/i965/brw_context.c|1 + src/mesa/drivers/dri/i965/brw_vtbl.c | 13 + src/mesa/drivers/dri/intel/intel_batchbuffer.c |9 +++-- src/mesa/drivers/dri/intel/intel_context.c |2 ++ src/mesa/drivers/dri/intel/intel_context.h |2 ++ 6 files changed, 22 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index 29ee87b..e668c69 100644 --- a/configure.ac +++ b/configure.ac @@ -33,7 +33,7 @@ USER_CXXFLAGS="$CXXFLAGS" dnl Versions for external dependencies LIBDRM_REQUIRED=2.4.24 LIBDRM_RADEON_REQUIRED=2.4.31 -LIBDRM_INTEL_REQUIRED=2.4.34 +LIBDRM_INTEL_REQUIRED=2.4.36 LIBDRM_NVVIEUX_REQUIRED=2.4.33 LIBDRM_NOUVEAU_REQUIRED=2.4.33 DRI2PROTO_REQUIRED=2.6 diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index f7073cd..d4159c7 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -298,6 +298,7 @@ brwCreateContext(int api, brw->prim_restart.in_progress = false; brw->prim_restart.enable_cut_index = false; + intel->hw_ctx = drm_intel_gem_context_create(intel->bufmgr); brw_init_state( brw ); diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c b/src/mesa/drivers/dri/i965/brw_vtbl.c index 5699749..88e6dd1 100644 --- a/src/mesa/drivers/dri/i965/brw_vtbl.c +++ b/src/mesa/drivers/dri/i965/brw_vtbl.c @@ -166,11 +166,16 @@ static void brw_new_batch( struct intel_context *intel ) { struct brw_context *brw = brw_context(&intel->ctx); - /* Mark all context state as needing to be re-emitted. -* This is probably not as severe as on 915, since almost all of our state -* is just in referenced buffers. + /* If the kernel supports hardware contexts, then most hardware state is +* preserved between batches; we only need to re-emit state that is required +* to be in every batch. Otherwise we need to re-emit all the state that +* would otherwise be stored in the context (which for all intents and +* purposes means everything). */ - brw->state.dirty.brw |= BRW_NEW_CONTEXT | BRW_NEW_BATCH; + if (intel->hw_ctx == NULL) + brw->state.dirty.brw |= BRW_NEW_CONTEXT; + + brw->state.dirty.brw |= BRW_NEW_BATCH; /* Assume that the last command before the start of our batch was a * primitive, for safety. diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c b/src/mesa/drivers/dri/intel/intel_batchbuffer.c index 76a69f7..7ba141d 100644 --- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c +++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c @@ -188,8 +188,13 @@ do_flush_locked(struct intel_context *intel) if (ret == 0) { if (unlikely(INTEL_DEBUG & DEBUG_AUB) && intel->vtbl.annotate_aub) intel->vtbl.annotate_aub(intel); -ret = drm_intel_bo_mrb_exec(batch->bo, 4*batch->used, NULL, 0, 0, -flags); +if (intel->hw_ctx == NULL || batch->is_blit) { + ret = drm_intel_bo_mrb_exec(batch->bo, 4*batch->used, NULL, 0, 0, + flags); +} else { + ret = drm_intel_gem_bo_context_exec(batch->bo, intel->hw_ctx, + 4 * batch->used, flags); +} } } diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index c2f7d29..fc244c1 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -593,6 +593,8 @@ intelInitContext(struct intel_context *intel, if (intelScreen->bufmgr == NULL) return false; + intel->hw_ctx = NULL; + /* Can't rely on invalidate events, fall back to glViewport hack */ if (!driContextPriv->driScreenPriv->dri2.useInvalidate) { intel->saved_viewport = functions->Viewport; diff --git a/src/mesa/drivers/dri/intel/intel_context.h b/src/mesa/drivers/dri/intel/intel_context.h index cc3ee0d..29ab187 100644 --- a/src/mesa/drivers/dri/intel/intel_context.h +++ b/src/mesa/drivers/dri/intel/intel_context.h @@ -225,6 +225,8 @@ struct intel_context int urb_size; + drm_intel_context *hw_ctx; + struct intel_batchbuffer batch; drm_intel_bo *first_post_swapbuffers_batc
[Intel-gfx] [PATCH] intel: Don't print messages to stderr if context creation fails.
Since there is no getparam for hardware context support, Mesa always tries to obtain a context by calling drm_intel_gem_context_create and NULL-checking the result. On an older kernel without context support, this caused libdrm to print an unwanted message to stderr: DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed: Invalid argument In fact, this caused every Piglit test to fail with a "warn" status due to the unrecognized error message. Simply delete the message. It's OK for context creation to fail. Cc: Ben Widawsky Cc: Paul Berry Cc: mesa-de...@lists.freedesktop.org Signed-off-by: Kenneth Graunke --- intel/intel_bufmgr_gem.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index a957c28..1b4ac78 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -2850,11 +2850,8 @@ drm_intel_gem_context_create(drm_intel_bufmgr *bufmgr) int tmp = 0, ret; ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, &create); - if (ret != 0) { - fprintf(stderr, "DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed: %s\n", - strerror(errno)); + if (ret != 0) return NULL; - } context = calloc(1, sizeof(*context)); context->ctx_id = create.ctx_id; -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 0/5] First batch of gm45 clipping/interpolation fixes
On 07/13/2012 12:20 AM, Olivier Galibert wrote: > On Sat, Jun 30, 2012 at 08:50:10PM +0200, Olivier Galibert wrote: >> This is the first part of the fixes I've done to make my gm45 work >> correctly w.r.t clipping and interpolation. There's a fair chance >> they work for everything gen 4/5, but I have no way to be sure. > > So, not even one comment, nothing? > > OG. Sorry...been really busy, and most of us haven't actually spent much if any time in the clipper shaders. I'll try and review it within a week. Despite the lack of response, I am really excited to see that you're working on this---this is a huge step toward bringing GL 3.x back to Gen4/5, and we're all really glad to see it happen! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH mesa] i965: add more Haswell PCI IDs
On 08/06/2012 02:50 PM, Paulo Zanoni wrote: > From: Paulo Zanoni > > Signed-off-by: Paulo Zanoni Reviewed-by: Kenneth Graunke Do you have push access? If not, I can commit this for you. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel: Use VG_CLEAR on the context destroy ioctl as well.
Otherwise pad appears uninitialized and valgrind grumbles. Signed-off-by: Kenneth Graunke --- intel/intel_bufmgr_gem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index a170813..795c1a8 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -2936,6 +2936,8 @@ drm_intel_gem_context_destroy(drm_intel_context *ctx) if (ctx == NULL) return; + VG_CLEAR(destroy); + bufmgr_gem = (drm_intel_bufmgr_gem *)ctx->bufmgr; destroy.ctx_id = ctx->ctx_id; ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_CONTEXT_DESTROY, -- 1.7.11.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: apply HWSTAM writes to Ivy Bridge as well
On 07/01/2011 11:08 AM, Jesse Barnes wrote: > In an attempt to fix 38862 and 38863. > > Signed-off-by: Jesse Barnes Tested-by: Kenneth Graunke Prior to this patch, running the piglit test suite would randomly hang the GPU unless I added msleeps between each test. (Individual tests ran fine.) This patch fixes the issue. I am now able to run piglit unmodified without hanging the GPU. Keith, could this go into -fixes? Thanks for finding this, Chris and Jesse! --Kenneth > --- > drivers/gpu/drm/i915/i915_irq.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 2e18161..23d1ae6 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -1745,7 +1745,7 @@ static void ironlake_irq_preinstall(struct drm_device > *dev) > INIT_WORK(&dev_priv->rps_work, gen6_pm_rps_work); > > I915_WRITE(HWSTAM, 0xeffe); > - if (IS_GEN6(dev)) { > + if (IS_GEN6(dev) || IS_GEN7(dev)) { > /* Workaround stalls observed on Sandy Bridge GPUs by >* making the blitter command streamer generate a >* write to the Hardware Status Page for ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH resend] drm/i915: Enable GPU reset on Ivybridge.
According to the hardware documentation, GDRST is exactly the same as on Sandybridge. So simply enable the existing code. Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_drv.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) (Somehow this got lost; resending. It still applies cleanly to -next.) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 649278f..ec4308d 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -580,6 +580,7 @@ int i915_reset(struct drm_device *dev, u8 flags) if (get_seconds() - dev_priv->last_gpu_reset < 5) { DRM_ERROR("GPU hanging too fast, declaring wedged!\n"); } else switch (INTEL_INFO(dev)->gen) { + case 7: case 6: ret = gen6_do_reset(dev, flags); /* If reset with a user forcewake, try to restore */ -- 1.7.4.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/10] UXA Render acceleration for Ivybridge
Hi, This patch series adds 2D render acceleration for Ivybridge, using UXA. It also refactors some (some!) of the duplicated code between Xv and render. I've done very minimal testing, but it seems to work. --Kenneth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] render: New Ivybridge assembly programs for render acceleration.
These are exactly the same as the ones for Sandybridge, but with message registers translated (hopefully) in the same way as Haihao's new programs (m1 == g65). Signed-off-by: Kenneth Graunke --- src/i965_render.c | 95 +++- src/render_program/exa_wm_mask_affine.g7a | 41 ++ src/render_program/exa_wm_mask_affine.g7b |4 + src/render_program/exa_wm_mask_projective.g7a | 63 src/render_program/exa_wm_mask_projective.g7b | 12 +++ src/render_program/exa_wm_mask_sample_a.g7a| 49 src/render_program/exa_wm_mask_sample_a.g7b|3 + src/render_program/exa_wm_mask_sample_argb.g7a | 49 src/render_program/exa_wm_mask_sample_argb.g7b |3 + src/render_program/exa_wm_src_projective.g7a | 63 src/render_program/exa_wm_src_projective.g7b | 12 +++ src/render_program/exa_wm_src_sample_a.g7a | 48 src/render_program/exa_wm_src_sample_a.g7b |3 + 13 files changed, 442 insertions(+), 3 deletions(-) create mode 100644 src/render_program/exa_wm_mask_affine.g7a create mode 100644 src/render_program/exa_wm_mask_affine.g7b create mode 100644 src/render_program/exa_wm_mask_projective.g7a create mode 100644 src/render_program/exa_wm_mask_projective.g7b create mode 100644 src/render_program/exa_wm_mask_sample_a.g7a create mode 100644 src/render_program/exa_wm_mask_sample_a.g7b create mode 100644 src/render_program/exa_wm_mask_sample_argb.g7a create mode 100644 src/render_program/exa_wm_mask_sample_argb.g7b create mode 100644 src/render_program/exa_wm_src_projective.g7a create mode 100644 src/render_program/exa_wm_src_projective.g7b create mode 100644 src/render_program/exa_wm_src_sample_a.g7a create mode 100644 src/render_program/exa_wm_src_sample_a.g7b diff --git a/src/i965_render.c b/src/i965_render.c index b76107d..5ab53c4 100644 --- a/src/i965_render.c +++ b/src/i965_render.c @@ -538,6 +538,74 @@ static const uint32_t ps_kernel_masknoca_projective_static_gen6[][4] = { #include "exa_wm_write.g6b" }; +/* programs for GEN7 */ +static const uint32_t ps_kernel_nomask_affine_static_gen7[][4] = { +#include "exa_wm_src_affine.g7b" +#include "exa_wm_src_sample_argb.g7b" +#include "exa_wm_write.g7b" +}; + +static const uint32_t ps_kernel_nomask_projective_static_gen7[][4] = { +#include "exa_wm_src_projective.g7b" +#include "exa_wm_src_sample_argb.g7b" +#include "exa_wm_write.g7b" +}; + +static const uint32_t ps_kernel_maskca_affine_static_gen7[][4] = { +#include "exa_wm_src_affine.g7b" +#include "exa_wm_src_sample_argb.g7b" +#include "exa_wm_mask_affine.g7b" +#include "exa_wm_mask_sample_argb.g7b" +#include "exa_wm_ca.g6b" +#include "exa_wm_write.g7b" +}; + +static const uint32_t ps_kernel_maskca_projective_static_gen7[][4] = { +#include "exa_wm_src_projective.g7b" +#include "exa_wm_src_sample_argb.g7b" +#include "exa_wm_mask_projective.g7b" +#include "exa_wm_mask_sample_argb.g7b" +#include "exa_wm_ca.g4b.gen5" +#include "exa_wm_write.g7b" +}; + +static const uint32_t ps_kernel_maskca_srcalpha_affine_static_gen7[][4] = { +#include "exa_wm_src_affine.g7b" +#include "exa_wm_src_sample_a.g7b" +#include "exa_wm_mask_affine.g7b" +#include "exa_wm_mask_sample_argb.g7b" +#include "exa_wm_ca_srcalpha.g6b" +#include "exa_wm_write.g7b" +}; + +static const uint32_t ps_kernel_maskca_srcalpha_projective_static_gen7[][4] = { +#include "exa_wm_src_projective.g7b" +#include "exa_wm_src_sample_a.g7b" +#include "exa_wm_mask_projective.g7b" +#include "exa_wm_mask_sample_argb.g7b" +#include "exa_wm_ca_srcalpha.g6b" +#include "exa_wm_write.g7b" +}; + +static const uint32_t ps_kernel_masknoca_affine_static_gen7[][4] = { +#include "exa_wm_src_affine.g7b" +#include "exa_wm_src_sample_argb.g7b" +#include "exa_wm_mask_affine.g7b" +#include "exa_wm_mask_sample_a.g7b" +#include "exa_wm_noca.g6b" +#include "exa_wm_write.g7b" +}; + +static const uint32_t ps_kernel_masknoca_projective_static_gen7[][4] = { +#include "exa_wm_src_projective.g7b" +#include "exa_wm_src_sample_argb.g7b" +#include "exa_wm_mask_projective.g7b" +#include "exa_wm_mask_sample_a.g7b" +#include "exa_wm_noca.g6b" +#include "exa_wm_write.g7b" +}; + + typedef enum { SAMPLER_STATE_FILTER_NEAREST, SAMPLER_STATE_FILTER_BILINEAR, @@ -629,6 +697,25 @@ static const struct wm_kernel_info wm_kernels_gen6[] = { ps_kernel_masknoca_projective_static_gen6, TRUE), }; +static const struct wm_kernel_info wm_kernels_gen7
[Intel-gfx] [PATCH 02/10] render: Update SURFACE_STATE for Ivybridge.
Signed-off-by: Kenneth Graunke --- src/i965_render.c | 91 +++- 1 files changed, 82 insertions(+), 9 deletions(-) diff --git a/src/i965_render.c b/src/i965_render.c index 5ab53c4..bb3c2b7 100644 --- a/src/i965_render.c +++ b/src/i965_render.c @@ -723,10 +723,10 @@ typedef struct _brw_cc_unit_state_padded { char pad[64 - sizeof(struct brw_cc_unit_state)]; } brw_cc_unit_state_padded; -typedef struct brw_surface_state_padded { - struct brw_surface_state state; - char pad[32 - sizeof(struct brw_surface_state)]; -} brw_surface_state_padded; +#ifndef MAX +#define MAX(a, b) ((a) > (b) ? (a) : (b)) +#endif +#define SURFACE_STATE_PADDED_SIZE ALIGN(MAX(sizeof(struct brw_surface_state), sizeof(struct gen7_surface_state)), 32) struct gen4_cc_unit_state { /* Index by [src_blend][dst_blend] */ @@ -1161,7 +1161,7 @@ static sampler_state_extend_t sampler_state_extend_from_picture(int repeat_type) * picture in the given surface state buffer. */ static int -i965_set_picture_surface_state(intel_screen_private *intel, +gen4_set_picture_surface_state(intel_screen_private *intel, PicturePtr picture, PixmapPtr pixmap, Bool is_dst) { @@ -1215,7 +1215,70 @@ i965_set_picture_surface_state(intel_screen_private *intel, priv->bo); offset = intel->surface_used; - intel->surface_used += sizeof(struct brw_surface_state_padded); + intel->surface_used += SURFACE_STATE_PADDED_SIZE; + + if (is_dst) + priv->dst_bound = offset; + else + priv->src_bound = offset; + + return offset; +} + +static int +gen7_set_picture_surface_state(intel_screen_private *intel, + PicturePtr picture, PixmapPtr pixmap, + Bool is_dst) +{ + struct intel_pixmap *priv = intel_get_pixmap_private(pixmap); + struct gen7_surface_state *ss; + uint32_t write_domain, read_domains; + int offset; + + if (is_dst) { + write_domain = I915_GEM_DOMAIN_RENDER; + read_domains = I915_GEM_DOMAIN_RENDER; + } else { + write_domain = 0; + read_domains = I915_GEM_DOMAIN_SAMPLER; + } + intel_batch_mark_pixmap_domains(intel, priv, + read_domains, write_domain); + if (is_dst) { + if (priv->dst_bound) + return priv->dst_bound; + } else { + if (priv->src_bound) + return priv->src_bound; + } + + ss = (struct gen7_surface_state *) + (intel->surface_data + intel->surface_used); + + memset(ss, 0, sizeof(*ss)); + ss->ss0.surface_type = BRW_SURFACE_2D; + if (is_dst) + ss->ss0.surface_format = i965_get_dest_format(picture); + else + ss->ss0.surface_format = i965_get_card_format(picture); + + ss->ss0.tile_walk = 0; /* Tiled X */ + ss->ss0.tiled_surface = intel_pixmap_tiled(pixmap) ? 1 : 0; + ss->ss1.base_addr = priv->bo->offset; + + ss->ss2.height = pixmap->drawable.height - 1; + ss->ss2.width = pixmap->drawable.width - 1; + ss->ss3.pitch = intel_pixmap_pitch(pixmap) - 1; + + dri_bo_emit_reloc(intel->surface_bo, + read_domains, write_domain, + 0, + intel->surface_used + + offsetof(struct gen7_surface_state, ss1), + priv->bo); + + offset = intel->surface_used; + intel->surface_used += SURFACE_STATE_PADDED_SIZE; if (is_dst) priv->dst_bound = offset; @@ -1225,6 +1288,16 @@ i965_set_picture_surface_state(intel_screen_private *intel, return offset; } +static inline int +i965_set_picture_surface_state(intel_screen_private *intel, + PicturePtr picture, PixmapPtr pixmap, + Bool is_dst) +{ +if (INTEL_INFO(intel)->gen < 70) +return gen4_set_picture_surface_state(intel, picture, pixmap, is_dst); +return gen7_set_picture_surface_state(intel, picture, pixmap, is_dst); +} + static void gen4_composite_vertex_elements(struct intel_screen_private *intel) { struct gen4_render_state *render_state = intel->gen4_render_state; @@ -1968,7 +2041,7 @@ i965_prepare_composite(int op, PicturePtr source_picture, } if (sizeof(intel->surface_data) - intel->surface_used < - 4 * sizeof(struct brw_surface_state_padded)) + 4 * SURFACE_STATE_PADDED_SIZE) i965_surface_flush(intel); intel->needs_render_state_emit = TRUE; @@ -2014,11 +2087,11 @@ static void i965_bind_s
[Intel-gfx] [PATCH 03/10] render: Update SAMPLER_STATE for Ivybridge.
Signed-off-by: Kenneth Graunke --- src/i965_render.c | 133 + 1 files changed, 124 insertions(+), 9 deletions(-) diff --git a/src/i965_render.c b/src/i965_render.c index bb3c2b7..1dfdde4 100644 --- a/src/i965_render.c +++ b/src/i965_render.c @@ -842,7 +842,7 @@ static drm_intel_bo *sampler_border_color_create(intel_screen_private *intel) } static void -sampler_state_init(drm_intel_bo * sampler_state_bo, +gen4_sampler_state_init(drm_intel_bo * sampler_state_bo, struct brw_sampler_state *sampler_state, sampler_state_filter_t filter, sampler_state_extend_t extend, @@ -907,6 +907,74 @@ sampler_state_init(drm_intel_bo * sampler_state_bo, sampler_state->ss3.chroma_key_enable = 0; /* disable chromakey */ } +static void +gen7_sampler_state_init(drm_intel_bo * sampler_state_bo, + struct gen7_sampler_state *sampler_state, + sampler_state_filter_t filter, + sampler_state_extend_t extend, + drm_intel_bo * border_color_bo) +{ + uint32_t sampler_state_offset; + + sampler_state_offset = (char *)sampler_state - + (char *)sampler_state_bo->virtual; + + /* PS kernel use this sampler */ + memset(sampler_state, 0, sizeof(*sampler_state)); + + sampler_state->ss0.lod_preclamp = 1;/* GL mode */ + + /* We use the legacy mode to get the semantics specified by +* the Render extension. */ + sampler_state->ss0.default_color_mode = BRW_BORDER_COLOR_MODE_LEGACY; + + switch (filter) { + default: + case SAMPLER_STATE_FILTER_NEAREST: + sampler_state->ss0.min_filter = BRW_MAPFILTER_NEAREST; + sampler_state->ss0.mag_filter = BRW_MAPFILTER_NEAREST; + break; + case SAMPLER_STATE_FILTER_BILINEAR: + sampler_state->ss0.min_filter = BRW_MAPFILTER_LINEAR; + sampler_state->ss0.mag_filter = BRW_MAPFILTER_LINEAR; + break; + } + + switch (extend) { + default: + case SAMPLER_STATE_EXTEND_NONE: + sampler_state->ss3.r_wrap_mode = BRW_TEXCOORDMODE_CLAMP_BORDER; + sampler_state->ss3.s_wrap_mode = BRW_TEXCOORDMODE_CLAMP_BORDER; + sampler_state->ss3.t_wrap_mode = BRW_TEXCOORDMODE_CLAMP_BORDER; + break; + case SAMPLER_STATE_EXTEND_REPEAT: + sampler_state->ss3.r_wrap_mode = BRW_TEXCOORDMODE_WRAP; + sampler_state->ss3.s_wrap_mode = BRW_TEXCOORDMODE_WRAP; + sampler_state->ss3.t_wrap_mode = BRW_TEXCOORDMODE_WRAP; + break; + case SAMPLER_STATE_EXTEND_PAD: + sampler_state->ss3.r_wrap_mode = BRW_TEXCOORDMODE_CLAMP; + sampler_state->ss3.s_wrap_mode = BRW_TEXCOORDMODE_CLAMP; + sampler_state->ss3.t_wrap_mode = BRW_TEXCOORDMODE_CLAMP; + break; + case SAMPLER_STATE_EXTEND_REFLECT: + sampler_state->ss3.r_wrap_mode = BRW_TEXCOORDMODE_MIRROR; + sampler_state->ss3.s_wrap_mode = BRW_TEXCOORDMODE_MIRROR; + sampler_state->ss3.t_wrap_mode = BRW_TEXCOORDMODE_MIRROR; + break; + } + + sampler_state->ss2.default_color_pointer = + intel_emit_reloc(sampler_state_bo, sampler_state_offset + +offsetof(struct gen7_sampler_state, ss2), +border_color_bo, 0, +I915_GEM_DOMAIN_SAMPLER, 0) >> 5; + + sampler_state->ss3.chroma_key_enable = 0; /* disable chromakey */ +} + + + static drm_intel_bo *gen4_create_sampler_state(intel_screen_private *intel, sampler_state_filter_t src_filter, sampler_state_extend_t src_extend, @@ -923,18 +991,65 @@ static drm_intel_bo *gen4_create_sampler_state(intel_screen_private *intel, drm_intel_bo_map(sampler_state_bo, TRUE); sampler_state = sampler_state_bo->virtual; - sampler_state_init(sampler_state_bo, - &sampler_state[0], - src_filter, src_extend, border_color_bo); - sampler_state_init(sampler_state_bo, - &sampler_state[1], - mask_filter, mask_extend, border_color_bo); + gen4_sampler_state_init(sampler_state_bo, + &sampler_state[0], + src_filter, src_extend, border_color_bo); + gen4_sampler_state_init(sampler_state_bo, + &sampler_state[1], + mask_filter, mask_extend, border_color_bo); + + drm_intel_bo_unmap(sampler_state_bo); + + return sampler_s
[Intel-gfx] [PATCH 04/10] render: Set Address Modify Enable in 3DSTATE_VERTEX_BUFFERS on Gen7.
Signed-off-by: Kenneth Graunke --- src/i965_render.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/i965_render.c b/src/i965_render.c index 1dfdde4..ec10392 100644 --- a/src/i965_render.c +++ b/src/i965_render.c @@ -2167,10 +2167,14 @@ i965_prepare_composite(int op, PicturePtr source_picture, static void i965_select_vertex_buffer(struct intel_screen_private *intel) { int id = intel->gen4_render_state->composite_op.vertex_id; + int modifyenable = 0; if (intel->vertex_id & (1 << id)) return; + if (INTEL_INFO(intel)->gen >= 70) + modifyenable = GEN7_VB0_ADDRESS_MODIFYENABLE; + /* Set up the pointer to our (single) vertex buffer */ OUT_BATCH(BRW_3DSTATE_VERTEX_BUFFERS | 3); @@ -2180,6 +2184,7 @@ static void i965_select_vertex_buffer(struct intel_screen_private *intel) if (INTEL_INFO(intel)->gen >= 60) { OUT_BATCH((id << GEN6_VB0_BUFFER_INDEX_SHIFT) | GEN6_VB0_VERTEXDATA | + modifyenable | (4*intel->floats_per_vertex << VB0_BUFFER_PITCH_SHIFT)); } else { OUT_BATCH((id << VB0_BUFFER_INDEX_SHIFT) | -- 1.7.4.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] Xv: Refactor out pipeline setup functions for future reuse in render.
While we're at it, make the functions simply take an intel_screen_private pointer directly instead of having to fetch it from ScrnInfoPtr. Also coalesce some gen6/gen7 functions that were 98% identical. Cc: Xiang, Haihao Signed-off-by: Kenneth Graunke --- src/Makefile.am |1 + src/i965_3d.c| 430 ++ src/i965_video.c | 500 +++--- src/intel.h | 29 +++ 4 files changed, 482 insertions(+), 478 deletions(-) create mode 100644 src/i965_3d.c diff --git a/src/Makefile.am b/src/Makefile.am index a7f219c..cd1bb36 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -67,6 +67,7 @@ intel_drv_la_SOURCES = \ i915_render.c \ i915_video.c \ i965_reg.h \ +i965_3d.c \ i965_video.c \ i965_render.c \ $(NULL) diff --git a/src/i965_3d.c b/src/i965_3d.c new file mode 100644 index 000..19ddee7 --- /dev/null +++ b/src/i965_3d.c @@ -0,0 +1,430 @@ +/* + * Copyright � 2011 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include + +#include "intel.h" +#include "i965_reg.h" +#include "brw_defines.h" +#include "brw_structs.h" + +void +gen6_upload_invariant_states(intel_screen_private *intel) +{ + Bool ivb = INTEL_INFO(intel)->gen >= 70; + + OUT_BATCH(BRW_PIPE_CONTROL | (4 - 2)); + OUT_BATCH(BRW_PIPE_CONTROL_IS_FLUSH | + BRW_PIPE_CONTROL_WC_FLUSH | + BRW_PIPE_CONTROL_DEPTH_CACHE_FLUSH | + BRW_PIPE_CONTROL_NOWRITE); + OUT_BATCH(0); /* write address */ + OUT_BATCH(0); /* write data */ + + OUT_BATCH(NEW_PIPELINE_SELECT | PIPELINE_SELECT_3D); + + OUT_BATCH(GEN6_3DSTATE_MULTISAMPLE | ((ivb ? 4 : 3) - 2)); + OUT_BATCH(GEN6_3DSTATE_MULTISAMPLE_PIXEL_LOCATION_CENTER | + GEN6_3DSTATE_MULTISAMPLE_NUMSAMPLES_1); /* 1 sample/pixel */ + OUT_BATCH(0); + if (ivb) + OUT_BATCH(0); + + OUT_BATCH(GEN6_3DSTATE_SAMPLE_MASK | (2 - 2)); + OUT_BATCH(1); + + /* Set system instruction pointer */ + OUT_BATCH(BRW_STATE_SIP | 0); + OUT_BATCH(0); +} + +void +gen6_upload_viewport_state_pointers(intel_screen_private *intel, + drm_intel_bo *cc_vp_bo) +{ + OUT_BATCH(GEN6_3DSTATE_VIEWPORT_STATE_POINTERS | + GEN6_3DSTATE_VIEWPORT_STATE_MODIFY_CC | + (4 - 2)); + OUT_BATCH(0); + OUT_BATCH(0); + OUT_RELOC(cc_vp_bo, I915_GEM_DOMAIN_INSTRUCTION, 0, 0); +} + +void +gen7_upload_viewport_state_pointers(intel_screen_private *intel, + drm_intel_bo *cc_vp_bo) +{ + OUT_BATCH(GEN7_3DSTATE_VIEWPORT_STATE_POINTERS_CC | (2 - 2)); + OUT_RELOC(cc_vp_bo, I915_GEM_DOMAIN_INSTRUCTION, 0, 0); + + OUT_BATCH(GEN7_3DSTATE_VIEWPORT_STATE_POINTERS_SF_CL | (2 - 2)); + OUT_BATCH(0); +} + +void +gen6_upload_urb(intel_screen_private *intel) +{ + OUT_BATCH(GEN6_3DSTATE_URB | (3 - 2)); + OUT_BATCH(((1 - 1) << GEN6_3DSTATE_URB_VS_SIZE_SHIFT) | + (24 << GEN6_3DSTATE_URB_VS_ENTRIES_SHIFT)); /* at least 24 on GEN6 */ + OUT_BATCH((0 << GEN6_3DSTATE_URB_GS_SIZE_SHIFT) | + (0 << GEN6_3DSTATE_URB_GS_ENTRIES_SHIFT)); /* no GS thread */ +} + +/* + * URB layout on GEN7 + * + * | PS Push Constants (8KB) | VS entries | + * + */ +void +gen7_upload_urb(intel_screen_private *intel) +{ + OUT_BATCH(GEN7_3DSTATE_PUSH_CONSTANT_ALLOC_PS | (2 - 2)); + OUT_BATCH(8); /* in 1KBs */ + + OUT_BATCH(GEN7_3DSTATE_URB_VS | (2 - 2)); +
[Intel-gfx] [PATCH 07/10] render: Refactor to use newly shared pipeline setup code in i965_3d.c.
Slightly generalize the shared SF and CC code to accomodate both. Signed-off-by: Kenneth Graunke --- src/i965_3d.c | 28 +--- src/i965_render.c | 183 + src/i965_video.c |8 +- src/intel.h | 10 ++- 4 files changed, 44 insertions(+), 185 deletions(-) diff --git a/src/i965_3d.c b/src/i965_3d.c index 19ddee7..d4d38e5 100644 --- a/src/i965_3d.c +++ b/src/i965_3d.c @@ -130,11 +130,13 @@ void gen6_upload_cc_state_pointers(intel_screen_private *intel, drm_intel_bo *blend_bo, drm_intel_bo *cc_bo, - drm_intel_bo *depth_stencil_bo) + drm_intel_bo *depth_stencil_bo, + uint32_t blend_offset) { OUT_BATCH(GEN6_3DSTATE_CC_STATE_POINTERS | (4 - 2)); if (blend_bo) - OUT_RELOC(blend_bo, I915_GEM_DOMAIN_INSTRUCTION, 0, 1); + OUT_RELOC(blend_bo, I915_GEM_DOMAIN_INSTRUCTION, 0, + blend_offset | 1); else OUT_BATCH(0); @@ -153,11 +155,13 @@ void gen7_upload_cc_state_pointers(intel_screen_private *intel, drm_intel_bo *blend_bo, drm_intel_bo *cc_bo, - drm_intel_bo *depth_stencil_bo) + drm_intel_bo *depth_stencil_bo, + uint32_t blend_offset) { OUT_BATCH(GEN7_3DSTATE_BLEND_STATE_POINTERS | (2 - 2)); if (blend_bo) - OUT_RELOC(blend_bo, I915_GEM_DOMAIN_INSTRUCTION, 0, 1); + OUT_RELOC(blend_bo, I915_GEM_DOMAIN_INSTRUCTION, 0, + blend_offset | 1); else OUT_BATCH(0); @@ -320,12 +324,14 @@ gen6_upload_clip_state(intel_screen_private *intel) } void -gen6_upload_sf_state(intel_screen_private *intel) +gen6_upload_sf_state(intel_screen_private *intel, +int num_sf_outputs, +int read_offset) { OUT_BATCH(GEN6_3DSTATE_SF | (20 - 2)); - OUT_BATCH((1 << GEN6_3DSTATE_SF_NUM_OUTPUTS_SHIFT) | + OUT_BATCH((num_sf_outputs << GEN6_3DSTATE_SF_NUM_OUTPUTS_SHIFT) | (1 << GEN6_3DSTATE_SF_URB_ENTRY_READ_LENGTH_SHIFT) | - (0 << GEN6_3DSTATE_SF_URB_ENTRY_READ_OFFSET_SHIFT)); + (read_offset << GEN6_3DSTATE_SF_URB_ENTRY_READ_OFFSET_SHIFT)); OUT_BATCH(0); OUT_BATCH(GEN6_3DSTATE_SF_CULL_NONE); OUT_BATCH(2 << GEN6_3DSTATE_SF_TRIFAN_PROVOKE_SHIFT); /* DW4 */ @@ -347,12 +353,14 @@ gen6_upload_sf_state(intel_screen_private *intel) } void -gen7_upload_sf_state(intel_screen_private *intel) +gen7_upload_sf_state(intel_screen_private *intel, +int num_sf_outputs, +int read_offset) { OUT_BATCH(GEN7_3DSTATE_SBE | (14 - 2)); - OUT_BATCH((1 << GEN7_SBE_NUM_OUTPUTS_SHIFT) | + OUT_BATCH((num_sf_outputs << GEN7_SBE_NUM_OUTPUTS_SHIFT) | (1 << GEN7_SBE_URB_ENTRY_READ_LENGTH_SHIFT) | - (0 << GEN7_SBE_URB_ENTRY_READ_OFFSET_SHIFT)); + (read_offset << GEN7_SBE_URB_ENTRY_READ_OFFSET_SHIFT)); OUT_BATCH(0); OUT_BATCH(0); OUT_BATCH(0); /* DW4 */ diff --git a/src/i965_render.c b/src/i965_render.c index c9b3c7a..17e35c9 100644 --- a/src/i965_render.c +++ b/src/i965_render.c @@ -2538,24 +2538,6 @@ gen6_composite_create_depth_stencil_state(intel_screen_private *intel) } static void -gen6_composite_invariant_states(intel_screen_private *intel) -{ - OUT_BATCH(NEW_PIPELINE_SELECT | PIPELINE_SELECT_3D); - - OUT_BATCH(GEN6_3DSTATE_MULTISAMPLE | (3 - 2)); - OUT_BATCH(GEN6_3DSTATE_MULTISAMPLE_PIXEL_LOCATION_CENTER | - GEN6_3DSTATE_MULTISAMPLE_NUMSAMPLES_1); /* 1 sample/pixel */ - OUT_BATCH(0); - - OUT_BATCH(GEN6_3DSTATE_SAMPLE_MASK | (2 - 2)); - OUT_BATCH(1); - - /* Set system instruction pointer */ - OUT_BATCH(BRW_STATE_SIP | 0); - OUT_BATCH(0); -} - -static void gen6_composite_state_base_address(intel_screen_private *intel) { OUT_BATCH(BRW_STATE_BASE_ADDRESS | (10 - 2)); @@ -2573,52 +2555,21 @@ gen6_composite_state_base_address(intel_screen_private *intel) } static void -gen6_composite_viewport_state_pointers(intel_screen_private *intel, - drm_intel_bo *cc_vp_bo) -{ - - OUT_BATCH(GEN6_3DSTATE_VIEWPORT_STATE_POINTERS | - GEN6_3DSTATE_VIEWPORT_STATE_MODIFY_CC | - (4 - 2)); - OUT_BATCH(0); - OUT_BATCH(0); - OUT_RELOC(cc_vp_bo, I915_GEM_DOMAIN_INSTRUCTION, 0, 0); -} - -static void -gen6_composite_urb(intel_screen_private *intel) -{ - OUT_BATCH(GEN6_3DSTATE_URB | (3 - 2)); - OUT_BATCH(((1 - 1) << GEN6_3DSTATE_URB_VS_SIZE_SHIF
[Intel-gfx] [PATCH 08/10] render: Use Ivybridge variants for 3D pipeline setup.
Signed-off-by: Kenneth Graunke --- src/i965_render.c | 50 +++--- 1 files changed, 39 insertions(+), 11 deletions(-) diff --git a/src/i965_render.c b/src/i965_render.c index 17e35c9..5222d1c 100644 --- a/src/i965_render.c +++ b/src/i965_render.c @@ -2569,7 +2569,11 @@ gen6_composite_cc_state_pointers(intel_screen_private *intel, cc_bo = render_state->cc_state_bo; depth_stencil_bo = render_state->gen6_depth_stencil_bo; } - gen6_upload_cc_state_pointers(intel, render_state->gen6_blend_bo, cc_bo, depth_stencil_bo, blend_offset); + if (INTEL_INFO(intel)->gen >= 70) { + gen7_upload_cc_state_pointers(intel, render_state->gen6_blend_bo, cc_bo, depth_stencil_bo, blend_offset); + } else { + gen6_upload_cc_state_pointers(intel, render_state->gen6_blend_bo, cc_bo, depth_stencil_bo, blend_offset); + } intel->gen6_render_state.blend = blend_offset; } @@ -2583,18 +2587,26 @@ gen6_composite_sampler_state_pointers(intel_screen_private *intel, intel->gen6_render_state.samplers = bo; - gen6_upload_sampler_state_pointers(intel, bo); + if (INTEL_INFO(intel)->gen >= 70) + gen7_upload_sampler_state_pointers(intel, bo); + else + gen6_upload_sampler_state_pointers(intel, bo); } static void gen6_composite_wm_constants(intel_screen_private *intel) { + Bool ivb = INTEL_INFO(intel)->gen >= 70; /* disable WM constant buffer */ - OUT_BATCH(GEN6_3DSTATE_CONSTANT_PS | (5 - 2)); + OUT_BATCH(GEN6_3DSTATE_CONSTANT_PS | ((ivb ? 7 : 5) - 2)); OUT_BATCH(0); OUT_BATCH(0); OUT_BATCH(0); OUT_BATCH(0); + if (ivb) { + OUT_BATCH(0); + OUT_BATCH(0); + } } static void @@ -2608,7 +2620,10 @@ gen6_composite_sf_state(intel_screen_private *intel, intel->gen6_render_state.num_sf_outputs = num_sf_outputs; - gen6_upload_sf_state(intel, num_sf_outputs, 1); + if (INTEL_INFO(intel)->gen >= 70) + gen7_upload_sf_state(intel, num_sf_outputs, 1); + else + gen6_upload_sf_state(intel, num_sf_outputs, 1); } static void @@ -2754,20 +2769,30 @@ gen6_emit_composite_state(struct intel_screen_private *intel) sampler_state_extend_t mask_extend = composite_op->mask_extend; Bool is_affine = composite_op->is_affine; Bool has_mask = intel->render_mask != NULL; + Bool ivb = INTEL_INFO(intel)->gen >= 70; uint32_t src, dst; drm_intel_bo *ps_sampler_state_bo = render->ps_sampler_state_bo[src_filter][src_extend][mask_filter][mask_extend]; intel->needs_render_state_emit = FALSE; if (intel->needs_3d_invariant) { gen6_upload_invariant_states(intel); - gen6_upload_viewport_state_pointers(intel, render->cc_vp_bo); - gen6_upload_urb(intel); + if (ivb) { + gen7_upload_viewport_state_pointers(intel, render->cc_vp_bo); + gen7_upload_urb(intel); + gen7_upload_bypass_states(intel); + gen7_upload_depth_buffer_state(intel); + } else { + gen6_upload_invariant_states(intel); + gen6_upload_viewport_state_pointers(intel, render->cc_vp_bo); + gen6_upload_urb(intel); + + gen6_upload_gs_state(intel); + gen6_upload_depth_buffer_state(intel); + } + gen6_composite_wm_constants(intel); gen6_upload_vs_state(intel); - gen6_upload_gs_state(intel); gen6_upload_clip_state(intel); - gen6_composite_wm_constants(intel); - gen6_upload_depth_buffer_state(intel); intel->needs_3d_invariant = FALSE; } @@ -2787,8 +2812,11 @@ gen6_emit_composite_state(struct intel_screen_private *intel) gen6_composite_wm_state(intel, has_mask, render->wm_kernel_bo[composite_op->wm_kernel]); - gen6_upload_binding_table(intel, intel->surface_table); - + if (ivb) { + gen7_upload_binding_table(intel, intel->surface_table); + } else { + gen6_upload_binding_table(intel, intel->surface_table); + } gen6_composite_drawing_rectangle(intel, intel->render_dest); gen6_composite_vertex_element_state(intel, has_mask, is_affine); } -- 1.7.4.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/10] render: Update pixel shader state for Ivybridge.
Signed-off-by: Kenneth Graunke --- src/i965_render.c | 38 +++--- 1 files changed, 35 insertions(+), 3 deletions(-) diff --git a/src/i965_render.c b/src/i965_render.c index 5222d1c..596d070 100644 --- a/src/i965_render.c +++ b/src/i965_render.c @@ -2657,6 +2657,37 @@ gen6_composite_wm_state(intel_screen_private *intel, } static void +gen7_composite_wm_state(intel_screen_private *intel, + Bool has_mask, + drm_intel_bo *bo) +{ + int num_surfaces = has_mask ? 3 : 2; + + if (intel->gen6_render_state.kernel == bo) + return; + + intel->gen6_render_state.kernel = bo; + + OUT_BATCH(GEN6_3DSTATE_WM | (3 - 2)); + OUT_BATCH(GEN7_WM_DISPATCH_ENABLE | + GEN7_WM_PERSPECTIVE_PIXEL_BARYCENTRIC); + OUT_BATCH(0); + + OUT_BATCH(GEN7_3DSTATE_PS | (8 - 2)); + OUT_RELOC(bo, I915_GEM_DOMAIN_INSTRUCTION, 0, 0); + OUT_BATCH((1 << GEN7_PS_SAMPLER_COUNT_SHIFT) | + (num_surfaces << GEN7_PS_BINDING_TABLE_ENTRY_COUNT_SHIFT)); + OUT_BATCH(0); /* scratch space base offset */ + OUT_BATCH(((86 - 1) << GEN7_PS_MAX_THREADS_SHIFT) | + GEN7_PS_ATTRIBUTE_ENABLE | + GEN7_PS_16_DISPATCH_ENABLE); + OUT_BATCH((6 << GEN7_PS_DISPATCH_START_GRF_SHIFT_0)); + OUT_BATCH(0); /* kernel 1 pointer */ + OUT_BATCH(0); /* kernel 2 pointer */ +} + + +static void gen6_composite_drawing_rectangle(intel_screen_private *intel, PixmapPtr dest) { @@ -2809,12 +2840,13 @@ gen6_emit_composite_state(struct intel_screen_private *intel) (src * BRW_BLENDFACTOR_COUNT + dst) * GEN6_BLEND_STATE_PADDED_SIZE); gen6_composite_sampler_state_pointers(intel, ps_sampler_state_bo); gen6_composite_sf_state(intel, has_mask); - gen6_composite_wm_state(intel, - has_mask, - render->wm_kernel_bo[composite_op->wm_kernel]); if (ivb) { + gen7_composite_wm_state(intel, has_mask, + render->wm_kernel_bo[composite_op->wm_kernel]); gen7_upload_binding_table(intel, intel->surface_table); } else { + gen6_composite_wm_state(intel, has_mask, + render->wm_kernel_bo[composite_op->wm_kernel]); gen6_upload_binding_table(intel, intel->surface_table); } gen6_composite_drawing_rectangle(intel, intel->render_dest); -- 1.7.4.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] render: Enable RENDER acceleration on Ivybridge.
Signed-off-by: Kenneth Graunke --- src/i965_render.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/src/i965_render.c b/src/i965_render.c index 596d070..7e1da5b 100644 --- a/src/i965_render.c +++ b/src/i965_render.c @@ -184,9 +184,6 @@ i965_check_composite(int op, ScrnInfoPtr scrn = xf86Screens[dest_picture->pDrawable->pScreen->myNum]; intel_screen_private *intel = intel_get_screen_private(scrn); - if (IS_GEN7(intel)) - return FALSE; - /* Check for unsupported compositing operations. */ if (op >= sizeof(i965_blend_op) / sizeof(i965_blend_op[0])) { intel_debug_fallback(scrn, -- 1.7.4.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/10] render: Update 3DPRIMITIVE for Ivybridge.
Signed-off-by: Kenneth Graunke --- src/i965_render.c | 16 +++- 1 files changed, 11 insertions(+), 5 deletions(-) diff --git a/src/i965_render.c b/src/i965_render.c index ec10392..c9b3c7a 100644 --- a/src/i965_render.c +++ b/src/i965_render.c @@ -2262,11 +2262,17 @@ i965_composite(PixmapPtr dest, int srcX, int srcY, int maskX, int maskY, i965_select_vertex_buffer(intel); if (intel->vertex_offset == 0) { - OUT_BATCH(BRW_3DPRIMITIVE | - BRW_3DPRIMITIVE_VERTEX_SEQUENTIAL | - (_3DPRIM_RECTLIST << BRW_3DPRIMITIVE_TOPOLOGY_SHIFT) | - (0 << 9) | - 4); + if (INTEL_INFO(intel)->gen >= 70) { + OUT_BATCH(BRW_3DPRIMITIVE | (7 - 2)); + OUT_BATCH(BRW_3DPRIMITIVE_VERTEX_SEQUENTIAL | + _3DPRIM_RECTLIST); + } else { + OUT_BATCH(BRW_3DPRIMITIVE | + BRW_3DPRIMITIVE_VERTEX_SEQUENTIAL | + (_3DPRIM_RECTLIST << BRW_3DPRIMITIVE_TOPOLOGY_SHIFT) | + (0 << 9) | + 4); + } intel->vertex_offset = intel->batch_used; OUT_BATCH(0); /* vertex count, to be filled in later */ OUT_BATCH(intel->vertex_index); -- 1.7.4.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] I need help before I can help
On 07/15/2011 11:00 PM, Andrew Yurkevitch wrote: > Hello, all > > I am having a little trouble compiling the mesa 3d 7.10.2 driver for my > machine. My graphics card is an Intel 82845G/GL[Brookdale-G]/GE Chipset > Integrated Graphics. I currently have an older version which works, but > not correctly. With the driver set to "intel" in my xorg.conf, I get > (relatively) fast 3d with incorrect rendering, and Xvideo doesn't work. > Without the driver part, I get an undetected monitor (only get 1024x768 > resolution), Xvideo works, and 3d runs at 1-2 FPS but renders correctly. > I believe I have everything I need to compile, however I get the > following error for the command "make linux-dri-x86" (same without "-x86"): Most of us use autoconf to build Mesa (it annoyingly has three different build systems). You might try something along the lines of: $ ./configure --disable-glut --enable-xcb --disable-glu --disable-glw --with-gallium-drivers='' --with-dri-drivers=swrast,i915 --enable-debug $ make > glxext.c:136: error: ‘xGLXBufferSwapComplete2’ undeclared (first use in > this function) > > I have the package x11proto-gl-dev installed with the file > "/usr/include/GL/glxproto.h" in the proper place, however upon > inspection, the file does not have 'xGLXBufferSwapComplete2' defined, > only 'xGLXBufferSwapComplete'. Do I need an older version of the > package, or do I need to patch 'glxproto.h', or what? Thank you in advance! That's a relatively new addition...you'll need to install glproto from git as well: git://git.freedesktop.org/git/xorg/proto/glproto > --Static > > P.S. Is the IRC channel exclusive to testers? I would have asked on IRC, > but I was instantly banned for some reason. No, for some reason the channel is just set up strangely. You'll need to register with NickServ on Freenode and identify...otherwise it says you are 'banned' and won't let you do anything. It's very odd. --Kenneth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dri: Do not tile stencil buffer
On 07/18/2011 05:08 PM, Chad Versace wrote: > Until now, the stencil buffer was allocated as a Y tiled buffer, because > in several locations the PRM states that it is. However, it is actually > W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part 2, Section > 4.5.2.1 W-Major Format: > W-Major Tile Format is used for separate stencil. > > The GTT is incapable of W fencing, so we allocate the stencil buffer with > I915_TILING_NONE and decode the tile's layout in software. > > This commit mutually depends on the mesa commit: > intel: Fix stencil buffer to be W tiled > Author: Chad Versace > Date: Mon Jul 18 00:37:45 2011 -0700 > > CC: Eric Anholt > CC: Kenneth Graunke > CC: Ian Romancik > Signed-off-by: Chad Versace > --- > src/intel_dri.c | 16 > 1 files changed, 12 insertions(+), 4 deletions(-) For the series: Acked-by: Kenneth Graunke (I would say Reviewed-by, but I haven't verified the math. That said, I don't think I need to...I've seen how rigorously you investigated this.) Happy to see these go in whenever. We definitely need them in 7.11 and 2.16. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: clear GFX_MODE on IVB at init time
On 08/12/2011 03:28 PM, Jesse Barnes wrote: > On Fri, 12 Aug 2011 15:18:09 -0700 > Jesse Barnes wrote: > >> On Fri, 12 Aug 2011 14:55:32 -0700 >> Jesse Barnes wrote: >> >>> GFX_MODE controls important behavior like PPGTT, run lists, and TLB >>> invalidate behavior. On the SDV I'm using, the TLB invalidation mode >>> was defaulting to "pipe control only" which meant regular MI_FLUSHes >>> wouldn't actually flush the TLB, leading to all sorts of stale data >>> getting used. >>> >>> So initialize it to 0 at ring buffer init time until we actually use >>> PIPE_CONTROL for TLB invalidation. >> >> Ignore this one, see below for an updated patch that uses bit >> definitions and makes sure the register gets reset at GPU reset time as >> well. > > Ignore the last one too. Third time's the charm! Tested-by: Kenneth Graunke With drm-intel-next, I've been seeing frequent but intermittent rendering corruption in GNOME Terminal, rendercheck failures, and the occasional kernel crash. After applying the patch, I was able to run for an entire day without any crashes or rendering corruption. To double check, I reverted this patch and was immediately able to reproduce my earlier problems. With this patch and C0 hardware, my system seems quite stable. Thanks Jesse! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
From: Jesse Barnes Signed-off-by: Jesse Barnes Signed-off-by: Kenneth Graunke Tested-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h |7 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 131 --- 2 files changed, 124 insertions(+), 14 deletions(-) I've been using this patch on my Ivybridge system for a while; it seems to work just fine. The difference between this and Jesse's earlier patch is that we added the VFC bit. diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 138eae1..9ef448a 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -243,6 +243,8 @@ #define DISPLAY_PLANE_A (0<<20) #define DISPLAY_PLANE_B (1<<20) #define GFX_OP_PIPE_CONTROL((0x3<<29)|(0x3<<27)|(0x2<<24)|2) +#define GFX_OP_PIPE_CONTROL_GEN6 ((0x3<<29)|(0x3<<27)|(0x2<<24)|3) +#define PIPE_CONTROL_CS_STALL (1<<20) #define PIPE_CONTROL_QW_WRITE(1<<14) #define PIPE_CONTROL_DEPTH_STALL (1<<13) #define PIPE_CONTROL_WC_FLUSH(1<<12) @@ -250,9 +252,10 @@ #define PIPE_CONTROL_TC_FLUSH (1<<10) /* GM45+ only */ #define PIPE_CONTROL_ISP_DIS (1<<9) #define PIPE_CONTROL_NOTIFY (1<<8) +#define PIPE_CONTROL_VFC (1<<4) #define PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */ -#define PIPE_CONTROL_STALL_EN(1<<1) /* in addr word, Ironlake+ only */ - +#define PIPE_CONTROL_STALL_AT_SCOREBOARD (1<<1) /* in addr word, Ironlake+ only */ +#define PIPE_CONTROL_DEPTH_FLUSH (1<<0) /* * Reset registers diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 0e99589..ad969fa 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -34,6 +34,16 @@ #include "i915_trace.h" #include "intel_drv.h" +/* + * 965+ support PIPE_CONTROL commands, which provide finer grained control + * over cache flushing. + */ +struct pipe_control { + struct drm_i915_gem_object *obj; + volatile u32 *cpu_page; + u32 gtt_offset; +}; + static inline int ring_space(struct intel_ring_buffer *ring) { int space = (ring->head & HEAD_ADDR) - (ring->tail + 8); @@ -123,6 +133,113 @@ render_ring_flush(struct intel_ring_buffer *ring, return 0; } +/** + * Emits a PIPE_CONTROL with a non-zero post-sync operation, for + * implementing two workarounds on gen6. From section 1.4.7.1 + * "PIPE_CONTROL" of the Sandy Bridge PRM volume 2 part 1: + * + * [DevSNB-C+{W/A}] Before any depth stall flush (including those + * produced by non-pipelined state commands), software needs to first + * send a PIPE_CONTROL with no bits set except Post-Sync Operation != + * 0. + * + * [Dev-SNB{W/A}]: Before a PIPE_CONTROL with Write Cache Flush Enable + * =1, a PIPE_CONTROL with any non-zero post-sync-op is required. + * + * And the workaround for these two requires this workaround first: + * + * [Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent + * BEFORE the pipe-control with a post-sync op and no write-cache + * flushes. + * + * And this last workaround is tricky because of the requirements on + * that bit. From section 1.4.7.2.3 "Stall" of the Sandy Bridge PRM + * volume 2 part 1: + * + * "1 of the following must also be set: + * - Render Target Cache Flush Enable ([12] of DW1) + * - Depth Cache Flush Enable ([0] of DW1) + * - Stall at Pixel Scoreboard ([1] of DW1) + * - Depth Stall ([13] of DW1) + * - Post-Sync Operation ([13] of DW1) + * - Notify Enable ([8] of DW1)" + * + * The cache flushes require the workaround flush that triggered this + * one, so we can't use it. Depth stall would trigger the same. + * Post-sync nonzero is what triggered this second workaround, so we + * can't use that one either. Notify enable is IRQs, which aren't + * really our business. That leaves only stall at scoreboard. + */ +static int +intel_emit_post_sync_nonzero_flush(struct intel_ring_buffer *ring) +{ + struct pipe_control *pc = ring->private; + u32 scratch_addr = pc->gtt_offset + 128; + int ret; + + + ret = intel_ring_begin(ring, 6); + if (ret) + return ret; + + intel_ring_emit(ring, GFX_OP_PIPE_CONTROL_GEN6); + intel_ring_emit(ring, PIPE_CONTROL_CS_STALL | + PIPE_CONTROL_STALL_AT_SCOREBOARD); + intel_ring_emit(ring, scratch_addr | PIPE_CONTROL_GLOBAL_GTT); /* address */ + intel_ring_emit(ring, 0); /* low dword */ + intel_ring_emit(ring, 0); /* high dword */ + intel_ring_emit(ring, MI_NOOP); + intel_ring_advance(ring); + + ret = intel_ring_begin(ring, 6); + if (ret) + return ret; + + intel_rin
Re: [Intel-gfx] [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
On 09/26/2011 12:16 PM, Chris Wilson wrote: > On Mon, 26 Sep 2011 11:59:23 -0700, Kenneth Graunke > wrote: >> From: Jesse Barnes > > From the school of "If ain't broke, don't fix it" there needs to be a real > explanation of why this change is required here. > > PIPE_CONTROL and its workarounds is a very bitter pill to swallow if > MI_FLUSH continues to function. > -Chris I hear you. The issue is that (from Eric's reading of the simulator) MI_FLUSH seems to be equivalent to PIPE_CONTROL with some unknown set of bits enabled...which means we likely do need workarounds. It's just not clear which ones. Also, according to the BSpec, MI_FLUSH is no longer validated or guaranteed to work on Ivybridge. I heard they said that about Sandybridge as well but later recanted...I don't know if they will this time, though. I suspect that it actually is broke, and we do need to fix it. This seems like a first step. --Kenneth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
On 09/26/2011 01:31 PM, Daniel Vetter wrote: > On Mon, Sep 26, 2011 at 11:59:23AM -0700, Kenneth Graunke wrote: >> +static int >> +gen6_render_ring_flush(struct intel_ring_buffer *ring, >> + u32 invalidate_domains, u32 flush_domains) >> +{ >> +u32 flags = 0; >> +struct pipe_control *pc = ring->private; >> +u32 scratch_addr = pc->gtt_offset + 128; >> +int ret; >> + >> +/* Force SNB workarounds for PIPE_CONTROL flushes */ >> +intel_emit_post_sync_nonzero_flush(ring); >> + >> +/* Just flush everything for now */ >> +flags |= PIPE_CONTROL_WC_FLUSH; >> +flags |= PIPE_CONTROL_IS_FLUSH; >> +flags |= PIPE_CONTROL_TC_FLUSH; >> +flags |= PIPE_CONTROL_DEPTH_FLUSH; >> +flags |= PIPE_CONTROL_VFC; > > Any reason you're not also setting the constant cache and state cache > invalidate bits? > -Daniel Bits 2 and 3? No particular reason; perhaps they should be. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] i915: Remove implied length of 2 from GFX_OP_PIPE_CONTROL #define.
Not all PIPE_CONTROLs have a length of 2, so remove it from the #define and make each invocation specify the desired length. Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h |2 +- drivers/gpu/drm/i915/intel_ringbuffer.c |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 138eae1..d691781 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -242,7 +242,7 @@ #define ASYNC_FLIP(1<<22) #define DISPLAY_PLANE_A (0<<20) #define DISPLAY_PLANE_B (1<<20) -#define GFX_OP_PIPE_CONTROL((0x3<<29)|(0x3<<27)|(0x2<<24)|2) +#define GFX_OP_PIPE_CONTROL((0x3<<29)|(0x3<<27)|(0x2<<24)) #define PIPE_CONTROL_QW_WRITE(1<<14) #define PIPE_CONTROL_DEPTH_STALL (1<<13) #define PIPE_CONTROL_WC_FLUSH(1<<12) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 0e99589..67ce601 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -467,7 +467,7 @@ pc_render_add_request(struct intel_ring_buffer *ring, if (ret) return ret; - intel_ring_emit(ring, GFX_OP_PIPE_CONTROL | PIPE_CONTROL_QW_WRITE | + intel_ring_emit(ring, GFX_OP_PIPE_CONTROL | 2 | PIPE_CONTROL_QW_WRITE | PIPE_CONTROL_WC_FLUSH | PIPE_CONTROL_TC_FLUSH); intel_ring_emit(ring, pc->gtt_offset | PIPE_CONTROL_GLOBAL_GTT); intel_ring_emit(ring, seqno); @@ -483,7 +483,7 @@ pc_render_add_request(struct intel_ring_buffer *ring, PIPE_CONTROL_FLUSH(ring, scratch_addr); scratch_addr += 128; PIPE_CONTROL_FLUSH(ring, scratch_addr); - intel_ring_emit(ring, GFX_OP_PIPE_CONTROL | PIPE_CONTROL_QW_WRITE | + intel_ring_emit(ring, GFX_OP_PIPE_CONTROL | 2 | PIPE_CONTROL_QW_WRITE | PIPE_CONTROL_WC_FLUSH | PIPE_CONTROL_TC_FLUSH | PIPE_CONTROL_NOTIFY); intel_ring_emit(ring, pc->gtt_offset | PIPE_CONTROL_GLOBAL_GTT); -- 1.7.6.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] i915: Rename PIPE_CONTROL bit defines to be less terse.
"STALL_AT_SCOREBOARD" is much clearer than "STALL_EN" now that there are several different kinds of stalls. Also, "INSTRUCTION_CACHE_FLUSH" is a lot easier to understand at a glance than the terse "IS_FLUSH." Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h | 16 drivers/gpu/drm/i915/intel_ringbuffer.c |6 -- 2 files changed, 12 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index d691781..bfe8488 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -243,15 +243,15 @@ #define DISPLAY_PLANE_A (0<<20) #define DISPLAY_PLANE_B (1<<20) #define GFX_OP_PIPE_CONTROL((0x3<<29)|(0x3<<27)|(0x2<<24)) -#define PIPE_CONTROL_QW_WRITE(1<<14) -#define PIPE_CONTROL_DEPTH_STALL (1<<13) -#define PIPE_CONTROL_WC_FLUSH(1<<12) -#define PIPE_CONTROL_IS_FLUSH(1<<11) /* MBZ on Ironlake */ -#define PIPE_CONTROL_TC_FLUSH (1<<10) /* GM45+ only */ -#define PIPE_CONTROL_ISP_DIS (1<<9) -#define PIPE_CONTROL_NOTIFY (1<<8) +#define PIPE_CONTROL_QW_WRITE(1<<14) +#define PIPE_CONTROL_DEPTH_STALL (1<<13) +#define PIPE_CONTROL_WRITE_FLUSH (1<<12) +#define PIPE_CONTROL_INSTRUCTION_CACHE_FLUSH (1<<11) /* MBZ on Ironlake */ +#define PIPE_CONTROL_TEXTURE_CACHE_FLUSH (1<<10) /* GM45+ only */ +#define PIPE_CONTROL_INDIRECT_STATE_DISABLE (1<<9) +#define PIPE_CONTROL_NOTIFY (1<<8) +#define PIPE_CONTROL_STALL_AT_SCOREBOARD (1<<1) #define PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */ -#define PIPE_CONTROL_STALL_EN(1<<1) /* in addr word, Ironlake+ only */ /* diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 67ce601..2b572fd 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -468,7 +468,8 @@ pc_render_add_request(struct intel_ring_buffer *ring, return ret; intel_ring_emit(ring, GFX_OP_PIPE_CONTROL | 2 | PIPE_CONTROL_QW_WRITE | - PIPE_CONTROL_WC_FLUSH | PIPE_CONTROL_TC_FLUSH); + PIPE_CONTROL_WRITE_FLUSH | + PIPE_CONTROL_TEXTURE_CACHE_FLUSH); intel_ring_emit(ring, pc->gtt_offset | PIPE_CONTROL_GLOBAL_GTT); intel_ring_emit(ring, seqno); intel_ring_emit(ring, 0); @@ -484,7 +485,8 @@ pc_render_add_request(struct intel_ring_buffer *ring, scratch_addr += 128; PIPE_CONTROL_FLUSH(ring, scratch_addr); intel_ring_emit(ring, GFX_OP_PIPE_CONTROL | 2 | PIPE_CONTROL_QW_WRITE | - PIPE_CONTROL_WC_FLUSH | PIPE_CONTROL_TC_FLUSH | + PIPE_CONTROL_WRITE_FLUSH | + PIPE_CONTROL_TEXTURE_CACHE_FLUSH | PIPE_CONTROL_NOTIFY); intel_ring_emit(ring, pc->gtt_offset | PIPE_CONTROL_GLOBAL_GTT); intel_ring_emit(ring, seqno); -- 1.7.6.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
From: Jesse Barnes Signed-off-by: Jesse Barnes Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h |5 + drivers/gpu/drm/i915/intel_ringbuffer.c | 136 --- 2 files changed, 129 insertions(+), 12 deletions(-) v2: - Add State & Constant Cache bits as suggested by Daniel. - Specify length directly rather than hiding it in a GEN6 #define. - Use more verbose bit field names, for clarity. diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index bfe8488..81713ae 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -243,6 +243,7 @@ #define DISPLAY_PLANE_A (0<<20) #define DISPLAY_PLANE_B (1<<20) #define GFX_OP_PIPE_CONTROL((0x3<<29)|(0x3<<27)|(0x2<<24)) +#define PIPE_CONTROL_CS_STALL(1<<20) #define PIPE_CONTROL_QW_WRITE(1<<14) #define PIPE_CONTROL_DEPTH_STALL (1<<13) #define PIPE_CONTROL_WRITE_FLUSH (1<<12) @@ -250,7 +251,11 @@ #define PIPE_CONTROL_TEXTURE_CACHE_FLUSH (1<<10) /* GM45+ only */ #define PIPE_CONTROL_INDIRECT_STATE_DISABLE (1<<9) #define PIPE_CONTROL_NOTIFY (1<<8) +#define PIPE_CONTROL_VF_CACHE_INVALIDATE (1<<4) +#define PIPE_CONTROL_CONST_CACHE_INVALIDATE (1<<3) +#define PIPE_CONTROL_STATE_CACHE_INVALIDATE (1<<2) #define PIPE_CONTROL_STALL_AT_SCOREBOARD (1<<1) +#define PIPE_CONTROL_DEPTH_CACHE_FLUSH (1<<0) #define PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */ diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 2b572fd..f841d5c 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -34,6 +34,16 @@ #include "i915_trace.h" #include "intel_drv.h" +/* + * 965+ support PIPE_CONTROL commands, which provide finer grained control + * over cache flushing. + */ +struct pipe_control { + struct drm_i915_gem_object *obj; + volatile u32 *cpu_page; + u32 gtt_offset; +}; + static inline int ring_space(struct intel_ring_buffer *ring) { int space = (ring->head & HEAD_ADDR) - (ring->tail + 8); @@ -123,6 +133,118 @@ render_ring_flush(struct intel_ring_buffer *ring, return 0; } +/** + * Emits a PIPE_CONTROL with a non-zero post-sync operation, for + * implementing two workarounds on gen6. From section 1.4.7.1 + * "PIPE_CONTROL" of the Sandy Bridge PRM volume 2 part 1: + * + * [DevSNB-C+{W/A}] Before any depth stall flush (including those + * produced by non-pipelined state commands), software needs to first + * send a PIPE_CONTROL with no bits set except Post-Sync Operation != + * 0. + * + * [Dev-SNB{W/A}]: Before a PIPE_CONTROL with Write Cache Flush Enable + * =1, a PIPE_CONTROL with any non-zero post-sync-op is required. + * + * And the workaround for these two requires this workaround first: + * + * [Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent + * BEFORE the pipe-control with a post-sync op and no write-cache + * flushes. + * + * And this last workaround is tricky because of the requirements on + * that bit. From section 1.4.7.2.3 "Stall" of the Sandy Bridge PRM + * volume 2 part 1: + * + * "1 of the following must also be set: + * - Render Target Cache Flush Enable ([12] of DW1) + * - Depth Cache Flush Enable ([0] of DW1) + * - Stall at Pixel Scoreboard ([1] of DW1) + * - Depth Stall ([13] of DW1) + * - Post-Sync Operation ([13] of DW1) + * - Notify Enable ([8] of DW1)" + * + * The cache flushes require the workaround flush that triggered this + * one, so we can't use it. Depth stall would trigger the same. + * Post-sync nonzero is what triggered this second workaround, so we + * can't use that one either. Notify enable is IRQs, which aren't + * really our business. That leaves only stall at scoreboard. + */ +static int +intel_emit_post_sync_nonzero_flush(struct intel_ring_buffer *ring) +{ + struct pipe_control *pc = ring->private; + u32 scratch_addr = pc->gtt_offset + 128; + int ret; + + + ret = intel_ring_begin(ring, 6); + if (ret) + return ret; + + intel_ring_emit(ring, GFX_OP_PIPE_CONTROL | 3); + intel_ring_emit(ring, PIPE_CONTROL_CS_STALL | + PIPE_CONTROL_STALL_AT_SCOREBOARD); + intel_ring_emit(ring, scratch_addr | PIPE_CONTROL_GLOBAL_GTT); /* address */ + intel_ring_emit(ring, 0); /* low dword */ + intel_ring_emit(ring, 0); /* high dword */ + intel_ring_emit(ring, MI_NOOP); + intel_ring_advance(ring); + + ret = intel_ring_begin(ring, 6); + if (ret) + return ret; + + intel_ring_emit(ri
Re: [Intel-gfx] [PATCH 2/3] i915: Rename PIPE_CONTROL bit defines to be less terse.
On 10/04/2011 01:30 AM, Daniel Vetter wrote: > On Mon, Oct 03, 2011 at 11:02:39PM -0700, Kenneth Graunke wrote: >> "STALL_AT_SCOREBOARD" is much clearer than "STALL_EN" now that there are >> several different kinds of stalls. Also, "INSTRUCTION_CACHE_FLUSH" is a >> lot easier to understand at a glance than the terse "IS_FLUSH." >> >> Signed-off-by: Kenneth Graunke >> --- >> drivers/gpu/drm/i915/i915_reg.h | 16 >> drivers/gpu/drm/i915/intel_ringbuffer.c |6 -- >> 2 files changed, 12 insertions(+), 10 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h >> b/drivers/gpu/drm/i915/i915_reg.h >> index d691781..bfe8488 100644 >> --- a/drivers/gpu/drm/i915/i915_reg.h >> +++ b/drivers/gpu/drm/i915/i915_reg.h >> @@ -243,15 +243,15 @@ >> #define DISPLAY_PLANE_A (0<<20) >> #define DISPLAY_PLANE_B (1<<20) >> #define GFX_OP_PIPE_CONTROL ((0x3<<29)|(0x3<<27)|(0x2<<24)) >> -#define PIPE_CONTROL_QW_WRITE (1<<14) >> -#define PIPE_CONTROL_DEPTH_STALL (1<<13) >> -#define PIPE_CONTROL_WC_FLUSH (1<<12) >> -#define PIPE_CONTROL_IS_FLUSH (1<<11) /* MBZ on Ironlake */ >> -#define PIPE_CONTROL_TC_FLUSH (1<<10) /* GM45+ only */ >> -#define PIPE_CONTROL_ISP_DIS (1<<9) >> -#define PIPE_CONTROL_NOTIFY (1<<8) >> +#define PIPE_CONTROL_QW_WRITE (1<<14) >> +#define PIPE_CONTROL_DEPTH_STALL (1<<13) >> +#define PIPE_CONTROL_WRITE_FLUSH (1<<12) >> +#define PIPE_CONTROL_INSTRUCTION_CACHE_FLUSH (1<<11) /* MBZ on >> Ironlake */ >> +#define PIPE_CONTROL_TEXTURE_CACHE_FLUSH (1<<10) /* GM45+ only */ > > Minor bikeshed: You retain the _FLUSH for the read-only > instruction/texture caches, but use _INVALIDATE for the new bits for > read-only caches. I think we want _INVALIDATE for all of them. > > Otherwise, these three patches are: > Reviewed-by: Daniel Vetter Yeah. The docs for pre-SNB use "Flush" in all the field names, while the docs for SNB+ switch to "Invalidate". So I just used it for the new ones. If we'd rather go with "invalidate" for the old bits too, I can do that. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Force sync command ordering
On 10/11/2011 11:31 AM, Ben Widawsky wrote: > This will strongly order synchronization commands with respect to 3d > state and 3d primitive commands. AFAIK, this shouldn't impact anything > as these sync commands are all for privileged (or ppgtt) batches only, > so user space should not be relying on this, and the kernel wouldn't be > relying on 3d state or primitive commands. > > This will help when we enable PPGTT, and perhaps this synchronization is > currently useful and I just don't realize it. > > This was found through doc inspection by Ken and applies to Gen6+; > > Reported-by: Kenneth Graunke > Signed-off-by: Ben Widawsky > --- > drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 ++-- > drivers/gpu/drm/i915/i915_reg.h|1 + > drivers/gpu/drm/i915/intel_ringbuffer.c|2 ++ > 3 files changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index 9572e52..1d55842 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -976,6 +976,7 @@ i915_set_constant_offset(struct intel_ring_buffer *ring, > int mode) > { > struct drm_device *dev = ring->dev; > struct drm_i915_private *dev_priv = dev->dev_private; > + uint32_t mask = I915_EXEC_CONSTANTS_MASK; > int ret; > > switch (mode) { > @@ -991,6 +992,10 @@ i915_set_constant_offset(struct intel_ring_buffer *ring, > int mode) > mode == I915_EXEC_CONSTANTS_REL_SURFACE) > return -EINVAL; > > + /* Never clear this bit because of execbuffer */ > + if (INTEL_INFO(dev)->gen >= 6) > + mask &= ~(INSTPM_FORCE_ORDERING); > + I might do: /* This bit doesn't exist on Gen6+. */ if (INTEL_INFO(dev)->gen >= 6) mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE; ...but, I don't mind either way. > ret = intel_ring_begin(ring, 4); > if (ret) > return ret; > @@ -998,8 +1003,7 @@ i915_set_constant_offset(struct intel_ring_buffer *ring, > int mode) > intel_ring_emit(ring, MI_NOOP); > intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1)); > intel_ring_emit(ring, INSTPM); > - intel_ring_emit(ring, > - I915_EXEC_CONSTANTS_MASK << 16 | mode); > + intel_ring_emit(ring, mask << 16 | mode); > intel_ring_advance(ring); > > dev_priv->relative_constants_mode = mode; > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 138eae1..51569f2 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -436,6 +436,7 @@ > #define INSTPM_AGPBUSY_DIS (1<<11) /* gen3: when disabled, pending > interrupts > will not assert AGPBUSY# and will only > be delivered when out of C3. */ > +#define INSTPM_FORCE_ORDERING (1<<7) /* GEN6+ > */ > #define ACTHD0x020c8 > #define FW_BLC 0x020d8 > #define FW_BLC2 0x020dc > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > index 0e99589..b1d312f 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > @@ -297,6 +297,8 @@ static int init_render_ring(struct intel_ring_buffer > *ring) > } > > if (INTEL_INFO(dev)->gen >= 6) { > + I915_WRITE(INSTPM, INSTPM_FORCE_ORDERING << 16 | > +INSTPM_FORCE_ORDERING); > } else if (IS_GEN5(dev)) { > ret = init_pipe_control(ring); > if (ret) I might only enable this on Gen7 for now, unless it actually fixes something on Sandybridge. It's not listed as required for Gen6. ___ 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: Remove implied length of 2 from GFX_OP_PIPE_CONTROL #define.
The series looks good, Daniel. Thanks for cleaning it up! ___ 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: Ivybridge still has fences!
On 10/23/2011 04:23 AM, Chris Wilson wrote: > Regardless of the outcome of Jesse's request for an if-ladder, the > substance of the patches look sound. > > However, I remain unconvinced that there are 32 fence registers on IVB. > Daniel's evidence is based upon the size of the register map (and not > on the BSPEC explicitly stating a change to 32 ;-), but most tellingly > the bitfields for fence-number in other registers have not been updated - > so we can only safely allocated the first 16 anyway... > (For instance, FBC_CTL). > -Chris It sure looks like it has 32 fence registers: BSpec vol1g GT Interface Register [DevIVB] / GT Interface Register DevIVB / System Agent Config Space lists FENCE0 through FENCE31. The simulator seems to indicate this as well. You're right that FBC_CTL still only has 4 bits for selecting a fence, but notably, in the latest (WIP) version of the BSpec, it says "This field must be programmed to b." I'm not sure how it's supposed to work now, but likely something has changed. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Question about how to troubleshoot sandybridge kernel opps and subsequest GPU lockup
On 10/24/2011 05:58 PM, James R. Leu wrote: > Debug output attached You're in luck! I fixed this GPU hang today in Mesa master. This commit fixes the hang: commit 3cc0a7be23ab603ed40d602595f673a44e079885 Author: Kenneth Graunke Date: Fri Oct 21 01:03:37 2011 -0700 i965: Apply post-sync non-zero workaround to homebrew workaround. In commit 3e5d3626, Eric added a homebrew workaround to fix GPU hangs in the Mesa "engine" demo and oglc's api-texcoord test. Unfortunately, his PIPE_CONTROL contains a Depth Stall, which necessitates the post-sync non-zero workaround, Fixes GPU hangs in Civilization 4, PlaneShift, and 3DMMES. Hopefully Heroes of Newerth as well, though I haven't tested that. NOTE: This is candidate for the 7.11 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40324 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41096 Signed-off-by: Kenneth Graunke Reviewed-and-tested-by: Eric Anholt I'm planning on cherry-picking it to the 7.11 branch in the next few days, so it ought to make the upcoming 7.11.1 release. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Remove BLT workaround for pre-production Sandybridge systems.
This code was effectively dead, as < rev08 never shipped. With the workaround gone, blt_ring_init became just another name for init_ring_common, so delete it and just call init_ring_common directly. This patch should not change behavior on Gen6 rev >= 8, nor Gen7. Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/intel_ringbuffer.c | 55 ++- 1 files changed, 3 insertions(+), 52 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index ca70e2f..8198ab3 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1345,66 +1345,17 @@ blt_ring_put_irq(struct intel_ring_buffer *ring) GEN6_BLITTER_USER_INTERRUPT); } - -/* Workaround for some stepping of SNB, - * each time when BLT engine ring tail moved, - * the first command in the ring to be parsed - * should be MI_BATCH_BUFFER_START - */ -#define NEED_BLT_WORKAROUND(dev) \ - (IS_GEN6(dev) && (dev->pdev->revision < 8)) - -static inline struct drm_i915_gem_object * -to_blt_workaround(struct intel_ring_buffer *ring) -{ - return ring->private; -} - -static int blt_ring_init(struct intel_ring_buffer *ring) -{ - if (NEED_BLT_WORKAROUND(ring->dev)) { - struct drm_i915_gem_object *obj; - u32 *ptr; - int ret; - - obj = i915_gem_alloc_object(ring->dev, 4096); - if (obj == NULL) - return -ENOMEM; - - ret = i915_gem_object_pin(obj, 4096, true); - if (ret) { - drm_gem_object_unreference(&obj->base); - return ret; - } - - ptr = kmap(obj->pages[0]); - *ptr++ = MI_BATCH_BUFFER_END; - *ptr++ = MI_NOOP; - kunmap(obj->pages[0]); - - ret = i915_gem_object_set_to_gtt_domain(obj, false); - if (ret) { - i915_gem_object_unpin(obj); - drm_gem_object_unreference(&obj->base); - return ret; - } - - ring->private = obj; - } - - return init_ring_common(ring); -} - static int blt_ring_begin(struct intel_ring_buffer *ring, int num_dwords) { if (ring->private) { + struct drm_i915_gem_object *obj = ring->private; int ret = intel_ring_begin(ring, num_dwords+2); if (ret) return ret; intel_ring_emit(ring, MI_BATCH_BUFFER_START); - intel_ring_emit(ring, to_blt_workaround(ring)->gtt_offset); + intel_ring_emit(ring, obj->gtt_offset); return 0; } else @@ -1447,7 +1398,7 @@ static const struct intel_ring_buffer gen6_blt_ring = { .id = RING_BLT, .mmio_base = BLT_RING_BASE, .size = 32 * PAGE_SIZE, - .init = blt_ring_init, + .init = init_ring_common, .write_tail = ring_write_tail, .flush = blt_ring_flush, .add_request= gen6_add_request, -- 1.7.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Remove extraneous MI_BATCHBUFFER_START from the BLT ring.
This looks like it was part of the BLT ring workaround which the prior patch removed. However, this is a separate patch because it changes behavior on shipping platforms. Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/intel_ringbuffer.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 8198ab3..9f11751 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1353,10 +1353,6 @@ static int blt_ring_begin(struct intel_ring_buffer *ring, int ret = intel_ring_begin(ring, num_dwords+2); if (ret) return ret; - - intel_ring_emit(ring, MI_BATCH_BUFFER_START); - intel_ring_emit(ring, obj->gtt_offset); - return 0; } else return intel_ring_begin(ring, 4); -- 1.7.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/ringbuffer: kill snb blt workaround
From: Daniel Vetter This was just to facilitate product enablement with pre-production hw. Allows us to kill quite a bit of cruft. Signed-off-by: Daniel Vetter Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt --- drivers/gpu/drm/i915/intel_ringbuffer.c | 81 +-- 1 files changed, 2 insertions(+), 79 deletions(-) Thanks Daniel, I missed that! This is much nicer. Here's your original patch rebased against drm-intel-next. I dropped the first hunk because the render ring now uses the cleanup hook for PIPE_CONTROL. Otherwise, it's the same. diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index ca70e2f..0602bb6 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1345,79 +1345,13 @@ blt_ring_put_irq(struct intel_ring_buffer *ring) GEN6_BLITTER_USER_INTERRUPT); } - -/* Workaround for some stepping of SNB, - * each time when BLT engine ring tail moved, - * the first command in the ring to be parsed - * should be MI_BATCH_BUFFER_START - */ -#define NEED_BLT_WORKAROUND(dev) \ - (IS_GEN6(dev) && (dev->pdev->revision < 8)) - -static inline struct drm_i915_gem_object * -to_blt_workaround(struct intel_ring_buffer *ring) -{ - return ring->private; -} - -static int blt_ring_init(struct intel_ring_buffer *ring) -{ - if (NEED_BLT_WORKAROUND(ring->dev)) { - struct drm_i915_gem_object *obj; - u32 *ptr; - int ret; - - obj = i915_gem_alloc_object(ring->dev, 4096); - if (obj == NULL) - return -ENOMEM; - - ret = i915_gem_object_pin(obj, 4096, true); - if (ret) { - drm_gem_object_unreference(&obj->base); - return ret; - } - - ptr = kmap(obj->pages[0]); - *ptr++ = MI_BATCH_BUFFER_END; - *ptr++ = MI_NOOP; - kunmap(obj->pages[0]); - - ret = i915_gem_object_set_to_gtt_domain(obj, false); - if (ret) { - i915_gem_object_unpin(obj); - drm_gem_object_unreference(&obj->base); - return ret; - } - - ring->private = obj; - } - - return init_ring_common(ring); -} - -static int blt_ring_begin(struct intel_ring_buffer *ring, - int num_dwords) -{ - if (ring->private) { - int ret = intel_ring_begin(ring, num_dwords+2); - if (ret) - return ret; - - intel_ring_emit(ring, MI_BATCH_BUFFER_START); - intel_ring_emit(ring, to_blt_workaround(ring)->gtt_offset); - - return 0; - } else - return intel_ring_begin(ring, 4); -} - static int blt_ring_flush(struct intel_ring_buffer *ring, u32 invalidate, u32 flush) { uint32_t cmd; int ret; - ret = blt_ring_begin(ring, 4); + ret = intel_ring_begin(ring, 4); if (ret) return ret; @@ -1432,22 +1366,12 @@ static int blt_ring_flush(struct intel_ring_buffer *ring, return 0; } -static void blt_ring_cleanup(struct intel_ring_buffer *ring) -{ - if (!ring->private) - return; - - i915_gem_object_unpin(ring->private); - drm_gem_object_unreference(ring->private); - ring->private = NULL; -} - static const struct intel_ring_buffer gen6_blt_ring = { .name = "blt ring", .id = RING_BLT, .mmio_base = BLT_RING_BASE, .size = 32 * PAGE_SIZE, - .init = blt_ring_init, + .init = init_ring_common, .write_tail = ring_write_tail, .flush = blt_ring_flush, .add_request= gen6_add_request, @@ -1455,7 +1379,6 @@ static const struct intel_ring_buffer gen6_blt_ring = { .irq_get= blt_ring_get_irq, .irq_put= blt_ring_put_irq, .dispatch_execbuffer= gen6_ring_dispatch_execbuffer, - .cleanup= blt_ring_cleanup, .sync_to= gen6_blt_ring_sync_to, .semaphore_register = {MI_SEMAPHORE_SYNC_BR, MI_SEMAPHORE_SYNC_BV, -- 1.7.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On 11/18/2011 10:41 PM, Keith Packard wrote: > RC6 should always work on IVB, and should work on SNB whenever IO > remapping is disabled. Make the default value for the parameter turn > it on in these cases. Setting the value to either 0 or 1 will force > the specified behavior. > > Signed-off-by: Keith Packard > --- > drivers/gpu/drm/i915/i915_drv.c |4 ++-- > drivers/gpu/drm/i915/i915_drv.h |2 +- > drivers/gpu/drm/i915/intel_display.c | 26 +++--- > 3 files changed, 26 insertions(+), 6 deletions(-) Reviewed-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/15] drm/i915: refactor debugfs open function
On 11/18/2011 06:24 PM, Ben Widawsky wrote: > From: Daniel Vetter > > Only forcewake has an open with special semantics, the other r/w > debugfs only assign the file private pointer. > > Signed-Off-by: Daniel Vetter > Signed-off-by: Ben Widawsky Patches 1 and 2 are Reviewed-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Add hook to obtain the irq signal on HDMI connectivity
On 11/24/2011 03:21 AM, Kavuri, Sateesh wrote: > Hi, > > I would like to add a hook to the i915 driver to get a signal whenever an > external > connection is made, say a HDMI cable connection. Where would the right place > be? > i915_irq.c? > Once I get a signal, I would have to read the EDID data (which I am already > done > with) and finally this connection needs to be signaled to the user space (for > which > the functionality already exists). > > Can someone point me to the right place? > > Thanks, > Sateesh I believe there is already infrastructure in place for this, so I doubt you'll need to add new hooks to the driver. But display is not my area of expertise; hopefully someone else here can point you at them. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/43] drm/i915: introduce a vtable for gpu core functions
On 12/14/2011 04:57 AM, Daniel Vetter wrote: > ... like for forcewake, which protects everything _but_ display. > Expect more things (like gtt abstractions, rings, inter-ring sync) > to come. > > Signed-Off-by: Daniel Vetter > Reviewed-by: Eugeni Dodonov > --- > drivers/gpu/drm/i915/i915_drv.c |6 +++--- > drivers/gpu/drm/i915/i915_drv.h |8 ++-- > drivers/gpu/drm/i915/intel_display.c |8 > 3 files changed, 13 insertions(+), 9 deletions(-) Reviewed-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 22/43] drm/i915: prevent division by zero when asking for chipset power
On 12/14/2011 04:57 AM, Daniel Vetter wrote: > From: Eugeni Dodonov > > This prevents an in-kernel division by zero which happens when we are > asking for i915_chipset_val too quickly, or within a race condition > between the power monitoring thread and userspace accesses via debugfs. > > The issue can be reproduced easily via the following command: > while ``; do cat /sys/kernel/debug/dri/0/i915_emon_status; done > > This is particularly dangerous because it can be triggered by > a non-privileged user by just reading the debugfs entry. > > This issue was also found independently by Konstantin Belousov > , who proposed a similar patch. > > Reported-by: Konstantin Belousov > Acked-by: Jesse Barnes > Acked-by: Keith Packard > Cc: > Signed-off-by: Eugeni Dodonov > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/i915/i915_dma.c | 10 ++ > drivers/gpu/drm/i915/i915_drv.h |1 + > 2 files changed, 11 insertions(+), 0 deletions(-) This has been in drm-intel-fixes since December 8th. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add support for resetting the SO write pointers on gen7.
On 12/29/2011 05:52 PM, Eric Anholt wrote: > These registers are automatically incremented by the hardware during > transform feedback to track where the next streamed vertex output > should go. Unlike the previous generation, which had a packet for > setting the corresponding registers to a defined value, gen7 only has > MI_LOAD_REGISTER_IMM to do so. That's a secure packet (since it loads > an arbitrary register), so we need to do it from the kernel, and it > needs to be settable atomically with the batchbuffer execution so that > two clients doing transform feedback don't stomp on each others' > state. > > Instead of building a more complicated interface involcing setting the > registers to a specific value, just set them to 0 when asked and > userland can tweak its pointers accordingly. > > Signed-off-by: Eric Anholt Looks great! Reviewed-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen7 missed IRQ workaround series.
On 12/22/2011 02:54 PM, Eric Anholt wrote: > This is the minimal patchset I have for working around the missed > IRQs. I've been running it since Monday doing test runs for other > work, and it appears to be stable. These all look okay to me, but this really isn't my area of expertise. Acked-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Drivers for gma 4500m?
On 01/04/2012 11:23 AM, je...@vige.it wrote: > Are the graphic drivers for gma 4500m included in the intel-gfx release? > If no there is a future develop for it? Yes, that's been supported for ages, and the drivers should already ship with basically any Linux distribution. You shouldn't have to download anything special. For reference, the drivers are 'i915' in the kernel (display), 'i965' in Mesa (3D), and 'xf86-video-intel' for X. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: paper over missed irq issues with force wake vodoo
On 01/10/2012 04:20 AM, Daniel Vetter wrote: On Wed, Jan 04, 2012 at 07:40:45PM +0100, Daniel Vetter wrote: Two things seem to do the trick on my ivb machine here: - prevent the gt from powering down while waiting for seqno notification interrupts by grabbing the force_wake in get_irq (and dropping it in put_irq again). - ordering writes from the ring's CS by reading a CS register, ACTHD seems to work. Only the blt&bsd ring on ivb seem to be massively affected by this, but for paranoia do this dance also on the render ring and on snb (i.e. all gpus with forcewake). Tested with Eric's glCopyPixels loop which without this patch scores a missed irq every few seconds. This patch needs my forcewake rework to use a spinlock instead of dev->struct_mutex. v2: Improve the comment per Eugeni Dodonov's suggestion. Cc: sta...@kernel.org Cc: Eric Anholt Cc: Kenneth Graunke Cc: Eugeni Dodonov Tested-by: Eugeni Dodonov Reviewed-by: Eugeni Dodonov Signed-Off-by: Daniel Vetter From the internal doc "SNB GT PM Programming Guide", Section 4.3.1: "GT does not generate interrupts while in RC6 (by design)" It talks about the PM interrupt but I think this might also apply to interrupts in general. So I think we should apply the voodoo patch also to snb. My current working theory is hw engineers changed the way hwstam writes are generated wrt to the read/write/irq pipeline on ivb and we've only been lucky that it syncs out everything on snb before the gpu goes into deep sleep states. -Daniel Daniel, This is a good find! Your patch looked good to me in the first place, but with this extra bit of information, I believe it all the more. It's simple and it makes a lot of sense. FWIW, Reviewed-by: Kenneth Graunke I'm in favor of applying this for Gen7, and I'd be fine with applying it on Gen6 too. At the very least we should experiment with it on Gen6---as Keith said, it might help with some of the mysterious issues we've seen. Worth a try at least. Thanks for your great work here! --Kenneth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Android port of intel-gpu-tools
On 01/09/2012 08:45 PM, Sateesh Kavuri wrote: Added support for Android. Changes include fixes for compilation issues related to Android using an older version of GCC compiler (ver 4.3.3) while the latest version of intel-gpu-tools confirms to GCC ver 4.5.2 (C99 standard functions), using functions like getline(). Fixed such functions, header dependencies for android and added an Android.mk file. signed-off-by: Sateesh Kavuri --- Android.mk | 528 lib/intel_drm.c|6 +- lib/intel_mmio.c |4 + lib/intel_pci.c|4 + tools/intel_decode.c | 10 + tools/intel_dump_decode.c | 14 +- tools/intel_error_decode.c | 14 ++ tools/intel_gpu_top.c |6 +- tools/intel_reg_write.c|2 + 9 files changed, 584 insertions(+), 4 deletions(-) create mode 100644 Android.mk diff --git a/Android.mk b/Android.mk new file mode 100644 index 000..0fc04cd --- /dev/null +++ b/Android.mk @@ -0,0 +1,528 @@ +LOCAL_PATH := $(call my-dir) +include $(CLEAR_VARS) + +LOCAL_SRC_FILES := \ + tools/intel_reg_write.c \ + lib/intel_pci.c \ + lib/intel_gpu_tools.h \ + tools/intel_reg.h \ + lib/intel_batchbuffer.h \ + lib/intel_batchbuffer.c \ + lib/intel_reg_map.c \ + lib/intel_mmio.c\ + tools/intel_chipset.h + + +LOCAL_C_INCLUDES +=\ + $(LOCAL_PATH)/lib \ + $(TOPDIR)hardware/intel/libdrm/include/drm \ + $(TOPDIR)hardware/intel/libdrm/intel\ + $(LOCAL_PATH)/../libpciaccess/include/ + +LOCAL_CFLAGS += -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 +LOCAL_CFLAGS += -DANDROID + +LOCAL_MODULE := intel_reg_write +LOCAL_MODULE_TAGS := optional + +LOCAL_SHARED_LIBRARIES := libpciaccess \ + libdrm \ + libdrm_intel + +include $(BUILD_EXECUTABLE) + +# +include $(CLEAR_VARS) + +LOCAL_SRC_FILES := \ + tools/intel_reg_read.c \ + lib/intel_pci.c \ + lib/intel_gpu_tools.h \ + tools/intel_reg.h \ + lib/intel_batchbuffer.h \ + lib/intel_batchbuffer.c \ + lib/intel_reg_map.c \ + lib/intel_mmio.c\ + tools/intel_chipset.h + + +LOCAL_C_INCLUDES +=\ + $(LOCAL_PATH)/lib \ + $(TOPDIR)hardware/intel/libdrm/include/drm \ + $(TOPDIR)hardware/intel/libdrm/intel\ + $(LOCAL_PATH)/../libpciaccess/include/ + +LOCAL_CFLAGS += -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 +LOCAL_CFLAGS += -DANDROID + + +LOCAL_MODULE := intel_reg_read +LOCAL_MODULE_TAGS := optional + +LOCAL_SHARED_LIBRARIES := libpciaccess \ + libdrm \ + libdrm_intel + +include $(BUILD_EXECUTABLE) + +# +include $(CLEAR_VARS) + +LOCAL_SRC_FILES := \ + tools/intel_disable_clock_gating.c \ + lib/intel_pci.c \ + lib/intel_gpu_tools.h \ + tools/intel_reg.h \ + lib/intel_batchbuffer.h \ + lib/intel_batchbuffer.c \ + lib/intel_mmio.c\ + tools/intel_chipset.h + + +LOCAL_C_INCLUDES +=\ + $(LOCAL_PATH)/lib \ + $(TOPDIR)hardware/intel/libdrm/include/drm \ + $(TOPDIR)hardware/intel/libdrm/intel\ + $(LOCAL_PATH)/../libpciaccess/include/ + +LOCAL_CFLAGS += -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 +LOCAL_CFLAGS += -DANDROID + + +LOCAL_MODULE := intel_disable_clock_gating +LOCAL_MODULE_TAGS := optional + +LOCAL_SHARED_LIBRARIES := libpciaccess \ + libdrm \ + libdrm_intel + +include $(BUILD_EXECUTABLE) + +# +include $(CLEAR_VARS) + +LOCAL_SRC_FILES := \ + tools/intel_audio_dump.c \ + lib/intel_pci.c \ + lib/intel_gpu_tools.h \ + tools/intel_reg.h \ + lib/intel_batchbuffer.h \ + lib/intel_batchbuffer.c \ + lib/intel_mmio.c\ + tools/intel_chipset.h + + +LOCAL_C_INCLUDES +=\ + $(LOCAL_PATH)/lib \ + $(TOPDIR)hardware/intel/libdrm/include/drm \ + $(TOPDIR)hardware/intel/libdrm/intel
Re: [Intel-gfx] [PATCH 1/1] drm/i915: add a LLC feature flag in device description
On 01/17/2012 08:43 AM, Eugeni Dodonov wrote: LLC is not SNB/IVB-specific, so we should check for it in a more generic way. Reviewed-by: Chris Wilson Reviewed-by: Daniel Vetter Signed-off-by: Eugeni Dodonov Reviewed-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Make XAA support optional
On 01/18/2012 06:36 AM, Eugeni Dodonov wrote: Wasn't DRI1 ripped from mesa as well? Yes it was, though theoretically you can still build DRI1 drivers from 7.11 and load them with 8.0. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove the MI_FLUSH_ENABLE setting.
On 01/19/2012 10:50 AM, Eric Anholt wrote: We have always been using the wrong bit -- it's bit 12. However, the bit also doesn't do anything -- hardware has always accepted the MI_FLUSH command even when it was specced not to. Given that there is only one MI_FLUSH emitted in all of the driver stack on gen6+ (in i965_video.c of the 2d driver, and it should be using other code to do its flush instead), just remove the MI_FLUSH enable instead of trying to fix it. Signed-off-by: Eric Anholt --- drivers/gpu/drm/i915/intel_ringbuffer.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 2df35e3..d21346b 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -389,8 +389,6 @@ static int init_render_ring(struct intel_ring_buffer *ring) if (INTEL_INFO(dev)->gen> 3) { int mode = VS_TIMER_DISPATCH<< 16 | VS_TIMER_DISPATCH; - if (IS_GEN6(dev) || IS_GEN7(dev)) - mode |= MI_FLUSH_ENABLE<< 16 | MI_FLUSH_ENABLE; I915_WRITE(MI_MODE, mode); if (IS_GEN7(dev)) I915_WRITE(GFX_MODE_GEN7, Everything using MI_FLUSH on SNB+ ought to be converted to PIPE_CONTROL. It sounds like everything except i965_video is there already. There's still the issue of old userspace, but...given that we were setting the wrong bit and _not_ setting the actual MI_FLUSH enable bit...it seems like this patch shouldn't break things. I'm all in favor of removing this code, as it's definitely a lie. For both patches: Reviewed-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Re-enable gen7 RC6 and GPU turbo after resume.
On 01/23/2012 04:14 PM, Eric Anholt wrote: Signed-off-by: Eric Anholt Cc: sta...@vger.kernel.org --- drivers/gpu/drm/i915/i915_suspend.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_suspend.c b/drivers/gpu/drm/i915/i915_suspend.c index 30d924f..2b5eb22 100644 --- a/drivers/gpu/drm/i915/i915_suspend.c +++ b/drivers/gpu/drm/i915/i915_suspend.c @@ -827,7 +827,7 @@ int i915_save_state(struct drm_device *dev) if (IS_IRONLAKE_M(dev)) ironlake_disable_drps(dev); - if (IS_GEN6(dev)) + if (INTEL_INFO(dev)->gen>= 6) gen6_disable_rps(dev); /* Cache mode state */ @@ -886,7 +886,7 @@ int i915_restore_state(struct drm_device *dev) intel_init_emon(dev); } - if (IS_GEN6(dev)) { + if (INTEL_INFO(dev)->gen>= 6) { gen6_enable_rps(dev_priv); gen6_update_ring_freq(dev_priv); } Reviewed-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Correct debugfs printout for RC1e.
On 01/23/2012 04:14 PM, Eric Anholt wrote: We had two things in a row claiming to be RC6. Signed-off-by: Eric Anholt --- drivers/gpu/drm/i915/i915_debugfs.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index a017b98..60dcee3 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1106,7 +1106,7 @@ static int gen6_drpc_info(struct seq_file *m) seq_printf(m, "SW control enabled: %s\n", yesno((rpmodectl1& GEN6_RP_MEDIA_MODE_MASK) == GEN6_RP_MEDIA_SW_MODE)); - seq_printf(m, "RC6 Enabled: %s\n", + seq_printf(m, "RC1e Enabled: %s\n", yesno(rcctl1& GEN6_RC_CTL_RC1e_ENABLE)); seq_printf(m, "RC6 Enabled: %s\n", yesno(rcctl1& GEN6_RC_CTL_RC6_ENABLE)); Reviewed-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: gen7: add two more IVB workarounds
On 02/03/2012 12:22 PM, Eugeni Dodonov wrote: This adds two cache-related workarounds for Ivy Bridge which can lead to 3D ring hangs and corruptions. Signed-off-by: Eugeni Dodonov --- drivers/gpu/drm/i915/i915_reg.h |7 +++ drivers/gpu/drm/i915/intel_display.c |6 ++ 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 80fd6b5..92274b1 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3028,6 +3028,13 @@ #define DISP_TILE_SURFACE_SWIZZLING (1<<13) #define DISP_FBC_WM_DIS (1<<15) +/* GEN7 chicken */ +#define GEN7_COMMON_SLICE_CHICKEN1 0x7010 +#define GEN7_WA_FOR_GEN7_L3_CONTROL 0x3C4FFF8C I'm skeptical of this value. Your mask doesn't match the bits you're setting: Actual chicken bits - bitdecode(0x3C4FFF8C & 0x): [2, 3, 7, 8, 9, 10, 11, 12, 13, 14, 15] Mask bits - bitdecode(0x3C4FFF8C >> 16): [0, 1, 2, 3, 6, 10, 11, 12, 13] Also, this is an awful lot of workarounds! I doubt we need all of them. On the BSpec Workaround page, I see a recommendation to set bits 10 and 26, but I don't see a rationale for the other ones. Is that sufficient? I'd also prefer to see these broken down into separate #defines for each bit rather than setting a magical value. +#define GEN7_L3_CHICKEN_MODE_REGISTER 0xB030 +#define GEN7_WA_L3_CHICKEN_MODE 0x2000 + This WA looks good and matches the docs (vol1i L3 URB > L3 Register Space (Bspec) > config space for L3 > L3CHMD - l3chicken mode). /* PCH */ /* south display engine interrupt */ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a72100f..49e5870 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8445,6 +8445,12 @@ static void gen6_init_clock_gating(struct drm_device *dev) ILK_DPARB_CLK_GATE | ILK_DPFD_CLK_GATE); + /* IVB workarounds */ + I915_WRITE(GEN7_COMMON_SLICE_CHICKEN1, + GEN7_WA_FOR_GEN7_L3_CONTROL); + I915_WRITE(GEN7_L3_CHICKEN_MODE_REGISTER, + GEN7_WA_L3_CHICKEN_MODE); + for_each_pipe(pipe) { I915_WRITE(DSPCNTR(pipe), I915_READ(DSPCNTR(pipe)) | ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: gen7: add two more IVB workarounds
On 02/03/2012 12:22 PM, Eugeni Dodonov wrote: This adds two cache-related workarounds for Ivy Bridge which can lead to 3D ring hangs and corruptions. Signed-off-by: Eugeni Dodonov --- drivers/gpu/drm/i915/i915_reg.h |7 +++ drivers/gpu/drm/i915/intel_display.c |6 ++ 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 80fd6b5..92274b1 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3028,6 +3028,13 @@ #define DISP_TILE_SURFACE_SWIZZLING (1<<13) #define DISP_FBC_WM_DIS (1<<15) +/* GEN7 chicken */ +#define GEN7_COMMON_SLICE_CHICKEN1 0x7010 +#define GEN7_WA_FOR_GEN7_L3_CONTROL 0x3C4FFF8C + +#define GEN7_L3_CHICKEN_MODE_REGISTER 0xB030 +#define GEN7_WA_L3_CHICKEN_MODE 0x2000 + /* PCH */ /* south display engine interrupt */ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a72100f..49e5870 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8445,6 +8445,12 @@ static void gen6_init_clock_gating(struct drm_device *dev) ILK_DPARB_CLK_GATE | ILK_DPFD_CLK_GATE); + /* IVB workarounds */ + I915_WRITE(GEN7_COMMON_SLICE_CHICKEN1, + GEN7_WA_FOR_GEN7_L3_CONTROL); + I915_WRITE(GEN7_L3_CHICKEN_MODE_REGISTER, + GEN7_WA_L3_CHICKEN_MODE); + for_each_pipe(pipe) { I915_WRITE(DSPCNTR(pipe), I915_READ(DSPCNTR(pipe)) | Also, shouldn't these be in the ivybridge_init_clock_gating function, not gen6? These are clearly Gen7 registers. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: gen7: work around a system hang on IVB
On 02/03/2012 12:22 PM, Eugeni Dodonov wrote: This adds the workaround for WaCatErrorRejectionIssue which could result in a system hang.. Signed-off-by: Eugeni Dodonov --- drivers/gpu/drm/i915/i915_reg.h |4 drivers/gpu/drm/i915/intel_display.c |4 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 92274b1..4f25cd5 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3035,6 +3035,10 @@ #define GEN7_L3_CHICKEN_MODE_REGISTER 0xB030 #define GEN7_WA_L3_CHICKEN_MODE 0x2000 +/* WaCatErrorRejectionIssue */ +#define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG 0x9030 +#define GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB (1<<11) + /* PCH */ /* south display engine interrupt */ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 49e5870..f7e86b8 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8451,6 +8451,10 @@ static void gen6_init_clock_gating(struct drm_device *dev) I915_WRITE(GEN7_L3_CHICKEN_MODE_REGISTER, GEN7_WA_L3_CHICKEN_MODE); + I915_WRITE(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG, + I915_READ(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG) | + GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB); + for_each_pipe(pipe) { I915_WRITE(DSPCNTR(pipe), I915_READ(DSPCNTR(pipe)) | Ditto: shouldn't this be in ivybridge_init_clock_gating? This does match the docs (vol1g GT Interface Register [IVB] > GT Interface Register DevIVB > MBCunit Config Space > SQCM - SQ Chicken Modes). Assuming it gets in a Gen7-specific location... Reviewed-by: Kenneth Graunke ___ 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: gen7: add two more IVB workarounds
On 02/05/2012 02:47 PM, Eugeni Dodonov wrote: This adds two cache-related workarounds for Ivy Bridge which can lead to 3D ring hangs and corruptions. Signed-off-by: Eugeni Dodonov --- drivers/gpu/drm/i915/i915_reg.h |7 +++ drivers/gpu/drm/i915/intel_display.c |6 ++ 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 80fd6b5..92274b1 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3028,6 +3028,13 @@ #define DISP_TILE_SURFACE_SWIZZLING (1<<13) #define DISP_FBC_WM_DIS (1<<15) +/* GEN7 chicken */ +#define GEN7_COMMON_SLICE_CHICKEN1 0x7010 +#define GEN7_WA_FOR_GEN7_L3_CONTROL 0x3C4FFF8C + +#define GEN7_L3_CHICKEN_MODE_REGISTER 0xB030 +#define GEN7_WA_L3_CHICKEN_MODE 0x2000 + /* PCH */ /* south display engine interrupt */ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 1defd42..eee0e75 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8475,6 +8475,12 @@ static void ivybridge_init_clock_gating(struct drm_device *dev) CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE | CHICKEN3_DGMG_DONE_FIX_DISABLE); + /* WaApplyL3ControlAndL3ChickenMode requires those two on Ivy Bridge */ + I915_WRITE(GEN7_COMMON_SLICE_CHICKEN1, + GEN7_WA_FOR_GEN7_L3_CONTROL); + I915_WRITE(GEN7_L3_CHICKEN_MODE_REGISTER, + GEN7_WA_L3_CHICKEN_MODE); + for_each_pipe(pipe) { I915_WRITE(DSPCNTR(pipe), I915_READ(DSPCNTR(pipe)) | Reviewed-by: Kenneth Graunke ___ 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: gen7: implement rczunit workaround
On 02/05/2012 02:47 PM, Eugeni Dodonov wrote: This is yet another workaround related to clock gating which we need on Ivy Bridge. Signed-off-by: Eugeni Dodonov --- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_display.c | 14 +++--- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index c3afb78..80fd6b5 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3618,6 +3618,7 @@ #defineGT_FIFO_NUM_RESERVED_ENTRIES 20 #define GEN6_UCGCTL2 0x9404 +# define GEN6_RCZUNIT_CLOCK_GATE_DISABLE (1<< 13) # define GEN6_RCPBUNIT_CLOCK_GATE_DISABLE (1<< 12) # define GEN6_RCCUNIT_CLOCK_GATE_DISABLE (1<< 11) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f1744aa..1defd42 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8396,6 +8396,7 @@ static void gen6_init_clock_gating(struct drm_device *dev) struct drm_i915_private *dev_priv = dev->dev_private; int pipe; uint32_t dspclk_gate = VRHUNIT_CLOCK_GATE_DISABLE; + u32 gstate; I915_WRITE(PCH_DSPCLK_GATE_D, dspclk_gate); @@ -8416,10 +8417,17 @@ static void gen6_init_clock_gating(struct drm_device *dev) * * According to the spec, bit 11 (RCCUNIT) must also be set, * but we didn't debug actual testcases to find it out. +* +* The bit 13 (RCZUNIT) must also be set, to implement the +* WaDisableRCZUnitClockGating workaround on Ivy Bridge. */ - I915_WRITE(GEN6_UCGCTL2, - GEN6_RCPBUNIT_CLOCK_GATE_DISABLE | - GEN6_RCCUNIT_CLOCK_GATE_DISABLE); + gstate = GEN6_RCPBUNIT_CLOCK_GATE_DISABLE | + GEN6_RCCUNIT_CLOCK_GATE_DISABLE; + + if (IS_IVYBRIDGE(dev)) + gstate |= GEN6_RCZUNIT_CLOCK_GATE_DISABLE; + + I915_WRITE(GEN6_UCGCTL2, gstate); /* * According to the spec the following bits should be Nack. gen6_init_clock_gating won't get run on Ivybridge... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Update generation checks to provide basic support for Ivybridge.
There may be some updates required, but assuming Ivybridge is similar to Sandybridge is a decent start; previously it fell through to the Gen2/3 case and nothing worked. Signed-off-by: Kenneth Graunke --- lib/intel_reg_map.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/intel_reg_map.c b/lib/intel_reg_map.c index 86cf9a6..0c8d49c 100644 --- a/lib/intel_reg_map.c +++ b/lib/intel_reg_map.c @@ -128,14 +128,15 @@ struct intel_register_map intel_get_register_map(uint32_t devid) { struct intel_register_map map; + const int gen = intel_gen(devid); - if (IS_GEN6(devid)) { + if (gen >= 6) { map.map = gen6_gt_register_map; map.top = 0x18; } else if (IS_BROADWATER(devid) || IS_CRESTLINE(devid)) { map.map = gen_bwcl_register_map; map.top = 0x8; - } else if (IS_GEN4(devid) || IS_GEN5(devid)) { + } else if (gen >= 4) { map.map = gen4_register_map; map.top = 0x8; } else { -- 1.7.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Ivybridge hang fixes respun
These fix many GPU hangs for Eugeni, though not on my machine for some reason. Oddly, the register writes to UCGCTL2 and SQ_CHICKEN_MBCUNIT_CONFIG stick, but the writes to L3_CHICKEN_MODE, L3CNTLREG1, and COMMON_SLICE_CHICKEN1 don't seem to take effect. Currently no theories why. Manually writing these values with intel_reg_write /does/ fix the hangs for me. I'm fine with these going to -fixes. They seem to help some people, and I highly doubt they'll make anything worse. It'd be nice to understand why the register writes aren't sticking, though... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: gen7: implement rczunit workaround
From: Eugeni Dodonov This is yet another workaround related to clock gating which we need on Ivy Bridge. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610 Tested-by: Eugeni Dodonov Signed-off-by: Eugeni Dodonov Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_display.c |5 + 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index c3afb78..80fd6b5 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3618,6 +3618,7 @@ #defineGT_FIFO_NUM_RESERVED_ENTRIES20 #define GEN6_UCGCTL2 0x9404 +# define GEN6_RCZUNIT_CLOCK_GATE_DISABLE (1 << 13) # define GEN6_RCPBUNIT_CLOCK_GATE_DISABLE (1 << 12) # define GEN6_RCCUNIT_CLOCK_GATE_DISABLE (1 << 11) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f1744aa..070c946 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8461,6 +8461,11 @@ static void ivybridge_init_clock_gating(struct drm_device *dev) I915_WRITE(WM2_LP_ILK, 0); I915_WRITE(WM1_LP_ILK, 0); + /* According to the spec, bit 13 (RCZUNIT) must be set on IVB. +* This implements the WaDisableRCZUnitClockGating workaround. +*/ + I915_WRITE(GEN6_UCGCTL2, GEN6_RCZUNIT_CLOCK_GATE_DISABLE); + I915_WRITE(ILK_DSPCLK_GATE, IVB_VRHUNIT_CLK_GATE); I915_WRITE(IVB_CHICKEN3, -- 1.7.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: gen7: Implement an L3 caching workaround.
From: Eugeni Dodonov This adds two cache-related workarounds for Ivy Bridge which can lead to 3D ring hangs and corruptions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610 Tested-by: Eugeni Dodonov Signed-off-by: Eugeni Dodonov Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h |7 +++ drivers/gpu/drm/i915/intel_display.c |6 ++ 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 80fd6b5..ca4737e 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3028,6 +3028,13 @@ #define DISP_TILE_SURFACE_SWIZZLING (1<<13) #define DISP_FBC_WM_DIS (1<<15) +/* GEN7 chicken */ +#define GEN7_L3CNTLREG10xB01C +#define GEN7_WA_FOR_GEN7_L3_CONTROL 0x3C4FFF8C + +#define GEN7_L3_CHICKEN_MODE_REGISTER 0xB030 +#define GEN7_WA_L3_CHICKEN_MODE 0x2000 + /* PCH */ /* south display engine interrupt */ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 070c946..2db1b67 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8472,6 +8472,12 @@ static void ivybridge_init_clock_gating(struct drm_device *dev) CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE | CHICKEN3_DGMG_DONE_FIX_DISABLE); + /* WaApplyL3ControlAndL3ChickenMode requires those two on Ivy Bridge */ + I915_WRITE(GEN7_L3CNTLREG1, + GEN7_WA_FOR_GEN7_L3_CONTROL); + I915_WRITE(GEN7_L3_CHICKEN_MODE_REGISTER, + GEN7_WA_L3_CHICKEN_MODE); + for_each_pipe(pipe) { I915_WRITE(DSPCNTR(pipe), I915_READ(DSPCNTR(pipe)) | -- 1.7.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: gen7: work around a system hang on IVB
From: Eugeni Dodonov This adds the workaround for WaCatErrorRejectionIssue which could result in a system hang. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610 Tested-by: Eugeni Dodonov Reviewed-by: Kenneth Graunke Signed-off-by: Eugeni Dodonov --- drivers/gpu/drm/i915/i915_reg.h |4 drivers/gpu/drm/i915/intel_display.c |5 + 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index ca4737e..4e1ee90 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3035,6 +3035,10 @@ #define GEN7_L3_CHICKEN_MODE_REGISTER 0xB030 #define GEN7_WA_L3_CHICKEN_MODE 0x2000 +/* WaCatErrorRejectionIssue */ +#define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG 0x9030 +#define GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB (1<<11) + /* PCH */ /* south display engine interrupt */ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 2db1b67..8b5ee4b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8478,6 +8478,11 @@ static void ivybridge_init_clock_gating(struct drm_device *dev) I915_WRITE(GEN7_L3_CHICKEN_MODE_REGISTER, GEN7_WA_L3_CHICKEN_MODE); + /* This is required by WaCatErrorRejectionIssue */ + I915_WRITE(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG, + I915_READ(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG) | + GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB); + for_each_pipe(pipe) { I915_WRITE(DSPCNTR(pipe), I915_READ(DSPCNTR(pipe)) | -- 1.7.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: gen7: Disable the RHWO optimization as it can cause GPU hangs.
The BSpec Workarounds page states that bits 10 and 26 must be set to avoid 3D ring hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610 Tested-by: Eugeni Dodonov Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h |3 +++ drivers/gpu/drm/i915/intel_display.c |4 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 4e1ee90..03c53fc 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3029,6 +3029,9 @@ #define DISP_FBC_WM_DIS (1<<15) /* GEN7 chicken */ +#define GEN7_COMMON_SLICE_CHICKEN1 0x7010 +# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1<<10) | (1<<26)) + #define GEN7_L3CNTLREG10xB01C #define GEN7_WA_FOR_GEN7_L3_CONTROL 0x3C4FFF8C diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 8b5ee4b..57a606d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8472,6 +8472,10 @@ static void ivybridge_init_clock_gating(struct drm_device *dev) CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE | CHICKEN3_DGMG_DONE_FIX_DISABLE); + /* Apply the WaDisableRHWOOptimizationForRenderHang workaround. */ + I915_WRITE(GEN7_COMMON_SLICE_CHICKEN1, + GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC); + /* WaApplyL3ControlAndL3ChickenMode requires those two on Ivy Bridge */ I915_WRITE(GEN7_L3CNTLREG1, GEN7_WA_FOR_GEN7_L3_CONTROL); -- 1.7.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Remove pointless Android ifdefs for sys/fcntl.h.
On my system, sys/fcntl.h contains exactly one line: #include So there's really no need to #ifdef it. Also, intel_mmio.c already included ; there's no need to include it twice. Signed-off-by: Kenneth Graunke --- lib/intel_drm.c |4 lib/intel_mmio.c |5 - lib/intel_pci.c |4 3 files changed, 0 insertions(+), 13 deletions(-) diff --git a/lib/intel_drm.c b/lib/intel_drm.c index 4a919d3..36a24fa 100644 --- a/lib/intel_drm.c +++ b/lib/intel_drm.c @@ -36,11 +36,7 @@ #include #include #include -#ifdef ANDROID #include -#else -#include -#endif #include #include #ifdef HAVE_STRUCT_SYSINFO_TOTALRAM diff --git a/lib/intel_mmio.c b/lib/intel_mmio.c index a158b04..b266847 100644 --- a/lib/intel_mmio.c +++ b/lib/intel_mmio.c @@ -38,11 +38,6 @@ #include #include #include -#ifdef ANDROID -#include -#else -#include -#endif #include #include diff --git a/lib/intel_pci.c b/lib/intel_pci.c index 08fac3e..7228dae 100644 --- a/lib/intel_pci.c +++ b/lib/intel_pci.c @@ -33,11 +33,7 @@ #include #include #include -#ifdef ANDROID #include -#else -#include -#endif #include #include -- 1.7.7.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] intel: Add support for overriding the PCI ID via an environment variable
For example: export INTEL_DEVID_OVERRIDE=0x162 If this variable is set, don't actually submit the batchbuffer to the GPU, it probably contains commands for the wrong generation of hardware. Signed-off-by: Kenneth Graunke --- intel/intel_bufmgr_gem.c | 43 ++- 1 files changed, 34 insertions(+), 9 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 0f33b71..fcb4764 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -1788,7 +1788,8 @@ drm_intel_gem_bo_mrb_exec2(drm_intel_bo *bo, int used, { drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)bo->bufmgr; struct drm_i915_gem_execbuffer2 execbuf; - int ret, i; + int ret = 0; + int i; switch (flags & 0x7) { default: @@ -1828,6 +1829,9 @@ drm_intel_gem_bo_mrb_exec2(drm_intel_bo *bo, int used, execbuf.rsvd1 = 0; execbuf.rsvd2 = 0; + if (getenv("INTEL_DEVID_OVERRIDE")) + goto skip_execution; + ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf); @@ -1845,6 +1849,7 @@ drm_intel_gem_bo_mrb_exec2(drm_intel_bo *bo, int used, } drm_intel_update_buffer_offsets2(bufmgr_gem); +skip_execution: if (bufmgr_gem->bufmgr.debug) drm_intel_gem_dump_validation_list(bufmgr_gem); @@ -2315,6 +2320,33 @@ drm_intel_bufmgr_gem_set_vma_cache_size(drm_intel_bufmgr *bufmgr, int limit) } /** + * Get the PCI ID for the device. This can be overridden by setting the + * INTEL_DEVID_OVERRIDE environment variable to the desired ID. + */ +static int +get_pci_device_id(drm_intel_bufmgr_gem *bufmgr_gem) +{ + char *devid_override; + int devid; + int ret; + drm_i915_getparam_t gp; + + devid_override = getenv("INTEL_DEVID_OVERRIDE"); + if (devid_override) + return strtod(devid_override, NULL); + + VG_CLEAR(gp); + gp.param = I915_PARAM_CHIPSET_ID; + gp.value = &devid; + ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp); + if (ret) { + fprintf(stderr, "get chip id failed: %d [%d]\n", ret, errno); + fprintf(stderr, "param: %d, val: %d\n", gp.param, *gp.value); + } + return devid; +} + +/** * Initializes the GEM buffer manager, which uses the kernel to allocate, map, * and manage map buffer objections. * @@ -2356,14 +2388,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size) (int)bufmgr_gem->gtt_size / 1024); } - VG_CLEAR(gp); - gp.param = I915_PARAM_CHIPSET_ID; - gp.value = &bufmgr_gem->pci_device; - ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp); - if (ret) { - fprintf(stderr, "get chip id failed: %d [%d]\n", ret, errno); - fprintf(stderr, "param: %d, val: %d\n", gp.param, *gp.value); - } + bufmgr_gem->pci_device = get_pci_device_id(bufmgr_gem); if (IS_GEN2(bufmgr_gem->pci_device)) bufmgr_gem->gen = 2; -- 1.7.7.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] intel: Remove Ironlake from IS_GEN4 macro.
Signed-off-by: Kenneth Graunke --- intel/intel_chipset.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index e3a30fc..1b6e357 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -96,8 +96,6 @@ dev == 0x2E22 || \ dev == 0x2E32 || \ dev == 0x2E42 || \ - dev == 0x0042 || \ - dev == 0x0046 || \ IS_I965GM(dev) || \ IS_G4X(dev)) -- 1.7.7.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] intel: Remove Ironlake from IS_GEN4 macro.
On 02/21/2012 01:08 PM, Chris Wilson wrote: On Tue, 21 Feb 2012 12:59:38 -0800, Kenneth Graunke wrote: Signed-off-by: Kenneth Graunke A task for a rainy afternoon would be to rigorously use the verbose PCI_ID_* names rather than the raw values. Reviewed-by: Chris Wilson --- intel/intel_chipset.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index e3a30fc..1b6e357 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -96,8 +96,6 @@ dev == 0x2E22 || \ dev == 0x2E32 || \ dev == 0x2E42 || \ Note that these 5 IDs are part of IS_G4X, can you kill them as well (in another patch). -Chris Hm. I guess I consider G4X to be part of GEN4. At least in Mesa, G4X is explicitly included: #define IS_GEN4(devid) (devid == ... || ... || IS_G4X(devid)) Using that instead of hardcoding the IDs would be cleaner, though. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] intel: Add support for overriding the PCI ID via an environment variable
On 02/21/2012 01:11 PM, Chris Wilson wrote: On Tue, 21 Feb 2012 12:59:37 -0800, Kenneth Graunke wrote: @@ -1828,6 +1829,9 @@ drm_intel_gem_bo_mrb_exec2(drm_intel_bo *bo, int used, execbuf.rsvd1 = 0; execbuf.rsvd2 = 0; + if (getenv("INTEL_DEVID_OVERRIDE")) + goto skip_execution; I'm not thrilled about calling getenv() for every execbuffer. Good point. I'll have to fix that. And what about the original execbuffer path? -Chris Does anybody care? I'm not even sure how I'd test it. A little bit of background: this is a stepping stone on the way to simulator support. When INTEL_DEVID_OVERRIDE is set, Mesa will generate code/batches for that system, rather than the current machine. It also implicitly sets INTEL_NO_HW=1, which makes it avoid calling execbuf2. This at least allows INTEL_DEBUG=vs,wm,bat style dumps, which is handy. However, our .aub trace file support is in libdrm, so I need Mesa to execbuf, or I don't get aub file dumps. But I don't want libdrm to -actually- exec it. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel: Add support for (possibly) unsynchronized maps.
On 02/25/2012 03:00 AM, Daniel Vetter wrote: On Fri, Feb 24, 2012 at 07:53:22PM -0800, Eric Anholt wrote: This improves the performance of Mesa's GL_MAP_UNSYNCHRONIZED_BIT path in GL_ARB_map_buffer_range. Improves Unigine Tropics performance at 1024x768 by 2.06236% +/- 0.50272% (n=11). --- A few questions: - iirc Ben's non-blocking stuff also worked for non-llc machines - I guess you haven't looked into this because we don't have a non-llc platform that runs ungine? Tropics works on Ironlake, too, it's just slow. Haven't tried earlier. - in my pwrite experience, writing through cpu maps beats writing through the gtt on llc machines. This has the added benefit that it reduces pressure on the mappable gtt. Have you tried that, too? Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] intel: Add .aub file output support.
On 03/07/2012 06:51 PM, Yuanhan Liu wrote: On Wed, Mar 07, 2012 at 11:21:07AM -0800, Eric Anholt wrote: From: Kenneth Graunke This will allow the driver to capture all of its execution state to a file for later debugging. intel_gpu_dump is limited in that it only captures batchbuffers, and Mesa's captures, while more complete, still capture only a portion of the state involved in execution. It also enables us to load traces in our internal simulator. Signed-off-by: Eric Anholt Signed-off-by: Yuanhan Liu Signed-off-by: Kenneth Graunke --- intel/Makefile.am|1 + intel/intel_aub.h| 123 ++ intel/intel_bufmgr.h | 14 ++ intel/intel_bufmgr_gem.c | 315 ++ 4 files changed, 453 insertions(+), 0 deletions(-) create mode 100644 intel/intel_aub.h diff --git a/intel/Makefile.am b/intel/Makefile.am index 06362b6..dc01a96 100644 --- a/intel/Makefile.am +++ b/intel/Makefile.am @@ -53,6 +53,7 @@ intel_bufmgr_gem_o_CFLAGS = $(AM_CFLAGS) -c99 libdrm_intelincludedir = ${includedir}/libdrm libdrm_intelinclude_HEADERS = intel_bufmgr.h \ + intel_aub.h \ intel_debug.h # This may be interesting even outside of "make check", due to the -dump option. diff --git a/intel/intel_aub.h b/intel/intel_aub.h new file mode 100644 index 000..a36fd53 --- /dev/null +++ b/intel/intel_aub.h @@ -0,0 +1,123 @@ +/* + * Copyright © 2010 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + * Authors: + *Eric Anholt + * + */ + +/** @file intel_aub.h + * + * The AUB file is a file format used by Intel's internal simulation + * and other validation tools. It can be used at various levels by a + * driver to input state to the simulated hardware or a replaying + * debugger. + * + * We choose to dump AUB files using the trace block format for ease + * of implementation -- dump out the blocks of memory as plain blobs + * and insert ring commands to execute the batchbuffer blob. + */ + +#ifndef _INTEL_AUB_H +#define _INTEL_AUB_H + +#define AUB_MI_NOOP(0) +#define AUB_MI_BATCH_BUFFER_START (0x31<< 23) +#define AUB_PIPE_CONTROL (0x7a02) + +/* DW0: instruction type. */ + +#define CMD_AUB(7<< 29) + +#define CMD_AUB_HEADER (CMD_AUB | (1<< 23) | (0x05<< 16)) +/* DW1 */ +# define AUB_HEADER_MAJOR_SHIFT24 +# define AUB_HEADER_MINOR_SHIFT16 + +#define CMD_AUB_TRACE_HEADER_BLOCK (CMD_AUB | (1<< 23) | (0x41<< 16)) +#define CMD_AUB_DUMP_BMP (CMD_AUB | (1<< 23) | (0x9e<< 16)) + +/* DW1 */ +#define AUB_TRACE_OPERATION_MASK 0x00ff +#define AUB_TRACE_OP_COMMENT 0x +#define AUB_TRACE_OP_DATA_WRITE0x0001 +#define AUB_TRACE_OP_COMMAND_WRITE 0x0002 +#define AUB_TRACE_OP_MMIO_WRITE0x0003 +// operation = TRACE_DATA_WRITE, Type +#define AUB_TRACE_TYPE_MASK0xff00 +#define AUB_TRACE_TYPE_NOTYPE (0<< 8) +#define AUB_TRACE_TYPE_BATCH (1<< 8) +#define AUB_TRACE_TYPE_VERTEX_BUFFER (5<< 8) +#define AUB_TRACE_TYPE_2D_MAP (6<< 8) +#define AUB_TRACE_TYPE_CUBE_MAP(7<< 8) +#define AUB_TRACE_TYPE_VOLUME_MAP (9<< 8) +#define AUB_TRACE_TYPE_1D_MAP (10<< 8) +#define AUB_TRACE_TYPE_CONSTANT_BUFFER (11<< 8) +#define AUB_TRACE_TYPE_CONSTANT_URB(12<< 8) +#define AUB_TRACE_TYPE_INDEX_BUFFER(13<< 8) +#define AUB_TRACE_TYPE_GENERAL (14<< 8) +#define AUB_TRACE_TYPE_SURFACE (15<< 8) + + +// operation = TRACE_COMMAND_WRITE, Type = +#define AUB_TRACE_TYPE_RING_HWB
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Pull MTRR setup to its own function
On 03/14/2012 08:22 AM, Adam Jackson wrote: No functional change here, just clarifying code flow. Signed-off-by: Adam Jackson Reviewed-by: Kenneth Graunke I'm not qualified to review patch 2, though from the little I know it sounds like a good idea. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel: Add some PCI IDs for Haswell.
Signed-off-by: Kenneth Graunke --- intel/intel_chipset.h | 28 +++- 1 files changed, 23 insertions(+), 5 deletions(-) This suffers from the usual copy & paste issues, since intel_chipset.h exists in Mesa, libdrm, and intel-gpu-tools. We should fix that, but for now, copy and pasting works. diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index e3a30fc..435d01a 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -45,6 +45,12 @@ #define PCI_CHIP_IVYBRIDGE_M_GT2 0x0166 #define PCI_CHIP_IVYBRIDGE_S 0x015a /* server */ +#define PCI_CHIP_HASWELL_GT10x0402 /* Desktop */ +#define PCI_CHIP_HASWELL_GT20x0412 +#define PCI_CHIP_HASWELL_M_GT1 0x0406 /* Mobile */ +#define PCI_CHIP_HASWELL_M_GT2 0x0416 +#define PCI_CHIP_HASWELL_M_ULT_GT2 0x0A16 /* Mobile ULT */ + #define IS_830(dev) (dev == 0x3577) #define IS_845(dev) (dev == 0x2562) #define IS_85X(dev) (dev == 0x3582) @@ -115,11 +121,23 @@ dev == PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS || \ dev == PCI_CHIP_SANDYBRIDGE_S) -#define IS_GEN7(dev) (dev == PCI_CHIP_IVYBRIDGE_GT1 || \ -dev == PCI_CHIP_IVYBRIDGE_GT2 || \ -dev == PCI_CHIP_IVYBRIDGE_M_GT1 || \ -dev == PCI_CHIP_IVYBRIDGE_M_GT2 || \ -dev == PCI_CHIP_IVYBRIDGE_S) +#define IS_GEN7(devid) (IS_IVYBRIDGE(devid) || \ + IS_HASWELL(devid)) + +#define IS_IVYBRIDGE(dev) (dev == PCI_CHIP_IVYBRIDGE_GT1 || \ +dev == PCI_CHIP_IVYBRIDGE_GT2 || \ +dev == PCI_CHIP_IVYBRIDGE_M_GT1 || \ +dev == PCI_CHIP_IVYBRIDGE_M_GT2 || \ +dev == PCI_CHIP_IVYBRIDGE_S) + +#define IS_HSW_GT1(devid) (devid == PCI_CHIP_HASWELL_GT1 || \ + devid == PCI_CHIP_HASWELL_M_GT1) +#define IS_HSW_GT2(devid) (devid == PCI_CHIP_HASWELL_GT2 || \ + devid == PCI_CHIP_HASWELL_M_GT2 || \ + devid == PCI_CHIP_HASWELL_M_ULT_GT2) + +#define IS_HASWELL(devid) (IS_HSW_GT1(devid) || \ + IS_HSW_GT2(devid)) #define IS_G4X(dev) (dev == 0x2E02 || \ dev == 0x2E12 || \ -- 1.7.7.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] OpenGL Extension support on IVY Bridge
On 03/28/2012 07:41 PM, Cheah, Douglas wrote: Hello folks, Hi Douglas, I like to know if there is an active list available of supported list OpenGL and OpenGLES for IVY Bridge? I am looking for a comprehensive list that include information on hardware support instead of list of supported extension just like GL_EXTENSION. Not that I'm aware of. We currently expose the same set of extensions on Ivy Bridge as we do on Sandy Bridge. If you have any specific inquiries, I'd be happy to answer them as best as I can. Also, if there are any extensions you'd like us to support, let us know. For example GL_ARB_robustness is supported but it seem like the GetGraphicResetStatus() isn’t supported, is this tied down to hardware? We're planning on implementing that soon; Ian, Eric, and Ben have been working out the details. I am also interested details on extension support that can be configure such as support for s3tc texture compression which looks to be a DRI config option. Douglas For now, the two configurable extensions are: - S3TC texture compression support To enable this, you need to install the libtxc_dxtn library. Mesa will then automatically detect the library and use it. No driconf options are necessary. - Floating point texture support To enable this, you need to build Mesa with: ./configure --enable-texture-float Enabling this also makes the driver expose OpenGL 3.0 rather than 2.1. Both of these are, unfortunately, encumbered by patents. (Otherwise, we'd just enable them all the time.) We still need to consult legal about this. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: add power monitoring support
Jesse, This patch seems to have a lot of magical numbers in it. In particular, v_table and cparams both seem rather cryptic. Would it be possible to add a few comments saying what these numbers mean or where they came from? Thanks, --Kenneth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Working out if my driver is borked ?
Those numbers are fine. See http://isglxgearsabenchmark.com/ or, more usefully but less comically, http://qa-rockstar.livejournal.com/7869.html --Kenneth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] OpenGL ES2.0 support in Sandy Bridge
On Tuesday, January 25, 2011 02:50:26 am Rozly-azni, Noor Amin Shahriz wrote: > Hi. > > I'm been using a benchmark software, 3DMarkMobileES2.0 for Intel Atom E6XX > platforms, which is based on Intel EGMD drivers. > > I tried porting the software in Sandy Bridge with the latest driver > (Q42010), however it failed and I got an error message. It seems as if > OpenGLES2.0 library is not there? Or is the library name not libGLESv2.so > ? Even when I try to recompile the software, I got "ld: cannot find > -lGLESv2" error. [snip] Have you built Mesa with the --enable-gles2 configure option? That enables the building of libGLESv2. Also, there was a bug in our parser that prevented 3DMarkMobileES2.0 from running until about a week ago - you will likely need to run Mesa master, rather than 7.10 from the Q4 release. (The rest of the components from the Q4 release should be fine.) --Kenneth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel: Add AUB file dump support
On Tuesday, February 22, 2011 05:49:57 PM Zhenyu Wang wrote: [snip] > > We also can't commit code to Mesa that just writes into some arbitrary > > file based on an environment variable -- keep in mind that our Mesa > > driver is loaded from the X Server which is running as root. > > yeah, I wasn't aware of this, any comment for how to dump the file? We could simply not commit this patch to master, but keep it in a branch and apply it when we need AUB file dumping support. Alternatively, perhaps we could commit everything, but change patch 1/3 to: #if 0 { "aub", DEBUG_AUB }, #endif This makes it ridiculously easy for us to enable INTEL_DEBUG=aub, but doesn't ship the potential security exploit. Also, since a .c file would have to be changed, it's unlikely a distributor would accidentally enable it. Thoughts? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] EMGD driver for X 1.7.7 and kernel 2.6.33 (TinyCore Linux)
Hi Daniel, This list is for the Intel open source drivers; we can't help you with Poulsbo or EMGD. There's probably another place to ask about that, but I'm not sure where. Ideally there would be an open source driver for the PVR 535/SGX graphics that just works, but at this point, there isn't. --Kenneth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HDMI on D525 detected as LVDS (Was: Re: YCbCr colourspace output)
On 03/28/2011 04:51 AM, Steven Newbury wrote: - Original message - I'm connecting a D525 (Pineview) based system to an older "HD" (1366x768) Phillips TV. I has a DVI connector for HD input, but whether I connect it using the VGA->DVI or HDMI->DVI the TV detects the incomming signal as from a PC and selects a "XGA" mode, limiting the screen format to aspects and resolutions it expects a PC to use; like 640x480, 800x600, 1024x768 4:3/16:10 @60Hz (always with black borders), even though the TV officially supports HDTV 720p,1080i 50/60Hz etc.. I suspect the issue lies in the assumption that HDTV equipment would have a YCbCr colourspace. Now my question is, since I can't really modify the TV firmware, is it possible to add YCbCr output to the driver, assuming the chip supports it? Okay, it's even weirder than I thought! Further testing has shown that with an analogue RGB input the frame always has a left/right borders (making it 16:10 when in "wide screen") and are restricted to 640x480, 800x600 and 1024x768, whilst the DVI-D input seems to be more resonable, except the BIOS on my board insists on configuring the HDMI port as an LVDS with BIOS configured mode timings. This wouldn't be too bad except the fixed mode in the BIOS for the native panel size (1366x768) gives a mode shifted significantly to the left (off the screen) and while the 1280x720 fits fine, the TV does a really awful job of scaling! I'm thinking this board must have an LVDS->HDMI converter so it wouldn't be suprising the driver treats it this way, even so it would be really handy to have an override to allow mode setting to adjust the apparent panel mode and so present such hardware in a useful fasion to userspace. Yes. I'm 99% positive that all "HDMI" on Pineview is actually done through LVDS->HDMI converters. Pineview doesn't natively support HDMI. Am I missing something, or does KMS only accept the BIOS provided panel timings? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i965: Fix the VS thread limits for GT1, and clarify the WM limits on both.
On 03/29/2011 03:17 PM, Eric Anholt wrote: --- I don't have GT1 to test with. Does this fix VS regressions for people with that hardware? Me neither, but it sure looks correct. [snip] diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index 9483ec6..a74ba5c 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -183,8 +183,17 @@ GLboolean brwCreateContext( int api, /* WM maximum threads is number of EUs times number of threads per EU. */ if (intel->gen>= 6) { brw->urb.size = 1024; - brw->vs_max_threads = 60; - brw->wm_max_threads = 80; + if (IS_GT2(intel->intelScreen->deviceID)) { +/* This could possibly be 80, but is supposed to require + * disabling of WIZ hashing (bit 6 of GT_MODE, 0x20d0) and a + * GPU reset to change. + */ +brw->wm_max_threads = 40; +brw->vs_max_threads = 60; + } else { +brw->wm_max_threads = 40; +brw->vs_max_threads = 24; + } Presumably 60 = 12 EUs * 5 threads/EU (for GT2), while 24 = 6 EUs * 4 threads/EU (for GT1). If so, a comment to that effect would be nice... I still have no idea where 40/80 come from. [snip] diff --git a/src/mesa/drivers/dri/intel/intel_chipset.h b/src/mesa/drivers/dri/intel/intel_chipset.h index 4ff9140..f7dcf47 100644 --- a/src/mesa/drivers/dri/intel/intel_chipset.h +++ b/src/mesa/drivers/dri/intel/intel_chipset.h Drop the intel_chipset.h changes, I just committed an equivalent patch. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [intel-gpu-tools] [PATCH 1/3] intel-gpu-tools add ioctl interface usage
On 04/05/2011 12:33 PM, Ben Widawsky wrote: Added the mechnanism to communicate with the i915 IOCTL interface, and removed the existing forcewake code, as it is not reliable. Modified gpu_top to take a flag -i, to use the IOCTL interface. Previous gpu_top behavior with no args is maintained from previous version. Signed-off-by: Ben Widawsky --- lib/intel_gpu_tools.h | 58 +++- lib/intel_mmio.c | 18 +++ tools/intel_gpu_top.c | 45 +++-- 3 files changed, 88 insertions(+), 33 deletions(-) One high level comment and a nitpick... I'm a bit surprised that there's a command line option to use the IOCTL interface (i.e. non-broken mode). Shouldn't it try the IOCTL and, if the kernel doesn't support it, fall back to using MMIO? Or, perhaps better...try using the IOCTL by default on gen6, and if it fails, print a message like "Your kernel doesn't support the necessary IOCTLs; please upgrade or run intel_gpu_top -m to force MMIO mode (which may be inaccurate)." and quit. +#define INREG(reg) \ + (use_ioctl_mmio ? INREG_IOCTL(reg) : INREG_PCI(reg)) + +#define OUTREG(reg, val) \ + (use_ioctl_mmio ? OUTREG_IOCTL(reg, val) : OUTREG_PCI(reg, val)) + static inline uint32_t -INREG(uint32_t reg) +INREG_PCI(uint32_t reg) { return *(volatile uint32_t *)((volatile char *)mmio + reg); } As long as you're renaming these, can we please use lowercase for inline functions, while keeping the INREG/OUTREG macros uppercase? +/* + * Try to read a register using the i915 IOCTL interface. The operations should + * not fall back to the normal pci mmio method to avoid confusion. IOCTL usage + * should be explicitly specified. + */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Trying to understand the URB code
Hi Nanhai, I'm trying to understand how the Gen6 URB setup works, and I had some questions... if (IS_GT1(intel->intelScreen->deviceID)) { urb_size = 32 * 1024; max_urb_entry = 128; } else { urb_size = 64 * 1024; max_urb_entry = 256; } I see in vol5c.5 that GT1 has 32kB of URB space and GT2 has 64kB, so urb_size must be the total size of the URB. But what is max_urb_entry? Where do 128 and 256 come from? brw->urb.vs_size = MAX2(brw->vs.prog_data->urb_entry_size, 1); It looks like brw->vs.prog_data->urb_entry_size is the size of a single VUE, which depends on the number of input/outputs in the particular vertex shader being used. So, brw->urb.vs_size is also the size of a VUE, but at least 1. What are the units here? The number of 1024-bit blocks? (I'm looking at 3DSTATE_URB in vol2a of the bspec...) brw->urb.nr_vs_entries = max_urb_entry; brw->urb.nr_gs_entries = max_urb_entry; if (2 * brw->urb.vs_size * brw->urb.nr_vs_entries > urb_size) brw->urb.nr_vs_entries = brw->urb.nr_gs_entries = (urb_size ) / (2 * brw->urb.vs_size); Here it looks like you're trying to allocate half of the URB to the VS, and half to the GS. I'm confused by the units, though: if vs_size is in 1024-bit (128-byte) blocks and urb_size is in bytes, don't we need to multiply vs_size by 128? I think the above code could be simplified to: int urb_entries = urb_size / (2 * brw->urb.vs_size * 128); brw->urb.nr_vs_entries = brw->urb.nr_gs_entries = MIN2(urb_entries, max_urb_entry); What do you think? Thanks for the help. --Kenneth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] Add support for Ivybridge chipset.
> This gets display and 2D blit acceleration up and running. No Render > acceleration is provided yet. [snip] > diff --git a/src/intel_driver.h b/src/intel_driver.h > index 2e72177..180281e 100644 > --- a/src/intel_driver.h > +++ b/src/intel_driver.h > @@ -184,6 +184,13 @@ > #define PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS 0x0126 > #define PCI_CHIP_SANDYBRIDGE_BRIDGE_S0x0108 /* Server */ > #define PCI_CHIP_SANDYBRIDGE_S_GT0x010A > + > +#define PCI_CHIP_IVYBRIDGE_M_GT1 0x0156 > +#define PCI_CHIP_IVYBRIDGE_M_GT2 0x0166 > +#define PCI_CHIP_IVYBRIDGE_D_GT1 0x0152 > +#define PCI_CHIP_IVYBRIDGE_D_GT1_SERVER 0x015a > +#define PCI_CHIP_IVYBRIDGE_D_GT2 0x0162 > + I think I'd prefer PCI_CHIP_IVYBRIDGE_S_GT1 - I think that's more consistent - but up to you. It's rather annoying that we have these PCI ID defines in the kernel, 2D driver, and twice in Mesa. Ditto for the IS_IVYBRIDGE/IS_GEN7/etc. macros. But I'm not sure what to do about it, really. > #endif > > #define I85X_CAPID 0x44 > @@ -209,6 +216,7 @@ > #define IS_GEN4(intel) IS_GENx(intel, 4) > #define IS_GEN5(intel) IS_GENx(intel, 5) > #define IS_GEN6(intel) IS_GENx(intel, 6) > +#define IS_GEN7(intel) IS_GENx(intel, 7) > > /* Some chips have specific errata (or limits) that we need to > workaround. */ > #define IS_I830(intel) (DEVICE_ID((intel)->PciInfo) == PCI_CHIP_I830_M) > @@ -222,6 +230,7 @@ > > /* supports Y tiled surfaces (pre-965 Mesa isn't ready yet) */ > #define SUPPORTS_YTILING(pI810) (INTEL_INFO(intel)->gen >= 40) > +#define HAS_BLT(pI810) (INTEL_INFO(intel)->gen >= 60) > > extern SymTabRec *intel_chipsets; > > diff --git a/src/intel_module.c b/src/intel_module.c > index 6cf5951..13f1635 100644 > --- a/src/intel_module.c > +++ b/src/intel_module.c > @@ -73,6 +73,10 @@ static const struct intel_device_info > intel_sandybridge_info = { > .gen = 60, > }; > > +static const struct intel_device_info intel_ivybridge_info = { > + .gen = 70, > +}; > + > static const SymTabRec _intel_chipsets[] = { > {PCI_CHIP_I810, "i810"}, > {PCI_CHIP_I810_DC100,"i810-dc100"}, > @@ -116,6 +120,11 @@ static const SymTabRec _intel_chipsets[] = { > {PCI_CHIP_SANDYBRIDGE_M_GT2, "Sandybridge" }, > {PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS,"Sandybridge" }, > {PCI_CHIP_SANDYBRIDGE_S_GT, "Sandybridge" }, > +{PCI_CHIP_IVYBRIDGE_M_GT1, "Ivybridge Mobile GT1" }, > +{PCI_CHIP_IVYBRIDGE_M_GT2, "Ivybridge Mobile GT2" }, > +{PCI_CHIP_IVYBRIDGE_D_GT1, "Ivybridge Desktop GT1" }, > +{PCI_CHIP_IVYBRIDGE_D_GT1_SERVER,"Ivybridge Desktop Server GT1" > }, > +{PCI_CHIP_IVYBRIDGE_D_GT2, "Ivybridge Desktop GT2" }, > {-1, NULL} > }; > SymTabRec *intel_chipsets = (SymTabRec *) _intel_chipsets; > @@ -173,6 +182,13 @@ static const struct pci_id_match intel_device_match[] > = { > INTEL_DEVICE_MATCH (PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS, > &intel_sandybridge_info ), > INTEL_DEVICE_MATCH (PCI_CHIP_SANDYBRIDGE_S_GT, > &intel_sandybridge_info ), > > + > +INTEL_DEVICE_MATCH (PCI_CHIP_IVYBRIDGE_M_GT1, &intel_ivybridge_info > ), > +INTEL_DEVICE_MATCH (PCI_CHIP_IVYBRIDGE_M_GT2, &intel_ivybridge_info > ), > +INTEL_DEVICE_MATCH (PCI_CHIP_IVYBRIDGE_D_GT1, &intel_ivybridge_info > ), > +INTEL_DEVICE_MATCH (PCI_CHIP_IVYBRIDGE_D_GT1_SERVER, > &intel_ivybridge_info ), > +INTEL_DEVICE_MATCH (PCI_CHIP_IVYBRIDGE_D_GT2, &intel_ivybridge_info > ), > + > { 0, 0, 0 }, > }; > > -- > 1.7.4.4 > > ___ > 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 3/4] Remove the static list of PciChipset and construct it from SymTabRec instead.
On 05/06/2011 05:08 PM, Eric Anholt wrote: This is one less place the new hardware enabler has to spam the chipset in. The PciChipset is just a match structure from PciId to the SymTabRec entry token, and our SymTabRec entry tokens are just the PciId, so it's trivial to construct. --- src/intel_module.c | 53 +++ 1 files changed, 8 insertions(+), 45 deletions(-) Acked-by: Kenneth Graunke I'm always glad to see lists of PCI IDs die. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Remove the memory of Option "AccelMethod"
On 05/10/2011 12:27 PM, Adam Jackson wrote: Signed-off-by: Adam Jackson Reviewed-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Enable GPU reset on Ivybridge.
According to the hardware documentation, GDRST is exactly the same as on Sandybridge. So simply enable the existing code. Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_drv.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) GPU reset does not seem terribly reliable, but did work at least once: My GPU hung halfway through an OpenArena run, successfully reset (the screen went blank for a moment), and continued rendering, finishing the time demo. I was also able to run glxgears after the reset. diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index f72f9ff..71a06d0 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -547,6 +547,7 @@ int i915_reset(struct drm_device *dev, u8 flags) if (get_seconds() - dev_priv->last_gpu_reset < 5) { DRM_ERROR("GPU hanging too fast, declaring wedged!\n"); } else switch (INTEL_INFO(dev)->gen) { + case 7: case 6: ret = gen6_do_reset(dev, flags); break; -- 1.7.4.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] error while loading shared libraries: libGLESv2.so
On 05/30/2011 02:16 AM, sudhanshu gupta wrote: Hi guyz I an new to OpenGL-ES 2.0 I am trying to run it in ubuntu 10.10 with emulator but whenever I try to run it gives me an error message. ./cube: error while loading shared libraries: libGLESv2.so: cannot open shared object file: No such file or directory I dont know why its happening. You need to install the libgles2-mesa package to get libGLESv2. Presumably the application also uses EGL, in which case you'll also need libegl1-mesa and libegl1-mesa-drivers. If you're going to compile ES2/EGL apps, you'll also need libgles2-mesa-dev and libegl1-mesa-dev. If you want to be able to debug inside Mesa or the drivers, you'll need libgles2-mesa-dbg, libegl1-mesa-dbg, and libegl-mesa-drivers-dbg. Actually I have to export the path to library. i have exported but I don't if we have to configure or not because after exporting if I write ./configure it says no such file or directory. thank you Sudhanshu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] Add attachment token DRI2BufferHiz
On 06/04/2011 05:06 PM, Chad Versace wrote: ... and bump version to 2.6. Signed-off-by: Chad Versace --- configure.ac |2 +- dri2proto.txt |6 +- dri2tokens.h |1 + 3 files changed, 7 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 297be0e..d671f5a 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.60]) -AC_INIT([DRI2Proto], [2.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([DRI2Proto], [2.6], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE diff --git a/dri2proto.txt b/dri2proto.txt index dc46e58..df763c7 100644 --- a/dri2proto.txt +++ b/dri2proto.txt @@ -178,7 +178,8 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft DRI2BufferAccum DRI2BufferFakeFrontLeft DRI2BufferFakeFrontRight -DRI2BufferDepthStencil } +DRI2BufferDepthStencil +DRI2BufferHiz } These values describe various attachment points for DRI2 buffers. @@ -509,6 +510,8 @@ The DRI2 extension has undergone a number of revisions before 2.3: Added the DRI2InvalidateBuffers event. + 2.6: Enlightenment attained. Added the DRI2BufferHiz attachment. + I hate to be a killjoy, but I'd leave out the first sentence lest someone think this is to support Enlightenment/EFL (enlightenment.org). Reviewed-by: Kenneth Graunke Compatibility up to 2.0 is not preserved, but was also never released. @@ -569,6 +572,7 @@ A.1 Common Types 0x7 DRI2BufferFakeFrontLeft 0x8 DRI2BufferFakeFrontRight 0x9 DRI2BufferDepthStencil + 0xa DRI2BufferHiz └─── Used to encode the possible attachment points. The attachment DRI2BufferDepthStencil is only available with protocol version 1.1 or diff --git a/dri2tokens.h b/dri2tokens.h index 7804e4d..16c9008 100644 --- a/dri2tokens.h +++ b/dri2tokens.h @@ -43,6 +43,7 @@ #define DRI2BufferFakeFrontLeft 7 #define DRI2BufferFakeFrontRight 8 #define DRI2BufferDepthStencil9 +#define DRI2BufferHiz 10 #define DRI2DriverDRI 0 #define DRI2DriverVDPAU 1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] dri: Add support for DRI2BufferStencil and DRI2BufferHiz
On 06/04/2011 05:06 PM, Chad Versace wrote: Before this commit, if a client were to request a stencil or hiz buffer, then I830DRI2CreateBuffer() allocated and returned an X-tiled buffer by accident. (DRI2BufferStencil and DRI2BufferHiz were unintentionally caught by the default case of a switch statement.) Now, I830DRI2CreateBuffer() correctly returns a Y-tiled buffer and handles the stencil buffer as a special case due its quirky pitch requirements. This shouldn't break older Mesa versions, because they never query (via DRI2GetBuffersWithFormat) for the drawable's DRI2BufferStencil. Signed-off-by: Chad Versace --- src/intel_dri.c | 30 ++ 1 files changed, 26 insertions(+), 4 deletions(-) This looks good to me, though I'm not too familiar with the DDX code. Reviewed-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] Add attachment token DRI2BufferHiz
On 06/05/2011 07:32 PM, Chad Versace wrote: On Sun, 05 Jun 2011 01:53:29 -0700, Kenneth Graunke wrote: I hate to be a killjoy, but I'd leave out the first sentence lest someone think this is to support Enlightenment/EFL (enlightenment.org). Reviewed-by: Kenneth Graunke It's not evident from the hunk, but I was just following the silly precedent in previous version bumps. 2.0: Awesomeness! 2.1: True excellence. Added DRI2GetBuffersWithFormat to allow more flexible object creation. 2.2: Approaching perfection. Added requests for swapbuffers, MSC and SBC related requests, and events. Oh :) I should have checked first...by all means, go ahead then! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Fix MI_DISPLAY_FLIP plane select offset on Ivybridge.
According to BSpec volume 1c.4 section 3.2.9, Display (Plane) Select is now at bits 21:19 instead of 21:20. Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/intel_display.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 81a9059..60b2941 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6390,7 +6390,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, break; case 6: - case 7: OUT_RING(MI_DISPLAY_FLIP | MI_DISPLAY_FLIP_PLANE(intel_crtc->plane)); OUT_RING(fb->pitch | obj->tiling_mode); @@ -6400,6 +6399,16 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, pipesrc = I915_READ(PIPESRC(pipe)) & 0x0fff0fff; OUT_RING(pf | pipesrc); break; + + case 7: + OUT_RING(MI_DISPLAY_FLIP | (intel_crtc->plane << 19)); + OUT_RING(fb->pitch | obj->tiling_mode); + OUT_RING(obj->gtt_offset); + + pf = I915_READ(PF_CTL(pipe)) & PF_ENABLE; + pipesrc = I915_READ(PIPESRC(pipe)) & 0x0fff0fff; + OUT_RING(pf | pipesrc); + break; } ADVANCE_LP_RING(); -- 1.7.4.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Remove HAS_BLT/HAS_BSD checks from ivybridge_irq_postinstall.
Ivybridge has BLT and BSD rings, so there's no need to check. Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_irq.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index b9fafe3..6a2b7f4 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1841,10 +1841,8 @@ int ivybridge_irq_postinstall(struct drm_device *dev) u32 hotplug_mask; DRM_INIT_WAITQUEUE(&dev_priv->ring[RCS].irq_queue); - if (HAS_BSD(dev)) - DRM_INIT_WAITQUEUE(&dev_priv->ring[VCS].irq_queue); - if (HAS_BLT(dev)) - DRM_INIT_WAITQUEUE(&dev_priv->ring[BCS].irq_queue); + DRM_INIT_WAITQUEUE(&dev_priv->ring[VCS].irq_queue); + DRM_INIT_WAITQUEUE(&dev_priv->ring[BCS].irq_queue); dev_priv->vblank_pipe = DRM_I915_VBLANK_PIPE_A | DRM_I915_VBLANK_PIPE_B; dev_priv->irq_mask = ~display_mask; -- 1.7.4.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx