On Fri, Mar 15, 2013 at 8:12 AM, Michel Dänzer <mic...@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 <mar...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
