linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Vasilev, Oleg" <oleg.vasilev@intel.com>
To: "liviu.dudau@arm.com" <liviu.dudau@arm.com>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"brian.starkey@arm.com" <brian.starkey@arm.com>,
	"hamohammed.sa@gmail.com" <hamohammed.sa@gmail.com>,
	"rodrigosiqueiramelo@gmail.com" <rodrigosiqueiramelo@gmail.com>,
	"contact@emersion.fr" <contact@emersion.fr>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V3 4/5] drm/vkms: Compute CRC without change input data
Date: Tue, 9 Jul 2019 10:05:22 +0000	[thread overview]
Message-ID: <3b7a5f6ae167517ff37b586b02e3faae38bf6cc0.camel@intel.com> (raw)
In-Reply-To: <ea7e3a0daa4ee502d8ec67a010120d53f88fa06b.1561491964.git.rodrigosiqueiramelo@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3346 bytes --]

On Tue, 2019-06-25 at 22:38 -0300, Rodrigo Siqueira wrote:
> The compute_crc() function is responsible for calculating the
> framebuffer CRC value; due to the XRGB format, this function has to
> ignore the alpha channel during the CRC computation. Therefore,
> compute_crc() set zero to the alpha channel directly in the input
> framebuffer, which is not a problem since this function receives a
> copy
> of the original buffer. However, if we want to use this function in a
> context without a buffer copy, it will change the initial value. This
> patch makes compute_crc() calculate the CRC value without modifying
> the
> input framebuffer.
> 
> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> ---
>  drivers/gpu/drm/vkms/vkms_composer.c | 31 +++++++++++++++++---------
> --
>  1 file changed, 19 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 51a270514219..8126aa0f968f 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -6,33 +6,40 @@
>  #include <drm/drm_atomic_helper.h>
>  #include <drm/drm_gem_framebuffer_helper.h>
>  
> +static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
> +				 const struct vkms_composer *composer)
> +{
> +	int src_offset = composer->offset + (y * composer->pitch)
> +					  + (x * composer->cpp);
> +
> +	return *(u32 *)&buffer[src_offset];
> +}
> +
>  /**
>   * compute_crc - Compute CRC value on output frame
>   *
> - * @vaddr_out: address to final framebuffer
> + * @vaddr: address to final framebuffer
>   * @composer: framebuffer's metadata
>   *
>   * returns CRC value computed using crc32 on the visible portion of
>   * the final framebuffer at vaddr_out
>   */
> -static uint32_t compute_crc(void *vaddr_out, struct vkms_composer
> *composer)
> +static uint32_t compute_crc(const u8 *vaddr,
> +			    const struct vkms_composer *composer)
>  {
> -	int i, j, src_offset;
> +	int x, y;
>  	int x_src = composer->src.x1 >> 16;
>  	int y_src = composer->src.y1 >> 16;
>  	int h_src = drm_rect_height(&composer->src) >> 16;
>  	int w_src = drm_rect_width(&composer->src) >> 16;
> -	u32 crc = 0;
> +	u32 crc = 0, pixel = 0;
>  
> -	for (i = y_src; i < y_src + h_src; ++i) {
> -		for (j = x_src; j < x_src + w_src; ++j) {
> -			src_offset = composer->offset
> -				     + (i * composer->pitch)
> -				     + (j * composer->cpp);
> +	for (y = y_src; y < y_src + h_src; ++y) {
> +		for (x = x_src; x < x_src + w_src; ++x) {
>  			/* XRGB format ignores Alpha channel */
> -			memset(vaddr_out + src_offset + 24, 0,  8);
Hi Rodgrigo,

Do I understand correctly, that previous version with memset was
actually zeroing out the whole fb, except first 24 bytes? On the first
iteration bytes 24..32 would be zeroed, on the second 25..33, etc.

Should we add more CRC tests to IGT, so we can catch such mistakes? For
example, compute CRC, than augment random pixel and assert that CRC
changed.

Oleg
> -			crc = crc32_le(crc, vaddr_out + src_offset,
> -				       sizeof(u32));
> +			pixel = get_pixel_from_buffer(x, y, vaddr,
> composer);
> +			bitmap_clear((void *)&pixel, 0, 8);
> +			crc = crc32_le(crc, (void *)&pixel,
> sizeof(u32));
>  		}
>  	}
>  

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3261 bytes --]

  reply	other threads:[~2019-07-09 10:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-26  1:35 [PATCH V3 0/5] drm/vkms: Introduces writeback support Rodrigo Siqueira
2019-06-26  1:36 ` [PATCH V3 1/5] drm/vkms: Avoid assigning 0 for possible_crtc Rodrigo Siqueira
2019-07-11  8:06   ` Daniel Vetter
2019-06-26  1:37 ` [PATCH V3 2/5] drm/vkms: Rename vkms_crc.c into vkms_composer.c Rodrigo Siqueira
2019-07-11  8:10   ` Daniel Vetter
2019-06-26  1:37 ` [PATCH V3 3/5] drm/vkms: Decouple crc operations from composer Rodrigo Siqueira
2019-07-11  8:19   ` Daniel Vetter
2019-07-11  8:23     ` Simon Ser
2019-06-26  1:38 ` [PATCH V3 4/5] drm/vkms: Compute CRC without change input data Rodrigo Siqueira
2019-07-09 10:05   ` Vasilev, Oleg [this message]
2019-07-11  8:21   ` Daniel Vetter
2019-07-11  8:28     ` Simon Ser
2019-07-11  9:00       ` Daniel Vetter
2019-07-12  3:14     ` Rodrigo Siqueira
2019-07-16  8:37       ` Daniel Vetter
2019-07-17  2:30         ` Rodrigo Siqueira
2019-06-26  1:39 ` [PATCH V3 5/5] drm/vkms: Add support for writeback Rodrigo Siqueira
2019-07-11  8:34   ` Daniel Vetter
2019-07-12  3:37     ` Rodrigo Siqueira
2019-07-16  8:40       ` Daniel Vetter

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=3b7a5f6ae167517ff37b586b02e3faae38bf6cc0.camel@intel.com \
    --to=oleg.vasilev@intel.com \
    --cc=brian.starkey@arm.com \
    --cc=contact@emersion.fr \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hamohammed.sa@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=rodrigosiqueiramelo@gmail.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;
as well as URLs for NNTP newsgroup(s).