[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.8.0

[Ben Gamari]

On Sat, Aug 01, 2009 at 12:50:06AM +0100, Chris Wilson wrote:
> On Fri, 2009-07-31 at 19:12 -0400, Ben Gamari wrote:
> > Testing the fastest chipset would produce useless data --- comparing
> > releases on different hardware is stamp-collecting at best and just
> > plain misleading at worst. Personally, I would much rather see the Intel
> > folks working on actually improving the codebase. Sure, some benchmarking
> > is required to do this, but spending developer time on benchmarking just
> > for publicity seems like a poor allocation of resources.
> 
> Never just for publicity.

I think this is the point that needs to be made. I hope I didn't imply
that performance profiling isn't an integral part of driver improvement.
Indeed, it is. What I object to is using developer time simply for
satisfying peoples' need for numerical metrics of improvement. Moreover,
an automated mechanism for running benchmarks would largely satisfy this
need. I think it would be great if we could have a better protocol for
monitoring performance over the course of driver development in an
automated fashion. The cairo-traces repository is a great start on this.

> So the question I have been asking myself is "just how much more effort
> will it be to (a) set up regular performance monitoring of not just
> cairo, but the whole gfx stack and (b) to report such benchmarks in both
> an accessible manner and sufficient detail for a developer?" And should
> we not open our own benchmarking practices and present them for review
> and critique?

It would be great if we had a machine of each hardware class (8xx, 945,
965, G4x, ???) which could benchmark these traces for each incoming
xf86-video-intel and drm commit and report serious regressions to the
list. Would it be possible for Intel to provide hardware for this? If
not, I have a 945 that I might be able to setup a cron job on.  Perhaps
we could create an intel-gfx-commits list where each commit and its
benchmark metrics across the range of hardware could be reported
(similar to xorg-commits but with performance benchmarking data).

The actual code to do this seems like it would be pretty simple
(assuming you use a high-level language), it's just a matter of finding
the hardware resources.

>[The next set of tools I need will be to monitor both the
> CPU and GPU (which of course presumes that I can reduce the overhead of
> Cairo sufficiently, or find a much faster CPU!).

Monitor in what way? Monitoring individual batchbuffers' utilization of
GPU and CPU time? Or simply monitoring their overall usage? I could
potentially be convinced to take on such a project.

> Tracepoints look like they provide suitable kernel probes, so now I
> just need some good visualisation and analysis tools in order to make
> use of the data.]

Yeah, this is always the issue.

- Ben