[vlc-devel] [PATCH 1/7] direct3d11: unmap the texture before it's displayed

[Steve Lhomme]

On Thu, Oct 15, 2015 at 7:47 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-10-15 20:04, Steve Lhomme a écrit :
>>
>> From: Steve Lhomme <robux4 at gmail.com>
>>
>> to avoid such issue: D3D11 ERROR: ID3D11DeviceContext::DrawIndexed:
>> Draw cannot be invoked while a bound Resource is currently mapped. The
>> Resource bound at Pixel Shader Resource slot (0) is still mapped. [
>> EXECUTION ERROR #364: DEVICE_DRAW_BOUND_RESOURCE_MAPPED]
>>
>> the picture_t unlock callback is called after the picture_t is displayed
>> ---
>>  modules/video_output/msw/direct3d11.c | 17 ++++++++++++++---
>>  1 file changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/modules/video_output/msw/direct3d11.c
>> b/modules/video_output/msw/direct3d11.c
>> index ccb7ea6..36888ed 100644
>> --- a/modules/video_output/msw/direct3d11.c
>> +++ b/modules/video_output/msw/direct3d11.c
>> @@ -139,6 +139,7 @@ static void Direct3D11DestroyPool(vout_display_t *);
>>  static void DestroyDisplayPicture(picture_t *);
>>  static void DestroyDisplayPoolPicture(picture_t *);
>>  static int  Direct3D11MapTexture(picture_t *);
>> +static int  Direct3D11UnmapTexture(picture_t *);
>>  static void Direct3D11DeleteRegions(int, picture_t **);
>>  static int Direct3D11MapSubpicture(vout_display_t *, int *,
>> picture_t ***, subpicture_t *);
>>
>> @@ -786,6 +787,9 @@ static void Display(vout_display_t *vd, picture_t
>> *picture, subpicture_t *subpic
>>
>>      ID3D11DeviceContext_ClearDepthStencilView(sys->d3dcontext,
>> sys->d3ddepthStencilView, D3D11_CLEAR_DEPTH | D3D11_CLEAR_STENCIL,
>> 1.0f, 0);
>>
>> +    if (picture->format.i_chroma != VLC_CODEC_D3D11_OPAQUE)
>> +        Direct3D11UnmapTexture(picture);
>
>
> Don't unmap picture buffers. If there is still more than one reference, this
> will obivously lead to a crash. If you can't render mapped buffers, you
> can't do direct rendering.

This is not direct rendering, this is the regular plane writing in the
display picture_t pool.

Now I don't understand why the lock/unlock is done between each
prepare/display attempt but the buffer is locked (for writing) until
the display is done. That seems counter intuitive. The split between
prepare and display would imply that it only needs to be locked during
preparation and display just throws the buffer to the screen.

> --
> Rémi Denis-Courmont
> http://www.remlab.net/