Paul Berry <stereotype...@gmail.com> writes: > 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.
Agreed -- shader_runner should get new features when it lets us write piglit tests more easily/understandably. But I do think there should be a line drawn at "features not required for piglit tests" -- we have mesa-demos for misc GL things that aren't related to automated regression testing.
pgp11qVngiK_e.pgp
Description: PGP signature
_______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
