Simplify the construction of the MI_FLUSH_DW command stream. Use ring
buffer generic variants of BEGIN, OUT, ADVANCE batch functions.
Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
src/intel_batchbuffer.c | 33 ++---
1 file changed, 10
Hi,
This patch series simplifies intel_batchbuffer_emit_mi_flush() for the
BSD ring, while also providing a minor fix for Broadwell.
Note: there are additional things that could be simplified. Please
have a look at it afterwards.
Thanks,
Gwenole Beauchesne (2):
batch: factor out MI_FLUSH_DW
On Sun, 2014-05-11 at 23:34 -0600, Gwenole Beauchesne wrote:
2014-05-12 7:29 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Sun, 2014-05-11 at 22:41 -0600, Gwenole Beauchesne wrote:
Hi,
2014-05-12 3:34 GMT+02:00 Zhao Yakui yakui.z...@intel.com:
On Fri, 2014-05-09 at 03:06 -0600, Yuan,
On Mon, 2014-05-12 at 07:34 +0200, Gwenole Beauchesne wrote:
2014-05-12 7:29 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Sun, 2014-05-11 at 22:41 -0600, Gwenole Beauchesne wrote:
Hi,
2014-05-12 3:34 GMT+02:00 Zhao Yakui yakui.z...@intel.com:
On Fri, 2014-05-09 at 03:06 -0600, Yuan,
On Wed, 2014-05-14 at 01:47 -0600, Gwenole Beauchesne wrote:
Simplify the construction of the MI_FLUSH_DW command stream. Use ring
buffer generic variants of BEGIN, OUT, ADVANCE batch functions.
Hi, Gwenole
Thanks for your patch.
But I don't think that we need factor out of
On Wed, 2014-05-14 at 15:49 +0800, Zhao, Yakui wrote:
On Sun, 2014-05-11 at 23:34 -0600, Gwenole Beauchesne wrote:
2014-05-12 7:29 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Sun, 2014-05-11 at 22:41 -0600, Gwenole Beauchesne wrote:
Hi,
2014-05-12 3:34 GMT+02:00 Zhao Yakui
On Wed, 2014-05-14 at 01:47 -0600, Gwenole Beauchesne wrote:
The MI_FLUSH_DW command contains 5 dwords on Broadwell, i.e. one extra
dword for the high order bits of the Address field.
Thanks for your patch.
What is wrong if this is applied?
The 4 dwords are still ok to Broadwell. And the
Hi,
2014-05-14 10:10 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Wed, 2014-05-14 at 01:47 -0600, Gwenole Beauchesne wrote:
The MI_FLUSH_DW command contains 5 dwords on Broadwell, i.e. one extra
dword for the high order bits of the Address field.
Thanks for your patch.
What is wrong if
Hi,
2014-05-14 10:05 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Wed, 2014-05-14 at 01:47 -0600, Gwenole Beauchesne wrote:
Simplify the construction of the MI_FLUSH_DW command stream. Use ring
buffer generic variants of BEGIN, OUT, ADVANCE batch functions.
Hi, Gwenole
Thanks for
On Wed, 2014-05-14 at 10:27 +0200, Gwenole Beauchesne wrote:
Hi,
2014-05-14 10:10 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Wed, 2014-05-14 at 01:47 -0600, Gwenole Beauchesne wrote:
The MI_FLUSH_DW command contains 5 dwords on Broadwell, i.e. one extra
dword for the high order bits
Hi,
This is close. When I meant do the conversion once while
parsing/accumulating, this is so that to further optimize the
translation/usage process. In this patch, you still have to perform
conversions afterwards, this is suboptimal.
Here is the exact approach I had in mind:
enum {
/* This
Hi,
2014-05-12 8:17 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Sun, 2014-05-11 at 23:31 -0600, Gwenole Beauchesne wrote:
Hi,
2014-05-12 7:21 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Sun, 2014-05-11 at 22:35 -0600, Gwenole Beauchesne wrote:
Hi,
2014-05-12 2:55 GMT+02:00 Zhao
On 14.05.2014 10:51, Xiang, Haihao wrote:
On Mon, 2014-05-12 at 07:34 +0200, Gwenole Beauchesne wrote:
2014-05-12 7:29 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Sun, 2014-05-11 at 22:41 -0600, Gwenole Beauchesne wrote:
Hi,
2014-05-12 3:34 GMT+02:00 Zhao Yakui yakui.z...@intel.com:
On
Allow vaDeriveImage() to work with grayscale surfaces by only exposing
the luma component.
Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
src/i965_drv_video.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c
index
Introduce a new i965_destroy_surface_storage() helper function to
unreference the underlying GEM buffer object, and any associated
private data, if any.
Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
src/i965_decoder_utils.c |6 +-
src/i965_drv_video.c | 14
Factor out code to validate profile/entrypoint per the underlying
hardware capabilities. Also fix vaGetConfigAttributes() to really
validate the profile/entrypoint pair.
Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
src/i965_drv_video.c | 145
Only validate the user-defined chroma format (VAConfigAttribRTFormat)
attribute, if any. Don't override it. i.e. append a pre-defined value
only if it was not defined by the user beforehand.
Propertly return VA_STATUS_ERROR_UNSUPPORTED_RT_FORMAT if the supplied
chroma format is not supported.
Add new avc_ensure_surface_bo() helper function to factor out the
allocatiion and initialization processes of the reconstructed VA
surface buffer stores.
Keep preferred native format (NV12) and initialize chroma values
to 0.0 (0x80) when needed for fake grayscale (Y800) surfaces
implemented on
If the hardware supports JPEG decoding, then we have to expose the
right set of chroma formats for the output (decoded) VA surface. In
particular, we could support YUV 4:1:0, 4:2:2 and 4:4:4.
Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
src/i965_drv_video.c | 15
Hi,
This patch series fixes and optimizes support for H.grayscale streams
encoded in H.264 (Patch8). This is backwards compatible with solutions
that incorrectly request for YUV 4:2:0 formats instead of the
appropriate Y800 one.
Tested with gstreamer-vaapi and FFmpeg/vaapi on Ivybridge. No
On Wed, 2014-05-14 at 07:13 -0600, Gwenole Beauchesne wrote:
Allow vaDeriveImage() to work with grayscale surfaces by only exposing
the luma component.
This is not necessary as the DeriveImage already supports the Y800
fourcc.
Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
On Wed, 2014-05-14 at 07:13 -0600, Gwenole Beauchesne wrote:
Optimize support for grayscale surfaces in two aspects: (i) space
by only allocating the luminance component ; (ii) speed by avoiding
initialization of the (now inexistent) chrominance planes.
Keep backward compatibility with older
On Wed, 2014-05-14 at 03:50 -0600, Sreerenj wrote:
On 14.05.2014 10:51, Xiang, Haihao wrote:
On Mon, 2014-05-12 at 07:34 +0200, Gwenole Beauchesne wrote:
2014-05-12 7:29 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Sun, 2014-05-11 at 22:41 -0600, Gwenole Beauchesne wrote:
Hi,
On Fri, 2014-05-09 at 12:20 +0200, Gwenole Beauchesne wrote:
Hi,
2014-05-05 7:00 GMT+02:00 Xiang, Haihao haihao.xi...@intel.com:
From: Xiang, Haihao haihao.xi...@intel.com
https://bugs.freedesktop.org/show_bug.cgi?id=77386
Signed-off-by: Xiang, Haihao haihao.xi...@intel.com
---
2014-05-15 2:35 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Wed, 2014-05-14 at 07:13 -0600, Gwenole Beauchesne wrote:
Allow vaDeriveImage() to work with grayscale surfaces by only exposing
the luma component.
This is not necessary as the DeriveImage already supports the Y800
fourcc.
Hi,
2014-05-15 3:34 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Wed, 2014-05-14 at 07:13 -0600, Gwenole Beauchesne wrote:
Optimize support for grayscale surfaces in two aspects: (i) space
by only allocating the luminance component ; (ii) speed by avoiding
initialization of the (now
On Wed, 2014-05-14 at 22:14 -0600, Gwenole Beauchesne wrote:
2014-05-15 2:35 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Wed, 2014-05-14 at 07:13 -0600, Gwenole Beauchesne wrote:
Allow vaDeriveImage() to work with grayscale surfaces by only exposing
the luma component.
This is not
On Wed, 2014-05-14 at 22:28 -0600, Gwenole Beauchesne wrote:
Hi,
2014-05-15 3:34 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
On Wed, 2014-05-14 at 07:13 -0600, Gwenole Beauchesne wrote:
Optimize support for grayscale surfaces in two aspects: (i) space
by only allocating the luminance
28 matches
Mail list logo
