<div dir="ltr"><div class="gmail_default"><div class="gmail_default"><font face="georgia, serif">Dear all,</font></div><div class="gmail_default"><font face="georgia, serif"><br></font></div><div class="gmail_default"><font face="georgia, serif">In the weston environment, there is a problem when displaying a specific image using the GPU(Fragment Shader(FS) only supports FP16).<br></font></div><div class="gmail_default"><font face="georgia, serif">In fact, I think it's not common case to use a GPU with FS of FP16 constraints in a desktop environment, so I was worried about asking question.<br></font></div><div class="gmail_default"><font face="georgia, serif"><br></font></div><div class="gmail_default"><font face="georgia, serif">The specific image which the error occurs is an image with black vertical lines and white vertical lines arranged at 1 pixel intervals.<br></font></div><div class="gmail_default"><font face="georgia, serif">I modified the weston-image code to display fullscreen to better observe where the error occurred.<br></font></div><div class="gmail_default"><font face="georgia, serif"><br></font></div><div class="gmail_default"><div class="gmail_default"><font face="georgia, serif">When I display the image on the screen, I get a triangle-shaped wrong drawing during the time of the fade animation in the top-right part. (Please refer to attachment 'cycleline-error.png')</font></div><div class="gmail_default"><font face="georgia, serif"><br></font></div><div class="gmail_default"><font face="georgia, serif">First, I contacted the GPU vendor about this issue and got the following answer:</font></div><div class="gmail_default"><font face="georgia, serif">---</font></div><div class="gmail_default"><div class="gmail_default"><font face="georgia, serif">I'm pretty sure the issue is that your texture coordinates are being converted to fp16 because arithmetic is being performed on them before they are used. For fp16 values above the 0.5 limit on the texture coordinate the fp16 "increment" between values is 2^-11, or about 0.000488. For a texture which is 1024 pixels wide this give an sample point accuracy of only +- half a pixel width which is insufficient for accurate sampling (especially when using GL_LINEAR filtering).</font></div><div class="gmail_default"><font face="georgia, serif">Short answer: don't do maths on texture coordinates in the fragment shader.</font></div><div class="gmail_default"><font face="georgia, serif">---</font></div><div class="gmail_default"><font face="georgia, serif">Based on the above answer, I would like to confirm whether the exception handling is appropriate for animation in the condition that FS is FP16 in weston's gl-renderer.<br></font></div></div><div><font face="georgia, serif">In addition, I have found one way to prevent such incorrect rendering.<br></font></div><div><font face="georgia, serif">When i remove the <i>weston_matrix_init(&animation->transform.matrix)</i> in <i>weston_view_animation_create()</i> function;, The error does not occur and the animation effect is shown.</font></div><div><font face="georgia, serif">In Android(I do not know if it is appropriate to compare), since there is no matrix operation during animation, wrong drawing does not occur.<br></font></div><div><font face="georgia, serif">So I would like to know whether the matrix operation in weston animation is necessary or can be removed.<br></font></div><div><font face="georgia, serif">Or is there another good way to avoid the above precision errors?</font></div><div><font face="georgia, serif"><br></font></div><div><font face="georgia, serif">My debugging and analysis may be wrong, so I would appreciate any feedback.<br></font></div><div><font face="georgia, serif"><br></font></div><div><font face="georgia, serif">Regards,</font></div><div><font face="georgia, serif">yj</font></div></div></div></div>