On 2/22/19 10:30 AM, Boris Brezillon wrote:
> On Thu, 21 Feb 2019 23:29:53 +0100
> Boris Brezillon <boris.brezil...@collabora.com> wrote:
>
>> Christian, Marek,
>>
>> On Wed, 30 Jan 2019 05:28:14 +0100
>> Marek Vasut <ma...@denx.de> wrote:
>>
>>> From: Christian Gmeiner <christian.gmei...@gmail.com>
>>>
>>> A pipe_resource can be shared by all the pipe_context's hanging off the
>>> same pipe_screen.
>>
>> We seem to be impacted by the problem you're fixing here, but, while
>> this patch definitely make things much better, the problem does not
>> seem to be entirely fixed (at least in our case).
>>
>> A bit more context: we have Qt App using QtWebEngine to render html
>> content. When we call QtWebEngine::initialize(), which as for effect
>> to allow shared GL contexts, we sometimes notice that part of the web
>> page is mis-rendered. That does not happen when we omit the
>> QtWebEngine::initialize() call.
>> As said above, this patch make those rendering issues less likely to
>> happen, but we still have the problem from time to time. So I thought
>> I'd share my guesses about what could cause these issues before
>> debugging it further.
>>
>> First thing I noticed: I couldn't reproduce the problem with [1]
>> applied (+ a tiny change forcing CPU-based tiling no matter the size of
>> the region to tile/untile). So, my guess is that it's related to how we
>> handle GPU-based tiling/untiling.
>> Also noticed that we're testing the rsc->status here [2] without the
>> screen->lock held, and there might be a race with another thread calling
>> resource_used(). We might also lack a resource_read(ctx, &src->base)
>> here [3]. But even after fixing those problems, the rendering issues
>> are not gone.
>
> I tested again with the following diff applied on top of your patch, and
> the remaining rendering issues we had seem to be gone (don't know what I
> messed up in my previous tests :-/).
>
> --->8---
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index fc4f65dbeee1..b8c8b96a6f72 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -729,6 +729,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
>
> etna_submit_rs_state(ctx, ©_to_screen);
> resource_written(ctx, &dst->base);
> + resource_read(ctx, &src->base);
> dst->seqno++;
> dst->levels[blit_info->dst.level].ts_valid = false;
> ctx->dirty |= ETNA_DIRTY_DERIVE_TS;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index a3013e624ead..e4b2ac605e63 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -356,6 +356,7 @@ etna_transfer_map(struct pipe_context *pctx, struct
> pipe_resource *prsc,
> * transfers without a temporary resource.
> */
> if (trans->rsc || !(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
> + struct etna_screen *screen = ctx->screen;
> uint32_t prep_flags = 0;
>
> /*
> @@ -364,11 +365,13 @@ etna_transfer_map(struct pipe_context *pctx, struct
> pipe_resource *prsc,
> * current GPU usage (reads must wait for GPU writes, writes must have
> * exclusive access to the buffer).
> */
> + mtx_lock(&screen->lock);
> if ((trans->rsc && (etna_resource(trans->rsc)->status &
> ETNA_PENDING_WRITE)) ||
> (!trans->rsc &&
> (((usage & PIPE_TRANSFER_READ) && (rsc->status &
> ETNA_PENDING_WRITE)) ||
> ((usage & PIPE_TRANSFER_WRITE) && rsc->status))))
> pctx->flush(pctx, NULL, 0);
> + mtx_unlock(&screen->lock);
>
> if (usage & PIPE_TRANSFER_READ)
> prep_flags |= DRM_ETNA_PREP_READ;
>
On iMX6Q
Tested-by: Marek Vasut <ma...@denx.de>
with multiple custom applications. I don't see any breakage.
--
Best regards,
Marek Vasut
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
