Bug 28446

Created attachment 36146 [details]
Mathematica 7, "Welcome" window

*** Bug 28445 has been marked as a duplicate of this bug. ***

Created attachment 36147 [details]
Mathematica 7, new (empty) notebook

Just did a bisection and ended up with the Mega-Glyphs commit that breaks things here. Unfortunately this is beyond my X/driver knowledge to provide a patch, sorry.

commit 5fff430046db2030f89e49beb66c6476dc3fcd4c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat May 29 17:35:00 2010 +0100

    uxa: Mega-Glyphs!
    
    Rewrite glyph rendering to avoid the intermediate buffer, accumulating
    the glyph rectangles directly in the backend composite routines. And
    modify the glyph cache routines to fully utilise the allocated size of
    the tiled buffer on older hardware. To do this we alias all glyph sizes
    into the same texture using a technique suggested by Keith Packard.
    
    PineView:
      885/856-> 1150/1110 kglyph/s (aa/rgb)
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Thanks for the bisection, can you attach a log file from the crash as well?

Hmm, also they may actually be two different bugs. Can you confirm reverting that patch (or just checking out the commit prior to that patch) fixes both issue? Taking a stab in the dark, I would think it might the render_to_dst path and clipping. Might be worth forcing it to use the render_via_mask path just to comfirm. What would be really useful would be a way to record and replay the X command stream...

Thanks for fast response!

I checked this commit prior to the Mega Glyph enhancement and it 
definitely worked just fine concerning the fonts and I was at least 
able to load a notebook without X to respawn. No further testing so far.

 commit d31abccd41c417338aac7c681e8bc6bd187b1843
 Author: Chris Wilson <chris@chris-wilson.co.uk>
 Date:   Mon May 31 12:14:23 2010 +0100

    i915: Support textured video on an extended desktop.

Strange enough (to me), the time it took to crash X jittered quite a bit. Sometimes this happened immediately after activating a drop-down menu item, then again it crashed several seconds later (say 2-3 seconds) or gave me enough time to load a notebook and crashed afterwards.

I'm using 2.11.0 now (flawless).

Hmm, not sure just how much I can do until I have a test case to ensure correct behaviour. In the meantime, can you tell me which chipset you have and if you can grab an xtrace of Mathemtica displaying its splash screen that should give me a few more clues as to which paths through the glyph code it is taking.

00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Dell Device 01da
        Flags: bus master, fast devsel, latency 0, IRQ 26
        Memory at fea00000 (32-bit, non-prefetchable) [size=1M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at ecb8 [size=8]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Kernel driver in use: i915

I'll see what I can do. The backtrace I get is obviously missing debugging symbols. I don't do this everyday, so: recompiling xorg-server and xf86-video-intel with '-O0 -g3' should do the job?

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x4a1278]
1: /usr/bin/X (0x400000+0x63579) [0x463579]
2: /lib/libpthread.so.0 (0x7f25633f0000+0xf010) [0x7f25633ff010]
3: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7f256036c000+0x3391d) [0x7f256039f91d]
4: /usr/bin/X (0x400000+0xd4d2a) [0x4d4d2a]
5: /usr/bin/X (0x400000+0xcf0bd) [0x4cf0bd]
6: /usr/bin/X (0x400000+0x2f56c) [0x42f56c]
7: /usr/bin/X (0x400000+0x24de5) [0x424de5]
8: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f2561abebbd]
9: /usr/bin/X (0x400000+0x24999) [0x424999]
Segmentation fault at address 0x54f2000

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting

Yes, recompiling with those that set of debugging flags would help. However the log file doesn't actually resolve symbols so to do so would actually require attaching gdb which is a bit of pain unless you happen to have a second machine handy. You can try using addr2line -e /usr/bin/X 0x4d4d2a to see if that resolves to anything (with full debugging symbols that will give us the actual line). I am not aware of any non-DRI2 related crashes at the moment, so if you can get a clean stacktrace, I would be most grateful.

Created attachment 36166 [details]
backtrace full

Here is the full backtrace, hope that helps.
Let me know if something is missing or if you need further information.

Ok, that confirms the render_to_dst() is screwy.

Can you check to see if this cheeky bandaid is sufficient to prevent the crashes?

diff --git a/uxa/uxa-glyphs.c b/uxa/uxa-glyphs.c
index e679b4e..419b6ab 100644
--- a/uxa/uxa-glyphs.c
+++ b/uxa/uxa-glyphs.c
@@ -1063,6 +1063,7 @@ fallback:
        ValidatePicture(pSrc);
        ValidatePicture(pDst);
 
+       maskFormat = list[0].format;
        if (!maskFormat) {
                /* If we don't have a mask format but all the glyphs have the same format,
                 * require ComponentAlpha and don't intersect, use the glyph format as mask

Works like a charm!

Font corruptions and crashing seems to be gone, 
i.e. working for about 15 minutes without crashing.

Thanks for the support, Chris.

This should fix the crash, I think, though not the misrendering.

commit 994aa1ef571ac2ab05f6588f9068d33b536c7a37
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jun 9 09:59:36 2010 +0100

    uxa: Handle all-clipped out case with destination glyphs.
    
    Fixes the crash reported in:
    
      Bug 28446 - Garbled Font with Mathematica 7
      https://bugs.freedesktop.org/show_bug.cgi?id=28446
    
    pDst=0x3d663c0, src_x=0, src_y=0, xDst=142, yDst=112, nlist=0,
    list=0x7fffea026580, glyphs=0x7fffea025d88, extents=0x0)
        at uxa-glyphs.c:809
            dx = 0
            y1 = 101
            x2 = 150
            x1 = 142
            dy = 0
            y2 = 112
            rects = 0x5491000
            this_atlas = 0x2456d00
            mask_y = 128
            glyph = 0x35933a0
            mask_x = 736
            priv = 0x39309e0
            screen = 0x8d2cc0
            uxa_screen = 0x2443eb0
            src_pixmap = 0x37c29e0
            dst_pixmap = 0x45ddbf0
            localSrc = 0x361a450
            glyph_atlas = 0x2456d00
            x = 142
            y = 112
            n = 18
            nrect = -9975128
            box = {x1 = 23152, y1 = -5630, x2 = 32767, y2 = 0}
            __PRETTY_FUNCTION__ = "uxa_glyphs_to_dst"
    
    Though the meat of that bug regarding the incorrect remains unsolved.

That's right, this patch resolves the crashing issue but fonts are still garbled.

The first (cheeky one-liner) patch you wanted me to try out fixed the misrendering as well. Is there a performance penalty connected to that "workaround"? Scrolling did not felt as snappy... I might be wrong, though.

(In reply to comment #15)
> That's right, this patch resolves the crashing issue but fonts are still
> garbled.

Thanks.

> The first (cheeky one-liner) patch you wanted me to try out fixed the
> misrendering as well. Is there a performance penalty connected to that
> "workaround"? Scrolling did not felt as snappy... I might be wrong, though.

It's partly a correctness issue, by using a temporary surface overlapping glyphs are rendered differently than if they were composited directly to the destination. And yes, there should be a considerable performance boost by avoiding the intermediate step - though the difference should be unnoticeable if it were not for some performance crippling workarounds inside the i965 driver.

I am forcing rendering of glyphs to use render_to_dst() here and I do observe some clipping issues, which I hope is the sole cause of your rendering issues... What I see is quite minor, glyphs overruning their box, nothing quite as disruptive as the Mathematica splash screen. I hope that is just an offset issue in combination with the clip, causing the glyph to disappear.

This is the fix for the clipping issue on the path in question:

commit 94217ed5f5a3726db3fad6cac2132d99ed45c154
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Jun 12 17:21:44 2010 +0100

    uxa: Always clip glyphs to destination.
    
    Even if there is only a single clip rect, since the clip may be smaller
    than the drawing rectangle on the destination we need to actually
    compute the clipped glyph rectangle.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>


That doesn't feel like the whole fix, though. Till, can I ask you to kindly check what the status of Mathematica is now, and upload a couple of new screenshots if progress has been made? Thanks.

Hi Chris,

thanks for the effort.

It's my desktop at work that is affected.
I will provide feedback tomorrow.

Unfortunately, commit 94217ed5f5a3726db3fad6cac2132d99ed45c154 did not solve the issue for me. In fact, from a visual pov, the welcome screen looks perfectly the same with the same glyphs being affected.

Just for the fun of it I disabled sub-pixel hinting and Mathematica shows up as expected. Apart from the fact, that fonts are not as nicely ant-aliased, of course...

Created attachment 36259 [details]
Mathematica 7, "Welcome" with sub-pixel hinting (commit 94217ed5f5a3726db3fad6cac2132d99ed45c154)

Created attachment 36260 [details]
Mathematica 7, "Welcome" _without_ sub-pixel hinting (commit 94217ed5f5a3726db3fad6cac2132d99ed45c154)

(In reply to comment #20)
> Just for the fun of it I disabled sub-pixel hinting and Mathematica shows up as
> expected. Apart from the fact, that fonts are not as nicely ant-aliased, of
> course...

Thanks, that's a significant bit of information. So it's render_to_dst() + ComponentAlpha + i965 that's broken. And I just realised that I was testing on i915, so no wonder I wasn't seeing the issue...

commit 995a4b2b1d09c31672d9258a8ac732dcf9a8fe9f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jun 14 12:15:34 2010 +0100

    i965: Sanity check ComponentAlpha status in prepare_composite
    
    Fixes:
    
      Bug 28446 - Garbled Font with Mathematica 7
      https://bugs.freedesktop.org/show_bug.cgi?id=28446
    
    Rewriting the glyphs to render to the destination directly and removing
    the more expensive multiple invocations of CompositePicture per picture
    was a great performance boost -- except that it needs special handling
    in the backend in order to not fallback. Having done so for i915, I
    neglected to ensure the sanity checking in i965_prepare_composite() was
    sufficient. As it turns out, it was not and so we misrendered CA-glyphs
    when rendering directly to the destination. This causes us to fallback
    properly, but is a performance regression as we no longer try the 2-pass
    magic helper before resorting to s/w. At the moment, I'd rather live
    with the temporary regression and fix i965 to do the same magic as i915,
    as it critical to fixing the severe performance issues currently
    crippling i965, as I believe that this regression only affects the
    minority of applications (incorrect, as it turns out, as the glyphs are
    overlapping) rendering directly to the destination.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Till, I believe this is the rendering regression fixed. If you can notice the performance regression can you please file a new bug - I am not inclined to classify that as a release blocker unless you can convince me otherwise. Thanks for your patience, and I hope to deliver upon my promises to make i965 a speed daemon. :)

(In reply to comment #24)
> Till, I believe this is the rendering regression fixed. If you can notice the
> performance regression can you please file a new bug - I am not inclined to
> classify that as a release blocker unless you can convince me otherwise. Thanks
> for your patience, and I hope to deliver upon my promises to make i965 a speed
> daemon. :)

You're welcome! Thanks for your excellent work and fast response.

It's hard to tell (for me) about the specific performance regressions. 
Scrolling in Mathematica is a bit sluggish.
Comparing Firefox 2.6.3 and Konqueror 4.4.4 using this bug report page as a test sample (mainly text), scrolling in Firefox is really fast while Konqueror is noticeably not as snappy for example (Qt?).

I don't think this motivates a bug report, especially not since you're obviously aware of those issues. =)

Thanks again, Chris!