On 16 October 2013 13:33, Jordan Justen <jljus...@gmail.com> wrote: > 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.) >
I think patches 1 and 2 are valuable and should be kept. > > > 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 don't think we've drawn that line. Yes, shader_runner is ugly and hacky, but there's a large class of tests where it's way easier to write shader_runner tests than to write c tests. If we can broaden this class by small, incremental improvements to shader_runner, I'm all for it. If someone wants to submit some patches that make shader_runner less hacky, I'm in favor of that too. > > > 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 >
_______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit