From: Samuel Pitoiset <samuel.pitoiset-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
mesa-dev-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: mesa-stable-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH] nouveau: make sure there's always room to emit a fence
Date: Mon, 5 Oct 2015 21:51:50 +0200 [thread overview]
Message-ID: <5612D4D6.3080108@gmail.com> (raw)
In-Reply-To: <1444072900-10104-1-git-send-email-imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
On 10/05/2015 09:21 PM, Ilia Mirkin wrote:
> I started seeing a lot of situations on nv30 where fence emission
> wouldn't fit into the previous buffer (causing assertions). This ensures
> that whenever checking for space, we always leave a bit of extra room
> for the fence emission commands. Adjusts the nv30 and nvc0 fence
> emission logic to bypass the space checking as well.
>
> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
> Cc: mesa-stable@lists.freedesktop.org
> ---
> src/gallium/drivers/nouveau/nouveau_winsys.h | 2 ++
> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 4 +++-
> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++-
> 4 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nouveau_winsys.h b/src/gallium/drivers/nouveau/nouveau_winsys.h
> index 389a229..a44fd3e 100644
> --- a/src/gallium/drivers/nouveau/nouveau_winsys.h
> +++ b/src/gallium/drivers/nouveau/nouveau_winsys.h
> @@ -24,6 +24,8 @@ PUSH_AVAIL(struct nouveau_pushbuf *push)
> static inline bool
> PUSH_SPACE(struct nouveau_pushbuf *push, uint32_t size)
> {
> + /* Provide a buffer so that fences always have room to be emitted */
> + size += 8;
> if (PUSH_AVAIL(push) < size)
> return nouveau_pushbuf_space(push, size, 0, 0) == 0;
> return true;
> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> index 39267b3..335c163 100644
> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> @@ -347,7 +347,9 @@ nv30_screen_fence_emit(struct pipe_screen *pscreen, uint32_t *sequence)
>
> *sequence = ++screen->base.fence.sequence;
>
> - BEGIN_NV04(push, NV30_3D(FENCE_OFFSET), 2);
> + assert(PUSH_AVAIL(push) >= 3);
> + PUSH_DATA (push, NV30_3D_FENCE_OFFSET |
> + (2 /* size */ << 18) | (7 /* subchan */ << 13));
Is there some other places where we do something like this?
If so, maybe we should introduce NV30_FIFO_PKHDR_SQ.
> PUSH_DATA (push, 0);
> PUSH_DATA (push, *sequence);
> }
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> index 6012ff6..812b246 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> @@ -388,6 +388,7 @@ nv50_screen_fence_emit(struct pipe_screen *pscreen, u32 *sequence)
> /* we need to do it after possible flush in MARK_RING */
> *sequence = ++screen->base.fence.sequence;
>
> + assert(PUSH_AVAIL(push) >= 5);
> PUSH_DATA (push, NV50_FIFO_PKHDR(NV50_3D(QUERY_ADDRESS_HIGH), 4));
> PUSH_DATAh(push, screen->fence.bo->offset);
> PUSH_DATA (push, screen->fence.bo->offset);
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> index 32da76c..afd91e6 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> @@ -537,7 +537,8 @@ nvc0_screen_fence_emit(struct pipe_screen *pscreen, u32 *sequence)
> /* we need to do it after possible flush in MARK_RING */
> *sequence = ++screen->base.fence.sequence;
>
> - BEGIN_NVC0(push, NVC0_3D(QUERY_ADDRESS_HIGH), 4);
> + assert(PUSH_AVAIL(push) >= 5);
> + PUSH_DATA (push, NVC0_FIFO_PKHDR_SQ(NVC0_3D(QUERY_ADDRESS_HIGH), 4));
> PUSH_DATAh(push, screen->fence.bo->offset);
> PUSH_DATA (push, screen->fence.bo->offset);
> PUSH_DATA (push, *sequence);
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
prev parent reply other threads:[~2015-10-05 19:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 19:21 [PATCH] nouveau: make sure there's always room to emit a fence Ilia Mirkin
[not found] ` <1444072900-10104-1-git-send-email-imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-10-05 19:51 ` Samuel Pitoiset [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=5612D4D6.3080108@gmail.com \
--to=samuel.pitoiset-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org \
--cc=mesa-dev-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=mesa-stable-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.