attached image:
what I see on linux. Circled: wrong values (side effects of other component).

Deleted: p8JHLXB.png 17.9 KB

	p8JHLXB.png 17.9 KB View Download

Tested this issue on reported chrome 68.0.3440.75 and latest chrome stable 68.0.3440.84 using Ubuntu 17.10. Attaching screen-cast for reference.
Steps:
------
1. Launched reported chrome
2. Navigated given URL " https://www.shadertoy.com/view/MttczS "
3. Observed the values 
As we are observed that different values 

@Reporter: Requesting you to please check and confirm if anything is missed from our end in triaging the issue. As we are not sure about the issue if possible provide screen-cast it will help us for further investigating it.
Could you please upgrade to latest chrome stable 68.0.3440.84, you can download latest chrome builds 
here:" https://www.chromium.org/getting-involved/dev-channel ".  

Thanks..!

Deleted: 869615.webm 7.4 MB

	869615.webm 7.4 MB View Download

This is not a good bug report. What is a "buffer" in this terminology? Is it a texture which is procedurally generated on ShaderToy?

A better reduced test case is needed which is outside of ShaderToy. Some similar sample test cases can be found here:
https://github.com/KhronosGroup/WebGL/tree/master/sdk/tests/conformance2/rendering

and here:
https://github.com/KhronosGroup/WebGL/tree/master/sdk/tests/conformance2/glsl3

In the conformance2/glsl3/ directory and harness, it's possible to write shaders that do rendering tests, for example:
https://github.com/KhronosGroup/WebGL/blob/master/sdk/tests/conformance2/glsl3/short-circuiting-in-loop-condition.html

Outputting opaque green (0, 1, 0, 1) causes the test to pass.

@ phanindra
strange. 
What is your GPU  ? here, nvidia (2 different on laptop & desktop), driver 396.45
my chrome is now Version 68.0.3440.84 (Build officiel) (64 bits), bug still there.

@kbr:
yes, shadertoy "buffers" are textures written by a 1st shader (cf tabs).
About using Shadertoy: sorry, it's the only tool I have. ( Some other participants here are usually happy with my shadertoy-based acid tests ;-) )

fabrice.neyret@: ShaderToy might be setting sampling parameters on these textures in such a way that you are observing interpolation between adjacent texels.

I'm sorry but we don't have the time to reduce this test case. Please reopen this bug if you can make the time to do so.

@kbr: 
no it's not interpolated. beside, I use texelFetch.

please let this open up to olli says something about it: he is the guy who knows, on these kind of topics.

OK. Olli, do you have time to triage and potentially reduce this?

Unfortunately I won't have time to look at this, unassigning myself.

Fabrice, thanks for the repro.

Would you be able to make a bit reduced version of the testcase, since you know it better than me?

Some tips, check if applicable:
- document a simple comment on what the thing does in high level
- make the repro demonstrate the failure by default. (This repro does, some others required some edits)
- instead of using all color channels, use just the ones that reproduce an issue
- reproduce one issue per repro. E.g. don't say "uncomment this to create this variance, swap this to that in order create that variant."
- don't use elaborate macros that expand to other macros that call functions. Unless the bug is in the macro, just write plain code. if it repeats, to a degree, repeating is better than requiring the reader to do proprocessor expansion in their head.
- be extra careful of the undefined behavior
- imo the analysis ui does not need to be present on the repro. simply component on == ok, component off = bug is informative and simple, or some sort of derivation of that (green=ok, red=failure).

For this particular repro: 

I can repro the white pixels on NV 416.34 GTX1080. However, it's not clear this is not undefined behavior.

If you test uintToFloat with particular value, be sure to add a simple comment what you expect the values to be in float, e.g. what you expect the function to return. I think some of the values might be undefined: 0xFFFF0000 as float might be undefined? 

I'm not an expert, but I seem to remember conditional texture fetches having undefined behavior with non-uniform control flow. So maybe make sure that the reader would see that it's obvious that there's no such undefinedness bugs in the repro case. Possibly textureFetch does not suffer from this, but it's hard to analyze with all the macros.

It is sort of probable that there's no bug in uintToFloat -> buffer -> floatToUint. It might be that the incorrect values hit the buffer. Alternatively, the correct values hit the buffer, but the load/conversion is the problem. So you might try to repro these two in isolation: A) Generate the values to the buffer in normal terms, but visualize the values in the repro terms. B) Generate the values in the repro terms, but visualize the values in normal terms.

On 21/01/2019 13:13, kkinnu… via monorail wrote:

bug seems multiple. -> I've isolated a first case implying const uvec 
conversion.  new acid test:

https://www.shadertoy.com/view/wdSGRh

new bug report:

https://bugs.chromium.org/p/chromium/issues/detail?id=923949