[Mesa-dev] [PATCH 3/4] winsys/radeon: Keep bo statistics

[Marek Olšák]

On Tue, Jan 7, 2014 at 11:14 AM, Lauri Kasanen <cand at gmx.com> wrote:
> On Tue, 7 Jan 2014 01:44:28 +0100
> Marek Olšák <maraeo at gmail.com> wrote:
>
>> On Mon, Jan 6, 2014 at 12:17 PM, Lauri Kasanen <cand at gmx.com> wrote:
>> > These will be used later on for optimizing the VRAM placement.
>> >
>> > No measurable overhead (glxgears).
>>
>> I recommend testing torcs (the Forza track) next time. glxgears is not
>> useful here.
>
> Can you elaborate why Torcs? I used glxgears, because it indeed was
> useful (if you check the previous patches, before the timing was moved
> into a thread, there was a 7% glxgears regression).

Torcs has higher CPU overhead and it's all in the Mesa driver.
glxgears only spends 50% of the time there, DRI2SwapBuffers and the
kernel takes the other 50%.

>
>> > +++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
>> > @@ -361,6 +361,14 @@ static unsigned radeon_drm_cs_add_reloc(struct radeon_winsys_cs *rcs,
>> > +    if (usage & RADEON_USAGE_WRITE) {
>> > +        bo->stats.num_writes++;
>> > +        bo->stats.last_write_time = stats_time_get(ws);
>> > +    } else {
>> > +        bo->stats.num_reads++;
>> > +        bo->stats.last_read_time = stats_time_get(ws);
>> > +    }
>>
>> You do know that this is mostly useless, don't you? You sure won't
>> know which resources are used for reading only, because
>> glBufferSubData or glTexSubImage may generate a write, and an app
>> which uploads data every frame or every couple of draw calls can cause
>> the resource to appear as being used for writing all the time, while
>> in reality it's only used for reading during rendering.
>
> That's ok, as they are both implemented as a blit - a write. Doing that
> write on the gpu hw, but in system RAM, is not ideal.
>
> I don't see how it would skew the results badly, since if the app
> bothers to update a texture every frame, that texture is surely
> important to the app.
>
> As the cost also takes into account the buffer size, having a small but
> often-written texture (such as a HUD that is read once per frame) would
> not displace a large read-only texture.
>
>> You also won't
>> know how many draw calls the resource is used in, because the function
>> is called only once per state change and there can be many draw calls
>> per state change. ... which may be called many
>> times for the same buffer.
>
> That sounds contradictory ;)

*"there can be a lot of draw calls after every state change"

>
> I see that r600_context_bo_reloc is called on every call of
> r600_draw_vbo, r600_emit_shader. Though for vertex, constant buffers

In draw_vbo, r600_context_bo_reloc should only be called for the index
buffer and the streamout "filled_size" buffer without dirty tracking.

> and sampler views there's indeed dirty_mask checks. For those,
> additional stats calls will need to be added in the places that update
> that dirty_mask for correct results.

This would add unnecessary overhead. I don't think you need so
accurate information, especially when you have to sacrifice CPU time.

Marek