Re: [Mesa-dev] [PATCH 0/5] Fix meson omx compilation

[Julien Isorce]

Thanks a lot for the fixes.
There is small issue, if fails to build with meson with 'auto' if tizonia
is installed but not bellagio because ENABLE_ST_OMX_BELLAGIO will remain
defined.
Though it can be added afterward, and the series is:
Tested-by: Julien Isorce <julien.iso...@gmail.com>

On 7 March 2018 at 13:44, Eric Engestrom <eric.engest...@imgtec.com> wrote:

> On Tuesday, 2018-03-06 11:57:11 -0800, Dylan Baker wrote:
> > This fixes a couple of problems with the meson build support for the
> > recent omx tizonia integration, namely that it breaks a lot of
> > previously working meson configurations.
>
> Thanks! Series is:
> Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
>
> >
> > The biggest change in here is the reintroduction of the 'auto' flag to
> > -Dgallium-omx. This allows configurations that lack tizonia, or that
> > otherwise can't build the omx tracker (i965, and gallium drivers other
> > than r600, radeon, or nouveau) to build without intervention.
> >
> > This also fixes some style things, but those are pretty trivial.
> >
> > Dylan Baker (5):
> >   meson: combine state trackers and target if blocks
> >   meson: fix tizonia compilation
> >   meson: Re-add auto option for omx
> >   meson: Use include directory variables instead of traversing
> >   meson: Fix indent in omx meson.build
> >
> >  meson.build| 67
> +++--
> >  meson_options.txt  |  4 +-
> >  src/egl/meson.build|  5 ++-
> >  src/gallium/meson.build| 30 -
> >  src/gallium/state_trackers/dri/meson.build |  2 +
> >  src/gallium/state_trackers/omx/meson.build | 69
> +++---
> >  src/gbm/meson.build|  2 +-
> >  7 files changed, 95 insertions(+), 84 deletions(-)
> >
> > --
> > 2.16.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
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/6] st/omx/tizonia: Add --enable-omx-tizonia flag and build files

[Julien Isorce]

Hi Leo,

Do you have enough data to start the merge ?

Thx
Julien

On 18 January 2018 at 02:28, Gurkirpal Singh <gurkirpal...@gmail.com> wrote:

>
>
> On Wed, Jan 17, 2018 at 10:39 PM, Dylan Baker <dy...@pnwbakers.com> wrote:
>
>> The meson build for omx-bellagio has landed along with the other media
>> state
>> trackers that are in tree. Currently there is a known bug with at least
>> vdpau
>> and va-api (I suspect that the omx, va, and xvmc are affected as well)
>> which
>> causes required symbols to not be exported, I'm still trying to resolve
>> that.
>>
>> For Tizonia, what I'd like to do is change the -Dgallium-omx argument to
>> accept
>> ['auto', 'bellagio', 'tizonia', 'disabled'] (this mirrors the glx
>> option), with
>> auto trying to find bellagio and tizonia in some order and falling back to
>> disabled if neither is found.
>>
>> The patches in this thread don't apply, there is some other work on you
>> tree not
>> included maybe? Or I'd see about adding it (I don't think it would be too
>> hard).
>> Do you have this series in a public git repo I could pull from?
>>
>
> I decided not to commit incomplete work so there are only these commits in
> the repo.
> I have it on my github repo branch "refactor_stomx"
> https://github.com/gpalsingh/mesa/commits/refactor_stomx
>
> Cheers
>
>>
>> Dylan
>>
>> Quoting Leo Liu (2018-01-17 08:23:54)
>> >
>> >
>> > On 01/17/2018 11:19 AM, Gurkirpal Singh wrote:
>> >
>> >
>> >
>> > On Wed, Jan 17, 2018 at 8:22 PM, Leo Liu <leo@amd.com> wrote:
>> >
>> > Hi Gurkirpal,
>> >
>> > Do we have patch 1 in the 6 patch set, or it hasn't arrived.
>> >
>> >
>> > We do have a patch 1 which has been held for moderation for being
>> too
>> > large.
>> >
>> > If there is no arrival tomorrow, please send it as attachment. Thanks.
>> >
>> >
>> >
>> > Also I haven't seen the updates for Meson build in the current
>> set.
>> >
>> >
>> > I wasn't sure if the changes needed to be added to this commit or
>> add a new
>> > commit.
>> >
>> >
>> > I think Dylan can give you advice on this for sure.
>> >
>> > Thanks,
>> > Leo
>> >
>> >
>> >
>> >
>> >
>> > @Dylan, if possible, could you give an update for the Meson
>> build on
>> > the current set?
>> >
>> >
>> > Thanks,
>> >
>> > Leo
>> >
>> >
>> >
>> >
>> > On 01/17/2018 08:54 AM, Gurkirpal Singh wrote:
>> >
>> > Allow only bellagio or tizonia to be used at the same time.
>> > Detect tizonia package config file
>> > Generate libomx_mesa.so and install it to
>> libtizcore.pc::pluginsdir
>> > Only compile empty source (target.c) for now.
>> >
>> > GSoC Project link: https://summerofcode.withgoogl
>> e.com/projects/#
>> > 4737166321123328
>> >
>> > Acked-by: Leo Liu <leo@amd.com>
>> > Reviewed-by: Julien Isorce <julien.iso...@gmail.com>
>> > ---
>> >   configure.ac   | 47
>> > +-
>> >   src/gallium/Makefile.am|  4 ++
>> >   src/gallium/state_trackers/omx/Makefile.am | 13
>> ++
>> >   src/gallium/state_trackers/omx/tizonia/Makefile.am | 36
>> > +
>> >   .../state_trackers/omx/tizonia/Makefile.sources|  1 +
>> >   src/gallium/targets/omx/Makefile.am| 19
>> -
>> >   src/gallium/targets/omx/omx.sym|  1 +
>> >   7 files changed, 117 insertions(+), 4 deletions(-)
>> >   create mode 100644 src/gallium/state_trackers/omx
>> /tizonia/
>> > Makefile.am
>> >   create mode 100644 src/gallium/state_trackers/omx
>> /tizonia/
>> > Makefile.sources
>> >
>> > diff --git a/configure.ac b/configure.ac
>> > index 7675a45..1f7b163 100644
>> &

Re: [Mesa-dev] [PATCH 1/7] gallium: Refactor out vl_put_screen and vl_get_screen

[Julien Isorce]

Hi Christian,

>> Otherwise I'm going to give it a few more days on the list and push it
if nobody objects.

Gentle ping ? So far the series are:

Acked-by: Leo Liu <leo@amd.com> <leo@amd.com>
Reviewed-by: Julien Isorce <julien.iso...@gmail.com>

Thx
Julien

On 30 November 2017 at 14:05, Leo Liu <leo@amd.com> wrote:

>
>
> On 11/30/2017 06:22 AM, Julien Isorce wrote:
>
> Hi Gurkirpal,
>
> > Before refactoring process both the state trackers were in independent
> directories.
> > During earlier refactoring effort we decided to keep that directory
> structure so it made
> > sense to move them to auxiliary code. After that I moved them both under
> st/omx.
> > Since there could be a chance of it being useful out of st/omx, I left
> the decision to
> > keep it or move it back to st/omx to the mailing list.
>
> Yes please move it back to st/omx for the reasons you said, i.e. there
> will now 2
> sub directories, st/omx/bellagio and st/omx/tizonia and common code in
> st/omx.
>
> Yes. Please move them back to st/omx.
>
> With that fixed, the series are:
>
> Acked-by: Leo Liu <leo@amd.com> <leo@amd.com>
>
> Thanks for the work!
>
> Leo
>
>
>
>
> Another reason is that the env var "OMX_RENDER_NODE" mentions OMX.
>
> Thx!
> Julien
>
>
> On 29 November 2017 at 04:02, Gurkirpal Singh <gurkirpal...@gmail.com>
> wrote:
>
>> ---
>>  src/gallium/auxiliary/Makefile.sources |   2 +
>>  src/gallium/auxiliary/vl/vl_screen.c   | 107
>> +
>>  src/gallium/auxiliary/vl/vl_screen.h   |  33 +++
>>  .../state_trackers/omx_bellagio/entrypoint.c   |  83
>> 
>>  .../state_trackers/omx_bellagio/entrypoint.h   |   3 -
>>  src/gallium/state_trackers/omx_bellagio/vid_dec.c  |   5 +-
>>  src/gallium/state_trackers/omx_bellagio/vid_enc.c  |   5 +-
>>  7 files changed, 148 insertions(+), 90 deletions(-)
>>  create mode 100644 src/gallium/auxiliary/vl/vl_screen.c
>>  create mode 100644 src/gallium/auxiliary/vl/vl_screen.h
>>
>> diff --git a/src/gallium/auxiliary/Makefile.sources
>> b/src/gallium/auxiliary/Makefile.sources
>> index f40c472..35e89f9 100644
>> --- a/src/gallium/auxiliary/Makefile.sources
>> +++ b/src/gallium/auxiliary/Makefile.sources
>> @@ -343,6 +343,8 @@ VL_SOURCES := \
>> vl/vl_mpeg12_decoder.c \
>> vl/vl_mpeg12_decoder.h \
>> vl/vl_rbsp.h \
>> +   vl/vl_screen.c \
>> +   vl/vl_screen.h \
>> vl/vl_types.h \
>> vl/vl_vertex_buffers.c \
>> vl/vl_vertex_buffers.h \
>> diff --git a/src/gallium/auxiliary/vl/vl_screen.c
>> b/src/gallium/auxiliary/vl/vl_screen.c
>> new file mode 100644
>> index 000..7192802
>> --- /dev/null
>> +++ b/src/gallium/auxiliary/vl/vl_screen.c
>> @@ -0,0 +1,107 @@
>> +/**
>> 
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining
>> a
>> + * copy of this software and associated documentation files (the
>> + * "Software"), to deal in the Software without restriction, including
>> + * without limitation the rights to use, copy, modify, merge, publish,
>> + * distribute, sub license, and/or sell copies of the Software, and to
>> + * permit persons to whom the Software is furnished to do so, subject to
>> + * the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the
>> + * next paragraph) shall be included in all copies or substantial
>> portions
>> + * of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS
>> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> NON-INFRINGEMENT.
>> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
>> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
>> CONTRACT,
>> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
>> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>> + *
>> + 
>> **/
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "os/os_thread.h"
>> +#include "util/u_memory.h"
>> +#include "loader/loader.h"

Re: [Mesa-dev] Refactored st/omx/tizonia commits

[Julien Isorce]

Hi Gurkirpal, I am glad to see you continue working on this out of the GSoC
project.
I have reviewed it already during that period so just giving my official
"the series is:"

Reviewed-by: Julien Isorce <julien.iso...@gmail.com>

On 30 November 2017 at 00:23, Dylan Baker <dy...@pnwbakers.com> wrote:

> Quoting Eric Engestrom (2017-11-29 07:19:02)
> > On Wednesday, 2017-11-29 09:32:09 +0530, Gurkirpal Singh wrote:
> > > These are the refactored commits related to the GSoC project involving
> > > adding a st/omx state tracker using tizonia.
> > > There are still some parts of code that i didn't refactor yet as
> > > explained below:
> > > 1) I wasn't sure if it's okay to use #if-#else declaratives for
> function
> > > declarations. For eg: One function accepts omx_base_PortType and the
> other
> > > one vid_dec_PrivateType
> > > 2) Because of the argument type differences there is excessive amounts
> of
> > > #if-#else pairs will be needed
> > > So I decided to wait for review before making those changes.
> >
> > I notice you left the meson build system out; could you give it a stab?
> > Feel free to ask me or Dylan for help if you get stuck :)
>
> Do note that the meson omx code hasn't landed yet (hopefully that will
> happen
> in the next day or two though).
>
> One thing I'm not sure about there is how to handle the command line
> option to
> enable the build. Currently it's `gallium-omx`, and accepts, 'true',
> 'false',
> and 'auto'. It might make sense to make it more like the glx option, and
> accept
> 'auto', 'bellagio', 'disabled', and when this lands 'tizonia'.
>
> Dylan
>
> ___
> 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 1/7] gallium: Refactor out vl_put_screen and vl_get_screen

[Julien Isorce]

Hi Gurkirpal,

> Before refactoring process both the state trackers were in independent
directories.
> During earlier refactoring effort we decided to keep that directory
structure so it made
> sense to move them to auxiliary code. After that I moved them both under
st/omx.
> Since there could be a chance of it being useful out of st/omx, I left
the decision to
> keep it or move it back to st/omx to the mailing list.

Yes please move it back to st/omx for the reasons you said, i.e. there will
now 2
sub directories, st/omx/bellagio and st/omx/tizonia and common code in
st/omx.

Another reason is that the env var "OMX_RENDER_NODE" mentions OMX.

Thx!
Julien


On 29 November 2017 at 04:02, Gurkirpal Singh 
wrote:

> ---
>  src/gallium/auxiliary/Makefile.sources |   2 +
>  src/gallium/auxiliary/vl/vl_screen.c   | 107
> +
>  src/gallium/auxiliary/vl/vl_screen.h   |  33 +++
>  .../state_trackers/omx_bellagio/entrypoint.c   |  83 
>  .../state_trackers/omx_bellagio/entrypoint.h   |   3 -
>  src/gallium/state_trackers/omx_bellagio/vid_dec.c  |   5 +-
>  src/gallium/state_trackers/omx_bellagio/vid_enc.c  |   5 +-
>  7 files changed, 148 insertions(+), 90 deletions(-)
>  create mode 100644 src/gallium/auxiliary/vl/vl_screen.c
>  create mode 100644 src/gallium/auxiliary/vl/vl_screen.h
>
> diff --git a/src/gallium/auxiliary/Makefile.sources
> b/src/gallium/auxiliary/Makefile.sources
> index f40c472..35e89f9 100644
> --- a/src/gallium/auxiliary/Makefile.sources
> +++ b/src/gallium/auxiliary/Makefile.sources
> @@ -343,6 +343,8 @@ VL_SOURCES := \
> vl/vl_mpeg12_decoder.c \
> vl/vl_mpeg12_decoder.h \
> vl/vl_rbsp.h \
> +   vl/vl_screen.c \
> +   vl/vl_screen.h \
> vl/vl_types.h \
> vl/vl_vertex_buffers.c \
> vl/vl_vertex_buffers.h \
> diff --git a/src/gallium/auxiliary/vl/vl_screen.c
> b/src/gallium/auxiliary/vl/vl_screen.c
> new file mode 100644
> index 000..7192802
> --- /dev/null
> +++ b/src/gallium/auxiliary/vl/vl_screen.c
> @@ -0,0 +1,107 @@
> +/**
> 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
> CONTRACT,
> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + 
> **/
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "os/os_thread.h"
> +#include "util/u_memory.h"
> +#include "loader/loader.h"
> +#include "vl_screen.h"
> +
> +#if defined(HAVE_X11_PLATFORM)
> +#include 
> +#else
> +#define XOpenDisplay(x) NULL
> +#define XCloseDisplay(x)
> +#define Display void
> +#endif
> +
> +static mtx_t st_lock = _MTX_INITIALIZER_NP;
> +static Display *st_display = NULL;
> +static struct vl_screen *st_screen = NULL;
> +static unsigned st_usecount = 0;
> +static const char *st_render_node = NULL;
> +static int drm_fd;
> +
> +struct vl_screen *vl_get_screen(const char* render_node)
> +{
> +   static bool first_time = true;
> +   mtx_lock(_lock);
> +
> +   if (!st_screen) {
> +  if (first_time) {
> + st_render_node = debug_get_option(render_node, NULL);
> + first_time = false;
> +  }
> +  if (st_render_node) {
> + drm_fd = loader_open_device(st_render_node);
> + if (drm_fd < 0)
> +goto error;
> +
> + st_screen = vl_drm_screen_create(drm_fd);
> + if (!st_screen) {
> +close(drm_fd);
> +goto error;
> + }
> +  } else {
> + st_display = XOpenDisplay(NULL);
> + if (!st_display)
> +goto error;
> +
> + st_screen = vl_dri3_screen_create(st_display, 0);
> + if (!st_screen)
> +st_screen = vl_dri2_screen_create(st_display, 0);
> + if (!st_screen) {
> +XCloseDisplay(st_display);
> +goto 

[Mesa-dev] [PATCH] i965: implement (un)mapImage

[Julien Isorce]

Already implemented for Gallium drivers.

Useful for gbm_bo_(un)map.

Tests:
  By porting wayland/weston/clients/simple-dmabuf-drm.c to GBM.
  kmscube --mode=rgba
  kmscube --mode=nv12-1img
  kmscube --mode=nv12-2img
  piglit ext_image_dma_buf_import-refcount -auto
  piglit ext_image_dma_buf_import-transcode-nv12-as-r8-gr88 -auto
  piglit ext_image_dma_buf_import-sample_rgb -fmt=XR24 -alpha-one -auto
  piglit ext_image_dma_buf_import-sample_rgb -fmt=AR24 -auto
  piglit ext_image_dma_buf_import-sample_yuv -fmt=NV12 -auto
  piglit ext_image_dma_buf_import-sample_yuv -fmt=YU12 -auto
  piglit ext_image_dma_buf_import-sample_yuv -fmt=YV12 -auto

v2: add early return if (flag & MAP_INTERNAL_MASK)
v3: take input rect into account and test with kmscube and piglit.
v4: handle wraparound and bo reference.
v5: indent, exclude 0 width and height on the boundary, map bo
independently of the image.

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/mesa/drivers/dri/i965/intel_screen.c | 65 +++-
 1 file changed, 63 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index cdc36ad..88bd982 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -755,6 +755,67 @@ intel_create_image(__DRIscreen *dri_screen,
loaderPrivate);
 }
 
+static void *
+intel_map_image(__DRIcontext *context, __DRIimage *image,
+int x0, int y0, int width, int height,
+unsigned int flags, int *stride, void **map_info)
+{
+   struct brw_context *brw = NULL;
+   struct brw_bo *bo = NULL;
+   void *raw_data = NULL;
+   GLuint pix_w = 1;
+   GLuint pix_h = 1;
+   GLint pix_bytes = 1;
+
+   if (!context || !image || !stride || !map_info || *map_info)
+  return NULL;
+
+   if (x0 < 0 || x0 >= image->width || width > image->width - x0)
+  return NULL;
+
+   if (y0 < 0 || y0 >= image->height || height > image->height - y0)
+return NULL;
+
+   if (flags & MAP_INTERNAL_MASK)
+  return NULL;
+
+   brw = context->driverPrivate;
+   bo = image->bo;
+
+   assert(brw);
+   assert(bo);
+
+   /* DRI flags and GL_MAP.*_BIT flags are the same, so just pass them on. */
+   raw_data = brw_bo_map(brw, bo, flags);
+   if (!raw_data)
+  return NULL;
+
+   _mesa_get_format_block_size(image->format, _w, _h);
+   pix_bytes = _mesa_get_format_bytes(image->format);
+
+   assert(pix_w);
+   assert(pix_h);
+   assert(pix_bytes > 0);
+
+   raw_data += ((x0 / pix_w) * pix_bytes) + (y0 / pix_h) * image->pitch;
+
+   brw_bo_reference(bo);
+
+   *stride = image->pitch;
+   *map_info = bo;
+
+   return raw_data;
+}
+
+static void
+intel_unmap_image(__DRIcontext *context, __DRIimage *image, void *map_info)
+{
+   struct brw_bo *bo = map_info;
+
+   brw_bo_unmap(bo);
+   brw_bo_unreference(bo);
+}
+
 static __DRIimage *
 intel_create_image_with_modifiers(__DRIscreen *dri_screen,
   int width, int height, int format,
@@ -1305,8 +1366,8 @@ static const __DRIimageExtension intelImageExtension = {
 .createImageFromDmaBufs = intel_create_image_from_dma_bufs,
 .blitImage  = NULL,
 .getCapabilities= NULL,
-.mapImage   = NULL,
-.unmapImage = NULL,
+.mapImage   = intel_map_image,
+.unmapImage = intel_unmap_image,
 .createImageWithModifiers   = intel_create_image_with_modifiers,
 .createImageFromDmaBufs2= intel_create_image_from_dma_bufs2,
 .queryDmaBufFormats = intel_query_dma_buf_formats,
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] i965: implement (un)mapImage

[Julien Isorce]

Thx for pointing that.

Gentle ping, anyone wants to mark 'reviewed' this patch ?

On 10 November 2017 at 16:18, Rafael Antognolli <rafael.antogno...@intel.com
> wrote:

> On Fri, Nov 10, 2017 at 10:46:03AM +0000, Julien Isorce wrote:
> > Thx for the suggestions.
> >
> > Anyone familiar with _mesa_get_format_block_size and
> _mesa_get_format_bytes
> > wants to review this patch ?
> >
> > On 9 November 2017 at 17:10, Eric Engestrom <eric.engest...@imgtec.com>
> wrote:
> >
> > On Thursday, 2017-11-09 17:03:13 +, Julien Isorce wrote:
> > > v2: add early return if (flag & MAP_INTERNAL_MASK)
> > > v3: take input rect into account and test with kmscube and piglit.
> > > v4: handle wraparound and bo reference.
>
> Just nitpick, but in case you need to respin a new version of this
> patch, please consider adding the changelog (v2-n) after the commit
> description. See other commits for some examples.
>
> Rafael
>
> > > Already implemented for Gallium drivers.
> > >
> > > Useful for gbm_bo_(un)map.
> > >
> > > Tests:
> > >   By porting wayland/weston/clients/simple-dmabuf-drm.c to GBM.
> > >   kmscube --mode=rgba
> > >   kmscube --mode=nv12-1img
> > >   kmscube --mode=nv12-2img
> > >   piglit ext_image_dma_buf_import-refcount -auto
> > >   piglit ext_image_dma_buf_import-transcode-nv12-as-r8-gr88 -auto
> > >   piglit ext_image_dma_buf_import-sample_rgb -fmt=AR24 -alpha-one
> -auto
> > >   piglit ext_image_dma_buf_import-sample_rgb -fmt=XR24 -auto
> > >   piglit ext_image_dma_buf_import-sample_yuv -fmt=NV12 -auto
> > >   piglit ext_image_dma_buf_import-sample_yuv -fmt=YU12 -auto
> > >   piglit ext_image_dma_buf_import-sample_yuv -fmt=YV12 -auto
> > >
> > > Signed-off-by: Julien Isorce <jiso...@oblong.com>
> > > ---
> > >  src/mesa/drivers/dri/i965/intel_screen.c | 75
> > +++-
> > >  1 file changed, 73 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/
> > dri/i965/intel_screen.c
> > > index cdc36ad..6074ee8 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > > +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> > > @@ -755,6 +755,77 @@ intel_create_image(__DRIscreen *dri_screen,
> > > loaderPrivate);
> > >  }
> > >
> > > +static void *
> > > +intel_map_image(__DRIcontext *context, __DRIimage *image,
> > > +int x0, int y0, int width, int height,
> > > +unsigned int flags, int *stride, void **map_info)
> > > +{
> > > +   struct brw_context *brw = NULL;
> > > +   struct brw_bo *bo = NULL;
> > > +   void *raw_data = NULL;
> > > +
> > > +   if (!context || !image || !stride || !map_info || *map_info)
> > > +  return NULL;
> > > +
> > > +   if (x0 < 0 || x0 > image->width || width > image->width - x0)
> > > +  return NULL;
> > > +
> > > +   if (y0 < 0 || y0 > image->height || height > image->height -
> y0)
> > > +return NULL;
> > > +
> > > +   if (flags & MAP_INTERNAL_MASK)
> > > +  return NULL;
> > > +
> > > +   brw = context->driverPrivate;
> > > +   bo = image->bo;
> > > +
> > > +   assert(brw);
> > > +   assert(bo);
> > > +
> > > +   brw_bo_reference(bo);
> > > +
> > > +   /* DRI flags and GL_MAP.*_BIT flags are the same, so just pass
> them
> > on. */
> > > +   raw_data = brw_bo_map(brw, bo, flags);
> > > +
> > > +   if (raw_data) {
> > > +  GLuint pix_w = 1;
> > > +  GLuint pix_h = 1;
> > > +  GLint pix_bytes = 1;
> > > +
> > > +  *map_info = raw_data;
> > > +  *stride = image->pitch;
> > > +
> > > +  _mesa_get_format_block_size(image->format, _w, _h);
> > > +  pix_bytes = _mesa_get_format_bytes(image->format);
> > > +
> > > +  assert(pix_w);
> > > +  assert(pix_h);
> > > +  assert(pix_by

Re: [Mesa-dev] [PATCH] i965: implement (un)mapImage

[Julien Isorce]

Thx for the suggestions.

Anyone familiar with _mesa_get_format_block_size and _mesa_get_format_bytes
wants to review this patch ?

On 9 November 2017 at 17:10, Eric Engestrom <eric.engest...@imgtec.com>
wrote:

> On Thursday, 2017-11-09 17:03:13 +0000, Julien Isorce wrote:
> > v2: add early return if (flag & MAP_INTERNAL_MASK)
> > v3: take input rect into account and test with kmscube and piglit.
> > v4: handle wraparound and bo reference.
> >
> > Already implemented for Gallium drivers.
> >
> > Useful for gbm_bo_(un)map.
> >
> > Tests:
> >   By porting wayland/weston/clients/simple-dmabuf-drm.c to GBM.
> >   kmscube --mode=rgba
> >   kmscube --mode=nv12-1img
> >   kmscube --mode=nv12-2img
> >   piglit ext_image_dma_buf_import-refcount -auto
> >   piglit ext_image_dma_buf_import-transcode-nv12-as-r8-gr88 -auto
> >   piglit ext_image_dma_buf_import-sample_rgb -fmt=AR24 -alpha-one -auto
> >   piglit ext_image_dma_buf_import-sample_rgb -fmt=XR24 -auto
> >   piglit ext_image_dma_buf_import-sample_yuv -fmt=NV12 -auto
> >   piglit ext_image_dma_buf_import-sample_yuv -fmt=YU12 -auto
> >   piglit ext_image_dma_buf_import-sample_yuv -fmt=YV12 -auto
> >
> > Signed-off-by: Julien Isorce <jiso...@oblong.com>
> > ---
> >  src/mesa/drivers/dri/i965/intel_screen.c | 75
> +++-
> >  1 file changed, 73 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> > index cdc36ad..6074ee8 100644
> > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> > @@ -755,6 +755,77 @@ intel_create_image(__DRIscreen *dri_screen,
> > loaderPrivate);
> >  }
> >
> > +static void *
> > +intel_map_image(__DRIcontext *context, __DRIimage *image,
> > +int x0, int y0, int width, int height,
> > +unsigned int flags, int *stride, void **map_info)
> > +{
> > +   struct brw_context *brw = NULL;
> > +   struct brw_bo *bo = NULL;
> > +   void *raw_data = NULL;
> > +
> > +   if (!context || !image || !stride || !map_info || *map_info)
> > +  return NULL;
> > +
> > +   if (x0 < 0 || x0 > image->width || width > image->width - x0)
> > +  return NULL;
> > +
> > +   if (y0 < 0 || y0 > image->height || height > image->height - y0)
> > +return NULL;
> > +
> > +   if (flags & MAP_INTERNAL_MASK)
> > +  return NULL;
> > +
> > +   brw = context->driverPrivate;
> > +   bo = image->bo;
> > +
> > +   assert(brw);
> > +   assert(bo);
> > +
> > +   brw_bo_reference(bo);
> > +
> > +   /* DRI flags and GL_MAP.*_BIT flags are the same, so just pass them
> on. */
> > +   raw_data = brw_bo_map(brw, bo, flags);
> > +
> > +   if (raw_data) {
> > +  GLuint pix_w = 1;
> > +  GLuint pix_h = 1;
> > +  GLint pix_bytes = 1;
> > +
> > +  *map_info = raw_data;
> > +  *stride = image->pitch;
> > +
> > +  _mesa_get_format_block_size(image->format, _w, _h);
> > +  pix_bytes = _mesa_get_format_bytes(image->format);
> > +
> > +  assert(pix_w);
> > +  assert(pix_h);
> > +  assert(pix_bytes > 0);
> > +
> > +  raw_data += ((x0 / pix_w) * pix_bytes) + (y0 / pix_h) *
> image->pitch;
> > +   } else {
> > +  brw_bo_unreference(bo);
> > +   }
>
> Feels really nit-picky, so don't send a new rev just for that, but:
>
>if (!raw_data) {
>   brw_bo_unreference(bo);
>   return NULL;
>}
>
>/* code from the `if (raw_data)` branch */
>
> that way you don't have to carry around the indentation :)
>
> > +
> > +   return raw_data;
> > +}
> > +
> > +static void
> > +intel_unmap_image(__DRIcontext *context, __DRIimage *image, void
> *map_info)
> > +{
> > +   struct brw_bo *bo = NULL;
> > +
> > +   if (!context || !image || !map_info)
> > +  return;
> > +
> > +   bo = image->bo;
> > +
> > +   assert(bo);
> > +
> > +   brw_bo_unmap(bo);
> > +   brw_bo_unreference(bo);
> > +}
> > +
> >  static __DRIimage *
> >  intel_create_image_with_modifiers(__DRIscreen *dri_screen,
> >int width, int height, int format,
> > @@ -1305,8 +1376,8 @@ static const __DRIimageExtension
> intelImageExtension = {
> > 

[Mesa-dev] [PATCH] i965: implement (un)mapImage

[Julien Isorce]

v2: add early return if (flag & MAP_INTERNAL_MASK)
v3: take input rect into account and test with kmscube and piglit.
v4: handle wraparound and bo reference.

Already implemented for Gallium drivers.

Useful for gbm_bo_(un)map.

Tests:
  By porting wayland/weston/clients/simple-dmabuf-drm.c to GBM.
  kmscube --mode=rgba
  kmscube --mode=nv12-1img
  kmscube --mode=nv12-2img
  piglit ext_image_dma_buf_import-refcount -auto
  piglit ext_image_dma_buf_import-transcode-nv12-as-r8-gr88 -auto
  piglit ext_image_dma_buf_import-sample_rgb -fmt=AR24 -alpha-one -auto
  piglit ext_image_dma_buf_import-sample_rgb -fmt=XR24 -auto
  piglit ext_image_dma_buf_import-sample_yuv -fmt=NV12 -auto
  piglit ext_image_dma_buf_import-sample_yuv -fmt=YU12 -auto
  piglit ext_image_dma_buf_import-sample_yuv -fmt=YV12 -auto

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/mesa/drivers/dri/i965/intel_screen.c | 75 +++-
 1 file changed, 73 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index cdc36ad..6074ee8 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -755,6 +755,77 @@ intel_create_image(__DRIscreen *dri_screen,
loaderPrivate);
 }
 
+static void *
+intel_map_image(__DRIcontext *context, __DRIimage *image,
+int x0, int y0, int width, int height,
+unsigned int flags, int *stride, void **map_info)
+{
+   struct brw_context *brw = NULL;
+   struct brw_bo *bo = NULL;
+   void *raw_data = NULL;
+
+   if (!context || !image || !stride || !map_info || *map_info)
+  return NULL;
+
+   if (x0 < 0 || x0 > image->width || width > image->width - x0)
+  return NULL;
+
+   if (y0 < 0 || y0 > image->height || height > image->height - y0)
+return NULL;
+
+   if (flags & MAP_INTERNAL_MASK)
+  return NULL;
+
+   brw = context->driverPrivate;
+   bo = image->bo;
+
+   assert(brw);
+   assert(bo);
+
+   brw_bo_reference(bo);
+
+   /* DRI flags and GL_MAP.*_BIT flags are the same, so just pass them on. */
+   raw_data = brw_bo_map(brw, bo, flags);
+
+   if (raw_data) {
+  GLuint pix_w = 1;
+  GLuint pix_h = 1;
+  GLint pix_bytes = 1;
+
+  *map_info = raw_data;
+  *stride = image->pitch;
+
+  _mesa_get_format_block_size(image->format, _w, _h);
+  pix_bytes = _mesa_get_format_bytes(image->format);
+
+  assert(pix_w);
+  assert(pix_h);
+  assert(pix_bytes > 0);
+
+  raw_data += ((x0 / pix_w) * pix_bytes) + (y0 / pix_h) * image->pitch;
+   } else {
+  brw_bo_unreference(bo);
+   }
+
+   return raw_data;
+}
+
+static void
+intel_unmap_image(__DRIcontext *context, __DRIimage *image, void *map_info)
+{
+   struct brw_bo *bo = NULL;
+
+   if (!context || !image || !map_info)
+  return;
+
+   bo = image->bo;
+
+   assert(bo);
+
+   brw_bo_unmap(bo);
+   brw_bo_unreference(bo);
+}
+
 static __DRIimage *
 intel_create_image_with_modifiers(__DRIscreen *dri_screen,
   int width, int height, int format,
@@ -1305,8 +1376,8 @@ static const __DRIimageExtension intelImageExtension = {
 .createImageFromDmaBufs = intel_create_image_from_dma_bufs,
 .blitImage  = NULL,
 .getCapabilities= NULL,
-.mapImage   = NULL,
-.unmapImage = NULL,
+.mapImage   = intel_map_image,
+.unmapImage = intel_unmap_image,
 .createImageWithModifiers   = intel_create_image_with_modifiers,
 .createImageFromDmaBufs2= intel_create_image_from_dma_bufs2,
 .queryDmaBufFormats = intel_query_dma_buf_formats,
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] i965: implement (un)mapImage

[Julien Isorce]

Hi Emil,

Thx for the suggestion about kmscube and piglit. I tried them and I have
sent a v3 patch.

Hi Chris,

I can see that in Ben's patch it calls brw_bo_unreference instead of
brw_bo_unmap.
Also the existing brw_bo_unmap is a no op (strange it is implemented as
just return 0)
Any idea ?

Thx
Julien


On 8 November 2017 at 17:18, Emil Velikov <emil.l.veli...@gmail.com> wrote:

> Hi Julien,
>
> On 8 November 2017 at 16:55, Julien Isorce <julien.iso...@gmail.com>
> wrote:
> > v2: add early return if (flag & MAP_INTERNAL_MASK)
> >
> > Already implemented for Gallium drivers.
> >
> > Useful for gbm_bo_(un)map.
> >
> > Tested by porting wayland/weston/clients/simple-dmabuf-drm.c to GBM.
> >
> Ben did a slightly different implementation a while back [1], but it
> never got merged due to shortage of review.
> Glad to see some interest on the topic.
>
> On the testing side - the ext_image_dma_buf_import piglit tests +
> kmscube should help, alongside your weston* case.
>
> HTH
> Emil
>
> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-April/152646.html
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: implement (un)mapImage

[Julien Isorce]

v2: add early return if (flag & MAP_INTERNAL_MASK)
v3: take input rect into account and test with kmscube and piglit.

Already implemented for Gallium drivers.

Useful for gbm_bo_(un)map.

Tests:
  By porting wayland/weston/clients/simple-dmabuf-drm.c to GBM.
  kmscube --mode=rgba
  kmscube --mode=nv12-1img
  kmscube --mode=nv12-2img
  piglit ext_image_dma_buf_import-refcount -auto
  piglit ext_image_dma_buf_import-transcode-nv12-as-r8-gr88 -auto
  piglit ext_image_dma_buf_import-sample_rgb -fmt=AR24 -alpha-one -auto
  piglit ext_image_dma_buf_import-sample_rgb -fmt=XR24 -auto
  piglit ext_image_dma_buf_import-sample_yuv -fmt=NV12 -auto
  piglit ext_image_dma_buf_import-sample_yuv -fmt=YU12 -auto
  piglit ext_image_dma_buf_import-sample_yuv -fmt=YV12 -auto

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/mesa/drivers/dri/i965/intel_screen.c | 68 +++-
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index cdc36ad..8de78b2 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -755,6 +755,70 @@ intel_create_image(__DRIscreen *dri_screen,
loaderPrivate);
 }
 
+static void *
+intel_map_image(__DRIcontext *context, __DRIimage *image,
+int x0, int y0, int width, int height,
+unsigned int flags, int *stride, void **map_info)
+{
+   struct brw_context *brw = NULL;
+   struct brw_bo *bo = NULL;
+   void *raw_data = NULL;
+
+   if (!context || !image || !stride || !map_info || *map_info)
+  return NULL;
+
+   if (x0 < 0 || y0 < 0 || width <= 0 || height <= 0 ||
+   (x0 + width) > image->width || (y0 + height) > image->height)
+  return NULL;
+
+   if (flags & MAP_INTERNAL_MASK)
+  return NULL;
+
+   brw = context->driverPrivate;
+   bo = image->bo;
+
+   assert(brw);
+   assert(bo);
+
+   /* DRI flags and GL_MAP.*_BIT flags are the same, so just pass them on. */
+   raw_data = brw_bo_map(brw, bo, flags);
+
+   if (raw_data) {
+  GLuint pix_w = 1;
+  GLuint pix_h = 1;
+  GLint pix_bytes = 1;
+
+  *map_info = raw_data;
+  *stride = image->pitch;
+
+  _mesa_get_format_block_size(image->format, _w, _h);
+  pix_bytes = _mesa_get_format_bytes(image->format);
+
+  assert(pix_w);
+  assert(pix_h);
+  assert(pix_bytes > 0);
+
+  raw_data += ((x0 / pix_w) * pix_bytes) + (y0 / pix_h) * image->pitch;
+   }
+
+   return raw_data;
+}
+
+static void
+intel_unmap_image(__DRIcontext *context, __DRIimage *image, void *map_info)
+{
+   struct brw_bo *bo = NULL;
+
+   if (!context || !image || !map_info)
+  return;
+
+   bo = image->bo;
+
+   assert(bo);
+
+   brw_bo_unmap(bo);
+}
+
 static __DRIimage *
 intel_create_image_with_modifiers(__DRIscreen *dri_screen,
   int width, int height, int format,
@@ -1305,8 +1369,8 @@ static const __DRIimageExtension intelImageExtension = {
 .createImageFromDmaBufs = intel_create_image_from_dma_bufs,
 .blitImage  = NULL,
 .getCapabilities= NULL,
-.mapImage   = NULL,
-.unmapImage = NULL,
+.mapImage   = intel_map_image,
+.unmapImage = intel_unmap_image,
 .createImageWithModifiers   = intel_create_image_with_modifiers,
 .createImageFromDmaBufs2= intel_create_image_from_dma_bufs2,
 .queryDmaBufFormats = intel_query_dma_buf_formats,
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] i965: implement (un)mapImage

[Julien Isorce]

Ah yes you are right, my mistake. I will update the patch after some more
testing. Thx.

On 8 November 2017 at 17:21, Chris Wilson <ch...@chris-wilson.co.uk> wrote:

> Quoting Julien Isorce (2017-11-08 16:55:05)
> > v2: add early return if (flag & MAP_INTERNAL_MASK)
> >
> > Already implemented for Gallium drivers.
> >
> > Useful for gbm_bo_(un)map.
> >
> > Tested by porting wayland/weston/clients/simple-dmabuf-drm.c to GBM.
> >
> > Signed-off-by: Julien Isorce <jiso...@oblong.com>
> > ---
> >  src/mesa/drivers/dri/i965/intel_screen.c | 51
> ++--
> >  1 file changed, 49 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> > index cdc36ad..b7b0e25 100644
> > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> > @@ -755,6 +755,53 @@ intel_create_image(__DRIscreen *dri_screen,
> > loaderPrivate);
> >  }
> >
> > +static void *
> > +intel_map_image(__DRIcontext *context, __DRIimage *image,
> > +int x0, int y0, int width, int height,
> > +unsigned int flags, int *stride, void **map_info)
> > +{
> > +  struct brw_context *brw = NULL;
> > +  struct brw_bo *bo = NULL;
> > +  void *raw_data = NULL;
> > +
> > +  if (!context || !image || !stride || !map_info || *map_info)
> > + return NULL;
> > +
> > +  if (flags & MAP_INTERNAL_MASK)
> > + return NULL;
> > +
> > +  brw = context->driverPrivate;
> > +  bo = image->bo;
> > +
> > +  assert(brw);
> > +  assert(bo);
> > +
> > +  /* DRI flags and GL_MAP.*_BIT flags are the same, so just pass them
> on. */
> > +  raw_data = brw_bo_map(brw, bo, flags);
> > +
> > +  if (raw_data) {
> > +*map_info = raw_data;
> > +*stride = image->pitch;
> > +  }
> > +
> > +  return raw_data;
>
> Did you not say the returned address is to pixel0 of the (x,y)x(w,h) rect
> within the image? So raw_data + y0*image->pitch + x0*image->cpp?
> Or something more like raw_data + 
> y0/util_format_get_blockheight(image->format)
> * image->pitch +
> x0/util_format_get_blockwidth(image->format) * util_format_get_blocksize(
> image->format);
> -Chris
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: implement (un)mapImage

[Julien Isorce]

v2: add early return if (flag & MAP_INTERNAL_MASK)

Already implemented for Gallium drivers.

Useful for gbm_bo_(un)map.

Tested by porting wayland/weston/clients/simple-dmabuf-drm.c to GBM.

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/mesa/drivers/dri/i965/intel_screen.c | 51 ++--
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index cdc36ad..b7b0e25 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -755,6 +755,53 @@ intel_create_image(__DRIscreen *dri_screen,
loaderPrivate);
 }
 
+static void *
+intel_map_image(__DRIcontext *context, __DRIimage *image,
+int x0, int y0, int width, int height,
+unsigned int flags, int *stride, void **map_info)
+{
+  struct brw_context *brw = NULL;
+  struct brw_bo *bo = NULL;
+  void *raw_data = NULL;
+
+  if (!context || !image || !stride || !map_info || *map_info)
+ return NULL;
+
+  if (flags & MAP_INTERNAL_MASK)
+ return NULL;
+
+  brw = context->driverPrivate;
+  bo = image->bo;
+
+  assert(brw);
+  assert(bo);
+
+  /* DRI flags and GL_MAP.*_BIT flags are the same, so just pass them on. */
+  raw_data = brw_bo_map(brw, bo, flags);
+
+  if (raw_data) {
+*map_info = raw_data;
+*stride = image->pitch;
+  }
+
+  return raw_data;
+}
+
+static void
+intel_unmap_image(__DRIcontext *context, __DRIimage *image, void *map_info)
+{
+   struct brw_bo *bo = NULL;
+
+   if (!context || !image || !map_info)
+  return;
+
+   bo = image->bo;
+
+   assert(bo);
+
+   brw_bo_unmap(bo);
+}
+
 static __DRIimage *
 intel_create_image_with_modifiers(__DRIscreen *dri_screen,
   int width, int height, int format,
@@ -1305,8 +1352,8 @@ static const __DRIimageExtension intelImageExtension = {
 .createImageFromDmaBufs = intel_create_image_from_dma_bufs,
 .blitImage  = NULL,
 .getCapabilities= NULL,
-.mapImage   = NULL,
-.unmapImage = NULL,
+.mapImage   = intel_map_image,
+.unmapImage = intel_unmap_image,
 .createImageWithModifiers   = intel_create_image_with_modifiers,
 .createImageFromDmaBufs2= intel_create_image_from_dma_bufs2,
 .queryDmaBufFormats = intel_query_dma_buf_formats,
-- 
2.7.4

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

[Mesa-dev] [PATCH] i965: implement (un)mapImage

[Julien Isorce]

Already implemented for Gallium drivers.

Useful for gbm_bo_(un)map.

Tested by porting wayland/weston/clients/simple-dmabuf-drm.c to GBM.

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/mesa/drivers/dri/i965/intel_screen.c | 47 ++--
 1 file changed, 45 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index cdc36ad..0408a14 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -755,6 +755,49 @@ intel_create_image(__DRIscreen *dri_screen,
loaderPrivate);
 }
 
+static void *
+intel_map_image(__DRIcontext *context, __DRIimage *image,
+int x0, int y0, int width, int height,
+unsigned int flags, int *stride, void **map_info)
+{
+  struct brw_context *brw = NULL;
+  struct brw_bo *bo = NULL;
+  void *raw_data = NULL;
+
+  if (!context || !image || !stride || !map_info || *map_info)
+  return NULL;
+
+  brw = context->driverPrivate;
+  bo = image->bo;
+
+  assert(brw);
+  assert(bo);
+
+  raw_data = brw_bo_map(brw, bo, flags);
+
+  if (raw_data) {
+*map_info = raw_data;
+*stride = image->pitch;
+  }
+
+  return raw_data;
+}
+
+static void
+intel_unmap_image(__DRIcontext *context, __DRIimage *image, void *map_info)
+{
+   struct brw_bo *bo = NULL;
+
+   if (!context || !image || !map_info)
+  return;
+
+   bo = image->bo;
+
+   assert(bo);
+
+   brw_bo_unmap(bo);
+}
+
 static __DRIimage *
 intel_create_image_with_modifiers(__DRIscreen *dri_screen,
   int width, int height, int format,
@@ -1305,8 +1348,8 @@ static const __DRIimageExtension intelImageExtension = {
 .createImageFromDmaBufs = intel_create_image_from_dma_bufs,
 .blitImage  = NULL,
 .getCapabilities= NULL,
-.mapImage   = NULL,
-.unmapImage = NULL,
+.mapImage   = intel_map_image,
+.unmapImage = intel_unmap_image,
 .createImageWithModifiers   = intel_create_image_with_modifiers,
 .createImageFromDmaBufs2= intel_create_image_from_dma_bufs2,
 .queryDmaBufFormats = intel_query_dma_buf_formats,
-- 
2.7.4

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

Re: [Mesa-dev] nouveau hardware decoding and vaDeriveImage

[Julien Isorce]

Hi,

This issue is tracked here https://bugs.freedesktop.org/s
how_bug.cgi?id=98285
This is due to a limitation in libva API which only supports 1 FD per
VaSurface.
It is enough for intel-driver because NV12 is only 1 bo. But in nouveau
driver, NV12 is 2 separates bo (omitting the interlaced pb).

Note that this libva API limitation is also a problem for AMD hardware
because NV12 is also 2 non-contiguous bo (see function
'si_video_buffer_create' and 'nouveau_vp3_video_buffer_create' mesa
source). I do not know if this is HW requirement, or if using one
contiguous bo with offset handling would work. So currently there is 2
independent calls to pipe->screen->resource_create. But maybe it would also
work if the second resource would somehow has the same underlying memory
but with an offset.

The workaround for now is to convert it to RGB: (the following pipeline
works on both nvidia and amd hardware)

GST_GL_PLATFORM=egl GST_GL_API=gles2 gst-launch-1.0 filesrc
location=test.mp4 ! qtdemux ! h264parse ! vaapih264dec ! vaapipostproc !
"video/x-raw(memory:DMABuf), format=*RGBA*" ! glimagesink

In the pipeline above, vaapipostproc will receive a NV12 vaSurface as input
and will convert it to a RGBA vaSurface. And export it as 1 dmabuf FD.
Which will be imported by glimagesink by using eglCreateImage. This is not
a full zero-copy, but at least this is zero-cpu-copy, the conversion being
done on the gpu.

Cheers
Julien


On 16 August 2017 at 03:06, Ilia Mirkin  wrote:

> [adding Julien, who did the nouveau va-api integration.]
>
> On Tue, Aug 15, 2017 at 9:59 AM, Philipp Kerling 
> wrote:
> > Hi,
> >
> > I recently noticed that hardware video decoding with the nouveau driver
> > and libva does not play nicely with Wayland and decided to dig a bit.
> >
> > To use libva in conjunction with Wayland in EGL applications, you
> > usually export the surface dmabuf via vaDeriveImage &
> > vaAcquireBufferHandle and then import it in EGL via eglCreateImageKHR &
> > EGL_LINUX_DMA_BUF_EXT.
> > However, this does not work with nouveau.
> >
> > The first problem I could identify is that nouveau uses NV12 as buffer
> > format and mesa vaDeriveImage cannot handle that (see FourCCs handled
> > in vlVaDeriveImage). It seems to be easy to add though (just have to
> > set num_planes/offset etc. correctly), and I did so locally. Also,
> > nouveau always sets the interlaced flag on the buffer, which
> > vlVaDeriveImage also errors out on. Not sure why it does that and what
> > to do with that currently, I just removed the check locally.
>
> The hw decoder produces an interlaced NV12 image -- i.e. the Y plane
> is 2 images and the UV plane is 2 images, below one another. This is
> in firmware written in falcon (VP3+) or xtensa (VP2) microcode by
> NVIDIA. There is no open-source implementation, and thus would be
> tricky to change. It's possible that this firmware supports other
> output formats as well ... but we're not presently aware of it.
> Presumably the 10-bit decoding is done *somehow*.
>
> >
> > Then I hit another problem, which is that NV12 uses two planes and thus
> > has an offset into the buffer for the second plane, but nouveau cannot
> > handle offsets in eglCreateImageKHR (see nouveau_screen_bo_from_handle
> > which has a check for this).
>
> The VP2-era hardware decoder (G84..G200, minus G98) wants a single
> output buffer - you enter it in as a single base address and then an
> offset to the UV plane. It's a 32-bit offset but a 40-bit VA space.
> Later decoder generations (VP3+) have a separate address for both Y
> and UV planes. Actually looking over the VP2 logic (which I'm sad to
> say I wrote many years ago), it *might* be possible to have separate
> buffers for the final output image (in the second VP step).
>
> > Is there an easy/obvious way to add handling for the offset parameter
> > in nouveau_screen.c? This might be all that is currently breaking hwdec
> > on nouveau+Wayland, but I couldn't test it of course, so there might
> > still be other problems lurking.
>
> Well, strictly speaking this should be easy - while nouveau_bo has no
> offset, nv04_resource does - specifically things tend to use
> nv04_resource->address. I believe this offset stuff was added
> recently, and I don't know much about EGL or Wayland or ... well a lot
> of the new hotness. So e.g. in nv50_miptree_from_handle you could set
> the mt->base.address = bo->offset + whandle->offset; I wonder if the
> tiling stuff will be an issue -- the decoder can get *very* picking
> about tiling -- somehow you'll have to ensure that the images are
> allocated with proper tiling flags set -- see how nvc0_miptree_create
> calls nvc0_miptree_init_layout_video, which sets tile_mode to 0x10.
> That's not by coincidence.
>
> BTW, note that you can't use a decoder in one thread and GL commands
> in another thread. This will cause death in nouveau. Also note that
> there are known (but unfixed) artifacts when decoding 

Re: [Mesa-dev] How to write using EGLImage?

[Julien Isorce]

Hi Christian,

Thx for the suggestion. Actually I thought about dmabuf (ref project
proposal), but not about opening the EGL so using an internal mesa
function. Also eglExportDMABUFImageMESA is still tagged 'MESA'
(EGL_MESA_image_dma_buf_export). Compared to EGL_*EXT*_image_dma_buf_import
.
This need more thought so I will see later.

Also for dmabuf, 'ideally' the spec should just be improved to pass the fd
directly to OMX_UseBuffer. Some board went ahead and exposed that as a
vendor omx extension.

But so far st_omx_pipe_texture_from_eglimage_v1 mentioned in previous email
works fine (color issue is fixed now). So we will keep it like this for now.

Thx
Julien


On 13 July 2017 at 16:39, Christian König <deathsim...@vodafone.de> wrote:

> Hi Julien,
>
> sorry, totally missed that question.
>
> I think the cleanest approach would be that the OpenMAX state tracker
> dlopen()s the EGL and tries to export the eglImage into a dma_buf handle.
>
> No idea how to do this, but I'm pretty sure somebody on the mailing list
> should know the details how this can be solved.
>
> Regards,
> Christian.
>
>
> Am 13.07.2017 um 14:26 schrieb Julien Isorce:
>
> Hi,
>
> With Gurkirpal we have been blocked on this problem last week and that
> would be great to get some input.
> It is not really urgent because Gurkirpal switched to the encoder work for
> the time being.
>
> So the goal is from src/gallium/state_trackers/omx, to find a way to
> retrieve the underlying struct pipe_texture given we have an EGLDisplay and
> an EGLImage as inputs. So then we can tell the decoder to use it directly.
>
> In order to help Gurkirpal, I had another go more recently and here are 2
> solutions that seems to work but not sure if this is 100 % valid (build
> deps, safe). It builds and does not crash but some feedback would be great.
> By "it works", I just mean that I can print the pipe_texture->width0 and
> height0 and values are correct. I have not tried to use the pipe_texture,
> this will be Gurkirpal's job :) and because I am not sure this is the right
> way. Note that the 2 following functions return the same pointer.
>
>
> #include "dri_screen.h"
> #include "egl_dri2.h"
>
> static struct pipe_resource *
> st_omx_pipe_texture_from_eglimage_v1(EGLDisplay egldisplay, EGLImage
> eglimage)
> {
>   _EGLDisplay *disp = egldisplay;
>   struct dri2_egl_display *dri2_egl_dpy = disp->DriverData;
>   __DRIscreen *_dri_screen = dri2_egl_dpy->dri_screen;
>   struct dri_screen *st_dri_screen = dri_screen(_dri_screen);
>   __DRIimage *_dri_image = st_dri_screen->lookup_egl_image(st_dri_screen,
> eglimage);
>
>   return _dri_image->texture;
> }
>
> static struct pipe_resource *
> st_omx_pipe_texture_from_eglimage_v2(EGLDisplay egldisplay, EGLImage
> eglimage)
> {
>   _EGLImage *img = eglimage;
>   struct dri2_egl_image *dri2_egl_img = (struct dri2_egl_image*)img;
>__DRIimage *_dri_image = dri2_egl_img->dri_image;
>
>   return _dri_image->texture;
> }
>
> And in the Makefile.am it is required to have:
>
>  AM_CFLAGS = \
> +-I$(top_srcdir)/include \
> +   -I$(top_srcdir)/src/mapi \
> +   -I$(top_srcdir)/src/mesa \
> +   -I$(top_builddir)/src/mesa/drivers/dri/common \
> +   -I$(top_srcdir)/src/mesa/drivers/dri/common \
> +   -I$(top_srcdir)/src/egl/drivers/dri2 \
> +   -I$(top_srcdir)/src/egl/main \
> +   -I$(top_srcdir)/src/gbm/main \
> +   -I$(top_srcdir)/src/loader \
> +   -I$(top_srcdir)/src/gbm/backends/dri \
> +   -I$(top_srcdir)/src/gallium/state_trackers/dri \
> $(GALLIUM_CFLAGS) \
> +   $(LIBDRM_CFLAGS) \
> $(VISIBILITY_CFLAGS) \
> $(VL_CFLAGS) \
> $(XCB_DRI3_CFLAGS) \
>
> So I wonder if this is the right approach or this should be hook up in
> vl_screen or pipe_context somehow.
> It looks to me the v1 is safer because it calls lookup_egl_image which
> seems to go all the way down and internally calls _eglCheckResource so it
> does some validity check on the input pointers.
> The v2 looks simpler but it does not even use the egldisplay pointer.
> Also I wonder if there is a way to avoid using dri2_egl_display/dri2_egl_
> image.
>
> Thx
> Julien
>
>
> On 8 July 2017 at 22:38, Gurkirpal Singh <gurkirpal...@gmail.com> wrote:
>
>> Hi,
>>
>> As a part of my GSoC project[1] I'm working on adding OMX_UseEGLImage
>> support in gallium/st/omx.
>>
>> I have an egl_display[1] (OMX_NATIVE_WINDOWTYPE) and the EGLImage[2] in
>> the H.264 decoder component. I'm looking some sort of method to get mesa
>> pipe screen pointer (or some other pipe structure) from the egl_display 

Re: [Mesa-dev] [PATCH v2 1/4] st/omx_bellagio: Rename state tracker and option

[Julien Isorce]

No objection from me. Please just re-double check it builds properly. Thx!

On 14 August 2017 at 09:10, Christian König <deathsim...@vodafone.de> wrote:

> Am 12.08.2017 um 18:07 schrieb Gurkirpal Singh:
>
>> Changes --enable-omx option to --enable-omx-bellagio
>>
>> Signed-off-by: Gurkirpal Singh <gurkirpal...@gmail.com>
>> Reviewed-and-Tested-by: Julien Isorce <julien.iso...@gmail.com>
>>
>
> Acked-by: Christian König <christian.koe...@amd.com>
>
> Any objections that I push this one to master preliminary?
>
> Regards,
> Christian.
>
>
> ---
>>   configure.ac   |   49 +-
>>   src/gallium/Makefile.am|4 +-
>>   src/gallium/state_trackers/omx/Makefile.am |   35 -
>>   src/gallium/state_trackers/omx/Makefile.sources|   10 -
>>   src/gallium/state_trackers/omx/entrypoint.c|  152 ---
>>   src/gallium/state_trackers/omx/entrypoint.h|   48 -
>>   src/gallium/state_trackers/omx/vid_dec.c   |  665 --
>>   src/gallium/state_trackers/omx/vid_dec.h   |  148 ---
>>   src/gallium/state_trackers/omx/vid_dec_h264.c  | 1032
>> 
>>   src/gallium/state_trackers/omx/vid_dec_h265.c  | 1013
>> 
>>   src/gallium/state_trackers/omx/vid_dec_mpeg12.c|  383 --
>>   src/gallium/state_trackers/omx/vid_enc.c   | 1278
>> 
>>   src/gallium/state_trackers/omx/vid_enc.h   |   96 --
>>   .../state_trackers/omx_bellagio/Makefile.am|   35 +
>>   .../state_trackers/omx_bellagio/Makefile.sources   |   10 +
>>   .../state_trackers/omx_bellagio/entrypoint.c   |  152 +++
>>   .../state_trackers/omx_bellagio/entrypoint.h   |   48 +
>>   src/gallium/state_trackers/omx_bellagio/vid_dec.c  |  665 ++
>>   src/gallium/state_trackers/omx_bellagio/vid_dec.h  |  148 +++
>>   .../state_trackers/omx_bellagio/vid_dec_h264.c | 1032
>> 
>>   .../state_trackers/omx_bellagio/vid_dec_h265.c | 1013
>> 
>>   .../state_trackers/omx_bellagio/vid_dec_mpeg12.c   |  383 ++
>>   src/gallium/state_trackers/omx_bellagio/vid_enc.c  | 1278
>> 
>>   src/gallium/state_trackers/omx_bellagio/vid_enc.h  |   96 ++
>>   src/gallium/targets/omx-bellagio/Makefile.am   |   75 ++
>>   src/gallium/targets/omx-bellagio/omx.sym   |   11 +
>>   src/gallium/targets/omx-bellagio/target.c  |2 +
>>   src/gallium/targets/omx/Makefile.am|   75 --
>>   src/gallium/targets/omx/omx.sym|   11 -
>>   src/gallium/targets/omx/target.c   |2 -
>>   30 files changed, 4977 insertions(+), 4972 deletions(-)
>>   delete mode 100644 src/gallium/state_trackers/omx/Makefile.am
>>   delete mode 100644 src/gallium/state_trackers/omx/Makefile.sources
>>   delete mode 100644 src/gallium/state_trackers/omx/entrypoint.c
>>   delete mode 100644 src/gallium/state_trackers/omx/entrypoint.h
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_dec.c
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_dec.h
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_dec_h264.c
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_dec_h265.c
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_dec_mpeg12.c
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_enc.c
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_enc.h
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/Makefile.am
>>   create mode 100644 src/gallium/state_trackers/omx
>> _bellagio/Makefile.sources
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/entrypoint.c
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/entrypoint.h
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec.c
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec.h
>>   create mode 100644 src/gallium/state_trackers/omx
>> _bellagio/vid_dec_h264.c
>>   create mode 100644 src/gallium/state_trackers/omx
>> _bellagio/vid_dec_h265.c
>>   create mode 100644 src/gallium/state_trackers/omx
>> _bellagio/vid_dec_mpeg12.c
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_enc.c
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_enc.h
>>   create mode 100644 src/gallium/targets/omx-bellagio/Makefile.am
>>   create mode 100644 src/gallium/targets/omx-bellagio/omx.sym
>>   create mode 100644 src/gal

Re: [Mesa-dev] [PATCH v2 2/4] st/omx_tizonia: Add --enable-omx-tizonia flag and build files

[Julien Isorce]

Hi Leo,

>It would be better if you can extract the common code between bellagio and
tizonia to avoid the duplication.

This is something Gurkirpal and me discussed, like having
state_trackers/omx/common, state_trackers/omx/bellagio,
state_trackers/omx/tizonia. To anticipate that Gurkirpal sent an email
https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg153562.html
during the Community Bonding period in May (a few weeks from the date
(early May) students are officially accepted to the date (end May) where
student actually starts working)

The problem with the directory layout above is that it would look like it
will be built together in the same shared library. This is not good because
it is suppose to export OMX_ComponentInit for each target. Of course this
would still be possible to have 2 shared libs but I believe in
state_trackers dir, all sub dir are for one target. Also we were afraid
that there would be other limitations so we decided to go for a separate
directory.
And since there were no objections in Gurkirpal's mail above we went this
way.

Now if I look into state_trackers/omx_tizonia, in fact the common code with
state_trackers/omx_bellagio does not have anything to do with omx. For
example "slice_header". Maybe it can be moved to gallium/auxiliary/vl/ like
it is done already for vl_rbsp_init. Same for omx_get_screen.

So I suggest this 'factorization' to be not a blocker for merging
state_trackers/omx_tizonia into usptream. But later on we can move
gradually bits from state_trackers/omx_bellagio to gallium/auxiliary. And
then make state_trackers/omx_tizonia use it as well.
This way you will only bother about maintaining state_trackers/omx_bellagio
the time being. This also allows to not slowly get its work lost.

Of course we would have done differently if we knew advance. But as today
Gurkirpal won't have enough time to do this factorization/move as the
project ends in 1 week. Having all of this merged in upstream is not
mandatory to succeed the project but Gurkirpal will need some rest after
these 3 months of hard work. And who knows what happens after, whether he
will still be around after sometimes or not. And this is entirely up to him.

So again I suggest this factorization/move not to be a blocker for the
reasons above. What do you think?

Thx
Julien

On 13 August 2017 at 16:52, Gurkirpal Singh <gurkirpal...@gmail.com> wrote:

>
>
> On Sun, Aug 13, 2017 at 8:47 AM, Leo Liu <leo@amd.com> wrote:
>
>> Where is the patch 1?
>
> Sorry for the patches got messed up somehow while sending, I could only
> see two patches on mail-archive but three on patchwork.
> Tried two times and same result.
> About the first one I got a mail saying that it was too large has been put
> aside for mod approval.
> The changes I made were to just rename the st/omx directory to
> st/omx_bellagio (the reason it became large)
> and renaming bits in the configure.ac and Makefiles.
>
>>
>>
>>
>> On 08/12/2017 12:07 PM, Gurkirpal Singh wrote:
>>
>>> Coexist with --enable-omx so they can be built independently
>>> Detect tizonia package config file
>>> Generate libomxtiz_mesa.so and install it to libtizcore.pc::pluginsdir
>>> Only compile empty source (target.c) for now.
>>>
>>> v2: Show error message when --enable-omx is used (Christian)
>>>  Use single PKG_CHECK_MODULES for omx_tizonia checks (Emil)
>>>  Use spaces instead of tabs
>>>  Add checks around omx-tizonia
>>>
>>> GSoC Project link: https://summerofcode.withgoogl
>>> e.com/projects/#4737166321123328
>>>
>>> Signed-off-by: Gurkirpal Singh <gurkirpal...@gmail.com>
>>> Reviewed-and-Tested-by: Julien Isorce <julien.iso...@gmail.com>
>>> ---
>>>   configure.ac| 40 ++-
>>>   src/gallium/Makefile.am |  4 ++
>>>   src/gallium/targets/omx-tizonia/Makefile.am | 77
>>> +
>>>   src/gallium/targets/omx-tizonia/omx.sym | 11 +
>>>   src/gallium/targets/omx-tizonia/target.c|  2 +
>>>   5 files changed, 132 insertions(+), 2 deletions(-)
>>>   create mode 100644 src/gallium/targets/omx-tizonia/Makefile.am
>>>   create mode 100644 src/gallium/targets/omx-tizonia/omx.sym
>>>   create mode 100644 src/gallium/targets/omx-tizonia/target.c
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 38af96a..5669695 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -85,6 +85,7 @@ dnl Versions for external dependencies
>>>   DRI2PROTO_REQUIRED=2.8
>>>   GLPROTO_REQUIRED=1.4.14
>>>   LIBOMXIL_BELLAGIO_REQUIRED=0.0
>

Re: [Mesa-dev] [PATCH] st/va: change frame_idx from array to hash table

[Julien Isorce]

Boyuan, gentle ping ?

On 26 July 2017 at 19:36, Christian König <deathsim...@vodafone.de> wrote:

> So that means Reviewed-and-tested-by: Zhang, Boyuan <boyuan.zh...@amd.com
> >?
>
> Christian.
>
>
> Am 26.07.2017 um 20:29 schrieb Zhang, Boyuan:
>
>> The code looks good to me. I also did a few local vaapi-enc tests and
>> confirmed that patch works fine.
>>
>> Regards,
>> Boyuan
>>
>> -Original Message-
>> From: Liu, Leo
>> Sent: July-26-17 12:01 PM
>> To: Andy Furniss; Koenig, Christian; Julien Isorce;
>> mesa-dev@lists.freedesktop.org; Zhang, Boyuan
>> Subject: Re: [Mesa-dev] [PATCH] st/va: change frame_idx from array to
>> hash table
>>
>>
>>
>> On 07/25/2017 06:04 PM, Andy Furniss wrote:
>>
>>> Christian König wrote:
>>>
>>> Leo and Boyuan can you take a quick look as well? On first glance
>>>> looks totally sane to me.
>>>>
>>> This reminds me .
>>>
>>> I don't know what's special about my setup, but I haven't been able to
>>> use gst + vce properly since March.
>>>
>>> As I said at the time -
>>>
>>> https://lists.freedesktop.org/archives/mesa-dev/2017-March/148216.html
>>>
>>> I did ping as well, but never quite got round to doing a bug.
>>>
>>> I guess devs who tests vce with gstreamer don't see this?
>>>
>> Personally, haven't been working on encode too much recently. esp for
>> VA-API encode.
>>
>> Cheers,
>> Leo
>>
>>
>> ___
>> 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] st/va: change frame_idx from array to hash table

[Julien Isorce]

The picture_is was assumed to be a frame number so in 0-31.
But the vaapi client gstreamer-vaapi uses the surfaces handles
as identifier which are unsigned int.

This bug can happen when using a lot of vaapi surfaces within
the same process. Indeed Mesa/st/va increments a counter for the
surface ID: mesa/util/u_handle_table.c::handle_table_add which
starts from 0 and incremented by 1 at each call.
So when creating above 32 surfaces it was a problem.

The following bug contains a test that reproduces the problem
by running a couple of vaapih264enc in the same process. The above
also explains why there was no pb when running them in separated
processes.

https://bugzilla.gnome.org/show_bug.cgi?id=785085
---
 src/gallium/include/pipe/p_video_state.h   |  4 +++-
 src/gallium/state_trackers/va/context.c|  9 +++--
 src/gallium/state_trackers/va/picture.c| 11 ---
 src/gallium/state_trackers/va/va_private.h | 13 +
 4 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/src/gallium/include/pipe/p_video_state.h 
b/src/gallium/include/pipe/p_video_state.h
index 39b3905..53f9ab3 100644
--- a/src/gallium/include/pipe/p_video_state.h
+++ b/src/gallium/include/pipe/p_video_state.h
@@ -32,6 +32,7 @@
 #include "pipe/p_format.h"
 #include "pipe/p_state.h"
 #include "pipe/p_screen.h"
+#include "util/u_hash_table.h"
 #include "util/u_inlines.h"
 
 #ifdef __cplusplus
@@ -407,7 +408,8 @@ struct pipe_h264_enc_picture_desc
bool not_referenced;
bool is_idr;
bool enable_vui;
-   unsigned int frame_idx[32];
+   struct util_hash_table *frame_idx;
+
 };
 
 struct pipe_h265_sps
diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 186f5066..f2cb37a 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -280,8 +280,10 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
 
context->desc.base.profile = config->profile;
context->desc.base.entry_point = config->entrypoint;
-   if (config->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE)
+   if (config->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
   context->desc.h264enc.rate_ctrl.rate_ctrl_method = config->rc;
+  context->desc.h264enc.frame_idx = util_hash_table_create(handle_hash, 
handle_compare);
+   }
 
mtx_lock(>mutex);
*context_id = handle_table_add(drv->htab, context);
@@ -308,7 +310,10 @@ vlVaDestroyContext(VADriverContextP ctx, VAContextID 
context_id)
}
 
if (context->decoder) {
-  if (context->desc.base.entry_point != PIPE_VIDEO_ENTRYPOINT_ENCODE) {
+  if (context->desc.base.entry_point == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
+ if (context->desc.h264enc.frame_idx)
+util_hash_table_destroy (context->desc.h264enc.frame_idx);
+  } else {
  if (u_reduce_video_profile(context->decoder->profile) ==
PIPE_VIDEO_FORMAT_MPEG4_AVC) {
 FREE(context->desc.h264.pps->sps);
diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 20fe750..338e090 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -427,7 +427,10 @@ handleVAEncPictureParameterBufferType(vlVaDriver *drv, 
vlVaContext *context, vlV
 PIPE_USAGE_STREAM, 
coded_buf->size);
context->coded_buf = coded_buf;
 
-   context->desc.h264enc.frame_idx[h264->CurrPic.picture_id] = h264->frame_num;
+   util_hash_table_set(context->desc.h264enc.frame_idx,
+  UINT_TO_PTR(h264->CurrPic.picture_id),
+  UINT_TO_PTR(h264->frame_num));
+
if (context->desc.h264enc.is_idr)
   context->desc.h264enc.picture_type = PIPE_H264_ENC_PICTURE_TYPE_IDR;
else
@@ -455,11 +458,13 @@ handleVAEncSliceParameterBufferType(vlVaDriver *drv, 
vlVaContext *context, vlVaB
for (int i = 0; i < 32; i++) {
   if (h264->RefPicList0[i].picture_id != VA_INVALID_ID) {
  if (context->desc.h264enc.ref_idx_l0 == VA_INVALID_ID)
-context->desc.h264enc.ref_idx_l0 = 
context->desc.h264enc.frame_idx[h264->RefPicList0[i].picture_id];
+context->desc.h264enc.ref_idx_l0 = 
PTR_TO_UINT(util_hash_table_get(context->desc.h264enc.frame_idx,
+  
UINT_TO_PTR(h264->RefPicList0[i].picture_id)));
   }
   if (h264->RefPicList1[i].picture_id != VA_INVALID_ID && h264->slice_type 
== 1) {
  if (context->desc.h264enc.ref_idx_l1 == VA_INVALID_ID)
-context->desc.h264enc.ref_idx_l1 = 
context->desc.h264enc.frame_idx[h264->RefPicList1[i].picture_id];
+context->desc.h264enc.ref_idx_l1 = 
PTR_TO_UINT(util_hash_table_get(context->desc.h264enc.frame_idx,
+  
UINT_TO_PTR(h264->RefPicList1[i].picture_id)));
   }
}
 
diff --git 

Re: [Mesa-dev] How to write using EGLImage?

[Julien Isorce]

Hi,

With Gurkirpal we have been blocked on this problem last week and that
would be great to get some input.
It is not really urgent because Gurkirpal switched to the encoder work for
the time being.

So the goal is from src/gallium/state_trackers/omx, to find a way to
retrieve the underlying struct pipe_texture given we have an EGLDisplay and
an EGLImage as inputs. So then we can tell the decoder to use it directly.

In order to help Gurkirpal, I had another go more recently and here are 2
solutions that seems to work but not sure if this is 100 % valid (build
deps, safe). It builds and does not crash but some feedback would be great.
By "it works", I just mean that I can print the pipe_texture->width0 and
height0 and values are correct. I have not tried to use the pipe_texture,
this will be Gurkirpal's job :) and because I am not sure this is the right
way. Note that the 2 following functions return the same pointer.


#include "dri_screen.h"
#include "egl_dri2.h"

static struct pipe_resource *
st_omx_pipe_texture_from_eglimage_v1(EGLDisplay egldisplay, EGLImage
eglimage)
{
  _EGLDisplay *disp = egldisplay;
  struct dri2_egl_display *dri2_egl_dpy = disp->DriverData;
  __DRIscreen *_dri_screen = dri2_egl_dpy->dri_screen;
  struct dri_screen *st_dri_screen = dri_screen(_dri_screen);
  __DRIimage *_dri_image = st_dri_screen->lookup_egl_image(st_dri_screen,
eglimage);

  return _dri_image->texture;
}

static struct pipe_resource *
st_omx_pipe_texture_from_eglimage_v2(EGLDisplay egldisplay, EGLImage
eglimage)
{
  _EGLImage *img = eglimage;
  struct dri2_egl_image *dri2_egl_img = (struct dri2_egl_image*)img;
   __DRIimage *_dri_image = dri2_egl_img->dri_image;

  return _dri_image->texture;
}

And in the Makefile.am it is required to have:

 AM_CFLAGS = \
+-I$(top_srcdir)/include \
+   -I$(top_srcdir)/src/mapi \
+   -I$(top_srcdir)/src/mesa \
+   -I$(top_builddir)/src/mesa/drivers/dri/common \
+   -I$(top_srcdir)/src/mesa/drivers/dri/common \
+   -I$(top_srcdir)/src/egl/drivers/dri2 \
+   -I$(top_srcdir)/src/egl/main \
+   -I$(top_srcdir)/src/gbm/main \
+   -I$(top_srcdir)/src/loader \
+   -I$(top_srcdir)/src/gbm/backends/dri \
+   -I$(top_srcdir)/src/gallium/state_trackers/dri \
$(GALLIUM_CFLAGS) \
+   $(LIBDRM_CFLAGS) \
$(VISIBILITY_CFLAGS) \
$(VL_CFLAGS) \
$(XCB_DRI3_CFLAGS) \

So I wonder if this is the right approach or this should be hook up in
vl_screen or pipe_context somehow.
It looks to me the v1 is safer because it calls lookup_egl_image which
seems to go all the way down and internally calls _eglCheckResource so it
does some validity check on the input pointers.
The v2 looks simpler but it does not even use the egldisplay pointer.
Also I wonder if there is a way to avoid using
dri2_egl_display/dri2_egl_image.

Thx
Julien


On 8 July 2017 at 22:38, Gurkirpal Singh  wrote:

> Hi,
>
> As a part of my GSoC project[1] I'm working on adding OMX_UseEGLImage
> support in gallium/st/omx.
>
> I have an egl_display[1] (OMX_NATIVE_WINDOWTYPE) and the EGLImage[2] in
> the H.264 decoder component. I'm looking some sort of method to get mesa
> pipe screen pointer (or some other pipe structure) from the egl_display and
> from which I can get struct pipe_surface and eglimage pointer/id.
>
> [1] https://summerofcode.withgoogle.com/projects/#4737166321123328
> [2] https://github.com/gpalsingh/mesa/blob/gsoc-dev/
> src/gallium/state_trackers/omx_tizonia/h264dprc.c#L205
>
> Thanks,
> Gurkirpal
>
> ___
> 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 v2] gallium/hud: set the dump file streams to line buffered

[Julien Isorce]

Reviewed-by: Julien Isorce <jiso...@oblong.com>

On 5 April 2017 at 20:03, Edmondo Tommasina <edmondo.tommas...@gmail.com>
wrote:

> Flush the HUD value streams to the dump files after every newline.
>
> v2: check that fopen succeeded  (Julien)
>
> Tested-by: Julien Isorce <jiso...@oblong.com>
> ---
>  src/gallium/auxiliary/hud/hud_context.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/auxiliary/hud/hud_context.c
> b/src/gallium/auxiliary/hud/hud_context.c
> index 29ef9eee31..f492c81fe6 100644
> --- a/src/gallium/auxiliary/hud/hud_context.c
> +++ b/src/gallium/auxiliary/hud/hud_context.c
> @@ -972,6 +972,8 @@ hud_graph_set_dump_file(struct hud_graph *gr)
>   strcat(dump_file, "/");
>   strcat_without_spaces(dump_file, gr->name);
>   gr->fd = fopen(dump_file, "w+");
> + if (gr->fd)
> +setvbuf(gr->fd, NULL, _IOLBF, 0);
>   free(dump_file);
>}
> }
> --
> 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] gallium/hud: set the dump file streams to line buffered

[Julien Isorce]

I confirm it works, awesome!  Thx!
Should you check that fopen succeeded  ? because I think setvbuf would
crash otherwise.
That's said:
Tested-by: Julien Isorce <jiso...@oblong.com>

On 4 April 2017 at 21:52, Edmondo Tommasina <edmondo.tommas...@gmail.com>
wrote:

> Flush the HUD value streams to the dump files after every newline.
> ---
>  src/gallium/auxiliary/hud/hud_context.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/auxiliary/hud/hud_context.c
> b/src/gallium/auxiliary/hud/hud_context.c
> index 29ef9eee31..633e3650cc 100644
> --- a/src/gallium/auxiliary/hud/hud_context.c
> +++ b/src/gallium/auxiliary/hud/hud_context.c
> @@ -972,6 +972,7 @@ hud_graph_set_dump_file(struct hud_graph *gr)
>   strcat(dump_file, "/");
>   strcat_without_spaces(dump_file, gr->name);
>   gr->fd = fopen(dump_file, "w+");
> + setvbuf(gr->fd, NULL, _IOLBF, 0);
>   free(dump_file);
>}
> }
> --
> 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] Empty files when dumping hud values selected with GALLIUM_HUD

[Julien Isorce]

Thx Edmondo, let me know the result! Also is the pane on screen supposed to
work with llvmpipe driver because I cannot see it with GALLIUM_HUD=fps
LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=llvmpipe glxgears

Cheers.
Julien

On 4 April 2017 at 11:29, Edmondo Tommasina <edmondo.tommas...@gmail.com>
wrote:

>
>
> On Apr 4, 2017 11:26, "Julien Isorce" <julien.iso...@gmail.com> wrote:
>
> Hi,
>
> I noticed that GALLIUM_HUD does not write hud values into files properly.
>
> The destination files look empty at least for 5 min and then are filed in
> with some burst. I wonder if it could be a problem with the
> GALLIUM_HUD_PERIOD which would be wrong when writing values into files. Or
> write is not committed or not flushed.
>
> I can see these values properly updated in the pane on screen but
> destination files are empty for some minutes.
>
> This is happening with various recent version of mesa + radeonsi. With
> older mesa like 12.0.6, it is even worst, the destinations are not created
> at all.
>
> Does it happen for anybody else before I fill in a bug ?
> TEST:  GALLIUM_HUD=fps+VRAM-usage+temperature GALLIUM_HUD_DUMP_DIR=/tmp
> glxgears
>
> -
> Julien
>
>
>
> Hi Julien
>
> I think this could be a buffering issue.
> The values are printed with fprintf, I'm using default
> buffer sizes and never explicitly flushing.
> This evening I'll try to make it more reliable.
>
> Btw. the dump functionality is not implemented in Mesa 12.
>
> Thanks
> edmondo
>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Empty files when dumping hud values selected with GALLIUM_HUD

[Julien Isorce]

Hi,

I noticed that GALLIUM_HUD does not write hud values into files properly.

The destination files look empty at least for 5 min and then are filed in
with some burst. I wonder if it could be a problem with the
GALLIUM_HUD_PERIOD which would be wrong when writing values into files. Or
write is not committed or not flushed.

I can see these values properly updated in the pane on screen but
destination files are empty for some minutes.

This is happening with various recent version of mesa + radeonsi. With
older mesa like 12.0.6, it is even worst, the destinations are not created
at all.

Does it happen for anybody else before I fill in a bug ?
TEST:  GALLIUM_HUD=fps+VRAM-usage+temperature GALLIUM_HUD_DUMP_DIR=/tmp
glxgears

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

Re: [Mesa-dev] [PATCH v2 2/4] si_compute: check NULL return from u_upload_alloc

[Julien Isorce]

Oops it should be just "return;" here.

On 28 March 2017 at 17:52, Julien Isorce <julien.iso...@gmail.com> wrote:

> -   if (program->input_size || program->ir_type ==
> PIPE_SHADER_IR_NATIVE)
> -   si_upload_compute_input(sctx, code_object, info);
> +   if ((program->input_size ||
> +program->ir_type == PIPE_SHADER_IR_NATIVE) &&
> +unlikely(!si_upload_compute_input(sctx, code_object, info)))
> {
> +   return false;
> +   }
>
> is the indentation ok ?
>
>
> On 27 March 2017 at 16:39, Marek Olšák <mar...@gmail.com> wrote:
>
>> "&&" at the end of the previous line please.
>>
>> Reviewed-by: Marek Olšák <marek.ol...@amd.com>
>>
>> Marek
>>
>> On Mon, Mar 27, 2017 at 3:46 PM, Julien Isorce <julien.iso...@gmail.com>
>> wrote:
>> > Signed-off-by: Julien Isorce <jiso...@oblong.com>
>> > ---
>> >  src/gallium/drivers/radeonsi/si_compute.c | 13 ++---
>> >  1 file changed, 10 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
>> b/src/gallium/drivers/radeonsi/si_compute.c
>> > index 46476b6..a38138f 100644
>> > --- a/src/gallium/drivers/radeonsi/si_compute.c
>> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
>> > @@ -579,7 +579,7 @@ static void si_setup_user_sgprs_co_v2(struct
>> si_context *sctx,
>> > }
>> >  }
>> >
>> > -static void si_upload_compute_input(struct si_context *sctx,
>> > +static bool si_upload_compute_input(struct si_context *sctx,
>> > const amd_kernel_code_t
>> *code_object,
>> > const struct pipe_grid_info *info)
>> >  {
>> > @@ -602,6 +602,9 @@ static void si_upload_compute_input(struct
>> si_context *sctx,
>> >_args_offset,
>> >(struct pipe_resource**)_buffer,
>> _args_ptr);
>> >
>> > +   if (unlikely(!kernel_args_ptr))
>> > +   return false;
>> > +
>> > kernel_args = (uint32_t*)kernel_args_ptr;
>> > kernel_args_va = input_buffer->gpu_address + kernel_args_offset;
>> >
>> > @@ -636,6 +639,8 @@ static void si_upload_compute_input(struct
>> si_context *sctx,
>> > }
>> >
>> > r600_resource_reference(_buffer, NULL);
>> > +
>> > +   return true;
>> >  }
>> >
>> >  static void si_setup_tgsi_grid(struct si_context *sctx,
>> > @@ -790,8 +795,10 @@ static void si_launch_grid(
>> > si_set_atom_dirty(sctx, sctx->atoms.s.render_cond,
>> false);
>> > }
>> >
>> > -   if (program->input_size || program->ir_type ==
>> PIPE_SHADER_IR_NATIVE)
>> > -   si_upload_compute_input(sctx, code_object, info);
>> > +   if ((program->input_size || program->ir_type ==
>> PIPE_SHADER_IR_NATIVE)
>> > +&& unlikely(!si_upload_compute_input(sctx, code_object,
>> info))) {
>> > +   return false;
>> > +   }
>> >
>> > /* Global buffers */
>> > for (i = 0; i < MAX_GLOBAL_BUFFERS; i++) {
>> > --
>> > 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 v2 2/4] si_compute: check NULL return from u_upload_alloc

[Julien Isorce]

-   if (program->input_size || program->ir_type ==
PIPE_SHADER_IR_NATIVE)
-   si_upload_compute_input(sctx, code_object, info);
+   if ((program->input_size ||
+program->ir_type == PIPE_SHADER_IR_NATIVE) &&
+unlikely(!si_upload_compute_input(sctx, code_object, info))) {
+   return false;
+   }

is the indentation ok ?


On 27 March 2017 at 16:39, Marek Olšák <mar...@gmail.com> wrote:

> "&&" at the end of the previous line please.
>
> Reviewed-by: Marek Olšák <marek.ol...@amd.com>
>
> Marek
>
> On Mon, Mar 27, 2017 at 3:46 PM, Julien Isorce <julien.iso...@gmail.com>
> wrote:
> > Signed-off-by: Julien Isorce <jiso...@oblong.com>
> > ---
> >  src/gallium/drivers/radeonsi/si_compute.c | 13 ++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> > index 46476b6..a38138f 100644
> > --- a/src/gallium/drivers/radeonsi/si_compute.c
> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
> > @@ -579,7 +579,7 @@ static void si_setup_user_sgprs_co_v2(struct
> si_context *sctx,
> > }
> >  }
> >
> > -static void si_upload_compute_input(struct si_context *sctx,
> > +static bool si_upload_compute_input(struct si_context *sctx,
> > const amd_kernel_code_t *code_object,
> > const struct pipe_grid_info *info)
> >  {
> > @@ -602,6 +602,9 @@ static void si_upload_compute_input(struct
> si_context *sctx,
> >_args_offset,
> >(struct pipe_resource**)_buffer,
> _args_ptr);
> >
> > +   if (unlikely(!kernel_args_ptr))
> > +   return false;
> > +
> > kernel_args = (uint32_t*)kernel_args_ptr;
> > kernel_args_va = input_buffer->gpu_address + kernel_args_offset;
> >
> > @@ -636,6 +639,8 @@ static void si_upload_compute_input(struct
> si_context *sctx,
> > }
> >
> > r600_resource_reference(_buffer, NULL);
> > +
> > +   return true;
> >  }
> >
> >  static void si_setup_tgsi_grid(struct si_context *sctx,
> > @@ -790,8 +795,10 @@ static void si_launch_grid(
> > si_set_atom_dirty(sctx, sctx->atoms.s.render_cond,
> false);
> > }
> >
> > -   if (program->input_size || program->ir_type ==
> PIPE_SHADER_IR_NATIVE)
> > -   si_upload_compute_input(sctx, code_object, info);
> > +   if ((program->input_size || program->ir_type ==
> PIPE_SHADER_IR_NATIVE)
> > +&& unlikely(!si_upload_compute_input(sctx, code_object,
> info))) {
> > +   return false;
> > +   }
> >
> > /* Global buffers */
> > for (i = 0; i < MAX_GLOBAL_BUFFERS; i++) {
> > --
> > 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 3/4] st_cb_bitmap: check NULL return from u_upload_alloc

[Julien Isorce]

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/mesa/state_tracker/st_cb_bitmap.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/mesa/state_tracker/st_cb_bitmap.c 
b/src/mesa/state_tracker/st_cb_bitmap.c
index b2e2608..cf820e4 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -720,6 +720,11 @@ st_DrawAtlasBitmaps(struct gl_context *ctx,
u_upload_alloc(pipe->stream_uploader, 0, num_vert_bytes, 4,
   _offset, , (void **) );
 
+   if (unlikely(!verts)) {
+  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glCallLists(bitmap text)");
+  goto out;
+   }
+
/* build quads vertex data */
for (i = 0; i < count; i++) {
   const GLfloat epsilon = 0.0001F;
@@ -797,6 +802,7 @@ st_DrawAtlasBitmaps(struct gl_context *ctx,
 
cso_draw_arrays(st->cso_context, PIPE_PRIM_QUADS, 0, num_verts);
 
+out:
restore_render_state(ctx);
 
pipe_resource_reference(, NULL);
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 1/4] r600_state_common: check NULL return from u_upload_alloc

[Julien Isorce]

Like done in si_state_draw.c::si_draw_vbo

u_upload_alloc can fail, i.e. set output param *ptr to NULL, for 2 reasons:
alloc fails or map fails. For both there is already a fprintf/stderr in
radeon_create_bo and radeon_bo_do_map.

In src/gallium/drivers/ it is a common usage to just avoid to crash by doing
a silent check. But defer fprintf where the error comes from, libdrm calls.

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/drivers/r600/r600_state_common.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c
index 6f8279f..cedeb74 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -1746,6 +1746,10 @@ static void r600_draw_vbo(struct pipe_context *ctx, 
const struct pipe_draw_info
 
u_upload_alloc(ctx->stream_uploader, start, count * 2,
256, _offset, _buffer, );
+   if (unlikely(!ptr)) {
+   pipe_resource_reference(, NULL);
+   return;
+   }
 
util_shorten_ubyte_elts_to_userptr(
>b.b, , 0, 0, 
ib.offset + start, count, ptr);
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 2/4] si_compute: check NULL return from u_upload_alloc

[Julien Isorce]

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/drivers/radeonsi/si_compute.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index 46476b6..a38138f 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -579,7 +579,7 @@ static void si_setup_user_sgprs_co_v2(struct si_context 
*sctx,
}
 }
 
-static void si_upload_compute_input(struct si_context *sctx,
+static bool si_upload_compute_input(struct si_context *sctx,
const amd_kernel_code_t *code_object,
const struct pipe_grid_info *info)
 {
@@ -602,6 +602,9 @@ static void si_upload_compute_input(struct si_context *sctx,
   _args_offset,
   (struct pipe_resource**)_buffer, _args_ptr);
 
+   if (unlikely(!kernel_args_ptr))
+   return false;
+
kernel_args = (uint32_t*)kernel_args_ptr;
kernel_args_va = input_buffer->gpu_address + kernel_args_offset;
 
@@ -636,6 +639,8 @@ static void si_upload_compute_input(struct si_context *sctx,
}
 
r600_resource_reference(_buffer, NULL);
+
+   return true;
 }
 
 static void si_setup_tgsi_grid(struct si_context *sctx,
@@ -790,8 +795,10 @@ static void si_launch_grid(
si_set_atom_dirty(sctx, sctx->atoms.s.render_cond, false);
}
 
-   if (program->input_size || program->ir_type == PIPE_SHADER_IR_NATIVE)
-   si_upload_compute_input(sctx, code_object, info);
+   if ((program->input_size || program->ir_type == PIPE_SHADER_IR_NATIVE)
+&& unlikely(!si_upload_compute_input(sctx, code_object, info))) {
+   return false;
+   }
 
/* Global buffers */
for (i = 0; i < MAX_GLOBAL_BUFFERS; i++) {
-- 
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/4] r600_state_common: check NULL return from u_upload_alloc

[Julien Isorce]

1: Ack, thx.
2: u_upload_alloc can fail, i.e. set output param *ptr to NULL, for 2
reasons: alloc fails or map fails. For both there are already a
fprintf/stderr, i.e., in radeon_create_bo and radeon_bo_do_map .
It looks to me that in src/gallium/drivers/ it is a common usage to just
avoid to crash by doing a silent check. But it defers the fprintf to where
the error comes from, i.e. libdrm calls.

Also I think that if drmCommandWriteRead returns -ENOMEM it should be
translated to _mesa_error_no_memory(__func__); at some point. But it seems
it is not possible to use _mesa_error_no_memory in mesa/src/gallium/winsys
(though it is possible from gallium/state_trackers/glx). And it would
require to be in the gl context's thread to call it.

Regards
Julien


On 24 March 2017 at 11:19, Nicolai Hähnle <nhaeh...@gmail.com> wrote:

> I generally like the patches in the series, thanks for that. Two points
> though:
>
> 1. The order of patches in series is usually general code before driver
> code, i.e. the st/cb_bitmap should come first.
>
> 2. I don't like having silent errors, as that could be confusing. In
> places where the error isn't propagated to the application (as it really
> should be...), I think we should have an fprintf to stderr.
>
> Cheers,
> Nicolai
>
> On 24.03.2017 12:08, Julien Isorce wrote:
>
>> Like done in si_state_draw.c::si_draw_vbo
>>
>> Signed-off-by: Julien Isorce <jiso...@oblong.com>
>> ---
>>  src/gallium/drivers/r600/r600_state_common.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/src/gallium/drivers/r600/r600_state_common.c
>> b/src/gallium/drivers/r600/r600_state_common.c
>> index 6f8279f..cedeb74 100644
>> --- a/src/gallium/drivers/r600/r600_state_common.c
>> +++ b/src/gallium/drivers/r600/r600_state_common.c
>> @@ -1746,6 +1746,10 @@ static void r600_draw_vbo(struct pipe_context
>> *ctx, const struct pipe_draw_info
>>
>> u_upload_alloc(ctx->stream_uploader, start,
>> count * 2,
>> 256, _offset, _buffer,
>> );
>> +   if (unlikely(!ptr)) {
>> +   pipe_resource_reference(,
>> NULL);
>> +   return;
>> +   }
>>
>> util_shorten_ubyte_elts_to_userptr(
>> >b.b, , 0, 0,
>> ib.offset + start, count, ptr);
>>
>>
>
> --
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] si_compute: check NULL return from u_upload_alloc

[Julien Isorce]

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/drivers/radeonsi/si_compute.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index 19a9189..e3ccc55 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -602,6 +602,9 @@ static void si_upload_compute_input(struct si_context *sctx,
   _args_offset,
   (struct pipe_resource**)_buffer, _args_ptr);
 
+   if (unlikely(!kernel_args_ptr))
+   return;
+
kernel_args = (uint32_t*)kernel_args_ptr;
kernel_args_va = input_buffer->gpu_address + kernel_args_offset;
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/4] st_cb_bitmap: check NULL return from u_upload_alloc

[Julien Isorce]

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/mesa/state_tracker/st_cb_bitmap.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/state_tracker/st_cb_bitmap.c 
b/src/mesa/state_tracker/st_cb_bitmap.c
index b2e2608..3ce190e 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -720,6 +720,11 @@ st_DrawAtlasBitmaps(struct gl_context *ctx,
u_upload_alloc(pipe->stream_uploader, 0, num_vert_bytes, 4,
   _offset, , (void **) );
 
+   if (unlikely(!verts)) {
+  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glCallLists(bitmap text)");
+  return;
+   }
+
/* build quads vertex data */
for (i = 0; i < count; i++) {
   const GLfloat epsilon = 0.0001F;
-- 
2.7.4

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

[Mesa-dev] [PATCH 4/4] r600_state: check NULL return from r600_aligned_buffer_create

[Julien Isorce]

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/drivers/r600/r600_state.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_state.c 
b/src/gallium/drivers/r600/r600_state.c
index 6139bd2..9ca113a 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -983,6 +983,11 @@ static void r600_init_color_surface(struct r600_context 
*rctx,
   PIPE_USAGE_DEFAULT,
   cmask.size, 
cmask.alignment);
 
+   if (unlikely(!rctx->dummy_cmask)) {
+   surf->color_initialized = false;
+   return;
+   }
+
/* Set the contents to 0xCC. */
ptr = pipe_buffer_map(>b.b, 
>dummy_cmask->b.b, PIPE_TRANSFER_WRITE, );
memset(ptr, 0xCC, cmask.size);
@@ -999,6 +1004,11 @@ static void r600_init_color_surface(struct r600_context 
*rctx,
r600_aligned_buffer_create(>b.b, 0,
   PIPE_USAGE_DEFAULT,
   fmask.size, 
fmask.alignment);
+
+   if (unlikely(!rctx->dummy_fmask)) {
+   surf->color_initialized = false;
+   return;
+   }
}
r600_resource_reference(>cb_buffer_fmask, 
rctx->dummy_fmask);
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/4] r600_state_common: check NULL return from u_upload_alloc

[Julien Isorce]

Like done in si_state_draw.c::si_draw_vbo

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/drivers/r600/r600_state_common.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c
index 6f8279f..cedeb74 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -1746,6 +1746,10 @@ static void r600_draw_vbo(struct pipe_context *ctx, 
const struct pipe_draw_info
 
u_upload_alloc(ctx->stream_uploader, start, count * 2,
256, _offset, _buffer, );
+   if (unlikely(!ptr)) {
+   pipe_resource_reference(, NULL);
+   return;
+   }
 
util_shorten_ubyte_elts_to_userptr(
>b.b, , 0, 0, 
ib.offset + start, count, ptr);
-- 
2.7.4

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

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

[Julien Isorce]

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

Re: [Mesa-dev] [PATCH 3/6] si_pipe: do not dereference sscreen before checking if it is NULL.

[Julien Isorce]

Should I remove
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/radeonsi/si_pipe.c#n687
then ?  (if (!sscreen)  return;)

On 20 March 2017 at 15:29, Marek Olšák <mar...@gmail.com> wrote:

> NAK. sscreen is never NULL here.
>
> Marek
>
> On Thu, Mar 16, 2017 at 3:25 PM, Julien Isorce <julien.iso...@gmail.com>
> wrote:
> > CID 1354483
> >
> > Signed-off-by: Julien Isorce <jiso...@oblong.com>
> > ---
> >  src/gallium/drivers/radeonsi/si_pipe.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
> b/src/gallium/drivers/radeonsi/si_pipe.c
> > index a9a7c8f..6cbaa72 100644
> > --- a/src/gallium/drivers/radeonsi/si_pipe.c
> > +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> > @@ -675,12 +675,12 @@ static void si_destroy_screen(struct pipe_screen*
> pscreen)
> >  {
> > struct si_screen *sscreen = (struct si_screen *)pscreen;
> > struct si_shader_part *parts[] = {
> > -   sscreen->vs_prologs,
> > -   sscreen->vs_epilogs,
> > -   sscreen->tcs_epilogs,
> > -   sscreen->gs_prologs,
> > -   sscreen->ps_prologs,
> > -   sscreen->ps_epilogs
> > +   sscreen ? sscreen->vs_prologs : NULL,
> > +   sscreen ? sscreen->vs_epilogs : NULL,
> > +   sscreen ? sscreen->tcs_epilogs : NULL,
> > +   sscreen ? sscreen->gs_prologs : NULL,
> > +   sscreen ? sscreen->ps_prologs : NULL,
> > +   sscreen ? sscreen->ps_epilogs : NULL
> > };
> > unsigned i;
> >
> > --
> > 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 4/6] radeon_drm_bo: explicitly check return value of drmCommandWriteRead

[Julien Isorce]

CID 1313492

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index f4ed3ce..f6d5c8a 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -186,8 +186,13 @@ static enum radeon_bo_domain radeon_bo_get_initial_domain(
 args.handle = bo->handle;
 args.op = RADEON_GEM_OP_GET_INITIAL_DOMAIN;
 
-drmCommandWriteRead(bo->rws->fd, DRM_RADEON_GEM_OP,
-, sizeof(args));
+if (drmCommandWriteRead(bo->rws->fd, DRM_RADEON_GEM_OP,
+, sizeof(args))) {
+fprintf(stderr, "radeon: failed to get initial domain: %p 0x%08X\n",
+bo, bo->handle);
+/* Default domain as returned by get_valid_domain. */
+return RADEON_DOMAIN_VRAM_GTT;
+}
 
 /* GEM domains and winsys domains are defined the same. */
 return get_valid_domain(args.value);
-- 
2.7.4

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

[Mesa-dev] [PATCH 5/6] si_blit: check zstex nullity

[Julien Isorce]

Few lines before there is a if (zstex && zstex->htile_buffer ...)
which tells that there are some situation where it can be NULL.

So let's check for its nullity in other places too. Spotted by
coverity:

CID 1237295

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/drivers/radeonsi/si_blit.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_blit.c 
b/src/gallium/drivers/radeonsi/si_blit.c
index da6c0cd..db4f533 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -749,14 +749,16 @@ static void si_clear(struct pipe_context *ctx, unsigned 
buffers,
if (sctx->db_depth_clear) {
sctx->db_depth_clear = false;
sctx->db_depth_disable_expclear = false;
-   zstex->depth_cleared = true;
+   if (zstex)
+   zstex->depth_cleared = true;
si_mark_atom_dirty(sctx, >db_render_state);
}
 
if (sctx->db_stencil_clear) {
sctx->db_stencil_clear = false;
sctx->db_stencil_disable_expclear = false;
-   zstex->stencil_cleared = true;
+   if (zstex)
+   zstex->stencil_cleared = true;
si_mark_atom_dirty(sctx, >db_render_state);
}
 }
-- 
2.7.4

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

[Mesa-dev] [PATCH 6/6] si_descriptor: move velems nullity check before dereference

[Julien Isorce]

CID 1399479: Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking velems suggests that it may be null,
but it has already been dereferenced on all paths leading to the check.

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/drivers/radeonsi/si_descriptors.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index eb79578..2e62725 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -949,15 +949,22 @@ bool si_upload_vertex_buffer_descriptors(struct 
si_context *sctx)
 {
struct si_vertex_element *velems = sctx->vertex_elements;
struct si_descriptors *desc = >vertex_buffers;
-   unsigned i, count = velems->count;
-   unsigned desc_list_byte_size = velems->desc_list_byte_size;
+   unsigned i, count;
+   unsigned desc_list_byte_size;
+   unsigned first_vb_use_mask;
uint64_t va;
uint32_t *ptr;
 
-   if (!sctx->vertex_buffers_dirty || !count || !velems)
+   if (!sctx->vertex_buffers_dirty || !velems)
return true;
 
-   unsigned first_vb_use_mask = velems->first_vb_use_mask;
+   count = velems->count;
+
+   if (!count)
+   return true;
+
+   desc_list_byte_size = velems->desc_list_byte_size;
+   first_vb_use_mask = velems->first_vb_use_mask;
 
/* Vertex buffer descriptors are the only ones which are uploaded
 * directly through a staging buffer and don't go through
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/6] si_pipe: do not dereference sscreen before checking if it is NULL.

[Julien Isorce]

CID 1354483

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/drivers/radeonsi/si_pipe.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index a9a7c8f..6cbaa72 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -675,12 +675,12 @@ static void si_destroy_screen(struct pipe_screen* pscreen)
 {
struct si_screen *sscreen = (struct si_screen *)pscreen;
struct si_shader_part *parts[] = {
-   sscreen->vs_prologs,
-   sscreen->vs_epilogs,
-   sscreen->tcs_epilogs,
-   sscreen->gs_prologs,
-   sscreen->ps_prologs,
-   sscreen->ps_epilogs
+   sscreen ? sscreen->vs_prologs : NULL,
+   sscreen ? sscreen->vs_epilogs : NULL,
+   sscreen ? sscreen->tcs_epilogs : NULL,
+   sscreen ? sscreen->gs_prologs : NULL,
+   sscreen ? sscreen->ps_prologs : NULL,
+   sscreen ? sscreen->ps_epilogs : NULL
};
unsigned i;
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/6] r600_shader.c: check validity of the value returned by eg_get_interpolator_index

[Julien Isorce]

Like done in another place in that same file.
Not sure if this should be an assert though.

CID 1250588

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/drivers/r600/r600_shader.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 8cb3f8b..55fd4ca 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1113,7 +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);
-   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 = 

@@ -1209,7 +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);
-   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] [PATCH 1/6] radeon: initialize hole variable before calling container_of

[Julien Isorce]

Like in a few other places in that radeon_drm_bo.c file.

CID 715739.

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index d4f4763..f4ed3ce 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -258,7 +258,7 @@ static uint64_t radeon_bomgr_find_va(struct 
radeon_drm_winsys *rws,
 static void radeon_bomgr_free_va(struct radeon_drm_winsys *rws,
  uint64_t va, uint64_t size)
 {
-struct radeon_bo_va_hole *hole;
+struct radeon_bo_va_hole *hole = NULL;
 
 size = align(size, rws->info.gart_page_size);
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 0/6] Fixes a few radeon issues found by Coverity

[Julien Isorce]

CID 1399479: medium
CID 1237295: medium
CID 1313492: medium
CID 1354483: medium
CID 1250588: high
CID 715739:  high

It is all more cosmetic than anything but worth to add some more checks.
To Emil: thx for your reply about "question about container_of". Here is
a cosmetic patch for it.

https://scan.coverity.com/projects/mesa/view_defects

Julien Isorce (6):
  radeon: initialize hole variable before calling container_of
  r600_shader.c: check validity of the value returned by
eg_get_interpolator_index
  si_pipe: do not dereference sscreen before checking if it is NULL.
  radeon_drm_bo: explicitly check return value of drmCommandWriteRead
  si_blit: check zstex nullity
  si_descriptor: move velems nullity check before dereference

 src/gallium/drivers/r600/r600_shader.c|  6 --
 src/gallium/drivers/radeonsi/si_blit.c|  6 --
 src/gallium/drivers/radeonsi/si_descriptors.c | 15 +++
 src/gallium/drivers/radeonsi/si_pipe.c| 12 ++--
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 11 ---
 5 files changed, 33 insertions(+), 17 deletions(-)

-- 
2.7.4

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

[Mesa-dev] [PATCH 2/3] radeon_drm_cs_flush: check null return from radeon_cs_create_fence

[Julien Isorce]

Follow-up of patch:
"radeon_cs_create_fence: check null return from radeon_winsys_bo_create"

radeon_drm_cs_flush
  radeon_cs_create_fence
radeon_winsys_bo_create

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index 1545fd8..f59b539 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -593,18 +593,20 @@ static int radeon_drm_cs_flush(struct radeon_winsys_cs 
*rcs,
 fence = radeon_cs_create_fence(rcs);
 }
 
-if (pfence)
-radeon_fence_reference(pfence, fence);
-
-mtx_lock(>ws->bo_fence_lock);
-for (unsigned i = 0; i < cs->csc->num_slab_buffers; ++i) {
-struct radeon_bo *bo = cs->csc->slab_buffers[i].bo;
-p_atomic_inc(>num_active_ioctls);
-radeon_bo_slab_fence(bo, (struct radeon_bo *)fence);
-}
-mtx_unlock(>ws->bo_fence_lock);
+if (fence) {
+if (pfence)
+radeon_fence_reference(pfence, fence);
+
+mtx_lock(>ws->bo_fence_lock);
+for (unsigned i = 0; i < cs->csc->num_slab_buffers; ++i) {
+struct radeon_bo *bo = cs->csc->slab_buffers[i].bo;
+p_atomic_inc(>num_active_ioctls);
+radeon_bo_slab_fence(bo, (struct radeon_bo *)fence);
+}
+mtx_unlock(>ws->bo_fence_lock);
 
-radeon_fence_reference(, NULL);
+radeon_fence_reference(, NULL);
+}
 } else {
 radeon_fence_reference(>next_fence, NULL);
 }
-- 
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] Fixes 1 crash in gallium/hud and 1 crash in gallium/radeon

[Julien Isorce]

I encountered these crashes with the radeonsi driver when the VRAM was full.
Even if the app should be careful to not upload too much texture for example,
it is better not to crash in mesa. Also I found other places in mesa when
these checks are done so let's do the same here.

I am quite confident with the first patch but unsure with the 2 others for the
teardown parts.

Julien Isorce (3):
  radeon_cs_create_fence: check null return from radeon_winsys_bo_create
  radeon_drm_cs_flush: check null return from radeon_cs_create_fence
  hud_context: check NULL return from u_upload_alloc

 src/gallium/auxiliary/hud/hud_context.c   |  5 +
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 25 ++---
 2 files changed, 19 insertions(+), 11 deletions(-)

-- 
2.7.4

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

[Mesa-dev] [PATCH 1/3] radeon_cs_create_fence: check null return from radeon_winsys_bo_create

[Julien Isorce]

Fixes the following segmentation fault:

radeon_drm_cs_add_buffer (bo=0x0) at radeon_drm_cs.c
  -> if (!bo->handle)
(gdb) bt
0  radeon_drm_cs_add_buffer (bo=0x0) at radeon_drm_cs.c
1  0x7fffe73575de in radeon_cs_create_fence radeon_drm_cs.c
2  0x7fffe7358c48 in radeon_drm_cs_flush radeon_drm_cs.c

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index d431bfc..1545fd8 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -750,6 +750,9 @@ radeon_cs_create_fence(struct radeon_winsys_cs *rcs)
 /* Create a fence, which is a dummy BO. */
 fence = cs->ws->base.buffer_create(>ws->base, 1, 1,
RADEON_DOMAIN_GTT, RADEON_FLAG_HANDLE);
+if (!fence)
+   return NULL;
+
 /* Add the fence as a dummy relocation. */
 cs->ws->base.cs_add_buffer(rcs, fence,
   RADEON_USAGE_READWRITE, RADEON_DOMAIN_GTT,
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/3] hud_context: check NULL return from u_upload_alloc

[Julien Isorce]

Fixes the following segmentation fault:

signal SIGSEGV: invalid address (fault address: 0x0)
 frame #0: 0x7fffe718e117 radeonsi_dri.so hud_draw_background_quad 
hud_context.c:170
   167
   168 assert(hud->bg.num_vertices + 4 <= hud->bg.max_num_vertices);
   169
-> 170 vertices[num++] = (float) x1;
   171 vertices[num++] = (float) y1;
   172
   173 vertices[num++] = (float) x1;
(lldb) bt
  * frame #0: 0x7fffe718e117 radeonsi_dri.so`hud_draw_background_quad
frame #1: 0x7fffe718f458 radeonsi_dri.so`hud_draw
frame #2: 0x7fffe712967f radeonsi_dri.so`dri_flush
---
 src/gallium/auxiliary/hud/hud_context.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index c44f8c0..29ef9ee 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -581,6 +581,10 @@ hud_draw(struct hud_context *hud, struct pipe_resource 
*tex)
   hud->color_prims.buffer_size,
   16, >bg.vbuf.buffer_offset, >bg.vbuf.buffer,
   (void**)>bg.vertices);
+   if (!hud->bg.vertices) {
+  goto out;
+   }
+
pipe_resource_reference(>whitelines.vbuf.buffer, hud->bg.vbuf.buffer);
pipe_resource_reference(>text.vbuf.buffer, hud->bg.vbuf.buffer);
pipe_resource_reference(>color_prims.vbuf.buffer, hud->bg.vbuf.buffer);
@@ -690,6 +694,7 @@ hud_draw(struct hud_context *hud, struct pipe_resource *tex)
  hud_pane_draw_colored_objects(hud, pane);
}
 
+out:
cso_restore_state(cso);
cso_restore_constant_buffer_slot0(cso, PIPE_SHADER_VERTEX);
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/3] radeon_drm_cs_flush: check null return from radeon_cs_create_fence

[Julien Isorce]

Follow-up of patch:
"radeon_cs_create_fence: check null return from radeon_winsys_bo_create"

radeon_drm_cs_flush
  radeon_cs_create_fence
radeon_winsys_bo_create

Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index 1545fd8..c854d11 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -593,18 +593,18 @@ static int radeon_drm_cs_flush(struct radeon_winsys_cs 
*rcs,
 fence = radeon_cs_create_fence(rcs);
 }
 
-if (pfence)
-radeon_fence_reference(pfence, fence);
-
-mtx_lock(>ws->bo_fence_lock);
-for (unsigned i = 0; i < cs->csc->num_slab_buffers; ++i) {
-struct radeon_bo *bo = cs->csc->slab_buffers[i].bo;
-p_atomic_inc(>num_active_ioctls);
-radeon_bo_slab_fence(bo, (struct radeon_bo *)fence);
+if (fence) {
+if (pfence)
+radeon_fence_reference(pfence, fence);
+
+mtx_lock(>ws->bo_fence_lock);
+for (unsigned i = 0; i < cs->csc->num_slab_buffers; ++i) {
+struct radeon_bo *bo = cs->csc->slab_buffers[i].bo;
+p_atomic_inc(>num_active_ioctls);
+radeon_bo_slab_fence(bo, (struct radeon_bo *)fence);
+}
+mtx_unlock(>ws->bo_fence_lock);
 }
-mtx_unlock(>ws->bo_fence_lock);
-
-radeon_fence_reference(, NULL);
 } else {
 radeon_fence_reference(>next_fence, NULL);
 }
-- 
2.7.4

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

[Mesa-dev] question about container_of

[Julien Isorce]

Hi,

Since 2012 commit ccff74971203b533bf16b46b49a9e61753f75e6c it is said:
"sample must be initialized, or else the result is undefined" in the
description of mesa/src/util/list.h::container_of .

But I can find a few places where it is used without initializing that
second parameter, i.e. like:

struct A a;
container_of(ptr, a, member);

Then I can add the "= NULL" but should it be just
container_of(ptr, struct A, member);
like in the kernel and some other places in mesa ?

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

Re: [Mesa-dev] [PATCH] st/va: set default rt formats when calling vaCreateConfig

[Julien Isorce]

Hi Christian,

I pushed it before already.  I can try to add a git notes if you want.
In any case thx for the review.

Cheers
Julien


On 18 October 2016 at 10:09, Christian König <christian.koe...@amd.com>
wrote:

> Am 17.10.2016 um 21:40 schrieb Julien Isorce:
>
>
>
> On Monday, 17 October 2016, Mark Thompson <s...@jkqxz.net> wrote:
>
>> On 17/10/16 17:33, Julien Isorce wrote:
>> > As specified in va.h, default value should be set on attributes
>> > not present in the input list.
>> >
>> > Signed-off-by: Julien Isorce <j.iso...@samsung.com>
>> > ---
>> >  src/gallium/state_trackers/va/config.c  | 9 +
>> >  src/gallium/state_trackers/va/surface.c | 5 +++--
>> >  2 files changed, 12 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/src/gallium/state_trackers/va/config.c
>> b/src/gallium/state_trackers/va/config.c
>> > index 2f96eb6..fb236f1 100644
>> > --- a/src/gallium/state_trackers/va/config.c
>> > +++ b/src/gallium/state_trackers/va/config.c
>> > @@ -195,6 +195,11 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile
>> profile, VAEntrypoint entrypoin
>> >  }
>> >   }
>> >}
>> > +
>> > +  /* Default value if not specified in the input attributes. */
>> > +  if (!config->rt_format)
>> > +config->rt_format = VA_RT_FORMAT_YUV420 | VA_RT_FORMAT_RGB32;
>>
>> Indent should be three spaces.
>>
>> > +
>> >pipe_mutex_lock(drv->mutex);
>> >*config_id = handle_table_add(drv->htab, config);
>> >pipe_mutex_unlock(drv->mutex);
>> > @@ -256,6 +261,10 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile
>> profile, VAEntrypoint entrypoin
>> >}
>> > }
>> >
>> > +   /* Default value if not specified in the input attributes. */
>> > +   if (!config->rt_format)
>> > + config->rt_format = VA_RT_FORMAT_YUV420;
>>
>> And here.
>
>
> Oh I forgot :) , cheers.
>
>
>> > +
>> > pipe_mutex_lock(drv->mutex);
>> > *config_id = handle_table_add(drv->htab, config);
>> > pipe_mutex_unlock(drv->mutex);
>> > diff --git a/src/gallium/state_trackers/va/surface.c
>> b/src/gallium/state_trackers/va/surface.c
>> > index 5e92980..f8513d9 100644
>> > --- a/src/gallium/state_trackers/va/surface.c
>> > +++ b/src/gallium/state_trackers/va/surface.c
>> > @@ -419,7 +419,7 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
>> VAConfigID config_id,
>> > /* vlVaCreateConfig returns PIPE_VIDEO_PROFILE_UNKNOWN
>> >  * only for VAEntrypointVideoProc. */
>> > if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
>> > -  if (config->rt_format == VA_RT_FORMAT_RGB32) {
>> > +  if (config->rt_format & VA_RT_FORMAT_RGB32) {
>> >   for (j = 0; j < ARRAY_SIZE(vpp_surface_formats); ++j) {
>> >  attribs[i].type = VASurfaceAttribPixelFormat;
>> >  attribs[i].value.type = VAGenericValueTypeInteger;
>> > @@ -427,7 +427,8 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
>> VAConfigID config_id,
>> >  attribs[i].value.value.i = PipeFormatToVaFourcc(vpp_surfa
>> ce_formats[j]);
>> >  i++;
>> >   }
>> > -  } else if (config->rt_format == VA_RT_FORMAT_YUV420) {
>> > +  }
>> > +  if (config->rt_format & VA_RT_FORMAT_YUV420) {
>> >   attribs[i].type = VASurfaceAttribPixelFormat;
>> >   attribs[i].value.type = VAGenericValueTypeInteger;
>> >   attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE |
>> VA_SURFACE_ATTRIB_SETTABLE;
>> >
>>
>> Actual code LGTM, and tested.
>>
>> Reviewed-by: Mark Thompson <s...@jkqxz.net>
>
>
> Thx, will push it soon.
>
>
> If you haven't already pushed it with the fixes Mark mentioned the patch
> is Reviewed-by: Christian König <christian.koe...@amd.com>
> <christian.koe...@amd.com> as well.
>
> Regards,
> Christian.
>
> Julien
>
>
>>
>> Thanks,
>>
>> - Mark
>>
>> ___
>> 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: set default rt formats when calling vaCreateConfig

[Julien Isorce]

On Monday, 17 October 2016, Mark Thompson <s...@jkqxz.net> wrote:

> On 17/10/16 17:33, Julien Isorce wrote:
> > As specified in va.h, default value should be set on attributes
> > not present in the input list.
> >
> > Signed-off-by: Julien Isorce <j.iso...@samsung.com <javascript:;>>
> > ---
> >  src/gallium/state_trackers/va/config.c  | 9 +
> >  src/gallium/state_trackers/va/surface.c | 5 +++--
> >  2 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/va/config.c
> b/src/gallium/state_trackers/va/config.c
> > index 2f96eb6..fb236f1 100644
> > --- a/src/gallium/state_trackers/va/config.c
> > +++ b/src/gallium/state_trackers/va/config.c
> > @@ -195,6 +195,11 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile
> profile, VAEntrypoint entrypoin
> >  }
> >   }
> >}
> > +
> > +  /* Default value if not specified in the input attributes. */
> > +  if (!config->rt_format)
> > +config->rt_format = VA_RT_FORMAT_YUV420 | VA_RT_FORMAT_RGB32;
>
> Indent should be three spaces.
>
> > +
> >pipe_mutex_lock(drv->mutex);
> >*config_id = handle_table_add(drv->htab, config);
> >pipe_mutex_unlock(drv->mutex);
> > @@ -256,6 +261,10 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile
> profile, VAEntrypoint entrypoin
> >}
> > }
> >
> > +   /* Default value if not specified in the input attributes. */
> > +   if (!config->rt_format)
> > + config->rt_format = VA_RT_FORMAT_YUV420;
>
> And here.


Oh I forgot :) , cheers.


> > +
> > pipe_mutex_lock(drv->mutex);
> > *config_id = handle_table_add(drv->htab, config);
> > pipe_mutex_unlock(drv->mutex);
> > diff --git a/src/gallium/state_trackers/va/surface.c
> b/src/gallium/state_trackers/va/surface.c
> > index 5e92980..f8513d9 100644
> > --- a/src/gallium/state_trackers/va/surface.c
> > +++ b/src/gallium/state_trackers/va/surface.c
> > @@ -419,7 +419,7 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
> VAConfigID config_id,
> > /* vlVaCreateConfig returns PIPE_VIDEO_PROFILE_UNKNOWN
> >  * only for VAEntrypointVideoProc. */
> > if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
> > -  if (config->rt_format == VA_RT_FORMAT_RGB32) {
> > +  if (config->rt_format & VA_RT_FORMAT_RGB32) {
> >   for (j = 0; j < ARRAY_SIZE(vpp_surface_formats); ++j) {
> >  attribs[i].type = VASurfaceAttribPixelFormat;
> >  attribs[i].value.type = VAGenericValueTypeInteger;
> > @@ -427,7 +427,8 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
> VAConfigID config_id,
> >  attribs[i].value.value.i = PipeFormatToVaFourcc(vpp_
> surface_formats[j]);
> >  i++;
> >   }
> > -  } else if (config->rt_format == VA_RT_FORMAT_YUV420) {
> > +  }
> > +  if (config->rt_format & VA_RT_FORMAT_YUV420) {
> >   attribs[i].type = VASurfaceAttribPixelFormat;
> >   attribs[i].value.type = VAGenericValueTypeInteger;
> >   attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE |
> VA_SURFACE_ATTRIB_SETTABLE;
> >
>
> Actual code LGTM, and tested.
>
> Reviewed-by: Mark Thompson <s...@jkqxz.net <javascript:;>>


Thx, will push it soon.
Julien


>
> Thanks,
>
> - Mark
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org <javascript:;>
> 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: Default to YUV420 RT format when creating a config

[Julien Isorce]

On 17 October 2016 at 16:27, Mark Thompson <s...@jkqxz.net> wrote:

> On 17/10/16 16:13, Julien Isorce wrote:
> > Hi Mark,
> >
> > Yes I actually saw that too in the intel driver though I think it does
> not add
> > VA_RT_FORMAT_RGB32 ? Or I missed something ?
> > Maybe this is a bug. In any case yes as said before " the intel va
> driver always
> > return the full list for vpp." from vaQuerySurfaceAttributes
> > no matter the format selected when creating the config.
>
> Looks like the lack of RGB32 has already been noted and fixed:
> <https://cgit.freedesktop.org/vaapi/intel-driver/commit/?id=
> e748bc7f0565d59a7ec2ba038e76a0a1de19c15c>.
>

Great, thx for the link.


>
> > So combining all it should probably be something like this:
> >
> > diff --git a/src/gallium/state_trackers/va/config.c
> > b/src/gallium/state_trackers/va/config.c
> > index 2f96eb6..11afc81 100644
> > --- a/src/gallium/state_trackers/va/config.c
> > +++ b/src/gallium/state_trackers/va/config.c
> > @@ -185,6 +185,8 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile
> profile,
> > VAEntrypoint entrypoin
> > if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc)
> {
> >config->entrypoint = VAEntrypointVideoProc;
> >config->profile = PIPE_VIDEO_PROFILE_UNKNOWN;
> > +  config->rt_format = VA_RT_FORMAT_YUV420 | VA_RT_FORMAT_RGB32;
> > +
> >for (int i = 0; i < num_attribs; i++) {
> >   if (attrib_list[i].type == VAConfigAttribRTFormat) {
> >  if (attrib_list[i].value & (VA_RT_FORMAT_YUV420 |
> > VA_RT_FORMAT_RGB32)) {
>
> Please set a default for the non-VideoProc case too, so that codecs have
> the
> same behaviour.
>

Oups


>
> > diff --git a/src/gallium/state_trackers/va/surface.c
> > b/src/gallium/state_trackers/va/surface.c
> > index 5e92980..f8513d9 100644
> > --- a/src/gallium/state_trackers/va/surface.c
> > +++ b/src/gallium/state_trackers/va/surface.c
> > @@ -419,7 +419,7 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
> VAConfigID
> > config_id,
> > /* vlVaCreateConfig returns PIPE_VIDEO_PROFILE_UNKNOWN
> >  * only for VAEntrypointVideoProc. */
> > if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
> > -  if (config->rt_format == VA_RT_FORMAT_RGB32) {
> > +  if (config->rt_format & VA_RT_FORMAT_RGB32) {
> >   for (j = 0; j < ARRAY_SIZE(vpp_surface_formats); ++j) {
> >  attribs[i].type = VASurfaceAttribPixelFormat;
> >  attribs[i].value.type = VAGenericValueTypeInteger;
> > @@ -427,7 +427,8 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
> VAConfigID
> > config_id,
> >  attribs[i].value.value.i =
> > PipeFormatToVaFourcc(vpp_surface_formats[j]);
> >  i++;
> >   }
> > -  } else if (config->rt_format == VA_RT_FORMAT_YUV420) {
> > +  }
> > +  if (config->rt_format & VA_RT_FORMAT_YUV420) {
> >   attribs[i].type = VASurfaceAttribPixelFormat;
> >   attribs[i].value.type = VAGenericValueTypeInteger;
> >   attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE |
> > VA_SURFACE_ATTRIB_SETTABLE;
> >
> > Will it be ok for your case ?
> >
> > Cheers
> > Julien
>
> Yeah, that seems right to me (with the small change above).
>

I sent the patch to mesa-dev few minutes ago, please have a look, thx.

Cheers
Julien


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

[Mesa-dev] [PATCH] st/va: set default rt formats when calling vaCreateConfig

[Julien Isorce]

As specified in va.h, default value should be set on attributes
not present in the input list.

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/state_trackers/va/config.c  | 9 +
 src/gallium/state_trackers/va/surface.c | 5 +++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 2f96eb6..fb236f1 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -195,6 +195,11 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
 }
  }
   }
+
+  /* Default value if not specified in the input attributes. */
+  if (!config->rt_format)
+config->rt_format = VA_RT_FORMAT_YUV420 | VA_RT_FORMAT_RGB32;
+
   pipe_mutex_lock(drv->mutex);
   *config_id = handle_table_add(drv->htab, config);
   pipe_mutex_unlock(drv->mutex);
@@ -256,6 +261,10 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
   }
}
 
+   /* Default value if not specified in the input attributes. */
+   if (!config->rt_format)
+ config->rt_format = VA_RT_FORMAT_YUV420;
+
pipe_mutex_lock(drv->mutex);
*config_id = handle_table_add(drv->htab, config);
pipe_mutex_unlock(drv->mutex);
diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 5e92980..f8513d9 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -419,7 +419,7 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx, VAConfigID 
config_id,
/* vlVaCreateConfig returns PIPE_VIDEO_PROFILE_UNKNOWN
 * only for VAEntrypointVideoProc. */
if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
-  if (config->rt_format == VA_RT_FORMAT_RGB32) {
+  if (config->rt_format & VA_RT_FORMAT_RGB32) {
  for (j = 0; j < ARRAY_SIZE(vpp_surface_formats); ++j) {
 attribs[i].type = VASurfaceAttribPixelFormat;
 attribs[i].value.type = VAGenericValueTypeInteger;
@@ -427,7 +427,8 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx, VAConfigID 
config_id,
 attribs[i].value.value.i = 
PipeFormatToVaFourcc(vpp_surface_formats[j]);
 i++;
  }
-  } else if (config->rt_format == VA_RT_FORMAT_YUV420) {
+  }
+  if (config->rt_format & VA_RT_FORMAT_YUV420) {
  attribs[i].type = VASurfaceAttribPixelFormat;
  attribs[i].value.type = VAGenericValueTypeInteger;
  attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE | 
VA_SURFACE_ATTRIB_SETTABLE;
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] st/va: Default to YUV420 RT format when creating a config

[Julien Isorce]

Hi Mark,

Yes I actually saw that too in the intel driver though I think it does not
add VA_RT_FORMAT_RGB32 ? Or I missed something ?
Maybe this is a bug. In any case yes as said before " the intel va driver
always return the full list for vpp." from vaQuerySurfaceAttributes
no matter the format selected when creating the config.

So combining all it should probably be something like this:

diff --git a/src/gallium/state_trackers/va/config.c
b/src/gallium/state_trackers/va/config.c
index 2f96eb6..11afc81 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -185,6 +185,8 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile
profile, VAEntrypoint entrypoin
if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc) {
   config->entrypoint = VAEntrypointVideoProc;
   config->profile = PIPE_VIDEO_PROFILE_UNKNOWN;
+  config->rt_format = VA_RT_FORMAT_YUV420 | VA_RT_FORMAT_RGB32;
+
   for (int i = 0; i < num_attribs; i++) {
  if (attrib_list[i].type == VAConfigAttribRTFormat) {
 if (attrib_list[i].value & (VA_RT_FORMAT_YUV420 |
VA_RT_FORMAT_RGB32)) {
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
index 5e92980..f8513d9 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -419,7 +419,7 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
VAConfigID config_id,
/* vlVaCreateConfig returns PIPE_VIDEO_PROFILE_UNKNOWN
 * only for VAEntrypointVideoProc. */
if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
-  if (config->rt_format == VA_RT_FORMAT_RGB32) {
+  if (config->rt_format & VA_RT_FORMAT_RGB32) {
  for (j = 0; j < ARRAY_SIZE(vpp_surface_formats); ++j) {
 attribs[i].type = VASurfaceAttribPixelFormat;
 attribs[i].value.type = VAGenericValueTypeInteger;
@@ -427,7 +427,8 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
VAConfigID config_id,
 attribs[i].value.value.i =
PipeFormatToVaFourcc(vpp_surface_formats[j]);
 i++;
  }
-  } else if (config->rt_format == VA_RT_FORMAT_YUV420) {
+  }
+  if (config->rt_format & VA_RT_FORMAT_YUV420) {
  attribs[i].type = VASurfaceAttribPixelFormat;
  attribs[i].value.type = VAGenericValueTypeInteger;
  attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE |
VA_SURFACE_ATTRIB_SETTABLE;

Will it be ok for your case ?

Cheers
Julien






On 17 October 2016 at 15:54, Mark Thompson <s...@jkqxz.net> wrote:

> On 17/10/16 15:42, Mark Thompson wrote:
> > The default will only be used if the VAConfigRTFormat attribute is not
> > provided by the user.
> > ---
> > On 17/10/16 15:21, Julien Isorce wrote:
> >> Hi Mark,
> >>
> >> Thx for the patch. I can see it has already landed.
> >>
> >> I just tried it with gstreamer-vaapi and it causes problem since they
> create the
> >> config like this for VPP:
> >>
> >> va_status = vaCreateConfig (filter->va_display, VAProfileNone,
> >>   VAEntrypointVideoProc, NULL, 0, >va_config);
> >>
> >> As you can see num attrivs is 0 so it makes vaQuerySurfaceAttributes to
> return
> >> no supported format
> >> because config->rt_format is 0.
> >>
> >> So I plan to make a patch that looks like this:
> >>
> >>
> >> --- a/src/gallium/state_trackers/va/surface.c
> >> +++ b/src/gallium/state_trackers/va/surface.c
> >> @@ -419,7 +419,7 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
> VAConfigID
> >> config_id,
> >> /* vlVaCreateConfig returns PIPE_VIDEO_PROFILE_UNKNOWN
> >>  * only for VAEntrypointVideoProc. */
> >> if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
> >> -  if (config->rt_format == VA_RT_FORMAT_RGB32) {
> >> +  if (!config->rt_format || config->rt_format ==
> VA_RT_FORMAT_RGB32) {
> >>   for (j = 0; j < ARRAY_SIZE(vpp_surface_formats); ++j) {
> >>  attribs[i].type = VASurfaceAttribPixelFormat;
> >>  attribs[i].value.type = VAGenericValueTypeInteger;
> >> @@ -427,7 +427,8 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
> VAConfigID
> >> config_id,
> >>  attribs[i].value.value.i =
> >> PipeFormatToVaFourcc(vpp_surface_formats[j]);
> >>  i++;
> >>   }
> >> -  } else if (config->rt_format == VA_RT_FORMAT_YUV420) {
> >> +  }
> >> +  if (!config->rt_format || config->rt_format ==
> VA_RT_FORMAT_YUV420) {
> >>   attribs[i].type = VASurfaceAtt

Re: [Mesa-dev] [PATCH 3/5] st/va: Return surface formats depending on config chroma format

[Julien Isorce]

Hi Mark,

Thx for the patch. I can see it has already landed.

I just tried it with gstreamer-vaapi and it causes problem since they
create the config like this for VPP:

va_status = vaCreateConfig (filter->va_display, VAProfileNone,
  VAEntrypointVideoProc, NULL, 0, >va_config);

As you can see num attrivs is 0 so it makes vaQuerySurfaceAttributes to
return no supported format
because config->rt_format is 0.

So I plan to make a patch that looks like this:


--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -419,7 +419,7 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
VAConfigID config_id,
/* vlVaCreateConfig returns PIPE_VIDEO_PROFILE_UNKNOWN
 * only for VAEntrypointVideoProc. */
if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
-  if (config->rt_format == VA_RT_FORMAT_RGB32) {
+  if (!config->rt_format || config->rt_format == VA_RT_FORMAT_RGB32) {
  for (j = 0; j < ARRAY_SIZE(vpp_surface_formats); ++j) {
 attribs[i].type = VASurfaceAttribPixelFormat;
 attribs[i].value.type = VAGenericValueTypeInteger;
@@ -427,7 +427,8 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
VAConfigID config_id,
 attribs[i].value.value.i =
PipeFormatToVaFourcc(vpp_surface_formats[j]);
 i++;
  }
-  } else if (config->rt_format == VA_RT_FORMAT_YUV420) {
+  }
+  if (!config->rt_format || config->rt_format == VA_RT_FORMAT_YUV420) {
  attribs[i].type = VASurfaceAttribPixelFormat;
  attribs[i].value.type = VAGenericValueTypeInteger;
  attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE |
VA_SURFACE_ATTRIB_SETTABLE;


Will it be ok for whatever test application you are using ?

Not that the intel va driver always return the full list for vpp.

Cheers
Julien







On 12 October 2016 at 23:53, Mark Thompson  wrote:

> This makes the supported format actually match the configuration, and
> allows the user to observe that NV12 is supported for video processing
> where previously they couldn't (though it did always work if they
> blindly tried to use it anyway).
> ---
>  src/gallium/state_trackers/va/surface.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/surface.c
> b/src/gallium/state_trackers/va/surface.c
> index 173e7d9..5e92980 100644
> --- a/src/gallium/state_trackers/va/surface.c
> +++ b/src/gallium/state_trackers/va/surface.c
> @@ -419,11 +419,19 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
> VAConfigID config_id,
> /* vlVaCreateConfig returns PIPE_VIDEO_PROFILE_UNKNOWN
>  * only for VAEntrypointVideoProc. */
> if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
> -  for (j = 0; j < ARRAY_SIZE(vpp_surface_formats); ++j) {
> +  if (config->rt_format == VA_RT_FORMAT_RGB32) {
> + for (j = 0; j < ARRAY_SIZE(vpp_surface_formats); ++j) {
> +attribs[i].type = VASurfaceAttribPixelFormat;
> +attribs[i].value.type = VAGenericValueTypeInteger;
> +attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE |
> VA_SURFACE_ATTRIB_SETTABLE;
> +attribs[i].value.value.i = PipeFormatToVaFourcc(vpp_
> surface_formats[j]);
> +i++;
> + }
> +  } else if (config->rt_format == VA_RT_FORMAT_YUV420) {
>   attribs[i].type = VASurfaceAttribPixelFormat;
>   attribs[i].value.type = VAGenericValueTypeInteger;
>   attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE |
> VA_SURFACE_ATTRIB_SETTABLE;
> - attribs[i].value.value.i = PipeFormatToVaFourcc(vpp_
> surface_formats[j]);
> + attribs[i].value.value.i = VA_FOURCC_NV12;
>   i++;
>}
> } else {
> --
> 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] st/va: Make VAAPI_DISABLE_INTERLACE default true

[Julien Isorce]

On 16 September 2016 at 08:43, Christian König <deathsim...@vodafone.de>
wrote:

> Am 15.09.2016 um 23:07 schrieb Julien Isorce:
>
>
>
> On 15 September 2016 at 16:02, Leo Liu <leo@amd.com> wrote:
>
>>
>>
>> On 09/15/2016 10:43 AM, Andy Furniss wrote:
>>
>>> Since bf901a2
>>> st/va: also honors interlaced preference when providing a video format
>>> existing scripts and most use cases will need true.
>>>
>>> Signed-off-by: Andy Furniss <adf.li...@gmail.com>
>>> ---
>>>  src/gallium/state_trackers/va/surface.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/state_trackers/va/surface.c
>>> b/src/gallium/state_trackers/va/surface.c
>>> index 00df69d..e73e17e 100644
>>> --- a/src/gallium/state_trackers/va/surface.c
>>> +++ b/src/gallium/state_trackers/va/surface.c
>>> @@ -43,7 +43,7 @@
>>>
>>>  #include "va_private.h"
>>>
>>> -DEBUG_GET_ONCE_BOOL_OPTION(nointerlace, "VAAPI_DISABLE_INTERLACE",
>>> FALSE);
>>> +DEBUG_GET_ONCE_BOOL_OPTION(nointerlace, "VAAPI_DISABLE_INTERLACE",
>>> TRUE);
>>>
>>
>> Like being mentioned,  It'll still override the preferred interlaced
>> format when this env is not explicitly used.
>>
>> Not sure this will be okay with other case. @Julien?
>>
>
> Hi,
>
> So the problem is that with radeon, PIPE_VIDEO_CAP_SUPPORTS_INTERLACED
> always returns false for encoding
> but can return true for decoding (depending on the chipset and the codec).
> Then when doing transcoding you need all to be non interlaced to avoid
> extra copy/conversion and even a clash. Is it correct ?
>
>
> Yes correct. The decoder supports both interlaced as well as progressive
> memory layout, but the encoder can only handle progressive input.
>
> Interlaced memory layout is needed for things like adaptive deinterlacing
> as well as VDPAU OpenGL interop.
>

> Should debug_get_option_nointerlace() be moved to 
> radeon_video.c::rvid_get_video_param
> ?
>
>
> For the short term that sounds like a good idea to me.
>


Hi @Andy, could you update your patch to move that debug env flag to radeon
?  Thx



> In the mid term we need to better handle this case. E.g. allocate the
> video buffer with the layout the driver reports as preferred, if that
> doesn't match the use case (transcoding, deinterlacing or interop) convert
> as needed.
>

yes, also if the conversion is done in HW that should still acceptable.
But also it should be a way to configure that from gstreamer-vaapi/libva
using VA_SURFACE_ATTRIB_USAGE_HINT_ENCODER /
VA_SURFACE_ATTRIB_USAGE_HINT_VPP_READ maybe ... and catch this flag in
vlVaCreateSurfaces2.


>
>
> Other question:
>
> case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED:
> if (rscreen->family < CHIP_PALM) {
> /* MPEG2 only with shaders and no support for
>interlacing on R6xx style UVD */
> return codec != PIPE_VIDEO_FORMAT_MPEG12 &&
>rscreen->family > CHIP_RV770;
> } else {
> if (u_reduce_video_profile(profile) == PIPE_VIDEO_FORMAT_HEVC)
> return false; //The firmware doesn't support interlaced
> HEVC.
> return true;
> }
> So if instead it would always return false then it will really work on
> hardware for which above code says true ?
>
>
> It would work, but the deinterlacing and interop use case I noted above
> would break.
>
>

> Because my understanding is that for nvidia hardware this is not a
> preference but rather a requirement but I might be wrong.
>
>
> Yes, as far as I know that is correct. AMD hardware can handle both for
> most hardware/profile combinations, even the HEVC limit only applies to a
> certain firmware version IIRC.
>
>
> In any case, with current upstream code and VAAPI_DISABLE_INTERLACE=1 it
> hits "assert(templat->interlaced);" in nouveau_vp3_video_buffer_create.
> If I remove the asset it crashes and can even stall the driver (just wanted
> to check ).
>
>
> Crap, feel free to revert the patch setting it to true by default.
>

It has not been pushed:
https://cgit.freedesktop.org/mesa/mesa/log/src/gallium/state_trackers/va
so still time for @Andy to update his patch.


Cheers
Julien


> Regards,
> Christian.
>
> Cheers
> Julien
>
>
>> Regards,
>> Leo
>>
>>
>>>  #include 
>>>
>>>
>>
>
>
> ___
> mesa-dev mailing 
> listmesa-dev@lists.freedesktop.orghttps://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: Make VAAPI_DISABLE_INTERLACE default true

[Julien Isorce]

On 15 September 2016 at 16:02, Leo Liu  wrote:

>
>
> On 09/15/2016 10:43 AM, Andy Furniss wrote:
>
>> Since bf901a2
>> st/va: also honors interlaced preference when providing a video format
>> existing scripts and most use cases will need true.
>>
>> Signed-off-by: Andy Furniss 
>> ---
>>  src/gallium/state_trackers/va/surface.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/state_trackers/va/surface.c
>> b/src/gallium/state_trackers/va/surface.c
>> index 00df69d..e73e17e 100644
>> --- a/src/gallium/state_trackers/va/surface.c
>> +++ b/src/gallium/state_trackers/va/surface.c
>> @@ -43,7 +43,7 @@
>>
>>  #include "va_private.h"
>>
>> -DEBUG_GET_ONCE_BOOL_OPTION(nointerlace, "VAAPI_DISABLE_INTERLACE",
>> FALSE);
>> +DEBUG_GET_ONCE_BOOL_OPTION(nointerlace, "VAAPI_DISABLE_INTERLACE",
>> TRUE);
>>
>
> Like being mentioned,  It'll still override the preferred interlaced
> format when this env is not explicitly used.
>
> Not sure this will be okay with other case. @Julien?
>

Hi,

So the problem is that with radeon, PIPE_VIDEO_CAP_SUPPORTS_INTERLACED
always returns false for encoding
but can return true for decoding (depending on the chipset and the codec).
Then when doing transcoding you need all to be non interlaced to avoid
extra copy/conversion and even a clash. Is it correct ?

Should debug_get_option_nointerlace() be moved to
radeon_video.c::rvid_get_video_param ?

Other question:

case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED:
if (rscreen->family < CHIP_PALM) {
/* MPEG2 only with shaders and no support for
   interlacing on R6xx style UVD */
return codec != PIPE_VIDEO_FORMAT_MPEG12 &&
   rscreen->family > CHIP_RV770;
} else {
if (u_reduce_video_profile(profile) == PIPE_VIDEO_FORMAT_HEVC)
return false; //The firmware doesn't support interlaced
HEVC.
return true;
}
So if instead it would always return false then it will really work on
hardware for which above code says true ?
Because my understanding is that for nvidia hardware this is not a
preference but rather a requirement but I might be wrong.

In any case, with current upstream code and VAAPI_DISABLE_INTERLACE=1 it
hits "assert(templat->interlaced);" in nouveau_vp3_video_buffer_create. If
I remove the asset it crashes and can even stall the driver (just wanted to
check ).

Cheers
Julien


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

[Mesa-dev] [PATCH] st/va: also honors interlaced preference when providing a video format

[Julien Isorce]

This fixes a crash when using the prefered video format with vaapisink
on Nvidia hardwares.
Also caught by the following assert:
  nouveau_vp3_video.c:91: Assertion `templat->interlaced' failed.

TEST= gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12 ! vaapisink

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
Tested-by: Víctor Manuel Jáquez Leal <vjaq...@igalia.com>
---
 src/gallium/state_trackers/va/surface.c | 36 +
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 3ee1cdd..00df69d 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -632,24 +632,26 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
 
memset(, 0, sizeof(templat));
 
+   templat.buffer_format = pscreen->get_video_param(
+  pscreen,
+  PIPE_VIDEO_PROFILE_UNKNOWN,
+  PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
+  PIPE_VIDEO_CAP_PREFERED_FORMAT
+   );
+   templat.interlaced = pscreen->get_video_param(
+  pscreen,
+  PIPE_VIDEO_PROFILE_UNKNOWN,
+  PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
+  PIPE_VIDEO_CAP_PREFERS_INTERLACED
+   );
+
if (expected_fourcc) {
-  templat.buffer_format = VaFourccToPipeFormat(expected_fourcc);
-  templat.interlaced = 0;
-   } else {
-  templat.buffer_format = pscreen->get_video_param
-(
-   pscreen,
-   PIPE_VIDEO_PROFILE_UNKNOWN,
-   PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
-   PIPE_VIDEO_CAP_PREFERED_FORMAT
-   );
-  templat.interlaced = pscreen->get_video_param
-(
-   pscreen,
-   PIPE_VIDEO_PROFILE_UNKNOWN,
-   PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
-   PIPE_VIDEO_CAP_PREFERS_INTERLACED
-   );
+  enum pipe_format expected_format = VaFourccToPipeFormat(expected_fourcc);
+
+  if (expected_format != templat.buffer_format || memory_attibute)
+templat.interlaced = 0;
+
+  templat.buffer_format = expected_format;
}
 
templat.chroma_format = ChromaToPipe(format);
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH 4/4] st/omx/dec: make decoder video buffer progressive

[Julien Isorce]

No encoder with nouveau driver so I cannot do a tunneling test
but at least this does not break the decoder part so the 4 patches are:
Tested-by: Julien Isorce <j.iso...@samsung.com>
Thx!


On 6 July 2016 at 19:03, Leo Liu <leo@amd.com> wrote:

> The idea of encode tunneling is to use video buffer directly for encoder,
> but currently the encoder doesn’t support interlaced surface, the OMX
> decoder set progressive surface before on that purpose.
>
> Since now we are polling the driver for interlacing information for
> decoder, we got the interlaced as preferred as other APIs(VDPAU, VA-API),
> thus breaking the transcode with tunneling.
>
> The solution is when with tunnel detected, re-allocate progressive target
> buffers, and then converting the interlaced decoder results to there.
>
> This has been tested with transcode results bit to bit matching as before
> with surface from progressive to progressive.
>
> Signed-off-by: Leo Liu <leo@amd.com>
> ---
>  src/gallium/state_trackers/omx/vid_dec.c | 65
> +++-
>  src/gallium/state_trackers/omx/vid_dec.h |  6 ++-
>  2 files changed, 68 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/state_trackers/omx/vid_dec.c
> b/src/gallium/state_trackers/omx/vid_dec.c
> index a989c10..7842966 100644
> --- a/src/gallium/state_trackers/omx/vid_dec.c
> +++ b/src/gallium/state_trackers/omx/vid_dec.c
> @@ -167,6 +167,19 @@ static OMX_ERRORTYPE
> vid_dec_Constructor(OMX_COMPONENTTYPE *comp, OMX_STRING nam
> if (!priv->pipe)
>return OMX_ErrorInsufficientResources;
>
> +   if (!vl_compositor_init(>compositor, priv->pipe)) {
> +  priv->pipe->destroy(priv->pipe);
> +  priv->pipe = NULL;
> +  return OMX_ErrorInsufficientResources;
> +   }
> +
> +   if (!vl_compositor_init_state(>cstate, priv->pipe)) {
> +  vl_compositor_cleanup(>compositor);
> +  priv->pipe->destroy(priv->pipe);
> +  priv->pipe = NULL;
> +  return OMX_ErrorInsufficientResources;
> +   }
> +
> priv->sPortTypesParam[OMX_PortDomainVideo].nStartPortNumber = 0;
> priv->sPortTypesParam[OMX_PortDomainVideo].nPorts = 2;
> priv->ports = CALLOC(2, sizeof(omx_base_PortType *));
> @@ -218,8 +231,11 @@ static OMX_ERRORTYPE
> vid_dec_Destructor(OMX_COMPONENTTYPE *comp)
>priv->ports=NULL;
> }
>
> -   if (priv->pipe)
> +   if (priv->pipe) {
> +  vl_compositor_cleanup_state(>cstate);
> +  vl_compositor_cleanup(>compositor);
>priv->pipe->destroy(priv->pipe);
> +   }
>
> if (priv->screen)
>omx_put_screen();
> @@ -547,6 +563,25 @@ static void vid_dec_FillOutput(vid_dec_PrivateType
> *priv, struct pipe_video_buff
> }
>  }
>
> +static void vid_dec_deint(vid_dec_PrivateType *priv, struct
> pipe_video_buffer *src_buf,
> +  struct pipe_video_buffer *dst_buf)
> +{
> +   struct vl_compositor *compositor = >compositor;
> +   struct vl_compositor_state *s = >cstate;
> +   struct pipe_surface **dst_surface;
> +
> +   dst_surface = dst_buf->get_surfaces(dst_buf);
> +   vl_compositor_clear_layers(s);
> +
> +   vl_compositor_set_yuv_layer(s, compositor, 0, src_buf, NULL, NULL,
> true);
> +   vl_compositor_set_layer_dst_area(s, 0, NULL);
> +   vl_compositor_render(s, compositor, dst_surface[0], NULL, false);
> +
> +   vl_compositor_set_yuv_layer(s, compositor, 0, src_buf, NULL, NULL,
> false);
> +   vl_compositor_set_layer_dst_area(s, 0, NULL);
> +   vl_compositor_render(s, compositor, dst_surface[1], NULL, false);
> +}
> +
>  static void vid_dec_FrameDecoded(OMX_COMPONENTTYPE *comp,
> OMX_BUFFERHEADERTYPE* input,
>   OMX_BUFFERHEADERTYPE* output)
>  {
> @@ -562,7 +597,33 @@ static void vid_dec_FrameDecoded(OMX_COMPONENTTYPE
> *comp, OMX_BUFFERHEADERTYPE*
>
> if (input->pInputPortPrivate) {
>if (output->pInputPortPrivate) {
> - struct pipe_video_buffer *tmp = output->pOutputPortPrivate;
> + struct pipe_video_buffer *tmp, *vbuf, *new_vbuf;
> +
> + tmp = output->pOutputPortPrivate;
> + vbuf = input->pInputPortPrivate;
> + if (vbuf->interlaced) {
> +/* re-allocate the progressive buffer */
> +omx_base_video_PortType *port;
> +struct pipe_video_buffer templat = {};
> +
> +port = (omx_base_video_PortType *)
> +priv->ports[OMX_BASE_FILTER_INPUTPORT_INDEX];
> +memset(, 0, sizeof(templat));
> +templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
&g

[Mesa-dev] [PATCH] st/omx: fix crash when vid_enc_Constructor fails

[Julien Isorce]

It happens when trying to use omxh264enc with nouveau driver
because it does not provide any encoder at the moment.

It crashes on enc_ReleaseTasks(>free_tasks) because
at this time the list is not initialized.
So this patch make sure the lists are initialized.

Another way to fix this would be to do an early return in
enc_ReleaseTasks if head->next is null.
---
 src/gallium/state_trackers/omx/vid_enc.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/src/gallium/state_trackers/omx/vid_enc.c 
b/src/gallium/state_trackers/omx/vid_enc.c
index d70439a..7df5565 100644
--- a/src/gallium/state_trackers/omx/vid_enc.c
+++ b/src/gallium/state_trackers/omx/vid_enc.c
@@ -158,9 +158,14 @@ static OMX_ERRORTYPE vid_enc_Constructor(OMX_COMPONENTTYPE 
*comp, OMX_STRING nam
if (!priv)
   return OMX_ErrorInsufficientResources;
 
+   LIST_INITHEAD(>free_tasks);
+   LIST_INITHEAD(>used_tasks);
+   LIST_INITHEAD(>b_frames);
+   LIST_INITHEAD(>stacked_tasks);
+
r = omx_base_filter_Constructor(comp, name);
if (r)
-   return r;
+  return r;
 
priv->BufferMgmtCallback = vid_enc_BufferEncoded;
priv->messageHandler = vid_enc_MessageHandler;
@@ -256,11 +261,6 @@ static OMX_ERRORTYPE vid_enc_Constructor(OMX_COMPONENTTYPE 
*comp, OMX_STRING nam
priv->scale.xWidth = OMX_VID_ENC_SCALING_WIDTH_DEFAULT;
priv->scale.xHeight = OMX_VID_ENC_SCALING_WIDTH_DEFAULT;
 
-   LIST_INITHEAD(>free_tasks);
-   LIST_INITHEAD(>used_tasks);
-   LIST_INITHEAD(>b_frames);
-   LIST_INITHEAD(>stacked_tasks);
-
return OMX_ErrorNone;
 }
 
@@ -269,6 +269,9 @@ static OMX_ERRORTYPE vid_enc_Destructor(OMX_COMPONENTTYPE 
*comp)
vid_enc_PrivateType* priv = comp->pComponentPrivate;
int i;
 
+   if (!priv)
+  return OMX_ErrorBadParameter;
+
enc_ReleaseTasks(>free_tasks);
enc_ReleaseTasks(>used_tasks);
enc_ReleaseTasks(>b_frames);
@@ -875,7 +878,7 @@ static void enc_ReleaseTasks(struct list_head *head)
struct encode_task *i, *next;
 
if (!head)
-  return;
+  return;
 
LIST_FOR_EACH_ENTRY_SAFE(i, next, head, list) {
   pipe_resource_reference(>bitstream, NULL);
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH 2/3] st/omx: add support for nouveau / interlaced

[Julien Isorce]

Thx Leo.
I confirm it works with nouveau driver so your fix is:
Tested-by: Julien Isorce <j.iso...@samsung.com>

On 28 June 2016 at 02:27, Liu, Leo <leo@amd.com> wrote:

> Hi Julien and Christian,
>
>
> I got a patch attached to fix the "fillout" problem, and please review.
>
>
> But we still need to fix transcoding issue with interlaced as true. Our
> transcode support tunneling, basic the decode buffer will be used directly
> for encode.
>
>
> Thanks,
>
> Leo
>
>
>
> --
> *From:* Julien Isorce <julien.iso...@gmail.com>
> *Sent:* June 27, 2016 4:54:07 PM
> *To:* Liu, Leo
> *Cc:* ML mesa-dev; Gurkirpal Singh; Koenig, Christian
> *Subject:* Re: [Mesa-dev] [PATCH 2/3] st/omx: add support for nouveau /
> interlaced
>
> Hi Leo,
>
> Sorry for the inconvenience, could you let me know how to reproduce the
> problem ?
> I have been playing with some gst pipelines and they all work but I can
> only test with nouveau driver.
>
> Cheers
> Julien
>
>
> On 27 June 2016 at 21:35, Leo Liu <leo@amd.com> wrote:
>
>> This patch break omx decode to file, it got seg fault. Will take look
>> further.
>>
>> Regards,
>> Leo
>>
>>
>>
>> On 06/27/2016 04:16 AM, Julien Isorce wrote:
>>
>>> Signed-off-by: Julien Isorce <j.iso...@samsung.com>
>>> ---
>>>   src/gallium/state_trackers/omx/vid_dec.c | 51
>>> 
>>>   1 file changed, 26 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/src/gallium/state_trackers/omx/vid_dec.c
>>> b/src/gallium/state_trackers/omx/vid_dec.c
>>> index 564ca2f..85ffb88 100644
>>> --- a/src/gallium/state_trackers/omx/vid_dec.c
>>> +++ b/src/gallium/state_trackers/omx/vid_dec.c
>>> @@ -48,6 +48,7 @@
>>>   #include "pipe/p_video_codec.h"
>>>   #include "util/u_memory.h"
>>>   #include "util/u_surface.h"
>>> +#include "vl/vl_video_buffer.h"
>>>   #include "vl/vl_vlc.h"
>>> #include "entrypoint.h"
>>> @@ -515,34 +516,34 @@ static void vid_dec_FillOutput(vid_dec_PrivateType
>>> *priv, struct pipe_video_buff
>>>  OMX_VIDEO_PORTDEFINITIONTYPE *def = >sPortParam.format.video;
>>>struct pipe_sampler_view **views;
>>> -   struct pipe_transfer *transfer;
>>> -   struct pipe_box box = { };
>>> -   uint8_t *src, *dst;
>>> +   unsigned i, j;
>>> +   unsigned width, height;
>>>views = buf->get_sampler_view_planes(buf);
>>>   -   dst = output->pBuffer;
>>> -
>>> -   box.width = def->nFrameWidth;
>>> -   box.height = def->nFrameHeight;
>>> -   box.depth = 1;
>>> -
>>> -   src = priv->pipe->transfer_map(priv->pipe, views[0]->texture, 0,
>>> -  PIPE_TRANSFER_READ, , );
>>> -   util_copy_rect(dst, views[0]->texture->format, def->nStride, 0, 0,
>>> -  box.width, box.height, src, transfer->stride, 0, 0);
>>> -   pipe_transfer_unmap(priv->pipe, transfer);
>>> -
>>> -   dst = ((uint8_t*)output->pBuffer) + (def->nStride * box.height);
>>> -
>>> -   box.width = def->nFrameWidth / 2;
>>> -   box.height = def->nFrameHeight / 2;
>>> -
>>> -   src = priv->pipe->transfer_map(priv->pipe, views[1]->texture, 0,
>>> -  PIPE_TRANSFER_READ, , );
>>> -   util_copy_rect(dst, views[1]->texture->format, def->nStride, 0, 0,
>>> -  box.width, box.height, src, transfer->stride, 0, 0);
>>> -   pipe_transfer_unmap(priv->pipe, transfer);
>>> +   for (i = 0; i < 2 /* NV12 */; i++) {
>>> +  if (!views[i]) continue;
>>> +  width = buf->width;
>>> +  height = buf->height;
>>> +  vl_video_buffer_adjust_size(, , i, buf->interlaced,
>>> buf->chroma_format);
>>> +  for (j = 0; j < views[i]->texture->array_size; ++j) {
>>> + struct pipe_box box = {0, 0, j, width, height, 1};
>>> + struct pipe_transfer *transfer;
>>> + uint8_t *map, *dst;
>>> + map = priv->pipe->transfer_map(priv->pipe, views[i]->texture,
>>> 0,
>>> +  PIPE_TRANSFER_READ, , );
>>> + if (!map)
>>> +return;
>>> +
>>> + dst = ((uint8_t*)output->pBuffer + output->nOffset) + j *
>>> def->nStride + i * buf->width * buf->height;
>>> + util_copy_rect(dst,
>>> +views[i]->texture->format,
>>> +def->nStride * views[i]->texture->array_size, 0, 0,
>>> +box.width, box.height, map, transfer->stride, 0, 0);
>>> +
>>> + pipe_transfer_unmap(priv->pipe, transfer);
>>> +  }
>>> +   }
>>>   }
>>> static void vid_dec_FrameDecoded(OMX_COMPONENTTYPE *comp,
>>> OMX_BUFFERHEADERTYPE* input,
>>>
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] st/omx: add support for nouveau / interlaced

[Julien Isorce]

Hi Leo,

Sorry for the inconvenience, could you let me know how to reproduce the
problem ?
I have been playing with some gst pipelines and they all work but I can
only test with nouveau driver.

Cheers
Julien


On 27 June 2016 at 21:35, Leo Liu <leo@amd.com> wrote:

> This patch break omx decode to file, it got seg fault. Will take look
> further.
>
> Regards,
> Leo
>
>
>
> On 06/27/2016 04:16 AM, Julien Isorce wrote:
>
>> Signed-off-by: Julien Isorce <j.iso...@samsung.com>
>> ---
>>   src/gallium/state_trackers/omx/vid_dec.c | 51
>> 
>>   1 file changed, 26 insertions(+), 25 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/omx/vid_dec.c
>> b/src/gallium/state_trackers/omx/vid_dec.c
>> index 564ca2f..85ffb88 100644
>> --- a/src/gallium/state_trackers/omx/vid_dec.c
>> +++ b/src/gallium/state_trackers/omx/vid_dec.c
>> @@ -48,6 +48,7 @@
>>   #include "pipe/p_video_codec.h"
>>   #include "util/u_memory.h"
>>   #include "util/u_surface.h"
>> +#include "vl/vl_video_buffer.h"
>>   #include "vl/vl_vlc.h"
>> #include "entrypoint.h"
>> @@ -515,34 +516,34 @@ static void vid_dec_FillOutput(vid_dec_PrivateType
>> *priv, struct pipe_video_buff
>>  OMX_VIDEO_PORTDEFINITIONTYPE *def = >sPortParam.format.video;
>>struct pipe_sampler_view **views;
>> -   struct pipe_transfer *transfer;
>> -   struct pipe_box box = { };
>> -   uint8_t *src, *dst;
>> +   unsigned i, j;
>> +   unsigned width, height;
>>views = buf->get_sampler_view_planes(buf);
>>   -   dst = output->pBuffer;
>> -
>> -   box.width = def->nFrameWidth;
>> -   box.height = def->nFrameHeight;
>> -   box.depth = 1;
>> -
>> -   src = priv->pipe->transfer_map(priv->pipe, views[0]->texture, 0,
>> -  PIPE_TRANSFER_READ, , );
>> -   util_copy_rect(dst, views[0]->texture->format, def->nStride, 0, 0,
>> -  box.width, box.height, src, transfer->stride, 0, 0);
>> -   pipe_transfer_unmap(priv->pipe, transfer);
>> -
>> -   dst = ((uint8_t*)output->pBuffer) + (def->nStride * box.height);
>> -
>> -   box.width = def->nFrameWidth / 2;
>> -   box.height = def->nFrameHeight / 2;
>> -
>> -   src = priv->pipe->transfer_map(priv->pipe, views[1]->texture, 0,
>> -  PIPE_TRANSFER_READ, , );
>> -   util_copy_rect(dst, views[1]->texture->format, def->nStride, 0, 0,
>> -  box.width, box.height, src, transfer->stride, 0, 0);
>> -   pipe_transfer_unmap(priv->pipe, transfer);
>> +   for (i = 0; i < 2 /* NV12 */; i++) {
>> +  if (!views[i]) continue;
>> +  width = buf->width;
>> +  height = buf->height;
>> +  vl_video_buffer_adjust_size(, , i, buf->interlaced,
>> buf->chroma_format);
>> +  for (j = 0; j < views[i]->texture->array_size; ++j) {
>> + struct pipe_box box = {0, 0, j, width, height, 1};
>> + struct pipe_transfer *transfer;
>> + uint8_t *map, *dst;
>> + map = priv->pipe->transfer_map(priv->pipe, views[i]->texture, 0,
>> +  PIPE_TRANSFER_READ, , );
>> + if (!map)
>> +return;
>> +
>> + dst = ((uint8_t*)output->pBuffer + output->nOffset) + j *
>> def->nStride + i * buf->width * buf->height;
>> + util_copy_rect(dst,
>> +views[i]->texture->format,
>> +def->nStride * views[i]->texture->array_size, 0, 0,
>> +box.width, box.height, map, transfer->stride, 0, 0);
>> +
>> + pipe_transfer_unmap(priv->pipe, transfer);
>> +  }
>> +   }
>>   }
>> static void vid_dec_FrameDecoded(OMX_COMPONENTTYPE *comp,
>> OMX_BUFFERHEADERTYPE* input,
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] st/omx: retrieve preferred interlaced and buffer_formats

[Julien Isorce]

Interlaced can be true for nouveau driver.

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/state_trackers/omx/vid_dec.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/omx/vid_dec.c 
b/src/gallium/state_trackers/omx/vid_dec.c
index 108a460..564ca2f 100644
--- a/src/gallium/state_trackers/omx/vid_dec.c
+++ b/src/gallium/state_trackers/omx/vid_dec.c
@@ -385,16 +385,38 @@ static OMX_ERRORTYPE 
vid_dec_MessageHandler(OMX_COMPONENTTYPE* comp, internalReq
 void vid_dec_NeedTarget(vid_dec_PrivateType *priv)
 {
struct pipe_video_buffer templat = {};
+   struct vl_screen *omx_screen;
+   struct pipe_screen *pscreen;
omx_base_video_PortType *port;
 
+   omx_screen = priv->screen;
port = (omx_base_video_PortType 
*)priv->ports[OMX_BASE_FILTER_INPUTPORT_INDEX];
 
+   assert(omx_screen);
+   assert(port);
+
+   pscreen = omx_screen->pscreen;
+
+   assert(pscreen);
+
if (!priv->target) {
-  templat.buffer_format = PIPE_FORMAT_NV12;
+  memset(, 0, sizeof(templat));
+
   templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
   templat.width = port->sPortParam.format.video.nFrameWidth;
   templat.height = port->sPortParam.format.video.nFrameHeight;
-  templat.interlaced = false;
+  templat.buffer_format = pscreen->get_video_param(
+pscreen,
+PIPE_VIDEO_PROFILE_UNKNOWN,
+PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
+PIPE_VIDEO_CAP_PREFERED_FORMAT
+  );
+  templat.interlaced = pscreen->get_video_param(
+  pscreen,
+  PIPE_VIDEO_PROFILE_UNKNOWN,
+  PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
+  PIPE_VIDEO_CAP_PREFERS_INTERLACED
+  );
   priv->target = priv->pipe->create_video_buffer(priv->pipe, );
}
 }
-- 
1.9.1

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

[Mesa-dev] [PATCH 2/3] st/omx: add support for nouveau / interlaced

[Julien Isorce]

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/state_trackers/omx/vid_dec.c | 51 
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/src/gallium/state_trackers/omx/vid_dec.c 
b/src/gallium/state_trackers/omx/vid_dec.c
index 564ca2f..85ffb88 100644
--- a/src/gallium/state_trackers/omx/vid_dec.c
+++ b/src/gallium/state_trackers/omx/vid_dec.c
@@ -48,6 +48,7 @@
 #include "pipe/p_video_codec.h"
 #include "util/u_memory.h"
 #include "util/u_surface.h"
+#include "vl/vl_video_buffer.h"
 #include "vl/vl_vlc.h"
 
 #include "entrypoint.h"
@@ -515,34 +516,34 @@ static void vid_dec_FillOutput(vid_dec_PrivateType *priv, 
struct pipe_video_buff
OMX_VIDEO_PORTDEFINITIONTYPE *def = >sPortParam.format.video;
 
struct pipe_sampler_view **views;
-   struct pipe_transfer *transfer;
-   struct pipe_box box = { };
-   uint8_t *src, *dst;
+   unsigned i, j;
+   unsigned width, height;
 
views = buf->get_sampler_view_planes(buf);
 
-   dst = output->pBuffer;
-
-   box.width = def->nFrameWidth;
-   box.height = def->nFrameHeight;
-   box.depth = 1;
-
-   src = priv->pipe->transfer_map(priv->pipe, views[0]->texture, 0,
-  PIPE_TRANSFER_READ, , );
-   util_copy_rect(dst, views[0]->texture->format, def->nStride, 0, 0,
-  box.width, box.height, src, transfer->stride, 0, 0);
-   pipe_transfer_unmap(priv->pipe, transfer);
-
-   dst = ((uint8_t*)output->pBuffer) + (def->nStride * box.height);
-
-   box.width = def->nFrameWidth / 2;
-   box.height = def->nFrameHeight / 2;
-
-   src = priv->pipe->transfer_map(priv->pipe, views[1]->texture, 0,
-  PIPE_TRANSFER_READ, , );
-   util_copy_rect(dst, views[1]->texture->format, def->nStride, 0, 0,
-  box.width, box.height, src, transfer->stride, 0, 0);
-   pipe_transfer_unmap(priv->pipe, transfer);
+   for (i = 0; i < 2 /* NV12 */; i++) {
+  if (!views[i]) continue;
+  width = buf->width;
+  height = buf->height;
+  vl_video_buffer_adjust_size(, , i, buf->interlaced, 
buf->chroma_format);
+  for (j = 0; j < views[i]->texture->array_size; ++j) {
+ struct pipe_box box = {0, 0, j, width, height, 1};
+ struct pipe_transfer *transfer;
+ uint8_t *map, *dst;
+ map = priv->pipe->transfer_map(priv->pipe, views[i]->texture, 0,
+  PIPE_TRANSFER_READ, , );
+ if (!map)
+return;
+
+ dst = ((uint8_t*)output->pBuffer + output->nOffset) + j * 
def->nStride + i * buf->width * buf->height;
+ util_copy_rect(dst,
+views[i]->texture->format,
+def->nStride * views[i]->texture->array_size, 0, 0,
+box.width, box.height, map, transfer->stride, 0, 0);
+
+ pipe_transfer_unmap(priv->pipe, transfer);
+  }
+   }
 }
 
 static void vid_dec_FrameDecoded(OMX_COMPONENTTYPE *comp, 
OMX_BUFFERHEADERTYPE* input,
-- 
1.9.1

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

[Mesa-dev] [PATCH 3/3] st/omx: count number of slices

[Julien Isorce]

Used by nouveau driver.
Similar patch was done for st/va:
851e7e12aa628d6781b5a3af2f2fc16ee73f435f

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/state_trackers/omx/vid_dec_h264.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/state_trackers/omx/vid_dec_h264.c 
b/src/gallium/state_trackers/omx/vid_dec_h264.c
index 54f244b..bc7feaa 100644
--- a/src/gallium/state_trackers/omx/vid_dec_h264.c
+++ b/src/gallium/state_trackers/omx/vid_dec_h264.c
@@ -128,6 +128,7 @@ static void vid_dec_h264_BeginFrame(vid_dec_PrivateType 
*priv)
 
   priv->codec = priv->pipe->create_video_codec(priv->pipe, );
}
+   priv->picture.h264.slice_count = 0;
priv->codec->begin_frame(priv->codec, priv->target, >picture.base);
priv->frame_started = true;
 }
@@ -961,6 +962,7 @@ static void vid_dec_h264_Decode(vid_dec_PrivateType *priv, 
struct vl_vlc *vlc, u
 
if (priv->slice) {
   unsigned bytes = priv->bytes_left - (vl_vlc_bits_left(vlc) / 8);
+  ++priv->picture.h264.slice_count;
   priv->codec->decode_bitstream(priv->codec, priv->target, 
>picture.base,
 1, >slice, );
   priv->slice = NULL;
@@ -1018,6 +1020,7 @@ static void vid_dec_h264_Decode(vid_dec_PrivateType 
*priv, struct vl_vlc *vlc, u
 
   vid_dec_h264_BeginFrame(priv);
 
+  ++priv->picture.h264.slice_count;
   priv->codec->decode_bitstream(priv->codec, priv->target, 
>picture.base,
 1, , );
}
-- 
1.9.1

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

[Mesa-dev] [PATCH 0/3] st/omx: add initial support for nouveau

[Julien Isorce]

3 patches I made in last january to allow running st/omx with
the nouveau video driver. But currently the video is full of
blockiness because nouveau driver requires manual reference
frames handling. Which is not the case for AMD hardware.
At least these patches avoid to crash directly.

Tested with Bellagio library on Desktop with gstomxh264dec plugin.

Julien Isorce (3):
  st/omx: retrieve preferred interlaced and buffer_formats
  st/omx: add support for nouveau / interlaced
  st/omx: count number of slices

 src/gallium/state_trackers/omx/vid_dec.c  | 77 +--
 src/gallium/state_trackers/omx/vid_dec_h264.c |  3 ++
 2 files changed, 53 insertions(+), 27 deletions(-)

-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] st/va: Check NULL pointer

[Julien Isorce]

Thx for the patch:
Reviewed-by: Julien Isorce <j.iso...@samsung.com>

I'll push it today.

On 26 June 2016 at 08:02, Gurkirpal Singh <gurkirpal...@gmail.com> wrote:

> Call to handle_table_get in vlVaDestroySurfaces can
> return NULL on failure.
>
> CID: 1243522
>
> Signed-off-by: Gurkirpal Singh <gurkirpal...@gmail.com>
> ---
>  src/gallium/state_trackers/va/surface.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/state_trackers/va/surface.c
> b/src/gallium/state_trackers/va/surface.c
> index 5efb893..3e74353 100644
> --- a/src/gallium/state_trackers/va/surface.c
> +++ b/src/gallium/state_trackers/va/surface.c
> @@ -71,6 +71,10 @@ vlVaDestroySurfaces(VADriverContextP ctx, VASurfaceID
> *surface_list, int num_sur
> pipe_mutex_lock(drv->mutex);
> for (i = 0; i < num_surfaces; ++i) {
>vlVaSurface *surf = handle_table_get(drv->htab, surface_list[i]);
> +  if (!surf) {
> + pipe_mutex_unlock(drv->mutex);
> + return VA_STATUS_ERROR_INVALID_SURFACE;
> +  }
>if (surf->buffer)
>   surf->buffer->destroy(surf->buffer);
>util_dynarray_fini(>subpics);
> --
> 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 5/5] st/va: enable h264 VAAPI encode

[Julien Isorce]

On 15 June 2016 at 14:07, Christian König  wrote:

> Please split that up into multiple parts. E.g. adding the config
> structure, new image format support etc..
>
> Julien, can you take a look as well if you have time and work a bit with
> Boyuan to get this cleaned up?
>

Hi,
I'll be happy to do that, I can find some time next week I think.
Cheers
Julien


>
> Thanks in advance,
> Christian.
>
>
> Am 14.06.2016 um 22:14 schrieb Boyuan Zhang:
>
>> Signed-off-by: Boyuan Zhang 
>> ---
>>   src/gallium/state_trackers/va/buffer.c |   6 ++
>>   src/gallium/state_trackers/va/config.c | 104 +++---
>>   src/gallium/state_trackers/va/context.c|  72 -
>>   src/gallium/state_trackers/va/image.c  | 126 +++---
>>   src/gallium/state_trackers/va/picture.c| 165
>> -
>>   src/gallium/state_trackers/va/surface.c|  16 ++-
>>   src/gallium/state_trackers/va/va_private.h |   9 ++
>>   7 files changed, 441 insertions(+), 57 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/va/buffer.c
>> b/src/gallium/state_trackers/va/buffer.c
>> index 7d3167b..dfcebbe 100644
>> --- a/src/gallium/state_trackers/va/buffer.c
>> +++ b/src/gallium/state_trackers/va/buffer.c
>> @@ -133,6 +133,12 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID
>> buf_id, void **pbuff)
>> if (!buf->derived_surface.transfer || !*pbuff)
>>return VA_STATUS_ERROR_INVALID_BUFFER;
>>   +  if (buf->type == VAEncCodedBufferType) {
>> + ((VACodedBufferSegment*)buf->data)->buf = *pbuff;
>> + ((VACodedBufferSegment*)buf->data)->size = buf->coded_size;
>> + ((VACodedBufferSegment*)buf->data)->next = NULL;
>> + *pbuff = buf->data;
>> +  }
>>  } else {
>> pipe_mutex_unlock(drv->mutex);
>> *pbuff = buf->data;
>> diff --git a/src/gallium/state_trackers/va/config.c
>> b/src/gallium/state_trackers/va/config.c
>> index 9ca0aa8..04d214d 100644
>> --- a/src/gallium/state_trackers/va/config.c
>> +++ b/src/gallium/state_trackers/va/config.c
>> @@ -34,6 +34,8 @@
>> #include "va_private.h"
>>   +#include "util/u_handle_table.h"
>> +
>>   DEBUG_GET_ONCE_BOOL_OPTION(mpeg4, "VAAPI_MPEG4_ENABLED", false)
>> VAStatus
>> @@ -72,6 +74,7 @@ vlVaQueryConfigEntrypoints(VADriverContextP ctx,
>> VAProfile profile,
>>   {
>>  struct pipe_screen *pscreen;
>>  enum pipe_video_profile p;
>> +   int va_status = VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
>>if (!ctx)
>> return VA_STATUS_ERROR_INVALID_CONTEXT;
>> @@ -88,12 +91,18 @@ vlVaQueryConfigEntrypoints(VADriverContextP ctx,
>> VAProfile profile,
>> return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
>>pscreen = VL_VA_PSCREEN(ctx);
>> -   if (!pscreen->get_video_param(pscreen, p,
>> PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_SUPPORTED))
>> -  return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
>> -
>> -   entrypoint_list[(*num_entrypoints)++] = VAEntrypointVLD;
>> +   if (pscreen->get_video_param(pscreen, p,
>> PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_SUPPORTED)) {
>> +  entrypoint_list[(*num_entrypoints)++] = VAEntrypointVLD;
>> +  va_status = VA_STATUS_SUCCESS;
>> +   }
>> +   if (pscreen->get_video_param(pscreen, p,
>> PIPE_VIDEO_ENTRYPOINT_ENCODE, PIPE_VIDEO_CAP_SUPPORTED) &&
>> +   p == PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) {
>> +  entrypoint_list[(*num_entrypoints)++] = VAEntrypointEncSlice;
>> +  entrypoint_list[(*num_entrypoints)++] = VAEntrypointEncPicture;
>> +  va_status = VA_STATUS_SUCCESS;
>> +   }
>>   -   return VA_STATUS_SUCCESS;
>> +   return va_status;
>>   }
>> VAStatus
>> @@ -112,7 +121,7 @@ vlVaGetConfigAttributes(VADriverContextP ctx,
>> VAProfile profile, VAEntrypoint en
>>value = VA_RT_FORMAT_YUV420;
>>break;
>> case VAConfigAttribRateControl:
>> - value = VA_RC_NONE;
>> + value = VA_RC_CQP | VA_RC_CBR;
>>break;
>> default:
>>value = VA_ATTRIB_NOT_SUPPORTED;
>> @@ -128,14 +137,27 @@ VAStatus
>>   vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint
>> entrypoint,
>>VAConfigAttrib *attrib_list, int num_attribs,
>> VAConfigID *config_id)
>>   {
>> +   vlVaDriver *drv;
>> +   vlVaConfig *config;
>>  struct pipe_screen *pscreen;
>>  enum pipe_video_profile p;
>>if (!ctx)
>> return VA_STATUS_ERROR_INVALID_CONTEXT;
>>   +   drv = VL_VA_DRIVER(ctx);
>> +
>> +   if (!drv)
>> +  return VA_STATUS_ERROR_INVALID_CONTEXT;
>> +
>> +   config = CALLOC(1, sizeof(vlVaConfig));
>> +   if (!config)
>> +  return VA_STATUS_ERROR_ALLOCATION_FAILED;
>> +
>>  if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc)
>> {
>> -  *config_id = PIPE_VIDEO_PROFILE_UNKNOWN;
>> +  config->entrypoint = VAEntrypointVideoProc;
>> +  config->profile = PIPE_VIDEO_PROFILE_UNKNOWN;
>> +  

Re: [Mesa-dev] [PATCH] st/va: hardlink driver instances to gallium_drv_video.so

[Julien Isorce]

Hi,

It seems this patch has been pushed recently. This is causing me problems
on a multi gpu configuration.
It is a laptop with intel and nvidia, graphic hardwares.

1: intel vaapi driver:
vainfo

2: st/va,nouveau:
DRI_PRIME=1 LIBVA_DRIVER_NAME=gallium vainfo

with that patch 0c0f841e5de27d01312f8857641668ca439b1ab1 " st/va: hardlink
driver instances to gallium_drv_video.so"
the case 2 does not work anymore. Ah I just realized that it does work by
setting:  LIBVA_DRIVER_NAME=nouveau

Is it the expected behavior ?

Cheers
Julien




On 21 April 2016 at 14:20, Emil Velikov  wrote:

> Hi Stefan,
>
> On 21 April 2016 at 14:05, Stefan Dirsch  wrote:
> > From: Jimmy Berry 
> >
> > Removes the need to set LIBVA_DRIVER_NAME=gallium for supported targets
> and is
> > consistent with vdpau and general gallium drivers.
> There are two options here afaict:
>  - Use an updated libva which already handles "gallium_drv.so"
>  - Chip-in on the following topic [1] and working from there.
>
> Personally I'd opt for the former, because (as you know) hardlinking
> things is a bit nasty.
>
> Speaking of which you guys are the only ones building multiple drivers
> at once (thus a megablob is created) yet still shiping the identical
> file as separate drivers.
>
> Suggestion - you can merge the separate packages into one or build
> mesa separate times to produce binaries similar to before megadriver.
>
> Emil
>
> [1] https://patchwork.freedesktop.org/patch/58540/
> ___
> 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 v3] st/va: ensure linear memory for dmabuf

[Julien Isorce]

In order to do zero-copy between two different devices
the memory should not be tiled.

Tested with GStreamer on a laptop that has 2 GPUs:
1- gstvaapidecode:
   HW decoding and dmabuf export with nouveau driver on Nvidia GPU.
2- glimagesink:
   EGLImage imports dmabuf on Intel GPU.

TEST: DRI_PRIME=1 gst-launch vaapidecodebin ! glimagesink

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/auxiliary/vl/vl_video_buffer.c | 3 +++
 src/gallium/include/pipe/p_video_codec.h   | 1 +
 src/gallium/state_trackers/va/surface.c| 8 
 3 files changed, 12 insertions(+)

diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c 
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index 4a68ac1..b383ad2 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.c
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
@@ -253,6 +253,9 @@ vl_video_buffer_template(struct pipe_resource *templ,
templ->bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET;
templ->usage = usage;
 
+   if (tmpl->bind)
+  templ->bind |= tmpl->bind;
+
vl_video_buffer_adjust_size(>width0, >height0, plane,
tmpl->chroma_format, false);
 }
diff --git a/src/gallium/include/pipe/p_video_codec.h 
b/src/gallium/include/pipe/p_video_codec.h
index b5575ab..b4b2b9c 100644
--- a/src/gallium/include/pipe/p_video_codec.h
+++ b/src/gallium/include/pipe/p_video_codec.h
@@ -126,6 +126,7 @@ struct pipe_video_buffer
unsigned width;
unsigned height;
bool interlaced;
+   unsigned bind;
 
/**
 * destroy this video buffer
diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 8a6a397..5efb893 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -621,6 +621,14 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
 
   switch (memory_type) {
   case VA_SURFACE_ATTRIB_MEM_TYPE_VA:
+ /* The application will clear the TILING flag when the surface is
+  * intended to be exported as dmabuf. Adding shared flag because not
+  * null memory_attibute means VASurfaceAttribExternalBuffers is used.
+  */
+ if (memory_attibute &&
+ !(memory_attibute->flags & VA_SURFACE_EXTBUF_DESC_ENABLE_TILING))
+templat.bind = PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
+
  surf->buffer = drv->pipe->create_video_buffer(drv->pipe, );
  if (!surf->buffer) {
 FREE(surf);
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH v2] st/va: ensure linear memory for dmabuf

[Julien Isorce]

To go back to "add a bind flag to struct pipe_video_buffer instead ", the
alternative is to bring back the first version
of the patch but according to the first review, it was duplication of bind
flag between pipe_video_buffer
and pipe_resource so it would require quite of big of refactoring unless I
miss understood the comment.

>> I obviously have missed that discussion, but yes that is exactly the way
we should go. The duplication is unproblematic as far as I can see.

The v1 patch and discussion is here:
https://patchwork.freedesktop.org/patch/66382/
In that v1 should I just replace the specific "bool disable_tiling" by a
generic bind flag ?

On 8 June 2016 at 14:07, Christian König <deathsim...@vodafone.de> wrote:

> Am 08.06.2016 um 14:20 schrieb Julien Isorce:
>
>
>
> On 8 June 2016 at 09:16, Christian König <deathsim...@vodafone.de> wrote:
>
>> Am 02.06.2016 um 16:00 schrieb Julien Isorce:
>>
>>> In order to do zero-copy between two different devices
>>> the memory should not be tiled.
>>>
>>> This is currently no way to set pipe_resource template's flag
>>> from pipe_video_buffer template. So disabled_tiling is added.
>>>
>>> Choosed "disable" prefix so that CALLOC keeps tiling enabled
>>> by default.
>>>
>>> Tested with GStreamer on a laptop that has 2 GPUs:
>>> 1- gstvaapidecode:
>>> HW decoding and dmabuf export with nouveau driver on Nvidia GPU.
>>> 2- glimagesink:
>>> EGLImage imports dmabuf on Intel GPU.
>>>
>>> Note that tiling is working if 1 and 2 are done on the same GPU.
>>> So it is up to the application to set or not the flag:
>>> VA_SURFACE_EXTBUF_DESC_ENABLE_TILING
>>>
>>> Signed-off-by: Julien Isorce < <j.iso...@samsung.com>
>>> j.iso...@samsung.com>
>>>
>>
>>
> Thx for the review.
>
>
>> NAK, it won't be possible to use the resulting video buffer with hardware
>> decoding on AMD hardware.
>>
>
> But I restrict to these format:
>
> +case VA_FOURCC_RGBA:
> +case VA_FOURCC_RGBX:
> +case VA_FOURCC_BGRA:
> +case VA_FOURCC_BGRX:
>
> So if the vaapi user request a linear layout, it will fail if not one of
> these formats. So basically for now it requires vpp.
>
>
> Yeah, ok that should work for now but is clearly not a good idea.
>
>
>
>>
>> Please add a bind flag to struct pipe_video_buffer instead so that we can
>> specify if linear layout is requested or not.
>>
>
> Do you mean that resource = pscreen->resource_create(pscreen, ) does
> not honor the bind flag of the template.
> Maybe I can just checked if it was effective after that call, i.e.
> checking presence of PIPE_BIND_LINEAR in
> resources[0]->bind.
>
>
> No, for resource_create() the flag should be honored. But we shouldn't be
> using resource_create() to create the different planes of video buffers if
> possible. We should use create_video_buffer() on the pipe context if
> possible.
>
>
>
>>
>> This way the hardware driver can still reject the request if this would
>> result in a surface which can't be decoded to.
>>
>
> For now it requires vpp since I explicitly restricted linear layout
> request to the rgbs format above. The reason behind is
> that vaapi is limited to export 1 fd per surface. Problem is that for at
> least nouveau, it uses 1 pipe resource per plane, and
> NV12 has 2 planes.
>
> In the spec the problem comes from the fact that a VAImage has only one
> VABufferID. It would require to define
> a new VABufferType which represents an array of VAImageBufferType,
> something like that.
>
>
> Yeah, I know that is one of the many deficits VA-API unfortunately has. It
> should work with the Radeon implementation, but only because UVD requires
> both planes to be in the same buffer object.
>
>
>
> To go back to "add a bind flag to struct pipe_video_buffer instead ", the
> alternative is to bring back the first version
> of the patch but according to the first review, it was duplication of bind
> flag between pipe_video_buffer
> and pipe_resource so it would require quite of big of refactoring unless I
> miss understood the comment.
>
>
> I obviously have missed that discussion, but yes that is exactly the way
> we should go. The duplication is unproblematic as far as I can see.
>
> Also in vdpau, the function vlVdpOutputSurfaceCreate is using
> PIPE_BIND_LINEAR flag and resource_create call,
> like in the v2 of my patch.
>
>
> Yeah, but that isn't a video buffer you try to c

Re: [Mesa-dev] [PATCH v2] st/va: ensure linear memory for dmabuf

[Julien Isorce]

On 8 June 2016 at 09:16, Christian König <deathsim...@vodafone.de> wrote:

> Am 02.06.2016 um 16:00 schrieb Julien Isorce:
>
>> In order to do zero-copy between two different devices
>> the memory should not be tiled.
>>
>> This is currently no way to set pipe_resource template's flag
>> from pipe_video_buffer template. So disabled_tiling is added.
>>
>> Choosed "disable" prefix so that CALLOC keeps tiling enabled
>> by default.
>>
>> Tested with GStreamer on a laptop that has 2 GPUs:
>> 1- gstvaapidecode:
>> HW decoding and dmabuf export with nouveau driver on Nvidia GPU.
>> 2- glimagesink:
>> EGLImage imports dmabuf on Intel GPU.
>>
>> Note that tiling is working if 1 and 2 are done on the same GPU.
>> So it is up to the application to set or not the flag:
>> VA_SURFACE_EXTBUF_DESC_ENABLE_TILING
>>
>> Signed-off-by: Julien Isorce <j.iso...@samsung.com>
>>
>
>
Thx for the review.


> NAK, it won't be possible to use the resulting video buffer with hardware
> decoding on AMD hardware.
>

But I restrict to these format:

+case VA_FOURCC_RGBA:
+case VA_FOURCC_RGBX:
+case VA_FOURCC_BGRA:
+case VA_FOURCC_BGRX:

So if the vaapi user request a linear layout, it will fail if not one of
these formats. So basically for now it requires vpp.


>
> Please add a bind flag to struct pipe_video_buffer instead so that we can
> specify if linear layout is requested or not.
>

Do you mean that resource = pscreen->resource_create(pscreen, ) does
not honor the bind flag of the template.
Maybe I can just checked if it was effective after that call, i.e. checking
presence of PIPE_BIND_LINEAR in
resources[0]->bind.


>
> This way the hardware driver can still reject the request if this would
> result in a surface which can't be decoded to.
>

For now it requires vpp since I explicitly restricted linear layout request
to the rgbs format above. The reason behind is
that vaapi is limited to export 1 fd per surface. Problem is that for at
least nouveau, it uses 1 pipe resource per plane, and
NV12 has 2 planes.

In the spec the problem comes from the fact that a VAImage has only one
VABufferID. It would require to define
a new VABufferType which represents an array of VAImageBufferType,
something like that.


To go back to "add a bind flag to struct pipe_video_buffer instead ", the
alternative is to bring back the first version
of the patch but according to the first review, it was duplication of bind
flag between pipe_video_buffer
and pipe_resource so it would require quite of big of refactoring unless I
miss understood the comment.
Also in vdpau, the function vlVdpOutputSurfaceCreate is using
PIPE_BIND_LINEAR flag and resource_create call,
like in the v2 of my patch.

Not sure if I replied to your concerns, let me know.

Thx
Julien


>
> Regards,
> Christian.
>
>
> ---
>>   src/gallium/state_trackers/va/surface.c | 60
>> -
>>   1 file changed, 59 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/state_trackers/va/surface.c
>> b/src/gallium/state_trackers/va/surface.c
>> index 8a6a397..b04ced4 100644
>> --- a/src/gallium/state_trackers/va/surface.c
>> +++ b/src/gallium/state_trackers/va/surface.c
>> @@ -507,7 +507,9 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned
>> int format,
>>  int i;
>>  int memory_type;
>>  int expected_fourcc;
>> +   int linear_layout;
>>  VAStatus vaStatus;
>> +   const enum pipe_format *resource_formats;
>>if (!ctx)
>> return VA_STATUS_ERROR_INVALID_CONTEXT;
>> @@ -529,6 +531,7 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned
>> int format,
>>  memory_attibute = NULL;
>>  memory_type = VA_SURFACE_ATTRIB_MEM_TYPE_VA;
>>  expected_fourcc = 0;
>> +   resource_formats = NULL;
>>for (i = 0; i < num_attribs && attrib_list; i++) {
>> if ((attrib_list[i].type == VASurfaceAttribPixelFormat) &&
>> @@ -569,8 +572,27 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned
>> int format,
>> return VA_STATUS_ERROR_UNSUPPORTED_RT_FORMAT;
>>  }
>>   +   /* The application will clear the TILING flag when the surface is
>> +* intended to be exported as dmabuf. */
>> +   linear_layout = memory_attibute &&
>> +  !(memory_attibute->flags & VA_SURFACE_EXTBUF_DESC_ENABLE_TILING);
>> +
>>  switch (memory_type) {
>>  case VA_SURFACE_ATTRIB_MEM_TYPE_VA:
>> +  if (linear_layout) {
>> + switch (expected_fourcc) {
>> +case

Re: [Mesa-dev] [PATCH] st/va: it is valid to release the VABuffer of an exported resource

[Julien Isorce]

Hi Christian,

Thx for the review.

pipe_resource_reference(, NULL)  will decrement reference counting
(p_atomic_dec  res->count). But the va surface still has the initial
reference since it created that resource.
So calling vaDestroyImage on a derived image will call VaDestroyBuffer but
the decrementation wont't reach 0.

It is just wrong that vlVaDestroyBuffer relies on the export_refcount flag.
I also compared with vaapi intel driver and they have same flag and it is
not present in their vaDestroyBuffer.

Cheers
Julien


On 8 June 2016 at 09:22, Christian König <deathsim...@vodafone.de> wrote:

> Am 02.06.2016 um 16:03 schrieb Julien Isorce:
>
>> Signed-off-by: Julien Isorce <j.iso...@samsung.com>
>>
>
> Actually I'm not sure if that is correct.
>
> If you release the VABuffer of an exported resource you won't be able to
> properly close the handle with vlVaReleaseBufferHandle().
>
> On the other hand the semantic VA requires for vlVaAcquireBufferHandle()
> and vlVaReleaseBufferHandle() is complete nonsense for DMA-buf handles.
>
> Christian.
>
> ---
>>   src/gallium/state_trackers/va/buffer.c | 8 +---
>>   1 file changed, 1 insertion(+), 7 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/va/buffer.c
>> b/src/gallium/state_trackers/va/buffer.c
>> index 2fd8661..7d3167b 100644
>> --- a/src/gallium/state_trackers/va/buffer.c
>> +++ b/src/gallium/state_trackers/va/buffer.c
>> @@ -192,14 +192,8 @@ vlVaDestroyBuffer(VADriverContextP ctx, VABufferID
>> buf_id)
>> return VA_STATUS_ERROR_INVALID_BUFFER;
>>  }
>>   -   if (buf->derived_surface.resource) {
>> -  if (buf->export_refcount > 0) {
>> - pipe_mutex_unlock(drv->mutex);
>> - return VA_STATUS_ERROR_INVALID_BUFFER;
>> -  }
>> -
>> +   if (buf->derived_surface.resource)
>> pipe_resource_reference(>derived_surface.resource, NULL);
>> -   }
>>FREE(buf->data);
>>  FREE(buf);
>>
>
> ___
> 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] st/va: use proper temp pipe_video_buffer template

[Julien Isorce]

Instead of changing the format on the existing template
which makes error handling not nice and confuses coverity.

CoverityID: 1337953

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/state_trackers/va/image.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index 92d014c..1b956e3 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -473,19 +473,19 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, 
VAImageID image,
 
if (format != surf->buffer->buffer_format) {
   struct pipe_video_buffer *tmp_buf;
-  enum pipe_format old_surf_format = surf->templat.buffer_format;
+  struct pipe_video_buffer templat = surf->templat;
 
-  surf->templat.buffer_format = format;
-  tmp_buf = drv->pipe->create_video_buffer(drv->pipe, >templat);
+  templat.buffer_format = format;
+  tmp_buf = drv->pipe->create_video_buffer(drv->pipe, );
 
   if (!tmp_buf) {
- surf->templat.buffer_format = old_surf_format;
  pipe_mutex_unlock(drv->mutex);
  return VA_STATUS_ERROR_ALLOCATION_FAILED;
   }
 
   surf->buffer->destroy(surf->buffer);
   surf->buffer = tmp_buf;
+  surf->templat.buffer_format = format;
}
 
views = surf->buffer->get_sampler_view_planes(surf->buffer);
-- 
1.9.1

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

[Mesa-dev] [PATCH] st/va: it is valid to release the VABuffer of an exported resource

[Julien Isorce]

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/state_trackers/va/buffer.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/src/gallium/state_trackers/va/buffer.c 
b/src/gallium/state_trackers/va/buffer.c
index 2fd8661..7d3167b 100644
--- a/src/gallium/state_trackers/va/buffer.c
+++ b/src/gallium/state_trackers/va/buffer.c
@@ -192,14 +192,8 @@ vlVaDestroyBuffer(VADriverContextP ctx, VABufferID buf_id)
   return VA_STATUS_ERROR_INVALID_BUFFER;
}
 
-   if (buf->derived_surface.resource) {
-  if (buf->export_refcount > 0) {
- pipe_mutex_unlock(drv->mutex);
- return VA_STATUS_ERROR_INVALID_BUFFER;
-  }
-
+   if (buf->derived_surface.resource)
   pipe_resource_reference(>derived_surface.resource, NULL);
-   }
 
FREE(buf->data);
FREE(buf);
-- 
1.9.1

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

[Mesa-dev] [PATCH v2] st/va: ensure linear memory for dmabuf

[Julien Isorce]

In order to do zero-copy between two different devices
the memory should not be tiled.

This is currently no way to set pipe_resource template's flag
from pipe_video_buffer template. So disabled_tiling is added.

Choosed "disable" prefix so that CALLOC keeps tiling enabled
by default.

Tested with GStreamer on a laptop that has 2 GPUs:
1- gstvaapidecode:
   HW decoding and dmabuf export with nouveau driver on Nvidia GPU.
2- glimagesink:
   EGLImage imports dmabuf on Intel GPU.

Note that tiling is working if 1 and 2 are done on the same GPU.
So it is up to the application to set or not the flag:
VA_SURFACE_EXTBUF_DESC_ENABLE_TILING

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/state_trackers/va/surface.c | 60 -
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 8a6a397..b04ced4 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -507,7 +507,9 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
int i;
int memory_type;
int expected_fourcc;
+   int linear_layout;
VAStatus vaStatus;
+   const enum pipe_format *resource_formats;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
@@ -529,6 +531,7 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
memory_attibute = NULL;
memory_type = VA_SURFACE_ATTRIB_MEM_TYPE_VA;
expected_fourcc = 0;
+   resource_formats = NULL;
 
for (i = 0; i < num_attribs && attrib_list; i++) {
   if ((attrib_list[i].type == VASurfaceAttribPixelFormat) &&
@@ -569,8 +572,27 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
   return VA_STATUS_ERROR_UNSUPPORTED_RT_FORMAT;
}
 
+   /* The application will clear the TILING flag when the surface is
+* intended to be exported as dmabuf. */
+   linear_layout = memory_attibute &&
+  !(memory_attibute->flags & VA_SURFACE_EXTBUF_DESC_ENABLE_TILING);
+
switch (memory_type) {
case VA_SURFACE_ATTRIB_MEM_TYPE_VA:
+  if (linear_layout) {
+ switch (expected_fourcc) {
+case VA_FOURCC_RGBA:
+case VA_FOURCC_RGBX:
+case VA_FOURCC_BGRA:
+case VA_FOURCC_BGRX:
+   if (memory_attibute->num_planes != 1)
+  return VA_STATUS_ERROR_INVALID_PARAMETER;
+   break;
+default:
+   return VA_STATUS_ERROR_INVALID_PARAMETER;
+ }
+  }
+
   break;
case VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME:
   if (!memory_attibute)
@@ -587,6 +609,13 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
if (expected_fourcc) {
   templat.buffer_format = VaFourccToPipeFormat(expected_fourcc);
   templat.interlaced = 0;
+
+  if (linear_layout) {
+ resource_formats = vl_video_buffer_formats(pscreen,
+templat.buffer_format);
+ if (!resource_formats)
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+  }
} else {
   templat.buffer_format = pscreen->get_video_param
 (
@@ -621,7 +650,36 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
 
   switch (memory_type) {
   case VA_SURFACE_ATTRIB_MEM_TYPE_VA:
- surf->buffer = drv->pipe->create_video_buffer(drv->pipe, );
+ if (linear_layout) {
+struct pipe_resource resource_template;
+struct pipe_resource *resources[VL_NUM_COMPONENTS];
+int depth = 1;
+int array_size = 1;
+
+memset(resources, 0, sizeof(resources));
+
+assert(resource_formats);
+vl_video_buffer_template(_template, ,
+ resource_formats[0], depth, array_size,
+ PIPE_USAGE_DEFAULT, 0);
+
+/* Shared because VASurfaceAttribExternalBuffers is used. */
+assert(memory_attibute);
+resource_template.bind |= PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
+
+resources[0] = pscreen->resource_create(pscreen,
+_template);
+if (!resources[0]) {
+FREE(surf);
+goto no_res;
+}
+
+surf->buffer = vl_video_buffer_create_ex2(drv->pipe, ,
+  resources);
+ } else {
+surf->buffer = drv->pipe->create_video_buffer(drv->pipe, );
+ }
+
  if (!surf->buffer) {
 FREE(surf);
 goto no_res;
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] st/va: restore old buffer format on error

[Julien Isorce]

no problem, it was actually good, I think that even if current code is
correct, I'll still submit
the new diff for review because it looks better.

On 2 June 2016 at 10:34, Eric Engestrom <eric.engest...@imgtec.com> wrote:

> On Tue, May 31, 2016 at 02:54:06PM +0200, Christian König wrote:
> > On the other hand the original code was correct in the first place.
> >
> > And as Julien noted Coverity tries to restore the template buffer format
> > from a local variable which doesn't exists any more where you wanted to
> add
> > the line.
> >
> > So Coverity creates code which won't compile and needs to be fixed
> instead.
>
> I guess the lesson for me is to not try and fix stuff in code I don't
> understand at all :]
>
> Sorry for wasting your time with this.
>
> Cheers,
>   Eric
>
> >
> > Christian.
> >
> > Am 31.05.2016 um 14:51 schrieb Christian König:
> > > Yeah, that solution looks more correct to me.
> > >
> > > Christian.
> > >
> > > Am 31.05.2016 um 14:44 schrieb Julien Isorce:
> > > > Hi,
> > > > Thx for looking at it but are you sure your diff compiles ?
> > > >
> > > > Can you try this instead:
> > > >
> > > > --- a/src/gallium/state_trackers/va/image.c
> > > > +++ b/src/gallium/state_trackers/va/image.c
> > > > @@ -471,19 +471,19 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID
> > > > surface, VAImageID image,
> > > >
> > > > if (format != surf->buffer->buffer_format) {
> > > >struct pipe_video_buffer *tmp_buf;
> > > > -  enum pipe_format old_surf_format =
> surf->templat.buffer_format;
> > > > +  struct pipe_video_buffer templat = surf->templat;
> > > >
> > > > -  surf->templat.buffer_format = format;
> > > > -  tmp_buf = drv->pipe->create_video_buffer(drv->pipe,
> > > > >templat);
> > > > +  templat.buffer_format = format;
> > > > +  tmp_buf = drv->pipe->create_video_buffer(drv->pipe, );
> > > >
> > > >if (!tmp_buf) {
> > > > - surf->templat.buffer_format = old_surf_format;
> > > >   pipe_mutex_unlock(drv->mutex);
> > > >   return VA_STATUS_ERROR_ALLOCATION_FAILED;
> > > >}
> > > >
> > > >surf->buffer->destroy(surf->buffer);
> > > >surf->buffer = tmp_buf;
> > > > +  surf->templat.buffer_format = format;
> > > > }
> > > >
> > > > Cheers
> > > > Julien
> > > >
> > > >
> > > > On 31 May 2016 at 08:43, Christian König <christian.koe...@amd.com
> > > > <mailto:christian.koe...@amd.com>> wrote:
> > > >
> > > > Am 31.05.2016 um 03:24 schrieb Eric Engestrom:
> > > >
> > > > CoverityID: 1337953
> > > >
> > > > Signed-off-by: Eric Engestrom <e...@engestrom.ch>
> > > > ---
> > > >
> > > > Note that I do not know this code at all; I'm blindly
> > > > following Coverity's advice on this one :]
> > > >
> > > >
> > > > Well and that is completely nonsense. The buffer was already
> > > > reallocated when this error happens and so resetting the template
> > > > to the original value is incorrect and actually rather dangerous.
> > > >
> > > > Why does Coverity things that we should add this? And how can we
> > > > fix this?
> > > >
> > > > Regards,
> > > > Christian.
> > > >
> > > >
> > > > ---
> > > >   src/gallium/state_trackers/va/image.c | 1 +
> > > >   1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/src/gallium/state_trackers/va/image.c
> > > > b/src/gallium/state_trackers/va/image.c
> > > > index 92d014c..8cfe17a 100644
> > > > --- a/src/gallium/state_trackers/va/image.c
> > > > +++ b/src/gallium/state_trackers/va/image.c
> > > > @@ -490,6 +490,7 @@ vlVaPutImage(VADriverContextP ctx,
> > > > VASurfaceID surface, VAImageID image,
> > > >views =
> > > > surf->buffer->get_sampler_view_planes(surf->buffer);
> > > >  if (!views) {
> > > > +  surf->templat.buffer_format = old_surf_format;
> > > > pipe_mutex_unlock(drv->mutex);
> > > > return VA_STATUS_ERROR_OPERATION_FAILED;
> > > >  }
> > > >
> > > >
> > > > ___
> > > > mesa-dev mailing list
> > > > mesa-dev@lists.freedesktop.org
> > > > <mailto: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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: restore old buffer format on error

[Julien Isorce]

Hi,
Thx for looking at it but are you sure your diff compiles ?

Can you try this instead:

--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -471,19 +471,19 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID
surface, VAImageID image,

if (format != surf->buffer->buffer_format) {
   struct pipe_video_buffer *tmp_buf;
-  enum pipe_format old_surf_format = surf->templat.buffer_format;
+  struct pipe_video_buffer templat = surf->templat;

-  surf->templat.buffer_format = format;
-  tmp_buf = drv->pipe->create_video_buffer(drv->pipe, >templat);
+  templat.buffer_format = format;
+  tmp_buf = drv->pipe->create_video_buffer(drv->pipe, );

   if (!tmp_buf) {
- surf->templat.buffer_format = old_surf_format;
  pipe_mutex_unlock(drv->mutex);
  return VA_STATUS_ERROR_ALLOCATION_FAILED;
   }

   surf->buffer->destroy(surf->buffer);
   surf->buffer = tmp_buf;
+  surf->templat.buffer_format = format;
}

Cheers
Julien


On 31 May 2016 at 08:43, Christian König  wrote:

> Am 31.05.2016 um 03:24 schrieb Eric Engestrom:
>
>> CoverityID: 1337953
>>
>> Signed-off-by: Eric Engestrom 
>> ---
>>
>> Note that I do not know this code at all; I'm blindly following
>> Coverity's advice on this one :]
>>
>
> Well and that is completely nonsense. The buffer was already reallocated
> when this error happens and so resetting the template to the original value
> is incorrect and actually rather dangerous.
>
> Why does Coverity things that we should add this? And how can we fix this?
>
> Regards,
> Christian.
>
>
>> ---
>>   src/gallium/state_trackers/va/image.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/src/gallium/state_trackers/va/image.c
>> b/src/gallium/state_trackers/va/image.c
>> index 92d014c..8cfe17a 100644
>> --- a/src/gallium/state_trackers/va/image.c
>> +++ b/src/gallium/state_trackers/va/image.c
>> @@ -490,6 +490,7 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID
>> surface, VAImageID image,
>>views = surf->buffer->get_sampler_view_planes(surf->buffer);
>>  if (!views) {
>> +  surf->templat.buffer_format = old_surf_format;
>> pipe_mutex_unlock(drv->mutex);
>> return VA_STATUS_ERROR_OPERATION_FAILED;
>>  }
>>
>
> ___
> 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] va: check null context in vlVaDestroyContext

[Julien Isorce]

Reviewed-by: Julien Isorce <j.iso...@samsung.com>

I'll push it shortly. Thx

On 12 April 2016 at 23:24, Iurie Salomov <iur...@gmail.com> wrote:

> From: iurie salomov <iur...@gmail.com>
>
> Signed-off-by: Iurie Salomov
> ---
>  src/gallium/state_trackers/va/context.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/state_trackers/va/context.c
> b/src/gallium/state_trackers/va/context.c
> index b25c381..932717d 100644
> --- a/src/gallium/state_trackers/va/context.c
> +++ b/src/gallium/state_trackers/va/context.c
> @@ -283,6 +283,10 @@ vlVaDestroyContext(VADriverContextP ctx, VAContextID
> context_id)
> drv = VL_VA_DRIVER(ctx);
> pipe_mutex_lock(drv->mutex);
> context = handle_table_get(drv->htab, context_id);
> +   if (!context) {
> +  pipe_mutex_unlock(drv->mutex);
> +  return VA_STATUS_ERROR_INVALID_CONTEXT;
> +  }
>
> if (context->decoder) {
>if (u_reduce_video_profile(context->decoder->profile) ==
> --
> 1.9.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] va: check null context in vlVaDestroyContext

[Julien Isorce]

On 12 April 2016 at 14:27, iurie  wrote:

It should be "Firstname Lastname" , click on any commit here
https://cgit.freedesktop.org/mesa/mesa/log/ to compare or just type: git log
It is a common practice for most open source projects and sometimes a
requirement. Not sure if this is strictly required for Mesa.
iurie, do you have any concern about having your full name here or was it
just a mistake ?

---
>  src/gallium/state_trackers/va/context.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/gallium/state_trackers/va/context.c
> b/src/gallium/state_trackers/va/context.c
> index b25c381..77be8de 100644
> --- a/src/gallium/state_trackers/va/context.c
> +++ b/src/gallium/state_trackers/va/context.c
> @@ -283,6 +283,11 @@ vlVaDestroyContext(VADriverContextP ctx, VAContextID
> context_id)
> drv = VL_VA_DRIVER(ctx);
> pipe_mutex_lock(drv->mutex);
> context = handle_table_get(drv->htab, context_id);
> +   if (!context){
> +  pipe_mutex_unlock(drv->mutex);
> +  return VA_STATUS_ERROR_INVALID_CONTEXT;
>

When apply your patch I can see an extra space at the end of
VA_STATUS_ERROR_INVALID_CONTEXT;
Please remove it.

+   }
> +
>
> if (context->decoder) {
>if (u_reduce_video_profile(context->decoder->profile) ==
> --
> 1.9.1
>
> ___
> 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] 0001-va-check-null-context-in-vlVaDestroyContext.patch

[Julien Isorce]

On 11 April 2016 at 22:24, Iurie  wrote:

> From d6a5bbd910dc19d4863dbac8eba5bdf07bd1c3ab Mon Sep 17 00:00:00 2001
> From: GreatMaster 
>

Please put your real name and add signed-off stamp: *git config --global
user*.name "FirstName LastName"
Then run : git commit --amend --reset-author --no-edit -s


> Date: Mon, 11 Apr 2016 21:37:02 +0100
> Subject: [PATCH] va: check null context in vlVaDestroyContext
>
> ---
>  src/gallium/state_trackers/va/context.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/state_trackers/va/context.c
> b/src/gallium/state_trackers/va/context.c
> index b25c381..419b271 100644
> --- a/src/gallium/state_trackers/va/context.c
> +++ b/src/gallium/state_trackers/va/context.c
> @@ -283,6 +283,8 @@ vlVaDestroyContext(VADriverContextP ctx, VAContextID
> context_id)
> drv = VL_VA_DRIVER(ctx);
> pipe_mutex_lock(drv->mutex);
> context = handle_table_get(drv->htab, context_id);
> +if (!context)
> +  return VA_STATUS_ERROR_INVALID_CONTEXT;
>

Change it to 3 spaces indentations and you need to unlock the mutex before
returning.

When submitting new version, append -v2 to git format-patch -1 if git
send-email still failed for you, or change subject to [PATCH v2].


>
> if (context->decoder) {
>if (u_reduce_video_profile(context->decoder->profile) ==
> --
> 1.9.1
>
>
> ___
> 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: avoid dereference after free

[Julien Isorce]

Hi Thomas and Emil, I tested it and pushed. Thx a lot.

On 6 April 2016 at 21:34, Thomas H.P. Andersen  wrote:

>
>
> On Sun, Mar 6, 2016 at 10:08 AM, Thomas H.P. Andersen 
> wrote:
>
>>
>>
>> On Sat, Mar 5, 2016 at 1:30 PM, Emil Velikov 
>> wrote:
>>
>>> Hi Thomas,
>>>
>>> On 5 March 2016 at 12:07, Thomas Hindoe Paaboel Andersen
>>>  wrote:
>>> > ---
>>> >  src/gallium/state_trackers/va/image.c | 4 +++-
>>> >  1 file changed, 3 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/src/gallium/state_trackers/va/image.c
>>> b/src/gallium/state_trackers/va/image.c
>>> > index 2c42a98..92d014c 100644
>>> > --- a/src/gallium/state_trackers/va/image.c
>>> > +++ b/src/gallium/state_trackers/va/image.c
>>> > @@ -280,6 +280,7 @@ vlVaDestroyImage(VADriverContextP ctx, VAImageID
>>> image)
>>> >  {
>>> > vlVaDriver *drv;
>>> > VAImage  *vaimage;
>>> > +   VAStatus status;
>>> >
>>> > if (!ctx)
>>> >return VA_STATUS_ERROR_INVALID_CONTEXT;
>>> > @@ -294,8 +295,9 @@ vlVaDestroyImage(VADriverContextP ctx, VAImageID
>>> image)
>>> >
>>> > handle_table_remove(VL_VA_DRIVER(ctx)->htab, image);
>>> > pipe_mutex_unlock(drv->mutex);
>>> > +   status = vlVaDestroyBuffer(ctx, vaimage->buf);
>>> > FREE(vaimage);
>>> > -   return vlVaDestroyBuffer(ctx, vaimage->buf);
>>> > +   return status;
>>>
>>> Nicely spotted !
>>> Out of curiosity: did you notice this during code inspection or did it
>>> pop up during testing ?
>>>
>>
>> Thanks for the review! I only saw it by inspection. I am just poking
>> around a bit to get to know the code.
>>
>>
>>>
>>> For the patch
>>>
>>> Cc: "11.1 11.2" 
>>> Reviewed-by: Emil Velikov 
>>>
>>> I'll push this in a couple of days unless someone beats me to it.
>>>
>>
> Hi Emil,
>
> Friendly ping :)
>
> ___
> 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] [GSOC] looking for information

[Julien Isorce]

Hi Lurie,

Thx for your interest.

In order to work on this project you would need either a AMD or NVIDIA
graphic hardware. Indeed current st/omx in Gallium, only work with these 2
hardwares and it would be out of scope of the project to add support for
another hardware.

In order to check that your HW decoding setup is working you should install
mpv player and run with option --hwdec=vaapi or --hwdec=vdpau.

Also I would suggest to start building Mesa with option --enable-omx. You
would need to install libomxil-bellagio and build gst-omx. I can help with
that.
Let us know how it goes. I think from that point you would have a better
idea of the required skills to succeed on that project.

Also feel free to reach me on IRC, I am on #dri-devel channel and my
nickname is capOM.

Best regards
Julien


On 23 March 2016 at 13:01, Iurie  wrote:

> hi,
> well, i am not very proficient, so i hope that with this project idea [Switch
> OpenMAX state tracker in Mesa/Gallium to use Tizonia from
> http://www.x.org/wiki/SummerOfCodeIdeas/] to solidify my knowledges.
> i never have contributed to anything. i do not have a blog.
> i am in electronics engineering. i had some classes about operating
> systems(we made a project in c using sockets, threads and processes),
> introduction to computer graphics (we made a small project in opengl),
>  intro do sql, intro to java, algorithms, paralel programation (we also
> made a project in c using openmp).
>
>
> ___
> 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: count number of slices

[Julien Isorce]

From: Julien Isorce <julien.iso...@gmail.com>

The counter was not set but used by the nouveau driver.
It is required otherwise visual output is garbage.

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/state_trackers/va/picture.c| 8 
 src/gallium/state_trackers/va/picture_h264.c   | 2 ++
 src/gallium/state_trackers/va/picture_mpeg12.c | 6 ++
 src/gallium/state_trackers/va/picture_vc1.c| 7 +++
 src/gallium/state_trackers/va/va_private.h | 2 ++
 5 files changed, 25 insertions(+)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 7b30bf8..da9ca5a 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -174,6 +174,14 @@ static void
 handleSliceParameterBuffer(vlVaContext *context, vlVaBuffer *buf)
 {
switch (u_reduce_video_profile(context->templat.profile)) {
+   case PIPE_VIDEO_FORMAT_MPEG12:
+  vlVaHandleSliceParameterBufferMPEG12(context, buf);
+  break;
+
+   case PIPE_VIDEO_FORMAT_VC1:
+  vlVaHandleSliceParameterBufferVC1(context, buf);
+  break;
+
case PIPE_VIDEO_FORMAT_MPEG4_AVC:
   vlVaHandleSliceParameterBufferH264(context, buf);
   break;
diff --git a/src/gallium/state_trackers/va/picture_h264.c 
b/src/gallium/state_trackers/va/picture_h264.c
index acbfe5d..883a94a 100644
--- a/src/gallium/state_trackers/va/picture_h264.c
+++ b/src/gallium/state_trackers/va/picture_h264.c
@@ -48,6 +48,7 @@ void vlVaHandlePictureParameterBufferH264(vlVaDriver *drv, 
vlVaContext *context,
unsigned i;
 
assert(buf->size >= sizeof(VAPictureParameterBufferH264) && 
buf->num_elements == 1);
+   context->desc.h264.slice_count = 0;
/*CurrPic*/
context->desc.h264.field_order_cnt[0] = h264->CurrPic.TopFieldOrderCnt;
context->desc.h264.field_order_cnt[1] = h264->CurrPic.BottomFieldOrderCnt;
@@ -162,6 +163,7 @@ void vlVaHandleSliceParameterBufferH264(vlVaContext 
*context, vlVaBuffer *buf)
VASliceParameterBufferH264 *h264 = buf->data;
 
assert(buf->size >= sizeof(VASliceParameterBufferH264) && buf->num_elements 
== 1);
+   context->desc.h264.slice_count += buf->num_elements;
context->desc.h264.num_ref_idx_l0_active_minus1 =
   h264->num_ref_idx_l0_active_minus1;
context->desc.h264.num_ref_idx_l1_active_minus1 =
diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c 
b/src/gallium/state_trackers/va/picture_mpeg12.c
index e587b1e..812e9e5 100644
--- a/src/gallium/state_trackers/va/picture_mpeg12.c
+++ b/src/gallium/state_trackers/va/picture_mpeg12.c
@@ -32,6 +32,7 @@ void vlVaHandlePictureParameterBufferMPEG12(vlVaDriver *drv, 
vlVaContext *contex
VAPictureParameterBufferMPEG2 *mpeg2 = buf->data;
 
assert(buf->size >= sizeof(VAPictureParameterBufferMPEG2) && 
buf->num_elements == 1);
+   context->desc.mpeg12.num_slices = 0;
/*horizontal_size;*/
/*vertical_size;*/
vlVaGetReferenceFrame(drv, mpeg2->forward_reference_picture, 
>desc.mpeg12.ref[0]);
@@ -78,3 +79,8 @@ void vlVaHandleIQMatrixBufferMPEG12(vlVaContext *context, 
vlVaBuffer *buf)
   context->desc.mpeg12.non_intra_matrix = NULL;
 }
 
+void vlVaHandleSliceParameterBufferMPEG12(vlVaContext *context, vlVaBuffer 
*buf)
+{
+   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2) && 
buf->num_elements == 1);
+   context->desc.mpeg12.num_slices += buf->num_elements;
+}
diff --git a/src/gallium/state_trackers/va/picture_vc1.c 
b/src/gallium/state_trackers/va/picture_vc1.c
index f95fd83..6ad1571 100644
--- a/src/gallium/state_trackers/va/picture_vc1.c
+++ b/src/gallium/state_trackers/va/picture_vc1.c
@@ -32,6 +32,7 @@ void vlVaHandlePictureParameterBufferVC1(vlVaDriver *drv, 
vlVaContext *context,
VAPictureParameterBufferVC1 * vc1 = buf->data;
 
assert(buf->size >= sizeof(VAPictureParameterBufferVC1) && 
buf->num_elements == 1);
+   context->desc.vc1.slice_count = 0;
vlVaGetReferenceFrame(drv, vc1->forward_reference_picture, 
>desc.vc1.ref[0]);
vlVaGetReferenceFrame(drv, vc1->backward_reference_picture, 
>desc.vc1.ref[1]);
context->desc.vc1.picture_type = vc1->picture_fields.bits.picture_type;
@@ -65,3 +66,9 @@ void vlVaHandlePictureParameterBufferVC1(vlVaDriver *drv, 
vlVaContext *context,
context->desc.vc1.deblockEnable = vc1->post_processing != 0;
context->desc.vc1.pquant = 
vc1->pic_quantizer_fields.bits.pic_quantizer_scale;
 }
+
+void vlVaHandleSliceParameterBufferVC1(vlVaContext *context, vlVaBuffer *buf)
+{
+   assert(buf->size >= sizeof(VASliceParameterBufferVC1) && buf->num_elements 
== 1);
+   context->desc.vc1.slice_count += buf->num_elements;
+}
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index fa6e0fb..bf9d24b 1

Re: [Mesa-dev] [PATCH] st/va: count number of slices

[Julien Isorce]

On 23 December 2015 at 09:42, Christian König <christian.koe...@amd.com>
wrote:

> On 23.12.2015 10:28, Julien Isorce wrote:
>
>> The counter was not set but used by the driver.
>> It is required otherwise visual output is garbage.
>>
>> Signed-off-by: Julien Isorce <j.iso...@samsung.com>
>>
>
> One minor nit pick below, apart from that the patch look good to me.
>
>
> ---
>>   src/gallium/state_trackers/va/picture.c| 22
>> ++
>>   src/gallium/state_trackers/va/picture_h264.c   |  2 ++
>>   src/gallium/state_trackers/va/picture_mpeg12.c |  7 +++
>>   src/gallium/state_trackers/va/picture_vc1.c|  8 
>>   src/gallium/state_trackers/va/va_private.h |  2 ++
>>   5 files changed, 41 insertions(+)
>>
>> diff --git a/src/gallium/state_trackers/va/picture.c
>> b/src/gallium/state_trackers/va/picture.c
>> index 7b30bf8..5029eb8 100644
>> --- a/src/gallium/state_trackers/va/picture.c
>> +++ b/src/gallium/state_trackers/va/picture.c
>> @@ -60,6 +60,20 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID
>> context_id, VASurfaceID rende
>>context->target = surf->buffer;
>>   +   switch (u_reduce_video_profile(context->templat.profile)) {
>> +   case PIPE_VIDEO_FORMAT_MPEG12:
>> +  context->desc.mpeg12.num_slices = 0;
>> +  break;
>> +   case PIPE_VIDEO_FORMAT_MPEG4_AVC:
>> +  context->desc.h264.slice_count = 0;
>> +  break;
>> +   case PIPE_VIDEO_FORMAT_VC1:
>> +  context->desc.vc1.slice_count = 0;
>> +  break;
>> +   default:
>> +  break;
>> +   }
>> +
>>
>
> We don't have anything in the picture description that needs to be
> preserved from frame to frame, don't we?
>
> So I would say just make nails with heads and clear the whole structure at
> the beginning of each from with zeros.
>
> Regards,
> Christian.


Hi Christian,

Matrix can be common between frames:

struct pipe_mpeg12_picture_desc
{
   ...
   const uint8_t *intra_matrix;
   const uint8_t *non_intra_matrix;

   struct pipe_video_buffer *ref[2];
};

And it is hard to say what will be common or not in general. But you are
right we should clear as much as possible.

For now I'll just move "context->desc.mpeg12.num_slices = 0;" to
vlVaHandlePictureParameterBufferMPEG12. Same for h264 and vc1.

Thx
Julien


>
>
>  if (!context->decoder) {
>> /* VPP */
>> if (context->templat.profile == PIPE_VIDEO_PROFILE_UNKNOWN &&
>> @@ -174,6 +188,14 @@ static void
>>   handleSliceParameterBuffer(vlVaContext *context, vlVaBuffer *buf)
>>   {
>>  switch (u_reduce_video_profile(context->templat.profile)) {
>> +   case PIPE_VIDEO_FORMAT_MPEG12:
>> +  vlVaHandleSliceParameterBufferMPEG12(context, buf);
>> +  break;
>> +
>> +   case PIPE_VIDEO_FORMAT_VC1:
>> +  vlVaHandleSliceParameterBufferVC1(context, buf);
>> +  break;
>> +
>>  case PIPE_VIDEO_FORMAT_MPEG4_AVC:
>> vlVaHandleSliceParameterBufferH264(context, buf);
>> break;
>> diff --git a/src/gallium/state_trackers/va/picture_h264.c
>> b/src/gallium/state_trackers/va/picture_h264.c
>> index acbfe5d..d98a20a 100644
>> --- a/src/gallium/state_trackers/va/picture_h264.c
>> +++ b/src/gallium/state_trackers/va/picture_h264.c
>> @@ -162,6 +162,8 @@ void vlVaHandleSliceParameterBufferH264(vlVaContext
>> *context, vlVaBuffer *buf)
>>  VASliceParameterBufferH264 *h264 = buf->data;
>>assert(buf->size >= sizeof(VASliceParameterBufferH264) &&
>> buf->num_elements == 1);
>> +
>> +   context->desc.h264.slice_count += buf->num_elements;
>>  context->desc.h264.num_ref_idx_l0_active_minus1 =
>> h264->num_ref_idx_l0_active_minus1;
>>  context->desc.h264.num_ref_idx_l1_active_minus1 =
>> diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c
>> b/src/gallium/state_trackers/va/picture_mpeg12.c
>> index e587b1e..f0a2ae0 100644
>> --- a/src/gallium/state_trackers/va/picture_mpeg12.c
>> +++ b/src/gallium/state_trackers/va/picture_mpeg12.c
>> @@ -78,3 +78,10 @@ void vlVaHandleIQMatrixBufferMPEG12(vlVaContext
>> *context, vlVaBuffer *buf)
>> context->desc.mpeg12.non_intra_matrix = NULL;
>>   }
>>   +void vlVaHandleSliceParameterBufferMPEG12(vlVaContext *context,
>> vlVaBuffer *buf)
>> +{
>> +   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2) &&
>> buf->num_elements == 1);
>> +
>> 

Re: [Mesa-dev] [PATCH v5 3/4] nouveau: fix chunk decoding by updating number of slices

[Julien Isorce]

On 17 December 2015 at 04:16, Ilia Mirkin <imir...@alum.mit.edu> wrote:

> Is there any guarantee that bsp_next is called a number of times equal
> to the number of slices? Seems like it's just for appending on more
> data, which may or may not be equal to the number of slices... Why is
> the value in the descriptor wrong?
>

You are entirely right, it is actually a problem in st/va which does not
set slice_count at all. It should use num_elements from the slice param. So
I'll drop this patch and submit another one because it will look completely
different.

Thx for the reviews !


>
> On Wed, Dec 16, 2015 at 9:40 AM, Julien Isorce <j.iso...@samsung.com>
> wrote:
> > https://bugs.freedesktop.org/show_bug.cgi?id=89969
> >
> > Signed-off-by: Julien Isorce <j.iso...@samsung.com>
> > ---
> >  src/gallium/drivers/nouveau/nouveau_vp3_video.h |  3 +++
> >  src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c | 17
> +++--
> >  2 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> > index 1e10693..a826532 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> > +++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> > @@ -121,6 +121,9 @@ struct nouveau_vp3_decoder {
> >
> > /* Total data appended so far after last begin frame. */
> > unsigned bsp_size;
> > +
> > +   /* Number of slices so far since last begin frame */
> > +   unsigned int nb_slices;
> >  };
> >
> >  struct comm {
> > diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> > index aab8e25..7a1dc8c 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> > +++ b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> > @@ -128,6 +128,8 @@ nouveau_vp3_fill_picparm_mpeg12_bsp(struct
> nouveau_vp3_decoder *dec,
> > for (i = 0; i < 4; ++i)
> >pic_bsp->f_code[i/2][i%2] = desc->f_code[i/2][i%2] + 1; // FU
> >
> > +   desc->num_slices = dec->nb_slices;
> > +
> > return (desc->num_slices << 4) | (dec->base.profile !=
> PIPE_VIDEO_PROFILE_MPEG1);
> >  }
> >
> > @@ -162,7 +164,11 @@ nouveau_vp3_fill_picparm_vc1_bsp(struct
> nouveau_vp3_decoder *dec,
> >   char *map)
> >  {
> > struct vc1_picparm_bsp *vc = (struct vc1_picparm_bsp *)map;
> > -   uint32_t caps = (d->slice_count << 4)&0xfff0;
> > +   uint32_t caps = 0;
> > +
> > +   d->slice_count = dec->nb_slices;
> > +   caps = (d->slice_count << 4)&0xfff0;
> > +
> > vc->width = dec->base.width;
> > vc->height = dec->base.height;
> > vc->profile = dec->base.profile - PIPE_VIDEO_PROFILE_VC1_SIMPLE; //
> 04
> > @@ -194,9 +200,12 @@ nouveau_vp3_fill_picparm_h264_bsp(struct
> nouveau_vp3_decoder *dec,
> >char *map)
> >  {
> > struct h264_picparm_bsp stub_h = {}, *h = _h;
> > -   uint32_t caps = (d->slice_count << 4)&0xfff0;
> > +   uint32_t caps = 0;
> > +
> > +   d->slice_count = dec->nb_slices;
> >
> > assert(!(d->slice_count & ~0xfff));
> > +   caps = (d->slice_count << 4)&0xfff0;
> > if (d->slice_count & 0x1000)
> >caps |= 1 << 20;
> >
> > @@ -239,6 +248,7 @@ nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder
> *dec)
> >
> > dec->bsp_ptr = bsp_bo->map;
> > dec->bsp_size = NOUVEAU_VP3_BSP_RESERVED_SIZE;
> > +   dec->nb_slices = 0;
> >
> > dec->bsp_ptr += 0x100;
> >
> > @@ -266,6 +276,8 @@ nouveau_vp3_bsp_next(struct nouveau_vp3_decoder
> *dec, unsigned num_buffers,
> > struct strparm_bsp *str_bsp = NULL;
> > int i = 0;
> >
> > +   ++dec->nb_slices;
> > +
> > bsp_origin += 0x100;
> > str_bsp = (struct strparm_bsp *)bsp_origin;
> >
> > @@ -331,6 +343,7 @@ nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec,
> union pipe_desc desc)
> >
> > dec->bsp_ptr = NULL;
> > dec->bsp_size = 0;
> > +   dec->nb_slices = 0;
> >
> > return caps;
> >  }
> > --
> > 1.9.1
> >
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 2/4] nvc0: add support for st/va

[Julien Isorce]

On 17 December 2015 at 04:13, Ilia Mirkin <imir...@alum.mit.edu> wrote:

> On Wed, Dec 16, 2015 at 9:39 AM, Julien Isorce <j.iso...@samsung.com>
> wrote:
> > - split nvc0_decoder_bsp in begin/next/end
> > - preserve content buffer when calling nvc0_decoder_bsp_next
> > - implement pipe_video_codec::begin_frame/end_frame
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=89969
> >
> > Signed-off-by: Julien Isorce <j.iso...@samsung.com>
> > ---
> >  src/gallium/drivers/nouveau/nouveau_vp3_video.h|   3 +
> >  .../drivers/nouveau/nouveau_vp3_video_bsp.c|   2 +
> >  src/gallium/drivers/nouveau/nvc0/nvc0_video.c  |  44 ++-
> >  src/gallium/drivers/nouveau/nvc0/nvc0_video.h  |  18 ++-
> >  src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c  | 138
> ++---
> >  5 files changed, 150 insertions(+), 55 deletions(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> > index 9db8c63..1e10693 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> > +++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> > @@ -118,6 +118,9 @@ struct nouveau_vp3_decoder {
> > /* End of the bsp bo where new data should be appended between one
> begin/end
> >  * frame. */
> > char *bsp_ptr;
> > +
> > +   /* Total data appended so far after last begin frame. */
> > +   unsigned bsp_size;
> >  };
> >
> >  struct comm {
> > diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> > index 2c15955..aab8e25 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> > +++ b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> > @@ -238,6 +238,7 @@ nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder
> *dec)
> > struct strparm_bsp *str_bsp = NULL;
> >
> > dec->bsp_ptr = bsp_bo->map;
> > +   dec->bsp_size = NOUVEAU_VP3_BSP_RESERVED_SIZE;
> >
> > dec->bsp_ptr += 0x100;
> >
> > @@ -329,6 +330,7 @@ nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec,
> union pipe_desc desc)
> > *(uint32_t *)dec->bsp_ptr = 0x;
> >
> > dec->bsp_ptr = NULL;
> > +   dec->bsp_size = 0;
> >
> > return caps;
> >  }
> > diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
> b/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
> > index 48ffac1..e28016a 100644
> > --- a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
> > +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
> > @@ -26,6 +26,24 @@
> >  #include "util/u_format.h"
> >
> >  static void
> > +nvc0_decoder_begin_frame(struct pipe_video_codec *decoder,
> > + struct pipe_video_buffer *target,
> > + struct pipe_picture_desc *picture)
> > +{
> > +   struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder
> *)decoder;
> > +   uint32_t comm_seq = ++dec->fence_seq;
> > +   unsigned ret = 0;
> > +
> > +   assert(dec);
> > +   assert(target);
> > +   assert(target->buffer_format == PIPE_FORMAT_NV12);
> > +
> > +   ret = nvc0_decoder_bsp_begin(dec, comm_seq);
> > +
> > +   assert(ret == 2);
> > +}
> > +
> > +static void
> >  nvc0_decoder_decode_bitstream(struct pipe_video_codec *decoder,
> >struct pipe_video_buffer *video_target,
> >struct pipe_picture_desc *picture,
> > @@ -34,8 +52,24 @@ nvc0_decoder_decode_bitstream(struct pipe_video_codec
> *decoder,
> >const unsigned *num_bytes)
> >  {
> > struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder
> *)decoder;
> > +   uint32_t comm_seq = dec->fence_seq;
> > +   unsigned ret = 0;
> > +
> > +   assert(decoder);
> > +
> > +   ret = nvc0_decoder_bsp_next(dec, comm_seq, num_buffers, data,
> num_bytes);
> > +
> > +   assert(ret == 2);
> > +}
> > +
> > +static void
> > +nvc0_decoder_end_frame(struct pipe_video_codec *decoder,
> > +   struct pipe_video_buffer *video_target,
> > +   struct pipe_picture_desc *picture)
> > +{
> > +   struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder
> *)decoder;
> > struct nouveau_vp3_video_buffer *target = (struct
> nouveau_vp3_video_buffer *)video_target;
> > -   uint32_t comm_seq = ++dec->fence_seq;
> &g

Re: [Mesa-dev] [PATCH v5 1/4] nouveau: split nouveau_vp3_bsp in begin/next/end

[Julien Isorce]

On 17 December 2015 at 04:02, Ilia Mirkin <imir...@alum.mit.edu> wrote:

> On Wed, Dec 16, 2015 at 9:39 AM, Julien Isorce <j.iso...@samsung.com>
> wrote:
> > It allows to call nouveau_vp3_bsp_next multiple times
> > between one begin/end.
> >
> > It is required to support st/va.
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=89969
> >
> > Signed-off-by: Julien Isorce <j.iso...@samsung.com>
> > ---
> >  src/gallium/drivers/nouveau/nouveau_vp3_video.h| 16 +++-
> >  .../drivers/nouveau/nouveau_vp3_video_bsp.c| 96
> ++
> >  src/gallium/drivers/nouveau/nv50/nv98_video_bsp.c  |  5 +-
> >  src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c  |  5 +-
> >  4 files changed, 78 insertions(+), 44 deletions(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> > index 58df5ee..9db8c63 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> > +++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
> > @@ -114,6 +114,10 @@ struct nouveau_vp3_decoder {
> > unsigned fence_seq, fw_sizes, last_frame_num, tmp_stride, ref_stride;
> >
> > unsigned bsp_idx, vp_idx, ppp_idx;
> > +
> > +   /* End of the bsp bo where new data should be appended between one
> begin/end
> > +* frame. */
> > +   char *bsp_ptr;
> >  };
> >
> >  struct comm {
> > @@ -208,11 +212,15 @@ nouveau_vp3_load_firmware(struct
> nouveau_vp3_decoder *dec,
> >enum pipe_video_profile profile,
> >unsigned chipset);
> >
> > +void
> > +nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec);
> > +
> > +void
> > +nouveau_vp3_bsp_next(struct nouveau_vp3_decoder *dec, unsigned
> num_buffers,
> > + const void *const *data, const unsigned
> *num_bytes);
> > +
> >  uint32_t
> > -nouveau_vp3_bsp(struct nouveau_vp3_decoder *dec,  union pipe_desc desc,
> > -struct nouveau_vp3_video_buffer *target,
> > -unsigned comm_seq, unsigned num_buffers,
> > -const void *const *data, const unsigned *num_bytes);
> > +nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec, union pipe_desc
> desc);
> >
> >  void
> >  nouveau_vp3_vp_caps(struct nouveau_vp3_decoder *dec, union pipe_desc
> desc,
> > diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> > index 692772e..2c15955 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> > +++ b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
> > @@ -230,20 +230,61 @@ nouveau_vp3_fill_picparm_h264_bsp(struct
> nouveau_vp3_decoder *dec,
> > return caps | 3;
> >  }
> >
> > +void
> > +nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec)
> > +{
> > +   uint32_t comm_seq = dec->fence_seq;
> > +   struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq %
> NOUVEAU_VP3_VIDEO_QDEPTH];
> > +   struct strparm_bsp *str_bsp = NULL;
> > +
> > +   dec->bsp_ptr = bsp_bo->map;
> > +
> > +   dec->bsp_ptr += 0x100;
> > +
> > +   str_bsp = (struct strparm_bsp *)dec->bsp_ptr;
> > +   memset(str_bsp, 0, 0x80);
> > +   str_bsp->w0[0] = 16;
>
> This field is, ostensibly, the number of bytes in the buffer. This 16
> should get added when you actually add the end sequence. Here it
> should get initialized to 0.
>

All right I'll move that to _end. It will also simplify
nouveau_vp3_bsp_next.


>
> > +   str_bsp->w1[0] = 0x1;
> > +   dec->bsp_ptr += 0x100;
> > +   /* Reserved for picparm_vp */
> > +   dec->bsp_ptr += 0x300;
> > +   /* Reserved for comm */
> > +   #if !NOUVEAU_VP3_DEBUG_FENCE
>
> I'm surprised this compiles... I thought macro processor stuff had to
> be on column 0. Either way, nowhere do we put spaces before the #.
>
> git grep -P '^\s+#' -- *.c\*
>
> just a handful of results.
>

Ack :)


>
> > +   memset(dec->bsp_ptr, 0, 0x200);
> > +   #endif
> > +   dec->bsp_ptr += 0x200;
> > +}
> > +
> > +void
> > +nouveau_vp3_bsp_next(struct nouveau_vp3_decoder *dec, unsigned
> num_buffers,
> > + const void *const *data, const unsigned *num_bytes)
> > +{
> > +   uint32_t comm_seq = dec->fence_seq;
> > +   struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq %
> NOUVEAU_VP3_VIDEO_QDEPTH];
> > +   char *bsp_origin = bsp_bo->map;
> > + 

[Mesa-dev] [PATCH v6 1/4] nouveau: split nouveau_vp3_bsp in begin/next/end

[Julien Isorce]

It allows to call nouveau_vp3_bsp_next multiple times
between one begin/end.

It is required to support st/va.

https://bugs.freedesktop.org/show_bug.cgi?id=89969

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/drivers/nouveau/nouveau_vp3_video.h| 16 +++-
 .../drivers/nouveau/nouveau_vp3_video_bsp.c| 86 ++
 src/gallium/drivers/nouveau/nv50/nv98_video_bsp.c  |  5 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c  |  5 +-
 4 files changed, 75 insertions(+), 37 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.h 
b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
index 58df5ee..9db8c63 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
@@ -114,6 +114,10 @@ struct nouveau_vp3_decoder {
unsigned fence_seq, fw_sizes, last_frame_num, tmp_stride, ref_stride;
 
unsigned bsp_idx, vp_idx, ppp_idx;
+
+   /* End of the bsp bo where new data should be appended between one begin/end
+* frame. */
+   char *bsp_ptr;
 };
 
 struct comm {
@@ -208,11 +212,15 @@ nouveau_vp3_load_firmware(struct nouveau_vp3_decoder *dec,
   enum pipe_video_profile profile,
   unsigned chipset);
 
+void
+nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec);
+
+void
+nouveau_vp3_bsp_next(struct nouveau_vp3_decoder *dec, unsigned num_buffers,
+ const void *const *data, const unsigned *num_bytes);
+
 uint32_t
-nouveau_vp3_bsp(struct nouveau_vp3_decoder *dec,  union pipe_desc desc,
-struct nouveau_vp3_video_buffer *target,
-unsigned comm_seq, unsigned num_buffers,
-const void *const *data, const unsigned *num_bytes);
+nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec, union pipe_desc desc);
 
 void
 nouveau_vp3_vp_caps(struct nouveau_vp3_decoder *dec, union pipe_desc desc,
diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c 
b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
index 692772e..39699d5 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
@@ -230,18 +230,55 @@ nouveau_vp3_fill_picparm_h264_bsp(struct 
nouveau_vp3_decoder *dec,
return caps | 3;
 }
 
+void
+nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec)
+{
+   unsigned comm_seq = dec->fence_seq;
+   struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq % 
NOUVEAU_VP3_VIDEO_QDEPTH];
+   struct strparm_bsp *str_bsp;
+
+   dec->bsp_ptr = bsp_bo->map;
+
+   dec->bsp_ptr += 0x100;
+
+   str_bsp = (struct strparm_bsp *)dec->bsp_ptr;
+   memset(str_bsp, 0, 0x80);
+   dec->bsp_ptr += 0x100;
+   /* Reserved for picparm_vp */
+   dec->bsp_ptr += 0x300;
+   /* Reserved for comm */
+#if !NOUVEAU_VP3_DEBUG_FENCE
+   memset(dec->bsp_ptr, 0, 0x200);
+#endif
+   dec->bsp_ptr += 0x200;
+}
+
+void
+nouveau_vp3_bsp_next(struct nouveau_vp3_decoder *dec, unsigned num_buffers,
+ const void *const *data, const unsigned *num_bytes)
+{
+#ifndef NDEBUG
+   unsigned comm_seq = dec->fence_seq;
+   struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq % 
NOUVEAU_VP3_VIDEO_QDEPTH];
+#endif
+   int i;
+
+   for (i = 0; i < num_buffers; ++i) {
+  assert((char *)bsp_bo->map + bsp_bo->size >= dec->bsp_ptr + 
num_bytes[i]);
+  memcpy(dec->bsp_ptr, data[i], num_bytes[i]);
+  dec->bsp_ptr += num_bytes[i];
+   }
+}
+
 uint32_t
-nouveau_vp3_bsp(struct nouveau_vp3_decoder *dec,  union pipe_desc desc,
-struct nouveau_vp3_video_buffer *target,
-unsigned comm_seq, unsigned num_buffers,
-const void *const *data, const unsigned *num_bytes)
+nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec, union pipe_desc desc)
 {
-   enum pipe_video_format codec = u_reduce_video_profile(dec->base.profile);
+   unsigned comm_seq = dec->fence_seq;
struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq % 
NOUVEAU_VP3_VIDEO_QDEPTH];
+   enum pipe_video_format codec = u_reduce_video_profile(dec->base.profile);
char *bsp;
uint32_t endmarker, caps;
struct strparm_bsp *str_bsp;
-   int i;
 
bsp = bsp_bo->map;
/*
@@ -277,34 +314,25 @@ nouveau_vp3_bsp(struct nouveau_vp3_decoder *dec,  union 
pipe_desc desc,
caps |= 1 << 17; // enable watchdog
caps |= 0 << 18; // do not report error to VP, so it can continue decoding 
what we have
caps |= 0 << 19; // if enabled, use crypto crap?
-   bsp += 0x100;
 
+   assert(dec->bsp_ptr - ((char *)bsp_bo->map + NOUVEAU_VP3_BSP_RESERVED_SIZE) 
>= 0);
+
+   bsp += 0x100;
str_bsp = (struct strparm_bsp *)bsp;
-   memset(str_bsp, 0, 0x80);
-   str_bsp->w0[0] = 16;
+   str_bsp->w0[0] =
+  16 + dec->bsp_ptr - ((char *)bsp_bo->map + 
NOUVEAU_VP3_BSP_RESERVED_SIZE);
str_bsp->w1[0] = 0x1;
-   bsp += 0x100;
-   /* Reserved for picp

[Mesa-dev] [PATCH v6 2/4] nvc0: add support for st/va

[Julien Isorce]

- split nvc0_decoder_bsp in begin/next/end
- preserve content buffer when calling nvc0_decoder_bsp_next
- implement pipe_video_codec::begin_frame/end_frame

https://bugs.freedesktop.org/show_bug.cgi?id=89969

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/drivers/nouveau/nvc0/nvc0_video.c |  44 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_video.h |  18 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c | 119 +++---
 3 files changed, 131 insertions(+), 50 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
index 48ffac1..e28016a 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
@@ -26,6 +26,24 @@
 #include "util/u_format.h"
 
 static void
+nvc0_decoder_begin_frame(struct pipe_video_codec *decoder,
+ struct pipe_video_buffer *target,
+ struct pipe_picture_desc *picture)
+{
+   struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder *)decoder;
+   uint32_t comm_seq = ++dec->fence_seq;
+   unsigned ret = 0;
+
+   assert(dec);
+   assert(target);
+   assert(target->buffer_format == PIPE_FORMAT_NV12);
+
+   ret = nvc0_decoder_bsp_begin(dec, comm_seq);
+
+   assert(ret == 2);
+}
+
+static void
 nvc0_decoder_decode_bitstream(struct pipe_video_codec *decoder,
   struct pipe_video_buffer *video_target,
   struct pipe_picture_desc *picture,
@@ -34,8 +52,24 @@ nvc0_decoder_decode_bitstream(struct pipe_video_codec 
*decoder,
   const unsigned *num_bytes)
 {
struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder *)decoder;
+   uint32_t comm_seq = dec->fence_seq;
+   unsigned ret = 0;
+
+   assert(decoder);
+
+   ret = nvc0_decoder_bsp_next(dec, comm_seq, num_buffers, data, num_bytes);
+
+   assert(ret == 2);
+}
+
+static void
+nvc0_decoder_end_frame(struct pipe_video_codec *decoder,
+   struct pipe_video_buffer *video_target,
+   struct pipe_picture_desc *picture)
+{
+   struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder *)decoder;
struct nouveau_vp3_video_buffer *target = (struct nouveau_vp3_video_buffer 
*)video_target;
-   uint32_t comm_seq = ++dec->fence_seq;
+   uint32_t comm_seq = dec->fence_seq;
union pipe_desc desc;
 
unsigned vp_caps, is_ref, ret;
@@ -43,11 +77,7 @@ nvc0_decoder_decode_bitstream(struct pipe_video_codec 
*decoder,
 
desc.base = picture;
 
-   assert(target->base.buffer_format == PIPE_FORMAT_NV12);
-
-   ret = nvc0_decoder_bsp(dec, desc, target, comm_seq,
-  num_buffers, data, num_bytes,
-  _caps, _ref, refs);
+   ret = nvc0_decoder_bsp_end(dec, desc, target, comm_seq, _caps, _ref, 
refs);
 
/* did we decode bitstream correctly? */
assert(ret == 2);
@@ -164,7 +194,9 @@ nvc0_create_decoder(struct pipe_context *context,
PUSH_DATA (push[2], dec->ppp->handle);
 
dec->base.context = context;
+   dec->base.begin_frame = nvc0_decoder_begin_frame;
dec->base.decode_bitstream = nvc0_decoder_decode_bitstream;
+   dec->base.end_frame = nvc0_decoder_end_frame;
 
for (i = 0; i < NOUVEAU_VP3_VIDEO_QDEPTH && !ret; ++i)
   ret = nouveau_bo_new(screen->device, NOUVEAU_BO_VRAM,
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_video.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_video.h
index 9ee0280..cf3c942 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_video.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_video.h
@@ -30,12 +30,18 @@
 #include "util/u_video.h"
 
 extern unsigned
-nvc0_decoder_bsp(struct nouveau_vp3_decoder *dec, union pipe_desc desc,
- struct nouveau_vp3_video_buffer *target,
- unsigned comm_seq, unsigned num_buffers,
- const void *const *data, const unsigned *num_bytes,
- unsigned *vp_caps, unsigned *is_ref,
- struct nouveau_vp3_video_buffer *refs[16]);
+nvc0_decoder_bsp_begin(struct nouveau_vp3_decoder *dec, unsigned comm_seq);
+
+extern unsigned
+nvc0_decoder_bsp_next(struct nouveau_vp3_decoder *dec,
+  unsigned comm_seq, unsigned num_buffers,
+  const void *const *data, const unsigned *num_bytes);
+
+extern unsigned
+nvc0_decoder_bsp_end(struct nouveau_vp3_decoder *dec, union pipe_desc desc,
+ struct nouveau_vp3_video_buffer *target,
+ unsigned comm_seq, unsigned *vp_caps, unsigned *is_ref,
+ struct nouveau_vp3_video_buffer *refs[16]);
 
 extern void
 nvc0_decoder_vp(struct nouveau_vp3_decoder *dec, union pipe_desc desc,
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c
index b0ee4a4..51d8690 100644
--- a

[Mesa-dev] [PATCH] st/va: count number of slices

[Julien Isorce]

The counter was not set but used by the driver.
It is required otherwise visual output is garbage.

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/state_trackers/va/picture.c| 22 ++
 src/gallium/state_trackers/va/picture_h264.c   |  2 ++
 src/gallium/state_trackers/va/picture_mpeg12.c |  7 +++
 src/gallium/state_trackers/va/picture_vc1.c|  8 
 src/gallium/state_trackers/va/va_private.h |  2 ++
 5 files changed, 41 insertions(+)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 7b30bf8..5029eb8 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -60,6 +60,20 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID 
context_id, VASurfaceID rende
 
context->target = surf->buffer;
 
+   switch (u_reduce_video_profile(context->templat.profile)) {
+   case PIPE_VIDEO_FORMAT_MPEG12:
+  context->desc.mpeg12.num_slices = 0;
+  break;
+   case PIPE_VIDEO_FORMAT_MPEG4_AVC:
+  context->desc.h264.slice_count = 0;
+  break;
+   case PIPE_VIDEO_FORMAT_VC1:
+  context->desc.vc1.slice_count = 0;
+  break;
+   default:
+  break;
+   }
+
if (!context->decoder) {
   /* VPP */
   if (context->templat.profile == PIPE_VIDEO_PROFILE_UNKNOWN &&
@@ -174,6 +188,14 @@ static void
 handleSliceParameterBuffer(vlVaContext *context, vlVaBuffer *buf)
 {
switch (u_reduce_video_profile(context->templat.profile)) {
+   case PIPE_VIDEO_FORMAT_MPEG12:
+  vlVaHandleSliceParameterBufferMPEG12(context, buf);
+  break;
+
+   case PIPE_VIDEO_FORMAT_VC1:
+  vlVaHandleSliceParameterBufferVC1(context, buf);
+  break;
+
case PIPE_VIDEO_FORMAT_MPEG4_AVC:
   vlVaHandleSliceParameterBufferH264(context, buf);
   break;
diff --git a/src/gallium/state_trackers/va/picture_h264.c 
b/src/gallium/state_trackers/va/picture_h264.c
index acbfe5d..d98a20a 100644
--- a/src/gallium/state_trackers/va/picture_h264.c
+++ b/src/gallium/state_trackers/va/picture_h264.c
@@ -162,6 +162,8 @@ void vlVaHandleSliceParameterBufferH264(vlVaContext 
*context, vlVaBuffer *buf)
VASliceParameterBufferH264 *h264 = buf->data;
 
assert(buf->size >= sizeof(VASliceParameterBufferH264) && buf->num_elements 
== 1);
+
+   context->desc.h264.slice_count += buf->num_elements;
context->desc.h264.num_ref_idx_l0_active_minus1 =
   h264->num_ref_idx_l0_active_minus1;
context->desc.h264.num_ref_idx_l1_active_minus1 =
diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c 
b/src/gallium/state_trackers/va/picture_mpeg12.c
index e587b1e..f0a2ae0 100644
--- a/src/gallium/state_trackers/va/picture_mpeg12.c
+++ b/src/gallium/state_trackers/va/picture_mpeg12.c
@@ -78,3 +78,10 @@ void vlVaHandleIQMatrixBufferMPEG12(vlVaContext *context, 
vlVaBuffer *buf)
   context->desc.mpeg12.non_intra_matrix = NULL;
 }
 
+void vlVaHandleSliceParameterBufferMPEG12(vlVaContext *context, vlVaBuffer 
*buf)
+{
+   assert(buf->size >= sizeof(VASliceParameterBufferMPEG2) && 
buf->num_elements == 1);
+
+   context->desc.mpeg12.num_slices += buf->num_elements;
+}
+
diff --git a/src/gallium/state_trackers/va/picture_vc1.c 
b/src/gallium/state_trackers/va/picture_vc1.c
index f95fd83..496bae3 100644
--- a/src/gallium/state_trackers/va/picture_vc1.c
+++ b/src/gallium/state_trackers/va/picture_vc1.c
@@ -65,3 +65,11 @@ void vlVaHandlePictureParameterBufferVC1(vlVaDriver *drv, 
vlVaContext *context,
context->desc.vc1.deblockEnable = vc1->post_processing != 0;
context->desc.vc1.pquant = 
vc1->pic_quantizer_fields.bits.pic_quantizer_scale;
 }
+
+void vlVaHandleSliceParameterBufferVC1(vlVaContext *context, vlVaBuffer *buf)
+{
+   assert(buf->size >= sizeof(VASliceParameterBufferVC1) && buf->num_elements 
== 1);
+
+   context->desc.vc1.slice_count += buf->num_elements;
+}
+
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index fa6e0fb..bf9d24b 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -351,10 +351,12 @@ VAStatus 
vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver *drv, vlVaContex
 void vlVaGetReferenceFrame(vlVaDriver *drv, VASurfaceID surface_id, struct 
pipe_video_buffer **ref_frame);
 void vlVaHandlePictureParameterBufferMPEG12(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf);
 void vlVaHandleIQMatrixBufferMPEG12(vlVaContext *context, vlVaBuffer *buf);
+void vlVaHandleSliceParameterBufferMPEG12(vlVaContext *context, vlVaBuffer 
*buf);
 void vlVaHandlePictureParameterBufferH264(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf);
 void vlVaHandleIQMatrixBufferH264(vlVaContext *context, vlVaBuffer *buf);
 void vlVaHandleSliceParameterBufferH264(vlVaContext *context, vlVaBuffer *buf);
 v

Re: [Mesa-dev] [PATCH 1/9] st/va: make the implementation thread save

[Julien Isorce]

On 21 December 2015 at 15:10, Christian König <deathsim...@vodafone.de>
wrote:

> On 21.12.2015 11:05, Andy Furniss wrote:
>
>> Julien Isorce wrote:
>>
>>> Hi Christian,
>>>
>>> I have 2 remarks:
>>>
>>> 1: I am sure you have the clear answer to the following questions, so
>>> maybe add a comment in the commit message: Isn't the thread safety
>>> delegated to the application that use vaapi ? like it is designed for
>>> many libraries. I tried to find answer in vaapi-intel-driver and
>>> libva but it is not obvious. I'll try the mailing list. For vdpau you
>>> are right: "All VDPAU functionality is fully thread-safe; any number
>>> of threads may call into any VDPAU functions at any time. VDPAU may
>>> not be called from signal-handlers." I could not find something
>>> equivalent for vaapi but I guess it would make sense if it was the
>>> same.
>>>
>>
>> Oh, interesting as ffmpeg recently decided hwdec should be forced to
>> single thread for some reason. It hurts perf for using ffmpeg cli.
>>
>
> Well I had to add this because of the simple reason MPV failed miserable
> in some circumstances because it assumed that VA-API is thread safe.
>
> And yes Julien your suspicion is right that VA-API simply doesn't define
> this properly like VDPAU does.
>

I guess you saw the conversation on libva mailing list, what you did
matches what it is done in intel-vaapi-driver so that's great.

I had time to go further, the series is:
Reviewed-by: Julien Isorce <j.iso...@samsung.com>
Tested-by: Julien Isorce <j.iso...@samsung.com>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/9] st/va: make the implementation thread save

[Julien Isorce]

Hi Christian,

I have 2 remarks:

1: I am sure you have the clear answer to the following questions, so maybe
add a comment in the commit message:
Isn't the thread safety delegated to the application that use vaapi ? like
it is designed for many libraries. I tried to find answer in
vaapi-intel-driver and libva but it is not obvious. I'll try the mailing
list.
For vdpau you are right: "All VDPAU functionality is fully thread-safe; any
number of threads may call into any VDPAU functions at any time. VDPAU may
not be called from signal-handlers."
I could not find something equivalent for vaapi but I guess it would make
sense if it was the same.

2: Sometimes lock/unlock is just surrounding the "get". Shouldn't the mutex
be kept locked until the function is done accessing the resources returned
by this "get". (if it was refcounted you would not unref before you
continue to access it)
(Also I cannot see any lock/unlock in vlVaQueryVideoProcPipelineCaps)

Otherwise this patch is:
Reviewed-by: Julien Isorce <j.iso...@samsung.com>
Tested-by: Julien Isorce <j.iso...@samsung.com>

Cheers
Julien


On 18 December 2015 at 15:08, Emil Velikov <emil.l.veli...@gmail.com> wrote:

> Hi Christian,
>
> I've just sent a few comments/suggestions. With or without the
> nitpicks (but the remaining addressed) the series is
> Reviewed-by: Emil Velikov <emil.l.veli...@gmail.com>
>
> Thanks
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v5 4/4] build: enable st/va with nouveau driver

[Julien Isorce]

vainfo fails in vaDriverInit because "dd_create_screen"
does not reach strcmp(driver_name, "nouveau") code.
Indeed when compiling the va target.c, the macro GALLIUM_NOUVEAU
is not defined.
This patch define the macro the same it is done for dri and
vdpau targets.

Tested with:
./autogen.sh --enable-glx --enable-gles2 --enable-egl --enable-vdpau 
--enable-glx-tls=yes --enable-va
--with-gallium-drivers=swrast,nouveau --with-dri-drivers=swrast,nouveau 
--with-egl-platforms=x11

LIBVA_DRIVER_NAME=gallium vainfo
Output:
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileMPEG4Simple: VAEntrypointVLD
  VAProfileMPEG4AdvancedSimple: VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264Baseline   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointVLD

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/targets/va/Makefile.am | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/targets/va/Makefile.am 
b/src/gallium/targets/va/Makefile.am
index 733e7ac..1edd5c2 100644
--- a/src/gallium/targets/va/Makefile.am
+++ b/src/gallium/targets/va/Makefile.am
@@ -42,6 +42,8 @@ TARGET_DRIVERS =
 TARGET_CPPFLAGS =
 TARGET_LIB_DEPS =
 
+include $(top_srcdir)/src/gallium/drivers/nouveau/Automake.inc
+
 include $(top_srcdir)/src/gallium/drivers/r600/Automake.inc
 include $(top_srcdir)/src/gallium/drivers/radeonsi/Automake.inc
 
-- 
1.9.1

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

[Mesa-dev] [PATCH v5 3/4] nouveau: fix chunk decoding by updating number of slices

[Julien Isorce]

https://bugs.freedesktop.org/show_bug.cgi?id=89969

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/drivers/nouveau/nouveau_vp3_video.h |  3 +++
 src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c | 17 +++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.h 
b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
index 1e10693..a826532 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
@@ -121,6 +121,9 @@ struct nouveau_vp3_decoder {
 
/* Total data appended so far after last begin frame. */
unsigned bsp_size;
+
+   /* Number of slices so far since last begin frame */
+   unsigned int nb_slices;
 };
 
 struct comm {
diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c 
b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
index aab8e25..7a1dc8c 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
@@ -128,6 +128,8 @@ nouveau_vp3_fill_picparm_mpeg12_bsp(struct 
nouveau_vp3_decoder *dec,
for (i = 0; i < 4; ++i)
   pic_bsp->f_code[i/2][i%2] = desc->f_code[i/2][i%2] + 1; // FU
 
+   desc->num_slices = dec->nb_slices;
+
return (desc->num_slices << 4) | (dec->base.profile != 
PIPE_VIDEO_PROFILE_MPEG1);
 }
 
@@ -162,7 +164,11 @@ nouveau_vp3_fill_picparm_vc1_bsp(struct 
nouveau_vp3_decoder *dec,
  char *map)
 {
struct vc1_picparm_bsp *vc = (struct vc1_picparm_bsp *)map;
-   uint32_t caps = (d->slice_count << 4)&0xfff0;
+   uint32_t caps = 0;
+
+   d->slice_count = dec->nb_slices;
+   caps = (d->slice_count << 4)&0xfff0;
+
vc->width = dec->base.width;
vc->height = dec->base.height;
vc->profile = dec->base.profile - PIPE_VIDEO_PROFILE_VC1_SIMPLE; // 04
@@ -194,9 +200,12 @@ nouveau_vp3_fill_picparm_h264_bsp(struct 
nouveau_vp3_decoder *dec,
   char *map)
 {
struct h264_picparm_bsp stub_h = {}, *h = _h;
-   uint32_t caps = (d->slice_count << 4)&0xfff0;
+   uint32_t caps = 0;
+
+   d->slice_count = dec->nb_slices;
 
assert(!(d->slice_count & ~0xfff));
+   caps = (d->slice_count << 4)&0xfff0;
if (d->slice_count & 0x1000)
   caps |= 1 << 20;
 
@@ -239,6 +248,7 @@ nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec)
 
dec->bsp_ptr = bsp_bo->map;
dec->bsp_size = NOUVEAU_VP3_BSP_RESERVED_SIZE;
+   dec->nb_slices = 0;
 
dec->bsp_ptr += 0x100;
 
@@ -266,6 +276,8 @@ nouveau_vp3_bsp_next(struct nouveau_vp3_decoder *dec, 
unsigned num_buffers,
struct strparm_bsp *str_bsp = NULL;
int i = 0;
 
+   ++dec->nb_slices;
+
bsp_origin += 0x100;
str_bsp = (struct strparm_bsp *)bsp_origin;
 
@@ -331,6 +343,7 @@ nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec, union 
pipe_desc desc)
 
dec->bsp_ptr = NULL;
dec->bsp_size = 0;
+   dec->nb_slices = 0;
 
return caps;
 }
-- 
1.9.1

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

[Mesa-dev] [PATCH v5 2/4] nvc0: add support for st/va

[Julien Isorce]

- split nvc0_decoder_bsp in begin/next/end
- preserve content buffer when calling nvc0_decoder_bsp_next
- implement pipe_video_codec::begin_frame/end_frame

https://bugs.freedesktop.org/show_bug.cgi?id=89969

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/drivers/nouveau/nouveau_vp3_video.h|   3 +
 .../drivers/nouveau/nouveau_vp3_video_bsp.c|   2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_video.c  |  44 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_video.h  |  18 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c  | 138 ++---
 5 files changed, 150 insertions(+), 55 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.h 
b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
index 9db8c63..1e10693 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
@@ -118,6 +118,9 @@ struct nouveau_vp3_decoder {
/* End of the bsp bo where new data should be appended between one begin/end
 * frame. */
char *bsp_ptr;
+
+   /* Total data appended so far after last begin frame. */
+   unsigned bsp_size;
 };
 
 struct comm {
diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c 
b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
index 2c15955..aab8e25 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
@@ -238,6 +238,7 @@ nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec)
struct strparm_bsp *str_bsp = NULL;
 
dec->bsp_ptr = bsp_bo->map;
+   dec->bsp_size = NOUVEAU_VP3_BSP_RESERVED_SIZE;
 
dec->bsp_ptr += 0x100;
 
@@ -329,6 +330,7 @@ nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec, union 
pipe_desc desc)
*(uint32_t *)dec->bsp_ptr = 0x;
 
dec->bsp_ptr = NULL;
+   dec->bsp_size = 0;
 
return caps;
 }
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
index 48ffac1..e28016a 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
@@ -26,6 +26,24 @@
 #include "util/u_format.h"
 
 static void
+nvc0_decoder_begin_frame(struct pipe_video_codec *decoder,
+ struct pipe_video_buffer *target,
+ struct pipe_picture_desc *picture)
+{
+   struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder *)decoder;
+   uint32_t comm_seq = ++dec->fence_seq;
+   unsigned ret = 0;
+
+   assert(dec);
+   assert(target);
+   assert(target->buffer_format == PIPE_FORMAT_NV12);
+
+   ret = nvc0_decoder_bsp_begin(dec, comm_seq);
+
+   assert(ret == 2);
+}
+
+static void
 nvc0_decoder_decode_bitstream(struct pipe_video_codec *decoder,
   struct pipe_video_buffer *video_target,
   struct pipe_picture_desc *picture,
@@ -34,8 +52,24 @@ nvc0_decoder_decode_bitstream(struct pipe_video_codec 
*decoder,
   const unsigned *num_bytes)
 {
struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder *)decoder;
+   uint32_t comm_seq = dec->fence_seq;
+   unsigned ret = 0;
+
+   assert(decoder);
+
+   ret = nvc0_decoder_bsp_next(dec, comm_seq, num_buffers, data, num_bytes);
+
+   assert(ret == 2);
+}
+
+static void
+nvc0_decoder_end_frame(struct pipe_video_codec *decoder,
+   struct pipe_video_buffer *video_target,
+   struct pipe_picture_desc *picture)
+{
+   struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder *)decoder;
struct nouveau_vp3_video_buffer *target = (struct nouveau_vp3_video_buffer 
*)video_target;
-   uint32_t comm_seq = ++dec->fence_seq;
+   uint32_t comm_seq = dec->fence_seq;
union pipe_desc desc;
 
unsigned vp_caps, is_ref, ret;
@@ -43,11 +77,7 @@ nvc0_decoder_decode_bitstream(struct pipe_video_codec 
*decoder,
 
desc.base = picture;
 
-   assert(target->base.buffer_format == PIPE_FORMAT_NV12);
-
-   ret = nvc0_decoder_bsp(dec, desc, target, comm_seq,
-  num_buffers, data, num_bytes,
-  _caps, _ref, refs);
+   ret = nvc0_decoder_bsp_end(dec, desc, target, comm_seq, _caps, _ref, 
refs);
 
/* did we decode bitstream correctly? */
assert(ret == 2);
@@ -164,7 +194,9 @@ nvc0_create_decoder(struct pipe_context *context,
PUSH_DATA (push[2], dec->ppp->handle);
 
dec->base.context = context;
+   dec->base.begin_frame = nvc0_decoder_begin_frame;
dec->base.decode_bitstream = nvc0_decoder_decode_bitstream;
+   dec->base.end_frame = nvc0_decoder_end_frame;
 
for (i = 0; i < NOUVEAU_VP3_VIDEO_QDEPTH && !ret; ++i)
   ret = nouveau_bo_new(screen->device, NOUVEAU_BO_VRAM,
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_video.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_video.h
index 9ee0280..cf3c942 100644
--- a/src/galliu

[Mesa-dev] [PATCH v5 0/4] nouveau: add support for vaapi

[Julien Isorce]

v5:
h264 is now working properly since:
http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/state_trackers/va?id=e483cba9f5ff45395fdb1cd40a796799707eb1e0
Just rebased these 4 patches (only one minor conflict due to commit
http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau/nvc0?id=be51020f2ad2ce8e8dc4d0f3a79186000fb01454)

* mpeg4:
mpv --hwdec=vaapi big_buck_bunny_720p_surround.avi (from 
http://download.blender.org/peach/bigbuckbunny_movies/)
* vc1:
mpv --hwdec=vaapi To_The_Limit_720_230.ismv (from 
http://playready.directtaps.net/smoothstreaming/)
* mpeg12:
mpv --hwdec=vaapi centaur_2.mpg (from 
https://github.com/malek0512/PLS/raw/master/Tests/centaur_2.mpg)
* h264:
mpv --hwdec=vaapi any_video (from http://www.h264info.com/clips.html)

* No regression found to VDPAU backend: --hwdec=vdpau

TODO:
Apply same logic for nv98 but I do not have the material to test it.
Ilia Mirkin suggested to do it afterward.

https://bugs.freedesktop.org/show_bug.cgi?id=89969

Julien Isorce (4):
  nouveau: split nouveau_vp3_bsp in begin/next/end
  nvc0: add support for st/va
  nouveau: fix chunk decoding by updating number of slices
  build: enable st/va with nouveau driver

 src/gallium/drivers/nouveau/nouveau_vp3_video.h|  22 +++-
 .../drivers/nouveau/nouveau_vp3_video_bsp.c| 115 +++--
 src/gallium/drivers/nouveau/nv50/nv98_video_bsp.c  |   5 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_video.c  |  44 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_video.h  |  18 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c  | 141 ++---
 src/gallium/targets/va/Makefile.am |   2 +
 7 files changed, 247 insertions(+), 100 deletions(-)

-- 
1.9.1

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

[Mesa-dev] [PATCH v5 1/4] nouveau: split nouveau_vp3_bsp in begin/next/end

[Julien Isorce]

It allows to call nouveau_vp3_bsp_next multiple times
between one begin/end.

It is required to support st/va.

https://bugs.freedesktop.org/show_bug.cgi?id=89969

Signed-off-by: Julien Isorce <j.iso...@samsung.com>
---
 src/gallium/drivers/nouveau/nouveau_vp3_video.h| 16 +++-
 .../drivers/nouveau/nouveau_vp3_video_bsp.c| 96 ++
 src/gallium/drivers/nouveau/nv50/nv98_video_bsp.c  |  5 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c  |  5 +-
 4 files changed, 78 insertions(+), 44 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.h 
b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
index 58df5ee..9db8c63 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
@@ -114,6 +114,10 @@ struct nouveau_vp3_decoder {
unsigned fence_seq, fw_sizes, last_frame_num, tmp_stride, ref_stride;
 
unsigned bsp_idx, vp_idx, ppp_idx;
+
+   /* End of the bsp bo where new data should be appended between one begin/end
+* frame. */
+   char *bsp_ptr;
 };
 
 struct comm {
@@ -208,11 +212,15 @@ nouveau_vp3_load_firmware(struct nouveau_vp3_decoder *dec,
   enum pipe_video_profile profile,
   unsigned chipset);
 
+void
+nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec);
+
+void
+nouveau_vp3_bsp_next(struct nouveau_vp3_decoder *dec, unsigned num_buffers,
+ const void *const *data, const unsigned *num_bytes);
+
 uint32_t
-nouveau_vp3_bsp(struct nouveau_vp3_decoder *dec,  union pipe_desc desc,
-struct nouveau_vp3_video_buffer *target,
-unsigned comm_seq, unsigned num_buffers,
-const void *const *data, const unsigned *num_bytes);
+nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec, union pipe_desc desc);
 
 void
 nouveau_vp3_vp_caps(struct nouveau_vp3_decoder *dec, union pipe_desc desc,
diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c 
b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
index 692772e..2c15955 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
@@ -230,20 +230,61 @@ nouveau_vp3_fill_picparm_h264_bsp(struct 
nouveau_vp3_decoder *dec,
return caps | 3;
 }
 
+void
+nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec)
+{
+   uint32_t comm_seq = dec->fence_seq;
+   struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq % 
NOUVEAU_VP3_VIDEO_QDEPTH];
+   struct strparm_bsp *str_bsp = NULL;
+
+   dec->bsp_ptr = bsp_bo->map;
+
+   dec->bsp_ptr += 0x100;
+
+   str_bsp = (struct strparm_bsp *)dec->bsp_ptr;
+   memset(str_bsp, 0, 0x80);
+   str_bsp->w0[0] = 16;
+   str_bsp->w1[0] = 0x1;
+   dec->bsp_ptr += 0x100;
+   /* Reserved for picparm_vp */
+   dec->bsp_ptr += 0x300;
+   /* Reserved for comm */
+   #if !NOUVEAU_VP3_DEBUG_FENCE
+   memset(dec->bsp_ptr, 0, 0x200);
+   #endif
+   dec->bsp_ptr += 0x200;
+}
+
+void
+nouveau_vp3_bsp_next(struct nouveau_vp3_decoder *dec, unsigned num_buffers,
+ const void *const *data, const unsigned *num_bytes)
+{
+   uint32_t comm_seq = dec->fence_seq;
+   struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq % 
NOUVEAU_VP3_VIDEO_QDEPTH];
+   char *bsp_origin = bsp_bo->map;
+   struct strparm_bsp *str_bsp = NULL;
+   int i = 0;
+
+   bsp_origin += 0x100;
+   str_bsp = (struct strparm_bsp *)bsp_origin;
+
+   for (i = 0; i < num_buffers; ++i) {
+  memcpy(dec->bsp_ptr, data[i], num_bytes[i]);
+  dec->bsp_ptr += num_bytes[i];
+  str_bsp->w0[0] += num_bytes[i];
+   }
+}
+
 uint32_t
-nouveau_vp3_bsp(struct nouveau_vp3_decoder *dec,  union pipe_desc desc,
-struct nouveau_vp3_video_buffer *target,
-unsigned comm_seq, unsigned num_buffers,
-const void *const *data, const unsigned *num_bytes)
+nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec, union pipe_desc desc)
 {
-   enum pipe_video_format codec = u_reduce_video_profile(dec->base.profile);
+   uint32_t comm_seq = dec->fence_seq;
struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq % 
NOUVEAU_VP3_VIDEO_QDEPTH];
-   char *bsp;
-   uint32_t endmarker, caps;
-   struct strparm_bsp *str_bsp;
-   int i;
+   enum pipe_video_format codec = u_reduce_video_profile(dec->base.profile);
+   uint32_t caps = 0;
+   uint32_t endmarker = 0;
+   char *bsp = bsp_bo->map;
 
-   bsp = bsp_bo->map;
/*
 * 0x000..0x100: picparm_bsp
 * 0x200..0x500: picparm_vp
@@ -277,34 +318,17 @@ nouveau_vp3_bsp(struct nouveau_vp3_decoder *dec,  union 
pipe_desc desc,
caps |= 1 << 17; // enable watchdog
caps |= 0 << 18; // do not report error to VP, so it can continue decoding 
what we have
caps |= 0 << 19; // if enabled, use crypto crap?
-   bsp += 0x100;
-
-   str_bsp = (struct strparm_bsp *)bsp;
-   memset(str_bsp, 0, 0x80);
-   str_bsp->w0[0] = 16;
-   str_b

Re: [Mesa-dev] [PATCH 6/8] st/va: remove fence handling

[Julien Isorce]

Hi Christian,

Sorry for the delay, I confirm the flush is required with that config
described before. Also in order to only affects that particular I wanted to
do this:

+if (buf->export_refcount > 0)
   drv->pipe->flush(drv->pipe, NULL, 0);

But this is not the same kind of vlVaBuffer, so not possible to do that.

But in any case I think you are right we should not need thsi flush at all
so I am ok that you remove this flush. The problem should be elsewhere.


So with your v2 + my change in vlVaAcquireBufferHandle,

This patch is:
Reviewed-by: Julien Isorce <j.iso...@samsung.com>
Tested-by: Julien Isorce <j.iso...@samsung.com>

Cheers
Julien


On 15 December 2015 at 10:02, Christian König <deathsim...@vodafone.de>
wrote:

> Are you sure the flush after calling the compositor is really necessary?
>
> That clearly looks odd, but if it works I'm fine with keeping that for now.
>
> Regards,
> Christian.
>
>
> On 15.12.2015 10:06, Julien Isorce wrote:
>
> And the attachment :)
>
> On 15 December 2015 at 09:06, Julien Isorce <julien.iso...@gmail.com>
> wrote:
>
>> Hi Christian,
>>
>> I tried your v2.
>>
>> I had to apply attached change on top of your patch. (the one in buffer.c
>> to avoid crashing, the one postproc.c otherwise same behavior as the v1 of
>> this patch). Note that I export the RGB-like surface (the one that vpp
>> output), not the NV12 one that come from the decoder directly.
>>
>> Cheers
>> Julien
>>
>> On 14 December 2015 at 10:11, Christian König < <deathsim...@vodafone.de>
>> deathsim...@vodafone.de> wrote:
>>
>>> Also note that in this pipeline, HW decoding is done with nouveau driver
>>> and rendering is done with intel. dmabuf in between.
>>>
>>> Yeah, I already thought that somebody is using it like this. I'm not
>>> sure if this is actually supposed to work because we don't have proper
>>> synchronization between kernel drivers with DMA-buf jet.
>>>
>>> Maybe the idea of the patch is good but something is still wrong.
>>>
>>> While it is not the proper solution I would say let's keep the pipeline
>>> draining during exporting the handle for now if that's really necessary for
>>> your use case. Please test the attached patch.
>>>
>>> Coding the patch I've just noticed that there wasn't a pipe->flush()
>>> before exporting the handle. Does it work as well if you just flush the
>>> pipeline without waiting for the commands to be finished?
>>>
>>> Regards,
>>> Christian.
>>>
>>>
>>> On 14.12.2015 10:14, Julien Isorce wrote:
>>>
>>> Hi Christian,
>>>
>>> I have tested this patch but then the displayed video is garbage (mostly
>>> white and sometimes just garbage). It also stall the nouveau driver which
>>> requires to reboot but I guess this is another issue.
>>> I tested with:
>>> GST_GL_WINDOW=x11 GST_GL_PLATFORM=egl GST_GL_API=gles2 GST_DEBUG=2
>>> LIBVA_DRIVER_NAME=gallium gst-launch-1.0 filesrc location=simpson.mp4 !
>>> qtdemux ! vaapidecodebin ! glimagesink
>>>
>>> (to test that you need my gstreamer-vaapi and gstgl branches on my
>>> github but I would not waste time to try them since they should be merged
>>> upstream at some point)
>>>
>>> Also note that in this pipeline, HW decoding is done with nouveau driver
>>> and rendering is done with intel. dmabuf in between.
>>>
>>> Maybe the idea of the patch is good but something is still wrong.
>>> I can test any update if it helps.
>>>
>>> Cheers
>>> Julien
>>>
>>>
>>>
>>>
>>> On 11 December 2015 at 12:33, Christian König <
>>> <deathsim...@vodafone.de>deathsim...@vodafone.de> wrote:
>>>
>>>> From: Christian König < <christian.koe...@amd.com>
>>>> christian.koe...@amd.com>
>>>>
>>>> It's nonsense to drain the pipeline like this.
>>>>
>>>> Signed-off-by: Christian König < <christian.koe...@amd.com>
>>>> christian.koe...@amd.com>
>>>> ---
>>>>  src/gallium/state_trackers/va/buffer.c |  5 -
>>>>  src/gallium/state_trackers/va/image.c  |  1 -
>>>>  src/gallium/state_trackers/va/postproc.c   |  6 --
>>>>  src/gallium/state_trackers/va/surface.c| 10 +-
>>>>  src/gallium/state_trackers/va/va_private.h |  2 --
>>>>  5 files changed, 1 insertion(+), 23 deleti