Bug 62304

Summary: vaDeriveImage() fails on IVB
Product: libva Reporter: Andy Ross <andy.ross>
Component: intelAssignee: haihao <haihao.xiang>
Status: RESOLVED FIXED QA Contact: Sean V Kelley <seanvk>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Andy Ross 2013-03-13 17:51:02 UTC 
In the staging branch, creating a YUV420 surface works fine (I'm doing JPEG decode, though that doesn't seem relevant) and I can grab the resulting data with vaGetImage()/vaMapBuffer() without problem.

But vaDeriveImage() (which I'd like to use to avoid a copy) fails with VA_STATUS_ERROR_OPERATION_FAILED.  A quick dig in the driver shows that the internal surface object for gen75 hardware (which is IVB only?) actually has a fourcc of "IMC1", and that isn't supported by the switch in i964_DeriveImage().

In this case, if the hardware format really is planar, then I need to do a copy anyway and this isn't a blocker bug for me.  Still, the spirit of vaDeriveImage() seems to be that it should expose the internal format as long as that is possible (which it is), and that it should be returning a valid VAImage.
Comment 1 haihao 2013-03-18 01:26:51 UTC 
HW needs IMC1/IMC3 for JPEG decoding, however the pixel format for IMC1/IMC3 is added in driver after driver enabling.  so IMC1/IMC3 is used interrnally in the driver.  We will expose it .
Comment 2 haihao 2015-11-19 01:53:45 UTC 
IMC3 was added years ago, and IMC1 isn't used for JPEG decoding

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.