https://bugs.freedesktop.org/show_bug.cgi?id=89622
--- Comment #5 from Ilia Mirkin <imir...@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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
