On Mon, Jul 06, 2015 at 11:32:47PM +0200, Daniel Vetter wrote:
> > Why don't we have some of those benchmarks they have in i-g-t? (using
> > OpenGL? they are not open source?) I have the feeling we should at least
> > have a single point of contribution, let's make sure it's i-g-t when
> > it's about low level tests? Do we want to start accepting tests written
> > in OpenGL in i-g-t?
>
> Atm I think it's just the various *marks and other stuff they have and
> run. But the idea would be that if we have wrappers it'd be easier to run
> them all for developers.
The way the test are launched is not really the goal of having more
utility functions (like computing stats on data) :) I think you're
talking about something else you had in mind for a long while.
> Anyway really just wanted to start a bit a discussion here. It's imo a gap
> we have in the open source gfx testing world, and thus far "random pile of
> scripts somewhere" seems to be the best we managed.
Oh we do. Just to be clear, I'm not very interested in doing yet another
set of wrapper scripts to run "well known" benchmarks. I'm more
interested in micro-benchmarks and their analysis, eg.:
- Speed of the various ways we have to upload tiled textures (GTT, cpu
tiling, WC mapping, blitter, ...) with a number of combination
(size, tiling format)
- benchmark the new fast copy blitter command on gen9
- memory bandwith on the GPU side (blitter commands, sampler usage,
...). I remember something flishy with render-copy like workloads
and number of threads for instance (that's compositor-like
workloads)
It's quite different from other things we can do with real workloads
where we need full frame analysis whith a bunch of GPU metrics to help.
Those don't really belong to i-g-t.
What I'm wondering: would people be OK for me to add a (optional) GL
dependency to compare the bare micro-benchmarks to their GL equivalents.
We could discover some surprises. I could also export the i-g-t data in
CSV/json/whatever and correlate them with other tests in piglit if we
want to keep the kernel Vs GL split.
That's all own-time thingies anyway, so the most likely thing to happen
is nothing :p
--
Damien
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
