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

[Lauri Kasanen]

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).

> > +++ 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 ;)

I see that r600_context_bo_reloc is called on every call of
r600_draw_vbo, r600_emit_shader. Though for vertex, constant buffers
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.

Thanks!

- Lauri