On Wed, Jan 8, 2014 at 6:38 PM, Lauri Kasanen <c...@gmx.com> wrote:
> On Wed, 8 Jan 2014 15:56:33 +0200
> Lauri Kasanen <c...@gmx.com> wrote:
>
>> On Wed, 8 Jan 2014 12:03:12 +0100
>> Marek Olšák <mar...@gmail.com> wrote:
>> > Also, last_cpu_time will be wrong anyway, because the driver may call
>> > the buffer_map function only once per buffer, e.g. at buffer creation.
>> > It's not a rule, but it happens.
>>
>> I'll investigate this, thanks.
>
> There are exactly two places where this happens.
>
> 1) trace_ptr, which is unused outside of the map call (should be removed
> it seems)
> 2) r600_clear_buffer cpu fallback, which I believe is a bug:
>
> } else {
> uint32_t *map = r600_buffer_map_sync_with_rings
> (&rctx->b, r600_resource(dst), PIPE_TRANSFER_WRITE);
> size /= 4;
> for (unsigned i = 0; i < size; i++)
> *map++ = value;
> }
>
> The buffer is never unmapped, and the pointer goes out of scope. So for
> the current state, the cpu map statistics are ok.
Wrong. u_upload_mgr doesn't unmap buffers when used by radeon drivers
directly. Although it unmaps buffers when used by state trackers and
shared code, there is a plan to make it not unmap buffers at all if
the underlying driver can handle it. Also, GL_ARB_buffer_storage
allows rendering with mapped buffers, which means you don't have to
unmap a buffer unless you destroy it.
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
