[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

--- Comment #5 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Dan Sebald from comment #0)
> 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.

libGL has no idea what's built. It's told by your X server (via DRI2) that it
should look for a DRI driver called "nouveau", so it looks for
"nouveau_dri.so".

> 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?

For those of us still getting with the program... let's say that
max_texture_size = 128 (for simplicity). Is the situation that you have a (say)
256-pixel wide image that you're feeding to glDrawPixels to be put onto a
128-wide texture, and you're using glPixelZoom(0.5) to achieve this?

-- 
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/3cdea373/attachment-0001.html>