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@lists.freedesktop.org
Reporter: daniel.seb...@ieee.org
QA Contact: mesa-dev@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
