GLSL bug: MIPmap of non-power-of-two does it wrong next to odd size LOD
Reported by
fabrice....@gmail.com,
Dec 11 2017
|
||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36 Example URL: https://www.shadertoy.com/view/llsfRs Steps to reproduce the problem: Observe how texture MIPmap LOD looks like next to a level of odd size. Especially with acid-test textures like checkboards or power-of-2 tiles (as in the link. In BufA you can switch TEST value). What is the expected behavior? Something reasonable (even if no efficient filtering scheme will do a perfect filtering). What went wrong? Trouble occurs when filtering a LOD which has an odd size. See the 2 captures in the bottom of the forum associated to the link https://www.shadertoy.com/view/llsfRs : - sometime the left column of pixels is totally wrong (seems not filtered) - the resampling cause an horizontal sliding artifact for vertical odd size ! ( same for swapped situation). Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? No Firefox Chrome version: 63.0.3239.84 Channel: stable OS Version: Flash Version: Shockwave Flash 27.0 r0 Appears on linux and windows and different browsers, but with not the exact same look. May somebody please set the tags Blink>WebGL, Internals>GPU ? thanks ! Note that MIPmap on float render target allows multiscale integration that can be used for many purposes (counting, testing collisions, computing covariance matrix of images for tracking, or get image statistics). But shifting artifacts or error in first line/row can totally corrupt the result at some buffer resolution.
,
Dec 12 2017
,
Dec 12 2017
No: you started with 512 x 288 resolution ( = 2^9 x 9*2^5 , so it is quite gentle ). I suggest to enlarge your window to start like me in 640 x 360 (360 = 45*2^3, lesser "power of two"), then see level 4. this is for bug1: the erroneous line on left. Now for bug 2 , just switch the bufA #define TEST to 2, and see what happen between level 3 and 4: the horizontal shift/blur, while the rounding should occur in vertical direction.
,
Dec 12 2017
Today I also did some tests on windows. - on Angle, by default firefox and chrome do a far good job, with accurate resampling at every levels - for some tunings of firefox (sorry, not sure witch), I once got a brutal clamping to rounded lower even resolution. - I would have like to try true openGl on windows, but it seems the tricks proposed online for that are too old and no longer working. Hints ?
,
Dec 12 2017
,
Dec 13 2017
* In "What went wrong?", "next to odd LOD size" is crucial. I should have stress it by recommending to try window resolution 640x360 and look level 4, as in my grabs.
,
Dec 13 2017
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 13 2017
* Another even better acid-test: [url]https://www.shadertoy.com/view/lllfDS[/url] To be tested at resolution 640x360 as well. Here, I draw lines only in one texture column, and watch color present in ultimate MIPmap level. For resolution 640x360 , on linux on chrome and firefox, columns 600 to 639 are just ignored in the final sum, and columns 0 to 23 weight 300% of what they should in the final sum. * BTW, could somebody add tag Blink>WebGL ? thanks !
,
Dec 14 2017
,
Dec 14 2017
Submitter: 1) Please provide about:gpu from your system. 2) You can use --use-angle=gl on Windows in order to use ANGLE's OpenGL backend. This is the only supported code path for using OpenGL on Windows in Chrome. 3) It's not obvious to me whether ShaderToy is using the built-in glGenerateMipmap or some other mechanism for filtering non-power-of-two textures. 4) It seems very possible that you're running into poor mipmap implementations for non-power-of-two textures on various graphics drivers. We can work on adding stricter conformance tests for this, but it will take quite some time for drivers to be fixed. 5) It would be more helpful if you could provide self-contained codepens rather than ShaderToy examples, like those for http://crbug.com/794035 . ShaderToy does a lot behind the scenes, and when trying to diagnose bugs like these, the smallest possible reproduction case is needed. As an aside, on the macOS laptop I use (older model with an NVIDIA GPU) there are enough bugs in the graphics driver that your samples don't render correctly. See attached screenshot. On the other hand these machines aren't close to passing the WebGL 2.0 conformance suite but they do run a lot of content.
,
Dec 14 2017
,
Dec 15 2017
1) see next comments 2) ok, thanks ! -> on windows, OpenGL mode have the same bug as in linux. 3) ShaderToy do use the built-in glGenerateMipmap ( cf lib/piLibs.js:681 ) 4) conformance, drivers issue: yes. Do you have a way to report this at best appropriate places ? 5) sorry, I can't. I currently practice webGl only through shadertoy. But, there is not much behind the scene in shadertoy: the header/footer added to mainImage is minimalistic: cf js/effect.js:44 : map the Uniforms, init col to vec4(0,0,0,1), call mainImage, set col.w to 1 and map to outColor. (ok, textures settings are elsewhere).
,
Dec 15 2017
Thank you for providing more feedback. Adding requester "kbr@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 15 2017
about:gpu - on my desktop ubuntu16 - on my laptop ubuntu14 - on windows with Angle - on windows with OpenGL (same machine same browser than for angle) all are (different) nVidia boards.
,
Dec 15 2017
NB: in comment8 https://bugs.chromium.org/p/chromium/issues/detail?id=793933#c8 I give another shadertoy testing a cousin problem under another aspect, showing different bad behaviors on openGl vs linux. (summary: parts of the texture do not contributes at all to highest MIPmap levels, others weight triple of what they should). -> should I make it a different bug report ?
,
Dec 15 2017
Submitter, the mipmap generation algorithm in OpenGL ES is not tightly defined. From the ES 3.0.5 spec, section 3.8.10.5 "Manual Mipmap Generation", page 160: "The contents of the derived arrays are computed by repeated, filtered reduction of the level_base array. For two-dimensional array textures, each layer is filtered independently. No particular filter algorithm is required, though a box filter is recommended." While I agree that you're seeing poor behavior of the algorithm, it seems highly unlikely that we will get traction from GPU vendors to improve the quality of implementation especially if it costs performance. Drivers tend to prize performance above everything else except when visual quality suffers noticeably. You seem to be the first person observing this behavior. Further, a specification change would be required in order to enforce the new behavior across vendors, and these are difficult to motivate. The best way for you to handle this would be to write a mipmap generation library in WebGL which does exactly the filtering you want using repeated draw calls and shaders. It will be GPU-accelerated and portable, and give you the behavior you want. CC'ing Olli Etuaho from NVIDIA in case there's a chance that they would be interested in revising their mipmap generation algorithm and tightening it up. If they are then we can reopen this. But unless that happens, I'm sorry, this is not an industry-wide change that the Chrome team can drive.
,
Dec 16 2017
A similar situation we ran into was mipmap generation for sRGB formats. Most drivers do it wrong (do interpolation in the wrong color space). Skia needs a better quality, so Chrome ended up emulate generateMipmap for that format. I agree with kbr that we don't want to do this in general because that's costly. Unless drivers want to improve, there is no further work from Chrome side.
,
Dec 16 2017
@kbr (and zmo): I agree this firstly is a vendor problem, and that perfs matters before exactness. Still, even in this scope, I believe the bugs I see here are not what the programmer intended to do, and that he might be interesting in fixing that with no perf change. (provided he have human cycles to spend of the topic). So forwarding the bug report to the appropriate vendor contacts is the best to do (if you know the right gates, Olli being apparently one :-) - thanks ). About the impact, the other test with color bands at different locations ( https://www.shadertoy.com/view/lllfDS ) suggests that real applications could suffer an inexplicated intensity or color drift or time flickering with LOD, e.g. when blurring light maps or render targets.Possibly without having identified the present issue as the cause.
,
Dec 18 2017
A yet even clearer and spectacular diagnostic: https://www.shadertoy.com/view/MtXBDf grey & colors show the contribution of each pixel to the uppest MIPmap levels. - white: correct weight of 1. light grey: ~1 - black: no contribution. dark: weight << 1. - colors: overweight. heat map red-violet: w = 1..10, then wrap with blink period = floor(w/10) On windows Angle, large image portions don't contribute at all to uppest MIPmap LODs, and some contribute up to 41 time too much ! (in full screen). On OpenGl it is way more reasonable: there is only a bug on the borders. Question: this diagnostic URL as well as the one in comment 8 are huge additions to the initial description, but not so visible to further investigations. -> - should this comment 19 + comment 8 be pasted to the initial description ? - or should I put them in a separate bug report ? - or is it perfect the way it is now ? thanks !
,
Dec 21 2017
Thanks for the new test case but we are swamped with more urgent bug reports and I don't see a path forward for us to motivate GPU vendors to improve the precision of their mipmap generation. So I think we should not file a new bug but leave this as is. If you want to urge GPU vendors to improve the precision of their mipmap generation then I would suggest you come up with some reasonable metric (obviously requiring exact computation is infeasible) and write a WebGL conformance test that catches the worst offenders. Put up a pull request at https://github.com/KhronosGroup/WebGL . We can motivate them to work on fixing it in future driver releases. I agree that it would be better for everyone if this basic functionality had tighter guarantees. |
||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||
Comment 1 by viswatej...@techmahindra.com
, Dec 12 20172.9 MB
2.9 MB View Download