[Mesa-dev] [PATCH 2/2] mesa: Speedup the xrgb -> argb special case in fast_read_rgba_pixels_memcpy

Ian Romanick idr at freedesktop.org
Tue Mar 12 09:56:49 PDT 2013


On 03/11/2013 06:23 PM, Marek Olšák wrote:
> On Mon, Mar 11, 2013 at 6:49 PM, Ian Romanick <idr at 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.



More information about the mesa-dev mailing list