<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">Hi Jasper,</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default"><font face="georgia, serif">Unfortunately, my GPU supports FP32 in the vertex shader, but only FP16 in the fragment shader.</font></div><div class="gmail_default"><font face="georgia, serif">I have changed from 'precision mediump' to 'precision highp' according to your advice, but the problem has not been solved.</font></div><div class="gmail_default"><font face="georgia, serif">The fixed-point interpolation you mentioned is already included in the pipeline as a result of asking the GPU vendor.</font></div><div class="gmail_default"><br></div><div class="gmail_default"><div class="gmail_default" style="font-family:georgia,serif">I received answer about "normalized GL_SHORT texture coordinates" from GPU vendor as below:</div><div class="gmail_default" style="font-family:georgia,serif">---</div><div class="gmail_default"><font face="georgia, serif">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.</font><br></div><div class="gmail_default"><font face="georgia, serif">---</font></div><div class="gmail_default"><font face="georgia, serif">According to the above, the gl-renderer currently does not perform any math, so the precision problem should not occur.<br></font></div><div class="gmail_default"><font face="georgia, serif">Can you help me with what I can fix or test?</font></div></div><div class="gmail_default"><br></div><div class="gmail_default"><font face="georgia, serif">Regards,</font></div><div class="gmail_default"><font face="georgia, serif">yj</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-11-21 19:28 GMT+09:00 Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 21 Nov 2017 17:08:51 +0900<br>
YoungJun Jo <<a href="mailto:dtoartist@gmail.com">dtoartist@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> The uploaded image was not capture using the camera or mobile phone.<br>
> I captured image using the screenshot program.<br>
> So that's not related display signals or illusion or the human vision.<br>
> The triangle error is shown in the top-right area when you see the image<br>
> with the original image state of 100% without scaling, that is 1280*720<br>
> size.<br>
> Download image and open with your program, do not resize.<br>
><br>
> As mentioned in the previous mail, changing the logic to from GL_LINEAR<br>
</span>> to GL_NEAREST in *draw_view()* function, the incorrect drawing<br>
<span class="">> of the triangle has disappeared. I have done the tests using pixman render,<br>
> so all RGB data values ​​are exactly the same.<br>
> I would like to know that this is related to the GPU's fragment shader fp16<br>
> constraint.<br>
><br>
> I linked the original image, error image and my analysis as shown below.<br>
> original-image<br>
</span>> <<a href="https://www.dropbox.com/s/pldq7z4qnxn7kmn/CycleLineImage.png?dl=0" rel="noreferrer" target="_blank">https://www.dropbox.com/s/<wbr>pldq7z4qnxn7kmn/<wbr>CycleLineImage.png?dl=0</a>><br>
> error-image<br>
> <<a href="https://www.dropbox.com/s/xq7qtvxn7ejrirj/CycleLineImage_shot_screen.png?dl=0" rel="noreferrer" target="_blank">https://www.dropbox.com/s/<wbr>xq7qtvxn7ejrirj/<wbr>CycleLineImage_shot_screen.<wbr>png?dl=0</a>><br>
> analysis excel file<br>
> <<a href="https://www.dropbox.com/s/dgxluifv10j8zh7/CycleLineImage%20from_0_to_90line_20170919.xlsx?dl=0" rel="noreferrer" target="_blank">https://www.dropbox.com/s/<wbr>dgxluifv10j8zh7/<wbr>CycleLineImage%20from_0_to_<wbr>90line_20170919.xlsx?dl=0</a>><br>
<span class="">><br>
> If you think that this issue is not related to weston, you can ignore it:-)<br>
<br>
</span>Hi,<br>
<br>
ok, now I see: the "triangle" is a red herring, irrelevant.<br>
<br>
The actual problem are the pixel values and the difference cannot (on<br>
my devices at least) be seen with a naked eye. When I inspected the<br>
error-image in Gimp, the pixel channel values indeed differ from 0 or<br>
255.<br>
<br>
This is a renderer problem, as far as I can see. The renderers are<br>
supposed to use linear texture interpolation only when the image is<br>
transformed, and use nearest when it is only translated. I suppose the<br>
detection of pure translation might not be perfect.<br>
<br>
I'm not sure what you mean by testing on Pixman-renderer, because the<br>
GL_* things are never used there. They are different renderers, they<br>
interpolate and sample with different code. They are supposed to<br>
produce the same output, but with OpenGL I don't think that can ever be<br>
strictly true.<br>
<br>
But yes, it makes sense now. How to fix it, I'm not sure.<br>
<br>
As said, Weston does not do math with texcoords in the fragment shaders,<br>
it just uses the interpolated coordinates from the vertex shader<br>
directly. The vertex shared does not compute with the texcoords either.<br>
If the issue is really caused by the coordinate interpolation on the<br>
fragment shader inputs, I wouldn't know what to do. It seems Jasper had<br>
some idea.<br>
<br>
If fixing it is as simple as changing "precision mediump" to "highp", I<br>
suppose we'd be happy to take that patch.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div>