[Webkit-unassigned] [Bug 52311] [chromium] Add command-line flag to enable composite to offscreen texture.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Feb 8 15:29:59 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=52311





--- Comment #56 from W. James MacLean <wjmaclean at chromium.org>  2011-02-08 15:29:59 PST ---
Here's a shot in the dark - feedback is appreciated ...

Hypothesis: the failing pixels are due to precision limitations in the shader computations (most likely the fragment shader, but possibly a combination of both). This becomes pronounced when trying to sample a large texture in a single chunk.

For Desktop GL we get max 23 bits (float mantissa) for shader floats, although for OpenGLES we're only guaranteed 2^(-10) precision in fragment shaders using mediump (i.e. 10 bits, highp not guaranteed to be available).

Observation: The failures always seem to occur when (i) rendering pixels with large x or y values (i.e. close to 1.0 normalized), (ii) always at high contrast edges (usually 0 -> 255 transitions from what I've seen), and (iii) in some cases it is most tenacious when two or more textures are composited together. (iv) All the tests render properly on my Mac workstation.

Some Numbers (back-of-the-envelope calculations only):

# of bits required (for the texture coordinate) to safely linearly sample across a 0->255 boundary, assuming rounding: 9 bits (must be off by less than 0.5 of an intensity value).

# of bits to represent an 800 pixel-wide texture = 10 bits

That's about 19 bits ... and we also have to account for errors in accumulating transforms, etc. Could we be just hitting the limit of precision of the GPUs? (Does the FX380 in the Linux z600 have poorer precision than the card in the Mac? The Radeon card in my Mac guarantees IEEE standard) Even if this is not the problem for the desktop GL cards, it may well be for OpenGL ES implementations on mobile devices.

Rendering direct to display may suffer from the same problem, but it's not so obvious since the baselines are done w.r.t. this case.

Note that as texture coordinates approach 1.0, the effective resolution drops (e.g. we can easily represent 0.0 + 2^(-23) but not so easily 0.9 + 2^(-23), so perhaps this explains why the problem becomes more prevalent as the coordinates move to the right/up (close to 1.0).

If this is true, then the fact that NEAREST sampling solves most of the cases is not surprising.

Conclusion: This *may* be a problem that is not due to any error in the code. It may also be that it will reduce/disappear when tiling is applied to all layers (although the notion of fuzzy testing may need consideration too).

We can try to devise appropriate tests if the idea seems worth further investigation.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list