public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 00/10] drm/i915: Some less complex FBC fixes
Date: Mon, 27 Jan 2014 11:36:34 +0200	[thread overview]
Message-ID: <20140127093634.GM9454@intel.com> (raw)
In-Reply-To: <20140126143332.GS9772@phenom.ffwll.local>

On Sun, Jan 26, 2014 at 03:33:32PM +0100, Daniel Vetter wrote:
> On Sat, Jan 25, 2014 at 08:59:49PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 23, 2014 at 07:47:59PM +0000, Chris Wilson wrote:
> > > On Thu, Jan 23, 2014 at 04:49:07PM +0200, ville.syrjala@linux.intel.com wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > Since fixing the FBC locking is a bigger task that will take a while,
> > > > I decided to pull all the simple fixes from my branch and post them
> > > > right away.
> > > > 
> > > > Some of these I've posted before, some others have seen a bit of action
> > > > by being in a public branch.
> > > > 
> > > > The FBC_FENCE_OFF change is just a guess at this point. The odd offset
> > > > just caught my eye while reading throguh i915_reg.h.
> > > 
> > > I didn't spot anything offensive in the series and each patch only does
> > > what it says on the tin. So I am going to stick my neck out and say
> > > 
> > > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > 
> > > for the series. Being picky, I guess Fix FBC_FENCE_OFF should only be an
> > > acked-by since we have no way to review it...
> > 
> > Entire series merged, and I'll fire up my g4x here to see what happens ;-)
> 
> Hm, seems to fail on my g4x when I enable fbc. This is on latest -nightly:
> 
> 
> > IGT-Version: 1.5-gb5109e62cea1 (x86_64) (Linux: 3.13.0-rc8+ x86_64)
> root@gina:/home/daniel/xorg/intel-gpu-tools# tests/kms_fbc_crc
> IGT-Version: 1.5-gb5109e62cea1 (x86_64) (Linux: 3.13.0-rc8+ x86_64)
> Beginning page_flip on crtc 3, connector 5
> 
> page_flip on crtc 3, connector 5: PASSED
> 
> Beginning page_flip on crtc 4, connector 5
> 
> page_flip on crtc 4, connector 5: PASSED
> 
> Subtest page_flip: SUCCESS
> Beginning mmap_cpu on crtc 3, connector 5
> 
> mmap_cpu on crtc 3, connector 5: PASSED
> 
> Beginning mmap_cpu on crtc 4, connector 5
> 
> mmap_cpu on crtc 4, connector 5: PASSED
> 
> Subtest mmap_cpu: SUCCESS

That's surprising considering the nuke stuff isn't there. It should
fail every time.

> Beginning mmap_gtt on crtc 3, connector 5
> 
> mmap_gtt on crtc 3, connector 5: PASSED
> 
> Beginning mmap_gtt on crtc 4, connector 5
> 
> mmap_gtt on crtc 4, connector 5: PASSED
> 
> Subtest mmap_gtt: SUCCESS
> Beginning blt on crtc 3, connector 5
> 
> blt on crtc 3, connector 5: PASSED
> 
> Beginning blt on crtc 4, connector 5
> 
> blt on crtc 4, connector 5: PASSED
> 
> Subtest blt: SUCCESS
> Beginning render on crtc 3, connector 5
> Test requirement not met in function fill_render, file kms_fbc_crc.c:212:
> Last errno: 0, Success
> Test requirement: (!rendercopy)
> Subtest render: SKIP
> Test requirement not met in function prepare_crtc, file kms_fbc_crc.c:398:
> Last errno: 19, No such device
> Test requirement: (!(data->ctx[0]))
> Subtest context: SKIP
> Beginning page_flip_and_mmap_cpu on crtc 3, connector 5
> Test assertion failure function test_crc, file kms_fbc_crc.c:315:
> Last errno: 0, Success
> Failed assertion: !igt_crc_equal(&crcs[0], &data->ref_crc[1])
> Subtest page_flip_and_mmap_cpu: FAIL
> Beginning page_flip_and_mmap_gtt on crtc 3, connector 5
> Test assertion failure function test_crc, file kms_fbc_crc.c:315:
> Last errno: 0, Success
> Failed assertion: !igt_crc_equal(&crcs[0], &data->ref_crc[1])
> Subtest page_flip_and_mmap_gtt: FAIL

And that's a bit weird since the fence is there. Although the FBC
locking is fubar, in this case there shouldn't be any issues since
the test doesn't try to do concurrent modesets or anything else
that would cause thing to go bad due to locking issues. So it's
not clear why it fails here.

Or could be my fence register fix was wrong after all. But then why
doesn't it fail for the non page flipped case?

In any case I think the test may need to be made harder. We should
really test the fence offset thing via panning, and probably write to
the first and last lines of the display to make sure the Y offset is
set up correctly.

> Beginning page_flip_and_blt on crtc 3, connector 5
> 
> page_flip_and_blt on crtc 3, connector 5: PASSED
> 
> Beginning page_flip_and_blt on crtc 4, connector 5
> 
> page_flip_and_blt on crtc 4, connector 5: PASSED
> 
> Subtest page_flip_and_blt: SUCCESS
> Beginning page_flip_and_render on crtc 3, connector 5
> Test requirement not met in function fill_render, file kms_fbc_crc.c:212:
> Last errno: 0, Success
> Test requirement: (!rendercopy)
> Subtest page_flip_and_render: SKIP
> Test requirement not met in function prepare_crtc, file kms_fbc_crc.c:398:
> Last errno: 19, No such device
> Test requirement: (!(data->ctx[0]))
> Subtest page_flip_and_context: SKIP
> 
> So something with flip + frontbuffer access seems still busted.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC

      parent reply	other threads:[~2014-01-27  9:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-23 14:49 [PATCH 00/10] drm/i915: Some less complex FBC fixes ville.syrjala
2014-01-23 14:49 ` [PATCH v3 01/10] drm/i915: Don't write IVB_FBC_RT_BASE ville.syrjala
2014-01-23 14:49 ` [PATCH 02/10] drm/i915: Don't set persistent FBC mode on ILK/SNB ville.syrjala
2014-01-23 14:49 ` [PATCH 03/10] drm/i915: Don't set DPFC_HT_MODIFY bit on CTG/ILK/SNB ville.syrjala
2014-01-23 14:49 ` [PATCH 04/10] drm/i915: Improve FBC plane defines a bit ville.syrjala
2014-01-23 14:49 ` [PATCH 05/10] drm/i915: Use 1/2 compression ratio limit for 16bpp on FBC2 ville.syrjala
2014-01-25 19:57   ` Daniel Vetter
2014-01-27  9:41     ` Ville Syrjälä
2014-01-23 14:49 ` [PATCH 06/10] drm/i915: Actually write the correct bits to DPFC_CONTROL on CTG ville.syrjala
2014-01-23 14:49 ` [PATCH 07/10] drm/i915: Don't preserve DPFC_CONTROL bits ILK/SNB ville.syrjala
2014-01-23 14:49 ` [PATCH v2 08/10] drm/i915: Kill most of the FBC register save/restore ville.syrjala
2014-01-23 14:49 ` [PATCH 09/10] drm/i915: Fix FBC1 enable message ville.syrjala
2014-01-23 14:49 ` [PATCH 10/10] drm/i915: Fix FBC_FENCE_OFF ville.syrjala
2014-01-23 19:47 ` [PATCH 00/10] drm/i915: Some less complex FBC fixes Chris Wilson
2014-01-25 19:59   ` Daniel Vetter
2014-01-26 14:33     ` Daniel Vetter
2014-01-26 14:35       ` Daniel Vetter
2014-01-27  9:40         ` Ville Syrjälä
2014-01-27  9:36       ` Ville Syrjälä [this message]

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=20140127093634.GM9454@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox