Provide a way for userspace shader debugger to notify the kernel that it
will be debugging. This interface does two things, provides a way for
the kernel to prepare for debugging, and act as a lock between
concurrent debugging (of course none of this is enforced).
---
drivers/gpu/drm/i915/i915_deb
Provide a flag to disable the hangcheck timer
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c |6 --
drivers/gpu/drm/i915/i915_irq.c |9 ++---
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu
I'd like it to not be in the SDK anymore, and we're not using anything
from it.
Signed-off-by: Adam Jackson
---
src/intel_dri.c|1 -
src/intel_driver.c |1 -
src/legacy/i810/i810_dri.c |1 -
src/sna/sna_dri.c |1 -
src/sna/sna_driver.c |1 -
On Wed, 22 Jun 2011 11:42:04 -0700
Eric Anholt wrote:
> On Tue, 21 Jun 2011 15:24:24 -0700, Jesse Barnes
> wrote:
> > 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. Normal
On Wed, 22 Jun 2011 11:42:04 -0700
Eric Anholt wrote:
> On Tue, 21 Jun 2011 15:24:24 -0700, Jesse Barnes
> wrote:
> > 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. Normal
On Tue, 21 Jun 2011 15:24:24 -0700, Jesse Barnes
wrote:
> 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-stat
On Wed, Jun 22, 2011 at 07:08:41PM +0100, Chris Wilson wrote:
> On Wed, 22 Jun 2011 10:50:41 -0700, Ben Widawsky wrote:
> > And this on some remote machine:
> > netcat -u -l -p
>
> One issue that I found with netcat (at least in the incarnation above) is
> that it fails to listen for more th
On Wed, 22 Jun 2011 10:50:41 -0700, Ben Widawsky wrote:
> And this on some remote machine:
> netcat -u -l -p
One issue that I found with netcat (at least in the incarnation above) is
that it fails to listen for more than one connection (even on UDP). Am I
doing it wrong? I ended up using a v
On Wed, 22 Jun 2011 10:55:33 -0700, Ben Widawsky wrote:
> I was planning a debugfs entry for it. Do you see any advantages to
> using an IOCTL?
The only danger is that we developing a useful api and hiding it debugfs.
We may be caught and forced to maintain such even if we do declare it as a
work
On Wed, Jun 22, 2011 at 06:45:56PM +0100, Chris Wilson wrote:
> On Wed, 22 Jun 2011 10:32:50 -0700, Ben Widawsky wrote:
> > The hangcheck is undesirable when doing shader debugging. The debugger
> > interacts with the EU, and these may cause the hangcheck to fire at most
> > unfortunate times.
> >
Tested-by: Andrey Rahmatullin
--
WBR, wRAR
signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Jun 22, 2011 at 10:35:24AM -0700, Dan McCabe wrote:
> My SNB laptop completely locks up every now and then (maybe twice a
> day). Is there any good way to look at post-mortem data to help my
> diagnose this issue.
>
> I've seen discussions suggesting that I ssh into the machine, but I
>
On Wed, 22 Jun 2011 10:35:24 -0700, Dan McCabe wrote:
> My SNB laptop completely locks up every now and then (maybe twice a
> day). Is there any good way to look at post-mortem data to help my
> diagnose this issue.
>
> I've seen discussions suggesting that I ssh into the machine, but I
> can'
On Wed, 22 Jun 2011 10:32:50 -0700, Ben Widawsky wrote:
> The hangcheck is undesirable when doing shader debugging. The debugger
> interacts with the EU, and these may cause the hangcheck to fire at most
> unfortunate times.
>
> This provides a way to let the user disable the hangcheck when they
My SNB laptop completely locks up every now and then (maybe twice a
day). Is there any good way to look at post-mortem data to help my
diagnose this issue.
I've seen discussions suggesting that I ssh into the machine, but I
can't even do that.
TIA
cheers, danm
_
The hangcheck is undesirable when doing shader debugging. The debugger
interacts with the EU, and these may cause the hangcheck to fire at most
unfortunate times.
This provides a way to let the user disable the hangcheck when they want
to do shader debugging.
Not Signed-off-by, for review only
I
On Wed, 22 Jun 2011 18:04:46 +0100, Chris Wilson
wrote:
> Reviewed-by: Chris Wilson
I've added this to drm-intel-fixes
--
keith.pack...@intel.com
pgpIrsnHzhStD.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.
On Wed, Jun 22, 2011 at 06:15:40PM +0100, Chris Wilson wrote:
> On Wed, 22 Jun 2011 10:07:50 -0700, Ben Widawsky wrote:
> > On Wed, Jun 22, 2011 at 10:00 AM, Chris Wilson
> > wrote:
> >
> > > On Wed, 22 Jun 2011 09:55:00 -0700, Ben Widawsky
> > > wrote:
> > > > Get some more useful info for de
On Wed, 22 Jun 2011 10:07:50 -0700, Ben Widawsky wrote:
> On Wed, Jun 22, 2011 at 10:00 AM, Chris Wilson
> wrote:
>
> > On Wed, 22 Jun 2011 09:55:00 -0700, Ben Widawsky wrote:
> > > Get some more useful info for debugging backtraces on forcewake
> > > problems. Appropriate debug flags will be r
On Wed, Jun 22, 2011 at 10:00 AM, Chris Wilson wrote:
> On Wed, 22 Jun 2011 09:55:00 -0700, Ben Widawsky wrote:
> > Get some more useful info for debugging backtraces on forcewake
> > problems. Appropriate debug flags will be required for the drm module.
>
> Wouldn't it be neater to pass the reg
On Wed, 22 Jun 2011 09:55:01 -0700, Ben Widawsky wrote:
> The lock must be held for the saving and restoring of VGA state.
>
> Signed-off-by: Ben Widawsky
> CC: Alexander Zhaunerchyk
> CC: Andrey Rahmatullin
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Cen
On Wed, 22 Jun 2011 09:55:00 -0700, Ben Widawsky wrote:
> Get some more useful info for debugging backtraces on forcewake
> problems. Appropriate debug flags will be required for the drm module.
Wouldn't it be neater to pass the reg down to
gen6_gt_force_wake_get() so that we only have a single d
The lock must be held for the saving and restoring of VGA state.
Signed-off-by: Ben Widawsky
CC: Alexander Zhaunerchyk
CC: Andrey Rahmatullin
---
drivers/gpu/drm/i915/i915_suspend.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
Get some more useful info for debugging backtraces on forcewake
problems. Appropriate debug flags will be required for the drm module.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 12
drivers/gpu/drm/i915/i915_drv.h |8 +---
2 files changed, 13 inserti
I'm having some trouble testing these currently. Hopefully someone else can
verify them.
Ben Widawsky (2):
drm/i915: more forcewake lock error info
drm/i915: save/resume forcewake lock fixes
drivers/gpu/drm/i915/i915_drv.c | 12
drivers/gpu/drm/i915/i915_drv.h |8 +
On Wed, 22 Jun 2011 09:20:35 -0700, Keith Packard wrote:
> On Wed, 22 Jun 2011 08:29:24 +0200, Daniel Vetter wrote:
>
> > The important thing is that you may never use the cpu mappings with
> > these functions (for objects of similar size). Because libdrm reuses
> > bos without checking their do
Chris Wilson wrote:
>On Tue, 21 Jun 2011 15:24:24 -0700, Jesse Barnes
> wrote:
>> 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
>> freque
On Wed, 22 Jun 2011 08:29:24 +0200, Daniel Vetter wrote:
> The important thing is that you may never use the cpu mappings with
> these functions (for objects of similar size). Because libdrm reuses
> bos without checking their domain, you'll get tons of unnecessary
> clflush even on objects that
On Wed, 22 Jun 2011 12:29:21 +0800, "Zou, Nanhai" wrote:
> As I understand,
> with movnti + sfence, data should be surly reach memory. Cache should be
> coherent at this case.
I wouldn't mind seeing additional experiments in this area, but when
Eric and I tried this a couple of years ago, w
Jesse Barnes writes:
> > [Note to self: submit a bug report]
>
> Please do; and please try to confirm that your GPU hangs are really rc6
> related. RC6 provides a huge (multiple Watt) power savings, and we
> really want it to be robust.
Done: BZ#38567. I'd love to save those watts, so please le
On Tue, 21 Jun 2011 15:24:24 -0700, Jesse Barnes
wrote:
> 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-stat
Yes. This issue also affected our test now. I find it is just caused by the
absent of the variable xorg-server when disable SNA. I didn't find any update
for it, so I just make a patch for it.
Chris,
Can you have a review and add it? Thanks.
Best regards
zhaojian
> -Original Message---
Dear Haihao,
Am Donnerstag, den 23.06.2011, 00:47 +0800 schrieb Xiang, Haihao:
> Xiang, Haihao (5):
> Xv: separate fragments from M4 macros
> Xv: New shaders for Xv on Ivybridge
> Xv: update SURFACE_STATE & SAMPLER_STATE for Xv on Ivybridge
> Xv: upload new shaders to GEM objects for Xv o
The configuration is same as that on Sandybridge, but
many state commands are changed
Signed-off-by: Xiang, Haihao
---
src/i965_reg.h | 132
src/i965_video.c | 446 +++---
2 files changed, 554 insertions(+), 24 deletions(-)
di
Signed-off-by: Xiang, Haihao
---
src/i965_video.c | 36 ++--
1 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/src/i965_video.c b/src/i965_video.c
index 9fbba40..84230a1 100644
--- a/src/i965_video.c
+++ b/src/i965_video.c
@@ -149,6 +149,21 @@ stati
SURFACE_STATE & SAMPLER_STATE are changed since Ivybridge
Signed-off-by: Xiang, Haihao
---
src/brw_structs.h | 124 ++
src/i965_video.c | 154 +
2 files changed, 267 insertions(+), 11 deletions(-)
dif
Redefine some M4 macros, also update the check for
intel-gen4asm to support Ivybridge
Signed-off-by: Xiang, Haihao
---
configure.ac|2 +-
src/render_program/Makefile.am | 27 +--
src/render_program/exa_wm_src_affine.g7a
It is to prepare for Xv on Ivybridge. The difference from Sandybridge
is that all message payload must be in GRF registers instead of MRF registers
on Ivybridge. We will only redefine some M4 macros for Ivybridge
Signed-off-by: Xiang, Haihao
---
src/render_program/Makefile.am |
Xiang, Haihao (5):
Xv: separate fragments from M4 macros
Xv: New shaders for Xv on Ivybridge
Xv: update SURFACE_STATE & SAMPLER_STATE for Xv on Ivybridge
Xv: upload new shaders to GEM objects for Xv on Ivybridge
Xv: set up pipeline for Xv on Ivybridge
configure.ac
39 matches
Mail list logo
