From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerome Glisse <j.glisse@gmail.com>
Subject: Re: Update: UVD status on loongson 3a platform
Date: Thu, 5 Sep 2013 15:29:52 -0400
Message-ID: <20130905191704.GA3621@gmail.com>
References: <CAGXxSxX6wAbKA-K-vWFTrrUA0MwHk85dgTFgeKMomY-FnD+wWw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org>
Content-Disposition: inline
In-Reply-To: <CAGXxSxX6wAbKA-K-vWFTrrUA0MwHk85dgTFgeKMomY-FnD+wWw@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: Chen Jie <chenj@lemote.com>
Cc: mesa-dev@lists.freedesktop.org, =?utf-8?B?5LiB5rGo5rGf?= <dingmj@lemote.com>, =?utf-8?B?546L6ZSQ?= <wangr@lemote.com>, dri-devel@lists.freedesktop.org, =?utf-8?B?6ZmI5Y2O5omN?= <chenhc@lemote.com>
List-Id: dri-devel@lists.freedesktop.org

On Thu, Sep 05, 2013 at 10:14:32PM +0800, Chen Jie wrote:
> Hi all,
> 
> This thread is about
> http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
> 
> We recently find some interesting thing about UVD based playback on
> loongson 3a plaform, and also find a way to fix the problem.
> 
> First, we find memcpy in [mesa]src/gallium/drivers/radeon/radeon_uvd.c
> caused the problem:
> * If memcpy is implemented though 16B or 8B load/store instructions,
> it will normally caused video mosaic. When insert a memcmp after the
> copying code in memcpy, it will report the src and dest are not equal.
> * If memcpy use 1B load/store instructions only, the memcmp after the
> copying code reports equal.
> 
> Then we find the following changeset fixs out problem:
> 
> diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
> b/src/gallium/drivers/radeon/radeon_uvd.c
> index 2f98de2..f9599b6 100644
> --- a/src/gallium/drivers/radeon/radeon_uvd.c
> +++ b/src/gallium/drivers/radeon/radeon_uvd.c
> @@ -162,7 +162,7 @@ static bool create_buffer(struct ruvd_decoder *dec,
>    unsigned size)
>  {
>   buffer->buf = dec->ws->buffer_create(dec->ws, size, 4096, false,
> -     RADEON_DOMAIN_GTT | RADEON_DOMAIN_VRAM);
> +     RADEON_DOMAIN_GTT);
>   if (!buffer->buf)
>   return false;
> 
> The VRAM is mapped to an uncached area in out platform, so, my
> question is what could go wrong while using  >4B load/store
> instructions in UVD workflow? Any idea?
> 

How do you map the VRAM into user process mapping ? ie do you have
something like Intel PAT or something like MTRR or something else.

In other word, can you map into process address space a region of
io memory (GPU VRAM in this case) and mark it as uncached so that
none of the access to it goes through CPU cache.

Cheers,
Jerome