[Mesa-dev] Fwd: [PATCH 5/6] st/mesa: implement blit-based ReadPixels

[Marek Olšák]

On Fri, Mar 15, 2013 at 8:12 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On Don, 2013-03-14 at 23:35 +0100, Martin Andersson wrote:
>> On Thu, Mar 14, 2013 at 7:45 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> >
>> > +   /* See if the texture format already matches the format and type,
>> > +    * in which case the memcpy-based fast path will likely be used and
>> > +    * we don't have to blit. */
>> > +   if (_mesa_format_matches_format_and_type(rb->Format, format,
>> > +                                            type, pack->SwapBytes)) {
>> > +      goto fallback;
>> > +   }
>>
>> On my system (Intel core i7 and AMD 6950) the memcpy fast-path takes
>> around 210 milliseconds and the blit path takes around 9 milliseconds, for a
>> 1920x1200 image. So it is much faster, at least on my system, to use the
>> blit path even when the mesa format matches format and type.
>>
>> To test this I forced the use of the memcpy fast-path (the mesa format was
>> MESA_FORMAT_XRGB8888, the format was GL_BGRA and the type was
>> GL_UNSIGNED_BYTE). I visually inspected the resulting image and I could
>> not see anything wrong with it.
>>
>> But perhaps forcing the use of the memcpy fast-path invalidates the results.
>> Or there might be some other issues that I am missing, but I just wanted to
>> say that on my system it is better to remove this check.
>
> If the read buffer is in VRAM, reading from it with the CPU directly
> will be very slow.

I think VRAM mapping is impossible to hit with r600g. If a texture is
in VRAM, it is always tiled, therefore the driver blits it to a linear
texture allocated in GTT and maps the linear one. Also, XRGB8888 never
takes the memcpy fast path in readpix.c because of the X component
that can be undefined.

([rant]We should really have an unmappable portion of VRAM as a
feature, because unmappable memory is cool: the memory can be
reclaimed immediately after texture deletion even if the texture is
busy, because the CPU can't access it, and thanks to that, ttm_bo_wait
could be a no-op for all unmappable resources[/rant]).

Marek