[Mesa-dev] [Bug 93813] Incorrect viewport range when GL_CLIP_ORIGIN is GL_UPPER_LEFT

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93813

Jose Fonseca <jfonseca at vmware.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brianp at vmware.com,
                   |                            |jfonseca at vmware.com,
                   |                            |sroland at vmware.com

--- Comment #5 from Jose Fonseca <jfonseca at vmware.com> ---
(In reply to Ilia Mirkin from comment #3)
> A bit of potentially-relevant spec quote from ARB_clip_control:
> 
>     12) Does setting the clip control origin to GL_UPPER_LEFT change the
>         origin of the window coordinate system use for commands such as
>         glViewport, glScissor, glWindowPos2i, and glReadPixels?
> 
>         RESOLVED:  No.
> 
>         The (x,y) window space location passed to these commands have the
>         (0,0) origin at the lower left corner of the window, independent
>         of the state of the clip control origin.
> 
> Still unsure whether that rules in favor of Mesa or of the test case :)
> Hopefully someone more knowledgeable can weigh in.

Hi Ilia,

First of all, let me warn that I'm not an expert on this extension.  I
appreciate your perseverance getting to the bottom at this though.  In fact, we
(at VMware) actually ran into issues using this extension, but the person most
knowledgeable about it is currently on PTO.

FWIW, I looked into this, and the way I interpret it, the text of issue 12) is
actually conclusive evidence that Mesa is *wrong*:

- The attached draws a red rectangle covering the whole viewport, as xyzw
coordinates before clipping will be

    -1.0, -1.0, 0.5, 1.0
     3.0, -1.0, 0.5, 1.0
    -1.0,  3.0, 0.5, 1.0
     3.0,  3.0, 0.5, 1.0

  hence the expected rendering is that all pixels inside viewport will be red,
all outside will be black (the clear color)

- Issue 12) states that the _window coordinate system_ for glViewport should be
the same

- Hence, we should get the _exact_ same rendering, whether we comment or not
the 

    glClipControl(GL_UPPER_LEFT, GL_ZERO_TO_ONE)

  call in the attached example.

  That is, it should doesn't matter where's the clip origin, as the primitive
completely cover the viewport, and all fragments have the same color.  

- But that's not what's happening:

  - if one comments out glClipControl one gets the viewport pixels painted red

  - if one does not comment the glClipControl only some viewport pixels are
painted red, but some are painted black, which really shouldn't happen.




For reference, this are a few modifications I did to the attached sample to
better understand it:

--- fdo121191.c.orig    2016-02-09 11:37:33.122145252 +0000
+++ fdo121191.c    2016-02-09 11:40:23.597820907 +0000
@@ -68,7 +68,8 @@
     typedef void (APIENTRYP PFNGLCLIPCONTROLPROC) (GLenum origin, GLenum
depth);
     const auto glClipControl = reinterpret_cast<PFNGLCLIPCONTROLPROC>(
         SDL_GL_GetProcAddress("glClipControl"));
-    glClipControl(GL_UPPER_LEFT, GL_ZERO_TO_ONE);
+    // XXX: We should get the same rendering regardless we have 1 or 0 here
+    if (1) glClipControl(GL_UPPER_LEFT, GL_ZERO_TO_ONE);

     GLuint texture;
     glGenTextures(1, &texture);
@@ -160,7 +161,12 @@

     assert(glGetError() == GL_NO_ERROR);

-    std::cout << colours[0] << ", " << colours[2] << "\n";
+    for (unsigned y = 0; y < textureSizeY; ++y) {
+        for (unsigned x = 0; x < textureSizeX; ++x) {
+            std::cout << colours[y*textureSizeX + x] << "\t";
+        }
+        std::cout << "\n";
+    }
     // This was outside the viewport, so should be black from the clear
     assert(colours[0] == 0.0f);
     // This was inside the viewport, so should be red from the draw

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160209/058705da/attachment.html>