[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] MAX_FRAGMENT_INPUT_COMPONENTS seems to return uninitalized memory



Yes, thanks for the heads up. Scanning Chromium's code and running some quick tests didn't turn up any obvious bug, so any more details you can provide would be helpful.

-Ken


On Thu, Jul 6, 2017 at 3:20 PM, Kai Ninomiya <kainino@google.com> wrote:
Florian, thanks for this heads up. Are you able to glean any details from your data - e.g., is it specific to a particular browser, OS, or GPU vendor? Otherwise, finding a reproduction case will be a wild goose chase until we can learn more about the bug.

-Kai

On Thu, Jul 6, 2017 at 2:51 AM Florian Bösch <pyalot@gmail.com> wrote:
Due to a large number of individual values being returned by the parameter MAX_FRAGMENT_INPUT_COMPONENTS webglstats updates failed for a few days. I have a filter mechanism for such erroneous values (which is fairly extensive for WebGL1, though it seems no longer required there as values returned there seem mostly well-formed).

However in WebGL2 this parameter seems to return uninitalized memory. Here is a small sample of values observed:

 -1788917824
 -1788916160
 -1786396928
 -1777804032
 -1775925664
 -1771568320
 -1771532704
 -1764617920
 -1758531200
 -1755832928
 -1754378656
 -1749930016
 -1748075776
 -1747997792
 -1737351904
 -1730633088
 -1721286400
 -1719047200
 -1718632576
 -1694800800
 -1670866528
 -1650593120
 -1648639264
 -1622535360
 -1622534016
 -1581364896
 -1572312000
 -1572281472
 -1330485792
 -1299065344
 -1252403712
 151689120
 263489344
 286266272
 300064872
 302099488
 307719328

I have filtered this parameter now and webglstats update should be progressing as per usual. The underlying implementation error likely still exists and would warrant WebGL vendors to investigate.