from:"Nayan Deshmukh"

Re: [Mesa-dev] [PATCH] r600_shader.c: fix indentation

2017-03-22 Thread Nayan Deshmukh

Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>

On Wed, Mar 22, 2017 at 9:28 PM, Julien Isorce <julien.iso...@gmail.com> wrote:
> Introduced by ad13bd2e51a5dc01b0f8a0eb927022f0deac0a0c
>
> Signed-off-by: Julien Isorce <jiso...@oblong.com>
> ---
>  src/gallium/drivers/r600/r600_shader.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_shader.c 
> b/src/gallium/drivers/r600/r600_shader.c
> index 8446502..41fabf3 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -1113,8 +1113,8 @@ static int allocate_system_value_inputs(struct 
> r600_shader_ctx *ctx, int gpr_off
>
> interpolate = 
> ctx->info.input_interpolate[inst->Src[0].Register.Index];
> k = eg_get_interpolator_index(interpolate, 
> location);
> -if (k >= 0)
> -ctx->eg_interpolators[k].enabled = 
> true;
> +   if (k >= 0)
> +   ctx->eg_interpolators[k].enabled = 
> true;
> }
> } else if (parse.FullToken.Token.Type == 
> TGSI_TOKEN_TYPE_DECLARATION) {
> struct tgsi_full_declaration *d = 
> 
> @@ -1210,8 +1210,8 @@ static int evergreen_gpr_count(struct r600_shader_ctx 
> *ctx)
>
> interpolate = 
> ctx->info.input_interpolate[inst->Src[0].Register.Index];
> k = eg_get_interpolator_index(interpolate, 
> location);
> -if (k >= 0)
> -ctx->eg_interpolators[k].enabled = 
> true;
> +   if (k >= 0)
> +   ctx->eg_interpolators[k].enabled = 
> true;
> }
> }
> }
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] st/va: remove assert for single slice

2017-03-21 Thread Nayan Deshmukh

we anyway allow for multiple slices

v2: do not remove assert to check for buf->size

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
Reviewed-by: Christian König <christian.koe...@amd.com>
---
 src/gallium/state_trackers/va/picture_mpeg12.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c 
b/src/gallium/state_trackers/va/picture_mpeg12.c
index 812e9e5..1e5a9c7 100644
--- a/src/gallium/state_trackers/va/picture_mpeg12.c
+++ b/src/gallium/state_trackers/va/picture_mpeg12.c
@@ -81,6 +81,6 @@ void vlVaHandleIQMatrixBufferMPEG12(vlVaContext *context, 
vlVaBuffer *buf)
 
 void vlVaHandleSliceParameterBufferMPEG12(vlVaContext *context, vlVaBuffer 
*buf)
 {
-   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2) && 
buf->num_elements == 1);
+   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2));
context->desc.mpeg12.num_slices += buf->num_elements;
 }
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vl: u_upload_alloc might fail to allocate buffer in bicubic filter

2017-02-22 Thread Nayan Deshmukh

Can you please push the patch.

On Thu, Feb 23, 2017 at 1:46 AM, Marek Olšák <mar...@gmail.com> wrote:
> OK sounds good.
>
> Reviewed-by: Marek Olšák <marek.ol...@amd.com>
>
> Marek
>
> On Wed, Feb 22, 2017 at 9:16 PM, Nayan Deshmukh
> <nayan26deshm...@gmail.com> wrote:
>> On Thu, Feb 23, 2017 at 1:34 AM, Marek Olšák <mar...@gmail.com> wrote:
>>> It would be better to return from the function in that case.
>>>
>> We can still execute it as it will display the video properly though
>> the edges will be
>> a bit jagged but it won't be much noticeable in most cases.
>>
>> Regards,
>> Nayan
>>
>>
>>> Marek
>>>
>>> On Wed, Feb 22, 2017 at 9:25 AM, Nayan Deshmukh
>>> <nayan26deshm...@gmail.com> wrote:
>>>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>>>> ---
>>>>  src/gallium/auxiliary/vl/vl_bicubic_filter.c | 8 +---
>>>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/src/gallium/auxiliary/vl/vl_bicubic_filter.c 
>>>> b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
>>>> index 570f153..275dd2a 100644
>>>> --- a/src/gallium/auxiliary/vl/vl_bicubic_filter.c
>>>> +++ b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
>>>> @@ -416,14 +416,16 @@ vl_bicubic_filter_render(struct vl_bicubic_filter 
>>>> *filter,
>>>> viewport.scale[2] = 1;
>>>>
>>>> struct pipe_constant_buffer cb = {};
>>>> -   float *ptr;
>>>> +   float *ptr = NULL;
>>>>
>>>> u_upload_alloc(filter->pipe->const_uploader, 0, 2 * sizeof(float), 256,
>>>>_offset, , (void**));
>>>> cb.buffer_size = 2 * sizeof(float);
>>>>
>>>> -   ptr[0] = 0.5f/viewport.scale[0];
>>>> -   ptr[1] = 0.5f/viewport.scale[1];
>>>> +   if (ptr) {
>>>> +  ptr[0] = 0.5f/viewport.scale[0];
>>>> +  ptr[1] = 0.5f/viewport.scale[1];
>>>> +   }
>>>> u_upload_unmap(filter->pipe->const_uploader);
>>>>
>>>> memset(_state, 0, sizeof(fb_state));
>>>> --
>>>> 2.9.3
>>>>
>>>> ___
>>>> mesa-dev mailing list
>>>> mesa-dev@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vl: u_upload_alloc might fail to allocate buffer in bicubic filter

2017-02-22 Thread Nayan Deshmukh

On Thu, Feb 23, 2017 at 1:34 AM, Marek Olšák <mar...@gmail.com> wrote:
> It would be better to return from the function in that case.
>
We can still execute it as it will display the video properly though
the edges will be
a bit jagged but it won't be much noticeable in most cases.

Regards,
Nayan


> Marek
>
> On Wed, Feb 22, 2017 at 9:25 AM, Nayan Deshmukh
> <nayan26deshm...@gmail.com> wrote:
>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>> ---
>>  src/gallium/auxiliary/vl/vl_bicubic_filter.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/vl/vl_bicubic_filter.c 
>> b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
>> index 570f153..275dd2a 100644
>> --- a/src/gallium/auxiliary/vl/vl_bicubic_filter.c
>> +++ b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
>> @@ -416,14 +416,16 @@ vl_bicubic_filter_render(struct vl_bicubic_filter 
>> *filter,
>> viewport.scale[2] = 1;
>>
>> struct pipe_constant_buffer cb = {};
>> -   float *ptr;
>> +   float *ptr = NULL;
>>
>> u_upload_alloc(filter->pipe->const_uploader, 0, 2 * sizeof(float), 256,
>>_offset, , (void**));
>> cb.buffer_size = 2 * sizeof(float);
>>
>> -   ptr[0] = 0.5f/viewport.scale[0];
>> -   ptr[1] = 0.5f/viewport.scale[1];
>> +   if (ptr) {
>> +  ptr[0] = 0.5f/viewport.scale[0];
>> +  ptr[1] = 0.5f/viewport.scale[1];
>> +   }
>> u_upload_unmap(filter->pipe->const_uploader);
>>
>> memset(_state, 0, sizeof(fb_state));
>> --
>> 2.9.3
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] vl: u_upload_alloc might fail to allocate buffer in bicubic filter

2017-02-22 Thread Nayan Deshmukh

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/auxiliary/vl/vl_bicubic_filter.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_bicubic_filter.c 
b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
index 570f153..275dd2a 100644
--- a/src/gallium/auxiliary/vl/vl_bicubic_filter.c
+++ b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
@@ -416,14 +416,16 @@ vl_bicubic_filter_render(struct vl_bicubic_filter *filter,
viewport.scale[2] = 1;
 
struct pipe_constant_buffer cb = {};
-   float *ptr;
+   float *ptr = NULL;
 
u_upload_alloc(filter->pipe->const_uploader, 0, 2 * sizeof(float), 256,
   _offset, , (void**));
cb.buffer_size = 2 * sizeof(float);
 
-   ptr[0] = 0.5f/viewport.scale[0];
-   ptr[1] = 0.5f/viewport.scale[1];
+   if (ptr) {
+  ptr[0] = 0.5f/viewport.scale[0];
+  ptr[1] = 0.5f/viewport.scale[1];
+   }
u_upload_unmap(filter->pipe->const_uploader);
 
memset(_state, 0, sizeof(fb_state));
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] docs/releasing.html: reword "distro breaking changes" hunk

2017-02-20 Thread Nayan Deshmukh

Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>

On Tue, Feb 21, 2017 at 12:57 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> Suggested-by: Eric Engestrom <eric.engest...@imgtec.com>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
>  docs/releasing.html | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/docs/releasing.html b/docs/releasing.html
> index 048aa1f7a4..26daf505a5 100644
> --- a/docs/releasing.html
> +++ b/docs/releasing.html
> @@ -171,9 +171,9 @@ Now go to
>   href="https://bugs.freedesktop.org/editversions.cgi?action=addproduct=Mesa;
>  target="_parent">Bugzilla and add the new Mesa version X.Y.
>  
>  
> -Check for rare that there are no distribution breaking changes and revert 
> them
> -if needed. Extremely rare - we had only one case so far (see
> -commit 2ced8eb136528914e1bf4e000dea06a9d53c7e04).
> +Check that there are no distribution breaking changes and revert them if 
> needed.
> +For example: files being overwritten on install, etc. Happens extremely rare 
> -
> +we had only one case so far (see commit 
> 2ced8eb136528914e1bf4e000dea06a9d53c7e04).
>  
>  
>  Proceed to release -rc1.
> --
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: remove assert for single slice

2017-02-11 Thread Nayan Deshmukh

On Sat, Feb 11, 2017 at 12:00 AM, Andy Furniss <adf.li...@gmail.com> wrote:
> Nayan Deshmukh wrote:
>>
>> Hi Andy,
>>
>> I am attaching the patches.
>> Does it cause any difference in the corruption in this video?
>>
>> https://drive.google.com/drive/folders/0BxP5-S1t9VEEbkR4dWhTUFozV2s
>>
>
> Hi, it seems mpv and ffmpeg have been changing their vaapi code recently.
>
> With an old mpv the corruption is the same as without the patches.
>
> With git mpv the patches cause a segfault -
>
I will the see the changes in the code to see what's the problem.
Christian, please push the patch that you reviewed.

Regards,
Nayan
> Program received signal SIGSEGV, Segmentation fault.
> 0x710bbe8e in __memcpy_sse2_unaligned () from /lib/libc.so.6
> (gdb) bt
> #0  0x710bbe8e in __memcpy_sse2_unaligned () from /lib/libc.so.6
> #1  0x7fffe423f4e0 in ruvd_decode_bitstream (decoder=0x226dcb0,
> target=, picture=, num_buffers= out>, buffers=, sizes=) at radeon_uvd.c:1029
> #2  0x7fffe40f37cb in handleVASliceDataBufferType (buf=,
> context=0x2236290) at picture.c:323
> #3  vlVaRenderPicture (ctx=, context_id=,
> buffers=, num_buffers=) at picture.c:518
> #4  0x00cba28e in ff_vaapi_decode_issue ()
> #5  0x008f8dac in vaapi_mpeg2_end_frame ()
> #6  0x007635cc in decode_chunks ()
> #7  0x007648e7 in mpeg_decode_frame ()
> #8  0x008daa53 in avcodec_decode_video2 ()
> #9  0x008db780 in do_decode ()
> #10 0x008dc650 in avcodec_send_packet ()
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: remove assert for single slice

2017-02-10 Thread Nayan Deshmukh

Hi Andy,

I am attaching the patches.
Does it cause any difference in the corruption in this video?

   https://drive.google.com/drive/folders/0BxP5-S1t9VEEbkR4dWhTUFozV2s

Regards,
Nayan

On Fri, Feb 10, 2017 at 11:15 PM, Andy Furniss <adf.li...@gmail.com> wrote:
> Nayan Deshmukh wrote:
>
>>>> Any ideas why? I am attaching the diff for reference.
>>>
>>>
>>>
>>> Could be that the shader based decoder has a bug with multiple slices as
>>> well.
>>>
>> It could be. Andy can you test it with your hardware decoder to see if
>> its specific
>> to shader decoder.
>
>
> Can you re-send or attach anything you want me to try to the bug.
>
> The diff in here is too corrupt to apply.
>
> It's a long time since I used shader decode (on rv790 before it got uvd).
>
> IIRC there were samples that were a bit wrong - but then that was
> testing with vdpau.
>
>
From 4e99ae5a79c60ceae8d1942fc6a9b66704221452 Mon Sep 17 00:00:00 2001
From: Nayan Deshmukh <nayan26deshm...@gmail.com>
Date: Tue, 31 Jan 2017 10:45:20 +0530
Subject: [PATCH 1/2] st/va: remove assert for single slice

we anyway allow for multiple slices

v2: do not remove assert to check for buf->size

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/va/picture_mpeg12.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c b/src/gallium/state_trackers/va/picture_mpeg12.c
index 812e9e5..1e5a9c7 100644
--- a/src/gallium/state_trackers/va/picture_mpeg12.c
+++ b/src/gallium/state_trackers/va/picture_mpeg12.c
@@ -81,6 +81,6 @@ void vlVaHandleIQMatrixBufferMPEG12(vlVaContext *context, vlVaBuffer *buf)
 
 void vlVaHandleSliceParameterBufferMPEG12(vlVaContext *context, vlVaBuffer *buf)
 {
-   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2) && buf->num_elements == 1);
+   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2));
context->desc.mpeg12.num_slices += buf->num_elements;
 }
-- 
2.9.3

From 516c54ed7ab608f69fb50b554a28cc59015ddba7 Mon Sep 17 00:00:00 2001
From: Nayan Deshmukh <nayan26deshm...@gmail.com>
Date: Mon, 6 Feb 2017 00:37:03 +0530
Subject: [PATCH 2/2] st/va: use the slice size provided in
 VASliceParameterBuffer

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/va/picture.c| 19 +--
 src/gallium/state_trackers/va/picture_mpeg12.c | 11 +++
 src/gallium/state_trackers/va/va_private.h |  1 +
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c b/src/gallium/state_trackers/va/picture.c
index 82584ea..8e68e35 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -262,8 +262,10 @@ handleVASliceDataBufferType(vlVaContext *context, vlVaBuffer *buf)
 {
enum pipe_video_format format;
unsigned num_buffers = 0;
-   void * const *buffers[2];
-   unsigned sizes[2];
+   void * const *buffers[context->desc.mpeg12.num_slices + 1];
+   unsigned sizes[context->desc.mpeg12.num_slices + 1];
+   char *cur;
+   int i;
static const uint8_t start_code_h264[] = { 0x00, 0x00, 0x01 };
static const uint8_t start_code_h265[] = { 0x00, 0x00, 0x01 };
static const uint8_t start_code_vc1[] = { 0x00, 0x00, 0x01, 0x0d };
@@ -306,9 +308,12 @@ handleVASliceDataBufferType(vlVaContext *context, vlVaBuffer *buf)
   break;
}
 
-   buffers[num_buffers] = buf->data;
-   sizes[num_buffers] = buf->size;
-   ++num_buffers;
+   cur = buf->data;
+   for (i = 0; i < context->desc.mpeg12.num_slices; ++i) {
+  buffers[i] = cur;
+  cur = cur + context->sizes[i];
+   }
+
 
if (context->needs_begin_frame) {
   context->decoder->begin_frame(context->decoder, context->target,
@@ -316,7 +321,8 @@ handleVASliceDataBufferType(vlVaContext *context, vlVaBuffer *buf)
   context->needs_begin_frame = false;
}
context->decoder->decode_bitstream(context->decoder, context->target, >desc.base,
-  num_buffers, (const void * const*)buffers, sizes);
+  context->desc.mpeg12.num_slices, (const void * const*)buffers, context->sizes);
+
 }
 
 static VAStatus
@@ -586,6 +592,7 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
}
 
context->decoder->end_frame(context->decoder, context->target, >desc.base);
+   FREE(context->sizes);
if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
   int idr_period = context->desc.h264enc.gop_size / context->gop_coeff;
   int p_remain_in_idr = idr_period - context->desc.h264enc.frame_num;
diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c b/src/gallium/state_trackers/va/picture_mpeg12.c
index 1e5a9c7..b9d8667 100

[Mesa-dev] [PATCH v2] st/va: remove assert for single slice

2017-02-10 Thread Nayan Deshmukh

we anyway allow for multiple slices

v2: do not remove assert to check for buf->size

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/va/picture_mpeg12.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c 
b/src/gallium/state_trackers/va/picture_mpeg12.c
index 812e9e5..1e5a9c7 100644
--- a/src/gallium/state_trackers/va/picture_mpeg12.c
+++ b/src/gallium/state_trackers/va/picture_mpeg12.c
@@ -81,6 +81,6 @@ void vlVaHandleIQMatrixBufferMPEG12(vlVaContext *context, 
vlVaBuffer *buf)
 
 void vlVaHandleSliceParameterBufferMPEG12(vlVaContext *context, vlVaBuffer 
*buf)
 {
-   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2) && 
buf->num_elements == 1);
+   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2));
context->desc.mpeg12.num_slices += buf->num_elements;
 }
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: remove assert for single slice

2017-02-10 Thread Nayan Deshmukh

On Fri, Feb 10, 2017 at 5:09 PM, Christian König
<deathsim...@vodafone.de> wrote:
> Sorry for the delay, as noted in the other mail I was on sick leave for a
> while.
>
>
> Am 03.02.2017 um 05:52 schrieb Nayan Deshmukh:
>>
>> On Thu, Feb 2, 2017 at 3:34 PM, Christian König <deathsim...@vodafone.de>
>> wrote:
>>>
>>> Am 01.02.2017 um 13:59 schrieb Nayan Deshmukh:
>>>>
>>>> we anyway allow for multiple slices
>>>>
>>>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>>>> ---
>>>>src/gallium/state_trackers/va/picture_mpeg12.c | 1 -
>>>>1 file changed, 1 deletion(-)
>>>>
>>>> diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c
>>>> b/src/gallium/state_trackers/va/picture_mpeg12.c
>>>> index 812e9e5..4d9c45f 100644
>>>> --- a/src/gallium/state_trackers/va/picture_mpeg12.c
>>>> +++ b/src/gallium/state_trackers/va/picture_mpeg12.c
>>>> @@ -81,6 +81,5 @@ void vlVaHandleIQMatrixBufferMPEG12(vlVaContext
>>>> *context, vlVaBuffer *buf)
>>>>  void vlVaHandleSliceParameterBufferMPEG12(vlVaContext *context,
>>>> vlVaBuffer *buf)
>>>>{
>>>> -   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2) &&
>>>> buf->num_elements == 1);
>>>
>>>
>>> NAK, we can lower the requirements here, but we shouldn't completely
>>> remove
>>> the assert.
>>>
>>> Especially since we ignore all of the fields from the
>>> VASliceParameterBufferMPEG2 structure and so won't catch errors.
>>>
>> I agree, we should have some assert here.
>>
>>> Please test something like the following:
>>>
>>> assert(buf->size >= (sizeof(VASliceParameterBufferMPEG2) *
>>> buf->num_elements));
>>>
>> buf->size represents the size of a single buffer element and hence it
>> will be equal to sizeof(VASliceParameterBufferMPEG2). So we can have
>> something like
>>
>> assert(buf->size >= sizeof(VASliceParameterBufferMPEG2))
>
>
> Sounds like a good idea to me, please send that out as a patch.
>
>>
>> I also tried using the fields of the VASliceParameterBufferMPEG2. I
>> misunderstood
>> the code first, as mpv sends all the slices at ones and buf->data points
>> to
>> num_elements number of VASliceParameterBuffers. I tried using this
>> size fields with the slice data buffers, but surprisingly it leads to no
>> change.
>> Any ideas why? I am attaching the diff for reference.
>
>
> Could be that the shader based decoder has a bug with multiple slices as
> well.
>
It could be. Andy can you test it with your hardware decoder to see if
its specific
to shader decoder.

> Another possibility is that the other slices are missing the start code.
Do we need to add any specific start code for MPEG2 vids as we don't add
anything in the va state tracker?
>
> Do you have a screenshoot of the problem? And maybe a dump of what is in the
> VASliceParameterBufferMPEG2 buffers and in your bitstream buffer?
>

Here is the link for the video that I am using;
   https://drive.google.com/drive/folders/0BxP5-S1t9VEEbkR4dWhTUFozV2s

Regards,
Nayan

> Regards,
> Christian.
>
>
>>
>> Which means that bug https://bugs.freedesktop.org/show_bug.cgi?id=93760
>> is still open.
>>
>> Regards,
>> Nayan
>>
>> diff --git a/src/gallium/state_trackers/va/picture.c
>> b/src/gallium/state_trackers/va/picture.c
>> index 82584ea..8e68e35 100644
>> --- a/src/gallium/state_trackers/va/picture.c
>> +++ b/src/gallium/state_trackers/va/picture.c
>> @@ -262,8 +262,10 @@ handleVASliceDataBufferType(vlVaContext *context,
>> vlVaBuffer *buf)
>>   {
>>  enum pipe_video_format format;
>>  unsigned num_buffers = 0;
>> -   void * const *buffers[2];
>> -   unsigned sizes[2];
>> +   void * const *buffers[context->desc.mpeg12.num_slices + 1];
>> +   unsigned sizes[context->desc.mpeg12.num_slices + 1];
>> +   char *cur;
>> +   int i;
>>  static const uint8_t start_code_h264[] = { 0x00, 0x00, 0x01 };
>>  static const uint8_t start_code_h265[] = { 0x00, 0x00, 0x01 };
>>  static const uint8_t start_code_vc1[] = { 0x00, 0x00, 0x01, 0x0d };
>> @@ -306,9 +308,12 @@ handleVASliceDataBufferType(vlVaContext *context,
>> vlVaBuffer *buf)
>> break;
>>  }
>>
>> -   buffers[num_buffers] = buf->data;
>> -   sizes[num_buffers] = buf->size

Re: [Mesa-dev] [PATCH] st/va: remove assert for single slice

2017-02-02 Thread Nayan Deshmukh

On Thu, Feb 2, 2017 at 3:34 PM, Christian König <deathsim...@vodafone.de> wrote:
> Am 01.02.2017 um 13:59 schrieb Nayan Deshmukh:
>>
>> we anyway allow for multiple slices
>>
>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>> ---
>>   src/gallium/state_trackers/va/picture_mpeg12.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c
>> b/src/gallium/state_trackers/va/picture_mpeg12.c
>> index 812e9e5..4d9c45f 100644
>> --- a/src/gallium/state_trackers/va/picture_mpeg12.c
>> +++ b/src/gallium/state_trackers/va/picture_mpeg12.c
>> @@ -81,6 +81,5 @@ void vlVaHandleIQMatrixBufferMPEG12(vlVaContext
>> *context, vlVaBuffer *buf)
>> void vlVaHandleSliceParameterBufferMPEG12(vlVaContext *context,
>> vlVaBuffer *buf)
>>   {
>> -   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2) &&
>> buf->num_elements == 1);
>
>
> NAK, we can lower the requirements here, but we shouldn't completely remove
> the assert.
>
> Especially since we ignore all of the fields from the
> VASliceParameterBufferMPEG2 structure and so won't catch errors.
>
I agree, we should have some assert here.

> Please test something like the following:
>
> assert(buf->size >= (sizeof(VASliceParameterBufferMPEG2) *
> buf->num_elements));
>

buf->size represents the size of a single buffer element and hence it
will be equal to sizeof(VASliceParameterBufferMPEG2). So we can have
something like

assert(buf->size >= sizeof(VASliceParameterBufferMPEG2))

I also tried using the fields of the VASliceParameterBufferMPEG2. I
misunderstood
the code first, as mpv sends all the slices at ones and buf->data points to
num_elements number of VASliceParameterBuffers. I tried using this
size fields with the slice data buffers, but surprisingly it leads to no change.
Any ideas why? I am attaching the diff for reference.

Which means that bug https://bugs.freedesktop.org/show_bug.cgi?id=93760
is still open.

Regards,
Nayan

diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index 82584ea..8e68e35 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -262,8 +262,10 @@ handleVASliceDataBufferType(vlVaContext *context,
vlVaBuffer *buf)
 {
enum pipe_video_format format;
unsigned num_buffers = 0;
-   void * const *buffers[2];
-   unsigned sizes[2];
+   void * const *buffers[context->desc.mpeg12.num_slices + 1];
+   unsigned sizes[context->desc.mpeg12.num_slices + 1];
+   char *cur;
+   int i;
static const uint8_t start_code_h264[] = { 0x00, 0x00, 0x01 };
static const uint8_t start_code_h265[] = { 0x00, 0x00, 0x01 };
static const uint8_t start_code_vc1[] = { 0x00, 0x00, 0x01, 0x0d };
@@ -306,9 +308,12 @@ handleVASliceDataBufferType(vlVaContext *context,
vlVaBuffer *buf)
   break;
}

-   buffers[num_buffers] = buf->data;
-   sizes[num_buffers] = buf->size;
-   ++num_buffers;
+   cur = buf->data;
+   for (i = 0; i < context->desc.mpeg12.num_slices; ++i) {
+  buffers[i] = cur;
+  cur = cur + context->sizes[i];
+   }
+

if (context->needs_begin_frame) {
   context->decoder->begin_frame(context->decoder, context->target,
@@ -316,7 +321,8 @@ handleVASliceDataBufferType(vlVaContext *context,
vlVaBuffer *buf)
   context->needs_begin_frame = false;
}
context->decoder->decode_bitstream(context->decoder,
context->target, >desc.base,
-  num_buffers, (const void * const*)buffers, sizes);
+  context->desc.mpeg12.num_slices, (const void * const*)buffers,
context->sizes);
+
 }

 static VAStatus
@@ -586,6 +592,7 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
}

context->decoder->end_frame(context->decoder, context->target,
>desc.base);
+   FREE(context->sizes);
if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
   int idr_period = context->desc.h264enc.gop_size / context->gop_coeff;
   int p_remain_in_idr = idr_period - context->desc.h264enc.frame_num;
diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c
b/src/gallium/state_trackers/va/picture_mpeg12.c
index 4d9c45f..9e51274 100644
--- a/src/gallium/state_trackers/va/picture_mpeg12.c
+++ b/src/gallium/state_trackers/va/picture_mpeg12.c
@@ -81,5 +81,16 @@ void vlVaHandleIQMatrixBufferMPEG12(vlVaContext
*context, vlVaBuffer *buf)

 void vlVaHandleSliceParameterBufferMPEG12(vlVaContext *context,
vlVaBuffer *buf)
 {
+   VASliceParameterBufferMPEG2 *mpeg2 = buf->data;
+   unsigned *sizes = MALLOC(buf->num_elements * sizeof(unsigned));
+   int i;
+
context->desc.mpeg12.num_slices += buf->num_elements;
+
+   for(i = 0; i < buf->

[Mesa-dev] [PATCH] st/va: remove assert for single slice

2017-02-01 Thread Nayan Deshmukh

we anyway allow for multiple slices

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/va/picture_mpeg12.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c 
b/src/gallium/state_trackers/va/picture_mpeg12.c
index 812e9e5..4d9c45f 100644
--- a/src/gallium/state_trackers/va/picture_mpeg12.c
+++ b/src/gallium/state_trackers/va/picture_mpeg12.c
@@ -81,6 +81,5 @@ void vlVaHandleIQMatrixBufferMPEG12(vlVaContext *context, 
vlVaBuffer *buf)
 
 void vlVaHandleSliceParameterBufferMPEG12(vlVaContext *context, vlVaBuffer 
*buf)
 {
-   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2) && 
buf->num_elements == 1);
context->desc.mpeg12.num_slices += buf->num_elements;
 }
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

2017-01-23 Thread Nayan Deshmukh

The patch is Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>



On Mon, Jan 23, 2017 at 7:01 PM, Christian König
<deathsim...@vodafone.de> wrote:
> Ah, yes of course. If we delay creating the decoder we need to call
> begin_frame() again as well.
>
> Please review and/or test the attached patch. Andy I did understand you
> right that this is already a Tested-by from your side, isn't it?
>
>> I am wondering if calling decode_bitstream one at a time for each
>> buffer is similar to
>> calling it with all buffers at once?
>
> Yes, that is correct. It's just not as efficient.
>
> One problem with VA-API is that it doesn't seem to guarantee that buffers
> stays around after handing them of to the decoder (the ownership handling of
> buffers and surfaces is a totally mess).
>
> So we would need to make a copy of the buffer content to submit it again all
> at once.
>
> Regards,
> Christian.
>
>
> Am 21.01.2017 um 20:46 schrieb Andy Furniss:
>>
>> Nayan Deshmukh wrote:
>>>
>>> Hi Christian,
>>>
>>> The new patch leads to seg fault on my system. You forgot to set the
>>> needs_begin_frame to true when the decoder is created. Here's diff for
>>> reference:
>>
>>
>> Setting true there seems to fix, though only a quick test.
>>
>> The patch below sets false :-)
>>
>>> 
>>> diff --git a/src/gallium/state_trackers/va/picture.c
>>> b/src/gallium/state_trackers/va/picture.c
>>> index e75006d..a51e482 100644
>>> --- a/src/gallium/state_trackers/va/picture.c
>>> +++ b/src/gallium/state_trackers/va/picture.c
>>> @@ -178,6 +178,8 @@ handlePictureParameterBuffer(vlVaDriver *drv,
>>> vlVaContext *context, vlVaBuffer *
>>>
>>> if (!context->decoder)
>>>return VA_STATUS_ERROR_ALLOCATION_FAILED;
>>> +
>>> +  context->needs_begin_frame = false;
>>>  }
>>>
>>>  return vaStatus;
>>> --
>>>
>>> I am wondering if calling decode_bitstream one at a time for each
>>> buffer is similar to
>>> calling it with all buffers at once?
>>>
>>> Cheers,
>>> Nayan
>>>
>>> On Thu, Jan 19, 2017 at 8:36 PM, Andy Furniss <adf.li...@gmail.com>
>>> wrote:
>>>>
>>>> Andy Furniss wrote:
>>>>>
>>>>>
>>>>> Christian König wrote:
>>>>>>
>>>>>>
>>>>>> Hi Andy,
>>>>>>
>>>>>> Am 19.01.2017 um 11:46 schrieb Andy Furniss:
>>>>>>>
>>>>>>>
>>>>>>> I think you are right about the slices, the failing vids are
>>>>>>> blu-ray/tv.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://drive.google.com/file/d/0BxP5-S1t9VEEZlozcjVUZ1lDbWM/view?usp=sharing
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Thanks for the link, if you have time please give the attached patch a
>>>>>> try.
>>>>>>
>>>>>> It should fix the issue, but I currently don't have a test system for
>>>>>> VAAPI ready so I can't confirm it of hand.
>>>>>
>>>>>
>>>>>
>>>>> It doesn't fix properly. The vid will play normally after a second,
>>>>> but during that second I get to see many flash frames of gpu mem.
>>>>>
>>>>> Lucky I chose this sample out of several as the patch does seem to
>>>>> fix a couple of other previously failing vids.
>>>>
>>>>
>>>>
>>>> Though more testing shows it also regresses previously working vids,
>>>> some as
>>>> above, but one never "starts" and is total junk.
>>>>
>>>>
>>>>
>>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

2017-01-21 Thread Nayan Deshmukh

Hi Christian,

The new patch leads to seg fault on my system. You forgot to set the
needs_begin_frame to true when the decoder is created. Here's diff for
reference:

diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index e75006d..a51e482 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -178,6 +178,8 @@ handlePictureParameterBuffer(vlVaDriver *drv,
vlVaContext *context, vlVaBuffer *

   if (!context->decoder)
  return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+  context->needs_begin_frame = false;
}

return vaStatus;
--

I am wondering if calling decode_bitstream one at a time for each
buffer is similar to
calling it with all buffers at once?

Cheers,
Nayan

On Thu, Jan 19, 2017 at 8:36 PM, Andy Furniss  wrote:
> Andy Furniss wrote:
>>
>> Christian König wrote:
>>>
>>> Hi Andy,
>>>
>>> Am 19.01.2017 um 11:46 schrieb Andy Furniss:

 I think you are right about the slices, the failing vids are blu-ray/tv.


 https://drive.google.com/file/d/0BxP5-S1t9VEEZlozcjVUZ1lDbWM/view?usp=sharing



>>> Thanks for the link, if you have time please give the attached patch a
>>> try.
>>>
>>> It should fix the issue, but I currently don't have a test system for
>>> VAAPI ready so I can't confirm it of hand.
>>
>>
>> It doesn't fix properly. The vid will play normally after a second,
>> but during that second I get to see many flash frames of gpu mem.
>>
>> Lucky I chose this sample out of several as the patch does seem to
>> fix a couple of other previously failing vids.
>
>
> Though more testing shows it also regresses previously working vids, some as
> above, but one never "starts" and is total junk.
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v4] st/vdpau: only send buffers with B8G8R8A8 format to X

2017-01-19 Thread Nayan Deshmukh

PresentPixmap only works if the pixmap depth matches with the
window depth, otherwise it returns a BadMatch protocol error.
Even if the depths match, the result won't look correctly
if the VDPAU RGB component order doesn't match the X11 one so
we only allow the X11 format.
For other buffers we copy them to a buffer which is send to X.

v2: only send buffers with format VDP_RGBA_FORMAT_B8G8R8A8
v3: reword commit message
v4: add comment explaining the code

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/output.c| 7 +++
 src/gallium/state_trackers/vdpau/presentation.c  | 6 +++---
 src/gallium/state_trackers/vdpau/vdpau_private.h | 1 +
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/output.c 
b/src/gallium/state_trackers/vdpau/output.c
index 98a8011..8740b53 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -75,6 +75,13 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
 
memset(_tmpl, 0, sizeof(res_tmpl));
 
+   /* 
+* The output won't look correctly when this buffer is send to X,
+* if the VDPAU RGB component order doesn't match the X11 one so
+* we only allow the X11 format
+*/ 
+   vlsurface->send_to_X = rgba_format == VDP_RGBA_FORMAT_B8G8R8A8;
+
res_tmpl.target = PIPE_TEXTURE_2D;
res_tmpl.format = VdpFormatRGBAToPipe(rgba_format);
res_tmpl.width0 = width;
diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index d479369..78cafc8 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -231,7 +231,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
vscreen = pq->device->vscreen;
 
pipe_mutex_lock(pq->device->mutex);
-   if (vscreen->set_back_texture_from_output)
+   if (vscreen->set_back_texture_from_output && surf->send_to_X)
   vscreen->set_back_texture_from_output(vscreen, surf->surface->texture, 
clip_width, clip_height);
tex = vscreen->texture_from_drawable(vscreen, (void *)pq->drawable);
if (!tex) {
@@ -239,7 +239,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   return VDP_STATUS_INVALID_HANDLE;
}
 
-   if (!vscreen->set_back_texture_from_output) {
+   if (!vscreen->set_back_texture_from_output || !surf->send_to_X) {
   dirty_area = vscreen->get_dirty_area(vscreen);
 
   memset(_templ, 0, sizeof(surf_templ));
@@ -289,7 +289,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   framenum++;
}
 
-   if (!vscreen->set_back_texture_from_output) {
+   if (!vscreen->set_back_texture_from_output || !surf->send_to_X) {
   pipe_resource_reference(, NULL);
   pipe_surface_reference(_draw, NULL);
}
diff --git a/src/gallium/state_trackers/vdpau/vdpau_private.h 
b/src/gallium/state_trackers/vdpau/vdpau_private.h
index 490a0bd..8356608 100644
--- a/src/gallium/state_trackers/vdpau/vdpau_private.h
+++ b/src/gallium/state_trackers/vdpau/vdpau_private.h
@@ -415,6 +415,7 @@ typedef struct
struct pipe_fence_handle *fence;
struct vl_compositor_state cstate;
struct u_rect dirty_area;
+   bool send_to_X;
 } vlVdpOutputSurface;
 
 typedef struct
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3] st/vdpau: only send buffers with B8G8R8A8 format to X

2017-01-19 Thread Nayan Deshmukh

PresentPixmap only works if the pixmap depth matches with the
window depth, otherwise it returns a BadMatch protocol error.
Even if the depths match, the result won't look correctly
if the VDPAU RGB component order doesn't match the X11 one so
we only allow the X11 format.
For other buffers we copy them to a buffer which is send to X.

v2: only send buffers with format VDP_RGBA_FORMAT_B8G8R8A8
v3: reword commit message

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/output.c| 2 ++
 src/gallium/state_trackers/vdpau/presentation.c  | 6 +++---
 src/gallium/state_trackers/vdpau/vdpau_private.h | 1 +
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/output.c 
b/src/gallium/state_trackers/vdpau/output.c
index 98a8011..e800d2c 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -75,6 +75,8 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
 
memset(_tmpl, 0, sizeof(res_tmpl));
 
+   vlsurface->send_to_X = rgba_format == VDP_RGBA_FORMAT_B8G8R8A8;
+
res_tmpl.target = PIPE_TEXTURE_2D;
res_tmpl.format = VdpFormatRGBAToPipe(rgba_format);
res_tmpl.width0 = width;
diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index d479369..78cafc8 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -231,7 +231,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
vscreen = pq->device->vscreen;
 
pipe_mutex_lock(pq->device->mutex);
-   if (vscreen->set_back_texture_from_output)
+   if (vscreen->set_back_texture_from_output && surf->send_to_X)
   vscreen->set_back_texture_from_output(vscreen, surf->surface->texture, 
clip_width, clip_height);
tex = vscreen->texture_from_drawable(vscreen, (void *)pq->drawable);
if (!tex) {
@@ -239,7 +239,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   return VDP_STATUS_INVALID_HANDLE;
}
 
-   if (!vscreen->set_back_texture_from_output) {
+   if (!vscreen->set_back_texture_from_output || !surf->send_to_X) {
   dirty_area = vscreen->get_dirty_area(vscreen);
 
   memset(_templ, 0, sizeof(surf_templ));
@@ -289,7 +289,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   framenum++;
}
 
-   if (!vscreen->set_back_texture_from_output) {
+   if (!vscreen->set_back_texture_from_output || !surf->send_to_X) {
   pipe_resource_reference(, NULL);
   pipe_surface_reference(_draw, NULL);
}
diff --git a/src/gallium/state_trackers/vdpau/vdpau_private.h 
b/src/gallium/state_trackers/vdpau/vdpau_private.h
index 490a0bd..8356608 100644
--- a/src/gallium/state_trackers/vdpau/vdpau_private.h
+++ b/src/gallium/state_trackers/vdpau/vdpau_private.h
@@ -415,6 +415,7 @@ typedef struct
struct pipe_fence_handle *fence;
struct vl_compositor_state cstate;
struct u_rect dirty_area;
+   bool send_to_X;
 } vlVdpOutputSurface;
 
 typedef struct
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

2017-01-19 Thread Nayan Deshmukh

On Thu, Jan 19, 2017 at 2:07 PM, Christian König
<deathsim...@vodafone.de> wrote:
> Am 19.01.2017 um 00:20 schrieb Andy Furniss:
>>
>> Nayan Deshmukh wrote:
>>>
>>> On Tue, Jan 17, 2017 at 9:12 PM, Emil Velikov <emil.l.veli...@gmail.com>
>>> wrote:
>>>>
>>>> On 17 January 2017 at 14:55, Nayan Deshmukh <nayan26deshm...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Tue, Jan 17, 2017 at 6:25 PM, Christian König
>>>>> <christian.koe...@amd.com> wrote:
>>>>>>
>>>>>> Hi Nayan,
>>>>>>
>>>>>> I've pushed this patch yesterday and this one just a minute ago.
>>>>>>
>>>>> Thanks for the push. I am planning on sending a similar patch for
>>>>> vaapi.
>>>>>
>>>> If this (and the vaapi one) does not have too many nasty dependencies
>>>> might be worth tagging for stable ?
>>>> Cc: mesa-sta...@lists.freedesktop.org
>>>>
>>> This one should be added to stable, I forgot to add the stable tag. I
>>> will send a mail
>>
>>
>> Unfortunately it seems this does regress some h264 videos.
>>
>> I did test several h264 - 576, 720, 1080 and 4K, all were OK but I've just
>> found
>> a couple that are regressed by this = decode to partial junk.
>
>
> Making an educated guess I would say everything which uses multiple slices
> would now break.
>
> Damn it, I should have thought earlier about this. Trivial to fix, we just
> need to make sure to call begin_frame only once for each frame.
>
> Nayan, do you want to provide a patch or should I take care of this?
>
I am a little busy, so you can take a jab at it.
> Andy can you point us to a broken video?
>
> Thanks in advance,
> Christian.
>
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] st/vdpau: only send buffers with B8G8R8A8 format to X

2017-01-18 Thread Nayan Deshmukh

PresentPixmap only works if the pixmap depth and format matches
with the window, otherwise it returns a BadMatch protocol error.
For other buffers we copy them to a buffer which is send to X.

v2: only send buffers with format VDP_RGBA_FORMAT_B8G8R8A8

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/output.c| 2 ++
 src/gallium/state_trackers/vdpau/presentation.c  | 6 +++---
 src/gallium/state_trackers/vdpau/vdpau_private.h | 1 +
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/output.c 
b/src/gallium/state_trackers/vdpau/output.c
index 98a8011..e800d2c 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -75,6 +75,8 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
 
memset(_tmpl, 0, sizeof(res_tmpl));
 
+   vlsurface->send_to_X = rgba_format == VDP_RGBA_FORMAT_B8G8R8A8;
+
res_tmpl.target = PIPE_TEXTURE_2D;
res_tmpl.format = VdpFormatRGBAToPipe(rgba_format);
res_tmpl.width0 = width;
diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index d479369..78cafc8 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -231,7 +231,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
vscreen = pq->device->vscreen;
 
pipe_mutex_lock(pq->device->mutex);
-   if (vscreen->set_back_texture_from_output)
+   if (vscreen->set_back_texture_from_output && surf->send_to_X)
   vscreen->set_back_texture_from_output(vscreen, surf->surface->texture, 
clip_width, clip_height);
tex = vscreen->texture_from_drawable(vscreen, (void *)pq->drawable);
if (!tex) {
@@ -239,7 +239,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   return VDP_STATUS_INVALID_HANDLE;
}
 
-   if (!vscreen->set_back_texture_from_output) {
+   if (!vscreen->set_back_texture_from_output || !surf->send_to_X) {
   dirty_area = vscreen->get_dirty_area(vscreen);
 
   memset(_templ, 0, sizeof(surf_templ));
@@ -289,7 +289,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   framenum++;
}
 
-   if (!vscreen->set_back_texture_from_output) {
+   if (!vscreen->set_back_texture_from_output || !surf->send_to_X) {
   pipe_resource_reference(, NULL);
   pipe_surface_reference(_draw, NULL);
}
diff --git a/src/gallium/state_trackers/vdpau/vdpau_private.h 
b/src/gallium/state_trackers/vdpau/vdpau_private.h
index 490a0bd..8356608 100644
--- a/src/gallium/state_trackers/vdpau/vdpau_private.h
+++ b/src/gallium/state_trackers/vdpau/vdpau_private.h
@@ -415,6 +415,7 @@ typedef struct
struct pipe_fence_handle *fence;
struct vl_compositor_state cstate;
struct u_rect dirty_area;
+   bool send_to_X;
 } vlVdpOutputSurface;
 
 typedef struct
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/vdpau: avoid sending buffers with 10bit channels to X

2017-01-18 Thread Nayan Deshmukh

On Wed, Jan 18, 2017 at 9:21 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> On 19/01/17 12:27 AM, Nayan Deshmukh wrote:
>> PresentPixmap only works if the pixmap depth matches the window
>> depth, otherwise it returns a BadMatch protocol error.
>>
>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>> ---
>>  src/gallium/state_trackers/vdpau/output.c| 6 ++
>>  src/gallium/state_trackers/vdpau/presentation.c  | 6 +++---
>>  src/gallium/state_trackers/vdpau/vdpau_private.h | 1 +
>>  3 files changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/vdpau/output.c 
>> b/src/gallium/state_trackers/vdpau/output.c
>> index 98a8011..4466483 100644
>> --- a/src/gallium/state_trackers/vdpau/output.c
>> +++ b/src/gallium/state_trackers/vdpau/output.c
>> @@ -75,6 +75,12 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>>
>> memset(_tmpl, 0, sizeof(res_tmpl));
>>
>> +   if (rgba_format == VDP_RGBA_FORMAT_B10G10R10A2 ||
>> +   rgba_format ==  VDP_RGBA_FORMAT_R10G10B10A2)
>> +  vlsurface->send_to_X = false;
>> +   else
>> +  vlsurface->send_to_X = true;
>
> This isn't sufficient: The window depth could be != 24 (in particular 16
> or 15, or 30). Even if the depths match, the result won't look correctly
In case the depth is not 24 then vl_winsys_dri3.c will return null and
it will follow the older code path.

> if the VDPAU RGB component order doesn't match the X11 one. So
> technically this actually needs to check the window's visual instead of
> just the depth (though in practice I think all X11 visuals use the same
> RGB component order).
>
What is the order that they use?

If they practically use the same order it will be easier to encode it instead
of checking it every time.

Regards,
Nayan

>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/vdpau: avoid sending buffers with 10bit channels to X

2017-01-18 Thread Nayan Deshmukh

PresentPixmap only works if the pixmap depth matches the window
depth, otherwise it returns a BadMatch protocol error.

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/output.c| 6 ++
 src/gallium/state_trackers/vdpau/presentation.c  | 6 +++---
 src/gallium/state_trackers/vdpau/vdpau_private.h | 1 +
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/output.c 
b/src/gallium/state_trackers/vdpau/output.c
index 98a8011..4466483 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -75,6 +75,12 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
 
memset(_tmpl, 0, sizeof(res_tmpl));
 
+   if (rgba_format == VDP_RGBA_FORMAT_B10G10R10A2 ||
+   rgba_format ==  VDP_RGBA_FORMAT_R10G10B10A2)
+  vlsurface->send_to_X = false;
+   else
+  vlsurface->send_to_X = true;
+
res_tmpl.target = PIPE_TEXTURE_2D;
res_tmpl.format = VdpFormatRGBAToPipe(rgba_format);
res_tmpl.width0 = width;
diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index d479369..78cafc8 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -231,7 +231,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
vscreen = pq->device->vscreen;
 
pipe_mutex_lock(pq->device->mutex);
-   if (vscreen->set_back_texture_from_output)
+   if (vscreen->set_back_texture_from_output && surf->send_to_X)
   vscreen->set_back_texture_from_output(vscreen, surf->surface->texture, 
clip_width, clip_height);
tex = vscreen->texture_from_drawable(vscreen, (void *)pq->drawable);
if (!tex) {
@@ -239,7 +239,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   return VDP_STATUS_INVALID_HANDLE;
}
 
-   if (!vscreen->set_back_texture_from_output) {
+   if (!vscreen->set_back_texture_from_output || !surf->send_to_X) {
   dirty_area = vscreen->get_dirty_area(vscreen);
 
   memset(_templ, 0, sizeof(surf_templ));
@@ -289,7 +289,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   framenum++;
}
 
-   if (!vscreen->set_back_texture_from_output) {
+   if (!vscreen->set_back_texture_from_output || !surf->send_to_X) {
   pipe_resource_reference(, NULL);
   pipe_surface_reference(_draw, NULL);
}
diff --git a/src/gallium/state_trackers/vdpau/vdpau_private.h 
b/src/gallium/state_trackers/vdpau/vdpau_private.h
index 490a0bd..8356608 100644
--- a/src/gallium/state_trackers/vdpau/vdpau_private.h
+++ b/src/gallium/state_trackers/vdpau/vdpau_private.h
@@ -415,6 +415,7 @@ typedef struct
struct pipe_fence_handle *fence;
struct vl_compositor_state cstate;
struct u_rect dirty_area;
+   bool send_to_X;
 } vlVdpOutputSurface;
 
 typedef struct
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): st/vdpau: use dri3 to directly send the buffer to X(v2)

2017-01-18 Thread Nayan Deshmukh

I could simply add an extra parameter to vlVdpOutputSurface which shows
that window and surface have the same format and revert to older otherwise.

Christian, I was wondering if removing the rendering hack is right since
with this vlc will follow the old codepath even with dri3.  Should we revert
that commit?

Regards,
Nayan
On Wed, Jan 18, 2017 at 3:26 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> On 18/01/17 06:47 PM, Christian König wrote:
>> Am 18.01.2017 um 09:25 schrieb Michel Dänzer:
>>> On 17/01/17 09:55 PM, Christian König wrote:
>>>> Module: Mesa
>>>> Branch: master
>>>> Commit: 15bfdea99c7b487d2c38d6dd7b88fb44810ef75a
>>>> URL:
>>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=15bfdea99c7b487d2c38d6dd7b88fb44810ef75a
>>>>
>>>>
>>>> Author: Nayan Deshmukh <nayan26deshm...@gmail.com>
>>>> Date:   Wed Jan 11 22:45:14 2017 +0530
>>>>
>>>> st/vdpau: use dri3 to directly send the buffer to X(v2)
>>> Unfortunately, this broke VLC, resulting in incorrect colours in videos.
>>> The problem is that VDP_RGBA_FORMAT_R10G10B10A2 is passed to
>>> vlVdpOutputSurfaceCreate. This can't work directly for presentation,
>>> because the Present extension request PresentPixmap only works if the
>>> pixmap depth matches the window depth, otherwise it returns a BadMatch
>>> protocol error.
>>
>> Price question: Is that a general limitation or just something not
>> implemented?
>
> The former. This would require adding a new Present extension request
> for cases where the depths of the source pixmap and the destination
> window don't match.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

2017-01-17 Thread Nayan Deshmukh

On Tue, Jan 17, 2017 at 9:12 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 17 January 2017 at 14:55, Nayan Deshmukh <nayan26deshm...@gmail.com> wrote:
>> On Tue, Jan 17, 2017 at 6:25 PM, Christian König
>> <christian.koe...@amd.com> wrote:
>>> Hi Nayan,
>>>
>>> I've pushed this patch yesterday and this one just a minute ago.
>>>
>> Thanks for the push. I am planning on sending a similar patch for vaapi.
>>
> If this (and the vaapi one) does not have too many nasty dependencies
> might be worth tagging for stable ?
> Cc: mesa-sta...@lists.freedesktop.org
>
This one should be added to stable, I forgot to add the stable tag. I
will send a mail
to the stable list. The vaapi patch that I was talking about in the
previous mail was
in reference to this patch

st/vdpau: use dri3 to directly send the buffer to X(v2)

this avoids an extra copy which occurs in case of dri2

Implementing this for va state tracker too. This is just an improvement.

Regards,
Nayan.
> -Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

2017-01-17 Thread Nayan Deshmukh

On Tue, Jan 17, 2017 at 6:25 PM, Christian König
 wrote:
> Hi Nayan,
>
> I've pushed this patch yesterday and this one just a minute ago.
>
Thanks for the push. I am planning on sending a similar patch for vaapi.

Regards,
Nayan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

2017-01-16 Thread Nayan Deshmukh

Hi Christian,

Please push this patch.

There are a couple of patches [1] which are not yet reviewed. They are
trivial and are tested by Andy. Please have a look at them.

Regards,
Nayan

[1] https://lists.freedesktop.org/archives/mesa-dev/2017-January/140395.html

On Fri, Jan 13, 2017 at 11:17 PM, Andy Furniss <adf.li...@gmail.com> wrote:

> Nayan Deshmukh wrote:
>
>> On Fri, Jan 13, 2017 at 9:54 PM, Andy Furniss <adf.li...@gmail.com>
>> wrote:
>>
>
> Would be interesting to see if you see the same with this vid
>>> which easily shows the corruption.
>>>
>>> https://drive.google.com/drive/folders/0BxP5-S1t9VEEbkR4dWhT
>>> UFozV2s?usp=sharing
>>>
>>> Looks bad --hwdec-vaapi with or without --vo=vaapi
>>>
>>> with --hwdec=vaapi and --vo=vaapi I see the corruption. But without
>> --vo=vaapi it uses VAAPI EGL interop and leads to this error
>> unsupported VA image format unknown
>>
>
> Ok and thanks for looking into the buzilla bug.
>
> I don't know why you get egl interop - I get "normal" opengl and don't
> know how force mpv to try egl.
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

2017-01-13 Thread Nayan Deshmukh

On Fri, Jan 13, 2017 at 9:54 PM, Andy Furniss <adf.li...@gmail.com> wrote:
>
> Nayan Deshmukh wrote:
>>
>> On Fri, Jan 13, 2017 at 8:32 PM, Andy Furniss <adf.li...@gmail.com> wrote:
>>
>>> Nayan Deshmukh wrote:
>>>
>>>> Hi Andy,
>>>>
>>>> Please test this patch for regressions.
>>>>
>>>
>>> Do you have a testcase to show the fix?
>>>
>>> TBH I've not tested gstreamer with mpeg2 before as vaapi mpeg2
>>> h/w dec never worked properly anyway.
>>>
>>> https://bugs.freedesktop.org/show_bug.cgi?id=93760
>>>
>>> With mpv --hwdec=vaapi it doesn't seem to regress anything.
>>>
>> I was talking about --hwdec=vaapi. Before this patch I was not able to play
>> any mpeg videos with vaapi as mpv --hwdec=vaapi --vo=vaapi always
>> segfaulted. With this patch I can see videos properly. Just wanted to
>> make sure it did not cause any regression when using hardware decoder.
>
>
> Oh, OK, I can't reproduce that with mpv, but it will still just assert with 
> mesa debug build
>
> mpv: picture_mpeg12.c:84: vlVaHandleSliceParameterBufferMPEG12: Assertion 
> `buf->size >= sizeof(VASliceParameterBufferMPEG2) && buf->num_elements == 1' 
> failed.
>
> Or play with non debug build, but depending on source vid may be
> slightly corrupted.
>
> Would be interesting to see if you see the same with this vid
> which easily shows the corruption.
>
> https://drive.google.com/drive/folders/0BxP5-S1t9VEEbkR4dWhTUFozV2s?usp=sharing
>
> Looks bad --hwdec-vaapi with or without --vo=vaapi
>
with --hwdec=vaapi and --vo=vaapi I see the corruption. But without
--vo=vaapi it uses VAAPI EGL interop and leads to this error
unsupported VA image format unknown

> OK with --hwdec=vdpau --vo=vdpau (just --hwdec=vdpau will be slightly wrong
> currently as there is a vdpau gl interop bug that causes half res)
>
Same for me.
>
>>> More generally - it's really good you are working on vaapi - I don't
>>> know what you've discusses with anyone but did you see the old threads
>>> around VAAPI_DISABLE_INTERLACE?
>>>
>> I haven't discussed it with anyone but I will try reading the old threads
>> and the
>> bug reports.
>
>
> Thanks.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

2017-01-13 Thread Nayan Deshmukh

On Fri, Jan 13, 2017 at 8:32 PM, Andy Furniss <adf.li...@gmail.com> wrote:

> Nayan Deshmukh wrote:
>
>> Hi Andy,
>>
>> Please test this patch for regressions.
>>
>
> Do you have a testcase to show the fix?
>
> TBH I've not tested gstreamer with mpeg2 before as vaapi mpeg2
> h/w dec never worked properly anyway.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=93760
>
> With mpv --hwdec=vaapi it doesn't seem to regress anything.
>
> I was talking about --hwdec=vaapi. Before this patch I was not able to play
any mpeg videos with vaapi as mpv --hwdec=vaapi --vo=vaapi always
segfaulted. With this patch I can see videos properly. Just wanted to
make sure it did not cause any regression when using hardware decoder.


> With gstreamer - I can display junk and segfault with or without
> the patch.
>
> This is the first time trying though, and I just don't know whether it's
> just me messing up demuxing mpeg container to feed vaapi or whether
> it's using vaapi sink (normally I only test x264/mkv/mp4/raw
> encode/transcode).
>
> If you have a working gstreamer commandline to demux mpegps decode and
> display
> it would be handy :-)
>
>
> More generally - it's really good you are working on vaapi - I don't
> know what you've discusses with anyone but did you see the old threads
> around VAAPI_DISABLE_INTERLACE?
>
> I haven't discussed it with anyone but I will try reading the old threads
and the
bug reports.

Regards,
Nayan

> I was meaning to bring this up via bug/finding replying to old mails.
> It was only meant to be a short term fix and as time goes on it's
> getting more problematic.
>
> Soon ffmpeg will enable de-interlacer, which depending on env, may lock
> peoples GPUs if they paste some example from the wiki.
>
> mpv --vo=vaapi is also borked = vmfaults probably related to interlaces
> vs progressive buffers (though may be more complicated than that as
> hwdec + vo does seem OK)
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

2017-01-13 Thread Nayan Deshmukh

Hi Andy,

Please test this patch for regressions.

Cheers,
Nayan

On Fri, Jan 13, 2017 at 6:45 PM, Nayan Deshmukh <nayan26deshm...@gmail.com>
wrote:

> If begin_frame is called before setting intra_matrix and
> non_intra_matrix it leads to segmentation faults when
> vl_mpeg12_decoder.c is used.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92634
> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
> ---
>  src/gallium/state_trackers/va/picture.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/picture.c
> b/src/gallium/state_trackers/va/picture.c
> index b5b9a83..dc7121c 100644
> --- a/src/gallium/state_trackers/va/picture.c
> +++ b/src/gallium/state_trackers/va/picture.c
> @@ -178,9 +178,6 @@ handlePictureParameterBuffer(vlVaDriver *drv,
> vlVaContext *context, vlVaBuffer *
>
>if (!context->decoder)
>   return VA_STATUS_ERROR_ALLOCATION_FAILED;
> -
> -  context->decoder->begin_frame(context->decoder, context->target,
> - >desc.base);
> }
>
> return vaStatus;
> @@ -310,6 +307,9 @@ handleVASliceDataBufferType(vlVaContext *context,
> vlVaBuffer *buf)
> buffers[num_buffers] = buf->data;
> sizes[num_buffers] = buf->size;
> ++num_buffers;
> +
> +   context->decoder->begin_frame(context->decoder, context->target,
> +  >desc.base);
> context->decoder->decode_bitstream(context->decoder, context->target,
> >desc.base,
>num_buffers, (const void * const*)buffers, sizes);
>  }
> --
> 2.9.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

2017-01-13 Thread Nayan Deshmukh

If begin_frame is called before setting intra_matrix and
non_intra_matrix it leads to segmentation faults when
vl_mpeg12_decoder.c is used.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92634
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/va/picture.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index b5b9a83..dc7121c 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -178,9 +178,6 @@ handlePictureParameterBuffer(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *
 
   if (!context->decoder)
  return VA_STATUS_ERROR_ALLOCATION_FAILED;
-
-  context->decoder->begin_frame(context->decoder, context->target,
- >desc.base);
}
 
return vaStatus;
@@ -310,6 +307,9 @@ handleVASliceDataBufferType(vlVaContext *context, 
vlVaBuffer *buf)
buffers[num_buffers] = buf->data;
sizes[num_buffers] = buf->size;
++num_buffers;
+
+   context->decoder->begin_frame(context->decoder, context->target,
+  >desc.base);
context->decoder->decode_bitstream(context->decoder, context->target, 
>desc.base,
   num_buffers, (const void * const*)buffers, sizes);
 }
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] st/vdpau: use dri3 to directly send the buffer to X(v2)

2017-01-11 Thread Nayan Deshmukh

this avoids an extra copy which occurs in case of dri2

v1.1: fallback to dri2 if dri3 fails to initialize
v2: add PIPE_BIND_SCANOUT to output buffers as they will
be send to X server directly (Michel)

Suggested-by: Christian König <christian.koe...@amd.com>
Tested-by: Andy Furniss <adf.li...@gmail.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/output.c   |  2 +-
 src/gallium/state_trackers/vdpau/presentation.c | 58 ++---
 2 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/output.c 
b/src/gallium/state_trackers/vdpau/output.c
index d67ead8..8ddf2c1 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -82,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
res_tmpl.depth0 = 1;
res_tmpl.array_size = 1;
res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
-   PIPE_BIND_SHARED;
+   PIPE_BIND_SHARED | PIPE_BIND_SCANOUT;
res_tmpl.usage = PIPE_USAGE_DEFAULT;
 
pipe_mutex_lock(dev->mutex);
diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index f35d73a..b2c8aea 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -231,43 +231,47 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
vscreen = pq->device->vscreen;
 
pipe_mutex_lock(pq->device->mutex);
+   if (vscreen->set_back_texture_from_output)
+  vscreen->set_back_texture_from_output(vscreen, surf->surface->texture, 
clip_width, clip_height);
tex = vscreen->texture_from_drawable(vscreen, (void *)pq->drawable);
if (!tex) {
   pipe_mutex_unlock(pq->device->mutex);
   return VDP_STATUS_INVALID_HANDLE;
}
 
-   dirty_area = vscreen->get_dirty_area(vscreen);
+   if (!vscreen->set_back_texture_from_output) {
+  dirty_area = vscreen->get_dirty_area(vscreen);
 
-   memset(_templ, 0, sizeof(surf_templ));
-   surf_templ.format = tex->format;
-   surf_draw = pipe->create_surface(pipe, tex, _templ);
+  memset(_templ, 0, sizeof(surf_templ));
+  surf_templ.format = tex->format;
+  surf_draw = pipe->create_surface(pipe, tex, _templ);
 
-   dst_clip.x0 = 0;
-   dst_clip.y0 = 0;
-   dst_clip.x1 = clip_width ? clip_width : surf_draw->width;
-   dst_clip.y1 = clip_height ? clip_height : surf_draw->height;
+  dst_clip.x0 = 0;
+  dst_clip.y0 = 0;
+  dst_clip.x1 = clip_width ? clip_width : surf_draw->width;
+  dst_clip.y1 = clip_height ? clip_height : surf_draw->height;
 
-   if (pq->device->delayed_rendering.surface == surface &&
-   dst_clip.x1 == surf_draw->width && dst_clip.y1 == surf_draw->height) {
+  if (pq->device->delayed_rendering.surface == surface &&
+  dst_clip.x1 == surf_draw->width && dst_clip.y1 == surf_draw->height) 
{
 
-  // TODO: we correctly support the clipping here, but not the pq 
background color in the clipped area
-  cstate = pq->device->delayed_rendering.cstate;
-  vl_compositor_set_dst_clip(cstate, _clip);
-  vlVdpResolveDelayedRendering(pq->device, surf_draw, dirty_area);
+ // TODO: we correctly support the clipping here, but not the pq 
background color in the clipped area
+ cstate = pq->device->delayed_rendering.cstate;
+ vl_compositor_set_dst_clip(cstate, _clip);
+ vlVdpResolveDelayedRendering(pq->device, surf_draw, dirty_area);
 
-   } else {
-  vlVdpResolveDelayedRendering(pq->device, NULL, NULL);
+  } else {
+ vlVdpResolveDelayedRendering(pq->device, NULL, NULL);
 
-  src_rect.x0 = 0;
-  src_rect.y0 = 0;
-  src_rect.x1 = surf_draw->width;
-  src_rect.y1 = surf_draw->height;
+ src_rect.x0 = 0;
+ src_rect.y0 = 0;
+ src_rect.x1 = surf_draw->width;
+ src_rect.y1 = surf_draw->height;
 
-  vl_compositor_clear_layers(cstate);
-  vl_compositor_set_rgba_layer(cstate, compositor, 0, surf->sampler_view, 
_rect, NULL, NULL);
-  vl_compositor_set_dst_clip(cstate, _clip);
-  vl_compositor_render(cstate, compositor, surf_draw, dirty_area, true);
+ vl_compositor_clear_layers(cstate);
+ vl_compositor_set_rgba_layer(cstate, compositor, 0, 
surf->sampler_view, _rect, NULL, NULL);
+ vl_compositor_set_dst_clip(cstate, _clip);
+ vl_compositor_render(cstate, compositor, surf_draw, dirty_area, true);
+  }
}
 
vscreen->set_next_timestamp(vscreen, earliest_presentation_time);
@@ -297,8 +301,10 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   framenum++;
}
 
-   pipe_resource_

[Mesa-dev] [PATCH 3/3] st/vdpau: remove the delayed rendering hack(v1.1)

2017-01-11 Thread Nayan Deshmukh

the hack was introduced to avoid an extra copying
but now with dri3 we don't need it anymore

v1.1: rebasing

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/bitmap.c|  2 -
 src/gallium/state_trackers/vdpau/device.c| 50 -
 src/gallium/state_trackers/vdpau/mixer.c | 93 +++-
 src/gallium/state_trackers/vdpau/output.c|  9 ---
 src/gallium/state_trackers/vdpau/presentation.c  | 30 +++-
 src/gallium/state_trackers/vdpau/vdpau_private.h |  9 ---
 6 files changed, 52 insertions(+), 141 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/bitmap.c 
b/src/gallium/state_trackers/vdpau/bitmap.c
index fd67a98..d9ec60d 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -198,8 +198,6 @@ vlVdpBitmapSurfacePutBitsNative(VdpBitmapSurface surface,
 
pipe_mutex_lock(vlsurface->device->mutex);
 
-   vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL);
-
dst_box = RectToPipeBox(destination_rect, vlsurface->sampler_view->texture);
pipe->texture_subdata(pipe, vlsurface->sampler_view->texture, 0,
  PIPE_TRANSFER_WRITE, _box, *source_data,
diff --git a/src/gallium/state_trackers/vdpau/device.c 
b/src/gallium/state_trackers/vdpau/device.c
index 8bae064..4f4ffdf 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -327,53 +327,3 @@ vlVdpDefaultSamplerViewTemplate(struct pipe_sampler_view 
*templ, struct pipe_res
if (desc->swizzle[3] == PIPE_SWIZZLE_0)
   templ->swizzle_a = PIPE_SWIZZLE_1;
 }
-
-void
-vlVdpResolveDelayedRendering(vlVdpDevice *dev, struct pipe_surface *surface, 
struct u_rect *dirty_area)
-{
-   struct vl_compositor_state *cstate;
-   vlVdpOutputSurface *vlsurface;
-
-   assert(dev);
-
-   cstate = dev->delayed_rendering.cstate;
-   if (!cstate)
-  return;
-
-   vlsurface = vlGetDataHTAB(dev->delayed_rendering.surface);
-   if (!vlsurface)
-  return;
-
-   if (!surface) {
-  surface = vlsurface->surface;
-  dirty_area = >dirty_area;
-   }
-
-   vl_compositor_render(cstate, >compositor, surface, dirty_area, true);
-
-   dev->delayed_rendering.surface = VDP_INVALID_HANDLE;
-   dev->delayed_rendering.cstate = NULL;
-
-   /* test if we need to create a new sampler for the just filled texture */
-   if (surface->texture != vlsurface->sampler_view->texture) {
-  struct pipe_resource *res = surface->texture;
-  struct pipe_sampler_view sv_templ;
-
-  vlVdpDefaultSamplerViewTemplate(_templ, res);
-  pipe_sampler_view_reference(>sampler_view, NULL);
-  vlsurface->sampler_view = 
dev->context->create_sampler_view(dev->context, res, _templ);
-   }
-
-   return;
-}
-
-void
-vlVdpSave4DelayedRendering(vlVdpDevice *dev, VdpOutputSurface surface, struct 
vl_compositor_state *cstate)
-{
-   assert(dev);
-
-   vlVdpResolveDelayedRendering(dev, NULL, NULL);
-
-   dev->delayed_rendering.surface = surface;
-   dev->delayed_rendering.cstate = cstate;
-}
diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index 1014174..37a6fcd 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -193,8 +193,6 @@ vlVdpVideoMixerDestroy(VdpVideoMixer mixer)
 
pipe_mutex_lock(vmixer->device->mutex);
 
-   vlVdpResolveDelayedRendering(vmixer->device, NULL, NULL);
-
vlRemoveDataHTAB(mixer);
 
vl_compositor_cleanup_state(>cstate);
@@ -293,7 +291,6 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
}
 
pipe_mutex_lock(vmixer->device->mutex);
-   vlVdpResolveDelayedRendering(vmixer->device, NULL, NULL);
 
vl_compositor_clear_layers(>cstate);
 
@@ -403,64 +400,60 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
   ++layers;
}
 
-   if (!vmixer->noise_reduction.filter && !vmixer->sharpness.filter && 
!vmixer->bicubic.filter)
-  vlVdpSave4DelayedRendering(vmixer->device, destination_surface, 
>cstate);
-   else {
-  vl_compositor_render(>cstate, compositor, surface, _area, 
true);
-
-  if (vmixer->noise_reduction.filter) {
- if (!vmixer->sharpness.filter && !vmixer->bicubic.filter) {
-vl_median_filter_render(vmixer->noise_reduction.filter,
-sampler_view, dst->surface);
- } else {
-res = pipe->screen->resource_create(pipe->screen, _tmpl);
-struct pipe_sampler_view *sampler_view_temp = 
pipe->create_sampler_view(pipe, res, _templ);
-struct pipe_surface *surface_temp = pipe->create_surface(pipe, 
res, _templ);
-pipe_resource_reference(, NULL);
-
-vl_median_filter_render(vmixer->

[Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

2017-01-11 Thread Nayan Deshmukh

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
  to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
use constant number of buffer and we can avoid calls to present
extension for every frame

Reviewed and Suggested-by: Leo Liu <leo@amd.com>
Acked-by: Christian König <christian.koe...@amd.com>
Tested-by: Andy Furniss <adf.li...@gmail.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 configure.ac  |   2 +-
 src/gallium/auxiliary/vl/vl_winsys.h  |   5 ++
 src/gallium/auxiliary/vl/vl_winsys_dri3.c | 126 ++
 3 files changed, 115 insertions(+), 18 deletions(-)

diff --git a/configure.ac b/configure.ac
index d1ffb57..1b3507c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2078,7 +2078,7 @@ if test "x$enable_xvmc" = xyes -o \
 "x$enable_va" = xyes; then
 if test x"$enable_dri3" = xyes; then
 PKG_CHECK_MODULES([VL], [xcb-dri3 xcb-present xcb-sync xshmfence >= 
$XSHMFENCE_REQUIRED
- x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED])
+ xcb-xfixes x11-xcb xcb xcb-dri2 >= 
$XCBDRI2_REQUIRED])
 else
 PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED])
 fi
diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..e1f9b27 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,11 @@ struct vl_screen
void *
(*get_private)(struct vl_screen *vscreen);
 
+   void
+   (*set_back_texture_from_output)(struct vl_screen *vscreen,
+   struct pipe_resource *buffer,
+   uint32_t width, uint32_t height);
+
struct pipe_screen *pscreen;
struct pipe_loader_device *dev;
 };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..a810dea 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "loader.h"
 
@@ -71,9 +72,12 @@ struct vl_dri3_screen
xcb_special_event_t *special_event;
 
struct pipe_context *pipe;
+   struct pipe_resource *output_texture;
+   uint32_t clip_width, clip_height;
 
struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
int cur_back;
+   int next_back;
 
struct u_rect dirty_areas[BACK_BUFFER_NUM];
 
@@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
xcb_free_pixmap(scrn->conn, buffer->pixmap);
xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!scrn->output_texture)
+  pipe_resource_reference(>texture, NULL);
if (buffer->linear_texture)
pipe_resource_reference(>linear_texture, NULL);
FREE(buffer);
@@ -236,29 +241,31 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
templ.target = PIPE_TEXTURE_2D;
templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   templ.width0 = (scrn->output_texture) ?
+  scrn->output_texture->width0 : scrn->width;
+   templ.height0 = (scrn->output_texture) ?
+   scrn->output_texture->height0 : scrn->height;
templ.depth0 = 1;
templ.array_size = 1;
 
if (scrn->is_different_gpu) {
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
-);
+  buffer->texture = (scrn->output_texture) ? scrn->output_texture :
+
scrn->base.pscreen->resource_create(scrn->base.pscreen, );
   if (!buffer->texture)
  goto unmap_shm;
 
   templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED |
 PIPE_BIND_LINEAR;
-  buffer->linear_texture = 
scrn->base.pscreen->resource_create(scrn->base.pscreen,
-  );
+  buffer->linear_texture =
+  scrn->base.pscreen->resource_create(scrn->base.pscreen, );
   pixmap_buffer_texture = buffer->linear_texture;
 
   if (!buffer->

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

2017-01-11 Thread Nayan Deshmukh

On Wed, Jan 11, 2017 at 9:25 PM, Andy Furniss <adf.li...@gmail.com> wrote:
> Nayan Deshmukh wrote:
>>
>> Hi Andy,
>>
>> Can you try this patch? This should help with the tearing.
>
>
> Patch seems to be good - I get page flipping again so DC, modesetting
> and "normal" setup all work OK.
>
Great.

Thanks for the help Michel.

Christian, I will resend the series with the changes. Please review the
other 2
patches.

Regards,
Nayan
>
>>
>> diff --git a/src/gallium/state_trackers/vdpau/output.c
>> b/src/gallium/state_trackers/vdpau/output.c
>> index 48e3133..98a8011 100644
>> --- a/src/gallium/state_trackers/vdpau/output.c
>> +++ b/src/gallium/state_trackers/vdpau/output.c
>> @@ -82,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>>  res_tmpl.depth0 = 1;
>>  res_tmpl.array_size = 1;
>>  res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
>> -   PIPE_BIND_SHARED;
>> +   PIPE_BIND_SHARED | PIPE_BIND_SCANOUT;
>>  res_tmpl.usage = PIPE_USAGE_DEFAULT;
>>
>>  pipe_mutex_lock(dev->mutex);
>>
>> Regards,
>> Nayan
>>
>> On Wed, Jan 11, 2017 at 5:11 PM, Andy Furniss <adf.li...@gmail.com>
wrote:
>>>
>>> Michel Dänzer wrote:
>>>>
>>>>
>>>> On 11/01/17 05:13 PM, Nayan Deshmukh wrote:
>>>>>
>>>>>
>>>>> On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer <mic...@daenzer.net>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer <mic...@daenzer.net>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/01/17 05:50 AM, Andy Furniss wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Christian König wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> dri3 allows us to send handle of a texture directly to X
>>>>>>>>>>> so this patch allows a state tracker to directly send its
>>>>>>>>>>> texture to X to be used as back buffer and avoids extra
>>>>>>>>>>> copying
>>>>>>>>>>>
>>>>>>>>>>> v2: use clip width/height to display a portion of the surface
>>>>>>>>>>> v3: remove redundant variables, fix wrapping, rename variables
>>>>>>>>>>>handle vaapi path
>>>>>>>>>>> v3.1: we need clip_width/height for every frame so we don't need
>>>>>>>>>>>  to maintain it for each buffer instead use a global
>>>>>>>>>>> variable
>>>>>>>>>>> v4: In case of single gpu we can cache the buffers as
>>>>>>>>>>> applications
>>>>>>>>>>>use constant number of buffer and we can avoid calls to
>>>>>>>>>>> present
>>>>>>>>>>>extension for every frame
>>>>>>>>>>>
>>>>>>>>>>> Suggested-by: Leo Liu <leo@amd.com>
>>>>>>>>>>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Acked-by: Christian König <christian.koe...@amd.com>.
>>>>>>>>>>
>>>>>>>>>> Andy & Leo did you guys already had a chance to test it? To me it
>>>>>>>>>> looks
>>>>>>>>>> like this should work now.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Well there is still the tearing issue from loosing pageflips.
>>>>>>>>>
>>>>>>>>> Maybe different GPUs don't see this. I can fix by forcing perf but
>>>>>>>>>

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

2017-01-11 Thread Nayan Deshmukh

Hi Andy,

Can you try this patch? This should help with the tearing.

diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index 48e3133..98a8011 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -82,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
res_tmpl.depth0 = 1;
res_tmpl.array_size = 1;
res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
-   PIPE_BIND_SHARED;
+   PIPE_BIND_SHARED | PIPE_BIND_SCANOUT;
res_tmpl.usage = PIPE_USAGE_DEFAULT;

pipe_mutex_lock(dev->mutex);

Regards,
Nayan

On Wed, Jan 11, 2017 at 5:11 PM, Andy Furniss <adf.li...@gmail.com> wrote:
> Michel Dänzer wrote:
>>
>> On 11/01/17 05:13 PM, Nayan Deshmukh wrote:
>>>
>>> On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer <mic...@daenzer.net>
>>> wrote:
>>>>
>>>> On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
>>>>>
>>>>> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer <mic...@daenzer.net>
>>>>> wrote:
>>>>>>
>>>>>> On 06/01/17 05:50 AM, Andy Furniss wrote:
>>>>>>>
>>>>>>> Christian König wrote:
>>>>>>>>
>>>>>>>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>>>>>>>>
>>>>>>>>> dri3 allows us to send handle of a texture directly to X
>>>>>>>>> so this patch allows a state tracker to directly send its
>>>>>>>>> texture to X to be used as back buffer and avoids extra
>>>>>>>>> copying
>>>>>>>>>
>>>>>>>>> v2: use clip width/height to display a portion of the surface
>>>>>>>>> v3: remove redundant variables, fix wrapping, rename variables
>>>>>>>>>   handle vaapi path
>>>>>>>>> v3.1: we need clip_width/height for every frame so we don't need
>>>>>>>>> to maintain it for each buffer instead use a global
>>>>>>>>> variable
>>>>>>>>> v4: In case of single gpu we can cache the buffers as applications
>>>>>>>>>   use constant number of buffer and we can avoid calls to
>>>>>>>>> present
>>>>>>>>>   extension for every frame
>>>>>>>>>
>>>>>>>>> Suggested-by: Leo Liu <leo@amd.com>
>>>>>>>>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> Acked-by: Christian König <christian.koe...@amd.com>.
>>>>>>>>
>>>>>>>> Andy & Leo did you guys already had a chance to test it? To me it
>>>>>>>> looks
>>>>>>>> like this should work now.
>>>>>>>
>>>>>>>
>>>>>>> Well there is still the tearing issue from loosing pageflips.
>>>>>>>
>>>>>>> Maybe different GPUs don't see this. I can fix by forcing perf but I
>>>>>>> just tested dal and it's not even fixable running that.
>>>>>>>
>>>>>>> I guess that may not count as an issue with these patches as such if
>>>>>>> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
>>>>>>> regression until that happens.
>>>>>>
>>>>>>
>>>>>> Somebody should track down why the buffers sent for presentation in
>>>>>> this
>>>>>> case don't use the same tiling parameters as buffers used for GL via
>>>>>> DRI3.
>>>>>>
>>>>> I can look into this, but I don't know where to look exactly. Can you
>>>>> give some
>>>>> pointers to get started.
>>>>
>>>>
>>>> Looking at src/gallium/auxiliary/vl/vl_winsys_dri3.c and the patches
>>>> again, my guess is that it's due to PIPE_BIND_SCANOUT not being set when
>>>> creating the buffers that are now being directly sent to the X server
>>>> for presentation.
>>>>
>>> So the only way to avoid this is to have a PIPE_BIND_SCANOUT for the
>>> output surfaces of the state tracker. Will introducing
>>> PIPE_BIND_SCANOUT lead to performance loss for these surfaces?
>>
>>
>> Potentially, but I doubt it'll make a big difference for this use case.
>> In the future, there might be a feedback mechanism which allows
>> re-allocating the buffer with/out PIPE_BIND_SCANOUT according to the
>> current circumstances, but for now it's probably better to set it (at
>> least in cases where we don't know that the buffer can never be scanned
>> out directly) to allow for page flipping.
>
>
> Pure luck noticing this because I haven't tested modesetting driver for
> ages, but -
>
> These patches also break full screen vdpau playback when using that.
>
> Result is a screen of mostly junk with a hint of the vid - looks like
> when direct scan out fails on wayland due to tiling mismatch.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

2017-01-11 Thread Nayan Deshmukh

On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
>> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>>> On 06/01/17 05:50 AM, Andy Furniss wrote:
>>>> Christian König wrote:
>>>>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>>>>> dri3 allows us to send handle of a texture directly to X
>>>>>> so this patch allows a state tracker to directly send its
>>>>>> texture to X to be used as back buffer and avoids extra
>>>>>> copying
>>>>>>
>>>>>> v2: use clip width/height to display a portion of the surface
>>>>>> v3: remove redundant variables, fix wrapping, rename variables
>>>>>>  handle vaapi path
>>>>>> v3.1: we need clip_width/height for every frame so we don't need
>>>>>>to maintain it for each buffer instead use a global variable
>>>>>> v4: In case of single gpu we can cache the buffers as applications
>>>>>>  use constant number of buffer and we can avoid calls to present
>>>>>>  extension for every frame
>>>>>>
>>>>>> Suggested-by: Leo Liu <leo@amd.com>
>>>>>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>>>>>
>>>>> Acked-by: Christian König <christian.koe...@amd.com>.
>>>>>
>>>>> Andy & Leo did you guys already had a chance to test it? To me it looks
>>>>> like this should work now.
>>>>
>>>> Well there is still the tearing issue from loosing pageflips.
>>>>
>>>> Maybe different GPUs don't see this. I can fix by forcing perf but I
>>>> just tested dal and it's not even fixable running that.
>>>>
>>>> I guess that may not count as an issue with these patches as such if
>>>> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
>>>> regression until that happens.
>>>
>>> Somebody should track down why the buffers sent for presentation in this
>>> case don't use the same tiling parameters as buffers used for GL via DRI3.
>>>
>> I can look into this, but I don't know where to look exactly. Can you give 
>> some
>> pointers to get started.
>
> Looking at src/gallium/auxiliary/vl/vl_winsys_dri3.c and the patches
> again, my guess is that it's due to PIPE_BIND_SCANOUT not being set when
> creating the buffers that are now being directly sent to the X server
> for presentation.
>
So the only way to avoid this is to have a PIPE_BIND_SCANOUT for the
output surfaces
of the state tracker. Will introducing PIPE_BIND_SCANOUT lead to
performance loss
for these surfaces?

It will probably depend on the way drivers handle PIPE_BIND_SCANOUT.

Regards,
Nayan.

>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

2017-01-10 Thread Nayan Deshmukh

On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> On 06/01/17 05:50 AM, Andy Furniss wrote:
>> Christian König wrote:
>>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>>> dri3 allows us to send handle of a texture directly to X
>>>> so this patch allows a state tracker to directly send its
>>>> texture to X to be used as back buffer and avoids extra
>>>> copying
>>>>
>>>> v2: use clip width/height to display a portion of the surface
>>>> v3: remove redundant variables, fix wrapping, rename variables
>>>>  handle vaapi path
>>>> v3.1: we need clip_width/height for every frame so we don't need
>>>>to maintain it for each buffer instead use a global variable
>>>> v4: In case of single gpu we can cache the buffers as applications
>>>>  use constant number of buffer and we can avoid calls to present
>>>>  extension for every frame
>>>>
>>>> Suggested-by: Leo Liu <leo@amd.com>
>>>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>>>
>>> Acked-by: Christian König <christian.koe...@amd.com>.
>>>
>>> Andy & Leo did you guys already had a chance to test it? To me it looks
>>> like this should work now.
>>
>> Well there is still the tearing issue from loosing pageflips.
>>
>> Maybe different GPUs don't see this. I can fix by forcing perf but I
>> just tested dal and it's not even fixable running that.
>>
>> I guess that may not count as an issue with these patches as such if
>> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
>> regression until that happens.
>
> Somebody should track down why the buffers sent for presentation in this
> case don't use the same tiling parameters as buffers used for GL via DRI3.
>
I can look into this, but I don't know where to look exactly. Can you give some
pointers to get started.

Regards,
Nayan
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

2017-01-10 Thread Nayan Deshmukh

On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss <adf.li...@gmail.com> wrote:
> Christian König wrote:
>>
>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>>
>>> dri3 allows us to send handle of a texture directly to X
>>> so this patch allows a state tracker to directly send its
>>> texture to X to be used as back buffer and avoids extra
>>> copying
>>>
>>> v2: use clip width/height to display a portion of the surface
>>> v3: remove redundant variables, fix wrapping, rename variables
>>>  handle vaapi path
>>> v3.1: we need clip_width/height for every frame so we don't need
>>>to maintain it for each buffer instead use a global variable
>>> v4: In case of single gpu we can cache the buffers as applications
>>>  use constant number of buffer and we can avoid calls to present
>>>  extension for every frame
>>>
>>> Suggested-by: Leo Liu <leo@amd.com>
>>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>>
>>
>> Acked-by: Christian König <christian.koe...@amd.com>.
>>
>> Andy & Leo did you guys already had a chance to test it? To me it looks
>> like this should work now.
>
>
> Well there is still the tearing issue from loosing pageflips.
>
> Maybe different GPUs don't see this. I can fix by forcing perf but I
> just tested dal and it's not even fixable running that.
>
> I guess that may not count as an issue with these patches as such if
> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
> regression until that happens.
>

That's bad. It should have improved the speed due to less copying involved.
But it seems there are some problems in the patch. It may be that somehow we
make calls to present extension on every frame.

Andy you are using dri3 for testing, right?

Leo, did you also experience tearing issues?

Regards,
Nayan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/va: fix incorrect argument in vl_compositor_cleanup

2017-01-05 Thread Nayan Deshmukh

This fixes the mistake introduced in commit
b6737a8bcd03ea68952799144c0c6e6e6679bee9

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/va/context.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 884b794..357c9be 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -184,7 +184,7 @@ error_csc_matrix:
vl_compositor_cleanup_state(>cstate);
 
 error_compositor_state:
-   vl_compositor_cleanup(>cstate);
+   vl_compositor_cleanup(>compositor);
 
 error_compositor:
handle_table_destroy(drv->htab);
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

2017-01-04 Thread Nayan Deshmukh

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
  to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
use constant number of buffer and we can avoid calls to present
extension for every frame

Suggested-by: Leo Liu <leo@amd.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 configure.ac  |   2 +-
 src/gallium/auxiliary/vl/vl_winsys.h  |   5 ++
 src/gallium/auxiliary/vl/vl_winsys_dri3.c | 126 ++
 3 files changed, 115 insertions(+), 18 deletions(-)

diff --git a/configure.ac b/configure.ac
index 799f5eb..94aac34 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2078,7 +2078,7 @@ if test "x$enable_xvmc" = xyes -o \
 "x$enable_va" = xyes; then
 if test x"$enable_dri3" = xyes; then
 PKG_CHECK_MODULES([VL], [xcb-dri3 xcb-present xcb-sync xshmfence >= 
$XSHMFENCE_REQUIRED
- x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED])
+ xcb-xfixes x11-xcb xcb xcb-dri2 >= 
$XCBDRI2_REQUIRED])
 else
 PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED])
 fi
diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..e1f9b27 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,11 @@ struct vl_screen
void *
(*get_private)(struct vl_screen *vscreen);
 
+   void
+   (*set_back_texture_from_output)(struct vl_screen *vscreen,
+   struct pipe_resource *buffer,
+   uint32_t width, uint32_t height);
+
struct pipe_screen *pscreen;
struct pipe_loader_device *dev;
 };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..a810dea 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "loader.h"
 
@@ -71,9 +72,12 @@ struct vl_dri3_screen
xcb_special_event_t *special_event;
 
struct pipe_context *pipe;
+   struct pipe_resource *output_texture;
+   uint32_t clip_width, clip_height;
 
struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
int cur_back;
+   int next_back;
 
struct u_rect dirty_areas[BACK_BUFFER_NUM];
 
@@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
xcb_free_pixmap(scrn->conn, buffer->pixmap);
xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!scrn->output_texture)
+  pipe_resource_reference(>texture, NULL);
if (buffer->linear_texture)
pipe_resource_reference(>linear_texture, NULL);
FREE(buffer);
@@ -236,29 +241,31 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
templ.target = PIPE_TEXTURE_2D;
templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   templ.width0 = (scrn->output_texture) ?
+  scrn->output_texture->width0 : scrn->width;
+   templ.height0 = (scrn->output_texture) ?
+   scrn->output_texture->height0 : scrn->height;
templ.depth0 = 1;
templ.array_size = 1;
 
if (scrn->is_different_gpu) {
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
-);
+  buffer->texture = (scrn->output_texture) ? scrn->output_texture :
+
scrn->base.pscreen->resource_create(scrn->base.pscreen, );
   if (!buffer->texture)
  goto unmap_shm;
 
   templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED |
 PIPE_BIND_LINEAR;
-  buffer->linear_texture = 
scrn->base.pscreen->resource_create(scrn->base.pscreen,
-  );
+  buffer->linear_texture =
+  scrn->base.pscreen->resource_create(scrn->base.pscreen, );
   pixmap_buffer_texture = buffer->linear_texture;
 
   if (!buffer->linear_texture)
  goto no_linear_texture;
} else {
   templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
-  buffer->texture = scrn->base.pscreen->reso

[Mesa-dev] [PATCH 2/3] st/vdpau: use dri3 to direclty send the buffer to X(v1.1)

2017-01-04 Thread Nayan Deshmukh

this avoids an extra copy which occurs in case of dri2

v1.1: fallback to dri2 if dri3 fails to initialize

Suggested-by: Christian König <christian.koe...@amd.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/presentation.c | 58 ++---
 1 file changed, 32 insertions(+), 26 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index f35d73a..b2c8aea 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -231,43 +231,47 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
vscreen = pq->device->vscreen;
 
pipe_mutex_lock(pq->device->mutex);
+   if (vscreen->set_back_texture_from_output)
+  vscreen->set_back_texture_from_output(vscreen, surf->surface->texture, 
clip_width, clip_height);
tex = vscreen->texture_from_drawable(vscreen, (void *)pq->drawable);
if (!tex) {
   pipe_mutex_unlock(pq->device->mutex);
   return VDP_STATUS_INVALID_HANDLE;
}
 
-   dirty_area = vscreen->get_dirty_area(vscreen);
+   if (!vscreen->set_back_texture_from_output) {
+  dirty_area = vscreen->get_dirty_area(vscreen);
 
-   memset(_templ, 0, sizeof(surf_templ));
-   surf_templ.format = tex->format;
-   surf_draw = pipe->create_surface(pipe, tex, _templ);
+  memset(_templ, 0, sizeof(surf_templ));
+  surf_templ.format = tex->format;
+  surf_draw = pipe->create_surface(pipe, tex, _templ);
 
-   dst_clip.x0 = 0;
-   dst_clip.y0 = 0;
-   dst_clip.x1 = clip_width ? clip_width : surf_draw->width;
-   dst_clip.y1 = clip_height ? clip_height : surf_draw->height;
+  dst_clip.x0 = 0;
+  dst_clip.y0 = 0;
+  dst_clip.x1 = clip_width ? clip_width : surf_draw->width;
+  dst_clip.y1 = clip_height ? clip_height : surf_draw->height;
 
-   if (pq->device->delayed_rendering.surface == surface &&
-   dst_clip.x1 == surf_draw->width && dst_clip.y1 == surf_draw->height) {
+  if (pq->device->delayed_rendering.surface == surface &&
+  dst_clip.x1 == surf_draw->width && dst_clip.y1 == surf_draw->height) 
{
 
-  // TODO: we correctly support the clipping here, but not the pq 
background color in the clipped area
-  cstate = pq->device->delayed_rendering.cstate;
-  vl_compositor_set_dst_clip(cstate, _clip);
-  vlVdpResolveDelayedRendering(pq->device, surf_draw, dirty_area);
+ // TODO: we correctly support the clipping here, but not the pq 
background color in the clipped area
+ cstate = pq->device->delayed_rendering.cstate;
+ vl_compositor_set_dst_clip(cstate, _clip);
+ vlVdpResolveDelayedRendering(pq->device, surf_draw, dirty_area);
 
-   } else {
-  vlVdpResolveDelayedRendering(pq->device, NULL, NULL);
+  } else {
+ vlVdpResolveDelayedRendering(pq->device, NULL, NULL);
 
-  src_rect.x0 = 0;
-  src_rect.y0 = 0;
-  src_rect.x1 = surf_draw->width;
-  src_rect.y1 = surf_draw->height;
+ src_rect.x0 = 0;
+ src_rect.y0 = 0;
+ src_rect.x1 = surf_draw->width;
+ src_rect.y1 = surf_draw->height;
 
-  vl_compositor_clear_layers(cstate);
-  vl_compositor_set_rgba_layer(cstate, compositor, 0, surf->sampler_view, 
_rect, NULL, NULL);
-  vl_compositor_set_dst_clip(cstate, _clip);
-  vl_compositor_render(cstate, compositor, surf_draw, dirty_area, true);
+ vl_compositor_clear_layers(cstate);
+ vl_compositor_set_rgba_layer(cstate, compositor, 0, 
surf->sampler_view, _rect, NULL, NULL);
+ vl_compositor_set_dst_clip(cstate, _clip);
+ vl_compositor_render(cstate, compositor, surf_draw, dirty_area, true);
+  }
}
 
vscreen->set_next_timestamp(vscreen, earliest_presentation_time);
@@ -297,8 +301,10 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   framenum++;
}
 
-   pipe_resource_reference(, NULL);
-   pipe_surface_reference(_draw, NULL);
+   if (!vscreen->set_back_texture_from_output) {
+  pipe_resource_reference(, NULL);
+  pipe_surface_reference(_draw, NULL);
+   }
pipe_mutex_unlock(pq->device->mutex);
 
return VDP_STATUS_OK;
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] st/vdpau: remove the delayed rendering hack(v1.1)

2017-01-04 Thread Nayan Deshmukh

the hack was introduced to avoid an extra copying
but now with dri3 we don't need it anymore

v1.1: rebasing

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/bitmap.c|  2 -
 src/gallium/state_trackers/vdpau/device.c| 50 -
 src/gallium/state_trackers/vdpau/mixer.c | 93 +++-
 src/gallium/state_trackers/vdpau/output.c|  9 ---
 src/gallium/state_trackers/vdpau/presentation.c  | 30 +++-
 src/gallium/state_trackers/vdpau/vdpau_private.h |  9 ---
 6 files changed, 52 insertions(+), 141 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/bitmap.c 
b/src/gallium/state_trackers/vdpau/bitmap.c
index fd67a98..d9ec60d 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -198,8 +198,6 @@ vlVdpBitmapSurfacePutBitsNative(VdpBitmapSurface surface,
 
pipe_mutex_lock(vlsurface->device->mutex);
 
-   vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL);
-
dst_box = RectToPipeBox(destination_rect, vlsurface->sampler_view->texture);
pipe->texture_subdata(pipe, vlsurface->sampler_view->texture, 0,
  PIPE_TRANSFER_WRITE, _box, *source_data,
diff --git a/src/gallium/state_trackers/vdpau/device.c 
b/src/gallium/state_trackers/vdpau/device.c
index 8bae064..4f4ffdf 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -327,53 +327,3 @@ vlVdpDefaultSamplerViewTemplate(struct pipe_sampler_view 
*templ, struct pipe_res
if (desc->swizzle[3] == PIPE_SWIZZLE_0)
   templ->swizzle_a = PIPE_SWIZZLE_1;
 }
-
-void
-vlVdpResolveDelayedRendering(vlVdpDevice *dev, struct pipe_surface *surface, 
struct u_rect *dirty_area)
-{
-   struct vl_compositor_state *cstate;
-   vlVdpOutputSurface *vlsurface;
-
-   assert(dev);
-
-   cstate = dev->delayed_rendering.cstate;
-   if (!cstate)
-  return;
-
-   vlsurface = vlGetDataHTAB(dev->delayed_rendering.surface);
-   if (!vlsurface)
-  return;
-
-   if (!surface) {
-  surface = vlsurface->surface;
-  dirty_area = >dirty_area;
-   }
-
-   vl_compositor_render(cstate, >compositor, surface, dirty_area, true);
-
-   dev->delayed_rendering.surface = VDP_INVALID_HANDLE;
-   dev->delayed_rendering.cstate = NULL;
-
-   /* test if we need to create a new sampler for the just filled texture */
-   if (surface->texture != vlsurface->sampler_view->texture) {
-  struct pipe_resource *res = surface->texture;
-  struct pipe_sampler_view sv_templ;
-
-  vlVdpDefaultSamplerViewTemplate(_templ, res);
-  pipe_sampler_view_reference(>sampler_view, NULL);
-  vlsurface->sampler_view = 
dev->context->create_sampler_view(dev->context, res, _templ);
-   }
-
-   return;
-}
-
-void
-vlVdpSave4DelayedRendering(vlVdpDevice *dev, VdpOutputSurface surface, struct 
vl_compositor_state *cstate)
-{
-   assert(dev);
-
-   vlVdpResolveDelayedRendering(dev, NULL, NULL);
-
-   dev->delayed_rendering.surface = surface;
-   dev->delayed_rendering.cstate = cstate;
-}
diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index 1014174..37a6fcd 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -193,8 +193,6 @@ vlVdpVideoMixerDestroy(VdpVideoMixer mixer)
 
pipe_mutex_lock(vmixer->device->mutex);
 
-   vlVdpResolveDelayedRendering(vmixer->device, NULL, NULL);
-
vlRemoveDataHTAB(mixer);
 
vl_compositor_cleanup_state(>cstate);
@@ -293,7 +291,6 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
}
 
pipe_mutex_lock(vmixer->device->mutex);
-   vlVdpResolveDelayedRendering(vmixer->device, NULL, NULL);
 
vl_compositor_clear_layers(>cstate);
 
@@ -403,64 +400,60 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
   ++layers;
}
 
-   if (!vmixer->noise_reduction.filter && !vmixer->sharpness.filter && 
!vmixer->bicubic.filter)
-  vlVdpSave4DelayedRendering(vmixer->device, destination_surface, 
>cstate);
-   else {
-  vl_compositor_render(>cstate, compositor, surface, _area, 
true);
-
-  if (vmixer->noise_reduction.filter) {
- if (!vmixer->sharpness.filter && !vmixer->bicubic.filter) {
-vl_median_filter_render(vmixer->noise_reduction.filter,
-sampler_view, dst->surface);
- } else {
-res = pipe->screen->resource_create(pipe->screen, _tmpl);
-struct pipe_sampler_view *sampler_view_temp = 
pipe->create_sampler_view(pipe, res, _templ);
-struct pipe_surface *surface_temp = pipe->create_surface(pipe, 
res, _templ);
-pipe_resource_reference(, NULL);
-
-vl_median_filter_render(vmixer->

[Mesa-dev] [PATCH 2/3] st/vdpau: error handling

2017-01-03 Thread Nayan Deshmukh

handle the cases when vl_compositor_set_csc_matrix(),
vl_compositor_init_state() and vl_compositor_init() fail

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
Reviewed-by: Christian König <christian.koe...@amd.com>
---
 src/gallium/state_trackers/vdpau/device.c |  8 +-
 src/gallium/state_trackers/vdpau/mixer.c  | 43 +++
 src/gallium/state_trackers/vdpau/output.c | 14 +++---
 3 files changed, 50 insertions(+), 15 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/device.c 
b/src/gallium/state_trackers/vdpau/device.c
index 81b7582..8bae064 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -128,13 +128,19 @@ vdp_imp_device_create_x11(Display *display, int screen, 
VdpDevice *device,
   goto no_handle;
}
 
-   vl_compositor_init(>compositor, dev->context);
+   if (!vl_compositor_init(>compositor, dev->context)) {
+   ret = VDP_STATUS_ERROR;
+   goto no_compositor;
+   }
+
pipe_mutex_init(dev->mutex);
 
*get_proc_address = 
 
return VDP_STATUS_OK;
 
+no_compositor:
+   vlRemoveDataHTAB(*device);
 no_handle:
pipe_sampler_view_reference(>dummy_sv, NULL);
 no_resource:
diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index aca43c1..1014174 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -65,11 +65,18 @@ vlVdpVideoMixerCreate(VdpDevice device,
 
pipe_mutex_lock(dev->mutex);
 
-   vl_compositor_init_state(>cstate, dev->context);
+   if (!vl_compositor_init_state(>cstate, dev->context)) {
+  ret = VDP_STATUS_ERROR;
+  goto no_compositor_state;
+   }
 
vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_BT_601, NULL, true, >csc);
-   if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE))
-  vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc, 1.0f, 0.0f);
+   if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE)) {
+  if (!vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc, 1.0f, 0.0f)) {
+ ret = VDP_STATUS_ERROR;
+ goto err_csc_matrix;
+  }
+   }
 
*mixer = vlAddDataHTAB(vmixer);
if (*mixer == 0) {
@@ -163,7 +170,9 @@ no_params:
vlRemoveDataHTAB(*mixer);
 
 no_handle:
+err_csc_matrix:
vl_compositor_cleanup_state(>cstate);
+no_compositor_state:
pipe_mutex_unlock(dev->mutex);
DeviceReference(>device, NULL);
FREE(vmixer);
@@ -690,8 +699,11 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer,
   case VDP_VIDEO_MIXER_FEATURE_LUMA_KEY:
  vmixer->luma_key.enabled = feature_enables[i];
  if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE))
-vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc,
- vmixer->luma_key.luma_min, 
vmixer->luma_key.luma_max);
+if (!vl_compositor_set_csc_matrix(>cstate, (const 
vl_csc_matrix *)>csc,
+vmixer->luma_key.luma_min, vmixer->luma_key.luma_max)) 
{
+   pipe_mutex_unlock(vmixer->device->mutex);
+   return VDP_STATUS_ERROR;
+}
  break;
 
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
@@ -810,8 +822,11 @@ vlVdpVideoMixerSetAttributeValues(VdpVideoMixer mixer,
  else
 memcpy(vmixer->csc, vdp_csc, sizeof(vl_csc_matrix));
  if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE))
-vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc,
- vmixer->luma_key.luma_min, 
vmixer->luma_key.luma_max);
+if (!vl_compositor_set_csc_matrix(>cstate, (const 
vl_csc_matrix *)>csc,
+ vmixer->luma_key.luma_min, 
vmixer->luma_key.luma_max)) {
+   ret = VDP_STATUS_ERROR;
+   goto fail;
+}
  break;
 
   case VDP_VIDEO_MIXER_ATTRIBUTE_NOISE_REDUCTION_LEVEL:
@@ -834,8 +849,11 @@ vlVdpVideoMixerSetAttributeValues(VdpVideoMixer mixer,
  }
  vmixer->luma_key.luma_min = val;
  if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE))
-vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc,
- vmixer->luma_key.luma_min, 
vmixer->luma_key.luma_max);
+if (!vl_compositor_set_csc_matrix(>cstate, (const 
vl_csc_matrix *)>csc,
+vmixer->luma_key.luma_min, vmixer->luma_key.luma_max)) 
{
+   ret = VDP_STATUS_ERROR;
+   goto fail;
+}
  break;
 
   case VDP_VIDEO_MIXER_ATTRIBUTE_LUMA_KEY_MAX_LUMA:
@@ -846,8 +864,11 @@ vlVdpVideoMixerSetAttributeValues(VdpVideoMi

[Mesa-dev] [PATCH 1/3] vl/compositor: implement error handling

2017-01-03 Thread Nayan Deshmukh

pipe_buffer_map and pipe_buffer_create may return NULL

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
Reviewed-by: Christian König <christian.koe...@amd.com>
---
 src/gallium/auxiliary/vl/vl_compositor.c | 13 +++--
 src/gallium/auxiliary/vl/vl_compositor.h |  2 +-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
b/src/gallium/auxiliary/vl/vl_compositor.c
index 03a0a64..297c3ab 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -919,7 +919,7 @@ vl_compositor_cleanup(struct vl_compositor *c)
cleanup_pipe_state(c);
 }
 
-void
+bool
 vl_compositor_set_csc_matrix(struct vl_compositor_state *s,
  vl_csc_matrix const *matrix,
  float luma_min, float luma_max)
@@ -932,6 +932,9 @@ vl_compositor_set_csc_matrix(struct vl_compositor_state *s,
PIPE_TRANSFER_WRITE | 
PIPE_TRANSFER_DISCARD_RANGE,
_transfer);
 
+   if (!ptr)
+  return false;
+
memcpy(ptr, matrix, sizeof(vl_csc_matrix));
 
ptr += sizeof(vl_csc_matrix)/sizeof(float);
@@ -939,6 +942,8 @@ vl_compositor_set_csc_matrix(struct vl_compositor_state *s,
ptr[1] = luma_max;
 
pipe_buffer_unmap(s->pipe, buf_transfer);
+
+   return true;
 }
 
 void
@@ -1246,10 +1251,14 @@ vl_compositor_init_state(struct vl_compositor_state *s, 
struct pipe_context *pip
   sizeof(csc_matrix) + 2*sizeof(float)
);
 
+   if (!s->csc_matrix)
+  return false;
+
vl_compositor_clear_layers(s);
 
vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_IDENTITY, NULL, true, _matrix);
-   vl_compositor_set_csc_matrix(s, (const vl_csc_matrix *)_matrix, 1.0f, 
0.0f);
+   if (!vl_compositor_set_csc_matrix(s, (const vl_csc_matrix *)_matrix, 
1.0f, 0.0f))
+  return false;
 
return true;
 }
diff --git a/src/gallium/auxiliary/vl/vl_compositor.h 
b/src/gallium/auxiliary/vl/vl_compositor.h
index ceab5e0..5460619 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.h
+++ b/src/gallium/auxiliary/vl/vl_compositor.h
@@ -142,7 +142,7 @@ vl_compositor_init_state(struct vl_compositor_state *state, 
struct pipe_context
 /**
  * set yuv -> rgba conversion matrix
  */
-void
+bool
 vl_compositor_set_csc_matrix(struct vl_compositor_state *settings,
  const vl_csc_matrix *matrix,
  float luma_min, float luma_max);
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] st/va: error handling

2017-01-03 Thread Nayan Deshmukh

handle the cases when vl_compositor_set_csc_matrix(),
vl_compositor_init_state() and vl_compositor_init() fail

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
Reviewed-by: Christian König <christian.koe...@amd.com>
---
 src/gallium/state_trackers/va/context.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 65ba7db..884b794 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -155,11 +155,14 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
if (!drv->htab)
   goto error_htab;
 
-   vl_compositor_init(>compositor, drv->pipe);
-   vl_compositor_init_state(>cstate, drv->pipe);
+   if (!vl_compositor_init(>compositor, drv->pipe))
+  goto error_compositor;
+   if (!vl_compositor_init_state(>cstate, drv->pipe))
+  goto error_compositor_state;
 
vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_BT_601, NULL, true, >csc);
-   vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc, 1.0f, 0.0f);
+   if (!vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc, 1.0f, 0.0f))
+  goto error_csc_matrix;
pipe_mutex_init(drv->mutex);
 
ctx->pDriverData = (void *)drv;
@@ -177,6 +180,15 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
 
return VA_STATUS_SUCCESS;
 
+error_csc_matrix:
+   vl_compositor_cleanup_state(>cstate);
+
+error_compositor_state:
+   vl_compositor_cleanup(>cstate);
+
+error_compositor:
+   handle_table_destroy(drv->htab);
+
 error_htab:
drv->pipe->destroy(drv->pipe);
 
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/3] error handling

2017-01-03 Thread Nayan Deshmukh

Hi Christian,

Can you please push the patches for me.

Regards,
Nayan

Nayan Deshmukh (3):
  vl/compositor: implement error handling
  st/vdpau: error handling
  st/va: error handling

 src/gallium/auxiliary/vl/vl_compositor.c  | 13 --
 src/gallium/auxiliary/vl/vl_compositor.h  |  2 +-
 src/gallium/state_trackers/va/context.c   | 18 ++---
 src/gallium/state_trackers/vdpau/device.c |  8 +-
 src/gallium/state_trackers/vdpau/mixer.c  | 43 +++
 src/gallium/state_trackers/vdpau/output.c | 14 +++---
 6 files changed, 77 insertions(+), 21 deletions(-)

-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] st/xvmc: use goto to make code more readable (v2)

2016-12-22 Thread Nayan Deshmukh

On Thu, Dec 22, 2016 at 4:56 PM, Christian König
<deathsim...@vodafone.de> wrote:
> Am 16.12.2016 um 12:58 schrieb Nayan Deshmukh:
>>
>> v2: add missing semicolon
>>
>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>
>
> Patch #2-#4 are Reviewed-by: Christian König <christian.koe...@amd.com>.
>
> For patch #1 and #5 I'm a bit hesitated to add them without testing.

I agree with you, maybe we can commit patch #2-#4 for now and meanwhile I will
try to do some testing with XvMC.

> XvMC isn't widely used any more, but we should still try to not break it.
>
> Maybe you can try to come up with something?
I am not able to run XvMC on my system now, but I'll try it some more later in
the evening.

Regards,
Nayan
>
> Regards,
> Christian.
>
>
>> ---
>>   src/gallium/state_trackers/xvmc/context.c | 40
>> +++
>>   1 file changed, 19 insertions(+), 21 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/xvmc/context.c
>> b/src/gallium/state_trackers/xvmc/context.c
>> index e9014c8..fb9f435 100644
>> --- a/src/gallium/state_trackers/xvmc/context.c
>> +++ b/src/gallium/state_trackers/xvmc/context.c
>> @@ -226,23 +226,20 @@ Status XvMCCreateContext(Display *dpy, XvPortID
>> port, int surface_type_id,
>>context_priv = CALLOC(1, sizeof(XvMCContextPrivate));
>>  if (!context_priv)
>> -  return BadAlloc;
>> +  goto no_context_priv;
>>/* TODO: Reuse screen if process creates another context */
>>  vscreen = vl_dri2_screen_create(dpy, scrn);
>>if (!vscreen) {
>> XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL screen.\n");
>> -  FREE(context_priv);
>> -  return BadAlloc;
>> +  goto no_screen;
>>  }
>>pipe = vscreen->pscreen->context_create(vscreen->pscreen, vscreen,
>> 0);
>>  if (!pipe) {
>> XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL context.\n");
>> -  vscreen->destroy(vscreen);
>> -  FREE(context_priv);
>> -  return BadAlloc;
>> +  goto no_context;
>>  }
>>templat.profile = ProfileToPipe(mc_type);
>> @@ -257,29 +254,17 @@ Status XvMCCreateContext(Display *dpy, XvPortID
>> port, int surface_type_id,
>>if (!context_priv->decoder) {
>> XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL decoder.\n");
>> -  pipe->destroy(pipe);
>> -  vscreen->destroy(vscreen);
>> -  FREE(context_priv);
>> -  return BadAlloc;
>> +  goto no_decoder;
>>  }
>>if (!vl_compositor_init(_priv->compositor, pipe)) {
>> XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor.\n");
>> -  context_priv->decoder->destroy(context_priv->decoder);
>> -  pipe->destroy(pipe);
>> -  vscreen->destroy(vscreen);
>> -  FREE(context_priv);
>> -  return BadAlloc;
>> +  goto no_compositor;
>>  }
>>if (!vl_compositor_init_state(_priv->cstate, pipe)) {
>> XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor
>> state.\n");
>> -  vl_compositor_cleanup(_priv->compositor);
>> -  context_priv->decoder->destroy(context_priv->decoder);
>> -  pipe->destroy(pipe);
>> -  vscreen->destroy(vscreen);
>> -  FREE(context_priv);
>> -  return BadAlloc;
>> +  goto no_compositor_state;
>>  }
>> @@ -313,6 +298,19 @@ Status XvMCCreateContext(Display *dpy, XvPortID
>> port, int surface_type_id,
>>  XVMC_MSG(XVMC_TRACE, "[XvMC] Context %p created.\n", context);
>>return Success;
>> +
>> +no_compositor_state:
>> +   vl_compositor_cleanup(_priv->compositor);
>> +no_compositor:
>> +   context_priv->decoder->destroy(context_priv->decoder);
>> +no_decoder:
>> +   pipe->destroy(pipe);
>> +no_context:
>> +   vscreen->destroy(vscreen);
>> +no_screen:
>> +   FREE(context_priv);
>> +no_context_priv:
>> +   return BadAlloc;
>>   }
>> PUBLIC
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/5] st/xvmc: error handling

2016-12-16 Thread Nayan Deshmukh

vl_compositor_set_csc_matrix may return false

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/xvmc/attributes.c | 3 ++-
 src/gallium/state_trackers/xvmc/context.c| 4 +++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/xvmc/attributes.c 
b/src/gallium/state_trackers/xvmc/attributes.c
index 3757056..1133fc2 100644
--- a/src/gallium/state_trackers/xvmc/attributes.c
+++ b/src/gallium/state_trackers/xvmc/attributes.c
@@ -110,7 +110,8 @@ Status XvMCSetAttribute(Display *dpy, XvMCContext *context, 
Atom attribute, int
   context_priv->color_standard,
   _priv->procamp, true, 
);
-   vl_compositor_set_csc_matrix(_priv->cstate, (const vl_csc_matrix 
*), 1.0f, 0.0f);
+   if (!vl_compositor_set_csc_matrix(_priv->cstate, (const 
vl_csc_matrix *), 1.0f, 0.0f))
+  return BadAlloc;
 
XVMC_MSG(XVMC_TRACE, "[XvMC] Set attribute %s to value %d.\n", attr, value);
 
diff --git a/src/gallium/state_trackers/xvmc/context.c 
b/src/gallium/state_trackers/xvmc/context.c
index fb9f435..fac3fde 100644
--- a/src/gallium/state_trackers/xvmc/context.c
+++ b/src/gallium/state_trackers/xvmc/context.c
@@ -278,7 +278,8 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
   context_priv->color_standard,
   _priv->procamp, true, 
);
-   vl_compositor_set_csc_matrix(_priv->cstate, (const vl_csc_matrix 
*), 1.0f, 0.0f);
+   if (!vl_compositor_set_csc_matrix(_priv->cstate, (const 
vl_csc_matrix *), 1.0f, 0.0f))
+  goto err_csc_matrix;
 
context_priv->vscreen = vscreen;
context_priv->pipe = pipe;
@@ -299,6 +300,7 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
 
return Success;
 
+err_csc_matrix:
 no_compositor_state:
vl_compositor_cleanup(_priv->compositor);
 no_compositor:
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/5] st/va: error handling

2016-12-16 Thread Nayan Deshmukh

handle the cases when vl_compositor_set_csc_matrix(),
vl_compositor_init_state() and vl_compositor_init() fail

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/va/context.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 65ba7db..884b794 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -155,11 +155,14 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
if (!drv->htab)
   goto error_htab;
 
-   vl_compositor_init(>compositor, drv->pipe);
-   vl_compositor_init_state(>cstate, drv->pipe);
+   if (!vl_compositor_init(>compositor, drv->pipe))
+  goto error_compositor;
+   if (!vl_compositor_init_state(>cstate, drv->pipe))
+  goto error_compositor_state;
 
vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_BT_601, NULL, true, >csc);
-   vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc, 1.0f, 0.0f);
+   if (!vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc, 1.0f, 0.0f))
+  goto error_csc_matrix;
pipe_mutex_init(drv->mutex);
 
ctx->pDriverData = (void *)drv;
@@ -177,6 +180,15 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
 
return VA_STATUS_SUCCESS;
 
+error_csc_matrix:
+   vl_compositor_cleanup_state(>cstate);
+
+error_compositor_state:
+   vl_compositor_cleanup(>cstate);
+
+error_compositor:
+   handle_table_destroy(drv->htab);
+
 error_htab:
drv->pipe->destroy(drv->pipe);
 
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/5] st/vdpau: error handling

2016-12-16 Thread Nayan Deshmukh

handle the cases when vl_compositor_set_csc_matrix(),
vl_compositor_init_state() and vl_compositor_init() fail

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/device.c |  8 +-
 src/gallium/state_trackers/vdpau/mixer.c  | 43 +++
 src/gallium/state_trackers/vdpau/output.c | 14 +++---
 3 files changed, 50 insertions(+), 15 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/device.c 
b/src/gallium/state_trackers/vdpau/device.c
index 81b7582..8bae064 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -128,13 +128,19 @@ vdp_imp_device_create_x11(Display *display, int screen, 
VdpDevice *device,
   goto no_handle;
}
 
-   vl_compositor_init(>compositor, dev->context);
+   if (!vl_compositor_init(>compositor, dev->context)) {
+   ret = VDP_STATUS_ERROR;
+   goto no_compositor;
+   }
+
pipe_mutex_init(dev->mutex);
 
*get_proc_address = 
 
return VDP_STATUS_OK;
 
+no_compositor:
+   vlRemoveDataHTAB(*device);
 no_handle:
pipe_sampler_view_reference(>dummy_sv, NULL);
 no_resource:
diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index aca43c1..1014174 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -65,11 +65,18 @@ vlVdpVideoMixerCreate(VdpDevice device,
 
pipe_mutex_lock(dev->mutex);
 
-   vl_compositor_init_state(>cstate, dev->context);
+   if (!vl_compositor_init_state(>cstate, dev->context)) {
+  ret = VDP_STATUS_ERROR;
+  goto no_compositor_state;
+   }
 
vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_BT_601, NULL, true, >csc);
-   if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE))
-  vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc, 1.0f, 0.0f);
+   if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE)) {
+  if (!vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc, 1.0f, 0.0f)) {
+ ret = VDP_STATUS_ERROR;
+ goto err_csc_matrix;
+  }
+   }
 
*mixer = vlAddDataHTAB(vmixer);
if (*mixer == 0) {
@@ -163,7 +170,9 @@ no_params:
vlRemoveDataHTAB(*mixer);
 
 no_handle:
+err_csc_matrix:
vl_compositor_cleanup_state(>cstate);
+no_compositor_state:
pipe_mutex_unlock(dev->mutex);
DeviceReference(>device, NULL);
FREE(vmixer);
@@ -690,8 +699,11 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer,
   case VDP_VIDEO_MIXER_FEATURE_LUMA_KEY:
  vmixer->luma_key.enabled = feature_enables[i];
  if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE))
-vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc,
- vmixer->luma_key.luma_min, 
vmixer->luma_key.luma_max);
+if (!vl_compositor_set_csc_matrix(>cstate, (const 
vl_csc_matrix *)>csc,
+vmixer->luma_key.luma_min, vmixer->luma_key.luma_max)) 
{
+   pipe_mutex_unlock(vmixer->device->mutex);
+   return VDP_STATUS_ERROR;
+}
  break;
 
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
@@ -810,8 +822,11 @@ vlVdpVideoMixerSetAttributeValues(VdpVideoMixer mixer,
  else
 memcpy(vmixer->csc, vdp_csc, sizeof(vl_csc_matrix));
  if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE))
-vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc,
- vmixer->luma_key.luma_min, 
vmixer->luma_key.luma_max);
+if (!vl_compositor_set_csc_matrix(>cstate, (const 
vl_csc_matrix *)>csc,
+ vmixer->luma_key.luma_min, 
vmixer->luma_key.luma_max)) {
+   ret = VDP_STATUS_ERROR;
+   goto fail;
+}
  break;
 
   case VDP_VIDEO_MIXER_ATTRIBUTE_NOISE_REDUCTION_LEVEL:
@@ -834,8 +849,11 @@ vlVdpVideoMixerSetAttributeValues(VdpVideoMixer mixer,
  }
  vmixer->luma_key.luma_min = val;
  if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE))
-vl_compositor_set_csc_matrix(>cstate, (const vl_csc_matrix 
*)>csc,
- vmixer->luma_key.luma_min, 
vmixer->luma_key.luma_max);
+if (!vl_compositor_set_csc_matrix(>cstate, (const 
vl_csc_matrix *)>csc,
+vmixer->luma_key.luma_min, vmixer->luma_key.luma_max)) 
{
+   ret = VDP_STATUS_ERROR;
+   goto fail;
+}
  break;
 
   case VDP_VIDEO_MIXER_ATTRIBUTE_LUMA_KEY_MAX_LUMA:
@@ -846,8 +864,11 @@ vlVdpVideoMixerSetAttributeValues(VdpVideoMixer mixer,
  }
  vmixer->luma_key.luma_max = val;
  if (!

[Mesa-dev] [PATCH 1/5] st/xvmc: use goto to make code more readable (v2)

2016-12-16 Thread Nayan Deshmukh

v2: add missing semicolon

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/xvmc/context.c | 40 +++
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/src/gallium/state_trackers/xvmc/context.c 
b/src/gallium/state_trackers/xvmc/context.c
index e9014c8..fb9f435 100644
--- a/src/gallium/state_trackers/xvmc/context.c
+++ b/src/gallium/state_trackers/xvmc/context.c
@@ -226,23 +226,20 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
 
context_priv = CALLOC(1, sizeof(XvMCContextPrivate));
if (!context_priv)
-  return BadAlloc;
+  goto no_context_priv;
 
/* TODO: Reuse screen if process creates another context */
vscreen = vl_dri2_screen_create(dpy, scrn);
 
if (!vscreen) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL screen.\n");
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_screen;
}
 
pipe = vscreen->pscreen->context_create(vscreen->pscreen, vscreen, 0);
if (!pipe) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL context.\n");
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_context;
}
 
templat.profile = ProfileToPipe(mc_type);
@@ -257,29 +254,17 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
 
if (!context_priv->decoder) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL decoder.\n");
-  pipe->destroy(pipe);
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_decoder;
}
 
if (!vl_compositor_init(_priv->compositor, pipe)) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor.\n");
-  context_priv->decoder->destroy(context_priv->decoder);
-  pipe->destroy(pipe);
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_compositor;
}
 
if (!vl_compositor_init_state(_priv->cstate, pipe)) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor state.\n");
-  vl_compositor_cleanup(_priv->compositor);
-  context_priv->decoder->destroy(context_priv->decoder);
-  pipe->destroy(pipe);
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_compositor_state;
}
 
 
@@ -313,6 +298,19 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
XVMC_MSG(XVMC_TRACE, "[XvMC] Context %p created.\n", context);
 
return Success;
+
+no_compositor_state:
+   vl_compositor_cleanup(_priv->compositor);
+no_compositor:
+   context_priv->decoder->destroy(context_priv->decoder);
+no_decoder:
+   pipe->destroy(pipe);
+no_context:
+   vscreen->destroy(vscreen);
+no_screen:
+   FREE(context_priv);
+no_context_priv:
+   return BadAlloc;
 }
 
 PUBLIC
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/5] vl/compositor: implement error handling

2016-12-16 Thread Nayan Deshmukh

pipe_buffer_map and pipe_buffer_create may return NULL

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/auxiliary/vl/vl_compositor.c | 13 +++--
 src/gallium/auxiliary/vl/vl_compositor.h |  2 +-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
b/src/gallium/auxiliary/vl/vl_compositor.c
index 03a0a64..297c3ab 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -919,7 +919,7 @@ vl_compositor_cleanup(struct vl_compositor *c)
cleanup_pipe_state(c);
 }
 
-void
+bool
 vl_compositor_set_csc_matrix(struct vl_compositor_state *s,
  vl_csc_matrix const *matrix,
  float luma_min, float luma_max)
@@ -932,6 +932,9 @@ vl_compositor_set_csc_matrix(struct vl_compositor_state *s,
PIPE_TRANSFER_WRITE | 
PIPE_TRANSFER_DISCARD_RANGE,
_transfer);
 
+   if (!ptr)
+  return false;
+
memcpy(ptr, matrix, sizeof(vl_csc_matrix));
 
ptr += sizeof(vl_csc_matrix)/sizeof(float);
@@ -939,6 +942,8 @@ vl_compositor_set_csc_matrix(struct vl_compositor_state *s,
ptr[1] = luma_max;
 
pipe_buffer_unmap(s->pipe, buf_transfer);
+
+   return true;
 }
 
 void
@@ -1246,10 +1251,14 @@ vl_compositor_init_state(struct vl_compositor_state *s, 
struct pipe_context *pip
   sizeof(csc_matrix) + 2*sizeof(float)
);
 
+   if (!s->csc_matrix)
+  return false;
+
vl_compositor_clear_layers(s);
 
vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_IDENTITY, NULL, true, _matrix);
-   vl_compositor_set_csc_matrix(s, (const vl_csc_matrix *)_matrix, 1.0f, 
0.0f);
+   if (!vl_compositor_set_csc_matrix(s, (const vl_csc_matrix *)_matrix, 
1.0f, 0.0f))
+  return false;
 
return true;
 }
diff --git a/src/gallium/auxiliary/vl/vl_compositor.h 
b/src/gallium/auxiliary/vl/vl_compositor.h
index ceab5e0..5460619 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.h
+++ b/src/gallium/auxiliary/vl/vl_compositor.h
@@ -142,7 +142,7 @@ vl_compositor_init_state(struct vl_compositor_state *state, 
struct pipe_context
 /**
  * set yuv -> rgba conversion matrix
  */
-void
+bool
 vl_compositor_set_csc_matrix(struct vl_compositor_state *settings,
  const vl_csc_matrix *matrix,
  float luma_min, float luma_max);
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] st/xvmc: remove dead code

2016-12-15 Thread Nayan Deshmukh

My apologies for sending the wrong series.



On Thu, Dec 15, 2016 at 7:45 PM, Christian König
<deathsim...@vodafone.de> wrote:
> Am 15.12.2016 um 15:07 schrieb Emil Velikov:
>>
>> On 15 December 2016 at 13:57, Nayan Deshmukh <nayan26deshm...@gmail.com>
>> wrote:
>>>
>>> I send out the wrong series, the earlier one. I am sending the v2.
>>>
>>> I am not sure of the reason as to why it was returning a bool anyways.
>>> So I was hoping that someone could point out the reason.
>>>
>> Looking within... strictly speaking pipe_buffer_create() and
>> vl_compositor_set_csc_matrix() can fail.
>> Christian seems to be the author back in 2012, so not sure if he still
>> recalls the details.
>
>
> My best guess is that the function used to have error handling or at least
> should have error handling, but this was never properly implemented.
>
> If you want to clean this up I suggest to either follow Ilia's comment as
> well and make the function return void, or go into the other direction and
> implement proper error handling (preferred).
>
I will send in a patch with error handling.

Regards,
Nayan
> Regards,
> Christian.
>
>>
>> Emil
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 4/4] st/xvmc: remove dead code

2016-12-15 Thread Nayan Deshmukh

vl_compositor_init_state always return true so we don't
need to handle false case

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/xvmc/context.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/src/gallium/state_trackers/xvmc/context.c 
b/src/gallium/state_trackers/xvmc/context.c
index fb9f435..057085d 100644
--- a/src/gallium/state_trackers/xvmc/context.c
+++ b/src/gallium/state_trackers/xvmc/context.c
@@ -262,11 +262,7 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
   goto no_compositor;
}
 
-   if (!vl_compositor_init_state(_priv->cstate, pipe)) {
-  XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor state.\n");
-  goto no_compositor_state;
-   }
-
+   vl_compositor_init_state(_priv->cstate, pipe);
 
context_priv->color_standard =
   debug_get_bool_option("G3DVL_NO_CSC", FALSE) ?
@@ -299,8 +295,6 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
 
return Success;
 
-no_compositor_state:
-   vl_compositor_cleanup(_priv->compositor);
 no_compositor:
context_priv->decoder->destroy(context_priv->decoder);
 no_decoder:
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 3/4] st/vdpau: check if compositor is initilized successfully

2016-12-15 Thread Nayan Deshmukh

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/device.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/vdpau/device.c 
b/src/gallium/state_trackers/vdpau/device.c
index 81b7582..8bae064 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -128,13 +128,19 @@ vdp_imp_device_create_x11(Display *display, int screen, 
VdpDevice *device,
   goto no_handle;
}
 
-   vl_compositor_init(>compositor, dev->context);
+   if (!vl_compositor_init(>compositor, dev->context)) {
+   ret = VDP_STATUS_ERROR;
+   goto no_compositor;
+   }
+
pipe_mutex_init(dev->mutex);
 
*get_proc_address = 
 
return VDP_STATUS_OK;
 
+no_compositor:
+   vlRemoveDataHTAB(*device);
 no_handle:
pipe_sampler_view_reference(>dummy_sv, NULL);
 no_resource:
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 1/4] st/xvmc: use goto to make code more readable

2016-12-15 Thread Nayan Deshmukh

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/xvmc/context.c | 40 +++
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/src/gallium/state_trackers/xvmc/context.c 
b/src/gallium/state_trackers/xvmc/context.c
index e9014c8..fb9f435 100644
--- a/src/gallium/state_trackers/xvmc/context.c
+++ b/src/gallium/state_trackers/xvmc/context.c
@@ -226,23 +226,20 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
 
context_priv = CALLOC(1, sizeof(XvMCContextPrivate));
if (!context_priv)
-  return BadAlloc;
+  goto no_context_priv;
 
/* TODO: Reuse screen if process creates another context */
vscreen = vl_dri2_screen_create(dpy, scrn);
 
if (!vscreen) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL screen.\n");
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_screen;
}
 
pipe = vscreen->pscreen->context_create(vscreen->pscreen, vscreen, 0);
if (!pipe) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL context.\n");
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_context;
}
 
templat.profile = ProfileToPipe(mc_type);
@@ -257,29 +254,17 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
 
if (!context_priv->decoder) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL decoder.\n");
-  pipe->destroy(pipe);
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_decoder;
}
 
if (!vl_compositor_init(_priv->compositor, pipe)) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor.\n");
-  context_priv->decoder->destroy(context_priv->decoder);
-  pipe->destroy(pipe);
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_compositor;
}
 
if (!vl_compositor_init_state(_priv->cstate, pipe)) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor state.\n");
-  vl_compositor_cleanup(_priv->compositor);
-  context_priv->decoder->destroy(context_priv->decoder);
-  pipe->destroy(pipe);
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_compositor_state;
}
 
 
@@ -313,6 +298,19 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
XVMC_MSG(XVMC_TRACE, "[XvMC] Context %p created.\n", context);
 
return Success;
+
+no_compositor_state:
+   vl_compositor_cleanup(_priv->compositor);
+no_compositor:
+   context_priv->decoder->destroy(context_priv->decoder);
+no_decoder:
+   pipe->destroy(pipe);
+no_context:
+   vscreen->destroy(vscreen);
+no_screen:
+   FREE(context_priv);
+no_context_priv:
+   return BadAlloc;
 }
 
 PUBLIC
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 2/4] st/vdpau: remove dead code

2016-12-15 Thread Nayan Deshmukh

vl_compositor_init_state always return true so we don't
need to handle false case

v2: add missing semicolon

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/presentation.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index f35d73a..c1e1054 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -66,11 +66,7 @@ vlVdpPresentationQueueCreate(VdpDevice device,
pq->drawable = pqt->drawable;
 
pipe_mutex_lock(dev->mutex);
-   if (!vl_compositor_init_state(>cstate, dev->context)) {
-  pipe_mutex_unlock(dev->mutex);
-  ret = VDP_STATUS_ERROR;
-  goto no_compositor;
-   }
+   vl_compositor_init_state(>cstate, dev->context);
pipe_mutex_unlock(dev->mutex);
 
*presentation_queue = vlAddDataHTAB(pq);
@@ -82,7 +78,6 @@ vlVdpPresentationQueueCreate(VdpDevice device,
return VDP_STATUS_OK;
 
 no_handle:
-no_compositor:
DeviceReference(>device, NULL);
FREE(pq);
return ret;
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] st/xvmc: remove dead code

2016-12-15 Thread Nayan Deshmukh

I send out the wrong series, the earlier one. I am sending the v2.

I am not sure of the reason as to why it was returning a bool anyways.
So I was hoping that someone could point out the reason.

Regards,
Nayan


On Thu, Dec 15, 2016 at 7:24 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> Also, please at least *compile test* your patches. This patch doesn't compile.
>
> On Thu, Dec 15, 2016 at 8:54 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>> Should there be a patch 5 which makes vl_compositor_init_state return void?
>>
>> On Thu, Dec 15, 2016 at 8:34 AM, Nayan Deshmukh
>> <nayan26deshm...@gmail.com> wrote:
>>> vl_compositor_init_state always return true so we don't
>>> need to handle false case
>>>
>>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>>> ---
>>>  src/gallium/state_trackers/xvmc/context.c | 8 +---
>>>  1 file changed, 1 insertion(+), 7 deletions(-)
>>>
>>> diff --git a/src/gallium/state_trackers/xvmc/context.c 
>>> b/src/gallium/state_trackers/xvmc/context.c
>>> index 469e1c1..4ae7d7b 100644
>>> --- a/src/gallium/state_trackers/xvmc/context.c
>>> +++ b/src/gallium/state_trackers/xvmc/context.c
>>> @@ -262,11 +262,7 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, 
>>> int surface_type_id,
>>>goto no_compositor;
>>> }
>>>
>>> -   if (!vl_compositor_init_state(_priv->cstate, pipe)) {
>>> -  XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor state.\n");
>>> -  goto no_compositor_state;
>>> -   }
>>> -
>>> +   vl_compositor_init_state(_priv->cstate, pipe)
>>>
>>> context_priv->color_standard =
>>>debug_get_bool_option("G3DVL_NO_CSC", FALSE) ?
>>> @@ -299,8 +295,6 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, 
>>> int surface_type_id,
>>>
>>> return Success;
>>>
>>> -no_compositor_state:
>>> -   vl_compositor_cleanup(_priv->compositor);
>>>  no_compositor:
>>> context_priv->decoder->destroy(context_priv->decoder);
>>>  no_decoder:
>>> --
>>> 2.9.3
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/4] st/vdpau: check if compositor is initilized successfully

2016-12-15 Thread Nayan Deshmukh

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/device.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/vdpau/device.c 
b/src/gallium/state_trackers/vdpau/device.c
index 81b7582..62709e3 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -128,13 +128,19 @@ vdp_imp_device_create_x11(Display *display, int screen, 
VdpDevice *device,
   goto no_handle;
}
 
-   vl_compositor_init(>compositor, dev->context);
+   if (!vl_compositor_init(>compositor, dev->context)) {
+   ret = VDP_STATUS_ERROR;
+   goto no_compositor;
+   }
+
pipe_mutex_init(dev->mutex);
 
*get_proc_address = 
 
return VDP_STATUS_OK;
 
+no_compositor:
+   vlRemoveDataHTAB(dev);
 no_handle:
pipe_sampler_view_reference(>dummy_sv, NULL);
 no_resource:
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] st/vdpau: remove dead code

2016-12-15 Thread Nayan Deshmukh

vl_compositor_init_state always return true so we don't
need to handle false case

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
We may as well make vl_compositor_init_state a void function
but I don't know the reason as to why it is there in first 
place so haven't touched it yet
---
 src/gallium/state_trackers/vdpau/presentation.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index f35d73a..980d5cb 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -66,11 +66,7 @@ vlVdpPresentationQueueCreate(VdpDevice device,
pq->drawable = pqt->drawable;
 
pipe_mutex_lock(dev->mutex);
-   if (!vl_compositor_init_state(>cstate, dev->context)) {
-  pipe_mutex_unlock(dev->mutex);
-  ret = VDP_STATUS_ERROR;
-  goto no_compositor;
-   }
+   vl_compositor_init_state(>cstate, dev->context)
pipe_mutex_unlock(dev->mutex);
 
*presentation_queue = vlAddDataHTAB(pq);
@@ -82,7 +78,6 @@ vlVdpPresentationQueueCreate(VdpDevice device,
return VDP_STATUS_OK;
 
 no_handle:
-no_compositor:
DeviceReference(>device, NULL);
FREE(pq);
return ret;
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/4] st/xvmc: use goto to make code more readable

2016-12-15 Thread Nayan Deshmukh

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/xvmc/context.c | 40 +++
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/src/gallium/state_trackers/xvmc/context.c 
b/src/gallium/state_trackers/xvmc/context.c
index e9014c8..469e1c1 100644
--- a/src/gallium/state_trackers/xvmc/context.c
+++ b/src/gallium/state_trackers/xvmc/context.c
@@ -226,23 +226,20 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
 
context_priv = CALLOC(1, sizeof(XvMCContextPrivate));
if (!context_priv)
-  return BadAlloc;
+  goto no_context_priv;
 
/* TODO: Reuse screen if process creates another context */
vscreen = vl_dri2_screen_create(dpy, scrn);
 
if (!vscreen) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL screen.\n");
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_screen;
}
 
pipe = vscreen->pscreen->context_create(vscreen->pscreen, vscreen, 0);
if (!pipe) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL context.\n");
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_context;
}
 
templat.profile = ProfileToPipe(mc_type);
@@ -257,29 +254,17 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
 
if (!context_priv->decoder) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL decoder.\n");
-  pipe->destroy(pipe);
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_decoder:
}
 
if (!vl_compositor_init(_priv->compositor, pipe)) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor.\n");
-  context_priv->decoder->destroy(context_priv->decoder);
-  pipe->destroy(pipe);
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_compositor;
}
 
if (!vl_compositor_init_state(_priv->cstate, pipe)) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor state.\n");
-  vl_compositor_cleanup(_priv->compositor);
-  context_priv->decoder->destroy(context_priv->decoder);
-  pipe->destroy(pipe);
-  vscreen->destroy(vscreen);
-  FREE(context_priv);
-  return BadAlloc;
+  goto no_compositor_state;
}
 
 
@@ -313,6 +298,19 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
XVMC_MSG(XVMC_TRACE, "[XvMC] Context %p created.\n", context);
 
return Success;
+
+no_compositor_state:
+   vl_compositor_cleanup(_priv->compositor);
+no_compositor:
+   context_priv->decoder->destroy(context_priv->decoder);
+no_decoder:
+   pipe->destroy(pipe);
+no_context:
+   vscreen->destroy(vscreen);
+no_screen:
+   FREE(context_priv);
+no_context_priv:
+   return BadAlloc;
 }
 
 PUBLIC
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] st/xvmc: remove dead code

2016-12-15 Thread Nayan Deshmukh

vl_compositor_init_state always return true so we don't
need to handle false case

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/xvmc/context.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/src/gallium/state_trackers/xvmc/context.c 
b/src/gallium/state_trackers/xvmc/context.c
index 469e1c1..4ae7d7b 100644
--- a/src/gallium/state_trackers/xvmc/context.c
+++ b/src/gallium/state_trackers/xvmc/context.c
@@ -262,11 +262,7 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
   goto no_compositor;
}
 
-   if (!vl_compositor_init_state(_priv->cstate, pipe)) {
-  XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor state.\n");
-  goto no_compositor_state;
-   }
-
+   vl_compositor_init_state(_priv->cstate, pipe)
 
context_priv->color_standard =
   debug_get_bool_option("G3DVL_NO_CSC", FALSE) ?
@@ -299,8 +295,6 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
 
return Success;
 
-no_compositor_state:
-   vl_compositor_cleanup(_priv->compositor);
 no_compositor:
context_priv->decoder->destroy(context_priv->decoder);
 no_decoder:
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 11/28] st/va: fix misplaced closing bracket

2016-12-14 Thread Nayan Deshmukh

Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>

On Fri, Dec 9, 2016 at 12:51 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> It's been like this since the code was introduced.
>
> Fixes: 86eb4131a90 (st/va: add headless support, i.e. VA_DISPLAY_DRM)
> Cc: "13.0" <mesa-sta...@lists.freedesktop.org>
> Cc: Julien Isorce <j.iso...@samsung.com>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
>  src/gallium/state_trackers/va/context.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/va/context.c 
> b/src/gallium/state_trackers/va/context.c
> index abc8b39..d52f95e 100644
> --- a/src/gallium/state_trackers/va/context.c
> +++ b/src/gallium/state_trackers/va/context.c
> @@ -138,8 +138,8 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
>drv->vscreen = vl_drm_screen_create(drm_info->fd);
>if (!drv->vscreen)
>   goto error_screen;
> -  }
>break;
> +   }
> default:
>FREE(drv);
>return VA_STATUS_ERROR_INVALID_DISPLAY;
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 14/28] st/omx: remove unused drm_driver.h includes

2016-12-14 Thread Nayan Deshmukh

Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>

On Fri, Dec 9, 2016 at 1:30 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
>  src/gallium/state_trackers/omx/vid_dec.h | 1 -
>  src/gallium/state_trackers/omx/vid_enc.c | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/omx/vid_dec.h 
> b/src/gallium/state_trackers/omx/vid_dec.h
> index 90acf7b..1ce3de7 100644
> --- a/src/gallium/state_trackers/omx/vid_dec.h
> +++ b/src/gallium/state_trackers/omx/vid_dec.h
> @@ -47,7 +47,6 @@
>  #include 
>
>  #include "pipe/p_video_state.h"
> -#include "state_tracker/drm_driver.h"
>  #include "os/os_thread.h"
>  #include "util/list.h"
>
> diff --git a/src/gallium/state_trackers/omx/vid_enc.c 
> b/src/gallium/state_trackers/omx/vid_enc.c
> index 0d7ab28..6bb5a76 100644
> --- a/src/gallium/state_trackers/omx/vid_enc.c
> +++ b/src/gallium/state_trackers/omx/vid_enc.c
> @@ -48,7 +48,6 @@
>
>  #include "pipe/p_screen.h"
>  #include "pipe/p_video_codec.h"
> -#include "state_tracker/drm_driver.h"
>  #include "util/u_memory.h"
>  #include "vl/vl_video_buffer.h"
>
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 15/28] st/omx: remove unneeded X11 include

2016-12-14 Thread Nayan Deshmukh

Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>

On Fri, Dec 9, 2016 at 1:30 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
>  src/gallium/state_trackers/omx/vid_dec.h | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/omx/vid_dec.h 
> b/src/gallium/state_trackers/omx/vid_dec.h
> index 1ce3de7..7a10e75 100644
> --- a/src/gallium/state_trackers/omx/vid_dec.h
> +++ b/src/gallium/state_trackers/omx/vid_dec.h
> @@ -34,8 +34,6 @@
>  #ifndef OMX_VID_DEC_H
>  #define OMX_VID_DEC_H
>
> -#include 
> -
>  #include 
>
>  #include 
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vl/zscan: fix "Fix trivial sign compare warnings"

2016-12-14 Thread Nayan Deshmukh

Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>


On Wed, Dec 14, 2016 at 7:37 PM, Christian König
<deathsim...@vodafone.de> wrote:
> From: Christian König <christian.koe...@amd.com>
>
> The variable actually needs to be signed, otherwise converting it to a
> float doesn't work as expected.
>
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98914
> Signed-off-by: Christian König <christian.koe...@amd.com>
> ---
>  src/gallium/auxiliary/vl/vl_zscan.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_zscan.c 
> b/src/gallium/auxiliary/vl/vl_zscan.c
> index ef05af4..24d6452 100644
> --- a/src/gallium/auxiliary/vl/vl_zscan.c
> +++ b/src/gallium/auxiliary/vl/vl_zscan.c
> @@ -152,7 +152,7 @@ create_vert_shader(struct vl_zscan *zscan)
> for (i = 0; i < zscan->num_channels; ++i) {
>ureg_ADD(shader, ureg_writemask(tmp, TGSI_WRITEMASK_X), 
> ureg_scalar(ureg_src(tmp), TGSI_SWIZZLE_Y),
> ureg_imm1f(shader, 1.0f / (zscan->blocks_per_line * 
> VL_BLOCK_WIDTH)
> -* (i - (signed)zscan->num_channels / 2)));
> +* ((signed)i - (signed)zscan->num_channels / 2)));
>
>ureg_MAD(shader, ureg_writemask(o_vtex[i], TGSI_WRITEMASK_X), vrect,
> ureg_imm1f(shader, 1.0f / zscan->blocks_per_line), 
> ureg_src(tmp));
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 17/28] auxiliary/vl: attempt to fix X11-less builds

2016-12-13 Thread Nayan Deshmukh

On Fri, Dec 9, 2016 at 1:30 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Use the proper guard around the include and use void * instead of
> Display *.
>
Some part of the patch is missing.

Regards,
Nayan
> Signed-off-by: Emil Velikov 
> ---
>  src/gallium/auxiliary/vl/vl_winsys.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
> b/src/gallium/auxiliary/vl/vl_winsys.h
> index 26db9f2..f6ee36c 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys.h
> +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> @@ -32,7 +32,9 @@
>  #ifndef vl_winsys_h
>  #define vl_winsys_h
>
> +#if defined(HAVE_PLATFORM_X11)
>  #include 
> +#endif
>  #include "pipe/p_defines.h"
>  #include "pipe/p_format.h"
>
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 24/28] configure: error out if building OMX w/o supported platform

2016-12-13 Thread Nayan Deshmukh

Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>

On Tue, Dec 13, 2016 at 11:58 PM, Nayan Deshmukh
<nayan26deshm...@gmail.com> wrote:
> Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>
> On Fri, Dec 9, 2016 at 1:30 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
>> From: Emil Velikov <emil.veli...@collabora.com>
>>
>> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
>> ---
>>  configure.ac | 11 ++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 602b2ce..4e4e965 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -2095,6 +2095,12 @@ if test "x$enable_xa" = xyes; then
>>  fi
>>  AM_CONDITIONAL(HAVE_ST_XA, test "x$enable_xa" = xyes)
>>
>> +if echo $platforms | grep -q "x11\|drm"; then
>> +have_omx_platform=yes
>> +else
>> +have_omx_platform=no
>> +fi
>> +
>>  if echo $platforms | grep -q "x11\|drm\|wayland"; then
>>  have_va_platform=yes
>>  else
>> @@ -2113,7 +2119,7 @@ if test -n "$with_gallium_drivers" -a 
>> "x$with_gallium_drivers" != xswrast; then
>> PKG_CHECK_EXISTS([vdpau >= $VDPAU_REQUIRED], [enable_vdpau=yes], 
>> [enable_vdpau=no])
>>  fi
>>
>> -if test "x$enable_omx" = xauto; then
>> +if test "x$enable_omx" = xauto -a "x$have_omx_platform" = xyes; then
>> PKG_CHECK_EXISTS([libomxil-bellagio >= $LIBOMXIL_BELLAGIO_REQUIRED], 
>> [enable_omx=yes], [enable_omx=no])
>>  fi
>>
>> @@ -2154,6 +2160,9 @@ fi
>>  AM_CONDITIONAL(HAVE_ST_VDPAU, test "x$enable_vdpau" = xyes)
>>
>>  if test "x$enable_omx" = xyes; then
>> +if test "x$have_omx_platform" != xyes; then
>> +AC_MSG_ERROR([OMX requires at least one of the x11 or drm 
>> platforms])
>> +fi
>>  PKG_CHECK_MODULES([OMX], [libomxil-bellagio >= 
>> $LIBOMXIL_BELLAGIO_REQUIRED])
>>  gallium_st="$gallium_st omx"
>>  fi
>> --
>> 2.10.2
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 26/28] configure: error out if building XVMC w/o supported platform

2016-12-13 Thread Nayan Deshmukh

Half of this patch went in 25, with that fixed both are Reviewed-by:
Nayan Deshmukh <nayan26deshm...@gmail.com>

On Fri, Dec 9, 2016 at 1:30 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
>  configure.ac | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index a4327ad..606ea98 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2123,7 +2123,7 @@ dnl
>  dnl Gallium G3DVL configuration
>  dnl
>  if test -n "$with_gallium_drivers" -a "x$with_gallium_drivers" != xswrast; 
> then
> -if test "x$enable_xvmc" = xauto; then
> +if test "x$enable_xvmc" = xauto -a "x$have_xvmc_platform" = xyes; then
> PKG_CHECK_EXISTS([xvmc >= $XVMC_REQUIRED], [enable_xvmc=yes], 
> [enable_xvmc=no])
>  fi
>
> @@ -2159,6 +2159,9 @@ fi
>  AM_CONDITIONAL(NEED_GALLIUM_VL_WINSYS, test "x$need_gallium_vl_winsys" = 
> xyes)
>
>  if test "x$enable_xvmc" = xyes; then
> +if test "x$have_xvmc_platform" != xyes; then
> +AC_MSG_ERROR([XVMC requires the x11 platforms])
> +fi
>  PKG_CHECK_MODULES([XVMC], [xvmc >= $XVMC_REQUIRED])
>  gallium_st="$gallium_st xvmc"
>  fi
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 25/28] configure: error out if building VDPAU w/o supported platform

2016-12-13 Thread Nayan Deshmukh

On Fri, Dec 9, 2016 at 1:30 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 4e4e965..a4327ad 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2095,6 +2095,18 @@ if test "x$enable_xa" = xyes; then
>  fi
>  AM_CONDITIONAL(HAVE_ST_XA, test "x$enable_xa" = xyes)
>
> +if echo $platforms | grep -q "x11"; then
> +have_xvmc_platform=yes
> +else
> +have_xvmc_platform=no
> +fi
> +
This is part of some other patch I guess.

Regards,
Nayan
> +if echo $platforms | grep -q "x11"; then
> +have_vdpau_platform=yes
> +else
> +have_vdpau_platform=no
> +fi
> +
>  if echo $platforms | grep -q "x11\|drm"; then
>  have_omx_platform=yes
>  else
> @@ -2115,7 +2127,7 @@ if test -n "$with_gallium_drivers" -a 
> "x$with_gallium_drivers" != xswrast; then
> PKG_CHECK_EXISTS([xvmc >= $XVMC_REQUIRED], [enable_xvmc=yes], 
> [enable_xvmc=no])
>  fi
>
> -if test "x$enable_vdpau" = xauto; then
> +if test "x$enable_vdpau" = xauto then -a "x$have_vdpau_platform" = xyes; 
> then
> PKG_CHECK_EXISTS([vdpau >= $VDPAU_REQUIRED], [enable_vdpau=yes], 
> [enable_vdpau=no])
>  fi
>
> @@ -2153,6 +2165,9 @@ fi
>  AM_CONDITIONAL(HAVE_ST_XVMC, test "x$enable_xvmc" = xyes)
>
>  if test "x$enable_vdpau" = xyes; then
> +if test "x$have_vdpau_platform" != xyes; then
> +AC_MSG_ERROR([VDPAU requires the x11 platforms])
> +fi
>  PKG_CHECK_MODULES([VDPAU], [vdpau >= $VDPAU_REQUIRED])
>  gallium_st="$gallium_st vdpau"
>  DEFINES="$DEFINES -DHAVE_ST_VDPAU"
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 27/28] configure: trivial whitespace cleanup

2016-12-13 Thread Nayan Deshmukh

Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>

On Fri, Dec 9, 2016 at 1:30 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
>  configure.ac | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 606ea98..bc08639 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2124,15 +2124,15 @@ dnl Gallium G3DVL configuration
>  dnl
>  if test -n "$with_gallium_drivers" -a "x$with_gallium_drivers" != xswrast; 
> then
>  if test "x$enable_xvmc" = xauto -a "x$have_xvmc_platform" = xyes; then
> -   PKG_CHECK_EXISTS([xvmc >= $XVMC_REQUIRED], [enable_xvmc=yes], 
> [enable_xvmc=no])
> +PKG_CHECK_EXISTS([xvmc >= $XVMC_REQUIRED], [enable_xvmc=yes], 
> [enable_xvmc=no])
>  fi
>
>  if test "x$enable_vdpau" = xauto then -a "x$have_vdpau_platform" = xyes; 
> then
> -   PKG_CHECK_EXISTS([vdpau >= $VDPAU_REQUIRED], [enable_vdpau=yes], 
> [enable_vdpau=no])
> +PKG_CHECK_EXISTS([vdpau >= $VDPAU_REQUIRED], [enable_vdpau=yes], 
> [enable_vdpau=no])
>  fi
>
>  if test "x$enable_omx" = xauto -a "x$have_omx_platform" = xyes; then
> -   PKG_CHECK_EXISTS([libomxil-bellagio >= $LIBOMXIL_BELLAGIO_REQUIRED], 
> [enable_omx=yes], [enable_omx=no])
> +PKG_CHECK_EXISTS([libomxil-bellagio >= $LIBOMXIL_BELLAGIO_REQUIRED], 
> [enable_omx=yes], [enable_omx=no])
>  fi
>
>  if test "x$enable_va" = xauto -a "x$have_va_platform" = xyes; then
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/28] st/va: move variable declaration to where its used

2016-12-13 Thread Nayan Deshmukh

s/thinker/tinker.

with that fixed Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>

On Fri, Dec 9, 2016 at 12:51 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> ... and make it const, since we shouldn't thinker with it.
>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
>  src/gallium/state_trackers/va/context.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/context.c 
> b/src/gallium/state_trackers/va/context.c
> index 65ba7db..abc8b39 100644
> --- a/src/gallium/state_trackers/va/context.c
> +++ b/src/gallium/state_trackers/va/context.c
> @@ -103,7 +103,6 @@ PUBLIC VAStatus
>  VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
>  {
> vlVaDriver *drv;
> -   struct drm_state *drm_info;
>
> if (!ctx)
>return VA_STATUS_ERROR_INVALID_CONTEXT;
> @@ -129,7 +128,7 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
> case VA_DISPLAY_WAYLAND:
> case VA_DISPLAY_DRM:
> case VA_DISPLAY_DRM_RENDERNODES: {
> -  drm_info = (struct drm_state *) ctx->drm_state;
> +  const struct drm_state *drm_info = (struct drm_state *) ctx->drm_state;
>
>if (!drm_info || drm_info->fd < 0) {
>   FREE(drv);
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 13/28] st/va: check if vl_*_screen_create has failed only once

2016-12-13 Thread Nayan Deshmukh

Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>

On Tue, Dec 13, 2016 at 11:04 PM, Nayan Deshmukh
<nayan26deshm...@gmail.com> wrote:
> Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>
>
> On Fri, Dec 9, 2016 at 1:30 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
>> From: Emil Velikov <emil.veli...@collabora.com>
>>
>> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
>> ---
>>  src/gallium/state_trackers/va/context.c | 7 +++
>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/va/context.c 
>> b/src/gallium/state_trackers/va/context.c
>> index 0f18399..1ff19a8 100644
>> --- a/src/gallium/state_trackers/va/context.c
>> +++ b/src/gallium/state_trackers/va/context.c
>> @@ -126,8 +126,6 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
>>  #endif
>>if (!drv->vscreen)
>>   drv->vscreen = vl_dri2_screen_create(ctx->native_dpy, 
>> ctx->x11_screen);
>> -  if (!drv->vscreen)
>> - goto error_screen;
>>break;
>> case VA_DISPLAY_WAYLAND:
>> case VA_DISPLAY_DRM:
>> @@ -144,8 +142,6 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
>>}
>>
>>drv->vscreen = vl_drm_screen_create(drm_info->fd);
>> -  if (!drv->vscreen)
>> - goto error_screen;
>>break;
>> }
>> default:
>> @@ -153,6 +149,9 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
>>return VA_STATUS_ERROR_INVALID_DISPLAY;
>> }
>>
>> +   if (!drv->vscreen)
>> +  goto error_screen;
>> +
>> drv->pipe = drv->vscreen->pscreen->context_create(drv->vscreen->pscreen,
>>   drv->vscreen, 0);
>> if (!drv->pipe)
>> --
>> 2.10.2
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/vdpau: fix compiler warning in vlVdpVideoMixerRender

2016-12-05 Thread Nayan Deshmukh

On Mon, Dec 5, 2016 at 6:28 PM, Emil Velikov  wrote:
> This seems like the compiler being silly since it fails to match if
> (vmixer->bicubic.filter || ...) with the else of if
> (!vmixer->noise_reduction.filter && ...)
>
> As usual, some wild idea(s) come to mind. Please don't read too much into 
> them.
>  - move current_picture_structure validation further up
>  - factor out the "allocate temporary resource(s)" (when we have a filter)
>  - ^^ on the rendering side
>
> So you'll end up with something like
>
>...
>if (vmixer->bicubic.filter || vmixer->sharpness.filter ||
> vmixer->noise_reduction.filter)
>   "allocate temporary resource(s)"
>// else in original code is redundant
>
>if (!vmixer->bicubic.filter)
>   "adjust dst area/clip" // current code, keep as-is
>
>for (i = 0; i < layer_count; ++i)
>...
>
>
>if (vmixer->bicubic.filter || vmixer->sharpness.filter ||
> vmixer->noise_reduction.filter)
>  "do filter rendering"
>else
>   vlVdpSave4DelayedRendering()
>
Hi Emil,

Thanks for the suggestions but I am working on a patch series which will
remove the vlVdpSave4DelayedRendering() and hence the above if and
else will be removed. So setting pipe to NULL will take care of the compiler
warnings for the future patches too.

Regards,
Nayan
>
> -Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/vdpau: fix compiler warning in vlVdpVideoMixerRender

2016-12-05 Thread Nayan Deshmukh

Christian, Thanks for the review. Can you push the patch for me?

Regards,
Nayan

On Mon, Dec 5, 2016 at 1:17 PM, Christian König
<christian.koe...@amd.com> wrote:
> Am 05.12.2016 um 06:25 schrieb Nayan Deshmukh:
>>
>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>
>
> Reviewed-by: Christian König <christian.koe...@amd.com>.
>
>
>> ---
>>   src/gallium/state_trackers/vdpau/mixer.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/state_trackers/vdpau/mixer.c
>> b/src/gallium/state_trackers/vdpau/mixer.c
>> index c205427..aca43c1 100644
>> --- a/src/gallium/state_trackers/vdpau/mixer.c
>> +++ b/src/gallium/state_trackers/vdpau/mixer.c
>> @@ -242,7 +242,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
>>  struct pipe_video_buffer *video_buffer;
>>  struct pipe_sampler_view *sampler_view, sv_templ;
>>  struct pipe_surface *surface, surf_templ;
>> -   struct pipe_context *pipe;
>> +   struct pipe_context *pipe = NULL;
>>  struct pipe_resource res_tmpl, *res;
>>vlVdpVideoMixer *vmixer;
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: fix resource leak in radv_amdgpu_ctx_create

2016-12-05 Thread Nayan Deshmukh

Thanks for the review. Can you push the patch for me.

Regards,
Nayan

On Mon, Dec 5, 2016 at 2:46 PM, Edward O'Callaghan
<funfunc...@folklore1984.net> wrote:
> Reviewed-by: Edward O'Callaghan <funfunc...@folkore1984.net>
>
> On 12/05/2016 04:45 AM, Nayan Deshmukh wrote:
>> CovID: 1396387
>>
>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>> ---
>>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c 
>> b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
>> index b8558fa..08abb9d 100644
>> --- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
>> +++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
>> @@ -742,6 +742,7 @@ static struct radeon_winsys_ctx 
>> *radv_amdgpu_ctx_create(struct radeon_winsys *_w
>>   ctx->ws = ws;
>>   return (struct radeon_winsys_ctx *)ctx;
>>  error_create:
>> +FREE(ctx);
>>   return NULL;
>>  }
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/vdpau: fix compiler warning in vlVdpVideoMixerRender

2016-12-04 Thread Nayan Deshmukh

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/mixer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index c205427..aca43c1 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -242,7 +242,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
struct pipe_video_buffer *video_buffer;
struct pipe_sampler_view *sampler_view, sv_templ;
struct pipe_surface *surface, surf_templ;
-   struct pipe_context *pipe;
+   struct pipe_context *pipe = NULL;
struct pipe_resource res_tmpl, *res;
 
vlVdpVideoMixer *vmixer;
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel/aubinator: fix resource leak in aub_file_open

2016-12-04 Thread Nayan Deshmukh

Yes, you are right, sorry for the noise.

Regards,
Nayan.

On Mon, Dec 5, 2016 at 10:14 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> Calling exit() is going to cause the program to terminate and all of its
> resources will get cleaned up by the OS.  There's no real reason why we need
> to free anything first.
>
> On Sun, Dec 4, 2016 at 9:47 AM, Nayan Deshmukh <nayan26deshm...@gmail.com>
> wrote:
>>
>> CovID: 1373563
>>
>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>> ---
>>  src/intel/tools/aubinator.c | 9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
>> index 5e3a684..f64a843 100644
>> --- a/src/intel/tools/aubinator.c
>> +++ b/src/intel/tools/aubinator.c
>> @@ -959,25 +959,28 @@ aub_file_open(const char *filename)
>> fd = open(filename, O_RDONLY);
>> if (fd == -1) {
>>fprintf(stderr, "open %s failed: %s\n", filename, strerror(errno));
>> -  exit(EXIT_FAILURE);
>> +  goto exit_failure;
>> }
>>
>> if (fstat(fd, ) == -1) {
>>fprintf(stderr, "stat failed: %s\n", strerror(errno));
>> -  exit(EXIT_FAILURE);
>> +  goto exit_failure;
>> }
>>
>> file->map = mmap(NULL, sb.st_size,
>>  PROT_READ, MAP_SHARED, fd, 0);
>> if (file->map == MAP_FAILED) {
>>fprintf(stderr, "mmap failed: %s\n", strerror(errno));
>> -  exit(EXIT_FAILURE);
>> +  goto exit_failure;
>> }
>>
>> file->cursor = file->map;
>> file->end = file->map + sb.st_size / 4;
>>
>> return file;
>> +exit_failure:
>> +   free(file);
>> +   exit(EXIT_FAILURE);
>>  }
>>
>>  static struct aub_file *
>> --
>> 2.9.3
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] intel/aubinator: fix resource leak in aub_file_open

2016-12-04 Thread Nayan Deshmukh

CovID: 1373563

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/intel/tools/aubinator.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 5e3a684..f64a843 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -959,25 +959,28 @@ aub_file_open(const char *filename)
fd = open(filename, O_RDONLY);
if (fd == -1) {
   fprintf(stderr, "open %s failed: %s\n", filename, strerror(errno));
-  exit(EXIT_FAILURE);
+  goto exit_failure;
}
 
if (fstat(fd, ) == -1) {
   fprintf(stderr, "stat failed: %s\n", strerror(errno));
-  exit(EXIT_FAILURE);
+  goto exit_failure;
}
 
file->map = mmap(NULL, sb.st_size,
 PROT_READ, MAP_SHARED, fd, 0);
if (file->map == MAP_FAILED) {
   fprintf(stderr, "mmap failed: %s\n", strerror(errno));
-  exit(EXIT_FAILURE);
+  goto exit_failure;
}
 
file->cursor = file->map;
file->end = file->map + sb.st_size / 4;
 
return file;
+exit_failure:
+   free(file);
+   exit(EXIT_FAILURE);
 }
 
 static struct aub_file *
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: fix resource leak in radv_amdgpu_ctx_create

2016-12-04 Thread Nayan Deshmukh

CovID: 1396387

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
index b8558fa..08abb9d 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
@@ -742,6 +742,7 @@ static struct radeon_winsys_ctx 
*radv_amdgpu_ctx_create(struct radeon_winsys *_w
ctx->ws = ws;
return (struct radeon_winsys_ctx *)ctx;
 error_create:
+FREE(ctx);
return NULL;
 }
 
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv: Add missing error-checking to anv_block_pool_init

2016-11-20 Thread Nayan Deshmukh

Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>

On Sun, Nov 20, 2016 at 4:41 PM, Mun Gwan-gyeong <elong...@gmail.com> wrote:
> When the allocation fails on u_vector_init(), it returns 0
> This fixes u_vector_init failure path on anv_block_pool_init
>
> CID 1394319
>
> Signed-off-by: Mun Gwan-gyeong <elong...@gmail.com>
> ---
>  src/intel/vulkan/anv_allocator.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_allocator.c 
> b/src/intel/vulkan/anv_allocator.c
> index f472213..30bbd69 100644
> --- a/src/intel/vulkan/anv_allocator.c
> +++ b/src/intel/vulkan/anv_allocator.c
> @@ -269,8 +269,10 @@ anv_block_pool_init(struct anv_block_pool *pool,
> if (ftruncate(pool->fd, BLOCK_POOL_MEMFD_SIZE) == -1)
>return;
>
> -   u_vector_init(>mmap_cleanups,
> -   round_to_power_of_two(sizeof(struct anv_mmap_cleanup)), 
> 128);
> +   if (!u_vector_init(>mmap_cleanups,
> +  round_to_power_of_two(sizeof(struct anv_mmap_cleanup)),
> +  128))
> +  return;
>
> pool->state.next = 0;
> pool->state.end = 0;
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] vl/dri3: use external texture as back buffers(v3)

2016-11-07 Thread Nayan Deshmukh

On Mon, Nov 7, 2016 at 8:31 PM, Leo Liu <leo@amd.com> wrote:

>
>
> On 11/05/2016 02:44 AM, Nayan Deshmukh wrote:
>
>> Hi Leo,
>>
>> Thanks for the reference patch.
>>
>>   There are only a number of output surfaces taking turns as the
>> mixer render targets, so we probably can use the same pixmap
>>   corresponding to each of output surface texture.
>>
>> The mixer renders to a VdpOutputSurface which is provided to it by the
>> application, so we can't make any assumptions on the surface that will
>> be provided it may or may not be the same. Instead we could have
>> additional fields in vlVdpOutputSurface which stores the handle and
>> pixamp of the texture.
>>
>
> What I meant is in vl dri3 to store certain numbers of pixmaps, and update
> them when texture, handle, size
> changed by calling "pixmap_from_buffer", if the same buffer got reused,
> and then we just can use the same pixmap
> for present.
>
> I just tried the mpv, if no resizing, there are only 3 textures in turn.
>
> I think we should avoid this "creating new pixmap frame by frame", what do
> you think?
>
> I agree this needs to be avoided.

   /* In case of a single gpu we need to get the
* handle and pixmap for the texture that is set
*/
if (buffer && scrn->output_texture &&
!scrn->is_different_gpu)
   allocate_new_buffer = true;

For this case we can simply check if the texture is present among the
available buffers and allocate a new
buffer in case it is not found, but avoid deleting the current buffer if
the no. of buffers is less than a fixed
value like 3.

However I will be busy for 2 weeks so it going to take sometime to complete
the patch.

Regards,
Nayan.

> Regards,
> Leo
>
>
>> Regards,
>> Nayan
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] vl/dri3: use external texture as back buffers(v3)

2016-11-05 Thread Nayan Deshmukh

Hi Leo,

Thanks for the reference patch.

 There are only a number of output surfaces taking turns as the
mixer render targets, so we probably can use the same pixmap
 corresponding to each of output surface texture.

The mixer renders to a VdpOutputSurface which is provided to it by the
application, so we can't make any assumptions on the surface that will
be provided it may or may not be the same. Instead we could have
additional fields in vlVdpOutputSurface which stores the handle and
pixamp of the texture.

Regards,
Nayan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3] vl/dri3: use external texture as back buffers(v3)

2016-11-04 Thread Nayan Deshmukh

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
handle vaapi path

Suggested-by: Leo Liu <leo@amd.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/auxiliary/vl/vl_winsys.h  |   4 +
 src/gallium/auxiliary/vl/vl_winsys_dri3.c | 117 ++
 2 files changed, 108 insertions(+), 13 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..908e9c6 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,10 @@ struct vl_screen
void *
(*get_private)(struct vl_screen *vscreen);
 
+   void
+   (*set_back_texture_from_output)(struct vl_screen *vscreen, struct 
pipe_resource *buffer,
+ uint32_t width, uint32_t height);
+
struct pipe_screen *pscreen;
struct pipe_loader_device *dev;
 };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..9d0cd5a 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "loader.h"
 
@@ -57,6 +58,7 @@ struct vl_dri3_buffer
 
bool busy;
uint32_t width, height, pitch;
+   uint32_t clip_width, clip_height;
 };
 
 struct vl_dri3_screen
@@ -71,6 +73,8 @@ struct vl_dri3_screen
xcb_special_event_t *special_event;
 
struct pipe_context *pipe;
+   struct pipe_resource *output_texture;
+   uint32_t clip_width, clip_height;
 
struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
int cur_back;
@@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
xcb_free_pixmap(scrn->conn, buffer->pixmap);
xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!scrn->output_texture)
+  pipe_resource_reference(>texture, NULL);
if (buffer->linear_texture)
pipe_resource_reference(>linear_texture, NULL);
FREE(buffer);
@@ -236,13 +241,25 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
templ.target = PIPE_TEXTURE_2D;
templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   if (scrn->output_texture) {
+  buffer->clip_width = (scrn->clip_width) ? scrn->clip_width :
+   scrn->width;
+  buffer->clip_height = (scrn->clip_height) ? scrn->clip_height :
+scrn->height;
+  templ.width0 = scrn->output_texture->width0;
+  templ.height0 = scrn->output_texture->height0;
+   } else {
+   templ.width0 = scrn->width;
+   templ.height0 = scrn->height;
+   buffer->clip_width = scrn->width;
+   buffer->clip_height = scrn->height;
+   }
templ.depth0 = 1;
templ.array_size = 1;
 
if (scrn->is_different_gpu) {
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
+  buffer->texture = (scrn->output_texture) ? scrn->output_texture :
+scrn->base.pscreen->resource_create(scrn->base.pscreen,
 );
   if (!buffer->texture)
  goto unmap_shm;
@@ -257,7 +274,8 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
  goto no_linear_texture;
} else {
   templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
+  buffer->texture = (scrn->output_texture) ? scrn->output_texture :
+scrn->base.pscreen->resource_create(scrn->base.pscreen,
 );
   if (!buffer->texture)
  goto unmap_shm;
@@ -271,11 +289,14 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
usage);
buffer_fd = whandle.handle;
buffer->pitch = whandle.stride;
+   buffer->width = templ.width0;
+   buffer->height = templ.height0;
+
xcb_dri3_pixmap_from_buffer(scrn->conn,
(pixmap = xcb_generate_id(scrn->conn)),
scrn->drawable,
0,
-   scrn->width, scrn->height, buffer->pitch,
+   buffer->width, buffer->height, buffer->pitch,
scrn->depth,

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v2)

2016-11-04 Thread Nayan Deshmukh

On Fri, Nov 04, 2016 at 12:20:51PM -0400, Leo Liu wrote:
> Hi Nayan,
> 
> With this patch, the resizing corruption is fixed, thanks for that.
> 
> Still a few comments below.
> 
> 
> On 11/04/2016 03:08 AM, Nayan Deshmukh wrote:
> > dri3 allows us to send handle of a texture directly to X
> > so this patch allows a state tracker to directly send its
> > texture to X to be used as back buffer and avoids extra
> > copying
> > 
> > v2: use clip width/height to display a portion of the surface
> > 
> > Suggested-by: Leo Liu <leo@amd.com>
> > Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
> > ---
> >   src/gallium/auxiliary/vl/vl_winsys.h  |   4 ++
> >   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 109 
> > ++
> >   2 files changed, 99 insertions(+), 14 deletions(-)
> > 
> > diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
> > b/src/gallium/auxiliary/vl/vl_winsys.h
> > index 26db9f2..908e9c6 100644
> > --- a/src/gallium/auxiliary/vl/vl_winsys.h
> > +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> > @@ -59,6 +59,10 @@ struct vl_screen
> >  void *
> >  (*get_private)(struct vl_screen *vscreen);
> > +   void
> > +   (*set_back_texture_from_output)(struct vl_screen *vscreen, struct 
> > pipe_resource *buffer,
> > + uint32_t width, uint32_t height);
> > +
> >  struct pipe_screen *pscreen;
> >  struct pipe_loader_device *dev;
> >   };
> > diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
> > b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > index 2929928..9739be4 100644
> > --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > @@ -31,6 +31,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include "loader.h"
> > @@ -56,7 +57,9 @@ struct vl_dri3_buffer
> >  struct xshmfence *shm_fence;
> >  bool busy;
> > +   bool is_external_texture;
> >  uint32_t width, height, pitch;
> > +   uint32_t clip_width, clip_height;
> >   };
> >   struct vl_dri3_screen
> > @@ -71,6 +74,9 @@ struct vl_dri3_screen
> >  xcb_special_event_t *special_event;
> >  struct pipe_context *pipe;
> > +   struct pipe_resource *output_texture;
> > +   uint32_t output_texture_width;
> > +   uint32_t output_texture_height;
> 
> Are these clipping sizes?
Yes indeed, may be something like output_texture_clip_width would be more 
appropriate
> 
> >  struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
> >  int cur_back;
> > @@ -105,7 +111,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
> >  xcb_free_pixmap(scrn->conn, buffer->pixmap);
> >  xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
> >  xshmfence_unmap_shm(buffer->shm_fence);
> > -   pipe_resource_reference(>texture, NULL);
> > +   if (!buffer->is_external_texture)
> > +  pipe_resource_reference(>texture, NULL);
> >  if (buffer->linear_texture)
> >  pipe_resource_reference(>linear_texture, NULL);
> >  FREE(buffer);
> > @@ -236,14 +243,23 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> >  templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
> >  templ.target = PIPE_TEXTURE_2D;
> >  templ.last_level = 0;
> > -   templ.width0 = scrn->width;
> > -   templ.height0 = scrn->height;
> > +   if (scrn->output_texture) {
> > +  buffer->clip_width = (scrn->output_texture_width) ? 
> > scrn->output_texture_width : scrn->output_texture->width0;
> > +  buffer->clip_height = (scrn->output_texture_height) ? 
> > scrn->output_texture_height : scrn->output_texture->height0;
> 
> Can you wrap these lines and many new added lines below?
> Normally make a line less than ~80 chars, and make lines from above and
> below balanced.
> I think the whole purpose of this is to make more readable and looks nicer.
> 
buffer->clip_width = (scrn->output_texture_width) ? 
scrn->output_texture_width
 : scrn->output_texture->width0;

Is something like this fine?
> > +  templ.width0 = scrn->output_texture->width0;
> > +  templ.height0 = scrn->output_texture->height0;
> > +   } else {
> > +   templ.width0 = scrn->width;
> > +   templ.height0 = scrn->height;
> > +   buffer->clip_width = scrn->width;
> > +   buffer->clip_height

[Mesa-dev] [PATCH 3/3] st/vdpau: remove the delayed rendering hack(v1.1)

2016-11-04 Thread Nayan Deshmukh

the hack was introduced to avoid an extra copying
but now with dri3 we don't need it anymore

v1.1: rebasing

Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/bitmap.c|  2 -
 src/gallium/state_trackers/vdpau/device.c| 50 -
 src/gallium/state_trackers/vdpau/mixer.c | 89 +++-
 src/gallium/state_trackers/vdpau/output.c|  9 ---
 src/gallium/state_trackers/vdpau/presentation.c  | 30 +++-
 src/gallium/state_trackers/vdpau/vdpau_private.h |  9 ---
 6 files changed, 50 insertions(+), 139 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/bitmap.c 
b/src/gallium/state_trackers/vdpau/bitmap.c
index fd67a98..d9ec60d 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -198,8 +198,6 @@ vlVdpBitmapSurfacePutBitsNative(VdpBitmapSurface surface,
 
pipe_mutex_lock(vlsurface->device->mutex);
 
-   vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL);
-
dst_box = RectToPipeBox(destination_rect, vlsurface->sampler_view->texture);
pipe->texture_subdata(pipe, vlsurface->sampler_view->texture, 0,
  PIPE_TRANSFER_WRITE, _box, *source_data,
diff --git a/src/gallium/state_trackers/vdpau/device.c 
b/src/gallium/state_trackers/vdpau/device.c
index 81b7582..79e99ba 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -321,53 +321,3 @@ vlVdpDefaultSamplerViewTemplate(struct pipe_sampler_view 
*templ, struct pipe_res
if (desc->swizzle[3] == PIPE_SWIZZLE_0)
   templ->swizzle_a = PIPE_SWIZZLE_1;
 }
-
-void
-vlVdpResolveDelayedRendering(vlVdpDevice *dev, struct pipe_surface *surface, 
struct u_rect *dirty_area)
-{
-   struct vl_compositor_state *cstate;
-   vlVdpOutputSurface *vlsurface;
-
-   assert(dev);
-
-   cstate = dev->delayed_rendering.cstate;
-   if (!cstate)
-  return;
-
-   vlsurface = vlGetDataHTAB(dev->delayed_rendering.surface);
-   if (!vlsurface)
-  return;
-
-   if (!surface) {
-  surface = vlsurface->surface;
-  dirty_area = >dirty_area;
-   }
-
-   vl_compositor_render(cstate, >compositor, surface, dirty_area, true);
-
-   dev->delayed_rendering.surface = VDP_INVALID_HANDLE;
-   dev->delayed_rendering.cstate = NULL;
-
-   /* test if we need to create a new sampler for the just filled texture */
-   if (surface->texture != vlsurface->sampler_view->texture) {
-  struct pipe_resource *res = surface->texture;
-  struct pipe_sampler_view sv_templ;
-
-  vlVdpDefaultSamplerViewTemplate(_templ, res);
-  pipe_sampler_view_reference(>sampler_view, NULL);
-  vlsurface->sampler_view = 
dev->context->create_sampler_view(dev->context, res, _templ);
-   }
-
-   return;
-}
-
-void
-vlVdpSave4DelayedRendering(vlVdpDevice *dev, VdpOutputSurface surface, struct 
vl_compositor_state *cstate)
-{
-   assert(dev);
-
-   vlVdpResolveDelayedRendering(dev, NULL, NULL);
-
-   dev->delayed_rendering.surface = surface;
-   dev->delayed_rendering.cstate = cstate;
-}
diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index c205427..1206292 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -184,8 +184,6 @@ vlVdpVideoMixerDestroy(VdpVideoMixer mixer)
 
pipe_mutex_lock(vmixer->device->mutex);
 
-   vlVdpResolveDelayedRendering(vmixer->device, NULL, NULL);
-
vlRemoveDataHTAB(mixer);
 
vl_compositor_cleanup_state(>cstate);
@@ -284,7 +282,6 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
}
 
pipe_mutex_lock(vmixer->device->mutex);
-   vlVdpResolveDelayedRendering(vmixer->device, NULL, NULL);
 
vl_compositor_clear_layers(>cstate);
 
@@ -394,63 +391,59 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
   ++layers;
}
 
-   if (!vmixer->noise_reduction.filter && !vmixer->sharpness.filter && 
!vmixer->bicubic.filter)
-  vlVdpSave4DelayedRendering(vmixer->device, destination_surface, 
>cstate);
-   else {
-  vl_compositor_render(>cstate, compositor, surface, _area, 
true);
+   vl_compositor_render(>cstate, compositor, surface, _area, 
true);
 
-  if (vmixer->noise_reduction.filter) {
- if (!vmixer->sharpness.filter && !vmixer->bicubic.filter) {
-vl_median_filter_render(vmixer->noise_reduction.filter,
-sampler_view, dst->surface);
- } else {
-res = pipe->screen->resource_create(pipe->screen, _tmpl);
-struct pipe_sampler_view *sampler_view_temp = 
pipe->create_sampler_view(pipe, res, _templ);
-struct pipe_surface *surface_temp = pipe->create_surface(pipe, 
res, _templ);
-pipe_resource_ref

[Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v2)

2016-11-04 Thread Nayan Deshmukh

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface

Suggested-by: Leo Liu <leo@amd.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/auxiliary/vl/vl_winsys.h  |   4 ++
 src/gallium/auxiliary/vl/vl_winsys_dri3.c | 109 ++
 2 files changed, 99 insertions(+), 14 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..908e9c6 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,10 @@ struct vl_screen
void *
(*get_private)(struct vl_screen *vscreen);
 
+   void
+   (*set_back_texture_from_output)(struct vl_screen *vscreen, struct 
pipe_resource *buffer,
+ uint32_t width, uint32_t height);
+
struct pipe_screen *pscreen;
struct pipe_loader_device *dev;
 };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..9739be4 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "loader.h"
 
@@ -56,7 +57,9 @@ struct vl_dri3_buffer
struct xshmfence *shm_fence;
 
bool busy;
+   bool is_external_texture;
uint32_t width, height, pitch;
+   uint32_t clip_width, clip_height;
 };
 
 struct vl_dri3_screen
@@ -71,6 +74,9 @@ struct vl_dri3_screen
xcb_special_event_t *special_event;
 
struct pipe_context *pipe;
+   struct pipe_resource *output_texture;
+   uint32_t output_texture_width;
+   uint32_t output_texture_height;
 
struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
int cur_back;
@@ -105,7 +111,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
xcb_free_pixmap(scrn->conn, buffer->pixmap);
xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!buffer->is_external_texture)
+  pipe_resource_reference(>texture, NULL);
if (buffer->linear_texture)
pipe_resource_reference(>linear_texture, NULL);
FREE(buffer);
@@ -236,14 +243,23 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
templ.target = PIPE_TEXTURE_2D;
templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   if (scrn->output_texture) {
+  buffer->clip_width = (scrn->output_texture_width) ? 
scrn->output_texture_width : scrn->output_texture->width0;
+  buffer->clip_height = (scrn->output_texture_height) ? 
scrn->output_texture_height : scrn->output_texture->height0;
+  templ.width0 = scrn->output_texture->width0;
+  templ.height0 = scrn->output_texture->height0;
+   } else {
+   templ.width0 = scrn->width;
+   templ.height0 = scrn->height;
+   buffer->clip_width = scrn->width;
+   buffer->clip_height = scrn->height;
+   }
templ.depth0 = 1;
templ.array_size = 1;
 
if (scrn->is_different_gpu) {
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
-);
+  buffer->texture = (scrn->output_texture) ? scrn->output_texture : 
scrn->base.pscreen->resource_create(scrn->base.pscreen,
+   
 );
   if (!buffer->texture)
  goto unmap_shm;
 
@@ -257,8 +273,8 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
  goto no_linear_texture;
} else {
   templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
-);
+  buffer->texture = (scrn->output_texture) ? scrn->output_texture : 
scrn->base.pscreen->resource_create(scrn->base.pscreen,
+   
 );
   if (!buffer->texture)
  goto unmap_shm;
   pixmap_buffer_texture = buffer->texture;
@@ -271,11 +287,15 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
usage);
buffer_fd = whandle.handle;
buffer->pitch = whandle.stride;
+   buffer->width = templ.width0;
+   buffer->height = templ.height0;
+   buffer->is_external_texture = (scrn->output_texture) ? true : false;
+
xcb_dri3_pixmap_from_buffer(scrn->conn,

[Mesa-dev] [PATCH 2/3] st/vdpau: use dri3 to direclty send the buffer to X(v1.1)

2016-11-04 Thread Nayan Deshmukh

this avoids an extra copy which occurs in case of dri2

v1.1: fallback to dri2 if dri3 fails to initialize

Suggested-by: Christian König <christian.koe...@amd.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/presentation.c | 58 ++---
 1 file changed, 32 insertions(+), 26 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index f35d73a..b2c8aea 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -231,43 +231,47 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
vscreen = pq->device->vscreen;
 
pipe_mutex_lock(pq->device->mutex);
+   if (vscreen->set_back_texture_from_output)
+  vscreen->set_back_texture_from_output(vscreen, surf->surface->texture, 
clip_width, clip_height);
tex = vscreen->texture_from_drawable(vscreen, (void *)pq->drawable);
if (!tex) {
   pipe_mutex_unlock(pq->device->mutex);
   return VDP_STATUS_INVALID_HANDLE;
}
 
-   dirty_area = vscreen->get_dirty_area(vscreen);
+   if (!vscreen->set_back_texture_from_output) {
+  dirty_area = vscreen->get_dirty_area(vscreen);
 
-   memset(_templ, 0, sizeof(surf_templ));
-   surf_templ.format = tex->format;
-   surf_draw = pipe->create_surface(pipe, tex, _templ);
+  memset(_templ, 0, sizeof(surf_templ));
+  surf_templ.format = tex->format;
+  surf_draw = pipe->create_surface(pipe, tex, _templ);
 
-   dst_clip.x0 = 0;
-   dst_clip.y0 = 0;
-   dst_clip.x1 = clip_width ? clip_width : surf_draw->width;
-   dst_clip.y1 = clip_height ? clip_height : surf_draw->height;
+  dst_clip.x0 = 0;
+  dst_clip.y0 = 0;
+  dst_clip.x1 = clip_width ? clip_width : surf_draw->width;
+  dst_clip.y1 = clip_height ? clip_height : surf_draw->height;
 
-   if (pq->device->delayed_rendering.surface == surface &&
-   dst_clip.x1 == surf_draw->width && dst_clip.y1 == surf_draw->height) {
+  if (pq->device->delayed_rendering.surface == surface &&
+  dst_clip.x1 == surf_draw->width && dst_clip.y1 == surf_draw->height) 
{
 
-  // TODO: we correctly support the clipping here, but not the pq 
background color in the clipped area
-  cstate = pq->device->delayed_rendering.cstate;
-  vl_compositor_set_dst_clip(cstate, _clip);
-  vlVdpResolveDelayedRendering(pq->device, surf_draw, dirty_area);
+ // TODO: we correctly support the clipping here, but not the pq 
background color in the clipped area
+ cstate = pq->device->delayed_rendering.cstate;
+ vl_compositor_set_dst_clip(cstate, _clip);
+ vlVdpResolveDelayedRendering(pq->device, surf_draw, dirty_area);
 
-   } else {
-  vlVdpResolveDelayedRendering(pq->device, NULL, NULL);
+  } else {
+ vlVdpResolveDelayedRendering(pq->device, NULL, NULL);
 
-  src_rect.x0 = 0;
-  src_rect.y0 = 0;
-  src_rect.x1 = surf_draw->width;
-  src_rect.y1 = surf_draw->height;
+ src_rect.x0 = 0;
+ src_rect.y0 = 0;
+ src_rect.x1 = surf_draw->width;
+ src_rect.y1 = surf_draw->height;
 
-  vl_compositor_clear_layers(cstate);
-  vl_compositor_set_rgba_layer(cstate, compositor, 0, surf->sampler_view, 
_rect, NULL, NULL);
-  vl_compositor_set_dst_clip(cstate, _clip);
-  vl_compositor_render(cstate, compositor, surf_draw, dirty_area, true);
+ vl_compositor_clear_layers(cstate);
+ vl_compositor_set_rgba_layer(cstate, compositor, 0, 
surf->sampler_view, _rect, NULL, NULL);
+ vl_compositor_set_dst_clip(cstate, _clip);
+ vl_compositor_render(cstate, compositor, surf_draw, dirty_area, true);
+  }
}
 
vscreen->set_next_timestamp(vscreen, earliest_presentation_time);
@@ -297,8 +301,10 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   framenum++;
}
 
-   pipe_resource_reference(, NULL);
-   pipe_surface_reference(_draw, NULL);
+   if (!vscreen->set_back_texture_from_output) {
+  pipe_resource_reference(, NULL);
+  pipe_surface_reference(_draw, NULL);
+   }
pipe_mutex_unlock(pq->device->mutex);
 
return VDP_STATUS_OK;
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/3] Use dri3 in vdpau to send handle of texture to X

2016-11-04 Thread Nayan Deshmukh

Hi all,

This is re-send of the previous series. It contains the updated patches
in response to Leo, Christian and Emil's comments. 

Please Review.

Regards,
Nayan

Nayan Deshmukh (3):
  vl/dri3: use external texture as back buffers(v2)
  st/vdpau: use dri3 to direclty send the buffer to X(v1.1)
  st/vdpau: remove the delayed rendering hack(v1.1)

 src/gallium/auxiliary/vl/vl_winsys.h |   4 +
 src/gallium/auxiliary/vl/vl_winsys_dri3.c| 109 ---
 src/gallium/state_trackers/vdpau/bitmap.c|   2 -
 src/gallium/state_trackers/vdpau/device.c|  50 ---
 src/gallium/state_trackers/vdpau/mixer.c |  89 +-
 src/gallium/state_trackers/vdpau/output.c|   9 --
 src/gallium/state_trackers/vdpau/presentation.c  |  36 
 src/gallium/state_trackers/vdpau/vdpau_private.h |   9 --
 8 files changed, 155 insertions(+), 153 deletions(-)

-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

2016-11-02 Thread Nayan Deshmukh

Hi Leo,

To support clipping of the output texture I was trying to send a
xcb_xfixes_region as the fifth argument (i.e valid-area) to
xcb_present_pixmap but it still displays the entire surface. Am I missing
something?

Regards,
Nayan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"

2016-10-31 Thread Nayan Deshmukh

Hi Guys,

This not in master yet, I have tested it on my system(I+A) and it works
fine.

Regards,
Nayan

On Sat, Oct 1, 2016 at 1:57 PM, Christian König 
wrote:

> Am 01.10.2016 um 00:06 schrieb Marek Olšák:
>
>> On Fri, Sep 30, 2016 at 11:23 PM, Dave Airlie  wrote:
>>
>>> On 1 October 2016 at 06:11, Marek Olšák  wrote:
>>>
 On Fri, Sep 30, 2016 at 4:42 PM, Ilia Mirkin 
 wrote:

> So is this getting pushed, or should I push my "don't build vdpau for
> nouveau" patch?
>
 Please wait.

 Christian, your commit says it fixes a radeonsi issue, but Ilia says
 it breaks nouveau.

 Can we do something to accommodate both drivers? Should we add a CAP
 for whether to use a linear layout for output surfaces?

>>> I think we need a flag that isn't SHARED/LINEAR that is more
>>> SHARED_OTHER_GPU.
>>>
>> That would be useless. Most OpenGL textures can be shared with other
>> GPUs and processes via the EGL dmabuf extensions. Relying on
>> PIPE_BIND_SHARED is a bug by itself and no driver should do that.
>>
>
> Yeah, completely agree.
>
> To answer the original question the comment in the patch was about an
> issue with sharing tiling information, but I think that is long fixed by
> now.
>
> Anyway somebody needs to test this, but I don't have time right now.
>
> Christian.
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

2016-10-28 Thread Nayan Deshmukh

On Fri, Oct 28, 2016 at 2:43 PM, Michel Dänzer <mic...@daenzer.net> wrote:

> On 28/10/16 06:04 PM, Nayan Deshmukh wrote:
> > On Fri, Oct 28, 2016 at 2:14 PM, Michel Dänzer <mic...@daenzer.net
> > <mailto:mic...@daenzer.net>> wrote:
> >
> > On 28/10/16 03:58 PM, Nayan Deshmukh wrote:
> > > On Fri, Oct 28, 2016 at 7:00 AM, Michel Dänzer <mic...@daenzer.net
> <mailto:mic...@daenzer.net>
> > > <mailto:mic...@daenzer.net <mailto:mic...@daenzer.net>>> wrote:
> > >
> > > On 28/10/16 03:08 AM, Marek Olšák wrote:
> > > > On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov
> > <emil.l.veli...@gmail.com <mailto:emil.l.veli...@gmail.com>
> > <mailto:emil.l.veli...@gmail.com <mailto:emil.l.veli...@gmail.com>>>
> > wrote:
> > > >> On 17 October 2016 at 10:37, Marek Olšák <mar...@gmail.com
> <mailto:mar...@gmail.com> <mailto:mar...@gmail.com
> > <mailto:mar...@gmail.com>>> wrote:
> > > >>> Reverting the whole commit is too much. You can just
> remove the PIPE BIND
> > > >>> SHARED usage if you need to.
> > > >>>
> > > >> I'd imagine that one wants to check if radeon(s) behave OK
> with the
> > > >> flag dropped ? Thus it might be better for someone with
> radeon HW to
> > > >> give it a bash.
> > > >> Can we have a volunteer please :-)
> > > >
> > > > r600-radeonsi ignore PIPE_BIND_SHARED on textures.
> > >
> > > That doesn't mean the state tracker can just drop
> PIPE_BIND_SHARED.
> > >
> > > https://patchwork.freedesktop.org/patch/110569/
> > <https://patchwork.freedesktop.org/patch/110569/>
> > > <https://patchwork.freedesktop.org/patch/110569/
> > <https://patchwork.freedesktop.org/patch/110569/>> seems the best
> > > candidate
> > > for resolving the nouveau issue, but I suspect as is it might
> break DRI3
> > > PRIME. Nayan, can you check this and fix it up as necessary?
> Basically,
> > > PIPE_BIND_LINEAR is only really necessary for buffers which
> are sent to
> > > the X server for presentation on a different GPU.
> > >
> > > It works fine with DRI3 Prime with my I+A system, but I think it
> won't
> > > work with a I+N system as it uses PIPE_BIND_SHARE and
> PIPE_BIND_LINEAR
> > > together for one buffer.
> >
> > The patch above removes PIPE_BIND_LINEAR. Which case are you
> > thinking of?
> >
> >
> > We also use PIPE_BIND_LINEAR and PIPE_BIND_SHARED when allocating a
> > buffer in vl_winsys_dri3.c, so do we also need to change that?
>
> No, that's for sharing between different GPUs, in which case both flags
> are required (even with nouveau).
>
> Then DRI3 works fine with this change.

Regards,
Nayan.

>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

2016-10-28 Thread Nayan Deshmukh

On Fri, Oct 28, 2016 at 2:14 PM, Michel Dänzer <mic...@daenzer.net> wrote:

> On 28/10/16 03:58 PM, Nayan Deshmukh wrote:
> > On Fri, Oct 28, 2016 at 7:00 AM, Michel Dänzer <mic...@daenzer.net
> > <mailto:mic...@daenzer.net>> wrote:
> >
> > On 28/10/16 03:08 AM, Marek Olšák wrote:
> > > On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov <
> emil.l.veli...@gmail.com <mailto:emil.l.veli...@gmail.com>> wrote:
> > >> On 17 October 2016 at 10:37, Marek Olšák <mar...@gmail.com
> <mailto:mar...@gmail.com>> wrote:
> > >>> Reverting the whole commit is too much. You can just remove the
> PIPE BIND
> > >>> SHARED usage if you need to.
> > >>>
> > >> I'd imagine that one wants to check if radeon(s) behave OK with
> the
> > >> flag dropped ? Thus it might be better for someone with radeon HW
> to
> > >> give it a bash.
> > >> Can we have a volunteer please :-)
> > >
> > > r600-radeonsi ignore PIPE_BIND_SHARED on textures.
> >
> > That doesn't mean the state tracker can just drop PIPE_BIND_SHARED.
> >
> > https://patchwork.freedesktop.org/patch/110569/
> > <https://patchwork.freedesktop.org/patch/110569/> seems the best
> > candidate
> > for resolving the nouveau issue, but I suspect as is it might break
> DRI3
> > PRIME. Nayan, can you check this and fix it up as necessary?
> Basically,
> > PIPE_BIND_LINEAR is only really necessary for buffers which are sent
> to
> > the X server for presentation on a different GPU.
> >
> > It works fine with DRI3 Prime with my I+A system, but I think it won't
> > work with a I+N system as it uses PIPE_BIND_SHARE and PIPE_BIND_LINEAR
> > together for one buffer.
>
> The patch above removes PIPE_BIND_LINEAR. Which case are you thinking of?
>

We also use PIPE_BIND_LINEAR and PIPE_BIND_SHARED when allocating a
buffer in vl_winsys_dri3.c, so do we also need to change that?

>
>
> > Since this buffer is being sent to X we need to have a PIPE_BIND_LINEAR,
> > so should I send a patch removing SHARED flag, it is working fine on
> > my system without the shared flag.
>
> PIPE_BIND_LINEAR is only required for buffers which are shared between
> different GPUs. Note that in that case it's required with nouveau as well.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

2016-10-28 Thread Nayan Deshmukh

On Fri, Oct 28, 2016 at 7:00 AM, Michel Dänzer  wrote:

> On 28/10/16 03:08 AM, Marek Olšák wrote:
> > On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov 
> wrote:
> >> On 17 October 2016 at 10:37, Marek Olšák  wrote:
> >>> Reverting the whole commit is too much. You can just remove the PIPE
> BIND
> >>> SHARED usage if you need to.
> >>>
> >> I'd imagine that one wants to check if radeon(s) behave OK with the
> >> flag dropped ? Thus it might be better for someone with radeon HW to
> >> give it a bash.
> >> Can we have a volunteer please :-)
> >
> > r600-radeonsi ignore PIPE_BIND_SHARED on textures.
>
> That doesn't mean the state tracker can just drop PIPE_BIND_SHARED.
>
> https://patchwork.freedesktop.org/patch/110569/ seems the best candidate
> for resolving the nouveau issue, but I suspect as is it might break DRI3
> PRIME. Nayan, can you check this and fix it up as necessary? Basically,
> PIPE_BIND_LINEAR is only really necessary for buffers which are sent to
> the X server for presentation on a different GPU.
>
> It works fine with DRI3 Prime with my I+A system, but I think it won't
work with a I+N
system as it uses PIPE_BIND_SHARE and PIPE_BIND_LINEAR together for one
buffer.
Since this buffer is being sent to X we need to have a PIPE_BIND_LINEAR, so
should I send
a patch removing SHARED flag, it is working fine on my system without the
shared flag.

Regards,
Nayan.

>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

2016-10-27 Thread Nayan Deshmukh

On Thu, Oct 27, 2016 at 11:07 PM, Leo Liu <leo@amd.com> wrote:

>
>
> On 10/27/2016 01:20 PM, Nayan Deshmukh wrote:
>
>
>
> On Thu, Oct 27, 2016 at 10:17 PM, Leo Liu <leo@amd.com> wrote:
>
>>
>>
>> On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:
>>
>>> On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
>>>
>>>>
>>>> On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:
>>>>
>>>>> Suggested-by: Leo Liu < <leo@amd.com>leo@amd.com>
>>>>> Signed-off-by: Nayan Deshmukh < <nayan26deshm...@gmail.com>
>>>>> nayan26deshm...@gmail.com>
>>>>> ---
>>>>>src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
>>>>>src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
>>>>> +++
>>>>>2 files changed, 83 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
>>>>> b/src/gallium/auxiliary/vl/vl_winsys.h
>>>>> index 26db9f2..7c56b48 100644
>>>>> --- a/src/gallium/auxiliary/vl/vl_winsys.h
>>>>> +++ b/src/gallium/auxiliary/vl/vl_winsys.h
>>>>> @@ -59,6 +59,10 @@ struct vl_screen
>>>>>   void *
>>>>>   (*get_private)(struct vl_screen *vscreen);
>>>>> +   void
>>>>> +   (*set_output_texture)(struct vl_screen *vscreen, struct
>>>>> pipe_resource *buffer,
>>>>> + uint32_t width, uint32_t height);
>>>>> +
>>>>>
>>>> I think it's more appropriate if it's called
>>>> "set_back_texture_from_output"
>>>>
>>> Yeah that makes more sense.
>>>
>>>>   struct pipe_screen *pscreen;
>>>>>   struct pipe_loader_device *dev;
>>>>>};
>>>>> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>>> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>>> index 2929928..44d6f4c 100644
>>>>> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>>> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>>> @@ -56,6 +56,7 @@ struct vl_dri3_buffer
>>>>>   struct xshmfence *shm_fence;
>>>>>   bool busy;
>>>>> +   bool is_external_texture;
>>>>>   uint32_t width, height, pitch;
>>>>>};
>>>>> @@ -71,6 +72,9 @@ struct vl_dri3_screen
>>>>>   xcb_special_event_t *special_event;
>>>>>   struct pipe_context *pipe;
>>>>> +   struct pipe_resource *output_texture;
>>>>> +   uint32_t output_texture_width;
>>>>> +   uint32_t output_texture_height;
>>>>>   struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
>>>>>   int cur_back;
>>>>> @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
>>>>>   xcb_free_pixmap(scrn->conn, buffer->pixmap);
>>>>>   xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
>>>>>   xshmfence_unmap_shm(buffer->shm_fence);
>>>>> -   pipe_resource_reference(>texture, NULL);
>>>>> +   if (!buffer->is_external_texture)
>>>>> +  pipe_resource_reference(>texture, NULL);
>>>>>   if (buffer->linear_texture)
>>>>>   pipe_resource_reference(>linear_texture, NULL);
>>>>>   FREE(buffer);
>>>>> @@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen
>>>>> *scrn)
>>>>>   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
>>>>>   templ.target = PIPE_TEXTURE_2D;
>>>>>   templ.last_level = 0;
>>>>> -   templ.width0 = scrn->width;
>>>>> -   templ.height0 = scrn->height;
>>>>> +   if (scrn->output_texture) {
>>>>> +  templ.width0 = (scrn->output_texture_width) ?
>>>>> + scrn->output_texture_width :
>>>>> + scrn->output_texture->width0;
>>>>> +  templ.height0 = (scrn->output_texture_height) ?
>>>>> +  scrn->output_texture_height :
>>>>> +  scrn->output_texture->height0;
>>>>> +   } else {
>>>>> +   templ.width0 = scrn->width;
>>>>> +   t

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

2016-10-27 Thread Nayan Deshmukh

On Thu, Oct 27, 2016 at 10:50 PM, Nayan Deshmukh <nayan26deshm...@gmail.com>
wrote:

>
>
> On Thu, Oct 27, 2016 at 10:17 PM, Leo Liu <leo@amd.com> wrote:
>
>>
>>
>> On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:
>>
>>> On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
>>>
>>>>
>>>> On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:
>>>>
>>>>> Suggested-by: Leo Liu <leo@amd.com>
>>>>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>>>>> ---
>>>>>src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
>>>>>src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
>>>>> +++
>>>>>2 files changed, 83 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
>>>>> b/src/gallium/auxiliary/vl/vl_winsys.h
>>>>> index 26db9f2..7c56b48 100644
>>>>> --- a/src/gallium/auxiliary/vl/vl_winsys.h
>>>>> +++ b/src/gallium/auxiliary/vl/vl_winsys.h
>>>>> @@ -59,6 +59,10 @@ struct vl_screen
>>>>>   void *
>>>>>   (*get_private)(struct vl_screen *vscreen);
>>>>> +   void
>>>>> +   (*set_output_texture)(struct vl_screen *vscreen, struct
>>>>> pipe_resource *buffer,
>>>>> + uint32_t width, uint32_t height);
>>>>> +
>>>>>
>>>> I think it's more appropriate if it's called
>>>> "set_back_texture_from_output"
>>>>
>>> Yeah that makes more sense.
>>>
>>>>   struct pipe_screen *pscreen;
>>>>>   struct pipe_loader_device *dev;
>>>>>};
>>>>> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>>> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>>> index 2929928..44d6f4c 100644
>>>>> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>>> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>>> @@ -56,6 +56,7 @@ struct vl_dri3_buffer
>>>>>   struct xshmfence *shm_fence;
>>>>>   bool busy;
>>>>> +   bool is_external_texture;
>>>>>   uint32_t width, height, pitch;
>>>>>};
>>>>> @@ -71,6 +72,9 @@ struct vl_dri3_screen
>>>>>   xcb_special_event_t *special_event;
>>>>>   struct pipe_context *pipe;
>>>>> +   struct pipe_resource *output_texture;
>>>>> +   uint32_t output_texture_width;
>>>>> +   uint32_t output_texture_height;
>>>>>   struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
>>>>>   int cur_back;
>>>>> @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
>>>>>   xcb_free_pixmap(scrn->conn, buffer->pixmap);
>>>>>   xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
>>>>>   xshmfence_unmap_shm(buffer->shm_fence);
>>>>> -   pipe_resource_reference(>texture, NULL);
>>>>> +   if (!buffer->is_external_texture)
>>>>> +  pipe_resource_reference(>texture, NULL);
>>>>>   if (buffer->linear_texture)
>>>>>   pipe_resource_reference(>linear_texture, NULL);
>>>>>   FREE(buffer);
>>>>> @@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen
>>>>> *scrn)
>>>>>   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
>>>>>   templ.target = PIPE_TEXTURE_2D;
>>>>>   templ.last_level = 0;
>>>>> -   templ.width0 = scrn->width;
>>>>> -   templ.height0 = scrn->height;
>>>>> +   if (scrn->output_texture) {
>>>>> +  templ.width0 = (scrn->output_texture_width) ?
>>>>> + scrn->output_texture_width :
>>>>> + scrn->output_texture->width0;
>>>>> +  templ.height0 = (scrn->output_texture_height) ?
>>>>> +  scrn->output_texture_height :
>>>>> +  scrn->output_texture->height0;
>>>>> +   } else {
>>>>> +   templ.width0 = scrn->width;
>>>>> +   templ.height0 = scrn->height;
>>>>> +   }
>>>>>   templ.depth0 = 1;
>>>>>

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

2016-10-27 Thread Nayan Deshmukh

On Thu, Oct 27, 2016 at 10:17 PM, Leo Liu <leo@amd.com> wrote:

>
>
> On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:
>
>> On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
>>
>>>
>>> On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:
>>>
>>>> Suggested-by: Leo Liu <leo@amd.com>
>>>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
>>>> ---
>>>>src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
>>>>src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
>>>> +++
>>>>2 files changed, 83 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
>>>> b/src/gallium/auxiliary/vl/vl_winsys.h
>>>> index 26db9f2..7c56b48 100644
>>>> --- a/src/gallium/auxiliary/vl/vl_winsys.h
>>>> +++ b/src/gallium/auxiliary/vl/vl_winsys.h
>>>> @@ -59,6 +59,10 @@ struct vl_screen
>>>>   void *
>>>>   (*get_private)(struct vl_screen *vscreen);
>>>> +   void
>>>> +   (*set_output_texture)(struct vl_screen *vscreen, struct
>>>> pipe_resource *buffer,
>>>> + uint32_t width, uint32_t height);
>>>> +
>>>>
>>> I think it's more appropriate if it's called
>>> "set_back_texture_from_output"
>>>
>> Yeah that makes more sense.
>>
>>>   struct pipe_screen *pscreen;
>>>>   struct pipe_loader_device *dev;
>>>>};
>>>> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>> index 2929928..44d6f4c 100644
>>>> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>>> @@ -56,6 +56,7 @@ struct vl_dri3_buffer
>>>>   struct xshmfence *shm_fence;
>>>>   bool busy;
>>>> +   bool is_external_texture;
>>>>   uint32_t width, height, pitch;
>>>>};
>>>> @@ -71,6 +72,9 @@ struct vl_dri3_screen
>>>>   xcb_special_event_t *special_event;
>>>>   struct pipe_context *pipe;
>>>> +   struct pipe_resource *output_texture;
>>>> +   uint32_t output_texture_width;
>>>> +   uint32_t output_texture_height;
>>>>   struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
>>>>   int cur_back;
>>>> @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
>>>>   xcb_free_pixmap(scrn->conn, buffer->pixmap);
>>>>   xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
>>>>   xshmfence_unmap_shm(buffer->shm_fence);
>>>> -   pipe_resource_reference(>texture, NULL);
>>>> +   if (!buffer->is_external_texture)
>>>> +  pipe_resource_reference(>texture, NULL);
>>>>   if (buffer->linear_texture)
>>>>   pipe_resource_reference(>linear_texture, NULL);
>>>>   FREE(buffer);
>>>> @@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen
>>>> *scrn)
>>>>   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
>>>>   templ.target = PIPE_TEXTURE_2D;
>>>>   templ.last_level = 0;
>>>> -   templ.width0 = scrn->width;
>>>> -   templ.height0 = scrn->height;
>>>> +   if (scrn->output_texture) {
>>>> +  templ.width0 = (scrn->output_texture_width) ?
>>>> + scrn->output_texture_width :
>>>> + scrn->output_texture->width0;
>>>> +  templ.height0 = (scrn->output_texture_height) ?
>>>> +  scrn->output_texture_height :
>>>> +  scrn->output_texture->height0;
>>>> +   } else {
>>>> +   templ.width0 = scrn->width;
>>>> +   templ.height0 = scrn->height;
>>>> +   }
>>>>   templ.depth0 = 1;
>>>>   templ.array_size = 1;
>>>>   if (scrn->is_different_gpu) {
>>>> -  buffer->texture = scrn->base.pscreen->resource_c
>>>> reate(scrn->base.pscreen,
>>>> +  buffer->texture = (scrn->output_texture) ?
>>>> +scrn->output_texture :
>>>> +scrn->base.pscreen->resource_c
>>>> reate(scrn-&g

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

2016-10-27 Thread Nayan Deshmukh

On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
> 
> 
> On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:
> > Suggested-by: Leo Liu <leo@amd.com>
> > Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
> > ---
> >   src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
> >   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89 
> > +++
> >   2 files changed, 83 insertions(+), 10 deletions(-)
> > 
> > diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
> > b/src/gallium/auxiliary/vl/vl_winsys.h
> > index 26db9f2..7c56b48 100644
> > --- a/src/gallium/auxiliary/vl/vl_winsys.h
> > +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> > @@ -59,6 +59,10 @@ struct vl_screen
> >  void *
> >  (*get_private)(struct vl_screen *vscreen);
> > +   void
> > +   (*set_output_texture)(struct vl_screen *vscreen, struct pipe_resource 
> > *buffer,
> > + uint32_t width, uint32_t height);
> > +
> 
> I think it's more appropriate if it's called "set_back_texture_from_output"
Yeah that makes more sense.
> 
> >  struct pipe_screen *pscreen;
> >  struct pipe_loader_device *dev;
> >   };
> > diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
> > b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > index 2929928..44d6f4c 100644
> > --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > @@ -56,6 +56,7 @@ struct vl_dri3_buffer
> >  struct xshmfence *shm_fence;
> >  bool busy;
> > +   bool is_external_texture;
> >  uint32_t width, height, pitch;
> >   };
> > @@ -71,6 +72,9 @@ struct vl_dri3_screen
> >  xcb_special_event_t *special_event;
> >  struct pipe_context *pipe;
> > +   struct pipe_resource *output_texture;
> > +   uint32_t output_texture_width;
> > +   uint32_t output_texture_height;
> >  struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
> >  int cur_back;
> > @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
> >  xcb_free_pixmap(scrn->conn, buffer->pixmap);
> >  xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
> >  xshmfence_unmap_shm(buffer->shm_fence);
> > -   pipe_resource_reference(>texture, NULL);
> > +   if (!buffer->is_external_texture)
> > +  pipe_resource_reference(>texture, NULL);
> >  if (buffer->linear_texture)
> >  pipe_resource_reference(>linear_texture, NULL);
> >  FREE(buffer);
> > @@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> >  templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
> >  templ.target = PIPE_TEXTURE_2D;
> >  templ.last_level = 0;
> > -   templ.width0 = scrn->width;
> > -   templ.height0 = scrn->height;
> > +   if (scrn->output_texture) {
> > +  templ.width0 = (scrn->output_texture_width) ?
> > + scrn->output_texture_width :
> > + scrn->output_texture->width0;
> > +  templ.height0 = (scrn->output_texture_height) ?
> > +  scrn->output_texture_height :
> > +  scrn->output_texture->height0;
> > +   } else {
> > +   templ.width0 = scrn->width;
> > +   templ.height0 = scrn->height;
> > +   }
> >  templ.depth0 = 1;
> >  templ.array_size = 1;
> >  if (scrn->is_different_gpu) {
> > -  buffer->texture = 
> > scrn->base.pscreen->resource_create(scrn->base.pscreen,
> > +  buffer->texture = (scrn->output_texture) ?
> > +scrn->output_texture :
> > +
> > scrn->base.pscreen->resource_create(scrn->base.pscreen,
> >   );
> 
> Why not just make it in the same line?
> 
I was just trying to limit characters to 78 as given in mesa coding style.

> > if (!buffer->texture)
> >goto unmap_shm;
> > @@ -257,7 +273,9 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> >goto no_linear_texture;
> >  } else {
> > templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
> > -  buffer->texture = 
> > scrn->base.pscreen->resource_create(scrn->base.pscreen,
> > +  buffer->texture = (scrn->output_texture) ?
> > +scrn->output_texture :
> > +
> > scrn->base.pscreen->

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

2016-10-27 Thread Nayan Deshmukh

On Thu, Oct 27, 2016 at 11:52:13AM +0100, Andy Furniss wrote:
> Andy Furniss wrote:
> > Michel Dänzer wrote:
> > > On 26/10/16 08:07 PM, Andy Furniss wrote:
> > > > 
> > > > The bad = Starting with DRI3 (which is default) I still get trashed
> > > > rendering full screen. Windowed including re-sizing seems OK.
> > > > 
> > > > I use Fluxbox window manager, which does not use compositing -
> > > > IIRC this has historically shown some ddx DRI2/3 issue that wasn't
> > > > visible to those testing with compositing (but then the full screen
> > > > case may avoid compositing anyway depending on settings).
> > > 
> > > You may be running into a DDX driver issue fixed by
> > > https://patchwork.freedesktop.org/patch/118514/ .
> > 
> > Yes, that was it, OK with that patch.
> 
> Though "OK", sub-optimal loosing pageflip on tonga, as a vsync test
> fails top 5% of screen unless I force GPU perf high.

This reason for this is that in case of single gpu, I have to recalculate 
its handle and get a pixmap from that buffer for each frame. This calulation 
is avoided due to the presence of a linear buffer in case of different gpu.

Regards,
Nayan
> 
> Not related to this patch directly of course, but I am a bit surprised
> that on auto powerplay the tonga is too slow to make 60Hz.
> 
> Tested with CPU forced high, so it's not CPU freq.
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

2016-10-27 Thread Nayan Deshmukh

s/runs/null/ 
On Wed, Oct 26, 2016 at 01:57:12AM +0530, Nayan Deshmukh wrote:
> Hi Andy,
> 
> It seems that you have compiled mesa with DRI3 enabled but 
> vl_dri3_screen_create returns 
> runs when called in device.c and hence VDPAU fallbacks to using DRI2.
> 
> BTW I have sent in the v1.1 for patch 2 which play the video using dri2 in 
> case of a 
> fallback.
> 
> Regards,
> Nayan.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

2016-10-27 Thread Nayan Deshmukh

On Tue, Oct 25, 2016 at 11:11:13PM +0100, Andy Furniss wrote:
> Nayan Deshmukh wrote:
> > Hi Andy,
> > 
> > It seems that you have compiled mesa with DRI3 enabled but 
> > vl_dri3_screen_create returns
> > runs when called in device.c and hence VDPAU fallbacks to using DRI2.
> > 
> > BTW I have sent in the v1.1 for patch 2 which play the video using dri2 in 
> > case of a
> > fallback.
> 
> Patch 3 won't apply with new patch 2
Sorry about that. I forgot to send the patch 3 which had to 
rebased upon updated patch 2 so that it can be appplied. I 
have sent the updated patch.

Regards,
Nayan. 
> 
> error: patch failed: src/gallium/state_trackers/vdpau/presentation.c:252
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] st/vdpau: use dri3 to direclty send the buffer to X

2016-10-27 Thread Nayan Deshmukh

this avoids an extra copy which occurs in case of dri2

Suggested-by: Christian König <christian.koe...@amd.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
---
 src/gallium/state_trackers/vdpau/presentation.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index f35d73a..9051b49 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -231,12 +231,16 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
vscreen = pq->device->vscreen;
 
pipe_mutex_lock(pq->device->mutex);
+#if defined(HAVE_DRI3)
+   vscreen->set_output_texture(vscreen, surf->surface->texture, clip_width, 
clip_height);
+#endif
tex = vscreen->texture_from_drawable(vscreen, (void *)pq->drawable);
if (!tex) {
   pipe_mutex_unlock(pq->device->mutex);
   return VDP_STATUS_INVALID_HANDLE;
}
 
+#if !defined(HAVE_DRI3)
dirty_area = vscreen->get_dirty_area(vscreen);
 
memset(_templ, 0, sizeof(surf_templ));
@@ -269,6 +273,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   vl_compositor_set_dst_clip(cstate, _clip);
   vl_compositor_render(cstate, compositor, surf_draw, dirty_area, true);
}
+#endif
 
vscreen->set_next_timestamp(vscreen, earliest_presentation_time);
 
@@ -297,8 +302,10 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   framenum++;
}
 
+#if !defined(HAVE_DRI3)
pipe_resource_reference(, NULL);
pipe_surface_reference(_draw, NULL);
+#endif
pipe_mutex_unlock(pq->device->mutex);
 
return VDP_STATUS_OK;
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

1 2 3 >

1 - 100 of 241 matches

Mail list logo