Fragment Shader of FP16 produces incorrect image drawing.

[Pekka Paalanen]

On Tue, 21 Nov 2017 17:08:51 +0900
YoungJun Jo <dtoartist at gmail.com> wrote:

> Hi,
> 
> The uploaded image was not capture using the camera or mobile phone.
> I captured image using the screenshot program.
> So that's not related display signals or illusion or the human vision.
> The triangle error is shown in the top-right area when you see the image
> with the original image state of 100% without scaling, that is 1280*720
> size.
> Download image and open with your program, do not resize.
> 
> As mentioned in the previous mail, changing the logic to from GL_LINEAR
> to GL_NEAREST in *draw_view()* function, the incorrect drawing
> of the triangle has disappeared. I have done the tests using pixman render,
> so all RGB data values ​​are exactly the same.
> I would like to know that this is related to the GPU's fragment shader fp16
> constraint.
> 
> I linked the original image, error image and my analysis as shown below.
> original-image
> <https://www.dropbox.com/s/pldq7z4qnxn7kmn/CycleLineImage.png?dl=0>
> error-image
> <https://www.dropbox.com/s/xq7qtvxn7ejrirj/CycleLineImage_shot_screen.png?dl=0>
> analysis excel file
> <https://www.dropbox.com/s/dgxluifv10j8zh7/CycleLineImage%20from_0_to_90line_20170919.xlsx?dl=0>
> 
> If you think that this issue is not related to weston, you can ignore it:-)

Hi,

ok, now I see: the "triangle" is a red herring, irrelevant.

The actual problem are the pixel values and the difference cannot (on
my devices at least) be seen with a naked eye. When I inspected the
error-image in Gimp, the pixel channel values indeed differ from 0 or
255.

This is a renderer problem, as far as I can see. The renderers are
supposed to use linear texture interpolation only when the image is
transformed, and use nearest when it is only translated. I suppose the
detection of pure translation might not be perfect.

I'm not sure what you mean by testing on Pixman-renderer, because the
GL_* things are never used there. They are different renderers, they
interpolate and sample with different code. They are supposed to
produce the same output, but with OpenGL I don't think that can ever be
strictly true.

But yes, it makes sense now. How to fix it, I'm not sure.

As said, Weston does not do math with texcoords in the fragment shaders,
it just uses the interpolated coordinates from the vertex shader
directly. The vertex shared does not compute with the texcoords either.
If the issue is really caused by the coordinate interpolation on the
fragment shader inputs, I wouldn't know what to do. It seems Jasper had
some idea.

If fixing it is as simple as changing "precision mediump" to "highp", I
suppose we'd be happy to take that patch.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171121/176bf1ea/attachment.sig>