Hi,
2014-05-15 7:24 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
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
On Thu, 2014-05-15 at 00:05 -0600, Gwenole Beauchesne wrote:
Hi,
2014-05-15 7:24 GMT+02:00 Zhao, Yakui yakui.z...@intel.com:
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
On 05/14/2014 04:55 PM, Gwenole Beauchesne wrote:
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
On Wed, 2014-05-14 at 15:13 +0200, 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
On Wed, 2014-05-14 at 15:13 +0200, Gwenole Beauchesne wrote:
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.
We could support YUV 4:0:0 for jpeg
2014-05-15 10:25 GMT+02:00 Xiang, Haihao haihao.xi...@intel.com:
On Wed, 2014-05-14 at 15:13 +0200, 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
Could you make your patches against the staging branch first ? On the
one hand, the nightly testing can check whether the patches result in
regression first, one the other hand, the hw info has been moved to a
separated file on the staging branch, your patches might introduce a lot
of conflict
Hi,
2014-05-15 10:45 GMT+02:00 Xiang, Haihao haihao.xi...@intel.com:
Could you make your patches against the staging branch first ? On the
one hand, the nightly testing can check whether the patches result in
regression first, one the other hand, the hw info has been moved to a
separated
2014-05-15 10:53 GMT+02:00 Gwenole Beauchesne gb.de...@gmail.com:
Hi,
2014-05-15 10:45 GMT+02:00 Xiang, Haihao haihao.xi...@intel.com:
Could you make your patches against the staging branch first ? On the
one hand, the nightly testing can check whether the patches result in
regression
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:0:0, 4:1:0, 4:2:2 and 4:4:4.
v2: export support for YUV 4:0:0 (grayscale) too [Haihao]
Signed-off-by: Gwenole Beauchesne
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
Fix size of the allocated buffer used to represent grayscale (Y800)
surfaces. Only the luminance component is needed, thus implying a
single plane.
Likewise, update render routines to only submit the first plane.
The existing render kernels readily only care about that single
plane.
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
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.
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
Question: Does Motion Adaption implementation (unlike Bob) require two
distinct source surfaces plus an ADDITIONAL surface for the result?
Yes. A new surface is required for the result surface.
-Original Message-
From: Libva [mailto:libva-boun...@lists.freedesktop.org] On Behalf Of
16 matches
Mail list logo
