On 03/11/2013 06:23 PM, Marek Olšák wrote:
On Mon, Mar 11, 2013 at 6:49 PM, Ian Romanick <i...@freedesktop.org> wrote:
Once upon a time Matt Turner was talking about using pixman to accelerate
operations like this in Mesa. It has a lot of highly optimized paths for
just this sort of thing. Since it's used by other projects, it gets a lot
more testing, etc. It may be worth looking at using that to solve this
problem.
I think that using pixman or any other CPU-based solution is a waste
of time (for dedicated GPUs at least). The OpenGL packing and
unpacking can be implemented entirely on the GPU using streamout and
TBOs, and we generally only want memcpy on the CPU side. That would
also allow us to finally accelerate pixel buffer objects.
That's probably true for dedicated GPUs. I suspect it depends a lot on
the hardware and how the driver implements the mappings, etc. I know
some of the closed-source drivers can still implement glMapBuffer and
friends by giving the app some malloc'ed memory and doing a copy to some
GPU memory. In those cases, you can still get the conversion for free
during the copy.
For now, the easiest and fastest solution is to do a blit, which
should cover swizzling and format conversions. We just need a lot of
texture formats or do swizzling in the fragment shader. The
destination of the blit can be a temporary texture allocated in GTT.
The author of the patch (at least I think it's him) has actually
started working on the blit-based solution for ReadPixels in st/mesa
and the time spent in ReadPixels went from 2300 ms to 9 ms (so he can
still use additional 7.6 ms for rendering and be at 60 fps).
The tricky part for a pure-GPU implementation is all the @#$&*! pixel
packing modes. That's where having a faster fallback using a robust
library like pixmap would (should, anyway) both make things faster and
let us delete code.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
