<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Drivers/Gallium/swrast: Pixel image limited to GL_MAX_TEXTURE_SIZE" href="https://bugs.freedesktop.org/show_bug.cgi?id=89622#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Drivers/Gallium/swrast: Pixel image limited to GL_MAX_TEXTURE_SIZE" href="https://bugs.freedesktop.org/show_bug.cgi?id=89622">bug 89622</a> from <a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> Ilia Mirkin</a> <pre>(In reply to Dan Sebald from <a href="show_bug.cgi?id=89622#c0">comment #0</a>) > 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: > > <a class="bz_bug_link bz_status_NEW " title="NEW - Drivers/DRI/swrast" href="show_bug.cgi?id=89586">https://bugs.freedesktop.org/show_bug.cgi?id=89586</a> > > 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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>