Question about blitting from RGB surface to YUV surface

Question about blitting from RGB surface to YUV surface

Post by soda » Fri, 17 Apr 2009 10:13:21


Hi,

I'm working on an application with DirectDraw7. I need create an overlay
surface and blit image to it from the primary surface. It works fine on some
PC with ATI graphic card, I notice that a RGB-format overlay surface was
created. But on some other graphics cards, only YUV format overlay be
supported. When I do a RGB->YUV blitting, it returns an DDERR_UNSUPPORTED
error. (I think the primary surface should *always* be RGB-format, please
correct me if not so.)

But the card do have DDCAPS_BLTFOURCC capability. From MSDN,
"DDCAPS_BLTFOURCC: Display hardware is capable of color space conversions
during the blit operations." I think the card should be capable to do color
space conversion by hardware. Am I missing something? If I have to do the
conversion by software, it's so so slow!


Thanks

sundx
 
 
 

Question about blitting from RGB surface to YUV surface

Post by UGhpbCBUYX » Sun, 19 Apr 2009 05:57:01

FOURCC means you have to do extra work with a FOURCC surface.

what does the debug runtime output tell you?
--
Phil Taylor
somewhat D3D knowledgeable :-)

 
 
 

Question about blitting from RGB surface to YUV surface

Post by sund » Tue, 21 Apr 2009 19:25:23

Taylor,

Thanks for the reply.

After several day's study, I realize that DDCAPS_BLTFOURCC commonly means
the capability of blitting from FOURCC surface to RGB. If a YUV->RGB
conversion needed, I should do the work programmly. But I still don't
understand why graphic drivers supply YUV->RGB conversion by hardware but no
reverse one.

sundx



"Phil Taylor" < XXXX@XXXXX.COM > 鍐欏叆娑堟伅
 
 
 

Question about blitting from RGB surface to YUV surface

Post by Phil Taylo » Thu, 23 Apr 2009 05:16:16

yes, to a software guy orthagonality in the API means a lot, and thus
forward and reverse transformations of data to/from formats is thought of as
"just obvious".

but, to a hardware guy, every feature costs gates, takes up area, uses
power, and generates heat.

so if a spec doesnt ask for a feature, the hw guy wont think to add it,
typically.

I suspect if you look at the DDI spec in the DDK, you will find support for
this feature is either called out as optional or not called out at all.
which means the hw and hw driver guys never see the feature as important or
never see it at all.

That and YUV is typically seen as a video format and not a 3D format. Since
the chips are 3D, and in my experience the 2D and 3D teams dont get along,
ipso post facto, video support is sometimes questionable. For instance,
D3D10 and D3D11 do not natively support DShow and playing DShow formats as a
texture. You should be aware of this fact and have your company ( or you )
send design feedback in. There is usually an address for both the DX SDK
(D3D ) and the Windows SDK ( DShow ) so get your asks in, dont assume
others are doing that. And you can ask the driver teams for a feature.
Perhaps the hw does it, its just not exposed yet. The more feedback a
feature gets, the more likely it gets implemented..