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