dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: daniel.thompson@linaro.org, daniel.vetter@ffwll.ch,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: Use CPU mapping for userspace dma-buf mmap()
Date: Thu, 6 Aug 2015 15:17:10 +0200	[thread overview]
Message-ID: <20150806131710.GQ17734@phenom.ffwll.local> (raw)
In-Reply-To: <55C26DA9.9020907@intel.com>

On Wed, Aug 05, 2015 at 05:10:17PM -0300, Tiago Vignatti wrote:
> On 08/05/2015 04:08 AM, Daniel Vetter wrote:
> >On Tue, Aug 04, 2015 at 06:30:25PM -0300, Tiago Vignatti wrote:
> >Nah they don't have to be equal since the problem isn't that nothing goes
> >out to memory where the display can see it, but usually only parts of it.
> >I.e. you need to change your test to
> >- draw black screen (it starts that way so nothing to do really), grab crtc
> >- draw white screen and make sure you flush correctly, don't bother with
> >   crc (we can't test for inequality
> >   because collisions are too easy)
> >- draw black screen again without flushing, grab crc
> >
> >Then assert that your two crc will be inequal (which they shouldn't be
> >because some cachelines will still be stuck). Maybe also add a delay
> >somewhere so you can see the cacheline dirt pattern, it's very
> >characteristic.
> 
> Cool, I've got it now. The test below makes the cachelines dirt, requiring
> them to get flushed correctly -- I'll work on it now. Should we add that
> kind of test somewhere in igt BTW?

Yeah if you expect me to merge dma-buf mmap with the begin/end stuff I'll
ask for an igt for it ;-)

> PS: I had an issue with the original kms_pwrite_crc which returns frequent
> fails. Paulo helped though and showed me that pwrite is currently broken:
> https://bugs.freedesktop.org/show_bug.cgi?id=86422

If you do dma-buf mmap with begin/end it should work, since in there we'll
just to manual range-based clflushing.
-Daniel


> 
> Tiago
> 
> diff --git a/tests/kms_pwrite_crc.c b/tests/kms_pwrite_crc.c
> index 05b9e38..419b46d 100644
> --- a/tests/kms_pwrite_crc.c
> +++ b/tests/kms_pwrite_crc.c
> @@ -50,6 +50,20 @@ typedef struct {
>  	uint32_t devid;
>  } data_t;
> 
> +static char *dmabuf_mmap_framebuffer(int drm_fd, struct igt_fb *fb)
> +{
> +	int dma_buf_fd;
> +	char *ptr = NULL;
> +
> +	dma_buf_fd = prime_handle_to_fd(drm_fd, fb->gem_handle);
> +	igt_assert(errno == 0);
> +
> +	ptr = mmap(NULL, fb->size, PROT_READ | PROT_WRITE, MAP_SHARED, dma_buf_fd,
> 0);
> +	igt_assert(ptr != MAP_FAILED);
> +
> +	return ptr;
> +}
> +
>  static void test(data_t *data)
>  {
>  	igt_display_t *display = &data->display;
> @@ -57,6 +71,7 @@ static void test(data_t *data)
>  	struct igt_fb *fb = &data->fb[1];
>  	drmModeModeInfo *mode;
>  	cairo_t *cr;
> +	char *ptr;
>  	uint32_t caching;
>  	void *buf;
>  	igt_crc_t crc;
> @@ -67,6 +82,8 @@ static void test(data_t *data)
>  	igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
>  		      DRM_FORMAT_XRGB8888, LOCAL_DRM_FORMAT_MOD_NONE, fb);
> 
> +	ptr = dmabuf_mmap_framebuffer(data->drm_fd, fb);
> +
>  	cr = igt_get_cairo_ctx(data->drm_fd, fb);
>  	igt_paint_test_pattern(cr, fb->width, fb->height);
>  	cairo_destroy(cr);
> @@ -83,11 +100,11 @@ static void test(data_t *data)
>  	caching = gem_get_caching(data->drm_fd, fb->gem_handle);
>  	igt_assert(caching == I915_CACHING_NONE || caching ==
> I915_CACHING_DISPLAY);
> 
> -	/* use pwrite to make the other fb all white too */
> +	/* use dmabuf pointer to make the other fb all white too */
>  	buf = malloc(fb->size);
>  	igt_assert(buf != NULL);
>  	memset(buf, 0xff, fb->size);
> -	gem_write(data->drm_fd, fb->gem_handle, 0, buf, fb->size);
> +	memcpy(ptr, buf, fb->size);
>  	free(buf);
> 
>  	/* and flip to it */
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-08-06 13:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31 20:42 [PATCH 0/2] mmap on the dma-buf directly Tiago Vignatti
2015-07-31 20:42 ` [PATCH 1/2] drm/i915: Use CPU mapping for userspace dma-buf mmap() Tiago Vignatti
2015-07-31 21:02   ` [Intel-gfx] " Chris Wilson
2015-08-04 21:30     ` Tiago Vignatti
2015-08-05  7:08       ` Daniel Vetter
2015-08-05 20:10         ` Tiago Vignatti
2015-08-06 13:17           ` Daniel Vetter [this message]
2015-07-31 20:42 ` [PATCH 2/2] drm: prime: Honour O_RDWR during prime-handle-to-fd Tiago Vignatti

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=20150806131710.GQ17734@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=daniel.thompson@linaro.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tiago.vignatti@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox