All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 6/6] drm/i915/selftests: Make the CS timestamp tests work on gen4-snb (sort of)
Date: Sun, 17 May 2020 13:49:36 +0100	[thread overview]
Message-ID: <158971977642.10809.16745087788965571257@build.alporthouse.com> (raw)
In-Reply-To: <20200302143943.32676-6-ville.syrjala@linux.intel.com>

Quoting Ville Syrjala (2020-03-02 14:39:43)
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> On pre-ivb the CS timestamp register is only present on RCS (despite
> what snb bspec claims). Let's test it.
> 
> Also on ctg/elk/ilk the usable part of the timestamp is the UDW so
> let's read that instead of the LDW. On ctg/elk the 10 msbs of the LDW
> do actually work, but we configure cs_timestamp_frequency_hz as if
> they didn't so  that we can treat ctg/elk the same as ilk.
> 
> TODO: figure out why the results we get aren't reliable. On some
> iterations we can get totally wrong (though consistent) values,
> on other iterations the values are correct. And somehow changing
> the offsets into the hwsp also seems to affect the behaviour.
> Manually reading the register always seems fine, so feels like
> the problem has something to do with the store rather than the actual
> register read.

On i965gm, I get fairly random output from reading the CS_TIMESTAMP.

One step at a time, first let's get the test results for reading
CS_TIMESTAMP vs the updated rawclk and see how well we fare across the
farm. Then we might see if there's a pattern here.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-05-17 12:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-02 14:39 [Intel-gfx] [PATCH 1/6] drm/i915: Nuke pointless div by 64bit Ville Syrjala
2020-03-02 14:39 ` [Intel-gfx] [PATCH 2/6] drm/i915: Store CS timestamp frequency in Hz Ville Syrjala
2020-05-13 15:04   ` Chris Wilson
2020-05-13 15:08   ` Lionel Landwerlin
2020-03-02 14:39 ` [Intel-gfx] [PATCH 3/6] drm/i915: Fix cs_timestamp_frequency_hz for ctg/elk/ilk Ville Syrjala
2020-03-02 14:39 ` [Intel-gfx] [PATCH 4/6] drm/i915: Fix cs_timestamp_frequency_hz for cl/bw Ville Syrjala
2020-03-02 14:39 ` [Intel-gfx] [PATCH 5/6] drm/i915: Extract i915_cs_timestamp_{ns_to_ticks, tick_to_ns}() Ville Syrjala
2020-05-13 15:09   ` Chris Wilson
2020-03-02 14:39 ` [Intel-gfx] [PATCH 6/6] drm/i915/selftests: Make the CS timestamp tests work on gen4-snb (sort of) Ville Syrjala
2020-05-17 12:49   ` Chris Wilson [this message]
2020-03-02 14:58 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915: Nuke pointless div by 64bit Patchwork
2020-03-02 15:15 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2020-03-02 15:24 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-03-03  1:51 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-05-13 14:57 ` [Intel-gfx] [PATCH 1/6] " Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=158971977642.10809.16745087788965571257@build.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.