<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - The big SKQP bug" href="https://bugs.freedesktop.org/show_bug.cgi?id=105301#c50">Comment # 50</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - The big SKQP bug" href="https://bugs.freedesktop.org/show_bug.cgi?id=105301">bug 105301</a> from <a class="email" href="mailto:dongseong.hwang@intel.com" title="Dongseong Hwang <dongseong.hwang@intel.com>"> Dongseong Hwang</a> <pre>(In reply to Tapani Pälli from <a href="show_bug.cgi?id=105301#c47">comment #47</a>) > (In reply to Kenneth Graunke from <a href="show_bug.cgi?id=105301#c46">comment #46</a>) > > (In reply to Dongseong Hwang from <a href="show_bug.cgi?id=105301#c45">comment #45</a>) > > > On the other hands, from implementation side, I think Aditya's change makes > > > sense and this change would be safe because > > > 1. it passes Piglit and deqp > > > 2. it restricts available functionality. > > > > How does removing a restriction "restrict available functionality"? > > I guess what he means is that when using TEXTURE_EXTERNAL_OES handle, there > is less functionality exposed. Of course at that at same time client can > still use the TEXTURE_2D handle with all functionality. So we are not really > restricting any functionality here. Yes, correct. EGL image based on EGL_KHR_gl_image has the full potential of functionality. The only read functionality is exposed with TEXTURE_EXTERNAL_OES target. > I'm not sure if we have fast clear and compression state stored so that one > could do resolve then switch them off (and never turn on again). If we allow > this then this is something we should probably do in this use case? From > client perspective this will result in un-optimal performance I'm not sure > if there are sensible options here :/ If unfortunately it's un-optimal performance from mesa driver perspective (we don't know it's true tho), the driver should respect the spec and the spec explicitly says TEXTURE_EXTERNAL_OES target can be used "ANY EGL image" described by GL_OES_EGL_image. <a href="https://www.khronos.org/registry/OpenGL/extensions/OES/OES_EGL_image_external.txt">https://www.khronos.org/registry/OpenGL/extensions/OES/OES_EGL_image_external.txt</a> Dependencies on GL_OES_EGL_image If GL_OES_EGL_image is supported then change the text in both extensions to allow either TEXTURE_2D or TEXTURE_EXTERNAL_OES to be passed as the <target> parameter to EGLImageTargetTexture2DOES(). When <target> is TEXTURE_2D, behavior of EGLImageTargetTexture2DOES() is as described in the GL_OES_EGL_image spec. When <target> is TEXTURE_EXTERNAL_OES, behavior of EGLImageTargetTexture2DOES() is as described in this spec. In my opinion, Intel has no excuse to Google about this conformance test failure, and a major product has been broken.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>