Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

On 27/01/17 14:27, Christian König wrote: > Am 27.01.2017 um 13:51 schrieb Mark Thompson: >> On 26/01/17 16:59, Christian König wrote: >>> Am 26.01.2017 um 13:14 schrieb Mark Thompson: >>>> [SNIP] >>> The problem here is I need to know what will be d

Re: [Mesa-dev] [PATCH] st/va encode handle ntsc framerate rate control

On 26/01/17 18:26, Andy Furniss wrote: > Tested with ffmpeg and gst-vaapi. Without this bits per > frame is set way too low. > > Signed-off-by: Andy Furniss > --- > src/gallium/state_trackers/va/picture.c | 32 > 1 file changed, 24 insertions(+), 8 deletions(-) >

[Mesa-dev] [PATCH] st/va: Support fractional framerate in misc parameter

Signed-off-by: Mark Thompson --- See <https://cgit.freedesktop.org/libva/tree/va/va.h#n1277> - this is a recent addition, but is backwards-compatible. Depends on Andy's patch <https://lists.freedesktop.org/archives/mesa-dev/2017-January/142242.html> for actual support for fra

Re: [Mesa-dev] [PATCH] st/va encode handle ntsc framerate rate control

On 27/01/17 22:06, Andy Furniss wrote: > Mark Thompson wrote: >> On 26/01/17 18:26, Andy Furniss wrote: >>> Tested with ffmpeg and gst-vaapi. Without this bits per >>> frame is set way too low. >>> >>> Signed-off-by: Andy Furniss >>>

Re: [Mesa-dev] [PATCH v2] st/va encode handle ntsc framerate rate control

On 29/01/17 14:22, Andy Furniss wrote: > Tested with ffmpeg and gst-vaapi. Without this bits per > frame is set way too low for fractional framerates. > > v2: Mark Thompson: simplify calculation. > Use float. > > Signed-off-by: Andy Furniss > --- > src/gallium/

[Mesa-dev] [PATCH 1/3] st/va: Return more useful config attributes

--- More chroma formats might be supportable, I've kept this to YUV420 + RGB for now. Also, B-frames might be supported in some configurations? That could be conditional on the GPU being used somehow if necessary. src/gallium/state_trackers/va/config.c | 53 --

[Mesa-dev] [PATCH 2/3] st/va: Save surface chroma format in config

--- We need this stored somewhere to be able to return useful information from vaQuerySurfaceAttributes() in the following patch. src/gallium/state_trackers/va/config.c | 23 +-- src/gallium/state_trackers/va/va_private.h | 1 + 2 files changed, 22 insertions(+), 2 dele

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

Also allows NV12 to be returned as a supported format for video processing. --- The useful change is that we can now see that NV12 is supported by the video processor, so things like decode-scale-encode are known to be possible. Again, there might be more supported things here which could be adde

[Mesa-dev] [PATCH 1/3] st/va: Return more useful config attributes

--- On 20/09/16 10:55, Christian König wrote: >> +if (profile == VAProfileHEVCMain10) >> + value = VA_RT_FORMAT_YUV420_10BPP; > We actually don't support that yet. Main10 profiles dither down the 10bit > output to 8bits before writing it to the VA-API surface at the momen

[Mesa-dev] [PATCH] st/va: H.264 baseline profile is not supported

H.264 constrained baseline is, so use that instead. --- On decode, FMO doesn't work - it's commented out at , and I doubt it is supported by the hardware anyway. On encode, it seems to use constrained b

[Mesa-dev] [PATCH] st/va: Fix vaSyncSurface with no outstanding operation

--- A simple fix to the problem described here: . With this applied, the driver no longer hangs/crashes when vaSyncSurface() is called in places other than for the first time after an encode operation (including a secon

Re: [Mesa-dev] [PATCH] st/va: Fix vaSyncSurface with no outstanding operation

On 27/09/16 00:49, Andy Furniss wrote: > Mark Thompson wrote: >> --- >> A simple fix to the problem described here: >> <https://lists.freedesktop.org/archives/mesa-dev/2016-September/128076.html>. >> >> With this applied, the driver no longer hangs/crashe

Re: [Mesa-dev] [PATCH] st/va: Fix vaSyncSurface with no outstanding operation

On 27/09/16 16:48, Andy Furniss wrote: > Ok, thanks, so with that I am back to where I was before it stopped working. > > In summary baseline works but JM ref decoder doesn't like the pocs. > > b frames don't work properly, but then they don't with gst vaapi either. They > do work with gst omx.

Re: [Mesa-dev] [PATCH] st/va: Fix vaSyncSurface with no outstanding operation

On 28/09/16 11:47, Andy Furniss wrote: > Andy Furniss wrote: >> Andy Furniss wrote: >> >>> I started to get some numbers but found a possible bug = I made a 1000 >>> frame 15mbit 1080p50 mkv with ffmpeg/libx264. >>> >>> Using it as source for transcode (s/w or h/w dec) it came out far too >>> low b

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

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 +

[Mesa-dev] [PATCH 5/5] st/va: Fix H.264 PicOrderCnt value

TopFieldPicOrderCnt is exactly the PicOrderCnt value for a frame - see H.264 section 8.2.1. --- src/gallium/state_trackers/va/picture.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/va/picture.c b/src/gallium/state_trackers/va/picture.c index 39966

[Mesa-dev] [PATCH 1/5] st/va: Return more useful config attributes

The encoder attributes are needed for a user of the encoder to be able to configure it sensibly without internal knowledge. --- src/gallium/state_trackers/va/config.c | 47 +++--- 1 file changed, 38 insertions(+), 9 deletions(-) diff --git a/src/gallium/state_trackers/

[Mesa-dev] [PATCH 2/5] st/va: Save surface chroma format in config

Both YUV420 and RGB32 configurations are supported, so we need to be able to distinguish which is being used. --- src/gallium/state_trackers/va/config.c | 20 +++- src/gallium/state_trackers/va/va_private.h | 1 + 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/

[Mesa-dev] [PATCH 4/5] st/va: Baseline profile is not supported

Constrained baseline profile is supported, so use that instead. This matches what the encoder already does (constraint_set1_flag is always set in the output bitstream). --- src/gallium/state_trackers/va/va_private.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/galli

Re: [Mesa-dev] [PATCH 1/5] st/va: Return more useful config attributes

On 13/10/16 08:20, Christian König wrote: > Am 13.10.2016 um 00:52 schrieb Mark Thompson: >> The encoder attributes are needed for a user of the encoder to be >> able to configure it sensibly without internal knowledge. > > Reviewed-by: Christian König for the whole ser

Re: [Mesa-dev] [PATCH 1/2] st/va: enable dual instances encode by sync surface

Hi, This patch (applied as ) changes the meaning of vaSyncSurface() in a way I don't think is quite right. The way it is implemented appears to make vaSyncSurface() mean "given a surface with an outsta

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

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 > con

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

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. >> >

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

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.

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

gt; 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 = VAGenericVal

[Mesa-dev] [PATCH] st/va: Fix scaling list ordering for H.265

Mesa here requires the scaling lists in diagonal scan order, but VAAPI passes them in raster scan order. Therefore, rearrange the elements when copying. (This ordering was likely inherited from VDPAU, which does pass them in diagonal scan order.) Signed-off-by: Mark Thompson --- Fixes some of

[Mesa-dev] [PATCH v2] st/va: Fix scaling list ordering for H.265

Mesa here requires the scaling lists in diagonal scan order, but VAAPI passes them in raster scan order. Therefore, rearrange the elements when copying. v2: Move scan tables to vl_zscan.c. Fix type in size assertion. Signed-off-by: Mark Thompson --- On 14/07/17 11:01, Christian König wrote

Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header implementations

On 08/11/17 18:08, boyuan.zh...@amd.com wrote: > From: Boyuan Zhang > > Implement encoding of sps, pps, and silce headers using the newly added h.264 > header coding descriptors functions based on h.264 specs. > > Signed-off-by: Boyuan Zhang > --- > src/gallium/drivers/radeon/radeon_vcn_enc_1_

Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header implementations

On 14/11/17 10:53, Andy Furniss wrote: > Zhang, Boyuan wrote: >> >> >> -Original Message- >> From: Zhang, Boyuan >> Sent: November-13-17 11:41 AM >> To: Andy Furniss; Koenig, Christian; Mark Thompson; >> mesa-dev@lists.freedesktop.org >&g

[Mesa-dev] [PATCH] st/va: Enable vaExportSurfaceHandle()

It will be present from libva 2.1 (VAAPI 1.1.0 or higher). Signed-off-by: Mark Thompson --- See: <https://github.com/01org/libva/commit/fcb9cc881596d7ff809adf5f6ff631c708d407e3> <https://github.com/01org/libva/commit/51e98b1224794a44ba097baa7a1b4e35c3596d0c> Also enabled in

Re: [Mesa-dev] [PATCH 2/3] st/va: use designated initialisers for VA driver functions

On 04/12/17 20:52, Leo Liu wrote: > Signed-off-by: Leo Liu > --- > src/gallium/state_trackers/va/context.c | 99 > - > 1 file changed, 49 insertions(+), 50 deletions(-) > > diff --git a/src/gallium/state_trackers/va/context.c > b/src/gallium/state_trackers/va/co

Re: [Mesa-dev] Please implement the vaapi-egl for vaapi hardware decoding, vdpau can't handle HEVC 10bit video.

On 04/12/17 16:33, Leo Liu wrote: > On 12/04/2017 04:32 AM, Emil Velikov wrote: >> On 2 December 2017 at 15:26, Julian Lai wrote: >>> Since the crappy vaapi-glx was dropped off by mpv-git player, there is no >>> way to play HEVC 10bit video with zero-copy hardware acceleration, vdpau >>> can't do

[Mesa-dev] [PATCH 1/2] st/dri: Add definitions to allow importing 16-bit surfaces

Necessary to support P010/P016 surfaces for video. Signed-off-by: Mark Thompson --- src/gallium/state_trackers/dri/dri2.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/src/gallium/state_trackers/dri/dri2.c b/src/gallium/state_trackers/dri/dri2.c index 1e8bb48104

[Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

This is a new interface in libva2 to support wider use-cases of passing surfaces to external APIs. In particular, this allows export of NV12 and P010 surfaces. Signed-off-by: Mark Thompson --- This implements a new interface I am proposing for libva2, which will allow export to work properly

[Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

This is a new interface in libva2 to support wider use-cases of passing surfaces to external APIs. In particular, this allows export of NV12 and P010 surfaces. Signed-off-by: Mark Thompson --- Trivial update for a minor change requested on libva side (1/2 identical). Still unsure on what to do

Re: [Mesa-dev] [PATCH 00/14] Patches for VA-API State Tracker Postproc

On 19/09/17 20:04, Leo Liu wrote: > This series are for VA-API State Tracker Postproc, including: > > Deinterlacing I video for transcode; > Scaling support in postproc for transcode; > Frame grabber in postproc > > Thanks Andy Furniss for lots of testing on these. > > Leo Liu (14): > st/va/p

Re: [Mesa-dev] [PATCH 00/14] Patches for VA-API State Tracker Postproc

On 21/09/17 03:17, Leo Liu wrote: > On 09/20/2017 06:11 PM, Mark Thompson wrote: >> On 19/09/17 20:04, Leo Liu wrote: >>> This series are for VA-API State Tracker Postproc, including: >>> >>> Deinterlacing I video for transcode; >>> Scaling support in

Re: [Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

On 20/09/17 09:14, Christian König wrote: > Am 20.09.2017 um 00:01 schrieb Mark Thompson: >> This is a new interface in libva2 to support wider use-cases of passing >> surfaces to external APIs.  In particular, this allows export of NV12 and >> P010 surfaces. > > Fi

[Mesa-dev] [PATCH 1/3] st/dri: Add definitions to allow importing 16-bit surfaces

Necessary to support P010/P016 surfaces for video. Signed-off-by: Mark Thompson --- src/gallium/state_trackers/dri/dri2.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/src/gallium/state_trackers/dri/dri2.c b/src/gallium/state_trackers/dri/dri2.c index 8672174787

[Mesa-dev] [PATCH 2/3] st/va: Implement vaExportSurfaceHandle()

This is a new interface in libva2 to support wider use-cases of passing surfaces to external APIs. In particular, this allows export of NV12 and P010 surfaces. Signed-off-by: Mark Thompson --- On 22/09/17 10:17, Christian König wrote: > Am 21.09.2017 um 21:00 schrieb Mark Thompson: >>

[Mesa-dev] [PATCH 3/3] Revert "gallium/radeon: consolidate PIPE_BIND_SHARED/SCANOUT handling"

This reverts commit f70f6baaa3bb0f8b280ac2eaea69bbffaf7de840. --- This commit broke VAAPI surface export (found by bisection). I think the observed behaviour with playback is consistent with surfaces not being updated some of the time, so something to do with sharing? I tried setting PIPE_BIND

Re: [Mesa-dev] [PATCH 3/3] Revert "gallium/radeon: consolidate PIPE_BIND_SHARED/SCANOUT handling"

- Mark >> >> Thanks, >> Marek >> >> On Fri, Sep 29, 2017 at 1:51 AM, Andy Furniss wrote: >>> Mark Thompson wrote: >>>> >>>> This reverts commit f70f6baaa3bb0f8b280ac2eaea69bbffaf7de840. >>> >>> >>> I just bisecte

Re: [Mesa-dev] [PATCH 3/3] Revert "gallium/radeon: consolidate PIPE_BIND_SHARED/SCANOUT handling"

On 29/09/17 17:25, Leo Liu wrote: > On 09/29/2017 11:37 AM, Leo Liu wrote: >> On 09/29/2017 10:45 AM, Andy Furniss wrote: >>> Marek Olšák wrote: Can you test this? >>> >>> My mpv test case is fixed by >>> >>> radeonsi/uvd: fix planar formats broken since f70f6baaa3bb0f8b280ac2eaea69bb >> >> Wi

[Mesa-dev] [PATCH 1/2] st/dri: Add definitions to allow importing 16-bit surfaces

Necessary to support P010/P016 surfaces for video. Signed-off-by: Mark Thompson --- src/gallium/state_trackers/dri/dri2.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/src/gallium/state_trackers/dri/dri2.c b/src/gallium/state_trackers/dri/dri2.c index 8672174787

[Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

(Leo). Add guards to allow building with libva1. Signed-off-by: Mark Thompson --- src/gallium/state_trackers/va/context.c| 5 +- src/gallium/state_trackers/va/surface.c| 148 + src/gallium/state_trackers/va/va_private.h | 1 + 3 files changed, 153

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2

On 28/09/17 04:41, Lukas Rusak wrote: > Hello all, > > I'm bumping this to layout some progress that has been made on our (Kodi) > side and hopefully we can create a road map for what needs to be done on > the amd side to get it working with our vaapi implementation. > > I have merged the drm/kms

Re: [Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

On 07/10/17 15:23, Leo Liu wrote: > On 2017-10-01 01:40 PM, Mark Thompson wrote: >> This is a new interface in libva2 to support wider use-cases of passing >> surfaces to external APIs.  In particular, this allows export of NV12 and >> P010 surfaces. >> >> v2

[Mesa-dev] [PATCH 1/2] st/va: Fix config entrypoint handling

Consistently use it as a PIPE_VIDEO_ENTRYPOINT. Signed-off-by: Mark Thompson --- src/gallium/state_trackers/va/config.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/src/gallium/state_trackers/va/config.c b/src/gallium/state_trackers/va/config.c index

[Mesa-dev] [PATCH 2/2] st/va: Return correct width and height for encode/decode support

Previously this would return the largest possible buffer size, which is much larger than the codecs themselves support. This caused confusion when client applications attempted to decode 8K video thinking it was supported when it isn't. Signed-off-by: Mark Thompson --- Before this change,

[Mesa-dev] [PATCH 1/2] st/va: Fix config entrypoint handling

Consistently use it as a PIPE_VIDEO_ENTRYPOINT. v2: Return an error if the entrypoint is not set (Christian). Signed-off-by: Mark Thompson --- On 10/10/17 08:32, Christian König wrote: > Am 09.10.2017 um 22:45 schrieb Mark Thompson: >> Consistently use it as a PIPE_VIDEO_E

[Mesa-dev] [PATCH 1/2] Revert "st/va: Implement vaExportSurfaceHandle()"

This reverts commit c4ed39f85b1ebd062eaa51880fcc79cfbcb4e5c3. --- Apparently the feature set of libva 2.0 was finalised inside Intel several weeks ago without communicating it externally, and this was not included. Therefore revert support for it here. This should be applied before the Mesa 17

[Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

(Leo). Add guards to allow building with libva1. v4: Adjust target version - this is no longer in libva 2.0. Signed-off-by: Mark Thompson --- (Testing only for now, not to be applied yet.) src/gallium/state_trackers/va/context.c| 5 +- src/gallium/state_trackers/va/surface.c

[Mesa-dev] [PATCH] st/va: Disable vaExportSurfaceHandle()

This is not in libva 2.0, so it shouldn't be enabled yet. Signed-off-by: Mark Thompson --- On 15/10/17 20:06, Leo Liu wrote: > On 2017-10-15 07:23 AM, Mark Thompson wrote: >> This reverts commit c4ed39f85b1ebd062eaa51880fcc79cfbcb4e5c3. > > Can we just leave the code there,

Re: [Mesa-dev] [PATCH 7/7] st/va: start of P016 support

On 25/01/17 14:42, Christian König wrote: > From: Christian König > > Most likely only partially correct, but at least a start. > > Signed-off-by: Christian König > --- > src/gallium/state_trackers/va/config.c | 9 ++--- > src/gallium/state_trackers/va/image.c | 10 ++ >

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

On 26/01/17 11:00, Christian König wrote: > Hi Peter, > > Am 25.01.2017 um 19:45 schrieb Peter Frühberger: >> >> >> Peter, Rainer any idea what I'm missing here? Do you guys use some >> modified ffmpeg for Kodi or how does that work for you? >> >> >> do you set the format correctly, e.g.:

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

On 25/01/17 14:41, Christian König wrote: > Hi guys, > > ok this is completely work in progress and untested except for a compile run. > > Most of the stuff necessary should be there for VDPAU, but I'm honestly not > sure how to approach VAAPI. > > My main problem at the moment is that I can't

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

On 26/01/17 16:59, Christian König wrote: > Am 26.01.2017 um 13:14 schrieb Mark Thompson: >> On 26/01/17 11:00, Christian König wrote: >>> Hi Peter, >>> >>> Am 25.01.2017 um 19:45 schrieb Peter Frühberger: >>>> >>>> Peter,

[Mesa-dev] [PATCH 1/2] st/va: Enable vaExportSurfaceHandle()

It is present from libva 2.1 (VAAPI 1.1.0 or higher). Signed-off-by: Mark Thompson Acked-by: Christian König --- Retested with up-to-date stuff, including unmodified git libva now. They have applied the version bump and it looks like 2.1 will actually be released soon (<https://github.

[Mesa-dev] [PATCH 2/2] st/va: Make the vendor string more descriptive

Include the Mesa version and detail about the platform. Signed-off-by: Mark Thompson --- This gives: $ vainfo --display drm --device /dev/dri/renderD128 libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/local/lib/dri/radeonsi_drv_video.so

Re: [Mesa-dev] [PATCH v2 4/8] radeon/uvd:add uvd hevc enc hw ib implementation

On 06/02/18 20:05, James Zhu wrote: > Implement required IBs for UVD HEVC encode. > > Signed-off-by: James Zhu > --- > src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 1115 > +++ > 1 file changed, 1115 insertions(+) > create mode 100644 src/gallium/drivers/radeon/radeon_u

Re: [Mesa-dev] [PATCH v2 5/8] radeon/uvd:add uvd hevc enc functions

On 06/02/18 20:05, James Zhu wrote: > Implement UVD hevc encode functions > > Signed-off-by: James Zhu > --- > src/gallium/drivers/radeon/radeon_uvd_enc.c | 370 > > 1 file changed, 370 insertions(+) > create mode 100644 src/gallium/drivers/radeon/radeon_uvd_enc.c

Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

On 06/02/18 20:05, James Zhu wrote: > The whole series are the updated version. Changes are made mainly based > on the comments from prevous code review from Alex, Leo and Boyuan > > James Zhu (8): > amd/common:add uvd hevc enc support check in hw query > winsys/amdgpu:add uvd hevc enc suppor

Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

On 08/02/18 22:37, Alex Deucher wrote: > On Thu, Feb 8, 2018 at 5:28 PM, Mark Thompson wrote: >> On 06/02/18 20:05, James Zhu wrote: >>> The whole series are the updated version. Changes are made mainly based >>> on the comments from prevous code review from Alex, Leo a

Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

On 08/02/18 23:05, Mark Thompson wrote: > On 08/02/18 22:37, Alex Deucher wrote: >> On Thu, Feb 8, 2018 at 5:28 PM, Mark Thompson wrote: >>> On 06/02/18 20:05, James Zhu wrote: >>>> The whole series are the updated version. Changes are made mainly based >>

Re: [Mesa-dev] [PATCH v3 4/8] radeon/uvd:add uvd hevc enc hw ib implementation

On 09/02/18 20:35, James Zhu wrote: > Implement required IBs for UVD HEVC encode. > > Signed-off-by: James Zhu > --- > src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 1115 > +++ > 1 file changed, 1115 insertions(+) > create mode 100644 src/gallium/drivers/radeon/radeon_u

Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

On 13/02/18 16:38, James Zhu wrote: > Hi Mark, > > Did you still encounter hung issue? > > If yes, could you share me with your play and transcode streams and command > line, > then I can try to reproduce at my side. > > Thanks & Best Regards! > > James Zhu Yes, it does still happen with the

Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

On 16/02/18 17:53, James Zhu wrote: > Hi Mark, > > I couldn't reproduce the issue on my Polaris 11 to run mpv / ffmpeg about 1.5 > hours. > > one terminal run: > > ffmpeg -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 > -hwaccel_output_format vaapi -i video/Mr.Right.mp4 -an -c:v hevc_va

[Mesa-dev] [PATCH] st/va: Fix forward/backward referencing for deinterlacing

from other implementations, in particular the i965 driver and the gstreamer client. In order to match those other implementations, this patch swaps the meaning of forward and backward references as they currently appear for motion-adaptive deinterlacing. Signed-off-by: Mark Thompson --- src

Re: [Mesa-dev] [PATCH] st/va: Support fractional framerate in misc parameter

On 27/01/17 22:03, Mark Thompson wrote: > Signed-off-by: Mark Thompson > --- > See <https://cgit.freedesktop.org/libva/tree/va/va.h#n1277> - this is a > recent addition, but is backwards-compatible. > > Depends on Andy's patch > <https://lists.freedesktop

[Mesa-dev] [PATCH] st/omx: Fix port format enumeration

From OpenMAX IL section 4.3.5: "The value of nIndex is the range 0 to N-1, where N is the number of formats supported by the port. There is no need for the port to report N, as the caller can determine N by enumerating all the formats supported by the port. Each port shall support at least one fo

[Mesa-dev] [PATCH] st/omx: Set end-of-frame flag on bitstream output buffers

Since all output buffers are whole frames, this should always be set. Technically, setting this flag is is optional (see OpenMAX IL section 3.1.2.7.1), but some clients assume that it will be used and therefore buffer indefinitely thinking that all output buffers are fragments of the first frame w

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2

On 08/03/17 12:29, Christian König wrote: > Hi guys, > > I finally found time testing this and hammering out (hopefully) all the > remaining bugs. Playing a 10bit HEVC file through VAAPI with mpv/ffmpeg git > master from about two days ago now works flawlessly and has only about 15% CPU > load on

Re: [Mesa-dev] [PATCH 11/11] st/va: add config support for 10bit decoding

On 08/03/17 12:29, Christian König wrote: > From: Christian König > > Advertise 10bpp support if the driver supports decoding to a P016 surface. > > Signed-off-by: Christian König > --- > src/gallium/state_trackers/va/config.c | 15 +-- > src/gallium/state_trackers/va/va_privat

Re: [Mesa-dev] [PATCH 11/11] st/va: add config support for 10bit decoding

On 08/03/17 21:32, Mark Thompson wrote: > On 08/03/17 12:29, Christian König wrote: >> From: Christian König >> >> Advertise 10bpp support if the driver supports decoding to a P016 surface. >> >> Signed-off-by: Christian König >> --- >> sr

Re: [Mesa-dev] [PATCH 11/11] st/va: add config support for 10bit decoding

onv): > Ah, yes that makes sense. Any objections merging that into my original patch > and adding your signed-of-by line? Sure, please do. Thanks, - Mark > Am 08.03.2017 um 22:36 schrieb Mark Thompson: >> >> On 08/03/17 21:32, Mark Thompson wrote: >>> On 08/03/1

Re: [Mesa-dev] [PATCH 11/11] st/va: add config support for 10bit decoding

TERLACE is usable as a workaround). After that, everything I would expect to work does and the series is Reviewed-by: Mark Thompson . Thanks, - Mark ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev