On Wed, Oct 16, 2013 at 10:58 AM, Eric Anholt <e...@anholt.net> wrote: > Jordan Justen <jordan.l.jus...@intel.com> writes: > >> git://people.freedesktop.org/~jljusten/piglit shader_runner-time-v1 >> >> I think shader_runner could be an easy way to develop >> quick micro-benchmarks when working on performance. >> >> I found shader_runner only required a few tweaks to >> be usable for this with depth clears. >> >> I'm not suggesting (at least in this series), that >> we add any micro benchmark scripts to the tree. Rather >> I would just like to make it possible to write such >> scripts for shader_runner. >> >> The last patch in this series provides an example >> usage, but I don't want that patch to be added to piglit. > > I don't think we should add this to shader_runner.
So, none of the patches? For example, are 1 & 2 valuable? My thought is, aren't many/most shader_test's indifferent to the window size? So, perhaps we could shrink the default size down smaller for Linux runs? (I know windows has some lower bound for size.) > You spent more code > putting this in shader_runner than it would have taken to just hack > something up standalone, Possibly. The shader_runner changes aren't that fancy though. But, I find tweaking and re-running a shader_test is faster/easier. Regarding the 'time' commands, I thought it might be an convenient way to micro benchmark shader code issue, although my series doesn't do this. But, if you don't agree that this is valuable, well, then it probably isn't. > and shader_runner is already a frankenstein. Without a doubt. Have we officially drawn a line that shader_runner is too much of a monster, and we should avoid adding new features to it? > I do most of my throwaway microbenchmarks in the mesa-demos repo. Would you be willing to consider ways to make this convenient in piglit, such as patch 3/piglit_get_microseconds? -Jordan _______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit