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

Worrying about mmu-less (or non-page-on-demand) issues is not something we do.

Basically st_DrawPixels takes the pixel data, sticks it into a texture, and
then uses shaders to texture that onto the framebuffer. Obviously the texture
can't be larger than MAX_TEXTURE_SIZE. However no harm done if you cut up the
source data into MAX_TEXTURE_SIZE-sized blocks and discarded fragments that
were not going to be covered by that texture slice (or even better, set the
viewport or scissors appropriately). If you were going to be sneaky, you could
even concoct some scheme to use a 2d array texture, although ultimately even
that has limits.

I don't immediately see a way to transfer a non-0,0-origin block of pixels from
memory into a texture, but I'm sure it's reasonably easy to do, and a helper
probably exists for some other functions. (Maybe it can be specified as a
gl_pixelstore_attrib? It has a SkipRows/SkipPixels attribute.)

-- 
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/0608f463/attachment.html>