Bug 27243

Does disabling RENDER acceleration work aorund the problem?

E.g.

    Option "EXANoComposite"

No, EXANoComposite doesn't solve the issue. 

Additionally, NoAccel flat out crashes the driver:

[...]
(**) GEODE(0): DPI set to (95, 120)
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/lib/xorg/modules/libfb.so
(II) Module fb: vendor="X.Org Foundation"
	compiled for 1.7.6, module version = 1.0.0
	ABI class: X.Org ANSI C Emulation, version 0.4
(II) GEODE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(II) GEODE(0): Geode LX video memory 7e00000 bytes at 0xaf5e9000
(II) GEODE(0): LX video memory:
(II) GEODE(0):  Display: 0x500000 bytes
(II) GEODE(0):  Compression: 0xaa000 bytes
(II) GEODE(0):  Cursor: 0x3000 bytes

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e937b]
1: /usr/bin/X (0x8048000+0x61c7d) [0x80a9c7d]
2: (vdso) (__kernel_rt_sigreturn+0x0) [0x59e410]
3: /usr/lib/xorg/modules/drivers/geode_drv.so (0xd7f000+0x198cf) [0xd988cf]
4: /usr/bin/X (AddScreen+0x198) [0x806cf48]
5: /usr/bin/X (InitOutput+0x820) [0x80b9ee0]
6: /usr/bin/X (0x8048000+0x1ebbb) [0x8066bbb]
7: /lib/libc.so.6 (__libc_start_main+0xe6) [0x196bc6]
8: /usr/bin/X (0x8048000+0x1e961) [0x8066961]
Segmentation fault at address 0xc

Caught signal 11 (Segmentation fault). Server aborting

Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

 ddxSigGiveUp: Closing log

Wait... I'll take that back; EXANoComposite alone DOES solve the issue.

However, NoAccel still crashes the driver.

Created attachment 34901 [details]
Slightly minimal test case

Some analysis in a slightly sleep deprived state:

gdb -p `pidof X`

# Catch the start of the buggy rendering operation:

break lx_check_composite
# Our icon is 24x24, so only break on that
condition 1 pSrc->pDrawable->width == 24
continue

# Run test app, X gdb will break once we are at the buggy rendering
# Now add extra breaks for other Composite (RENDER accel) hooks:

break lx_prepare_composite
break lx_do_composite
break lx_done


First CheckComposite returns TRUE - signifying we can render from the source to destination with format RGB565 (pDst->format) (Geode driver default depth is 16bit)

EXA does pixmap migration to GPU memory (exaDoMigration)

EXA calls PrepareComposite -> lx_prepare_composite

pMsk has a format of PICT_a8r8g8b8, lx_prepare_composite bails as we know how to handle A4 and A8 only, could the mask be simpler in this common image case?), EXA software fallback after pixmap migration was already done and fallback seems to fall down its face; no image gets composited.

With xorg-server-1.6 it seems to be PICT_a8r8g8b8 as well, but it manages to fallback gracefully and draw the image.


Oh EXA masters, what could be wrong in the fallback? Why doesn't it love me anymore :(

Created attachment 34903 [details] [review]
lx_exa: bail earlier (in CheckComposite) for non-alpha-only masks.

This seems to workaround the EXA bug and make icons appear again. However I believe the EXA fallback problem that this triggered should be investigated as well. Also a quick look by more experienced people on the patch would be greatly appreciated.

(In reply to comment #6)
> Created an attachment (id=34903) [details]
> lx_exa: bail earlier (in CheckComposite) for non-alpha-only masks.
> 
> This seems to workaround the EXA bug and make icons appear again.

The patch is probably a good idea anyway[0]: It's always better to catch an unsupported composite operation in the CheckComposite hook rather than in PrepareComposite, as this avoids superfluous pixmap migration.

[0] Assuming the hardware really doesn't support this format for the mask (simply ignoring the non-alpha bits, unless it's a component alpha picture).

> However I believe the EXA fallback problem that this triggered should be
> investigated as well.

Sure, assuming it still happens with xserver 1.8. Would you like to file a new report for that or reassign this one? BTW, a bt full along with a printout of the PictureRecs involved for the failing operation should be interesting.

(In reply to comment #5)
> pMsk has a format of PICT_a8r8g8b8, lx_prepare_composite bails as we know how
> to handle A4 and A8 only, could the mask be simpler in this common image
> case?),

EXA itself will only choose a mask format other than A8 for text rendering, and only if the driver doesn't support rendering to A8. So this mask format is probably chosen by the client.

I pushed Mart's patch into GIT as it at least resolves the most urgent issue, which was to restore image support in GTK2+ applications. Kudos for this patch!

However, this only seems to be the tip of the iceberg: reports at Debian indicate that Gecko-based browsers produce distortion on web content with background images. I asked the reporter whether completely disabling Composite solves the issue or not for him. Let's see what he answers.

Sure enough, the user confirmed that disabling compositing via xorg.conf option indeed resolved the Gecko-rendering issue on web sites with background images.

Other issues in separate individual bug records please..., this is only for discussion of this concrete one.
About that, will test with xorg-server-1.8 hopefully later this week and see if EXA needs fixing too or not.

I have confirmed that the EXA bug is still present on xorg-server-1.8.0 when present with an unpatched geode driver. It fails to render a XRenderComposite drawn image as done through pygtk in the attached test case if we fallback in PrepareComposite.

Reassigning to EXA component per comment 7. Will try to retrieve the backtraces and PictureRecs (once I figure what those are) later this week to help this along.

From the xf86-video-geode side, my patch is in GIT, and with that we can avoid triggering this bug in xorg-server-1.7/1.8 and so can live with it. However if it turns out that any PrepareComposite failures cause problems in EXA, then that would be very bad - we bail for quite a few common cases in PrepareComposite time at this time.


Some relevant bits from log:

X.Org X Server 1.8.0
Release Date: 2010-04-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.28-gentoo-r2 i586 Gentoo
Current Operating System: Linux geode 2.6.28-gentoo-r2 #5 Sun Feb 22 13:56:12 EET 2009 i586
Kernel command line: root=/dev/sda3 rootdelay=6 ro video=lxfb:off
Build Date: 14 April 2010  03:52:45AM

 
Current version of pixman: 0.18.0
...
[356817.689] (==) GEODE(0): Depth 16, (==) framebuffer bpp 16
[356817.689] (==) GEODE(0): RGB weight 565
[356817.689] (==) GEODE(0): Default visual is TrueColor
[356817.689] (==) GEODE(0): Using gamma correction (1.0, 1.0, 1.0)
[356817.689] (==) GEODE(0): No DCON is present
[356817.690] (II) GEODE(0): LX output options:
[356817.690] (II) GEODE(0):  CRT: YES
[356817.690] (II) GEODE(0):  PANEL: NO
[356817.690] (II) GEODE(0):  DCON: NO
[356817.690] (II) GEODE(0):  VGA: YES
[356817.690] (II) Loading sub module "int10"
[356817.690] (II) LoadModule: "int10"
[356817.692] (II) Loading /usr/lib/xorg/modules/libint10.so
[356817.693] (II) Module int10: vendor="X.Org Foundation"
[356817.693]    compiled for 1.8.0, module version = 1.0.0
[356817.693]    ABI class: X.Org Video Driver, version 7.0
[356817.699] (II) GEODE(0): Primary V_BIOS segment is: 0xc000
[356817.700] (II) GEODE(0): e00000 bytes of video memory is less then optimal
[356817.700] (II) GEODE(0): when compression is on. Disabling compression.
[356817.700] (II) GEODE(0): Output default using monitor section 204b
[356817.703] (EE) GEODE(0): GPIO pins are in serial mode.  Assuming no DDC
[356817.703] (**) GEODE(0): Option "NoDDC"
...
[356817.728] (II) GEODE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
[356817.729] (II) GEODE(0): Geode LX video memory c00000 bytes at 0xb6d4c000
[356817.729] (II) GEODE(0): LX video memory:
[356817.730] (II) GEODE(0):  Display: 0x4e2000 bytes
[356817.730] (II) GEODE(0):  Cursor: 0x3000 bytes
[356817.730] (II) GEODE(0):  EXA: 0x31800 bytes
[356817.730] (II) GEODE(0):  FREE: 0x5a9800 bytes
[356817.792] (II) EXA(0): Offscreen pixmap area of 202752 bytes
[356817.792] (II) EXA(0): Driver registered support for the following operations:
[356817.793] (II)         Solid
[356817.793] (II)         Copy
[356817.793] (II)         Composite (RENDER acceleration)
[356817.793] (==) GEODE(0): Backing store disabled
[356817.793] (==) GEODE(0): DPMS enabled

Mart's patch was included as a part of xf86-video-geode 2.11.8 as released a few days ago, which at least restores icon displaying in GTK2+ applications.

Remains the issue with pixmap distortion on Gecko-based browsers when displaying HTML content with complex background images. Should we open a separate bug for this issue and consider 27243 as only concerning the icon issue?

Does

	Option		"EXAOptimizeMigration" "off"

make any difference for this?

No, it does not fix the Gecko rendering issue on -geode.

Is "Gecko rendering issue" same as the bug 15700?
I am working on 15700 with a progressbar to see the composite thing in geode driver.

I have fixed the Src operation on blend and composite operation. 
And right now the most urgent bug in rendering is Over operation. Most of the rendering issue are arosed by this. Seems our driver does not handle this operation correc
You can add the following lines in lx_check_composite() to avoid the rendering bug.
		If(op == PictOpOver)
			return false;
I’ll fix this bug.


Thanks,
Frank

Frank, could you produce a patch against what we have in our GIT repository and attach it to this bug? Then, I can commit it to GIT (or if you already have commit rights, you could commit it yourself). Thanks!

Martin,

	Right now, my modification has fixed the Src operation problem. The Over operation is still under research now.
	And our main rendering bug is focusing on Over operation with mask. Now I am quite sure about this. I'll use rendercheck(composite and compositeCA) to modify the driver.
	Do you need the intermediate version of my modification?


Thanks,
Frank 

-----Original Message-----
From: bugzilla-daemon@freedesktop.org [mailto:bugzilla-daemon@freedesktop.org] 
Sent: 2010年5月28日 15:09
To: Huang, FrankR
Subject: [Bug 27243] EXA PrepareComposite failure fallback breakage since X server 1.7 core for XRenderComposited images

https://bugs.freedesktop.org/show_bug.cgi?id=27243

--- Comment #17 from Martin-Éric Racine <q-funk@iki.fi> 2010-05-28 00:09:25 PDT ---
Frank, could you produce a patch against what we have in our GIT repository and
attach it to this bug? Then, I can commit it to GIT (or if you already have
commit rights, you could commit it yourself). Thanks!

The bug is that when our driver handle the Over operation where source image has the alpha value and mask has the alpha value, our driver does the wrong thing. It use 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. 
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.
I'll correct this huge bug and let you know my result.


Thanks,
Frank

This bug entry here is meant for tracking the fixing of EXA PrepareComposite failure fallback breakage, as noticed by the missing images in geode driver, which were worked around by falling back early in CheckComposite instead of PrepareComposite.

Please use a dedicated bug about SrcOver issues for updates on that completely different bug. Or perhaps just the geode mailing list. Or bug 15700, but only if the black button problems are really SrcOver problems and go to there.

Ok, Mart.
I transfer this bug trace to bug 28352(EXA Rendering bug in geode driver). For the 15700, I am not sure if the black box has the same problem. I guess yes. After I correct this one, we can say more on 15700. 

Thanks,
Frank

Am I correct to assume that commit b46d4ff787bce43409d59837d736af0be2b0dda5 in Geode 2.11.9 solves this issue?

You are not correct. It only workarounds it with other benefits. So again, this bug is for finding out the core issue inside EXA code now (see the component), which we could help with.

Keep this issue here. It is not caused by our driver. Mart will update here if new findings is found in Xorg for this issue.

Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.