Re: [Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2
Yeah, talked with them last week, just didn't had time to test/fix the implementation. Basically they fixed the map/unmap issue in one of their nightly builds and now we need to confirm that the patch below with this nightly build fixes the issue. Additionally to the patch below which flushes the VDPAU pipe on "map" we also need a patch to flush the GL pipe on "unmap", otherwise UVD would happily start decoding the next frame into the buffer while the GL context is still waiting for the flush. It's the next thing on my todo list, but other issues currently have priority. Christian. Am 23.01.2014 01:38, schrieb Marek Olšák: Is there any news from the XBMC team? I think we should fix this sooner rather than later. Marek On Mon, Jan 13, 2014 at 3:29 PM, Christian König wrote: Yeah, probably because XBMC still (incorrectly) calls the map function only once. Putting the flush into vlVdpResolveDelayedRendering solves the problem because it's called the next time somebody starts rendering, but it's way to late at this point. Need to sync up with the XBMC devs on this. Christian. Am 13.01.2014 15:20, schrieb Marek Olšák: This patch doesn't fix the bug. :( Marek On Mon, Jan 13, 2014 at 2:55 PM, Christian König wrote: From: Marek Olšák Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73191 When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which always flushes the context in the winsys if the buffer being mapped is busy. Since I added handling of DISCARD_RANGE, DONTBLOCK has had no effect when combined with DISCARD_RANGE and I think the context isn't flushed anywhere else, so no commands are submitted to the GPU until the IB is full, which takes a lot of frames. Using DISCARD_RANGE is not the only way to trigger this bug. The other way is to reallocate the vertex buffer before every upload. BTW, I'm not sure if this is the right place for flushing, but it does fix the bug. v2 (chk): move the flush to the right place. Signed-off-by: Christian König --- src/gallium/state_trackers/vdpau/output.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/state_trackers/vdpau/output.c b/src/gallium/state_trackers/vdpau/output.c index e4e1433..7ff4196 100644 --- a/src/gallium/state_trackers/vdpau/output.c +++ b/src/gallium/state_trackers/vdpau/output.c @@ -736,6 +736,7 @@ struct pipe_resource *vlVdpOutputSurfaceGallium(VdpOutputSurface surface) pipe_mutex_lock(vlsurface->device->mutex); vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL); + vlsurface->device->context->flush(vlsurface->device->context, NULL, 0); pipe_mutex_unlock(vlsurface->device->mutex); return vlsurface->surface->texture; -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2
Is there any news from the XBMC team? I think we should fix this sooner rather than later. Marek On Mon, Jan 13, 2014 at 3:29 PM, Christian König wrote: > Yeah, probably because XBMC still (incorrectly) calls the map function only > once. > > Putting the flush into vlVdpResolveDelayedRendering solves the problem > because it's called the next time somebody starts rendering, but it's way to > late at this point. > > Need to sync up with the XBMC devs on this. > > Christian. > > Am 13.01.2014 15:20, schrieb Marek Olšák: > >> This patch doesn't fix the bug. :( >> >> Marek >> >> On Mon, Jan 13, 2014 at 2:55 PM, Christian König >> wrote: >>> >>> From: Marek Olšák >>> >>> Bugzilla: >>> https://bugs.freedesktop.org/show_bug.cgi?id=73191 >>> >>> When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which >>> always >>> flushes the context in the winsys if the buffer being mapped is busy. >>> Since >>> I added handling of DISCARD_RANGE, DONTBLOCK has had no effect when >>> combined >>> with DISCARD_RANGE and I think the context isn't flushed anywhere else, >>> so no commands are submitted to the GPU until the IB is full, which takes >>> a lot of frames. >>> >>> Using DISCARD_RANGE is not the only way to trigger this bug. The other >>> way >>> is to reallocate the vertex buffer before every upload. >>> >>> BTW, I'm not sure if this is the right place for flushing, but it does >>> fix >>> the bug. >>> >>> v2 (chk): move the flush to the right place. >>> >>> Signed-off-by: Christian König >>> --- >>> src/gallium/state_trackers/vdpau/output.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/src/gallium/state_trackers/vdpau/output.c >>> b/src/gallium/state_trackers/vdpau/output.c >>> index e4e1433..7ff4196 100644 >>> --- a/src/gallium/state_trackers/vdpau/output.c >>> +++ b/src/gallium/state_trackers/vdpau/output.c >>> @@ -736,6 +736,7 @@ struct pipe_resource >>> *vlVdpOutputSurfaceGallium(VdpOutputSurface surface) >>> >>> pipe_mutex_lock(vlsurface->device->mutex); >>> vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL); >>> + vlsurface->device->context->flush(vlsurface->device->context, NULL, >>> 0); >>> pipe_mutex_unlock(vlsurface->device->mutex); >>> >>> return vlsurface->surface->texture; >>> -- >>> 1.8.1.2 >>> > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2
Yeah, probably because XBMC still (incorrectly) calls the map function only once. Putting the flush into vlVdpResolveDelayedRendering solves the problem because it's called the next time somebody starts rendering, but it's way to late at this point. Need to sync up with the XBMC devs on this. Christian. Am 13.01.2014 15:20, schrieb Marek Olšák: This patch doesn't fix the bug. :( Marek On Mon, Jan 13, 2014 at 2:55 PM, Christian König wrote: From: Marek Olšák Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73191 When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which always flushes the context in the winsys if the buffer being mapped is busy. Since I added handling of DISCARD_RANGE, DONTBLOCK has had no effect when combined with DISCARD_RANGE and I think the context isn't flushed anywhere else, so no commands are submitted to the GPU until the IB is full, which takes a lot of frames. Using DISCARD_RANGE is not the only way to trigger this bug. The other way is to reallocate the vertex buffer before every upload. BTW, I'm not sure if this is the right place for flushing, but it does fix the bug. v2 (chk): move the flush to the right place. Signed-off-by: Christian König --- src/gallium/state_trackers/vdpau/output.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/state_trackers/vdpau/output.c b/src/gallium/state_trackers/vdpau/output.c index e4e1433..7ff4196 100644 --- a/src/gallium/state_trackers/vdpau/output.c +++ b/src/gallium/state_trackers/vdpau/output.c @@ -736,6 +736,7 @@ struct pipe_resource *vlVdpOutputSurfaceGallium(VdpOutputSurface surface) pipe_mutex_lock(vlsurface->device->mutex); vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL); + vlsurface->device->context->flush(vlsurface->device->context, NULL, 0); pipe_mutex_unlock(vlsurface->device->mutex); return vlsurface->surface->texture; -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2
This patch doesn't fix the bug. :( Marek On Mon, Jan 13, 2014 at 2:55 PM, Christian König wrote: > From: Marek Olšák > > Bugzilla: > https://bugs.freedesktop.org/show_bug.cgi?id=73191 > > When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which always > flushes the context in the winsys if the buffer being mapped is busy. Since > I added handling of DISCARD_RANGE, DONTBLOCK has had no effect when combined > with DISCARD_RANGE and I think the context isn't flushed anywhere else, > so no commands are submitted to the GPU until the IB is full, which takes > a lot of frames. > > Using DISCARD_RANGE is not the only way to trigger this bug. The other way > is to reallocate the vertex buffer before every upload. > > BTW, I'm not sure if this is the right place for flushing, but it does fix > the bug. > > v2 (chk): move the flush to the right place. > > Signed-off-by: Christian König > --- > src/gallium/state_trackers/vdpau/output.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/gallium/state_trackers/vdpau/output.c > b/src/gallium/state_trackers/vdpau/output.c > index e4e1433..7ff4196 100644 > --- a/src/gallium/state_trackers/vdpau/output.c > +++ b/src/gallium/state_trackers/vdpau/output.c > @@ -736,6 +736,7 @@ struct pipe_resource > *vlVdpOutputSurfaceGallium(VdpOutputSurface surface) > > pipe_mutex_lock(vlsurface->device->mutex); > vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL); > + vlsurface->device->context->flush(vlsurface->device->context, NULL, 0); > pipe_mutex_unlock(vlsurface->device->mutex); > > return vlsurface->surface->texture; > -- > 1.8.1.2 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
