[Mesa-dev] [Bug 89622] Drivers/Gallium/swrast: Pixel image limited to GL_MAX_TEXTURE_SIZE

[bugzilla-daemon at freedesktop.org]

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

            Bug ID: 89622
           Summary: Drivers/Gallium/swrast: Pixel image limited to
                    GL_MAX_TEXTURE_SIZE
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
          Assignee: mesa-dev at lists.freedesktop.org
          Reporter: daniel.sebald at ieee.org
        QA Contact: mesa-dev at lists.freedesktop.org

First, I want to point out that building Mesa from scratch *without* the
options

--with-dri-drivers=nouveau --with-gallium-drivers=nouveau

produces no nouveau_dri.so library file.  There is a nouveau_vieux_dri.so, but
no nouveau_dri.so.  When I then run an app that accesses this newly built mesa
library files I see the warning message:

libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: nouveau

It's no harm of course, but if this should not be happening--given
nourveau_dri.so--wasn't built, I'll file a bug report.

OK, I filed a bug report about vertical white lines in the legacy swrast_dri.so
associated with intervals of GL_MAX_TEXTURE_SIZE in the x dimension of the
input image:

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

I then went to try the newer Gallium version of the software implementation and
found that a limitation is placed on the size of the input image to
GL_MAX_TEXTURE_SIZE.  This can be seen in frame buffer images I will attach,
Screenshot-incomplete_image_x-dimension.png and
Screenshot-incomplete_image_y-dimension.png where only a portion of the
gradient image appears.  The source of this limitation is in
src/mesa/state_tracker/st_cb_drawpixels.c.  Out of curiousity, I removed the
limitation as follows:

--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -1110,14 +1110,6 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,

    st_validate_state(st);

-   /* Limit the size of the glDrawPixels to the max texture size.
-    * Strictly speaking, that's not correct but since we don't handle
-    * larger images yet, this is better than crashing.
-    */
-   clippedUnpack = *unpack;
-   unpack = &clippedUnpack;
-   clamp_size(st->pipe, &width, &height, &clippedUnpack);
-
    if (format == GL_DEPTH_STENCIL)
       write_stencil = write_depth = GL_TRUE;
    else if (format == GL_STENCIL_INDEX)

and the result is that the image comes out fine.

So, what is the problem here?  Is it that not all systems are ensured to have
non-paged memory, and my system just happens to have it?  Can this be tested
and adjusted accordingly?  More generally, it seems that the Gallium version of
pixel zoom/draw can be done in a more straightforward way than legacy swrast is
doing.  Notice that Gallium is treating the image as blocks (i.e., the clip
affects both width and height).  It shouldn't be difficult to write a double
loop to write to the frame buffer in blocks (unless there is a problem of not
being able to select the memory page in the st_DrawPixels() routine because
that is done prior to the function call).  What role does the st->pipe play in
affecting size of writes?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150318/7ccb64ba/attachment-0001.html>