Graphics driver crash in Chrome with 2014 rMBP in ECAA, Nvidia GT 750M

[trishume]

I tried running the new Pathfinder web demo at revision 81a6f8f in Chrome. I loaded the Nimbus sans font and it rendered a very ugly aliased looking line of text. Then I switched it to ECAA and my computer hard crashed to the login screen.

I'm using a 2014 15" rMBP. I have a discrete GPU but at the time I was using gfxSwitcher to lock the GPU to the integrated Intel Iris Pro.

I know there's probably nothing you can do about this and it's not your fault. Just noting it down in case anyone else runs into it.

[trishume]

Actually there's a chance this was caused by gfxSwitcher being locked to integrated while I was actually using an external display, which requires using the dedicated card. This may have confused Chrome and the drivers.

Or it could still be a normal driver bug, which makes more sense since it would be in the Nvidia GT 750M drivers, which I doubt are really maintained anymore.

Let me know if you'd like me to try to reproduce it again or in a different way. Just know that it puts my computer in a weird state where I need to restart, so it's fairly disruptive and means I have to reopen a bunch of things.

[pcwalton]

Interesting. I'm working on tracking down some excess memory usage, so that might be the issue, but if not then I'll have to see what's causing the problem.

[trishume]

Screenshots of some other rendering problems with my GT 750m in Chrome. I don't know which of these problems are known and which aren't.

I can't get the demo to work in any of the Firefoxen I have installed. Loading the Nimbus Sans font doesn't appear to do anything at all. I've tried in a reasonably old Developer Edition and a recent Nightly.

[pcwalton]

Please try again; most of these are fixed now, aside from the missing triangle in the "o", which is a known issue.

[trishume]

Yah things are much much better now. Also I tried ECAA again and it didn't crash this time. I don't know whether something changed or it was something unusual about the earlier circumstances. SSAA looks sub-par to me but ECAA looks great. Also in ECAA instead of the triangle in the "o" being missing it is filled with black.

This is a "Wo" at high zoom, the diagonal of the W gets more and more straight as I zoom in, as if it is changing shape. Also SSAA is slow at high zoom, but that's expected I guess since it's rendering many times a retina display's worth of pixels.

This is the start of "the" at high zoom. As I zoom in, first the top of the "t" gets taller, then it turns into a box. Basically all sorts of weird changes to glyphs start happening at high zooms.

[pcwalton]

SSAA (supersampling) isn't good for normal text; people expect analytic AA. I have SSAA as an option in the demo for several reasons:

1. For general vector graphics or text in 3D scenes, SSAA should be more acceptable. Flash, for example, used SSAA.

2. ECAA is currently incompatible with any transformation that makes vertical edges not vertical, which precludes rotation or use in 3D scenes without repartitioning paths. SSAA has no such limitation.

3. ECAA requires extensions beyond OpenGL ES 2 (specifically, half float color framebuffers), so the lowest of the low end GPUs (e.g. the Raspberry Pi's VideoCore IV) are stuck with SSAA. SSAA is so simple that I suspect it could even be ported to some fixed function GPUs!

The issues at extremely high zoom are just the result of running out of space in the atlas, which currently has a fixed size. The composite step tries to read outside the bounds of the atlas texture, which causes GL_CLAMP_TO_EDGE wrapping behavior to kick in. To fix, we can (a) cap the zoom size so that it refuses to zoom if doing so would overflow the atlas; (b) grow the atlas as necessary, which has memory usage implications; (c) clip glyphs that are partially out of view in the atlas.

[trishume]

Text ECAA hasn't crashed for me in a while, and looks good now with subpixel AA. Although I haven't done a side-by-side comparison with Core Text yet. I imagine subpixel positioning is planned to get rid of the wiggling during pinch-zoom on non-retina displays.

The 3D demo also works and is really cool, although the text layout isn't as good as the text demo.

However, I did just crash my graphics drivers again by trying to enable the "ECAA (broken)" on the SVG demo. It beachballed for a couple seconds, then the mouse dissapeared, and then it crashed to a login screen. That progression suggests your hypothesis of excess memory usage may be right.

I've been enjoying trying it out every once and a while and seeing all the progress. Awesome work.

[pcwalton]

Thanks! It won't look quite as good as Core Text until I implement slight hinting (i.e. pixel snapping the x-height of each glyph). That shouldn't be hard. I believe the kerning is a bit wrong in the text mode because the uv positions in the atlas are failing to take left side bearing into account somewhere.

[pcwalton]

Slight hinting has been implemented.

The zoom level is now capped, so the atlas should no longer run out of space.

The 3D demo text layout has been fixed.

[trishume]

Yah it looks great now. The text looks great, and the 3D demo is really cool, especially with the new SSAA on.

The 4x SSAA SVG demo takes ~20ms per frame on my 4k monitor, but I'm not that surprised, it's a lot of pixels. The 3D monument renders just under 16ms unless I look at two sides of the monument at once, at which point it drops closer to ~20ms.

Even without antialiasing if I zoom in on the tiger I'm getting around ~10ms per frame, which seems slower than your old Metal-based demo performed on more complex scenes. I'm guessing that's due to all the fragment shading the new method needs for diagonal lines, which can be fixed by generating tighter bounding polygons than rectangles.

And I did notice one bug, which is that in the default text demo settings, ascenders of letters like 'd' and 'h' overwrite a little bit of the descender of the g because their glyph rects overlap the bottom of the 'g' even though the actual ascender doesn't.

[pcwalton]

The bounding rectangles issue doesn't apply to SSAA, which is just Loop Blinn. I'm not sure why it's so slow (it's slow for me, too), but I suspect it may either have to do with early Z not working for whatever reason, or the partitioner producing inefficient partitions. Note that some of the partitions are incorrect right now due to the lack of a winding fill rule and problems with intersection of curves. It is also possible that vertex shading load is causing the problem, which should be fixable (note that WebGL 1 provides fewer opportunities for vertex shading optimization than WebGL 2/GLES 3/Metal do).