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 flushe
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 s
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
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
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
