Re: [Intel-gfx] [PATCH] drm/i915: Fixed VS thread distribution between slices

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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+.

[Kenneth Graunke]

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+.

[Kenneth Graunke]

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+.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

"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+.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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!

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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?

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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 ?

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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)

[Kenneth Graunke]

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)

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

> 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.

[Kenneth Graunke]

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"

[Kenneth Graunke]

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.

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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

[Kenneth Graunke]

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.

[Kenneth Graunke]

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.

[Kenneth Graunke]

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