Drivers/Gallium/swrast: Pixel image limited to GL_MAX_TEXTURE_SIZE
Submitted by Dan Sebald
Assigned to mes..@..op.org
Description
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?
Version: git