Fragment Shader of FP16 produces incorrect image drawing.

[YoungJun Jo]

Hi Jasper,

Unfortunately, my GPU supports FP32 in the vertex shader, but only FP16 in
the fragment shader.
I have changed from 'precision mediump' to 'precision highp' according to
your advice, but the problem has not been solved.
The fixed-point interpolation you mentioned is already included in the
pipeline as a result of asking the GPU vendor.

I received answer about "normalized GL_SHORT texture coordinates" from GPU
vendor as below:
---
Shouldn't make any difference - as long as your texture coordinates into
the shader are fp32 (highp) and there is no maths in the fragment shader on
the coordinate you should have enough precision.
---
According to the above, the gl-renderer currently does not perform any
math, so the precision problem should not occur.
Can you help me with what I can fix or test?

Regards,
yj

2017-11-21 19:28 GMT+09:00 Pekka Paalanen <ppaalanen at gmail.com>:

> 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171127/d324a462/attachment.html>