Hi all,
I think I have stumbled across a bug with the Intel i915 DRM Module.
I am running the 2.6.37.5 kernel with the intel module for xorg on 2.14.0.
The unit is a single board computer that is connected to a TV via the Component
Video Output, this board has a combination Component Video/Comp
I had some simple test on that machine.
It fails at VS threads set to 3, but pass at VS thread number 1 and 2.
So I believe it's some hidden bug.
One limitation for multi VS thread is
Not to use the scratch space, that will introduce race condition.
But I don't think our VS kernel used scratch spa
Hi,
Chris Wilson (29/03/2011):
> git tag: 2.14.902
as mentioned on IRC, lies! :)
(Dropping a mail anyway to make sure the tag gets pushed.)
KiBi.
signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.or
Hi again,
Cyril Brulebois (10/02/2011):
> The commit message says:
> | Update autotools configuration
> |
> | Use new libtool syntax and silent-rules to silent
> | the build output a bit (linux-like)
>
> What it doesn't say is:
> -AC_CONFIG_AUX_DIR(.)
> +AC_CONFIG_AUX_DIR([build-aux])
sorry to
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 9483e
hi i have a problem with the driver i defined a new modeline in the
xorg.conf the driver seems to ignor the Hsync start hsync end and htotal but
accepts the resolution
mfg fabian
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http:/
Improves full-screen openarena on my laptop 20.3% +/- 4.0% (n=3)
Improves 800x600 nexuiz on my laptop 12.3% +/- 0.1% (n=3)
We have more room to improve with doing LLC caching for display using
GFDT, and in doing LLC+MLC caching, but this was an easy performance
win and incremental improvement towa
The simplest and common method for ensuring scanout coherency on all
chipsets is to mark the scanout buffers as uncached (and for
userspace to remember to flush the render cache every so often).
We can improve upon this for later generations by marking scanout
objects as GFDT and only flush those
From: Chris Wilson
[v2: Don't forget that when going from cached to uncached, we haven't
been tracking the write domain from the CPU perspective, since we
haven't needed it for GPU coherency.]
Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/i915/i915_drv.h |
Chris posted a big patch series incorporating the cleaned up LLC
caching changes, but there were a bunch of not-ready-yet patches in
there. This is a reduced series that I think is ready, with some
fixes from me. From the final commit:
Improves full-screen openarena on my laptop 20.3% +/- 4.
From: Chris Wilson
... to clarify just how we use it inside the driver. We still need to
translate through agp_type for interface into the fake AGP driver.
Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
drivers/gpu/drm/i9
From: Chris Wilson
Rely on the GPU snooping into the CPU cache for appropriately bound
objects on MI_FLUSH. Or perhaps one day we will have a cache-coherent
CPU/GPU package...
Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/i915/i915_gem.c |8
1 files c
From: Chris Wilson
Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/i915/intel_display.c |2 +-
drivers/gpu/drm/i915/intel_overlay.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i
---
I don't have GT1 to test with. Does this fix VS regressions for
people with that hardware?
src/mesa/drivers/dri/i965/brw_context.c| 13 +++--
src/mesa/drivers/dri/i965/gen6_vs_state.c |2 +-
src/mesa/drivers/dri/i965/gen6_wm_state.c |2 +-
src/mesa/drivers/dri/intel/
On Tue, 29 Mar 2011 10:07:45 -0700, Eric Anholt wrote:
> On Tue, 29 Mar 2011 14:43:46 +0100, Chris Wilson
> wrote:
> > Proof-of-concept sanity check to see if we did successfully enable the
> > pipe. Without a means of report back the error and forcibly reverting back
> > to the previous configu
On Tue, 29 Mar 2011 14:43:46 +0100, Chris Wilson
wrote:
> Proof-of-concept sanity check to see if we did successfully enable the
> pipe. Without a means of report back the error and forcibly reverting back
> to the previous configuration, the error message is a little useless.
I still like it --
On Tue, 29 Mar 2011 09:48:24 -0700, Jesse Barnes
wrote:
> Still, it's a nice assertion at least.
It's a nice idea. But we need to wait much, much longer before even
trying...
Something to improve.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Mar 29, 2011 at 14:11:43 +0300, Christophe Gallaire wrote:
> Does this new version contains the fix for the Lenovo U160?
>
You need a kernel fix. This is not a kernel. So no.
Cheers,
Julien
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskt
On Tue, 29 Mar 2011 14:43:46 +0100
Chris Wilson wrote:
> Proof-of-concept sanity check to see if we did successfully enable the
> pipe. Without a means of report back the error and forcibly reverting back
> to the previous configuration, the error message is a little useless.
> ---
> drivers/gpu
On Tue, 29 Mar 2011 07:11:27 +0100
Chris Wilson wrote:
> This fails on the Macbook for example, and Jesse reported a failure
> after unloading and reloading the i915.ko module on a HP system. It
> looked promising distinguishing several of the ghost LVDS, but with even
> a single false positive,
> > > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie
> > > > > wrote:
> > > > > > can you guys ask someone internally about it also, there is a
> > > > > > driver somewhere in Google also for driving the LVDS->HDMI
> > > > > > adapter but I'm not sure what i2c bus its hanging off.
> > > > > >
>
On Tue, 29 Mar 2011 17:22:13 +0300, Pekka Enberg wrote:
> No ssh - the box seems to be dead.
But now you have a machine with which to listen out for the netconsole
scream of anguish...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
In
Proof-of-concept sanity check to see if we did successfully enable the
pipe. Without a means of report back the error and forcibly reverting back
to the previous configuration, the error message is a little useless.
---
drivers/gpu/drm/i915/intel_display.c | 24
1 files
On Tue, 29 Mar 2011 16:05:35 +0300, Pekka Enberg wrote:
> On Tue, Mar 29, 2011 at 3:23 PM, Chris Wilson
> wrote:
> > Required so that we don't obliterate the queue if initialising the
> > rings after the global IRQ handler is installed.
> >
> > Signed-off-by: Chris Wilson
>
> I applied both of
- Original message -
>
> - Original message -
> > - Original message -
> > > - Original message -
> > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie
> > > > wrote:
> > > > > can you guys ask someone internally about it also, there is a
> > > > > driver somewhere
Required so that we don't obliterate the queue if initialising the
rings after the global IRQ handler is installed.
Signed-off-by: Chris Wilson
---
This patch is required in conjunction with the first to prevent an oops
the first time we try to use i915_wait_request (i.e. when starting X).
-Chri
- Original message -
> - Original message -
> > - Original message -
> > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie
> > > wrote:
> > > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson
> > > > wrote:
> > > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
> > > > >
- Original message -
> - Original message -
> > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie wrote:
> > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson
> > > wrote:
> > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
> > > > wrote:
> > > > > Hi Chris, have you updated this
Chris Wilson a dit dans un souffle :
A bit later than everyone expected as it took a fair while to get our
overall regression count down, it's time for a new release candidate.
Still nothing exciting happening here, as you would expect once we were in
the release phase, with just a couple of bug
- Original message -
> On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie wrote:
> > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson
> > wrote:
> > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
> > > wrote:
> > > > Hi Chris, have you updated this patch? I have an Intel D525
> > > > (Pinev
A bit later than everyone expected as it took a fair while to get our
overall regression count down, it's time for a new release candidate.
Still nothing exciting happening here, as you would expect once we were in
the release phase, with just a couple of bug fixes.
Please test!
-Chris
Chris Wils
- Original message -
> On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
> wrote:
> > Hi Chris, have you updated this patch? I have an Intel D525 (Pineview)
> > system with HDMI port connected through an LVDS converter. The "panel
> > timings" are the HDMI output mode, and it gets set t
If the outputs are active and continuing to access the GATT when we
teardown the PTEs, then there is a potential for us to hang the GPU.
The hang tends to be a PGTBL_ER with either an invalid host access or
an invalid display plane fetch.
Reported-by: Pekka Enberg
Signed-off-by: Chris Wilson
---
On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie wrote:
> On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson
> wrote:
>> On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
>> wrote:
>>> Hi Chris, have you updated this patch? I have an Intel D525 (Pineview)
>>> system with HDMI port connected through a
On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson wrote:
> On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
> wrote:
>> Hi Chris, have you updated this patch? I have an Intel D525 (Pineview)
>> system with HDMI port connected through an LVDS converter. The "panel
>> timings" are the HDMI output
On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
wrote:
> Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) system
> with HDMI port connected through an LVDS converter. The "panel timings" are
> the HDMI output mode, and it gets set through a BIOS option making it
> imp
On Mon, 28 Mar 2011, Keith Packard wrote:
> On Tue, 29 Mar 2011 07:49:12 +0100, Chris Wilson
> wrote:
>
> > Yes, Oliver pointed out that we need to pass much more panel
> > configuration data in order to configure a bare LVDS. Given the bizarre
> > situation of the LVDS-attached-HDMI PNV boxes
37 matches
Mail list logo
