<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=gb2312"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>  <style>  </style> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> The bug is that when our driver handles the Over operation where source image has the alpha value and mask has the alpha value, our driver does the wrong thing. It uses the mask's alpha value to do the composite operation and omit the previous alpha value. The correct formula is that the source(ARGB) should be multiplied with the mask alpha value, then use the new alpha to do the OVER operation. I have done many experiments to prove that and guys from xorg-devel mail groug gives me the hint. <o:p></o:p> In short, our driver is short of one pass of Source*(alpha of mask) and wrongly use a*A+(1-a)*B to do the OVER operation. See datasheet of Geode on GP_RASTER_MODE for detail.<o:p></o:p> I'll correct this huge bug and let you know my result.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Thanks,<o:p></o:p> Frank<o:p></o:p> <o:p> </o:p> <div> <div class=MsoNormal align=center style='text-align:center'> <hr size=2 width="100%" align=center tabindex=-1> </div> From: Huang, FrankR Sent: 2010年5月24日 18:49 To: Huang, FrankR; xorg-driver-geode@lists.x.org; xorg-devel@lists.x.org Subject: RE: [Xorg-driver-geode] Rendering issue update<o:p></o:p> </div> <o:p> </o:p> Hi,all<o:p></o:p> I am now using the rendercheck application from freedesktop to test the rendering issue of geode driver. Many guys suggested me use this program to test our driver’s rendering issue and do the bugs fixed. Now it is time to do that after I am clear of the XRenderComposite() usage by my Xlib application.<o:p></o:p> That rendercheck application is a huge test on render. But we can use some specific tests(options) on our driver. Now following the suggestion on xorg-devel guy, I want to use blend and composite test with SRC, then OVER… That could give more information and full tests on our driver to fix bugs.<o:p></o:p> By the way, I have modified the <st1:place w:st="on"><st1:City w:st="on">cairo</st1:City></st1:place> library source code to let XRenderComposite() display the whole process of progressbar drawing on the screen instead of pict. Please see 15700 bug on freedesktop.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Thanks,<o:p></o:p> Frank <o:p></o:p> <o:p> </o:p> <div> <div class=MsoNormal align=center style='text-align:center'> <hr size=2 width="100%" align=center tabindex=-1> </div> From: xorg-driver-geode-bounces+frankr.huang=amd.com@lists.x.org [mailto:xorg-driver-geode-bounces+frankr.huang=amd.com@lists.x.org] On Behalf Of Huang, FrankR Sent: 2010年5月12日 17:13 To: <st1:PersonName w:st="on">xorg-driver-geode@lists.x.org</st1:PersonName> Subject: [Xorg-driver-geode] Rendering issue update<o:p></o:p> </div> <o:p> </o:p> Hi, all<o:p></o:p>             <o:p></o:p>             For the rendering issue, I have written a simple Xlib program that triggers geode HW rendering( lx_do_composite() ). What the application does is as below :<o:p></o:p> <![if !supportLists]>1)       <![endif]>It creates a 100x100 window (color: white) for the destination picture<o:p></o:p> <![if !supportLists]>2)       <![endif]>It creates a picture of 1x1 with the format PICT_x8r8g8b8(color: green) for the source picture, the source picture has the repeat attribute.<o:p></o:p> <![if !supportLists]>3)       <![endif]>It creates a picture of 20x20 with the format PICT_a8(only alpha value to do alpha blend) for the mask picture.<o:p></o:p> <![if !supportLists]>4)       <![endif]>Call the XRenderComposite() to trigger. The dst_x and dst_y are all 50, width and height are all 40. the mask_x and mask_y are all 5. So the alpha blend green region is 15x15<o:p></o:p> See the result of Radeon_X1200.png. It is the standard result. Run on my RS690/SB600 workstation. The rending function FUNC_NAME(RadeonComposite) on X1200 will be called. <o:p></o:p>  <o:p></o:p>             Because our driver can only support limit rendering, I choose this test case. This will use lx_do_composite() in the geode LX. I don’t know why our driver must require the pSrc->width and pSrc->height with value of 1 in lx_prepare_composite(). I follow this requirement in this application. You can see the HW rendering result with the picture of Geode_lx.png on geode platform. Apparently, there must be some HW rendinging bug in our driver. I will use this program instead of the progressbar gtk application to go on debugging.<o:p></o:p> <o:p> </o:p>             Source code is in render_test.zip. <o:p></o:p>             You can compiled it with “gcc –g –v –Wall –o render main.c ops.c tests_10x10.c –Lxxx –lX11 –lXrender”<o:p></o:p> <o:p> </o:p>             With the help of this application’s debug, we will close to the root cause of this long-long ago historical rendering bug on geode platform.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Thanks,<o:p></o:p> Frank<o:p></o:p> </div> </body> </html>