On Thu, 23 Jun 2011 19:02:32 -0700, Ben Widawsky wrote:
> On Thu, Jun 23, 2011 at 07:00:50PM -0700, Ben Widawsky wrote:
> > On Fri, Jun 24, 2011 at 12:45:27AM +0100, Chris Wilson wrote:
> > > On Thu, 23 Jun 2011 16:06:22 -0700, Ben Widawsky
> > > wrote:
> > > >
> > > > Signed-off-by: Ben Widaws
On Wed, 11 May 2011 10:48:01 -0700, Jesse Barnes
wrote:
> A couple of bug fixes, and some patches to support deep color on Intel
> chipsets.
My main concern with extended fb->depth support is in validation that the
crtc+encoder supports the requested fb, and that we have sufficient
logging of th
On Wed, 11 May 2011 10:48:07 -0700, Jesse Barnes
wrote:
> +static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc,
> + unsigned int *pipe_bpp)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private
On Fri, 24 Jun 2011 10:32:16 +0100, Chris Wilson
wrote:
> So here goes -depth 30...
So other than a couple of rendering paths where we write 8bpc data into
the depth-30 fb (go flash, go!), X looks good. Textured XVideo should just
work, GLX doesn't advertise a 10-bpc visual or fbconfig, so will
On Fri, 24 Jun 2011 11:24:08 +0100, Chris Wilson
wrote:
> On Fri, 24 Jun 2011 10:32:16 +0100, Chris Wilson
> wrote:
> > So here goes -depth 30...
>
> So other than a couple of rendering paths where we write 8bpc data into
> the depth-30 fb (go flash, go!), X looks good.
Looking at the xtrace
On Fri, Jun 24, 2011 at 08:54:24AM +0100, Chris Wilson wrote:
> On Thu, 23 Jun 2011 19:02:32 -0700, Ben Widawsky wrote:
> > On Thu, Jun 23, 2011 at 07:00:50PM -0700, Ben Widawsky wrote:
> > > On Fri, Jun 24, 2011 at 12:45:27AM +0100, Chris Wilson wrote:
> > > > On Thu, 23 Jun 2011 16:06:22 -0700,
On Fri, Jun 24, 2011 at 12:48:22AM +0100, Chris Wilson wrote:
> On Thu, 23 Jun 2011 15:49:14 -0700, Ben Widawsky wrote:
> > Provide a user accessible way to change the hangcheck timer. This is
> > useful mostly for disabling the timer completely (value <= 0).
>
> Having i915.hangcheck_interval as
This allows drivers and other code to get the max reported CPU frequency.
Initial use is for scaling ring frequency with GPU frequency in the i915
driver.
Signed-off-by: Jesse Barnes
---
drivers/cpufreq/cpufreq.c | 20
include/linux/cpufreq.h |5 +
2 files change
The ring frequency scaling table tells the PCU to treat certain GPU
frequencies as if they were a given CPU frequency for purposes of
scaling the ring frequency. Normally the PCU will scale the ring
frequency based on the CPU P-state, but with the table present, it will
also take the GPU frequency
On Fri, Jun 24, 2011 at 12:44 PM, Andi Kleen wrote:
> Andrew Lutomirski writes:
>
> [Putting the Intel graphics driver developers in cc.]
My Sandy Bridge laptop is to blame, the graphics aren't the culprit. It's this:
BIOS-e820: 0001 - 00010060 (usable)
The kernel can't
This update includes the fixes requested by Chris. The DP link
bandwidth calculation change seems ok here at least for basic mode sets
at different depths, but wider testing is definitely needed.
Thanks,
Jesse
___
Intel-gfx mailing list
Intel-gfx@lists
These bits are reserved on ILK+ (ILK+ provides this feature in the
transcoder and pipe configuration instead, which we already set).
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_hdmi.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
This prevents us from setting reserved or incorrect bits on CougarPoint.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_
This may not be the default value, so pull the bpc out of the pipe reg
and write it to the DP transcoder so proper dithering and signaling
occurs.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drive
The pipe may be driving various bpp values depending on the display
configuration, so take that into account when calculating link bandwidth
requirements.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/
Figuring out which pipe bpp to use is a bit painful. It depends on both
the encoder and display configuration attached to a pipe. For instance,
to drive a 24bpp framebuffer out to an 18bpp panel, we need to use 6bpc
on the pipe but also enable dithering. But driving that same
framebuffer to a Di
The Intel HDMI encoder can support 8bpc or 12bpc. Set the appropriate
value based on the pipe bpp when configuring the output.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_hdmi.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/inte
Updating the planes is device specific, so create a new display callback
and use it in pipe_set_base. (In fact we could go even further, valid
display plane bits have changed with each generation, as has tiled
buffer handling.)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h
To properly drive a framebuffer with a new depth or bpp, dither settings
and link bandwidth calculations may change, so make sure we go through a
full mode set in that case.
Reported-by: Chris Wilson
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc_helper.c |5 +
1 files changed
This will catch bad fb configs earlier.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index db88f15..f5c2012 100644
---
Now that we track bpp on a per-pipe basis, we can use the actual value
rather than assuming 24bpp.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm
These patches enable support for the GEN6+ based hardware to do shader
debugging.
Currently only fragment shader trace-like debugging is supported. This
means that you can get an architectural snapshot at each EU instruction,
and that's about it. Further improvements will be made over time, but
al
Signed-off-by: Ben Widawsky
---
intel/Makefile.am |3 ++-
intel/intel_debug.h | 44
2 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/intel/Makefile.am b/intel/Makefile.am
index b6a9014..7a44aaf 100644
--- a/intel/Makefile.am
+++
The system routine requires m0 be reserved. for saving off architectural
state. Moved the allocation to start at 2 instead of 0.
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa
The debugger shared memory needs to be a fixed size. Since this is
scratch memory that is already used by register spilling, add
appropriate hooks to do the right thing when debugging.
Also copy in a binary blob system routine based on an environment
variable. This blob will need to be relocated,
Since the debug system routine will share scratch space with threads
doing register spilling, we must offset the registers to accomodate.
This is more easily accomplished (and less bug prone) in Mesa, so there
you go...
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/i965/brw_fs_emit.cpp |
Upload the system routine as part of the invariant state if debugging.
Remove SIP setting if not debugging to make it more friendly for others
that may be debugging shaders or media kernels.
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 24 +++---
Provide a function to allow emitting breakpoints in the instruction
oword. Use breakpoints when debugging.
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/i965/brw_eu.c |6 ++
src/mesa/drivers/dri/i965/brw_eu.h |1 +
src/mesa/drivers/dri/i965/brw_wm.c |3 +++
3 files changed
Use unix domain sockets to connect to a debugger and send the
information the debugger will use to properly handle debug events.
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/i965/brw_wm_debug.c | 66 -
1 files changed, 63 insertions(+), 3 deletions(-)
diff
We can deprecate the old code by using the non-safe flag in the new API.
The safe flag should allow the previous behavior to continue.
The code also adds some range checking on register access. This code is
gives hooks to prevent tools from doing bad things.
Signed-off-by: Ben Widawsky
---
lib/
This app is required for debug features which seem to (undocumented)
reset themselves if/when the GT goes to sleep.
Signed-off-by: Ben Widawsky
---
tools/Makefile.am |1 +
tools/forcewaked.c | 45 +
2 files changed, 46 insertions(+), 0 deletions
Signed-off-by: Ben Widawsky
---
lib/intel_reg.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 48d8f66..ef9cb63 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -3488,5 +3488,10 @@ typedef enum {
#define TRANS_DP_HSYNC_A
The failure is as follows:
1. Userspace gets forcewake lock, lock count >=1
2. GPU hang/reset occurs (forcewake bit is reset)
3. count is now incorrect
The failure can only occur when using the forcewake userspace lock.
This has the unfortunate consequence of messing up the driver as well as
use
On Fri, 24 Jun 2011 12:42:47 -0700, Ben Widawsky wrote:
> The system routine requires m0 be reserved. for saving off architectural
> state. Moved the allocation to start at 2 instead of 0.
>
> Signed-off-by: Ben Widawsky
Reviewed-by: Eric Anholt
pgpNlUc0NKhIO.pgp
Description: PGP signature
_
On Fri, 24 Jun 2011 12:42:48 -0700, Ben Widawsky wrote:
> The debugger shared memory needs to be a fixed size. Since this is
> scratch memory that is already used by register spilling, add
> appropriate hooks to do the right thing when debugging.
>
> Also copy in a binary blob system routine base
On Fri, 24 Jun 2011 12:42:50 -0700, Ben Widawsky wrote:
> Upload the system routine as part of the invariant state if debugging.
>
> Remove SIP setting if not debugging to make it more friendly for others
> that may be debugging shaders or media kernels.
Instructions are from an offset of the br
36 matches
Mail list logo
