On Tue, 7 Jan 2014 01:44:28 +0100 Marek Olšák <mar...@gmail.com> wrote:
> On Mon, Jan 6, 2014 at 12:17 PM, Lauri Kasanen <c...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev