Re: [Intel-gfx] Improvements and fixes for Intel ddx swap scheduling/timestamping.

[Daniel Vetter]

On Sun, Oct 07, 2012 at 08:38:07AM +0200, Mario Kleiner wrote:
> Hi,
> 
> a series of three patches to improve the dri2 swap scheduling
> and timestamping for the current intel ddx.
> 
> The first one enables proper OML_sync_control timestamping
> while triple-buffering is enabled and XOrg 1.12+ with DRI2SwapLimit
> support is in use. So far, timestamping was unuseable with
> triple-buffering, only worked with double-buffering.
> 
> The second one repairs the broken pageflip swap scheduling, which
> is apparently in a frightening state for timing sensitive apps
> since a year, due to a tiny but really ugly bug. In a perfect
> implementation of Murphy's law, the same commit that broke the
> scheduling also disabled the builtin correctness checks that
> were supposed to catch such bugs.
> 
> The third one proposes to revert 'SwapBuffersWait' to its old
> behaviour where it didn't affect pageflipping. I just can't
> think of a case where the current behaviour makes any sense, not
> even for benchmarking? But maybe i'm overlooking something.
> 
> All patches were tested against an Intel 945-GME gpu.
> 
> I don't really care about the 'SwapBuffersWait' patch one way
> or the other, but the first two are crucial to make the intel
> ddx useable in a painless and safe way again for users of
> timing sensitive applications.

This kind of regressions suck. Are there no tests (in piglit) that check
OML buffer swap and timestamping behaviour at least internally? Or could I
volunteer you to create that? Toghether with the new kernel flip tests
this should catch any further such regressions ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
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: Align the hangcheck wakeup to the nearest second

[Jani Nikula]

On Fri, 05 Oct 2012, Chris Wilson  wrote:
> round_jiffies() aligns the wakeup time to the nearest second in order to
> batch wakeups and reduce system load, which is useful for unimportant
> coarse timers like our hangcheck.
>
> v2: round_jiffies_relative() returns the relative jiffie value, whereas
> we need the absolute value for the timer.

On the series,

Reviewed-by: Jani Nikula 

> Suggested-by: Arjan van de Ven 
> Signed-off-by: Chris Wilson 
> Cc: Arjan van de Ven 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |1 +
>  drivers/gpu/drm/i915/i915_gem.c |3 +--
>  drivers/gpu/drm/i915/i915_irq.c |5 ++---
>  3 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d8043af..f79c664 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -460,6 +460,7 @@ typedef struct drm_i915_private {
>  
>   /* For hangcheck timer */
>  #define DRM_I915_HANGCHECK_PERIOD 1500 /* in ms */
> +#define DRM_I915_HANGCHECK_JIFFIES 
> msecs_to_jiffies(DRM_I915_HANGCHECK_PERIOD)
>   struct timer_list hangcheck_timer;
>   int hangcheck_count;
>   uint32_t last_acthd[I915_NUM_RINGS];
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c78f8e3..5639ac7 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2151,8 +2151,7 @@ i915_add_request(struct intel_ring_buffer *ring,
>   if (!dev_priv->mm.suspended) {
>   if (i915_enable_hangcheck) {
>   mod_timer(&dev_priv->hangcheck_timer,
> -   jiffies +
> -   msecs_to_jiffies(DRM_I915_HANGCHECK_PERIOD));
> +   round_jiffies_up(jiffies + 
> DRM_I915_HANGCHECK_JIFFIES));
>   }
>   if (was_empty) {
>   queue_delayed_work(dev_priv->wq,
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index e18e56b..943e67b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -353,8 +353,7 @@ static void notify_ring(struct drm_device *dev,
>   if (i915_enable_hangcheck) {
>   dev_priv->hangcheck_count = 0;
>   mod_timer(&dev_priv->hangcheck_timer,
> -   jiffies +
> -   msecs_to_jiffies(DRM_I915_HANGCHECK_PERIOD));
> +   round_jiffies_up(jiffies + 
> DRM_I915_HANGCHECK_JIFFIES));
>   }
>  }
>  
> @@ -1787,7 +1786,7 @@ void i915_hangcheck_elapsed(unsigned long data)
>  repeat:
>   /* Reset timer case chip hangs without another request being added */
>   mod_timer(&dev_priv->hangcheck_timer,
> -   jiffies + msecs_to_jiffies(DRM_I915_HANGCHECK_PERIOD));
> +   round_jiffies_up(jiffies + DRM_I915_HANGCHECK_JIFFIES));
>  }
>  
>  /* drm_dma.h hooks
> -- 
> 1.7.10.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] [RFC 0/4] drm: add raw monotonic timestamp support

[Imre Deak]

On Fri, 2012-10-05 at 16:07 -0700, Eric Anholt wrote:
> Imre Deak  writes:
> 
> > This is needed to make applications depending on vblank/page flip
> > timestamps independent of time ajdustments.
> >
> > I've tested these with an updated intel-gpu-test/flip_test and will send
> > the update for that once there's no objection about this patchset.
> >
> > The patchset is based on danvet's dinq branch with the following
> > additional patches from the intel-gfx ML applied: 
> > drm/i915: paper over a pipe-enable vs pageflip race
> > drm/i915: don't frob the vblank ts in finish_page_flip
> > drm/i915: call drm_handle_vblank before finish_page_flip
> 
> While people are in pageflip code:
> 
> It would be really, really cool for application tracing if we could get
> timestamps out of our swaps that used the TIMESTAMP register that is the
> timer used for event tracing on the GPU using GL_ARB_timer_query.  Then
> you could get decent visualizations of the latency of your rendering.

I assume this querying wouldn't be done through the wait_for_vblank or
page_flip ioctls, but rather a new ioctl or even through a new perf
event? We could add such a new interface later; this patchset is more
focused on the above two ioctls.

--Imre


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

Re: [Intel-gfx] [RFC 1/4] time: export getnstime_raw_and_real for DRM

[Imre Deak]

On Sat, 2012-10-06 at 03:41 +0200, Mario Kleiner wrote:
> [...]
> 
> But then Psychtoolbox checks each timestamp it gets from somewhere 
> "outside" (OML_sync_control / INTEL_swap_events / ALSA audio timestamps, 
> network receive timestamps, evdev, x11, ...) if it is in gettimeofday() 
> aka CLOCK_REALTIME aka wall time or in CLOCK_MONOTONIC time and just 
> remaps to whatever its reference clock is.
> 
> There's no way around this than to have no fixed expectations, but to 
> remap stuff on the fly, because different parts of the Linux universe 
> have decided on different time bases, or even switched somewhere from 
> one kernel version to the next in the last years, e.g., ALSA, which at 
> some time switched from wall clock to CLOCK_MONOTONIC. Sometimes 
> clock_gettime() wasn't available at all in older setups, so there only 
> was gettimeofday(). Or toolkits like GStreamer use different timebases 
> dependent on OS and sometimes even on plugins.
> 
> I would expect that other timing sensitive apps have to have ways to 
> handle this in similar ways.

I think the question is, can we be sure? I don't think there is any
guarantee that random application X will not be confused by an
unconditional switch to monotonic timestamps.

> Wrt. to the drm vblank/pageflip timestamps, the userspace extensions 
> which expose these (INTEL_swap_events, OML_sync_control) don't allow 
> apps to select which timebase to use, they define monotonic time as what 
> is returned, so i don't know how a userspace app could actually ask the 
> DRM for one or the other format? So i guess just switching to 
> CLOCK_MONOTONIC shouldn't be that bad.

An application could just use the kernel DRM interface directly. I admit
this is not very likely but this is what should determine the rules by
which we change the ABI. 

> Kristian, i assume Wayland will also return presentation timestamps in 
> the format and microsecond precision of the DRM, right?
> 
> On 05.10.12 18:22, intel-gfx-requ...@lists.freedesktop.org wrote:
> > Message: 7 Date: Fri, 5 Oct 2012 12:14:29 -0400 From: Kristian H?gsberg
> 
> ...
> > I just had a quick look at driver/input/evdev.c, since evdev devices
> > did a similar change recently to allow evdev timestamp from the
> > monotonic clock.  They're using a different time API:
> >
> > time_mono = ktime_get();
> >  time_real = ktime_sub(time_mono, ktime_get_monotonic_offset());
> >
> > and
> >
> >  event->time = ktime_to_timeval(client->clkid == CLOCK_MONOTONIC ?
> > mono : real);
> >
> > I'm not really up-to-date on kernel time APIs, but I wonder if that
> > may be better?  At least, I suspect we wouldn't need changes outside
> > drm if we use this API.
> >
> > Kristian
> 
> Userspace apps only have access to what gettimeofday() and 
> clock_gettime() for CLOCK_REALTIME (== gettimeofday() afaik) and 
> CLOCK_MONOTONIC return, so whatever is returned should be in 
> CLOCK_MONOTONIC format, otherwise there will be lots of tears and dead 
> kittens. I think what evdev does makes a lot of sense, but i'm also not 
> up-to-date about the various layers of timing apis.

Yes, this should be the case, regardless of which kernel interface we
decide to use.

--Imre



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

Re: [Intel-gfx] [RFC 0/4] drm: add raw monotonic timestamp support (Imre Deak)

[Imre Deak]

On Sat, 2012-10-06 at 04:46 +0200, Mario Kleiner wrote:
> On 05.10.12 15:37, intel-gfx-requ...@lists.freedesktop.org wrote:
> >
> > Today's Topics:
> >
> > 1. [RFC 0/4] drm: add raw monotonic timestamp support (Imre Deak)
> > 2. [RFC 1/4] time: export getnstime_raw_and_real for DRM (Imre Deak)
> > 3. [RFC 2/4] drm: make memset/calloc for _vblank_time more
> >robust (Imre Deak)
> > 4. [RFC 3/4] drm: use raw time in
> >drm_calc_vbltimestamp_from_scanoutpos (Imre Deak)
> > 5. [RFC 4/4] drm: add support for raw monotonic vblank
> >timestamps (Imre Deak)
> >
> >
> > --
> >
> > Message: 1
> > Date: Fri,  5 Oct 2012 16:36:58 +0300
> > From: Imre Deak
> > To: Daniel Vetter,  Chris Wilson
> > , Kristian H?gsberg
> > Cc:intel-gfx@lists.freedesktop.org,dri-de...@lists.freedesktop.org
> > Subject: [Intel-gfx] [RFC 0/4] drm: add raw monotonic timestamp
> > support
> > Message-ID:<1349444222-22274-1-git-send-email-imre.d...@intel.com>
> >
> > This is needed to make applications depending on vblank/page flip
> > timestamps independent of time ajdustments.
> >
> > I've tested these with an updated intel-gpu-test/flip_test and will send
> > the update for that once there's no objection about this patchset.
> >
> 
> I'm mostly fine with this, although the wall time compatibility stuff 
> may not be useful given that userspace apps, e.g., OpenGL clients, have 
> no way to actually ask for wall vs. monotonic, and the spec actually 
> expects them to expect monotonic timestamps.
> 
> I also see that an update to nouveau-kms is missing? Afaik the vblank 
> timestamping on nouveau-kms is still handled by the fallback in the drm, 
> but pageflip completion uses do_gettimeofday() for the timestamping and 
> returns a hard-coded zero vblank count all time for pageflip events 
> (yay!). Lucas Stach and me have written and tested some patches to fix 
> this over a year ago, but somehow they never made it into the kms 
> driver, mostly due to bad timing in when stuff was submitted, reviewed 
> and revised, not for serious technical objections iirc.
> 
> Ideally we could give them another try, or at least update nouveaus 
> pageflip timestamping to avoid really bad breakage for OpenGL clients or 
> the nouveau-ddx due to inconsistent vblank vs. pageflip timestamps.
> 
> I quickly looked over the patches, i think they look mostly good, see 
> some small comments below.
> 
> > Subject: [Intel-gfx] [RFC 3/4] drm: use raw time in
> > drm_calc_vbltimestamp_from_scanoutpos
> > Message-ID: <1349444222-22274-4-git-send-email-imre.d...@intel.com>
> >
> > The timestamp is used here for handling the timeout case, so we don't
> > want it to be affected by time adjustments.
> >
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/drm_irq.c |   13 +++--
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 77f6577..5e42981 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -576,7 +576,7 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
> > drm_device *dev, int crtc,
> >   unsigned flags,
> >   struct drm_crtc *refcrtc)
> >  {
> > -   struct timeval stime, raw_time;
> > +   struct timespec raw_stime, raw_etime, real_etime;
> > struct drm_display_mode *mode;
> > int vbl_status, vtotal, vdisplay;
> > int vpos, hpos, i;
> > @@ -625,13 +625,13 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
> > drm_device *dev, int crtc,
> > preempt_disable();
> >
> > /* Get system timestamp before query. */
> > -   do_gettimeofday(&stime);
> > +   getrawmonotonic(&raw_stime);
> >
> > /* Get vertical and horizontal scanout pos. vpos, hpos. */
> > vbl_status = dev->driver->get_scanout_position(dev, crtc, 
> > &vpos, &hpos);
> >
> > /* Get system timestamp after query. */
> > -   do_gettimeofday(&raw_time);
> > +   getnstime_raw_and_real(&raw_etime, &real_etime);
> >
> > preempt_enable();
> >
> > @@ -642,7 +642,8 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
> > drm_device *dev, int crtc,
> > return -EIO;
> > }
> >
> > -   duration_ns = timeval_to_ns(&raw_time) - timeval_to_ns(&stime);
> > +   duration_ns = timespec_to_ns(&raw_etime) -
> > + timespec_to_ns(&raw_stime);
> >
> > /* Accept result with <  max_error nsecs timing uncertainty. */
> > if (duration_ns <= (s64) *max_error)
> > @@ -692,11 +693,11 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
> > drm_device *dev, int crtc,
> > /* Subtract time delta from raw timestamp to get final
> >  * vblank_time timestamp for end of vblank.
> >  */
> > -   *vblank_ti

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document that we are implementing WaDisableBackToBackFlipFix

[Daniel Vetter]

On Thu, Oct 04, 2012 at 02:58:04PM -0300, Paulo Zanoni wrote:
> 2012/10/4 Damien Lespiau :
> > From: Damien Lespiau 
> >
> > For the next person that checks these kind of things, without having to
> > dig up the register definition.
> >
> > Signed-off-by: Damien Lespiau 
> 
> Reviewed-by: Paulo Zanoni 

Both patches merged into dinq, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
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: Align the hangcheck wakeup to the nearest second

[Daniel Vetter]

On Mon, Oct 08, 2012 at 01:59:58PM +0300, Jani Nikula wrote:
> On Fri, 05 Oct 2012, Chris Wilson  wrote:
> > round_jiffies() aligns the wakeup time to the nearest second in order to
> > batch wakeups and reduce system load, which is useful for unimportant
> > coarse timers like our hangcheck.
> >
> > v2: round_jiffies_relative() returns the relative jiffie value, whereas
> > we need the absolute value for the timer.
> 
> On the series,
> 
> Reviewed-by: Jani Nikula 

Both patches merged to dinq, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Maik Zumstrull]

On Sun, Oct 7, 2012 at 7:26 PM, Julien Cristau  wrote:
> On Mon, Oct  1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote:
>
>>  - without this patch, modern X errors out instead of starting,
>>because the intel driver requires kms.  (In a hypothetical better
>>world, userspace would know to fall back to vesa or something.)
>>
> I'd expect X to start with vesa or fbdev, rather than erroring out?

There's a corner case when X and the kernel know about the graphics
device, but libdrm doesn't, in which case an assertion in the X driver
fails and X doesn't start. Upstream libdrm has been okay for a few
releases. A bug against Debian libdrm has been open for a while, but
they seem to disagree about the importance, nothing has happened. In
fairness, this device seems to be rare so far. I'm not really using
mine any more, I put an extra graphics card in the box.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Maik Zumstrull]

On Sun, Oct 7, 2012 at 7:44 PM, Jonathan Nieder  wrote:

> X should have been able to start using the vesa or fbdev driver.  I'm
> not sure why that doesn't happen --- do you have an Xorg log from
> booting and trying to start X with a 3.2.y kernel without the
> "drm/i915: add Ivy Bridge GT2 Server entries" patch?

No, and it would be a bit of fiddling to get one. Like I said, I've
modified that system with a graphics card since. If it's important, I
could get it done, but probably not next week, I'll be traveling and
otherwise busy.
___
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 a pipe-enable vs pageflip race

[Imre Deak]

On Thu, 2012-10-04 at 19:20 +0200, Daniel Vetter wrote:
> I've discovered this on my ivb machine while stress-testing the new
> flip_tests. Only harmful effect observed is that the timestamp is a
> bit bogus.
> 
> Signed-off-by: Daniel Vetter 

I've seen the same issue on an ivb ultrabook machine and the patch gets
rid of it, so:

Tested-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_display.c |   10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 67912fe..9cecfd7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3253,6 +3253,16 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
>  
>   if (HAS_PCH_CPT(dev))
>   intel_cpt_verify_modeset(dev, intel_crtc->pipe);
> +
> + /*
> +  * There seems to be a race in PCH platform hw (at least on some
> +  * outputs) where an enabled pipe still completes any pageflip right
> +  * away (as if the pipe is off) instead of waiting for vblank. As soon
> +  * as the first vblank happend, everything works as expected. Hence just
> +  * wait for one vblank before returning to avoid strange things
> +  * happening.
> +  */
> + intel_wait_for_vblank(dev, intel_crtc->pipe);
>  }
>  
>  static void ironlake_crtc_disable(struct drm_crtc *crtc)


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

Re: [Intel-gfx] Improvements and fixes for Intel ddx swap scheduling/timestamping.

[Eric Anholt]

Daniel Vetter  writes:

> On Sun, Oct 07, 2012 at 08:38:07AM +0200, Mario Kleiner wrote:
>> Hi,
>> 
>> a series of three patches to improve the dri2 swap scheduling
>> and timestamping for the current intel ddx.
>> 
>> The first one enables proper OML_sync_control timestamping
>> while triple-buffering is enabled and XOrg 1.12+ with DRI2SwapLimit
>> support is in use. So far, timestamping was unuseable with
>> triple-buffering, only worked with double-buffering.
>> 
>> The second one repairs the broken pageflip swap scheduling, which
>> is apparently in a frightening state for timing sensitive apps
>> since a year, due to a tiny but really ugly bug. In a perfect
>> implementation of Murphy's law, the same commit that broke the
>> scheduling also disabled the builtin correctness checks that
>> were supposed to catch such bugs.
>> 
>> The third one proposes to revert 'SwapBuffersWait' to its old
>> behaviour where it didn't affect pageflipping. I just can't
>> think of a case where the current behaviour makes any sense, not
>> even for benchmarking? But maybe i'm overlooking something.
>> 
>> All patches were tested against an Intel 945-GME gpu.
>> 
>> I don't really care about the 'SwapBuffersWait' patch one way
>> or the other, but the first two are crucial to make the intel
>> ddx useable in a painless and safe way again for users of
>> timing sensitive applications.
>
> This kind of regressions suck. Are there no tests (in piglit) that check
> OML buffer swap and timestamping behaviour at least internally? Or could I
> volunteer you to create that? Toghether with the new kernel flip tests
> this should catch any further such regressions ...

I posted a first couple of tests that try to just hit the API for the
most part, but I don't test the MSCs or wall-time timing behavior.


pgp34K91aczHH.pgp
Description: PGP signature
___
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 a pipe-enable vs pageflip race

[Daniel Vetter]

On Mon, Oct 08, 2012 at 08:19:20PM +0300, Imre Deak wrote:
> On Thu, 2012-10-04 at 19:20 +0200, Daniel Vetter wrote:
> > I've discovered this on my ivb machine while stress-testing the new
> > flip_tests. Only harmful effect observed is that the timestamp is a
> > bit bogus.
> > 
> > Signed-off-by: Daniel Vetter 
> 
> I've seen the same issue on an ivb ultrabook machine and the patch gets
> rid of it, so:
> 
> Tested-by: Imre Deak 

Applied with the commit message extended as per our irc discussion, and
with your irc r-b applied. Thanks for testing&review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Improvements and fixes for Intel ddx swap scheduling/timestamping.

[Mario Kleiner]

On 08.10.12 18:08, Eric Anholt wrote:

Daniel Vetter  writes:


On Sun, Oct 07, 2012 at 08:38:07AM +0200, Mario Kleiner wrote:

Hi,

a series of three patches to improve the dri2 swap scheduling
and timestamping for the current intel ddx.

The first one enables proper OML_sync_control timestamping
while triple-buffering is enabled and XOrg 1.12+ with DRI2SwapLimit
support is in use. So far, timestamping was unuseable with
triple-buffering, only worked with double-buffering.

The second one repairs the broken pageflip swap scheduling, which
is apparently in a frightening state for timing sensitive apps
since a year, due to a tiny but really ugly bug. In a perfect
implementation of Murphy's law, the same commit that broke the
scheduling also disabled the builtin correctness checks that
were supposed to catch such bugs.

The third one proposes to revert 'SwapBuffersWait' to its old
behaviour where it didn't affect pageflipping. I just can't
think of a case where the current behaviour makes any sense, not
even for benchmarking? But maybe i'm overlooking something.

All patches were tested against an Intel 945-GME gpu.

I don't really care about the 'SwapBuffersWait' patch one way
or the other, but the first two are crucial to make the intel
ddx useable in a painless and safe way again for users of
timing sensitive applications.


This kind of regressions suck. Are there no tests (in piglit) that check
OML buffer swap and timestamping behaviour at least internally? Or could I
volunteer you to create that? Toghether with the new kernel flip tests
this should catch any further such regressions ...


I posted a first couple of tests that try to just hit the API for the
most part, but I don't test the MSCs or wall-time timing behavior.



I will also have a look at piglit at one of the next weekends and see 
what i can do. I haven't tried piglit yet, but that would make sense if 
it can catch bugs before a driver release. My own toolkit has some 
builtin online tests for the bugs or limitations that are so far known, 
but that can only catch driver bugs after a broken driver is released. 
Here is what i currently test for, starting at the line in the link 
(paranoia at work):




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

Re: [Intel-gfx] [RFC 1/4] time: export getnstime_raw_and_real for DRM

[Mario Kleiner]

On 08.10.12 13:35, Imre Deak wrote:

On Sat, 2012-10-06 at 03:41 +0200, Mario Kleiner wrote:

[...]

But then Psychtoolbox checks each timestamp it gets from somewhere
"outside" (OML_sync_control / INTEL_swap_events / ALSA audio timestamps,
network receive timestamps, evdev, x11, ...) if it is in gettimeofday()
aka CLOCK_REALTIME aka wall time or in CLOCK_MONOTONIC time and just
remaps to whatever its reference clock is.

There's no way around this than to have no fixed expectations, but to
remap stuff on the fly, because different parts of the Linux universe
have decided on different time bases, or even switched somewhere from
one kernel version to the next in the last years, e.g., ALSA, which at
some time switched from wall clock to CLOCK_MONOTONIC. Sometimes
clock_gettime() wasn't available at all in older setups, so there only
was gettimeofday(). Or toolkits like GStreamer use different timebases
dependent on OS and sometimes even on plugins.

I would expect that other timing sensitive apps have to have ways to
handle this in similar ways.


I think the question is, can we be sure? I don't think there is any
guarantee that random application X will not be confused by an
unconditional switch to monotonic timestamps.


Wrt. to the drm vblank/pageflip timestamps, the userspace extensions
which expose these (INTEL_swap_events, OML_sync_control) don't allow
apps to select which timebase to use, they define monotonic time as what
is returned, so i don't know how a userspace app could actually ask the
DRM for one or the other format? So i guess just switching to
CLOCK_MONOTONIC shouldn't be that bad.


An application could just use the kernel DRM interface directly. I admit
this is not very likely but this is what should determine the rules by
which we change the ABI.



Ok, that's a good point, agreed.
-mario
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx