Re: [Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2

2014-01-23 Thread Christian König
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

Re: [Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2

2014-01-22 Thread 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 deathsim...@vodafone.de wrote: Yeah, probably because XBMC still (incorrectly) calls the map function only once. Putting the flush into

[Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2

2014-01-13 Thread Christian König
From: Marek Olšák marek.ol...@amd.com 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,

Re: [Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2

2014-01-13 Thread Marek Olšák
This patch doesn't fix the bug. :( Marek On Mon, Jan 13, 2014 at 2:55 PM, Christian König deathsim...@vodafone.de wrote: From: Marek Olšák marek.ol...@amd.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73191 When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which

Re: [Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2

2014-01-13 Thread Christian König
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