Re: [Intel-gfx] [PATCH] drm/i915/dp: add a delay before setting panel brightness after power on

2021-09-20 Thread Vasily Khoruzhick
On Wed, Sep 15, 2021 at 1:47 AM Jani Nikula  wrote:
>
> On Tue, 14 Sep 2021, Vasily Khoruzhick  wrote:
> > On Tue, Sep 14, 2021 at 3:31 PM Jani Nikula  
> > wrote:
> >>
> >> On Tue, 14 Sep 2021, Lyude Paul  wrote:
> >> > On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote:
> >> >> On Mon, 13 Sep 2021, Vasily Khoruzhick  wrote:
> >> >> > Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface 
> >> >> > to
> >> >> > control brightness, apparently needs a delay before setting brightness
> >> >> > after power on. Without this delay the panel does accept the setting
> >> >> > and may come up with some arbitrary brightness (sometimes it's too 
> >> >> > dark,
> >> >> > sometimes it's too bright, I wasn't able to find a system).
> >> >> >
> >> >> > I don't have access to the spec, so I'm not sure if it's expected
> >> >> > behavior or a quirk for particular device.
> >> >> >
> >> >> > Delay was chosen by experiment: it works with 100ms, but fails with
> >> >> > anything lower than 75ms.
> >> >>
> >> >> Looks like we don't respect the panel delays for DPCD backlight. The
> >> >> values are used for setting up the panel power sequencer, and thus PWM
> >> >> based backlight, but we should probably use the delays in DPCD backlight
> >> >> code too.
> >> >
> >> > This makes sense to me, you're referring to the panel delays in the VBT
> >> > correct?
> >>
> >> Yes. See pps_init_delays() and intel_pps_backlight_on(). The delays
> >> aren't applied to DPCD backlight, I think it would make sense if they
> >> were.
> >
> > I guess it explains why it usually stops working after suspend.
> > Probably BIOS doesn't re-init the power sequencer on resume.
>
> The point is, the DPCD backlight isn't driven via the power sequencer,
> while the PWM pin would be.
>
> Please file a bug at [1], and attach /sys/kernel/debug/dri/0/i915_vbt as
> well as dmesg from boot with drm.debug=14 module parameter set.

Done, see https://gitlab.freedesktop.org/drm/intel/-/issues/4170

> Thanks,
> Jani.
>
>
> [1] https://gitlab.freedesktop.org/drm/intel/issues/new
>
>
>
> >
> >> BR,
> >> Jani.
> >>
> >> >
> >> >>
> >> >> BR,
> >> >> Jani.
> >> >>
> >> >>
> >> >> >
> >> >> > Signed-off-by: Vasily Khoruzhick 
> >> >> > ---
> >> >> >  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 4 
> >> >> >  1 file changed, 4 insertions(+)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> >> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> >> > index 4f8337c7fd2e..c4f35e1b5870 100644
> >> >> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> >> > @@ -210,6 +210,10 @@ intel_dp_aux_hdr_enable_backlight(const struct
> >> >> > intel_crtc_state *crtc_state,
> >> >> >
> >> >> > ctrl = old_ctrl;
> >> >> > if (panel->backlight.edp.intel.sdr_uses_aux) {
> >> >> > +   /* Wait 100ms to ensure that panel is ready otherwise 
> >> >> > it
> >> >> > may not
> >> >> > +* set chosen backlight level
> >> >> > +*/
> >> >> > +   msleep(100);
> >> >> > ctrl |= INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE;
> >> >> > intel_dp_aux_hdr_set_aux_backlight(conn_state, level);
> >> >> > } else {
> >> >>
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
>
> --
> Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH] drm/i915/dp: add a delay before setting panel brightness after power on

2021-09-14 Thread Vasily Khoruzhick
On Tue, Sep 14, 2021 at 3:31 PM Jani Nikula  wrote:
>
> On Tue, 14 Sep 2021, Lyude Paul  wrote:
> > On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote:
> >> On Mon, 13 Sep 2021, Vasily Khoruzhick  wrote:
> >> > Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to
> >> > control brightness, apparently needs a delay before setting brightness
> >> > after power on. Without this delay the panel does accept the setting
> >> > and may come up with some arbitrary brightness (sometimes it's too dark,
> >> > sometimes it's too bright, I wasn't able to find a system).
> >> >
> >> > I don't have access to the spec, so I'm not sure if it's expected
> >> > behavior or a quirk for particular device.
> >> >
> >> > Delay was chosen by experiment: it works with 100ms, but fails with
> >> > anything lower than 75ms.
> >>
> >> Looks like we don't respect the panel delays for DPCD backlight. The
> >> values are used for setting up the panel power sequencer, and thus PWM
> >> based backlight, but we should probably use the delays in DPCD backlight
> >> code too.
> >
> > This makes sense to me, you're referring to the panel delays in the VBT
> > correct?
>
> Yes. See pps_init_delays() and intel_pps_backlight_on(). The delays
> aren't applied to DPCD backlight, I think it would make sense if they
> were.

I guess it explains why it usually stops working after suspend.
Probably BIOS doesn't re-init the power sequencer on resume.

> BR,
> Jani.
>
> >
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> >
> >> > Signed-off-by: Vasily Khoruzhick 
> >> > ---
> >> >  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 4 
> >> >  1 file changed, 4 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> > index 4f8337c7fd2e..c4f35e1b5870 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> > @@ -210,6 +210,10 @@ intel_dp_aux_hdr_enable_backlight(const struct
> >> > intel_crtc_state *crtc_state,
> >> >
> >> > ctrl = old_ctrl;
> >> > if (panel->backlight.edp.intel.sdr_uses_aux) {
> >> > +   /* Wait 100ms to ensure that panel is ready otherwise it
> >> > may not
> >> > +* set chosen backlight level
> >> > +*/
> >> > +   msleep(100);
> >> > ctrl |= INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE;
> >> > intel_dp_aux_hdr_set_aux_backlight(conn_state, level);
> >> > } else {
> >>
>
> --
> Jani Nikula, Intel Open Source Graphics Center


[Intel-gfx] [PATCH] drm/i915/dp: add a delay before setting panel brightness after power on

2021-09-13 Thread Vasily Khoruzhick
Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to
control brightness, apparently needs a delay before setting brightness
after power on. Without this delay the panel does accept the setting
and may come up with some arbitrary brightness (sometimes it's too dark,
sometimes it's too bright, I wasn't able to find a system).

I don't have access to the spec, so I'm not sure if it's expected
behavior or a quirk for particular device.

Delay was chosen by experiment: it works with 100ms, but fails with
anything lower than 75ms.

Signed-off-by: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 4f8337c7fd2e..c4f35e1b5870 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -210,6 +210,10 @@ intel_dp_aux_hdr_enable_backlight(const struct 
intel_crtc_state *crtc_state,
 
ctrl = old_ctrl;
if (panel->backlight.edp.intel.sdr_uses_aux) {
+   /* Wait 100ms to ensure that panel is ready otherwise it may not
+* set chosen backlight level
+*/
+   msleep(100);
ctrl |= INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE;
intel_dp_aux_hdr_set_aux_backlight(conn_state, level);
} else {
-- 
2.33.0



Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Keep track of pwm-related backlight hooks separately

2021-01-12 Thread Vasily Khoruzhick
On Thu, Jan 7, 2021 at 2:52 PM Lyude Paul  wrote:
>
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for controlling it.
>
> HDR backlights, in particular VESA and Intel's HDR backlight
> implementations, can end up being more complicated. With Intel's
> proprietary interface, HDR backlight controls always run through the
> DPCD. When the backlight is in SDR backlight mode however, the driver
> may need to bypass the TCON and control the backlight directly through
> PWM.
>
> So, in order to support this we'll need to split our backlight callbacks
> into two groups: a set of high-level backlight control callbacks in
> intel_panel, and an additional set of pwm-specific backlight control
> callbacks. This also implies a functional changes for how these
> callbacks are used:
>
> * We now keep track of two separate backlight level ranges, one for the
>   high-level backlight, and one for the pwm backlight range
> * We also keep track of backlight enablement and PWM backlight
>   enablement separately
> * Since the currently set backlight level might not be the same as the
>   currently programmed PWM backlight level, we stop setting
>   panel->backlight.level with the currently programmed PWM backlight
>   level in panel->backlight.pwm_funcs->setup(). Instead, we rely
>   on the higher level backlight control functions to retrieve the
>   current PWM backlight level (in this case, intel_pwm_get_backlight()).
>   Note that there are still a few PWM backlight setup callbacks that
>   do actually need to retrieve the current PWM backlight level, although
>   we no longer save this value in panel->backlight.level like before.
>
> Additionally, we drop the call to lpt_get_backlight() in
> lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
> we get from it and only write it back if we're in CPU mode, and switching
> to PCH mode. The reason for this is because in the original codepath for
> this, it was expected that the intel_panel_bl_funcs->setup() hook would be
> responsible for fetching the initial backlight level. On lpt systems, the
> only time we could ever be in PCH backlight mode is during the initial
> driver load - meaning that outside of the setup() hook, lpt_get_backlight()
> will always be the callback used for retrieving the current backlight
> level. After this patch we still need to fetch and write-back the PCH
> backlight value if we're switching from CPU mode to PCH, but because
> intel_pwm_setup_backlight() will retrieve the backlight level after setup()
> using the get() hook, which always ends up being lpt_get_backlight(). Thus
> - an additional call to lpt_get_backlight() in lpt_setup_backlight() is
> made redundant.
>
> v5:
> * Fix indenting warnings from checkpatch
> v4:
> * Fix commit message
> * Remove outdated comment in intel_panel.c
> * Rename pwm_(min|max) to pwm_level_(min|max)
> * Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
>   indirection
> * Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
>   intel_panel_init_backlight_funcs() quite yet
> v3:
> * Reuse intel_panel_bl_funcs() for pwm_funcs
> * Explain why we drop lpt_get_backlight()
>
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 

Whole series is:

Tested-by: Vasily Khoruzhick 

> ---
>  .../drm/i915/display/intel_display_types.h|   4 +
>  drivers/gpu/drm/i915/display/intel_panel.c| 333 ++
>  2 files changed, 187 insertions(+), 150 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 1067bd073c95..ee5c2d50b81a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -252,6 +252,9 @@ struct intel_panel {
> bool alternate_pwm_increment;   /* lpt+ */
>
> /* PWM chip */
> +   u32 pwm_level_min;
> +   u32 pwm_level_max;
> +   bool pwm_enabled;
> bool util_pin_active_low;   /* bxt+ */
> u8 controller;  /* bxt+ only */
> struct pwm_device *pwm;
> @@ -263,6 +266,7 @@ struct intel_panel {
> struct backlight_device *device;
>
> const struct intel_panel_bl_funcs *funcs;
> +   const struct intel_panel_bl_funcs *pwm_funcs;
> void (*power)(struct intel_connector *, bool enable);
> } backlig

Re: [Intel-gfx] [RFC v2 1/8] drm/i915/dp: Program source OUI on eDP panels

2020-10-16 Thread Vasily Khoruzhick
On Wed, Sep 16, 2020 at 10:19 AM Lyude Paul  wrote:
>
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will just read zeroes.
>
> We also take care not to reprogram the source OUI if it already matches
> what we expect. This is just to be careful so that we don't accidentally
> take the panel out of any backlight control modes we found it in.
>
> v2:
> * Add careful parameter to intel_edp_init_source_oui() to avoid
>   re-writing the source OUI if it's already been set during driver
>   initialization
>
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 

Hi Lyude,

Sorry for a late reply.

Whole series is:

Tested-by: Vasily Khoruzhick 

Regards,
Vasily

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 33 +
>  1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4bd10456ad188..7db2b6a3cd52e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3424,6 +3424,29 @@ void intel_dp_sink_set_decompression_state(struct 
> intel_dp *intel_dp,
> enable ? "enable" : "disable");
>  }
>
> +static void
> +intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
> +{
> +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +   u8 oui[] = { 0x00, 0xaa, 0x01 };
> +   u8 buf[3] = { 0 };
> +
> +   /*
> +* During driver init, we want to be careful and avoid changing the 
> source OUI if it's
> +* already set to what we want, so as to avoid clearing any state by 
> accident
> +*/
> +   if (careful) {
> +   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, 
> sizeof(buf)) < 0)
> +   drm_err(>drm, "Failed to read source OUI\n");
> +
> +   if (memcmp(oui, buf, sizeof(oui)) == 0)
> +   return;
> +   }
> +
> +   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, 
> sizeof(oui)) < 0)
> +   drm_err(>drm, "Failed to write source OUI\n");
> +}
> +
>  /* If the sink supports it, try to set the power state appropriately */
>  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
>  {
> @@ -3443,6 +3466,10 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
> mode)
> } else {
> struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>
> +   /* Write the source OUI as early as possible */
> +   if (intel_dp_is_edp(intel_dp))
> +   intel_edp_init_source_oui(intel_dp, false);
> +
> /*
>  * When turning on, we need to retry for 1ms to give the sink
>  * time to wake up.
> @@ -4607,6 +4634,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> intel_dp_get_dsc_sink_cap(intel_dp);
>
> +   /*
> +* If needed, program our source OUI so we can make various 
> Intel-specific AUX services
> +* available (such as HDR backlight controls)
> +*/
> +   intel_edp_init_source_oui(intel_dp, true);
> +
> return true;
>  }
>
> --
> 2.26.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [Beignet] Beignet crashes on vanilla 3.17.1 with IVB hardware

2014-10-28 Thread Vasily Khoruzhick
Hi Zhigang,

On Tue, Oct 28, 2014 at 7:31 AM, Zhigang Gong
zhigang.g...@linux.intel.com wrote:
 Vasily,

 Could you try ImageMagick(convert) again with latest git master
 beignet(git-e46764f). It should work now.

It works fine now. Thank you!

Regards,
Vasily


 Thanks,
 Zhigang Gong.

 On Fri, Oct 24, 2014 at 04:36:49PM +0300, Vasily Khoruzhick wrote:
 Hi Zhigang,

 On Fri, Oct 24, 2014 at 12:13 PM, Zhigang Gong
 zhigang.g...@linux.intel.com wrote:
  Hi,
 
  Luxmark (both 2.0/2.1) works fine on my IVB machine. The back trace
  you provided below doesn't indicate it's a beignet related problem.
  It hadn't enter beignet domain and just crashed in luxmark internal.

 I'm testing with Luxmark-1.3.1. Luxmark 2.0 works fine.

  On Fri, Oct 24, 2014 at 12:04:29PM +0300, Vasily Khoruzhick wrote:
  Hi Zhigang,
 
  Luxmark crashes with following backtrace:
 
  Program received signal SIGSEGV, Segmentation fault.
  0x004cd8b0 in slg::PathOCLRenderEngine::StopLockLess() ()
  (gdb) bt
  #0  0x004cd8b0 in slg::PathOCLRenderEngine::StopLockLess() ()
  #1  0x00482236 in slg::RenderEngine::Stop() ()
  #2  0x0047be9b in slg::RenderSession::~RenderSession() ()
  #3  0x00468a77 in LuxMarkApp::Stop() ()
  #4  0x00468b46 in LuxMarkApp::InitRendering(LuxMarkAppMode,
  char const*) ()
 
  After a quick analysis, I confirm that the second case is indeed a beignet
  bug. Beignet lacks of some llvm intrinsics support such as
  llvm.uadd.with.overflow.i32().
 
  Will fix it next week.

 Ok, thank you!

  Thanks,
  Zhigang Gong.

 Regards
 Vasily
 ___
 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] [Beignet] Beignet crashes on vanilla 3.17.1 with IVB hardware

2014-10-27 Thread Vasily Khoruzhick
zhigang.g...@linux.intel.com wrote:
 I just checked again, and found both 3.17 and 3.17.1 should work
 fine on IVB with beignet. I just tested beignet on IVB with kernel
 3.17.1, all unit tests passed successfully. For IVB user, no need
 to wait for 3.18.

 Don't know which application you were testing on your IVB machine.
 If it could be reproduced easily, please open a bug on fd.o.

 Thanks,
 Zhigang Gong.

 On Fri, Oct 24, 2014 at 10:27:23AM +0800, Zhigang Gong wrote:
 Hi,

 For IVB, I just checked the 3.18-rc1, it has the following patch:
 commit c9224faa59c3071ecfa2d4b24592f4eb61e57069
 Author: Brad Volkin bradley.d.vol...@intel.com
 Date:   Tue Jun 17 14:10:34 2014 -0700

 drm/i915: Add some L3 registers to the parser whitelist

 Beignet needs these in order to program the L3 cache config for
 OpenCL workloads, particularly when using SLM.

 Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

 So, beignet should work fine with 3.18 on IVB/BYT.

 But for the HSW,I'm not quite sure when we could get a workable vanilla
 kernel. Something I found at the intel-gfx mail list as below and it doesn't
 sound good.

 http://lists.freedesktop.org/archives/intel-gfx/2014-May/044694.html
 http://lists.freedesktop.org/archives/intel-gfx/2014-May/045088.html

 CC to intel-gfx mail list. Hope we can get an official anwser here.

 Thanks,
 Zhigang Gong.

 On Thu, Oct 23, 2014 at 03:39:35PM +0300, Vasily Khoruzhick wrote:
  Hi,
 
  As you maybe know, any application which uses beignet OpenCL
  implementation crashes on Ivy Bridge hardware when using vanilla
  3.17.1 kernel.
  I guess it's due to batchbuffer security and patch to disable
  batchbuffer security is required, but guys, it fails since 3.16, and
  3.17 was released quite a while ago.
 
  Could you cooperate with i915 driver devs to make Beignet working on
  vanilla kernel without extra patches?
 
  Thanks!
 
  Regards,
  Vasily
  ___
  Beignet mailing list
  beig...@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/beignet
 ___
 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] [Beignet] Beignet crashes on vanilla 3.17.1 with IVB hardware

2014-10-27 Thread Vasily Khoruzhick
Hi Zhigang,

On Fri, Oct 24, 2014 at 12:13 PM, Zhigang Gong
zhigang.g...@linux.intel.com wrote:
 Hi,

 Luxmark (both 2.0/2.1) works fine on my IVB machine. The back trace
 you provided below doesn't indicate it's a beignet related problem.
 It hadn't enter beignet domain and just crashed in luxmark internal.

I'm testing with Luxmark-1.3.1. Luxmark 2.0 works fine.

 On Fri, Oct 24, 2014 at 12:04:29PM +0300, Vasily Khoruzhick wrote:
 Hi Zhigang,

 Luxmark crashes with following backtrace:

 Program received signal SIGSEGV, Segmentation fault.
 0x004cd8b0 in slg::PathOCLRenderEngine::StopLockLess() ()
 (gdb) bt
 #0  0x004cd8b0 in slg::PathOCLRenderEngine::StopLockLess() ()
 #1  0x00482236 in slg::RenderEngine::Stop() ()
 #2  0x0047be9b in slg::RenderSession::~RenderSession() ()
 #3  0x00468a77 in LuxMarkApp::Stop() ()
 #4  0x00468b46 in LuxMarkApp::InitRendering(LuxMarkAppMode,
 char const*) ()

 After a quick analysis, I confirm that the second case is indeed a beignet
 bug. Beignet lacks of some llvm intrinsics support such as
 llvm.uadd.with.overflow.i32().

 Will fix it next week.

Ok, thank you!

 Thanks,
 Zhigang Gong.

Regards
Vasily
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

2011-08-09 Thread Vasily Khoruzhick
On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote:
 On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote:
  On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
   Keith,
   
   first of all thanks for your prompt reply. Then...
   
   On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov k...@mns.spb.ru 
wrote:
 And now after v3.0 is out, I've tested it again, and yes, like it
 was broken on v3.0-rc5, it is (now even more) broken on v3.0 --
 after first

 bad io access the system freezes completely:
I looked at this when I first saw it (a couple of weeks ago), and I
couldn't see any obvious reason this patch would cause this
particular problem. I didn't want to revert the patch at that point
as I feared it would cause other subtle problems. Given that you've
got a work-around, it seemed best to just push this off past 3.0.
   
   What kind of a workaround are you talking about? Sorry, to me it all
   looked like UMS is being ignored forever. Anyway, let's move on to
   try to solve the issue.
   
Given the failing address passed to ioread32, this seems like it's
probably the call to READ_BREADCRUMB -- I915_BREADCRUMB_INDEX is
0x21, which is an offset in 32-bit units within the hardware status
page. If the status_page.page_addr value was zero, then the computed
address would end up being 0x84.

And, it looks like status_page.page_addr *will* end up being zero as
a result of the patch in question. The patch resets the entire ring
structure contents back to the initial values, which includes
smashing the status_page structure to zero, clearing the value of
status_page.page_addr set in i915_init_phys_hws.

Here's an untested patch which moves the initialization of
status_page.page_addr into intel_render_ring_init_dri. I note that
intel_init_render_ring_buffer *already* has the setting of the
status_page.page_addr value, and so I've removed the setting of
status_page.page_addr from i915_init_phys_hws.

I suspect we could remove the memset from
intel_init_render_ring_buffer; it seems entirely superfluous given
the memset in i915_init_phys_hws.

From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00
2001 From: Keith Packard kei...@keithp.com
Date: Fri, 22 Jul 2011 10:44:39 -0700
Subject: [PATCH] drm/i915: Initialize RCS ring status page address in

 intel_render_ring_init_dri

Physically-addressed hardware status pages are initialized early in
the driver load process by i915_init_phys_hws. For UMS environments,
the ring structure is not initialized until the X server starts. At
that point, the entire ring structure is re-initialized with all new
values. Any values set in the ring structure (including
ring-status_page.page_addr) will be lost when the ring is
re-initialized.

This patch moves the initialization of the status_page.page_addr
value to intel_render_ring_init_dri.

Signed-off-by: Keith Packard kei...@keithp.com
---

 drivers/gpu/drm/i915/i915_dma.c |6 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct drm_device
*dev)

 static int i915_init_phys_hws(struct drm_device *dev)
 {
 
drm_i915_private_t *dev_priv = dev-dev_private;

-   struct intel_ring_buffer *ring = LP_RING(dev_priv);

/* Program Hardware Status Page */
dev_priv-status_page_dmah =

@@ -71,10 +70,9 @@ static int i915_init_phys_hws(struct drm_device
*dev)

DRM_ERROR(Can not allocate hardware status page\n);
return -ENOMEM;

}

-   ring-status_page.page_addr =
-   (void __force __iomem 
*)dev_priv-status_page_dmah-vaddr;

-   memset_io(ring-status_page.page_addr, 0, PAGE_SIZE);
+   memset_io((void __force __iomem
*)dev_priv-status_page_dmah-vaddr, +0, PAGE_SIZE);

i915_write_hws_pga(dev);

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c index e961568..47b9b27
100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1321,6 +1321,9 @@ int intel_render_ring_init_dri(struct
drm_device *dev, u64 start, u32 size)

ring-get_seqno = pc_render_get_seqno;

}

+   if 

Re: [Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

2011-08-09 Thread Vasily Khoruzhick
On Tuesday 09 August 2011 17:47:56 Kirill Smelkov wrote:
 On Tue, Aug 09, 2011 at 05:00:52PM +0300, Vasily Khoruzhick wrote:
  On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote:
   On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote:
On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
 Keith,
 
 first of all thanks for your prompt reply. Then...
 
 On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
  On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov
  k...@mns.spb.ru
  
  wrote:
   And now after v3.0 is out, I've tested it again, and yes, like
   it was broken on v3.0-rc5, it is (now even more) broken on
   v3.0 -- after first
  
   bad io access the system freezes completely:
  I looked at this when I first saw it (a couple of weeks ago), and
  I couldn't see any obvious reason this patch would cause this
  particular problem. I didn't want to revert the patch at that
  point as I feared it would cause other subtle problems. Given
  that you've got a work-around, it seemed best to just push this
  off past 3.0.
 
 What kind of a workaround are you talking about? Sorry, to me it
 all looked like UMS is being ignored forever. Anyway, let's move
 on to try to solve the issue.
 
  Given the failing address passed to ioread32, this seems like
  it's probably the call to READ_BREADCRUMB --
  I915_BREADCRUMB_INDEX is 0x21, which is an offset in 32-bit
  units within the hardware status page. If the
  status_page.page_addr value was zero, then the computed address
  would end up being 0x84.
  
  And, it looks like status_page.page_addr *will* end up being zero
  as a result of the patch in question. The patch resets the
  entire ring structure contents back to the initial values, which
  includes smashing the status_page structure to zero, clearing
  the value of status_page.page_addr set in i915_init_phys_hws.
  
  Here's an untested patch which moves the initialization of
  status_page.page_addr into intel_render_ring_init_dri. I note
  that intel_init_render_ring_buffer *already* has the setting of
  the status_page.page_addr value, and so I've removed the setting
  of status_page.page_addr from i915_init_phys_hws.
  
  I suspect we could remove the memset from
  intel_init_render_ring_buffer; it seems entirely superfluous
  given the memset in i915_init_phys_hws.
  
  From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00
  2001 From: Keith Packard kei...@keithp.com
  Date: Fri, 22 Jul 2011 10:44:39 -0700
  Subject: [PATCH] drm/i915: Initialize RCS ring status page
  address in
  
   intel_render_ring_init_dri
  
  Physically-addressed hardware status pages are initialized early
  in the driver load process by i915_init_phys_hws. For UMS
  environments, the ring structure is not initialized until the X
  server starts. At that point, the entire ring structure is
  re-initialized with all new values. Any values set in the ring
  structure (including
  ring-status_page.page_addr) will be lost when the ring is
  re-initialized.
  
  This patch moves the initialization of the status_page.page_addr
  value to intel_render_ring_init_dri.
  
  Signed-off-by: Keith Packard kei...@keithp.com
  ---
  
   drivers/gpu/drm/i915/i915_dma.c |6 ++
   drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
   2 files changed, 5 insertions(+), 4 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_dma.c
  b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c 100644
  --- a/drivers/gpu/drm/i915/i915_dma.c
  +++ b/drivers/gpu/drm/i915/i915_dma.c
  @@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct
  drm_device *dev)
  
   static int i915_init_phys_hws(struct drm_device *dev)
   {
   
  drm_i915_private_t *dev_priv = dev-dev_private;
  
  -   struct intel_ring_buffer *ring = LP_RING(dev_priv);
  
  /* Program Hardware Status Page */
  dev_priv-status_page_dmah =
  
  @@ -71,10 +70,9 @@ static int i915_init_phys_hws(struct
  drm_device *dev)
  
  DRM_ERROR(Can not allocate hardware status page\n);
  return -ENOMEM;
  
  }
  
  -   ring-status_page.page_addr =
  -   (void __force __iomem 
  *)dev_priv-status_page_dmah-vaddr;
  
  -   memset_io(ring-status_page.page_addr, 0, PAGE_SIZE);
  +   memset_io((void __force __iomem
  *)dev_priv-status_page_dmah-vaddr, +0, PAGE_SIZE);
  
  i915_write_hws_pga(dev);
  
  diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
  b/drivers/gpu/drm/i915/intel_ringbuffer.c index e961568..47b9b27
  100644

Re: [Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

2011-08-09 Thread Vasily Khoruzhick
On Tuesday 09 August 2011 18:34:46 Kirill Smelkov wrote:
 On Tue, Aug 09, 2011 at 06:09:57PM +0300, Vasily Khoruzhick wrote:
  On Tuesday 09 August 2011 17:47:56 Kirill Smelkov wrote:
   On Tue, Aug 09, 2011 at 05:00:52PM +0300, Vasily Khoruzhick wrote:
On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote:
 On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote:
  On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
   Keith,
   
   first of all thanks for your prompt reply. Then...
   
   On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov
k...@mns.spb.ru

wrote:
 And now after v3.0 is out, I've tested it again, and yes,
 like it was broken on v3.0-rc5, it is (now even more)
 broken on v3.0 -- after first

 bad io access the system freezes completely:
I looked at this when I first saw it (a couple of weeks ago),
and I couldn't see any obvious reason this patch would cause
this particular problem. I didn't want to revert the patch
at that point as I feared it would cause other subtle
problems. Given that you've got a work-around, it seemed
best to just push this off past 3.0.
   
   What kind of a workaround are you talking about? Sorry, to me
   it all looked like UMS is being ignored forever. Anyway,
   let's move on to try to solve the issue.
   
Given the failing address passed to ioread32, this seems like
it's probably the call to READ_BREADCRUMB --
I915_BREADCRUMB_INDEX is 0x21, which is an offset in 32-bit
units within the hardware status page. If the
status_page.page_addr value was zero, then the computed
address would end up being 0x84.

And, it looks like status_page.page_addr *will* end up being
zero as a result of the patch in question. The patch resets
the entire ring structure contents back to the initial
values, which includes smashing the status_page structure to
zero, clearing the value of status_page.page_addr set in
i915_init_phys_hws.

Here's an untested patch which moves the initialization of
status_page.page_addr into intel_render_ring_init_dri. I note
that intel_init_render_ring_buffer *already* has the setting
of the status_page.page_addr value, and so I've removed the
setting of status_page.page_addr from i915_init_phys_hws.

I suspect we could remove the memset from
intel_init_render_ring_buffer; it seems entirely superfluous
given the memset in i915_init_phys_hws.

From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17
00:00:00 2001 From: Keith Packard kei...@keithp.com
Date: Fri, 22 Jul 2011 10:44:39 -0700
Subject: [PATCH] drm/i915: Initialize RCS ring status page
address in

 intel_render_ring_init_dri

Physically-addressed hardware status pages are initialized
early in the driver load process by i915_init_phys_hws. For
UMS environments, the ring structure is not initialized
until the X server starts. At that point, the entire ring
structure is re-initialized with all new values. Any values
set in the ring structure (including
ring-status_page.page_addr) will be lost when the ring is
re-initialized.

This patch moves the initialization of the
status_page.page_addr value to intel_render_ring_init_dri.

Signed-off-by: Keith Packard kei...@keithp.com
---

 drivers/gpu/drm/i915/i915_dma.c |6 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c
100644 --- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct
drm_device *dev)

 static int i915_init_phys_hws(struct drm_device *dev)
 {
 
drm_i915_private_t *dev_priv = dev-dev_private;

-   struct intel_ring_buffer *ring = LP_RING(dev_priv);

/* Program Hardware Status Page */
dev_priv-status_page_dmah =

@@ -71,10 +70,9 @@ static int i915_init_phys_hws(struct
drm_device *dev)

DRM_ERROR(Can not allocate hardware status 
page\n);
return -ENOMEM;

}

-   ring-status_page.page_addr =
-   (void __force __iomem 
*)dev_priv

Re: [Intel-gfx] [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU

2010-12-08 Thread Vasily Khoruzhick
On Wednesday 08 December 2010 18:24:35 Chris Wilson wrote:
 This is just a preliminary attempt to see if this even helps. Obviously
 some more effort will need to be spent investigating a better choice of
 latency and when we need to request it, but first: does this help?

Sorry, but it does not. glxgears is still jerky.

Regards
Vasily
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU

2010-12-08 Thread Vasily Khoruzhick
On Wednesday 08 December 2010 19:54:59 Andrew Lutomirski wrote:
 On Wed, Dec 8, 2010 at 12:00 PM, Vasily Khoruzhick anars...@gmail.com 
wrote:
  On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote:
  On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick
  anars...@gmail.com
  
  wrote:
   On Wednesday 08 December 2010 18:24:35 Chris Wilson wrote:
This is just a preliminary attempt to see if this even helps.
Obviously some more effort will need to be spent investigating a
better choice of latency and when we need to request it, but first:
does this help?
   
   Sorry, but it does not. glxgears is still jerky.
 
 Do you have the 2.6.36.2 candidate patch that fixes pm_qos in?  From
 the description, it looks like pm_qos doesn't work at all without it.

Nope, where I can get this patch?

Regards
Vasily
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] less load less performance

2010-10-31 Thread Vasily Khoruzhick
On Sunday 31 October 2010 18:44:47 Alexey Fisher wrote:
 Hallo all,
 
 after testing latest intel_drm_next v2.6.36-07547-g100519e on my netbook
 i have seen interesting issue. Standardly started glxgears performs not
 so well, it drops some times to 25fps.
 if start glxgears in fullscrean mode it performs well - about 60fps.

It's a know bug for 945GM(E) chipset:

https://bugs.freedesktop.org/show_bug.cgi?id=30364

Regards
Vasily
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Interrupt latency on some 945GM platforms

2010-09-27 Thread Vasily Khoruzhick
On 27 of September 2010 03:46:23 Shaohua Li wrote:

 does disable msi help with 'pci=nomsi'?

Doesn't help on my system :(
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Interrupt latency on some 945GM platforms

2010-09-27 Thread Vasily Khoruzhick
On 26 of September 2010 13:53:35 Stefan Biereigel wrote:

 Hello Everyone,
 just to add on to reports of this problem, there was a Thread here in
 LKML some months ago targeting the same problem (but not really
 attacking it at the Chipset driver). As I have one of those Laptops with
 a 945GM-Chipset and am stuck with the same Problem (disabled tickless
 now as a workaround and set ticks to 1000) I could maybe do some testing
 of patches.
 So what I can summarize is what the others did before: Disabling CPU1
 helps, adding nohz=off helps, changing the Clocksource afterwards helps,
 binding the Interrupt does NOT help.
 So here's the Link to the old Discussion with follow-ups, maybe you can
 get some furter information from there.
 http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-05/msg03696.html
 We targeted the BIOS itself as everyone in this thread happened to own
 an Phoenix BIOS with some special version string.
 best, Stefan

Yep, my laptop has Phoenix BIOS too. Btw, this BIOS has buggy DSDT (thermal 
and battery don't work reliably without patching DSDT). But I tested with and 
without patched DSDT - so my custom DSDT is not cause of bug in my case.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Interrupt latency on some 945GM platforms

2010-09-24 Thread Vasily Khoruzhick
On 24 of September 2010 22:39:01 Jesse Barnes wrote:
 On Thu, 16 Sep 2010 23:06:46 +0300
 
 Vasily Khoruzhick anars...@gmail.com wrote:
  В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner 
написал:
   Ok. The problematic part of HPET was not the clocksource, it was the
   clock event device which failed to deliver interrupts occasionally. It
   was worth a try at least.
  
  Hm, it seems that jerky glxgears is not related to jerky keyboard events.
  Keyboard is jerky only in konsole (kde terminal emulator), it seems
  something happened it seems that font rendering performance is much
  worse in latest xf86-video-intel than in xf86-video-intel-2.12.0.
 
 Len just had me try a few things too:
   - maxcpus=1 lets things work
   - offlining cpu1 at runtime (echo 0
 
  /sys/devices/system/cpu/cpu1/online) lets things work
 
   - binding the i915 interrupt to cpu 0 does *not* help
 
 Vasily and Paolo, do you both have Atom CPUs with hyperthreading
 enabled?

Nope, I have Core2Duo T5500, dual-core, no hyperthreading :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Interrupt latency on some 945GM platforms

2010-09-17 Thread Vasily Khoruzhick
В сообщении от 17 of September 2010 19:30:26 автор Jesse Barnes написал:
 Yeah if that works we could definitely add some qos calls to the driver. 
 When vblanks are alive we'd need a latency less tha the refresh rate, and
 when commands are oustanding we'd probably want it even lower.
 
 Vasily, can you try the qos workaround on your machine and see if it works
 too?
 
 Thanks,

Just give me a patch :)

Regards
Vasily


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Interrupt latency on some 945GM platforms

2010-09-16 Thread Vasily Khoruzhick
В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
   processor.max_cstate=2
  
  Nope, it doesn't work with max_cstate=2
 
 Perhaps intel_idle is being used? Any mention of it in dmesg?

Sitsofe, maybe you misunderstood me, I mean with max_cstate=1 graphics is 
smooth, with higher values (i.e. max_cstate=2) graphics is jerky.

Btw, Jesse, any comments/solutions/workarounds except one with 
processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo 
bugzilla?


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Interrupt latency on some 945GM platforms

2010-09-16 Thread Vasily Khoruzhick
В сообщении от 16 of September 2010 21:07:39 автор Thomas Gleixner написал:

  Btw, Jesse, any comments/solutions/workarounds except one with
  processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo
  bugzilla?
 
 we fixed a HPET related bug a few days ago, which might be the cause
 for your problem as well.

Nope, it doesn't help :(

Regards
Vasily


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Interrupt latency on some 945GM platforms

2010-09-16 Thread Vasily Khoruzhick
В сообщении от 16 of September 2010 21:30:58 автор Vasily Khoruzhick написал:
 В сообщении от 16 of September 2010 21:07:39 автор Thomas Gleixner написал:
   Btw, Jesse, any comments/solutions/workarounds except one with
   processor.max_cstate=1 in kernel commandline? Should I file a bug on
   fdo bugzilla?
  
  we fixed a HPET related bug a few days ago, which might be the cause
  for your problem as well.
 
 Nope, it doesn't help :(

Btw, I suspect hpet is not related, I disabled hpet completely in kernel 
config but issue is still here (clocksource is acpi_pm)

Regards
Vasily


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Interrupt latency on some 945GM platforms

2010-09-16 Thread Vasily Khoruzhick
В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner написал:
 Ok. The problematic part of HPET was not the clocksource, it was the
 clock event device which failed to deliver interrupts occasionally. It
 was worth a try at least.

Hm, it seems that jerky glxgears is not related to jerky keyboard events. 
Keyboard is jerky only in konsole (kde terminal emulator), it seems something 
happened it seems that font rendering performance is much worse in latest 
xf86-video-intel than in xf86-video-intel-2.12.0.

Regards
Vasily


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] vsync problems with recent graphics stack and 945gm

2010-09-13 Thread Vasily Khoruzhick
Hi there, I've just built graphics stack (xf86-video-intel, libdrm, mesa) from 
git (but I'm on 2.6.35.x kernel) and still experiencing vsync troubles without 
composite manager, here's output of glxgears:

$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
243 frames in 5.0 seconds = 48.124 FPS
157 frames in 5.0 seconds = 31.300 FPS
155 frames in 5.0 seconds = 30.864 FPS

But I'm pretty sure that vertical refresh is 60 hz! And gears are jerky (not 
smooth at all). If I move mouse cursor over glxgears window FPS goes up to 60. 
And main problem is that keyboard events are also jerky, i.e. I press key and 
system receives press event in 0.1-0.5 sec or so (tested via xev).

There's no such problem when composition manager is running (i.e. effects are 
enabled in KDE)

Is there any solution for this problem? It really annoys me.

Regards
Vasily


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Interrupt latency on some 945GM platforms

2010-09-13 Thread Vasily Khoruzhick
В сообщении от 14 of September 2010 00:19:55 автор Jesse Barnes написал:
 On Tue, 14 Sep 2010 00:10:08 +0300
 
 Vasily Khoruzhick anars...@gmail.com wrote:
  В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал:
   I remember seeing a similar problem on an Eee PC I had; it seemed to be
   timer/interrupt related somehow.  If I booted with clocksource=tsc
   (or maybe it was pit) I got nice smooth animations, but if I used the
   HPET things were really slow.
   
   Does the same work for you?
  
  Yeah, it works for me (will use it as temporary workaround). But it
  definitely is not clean solution, as I can't use nohz mode with tsc
  clocksource :)
 
 Thomas, does this ring any bells for you?
 
 I think the root symptom of the issue is that we get a much reduced i915
 interrupt frequency (or no interrupts) on some 945GM platforms when
 using HPET as our clock source.
 
 In fact, on the platform I tested, it seemed that the i915 IRQs wouldn't
 generate interrupts at all when HPET was used.  But shaking the mouse or
 generating network traffic was enough to get i915 interrupts coming in,
 even though neither of those interrupts were shared with the i915
 device.
 
 Here's hoping you have some ideas to try...
 
 Thanks,

Jesse, is it possible to disable wait for vsync somehow? cpufreq is not 
working for me with nohz=no for some reason, as result cpu temperature and 
power usage are higher. I prefer to see tearing but with low power usage and 
without jerky keyboard :)

Regards
Vasily


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Interrupt latency on some 945GM platforms

2010-09-13 Thread Vasily Khoruzhick
В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:

 Yes, you can set vblank_mode=0 in your environment or drirc.  At least
 I think 0 is no vsync. :)

That doesn't help, glxgears shows ~1000fps, but it's output is jerky.


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Interrupt latency on some 945GM platforms

2010-09-13 Thread Vasily Khoruzhick
В сообщении от 14 of September 2010 00:59:52 автор Jesse Barnes написал:
 On Tue, 14 Sep 2010 00:52:31 +0300
 
 Vasily Khoruzhick anars...@gmail.com wrote:
  В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:
   Yes, you can set vblank_mode=0 in your environment or drirc.  At least
   I think 0 is no vsync. :)
  
  That doesn't help, glxgears shows ~1000fps, but it's output is jerky.
 
 Is it smooth with clocksource=tsc?  I wonder if the GPU batch
 interrupts are also getting delayed, and possibly timer ticks...


Yes, it's smooth with clocksource=tsc nohz=off

Regards
Vasily


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Intel 2010Q2 release

2010-06-28 Thread Vasily Khoruzhick
В сообщении от 27 июня 2010 15:31:28 автор Chris Wilson написал:
 On Sun, 27 Jun 2010 14:30:24 +0300, Vasily Khoruzhick anars...@gmail.com 
wrote:
  Ok, I'll file bug once I reproduce it once again (can't reproduce it
  since posted first mail :().
 
 Thankyou, the information will be appreciated.

Here it is:

https://bugs.freedesktop.org/show_bug.cgi?id=28785


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Intel 2010Q2 release

2010-06-27 Thread Vasily Khoruzhick
В сообщении от 27 июня 2010 15:31:28 автор Chris Wilson написал:
 You need libdrm.git, in particular:
 
 commit 726210f87d558d558022f35bc8c839e798a19f0c
 Author: Chris Wilson ch...@chris-wilson.co.uk
 Date:   Thu Jun 24 11:38:00 2010 +0100
 
 intel: Limit tiled pitches to 8192 on pre-i965.
 
 Fixes:
 
   Bug 28515 - Failed to allocate framebuffer when exceed 2048 width
   https://bugs.freedesktop.org/show_bug.cgi?id=28515
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

Then you should release new libdrm, you can't say to ordinary users that they 
need version from git, they just can't compile it.

Regards
Vasily


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] 945gm: xrandr crashes X

2010-05-25 Thread Vasily Khoruzhick
Hi, after upgrade to 2.6.34 kernel I'm unable to configure external VGA 
monitor anymore, any attempt to use xrandr results in X crash with following 
message:

X: intel_bufmgr_gem.c:900: drm_intel_gem_bo_unreference_locked_timed: 
Assertion `((bo_gem-refcount)-atomic)  0' failed.

There's a bug entry in gentoo bugzilla, however they blame xorg-server, but 
xorg-server-1.8.x works for me with 2.6.33.x kernel:

http://bugs.gentoo.org/show_bug.cgi?id=318743

Is it known/fixed issue, or should I file a new bug on fd.o bugzilla?

Regards
Vasily


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx