Fragment Shader of FP16 produces incorrect image drawing.

YoungJun Jo dtoartist at
Mon Nov 27 12:19:18 UTC 2017

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?


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

> On Tue, 21 Nov 2017 17:08:51 +0900
> YoungJun Jo <dtoartist at> 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
> > <>
> > error-image
> > <
> png?dl=0>
> > analysis excel file
> > <
> 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: <>

More information about the wayland-devel mailing list