[Piglit] [PATCH 00/10] shader_runner support for micro benchmarks

[Eric Anholt]

Paul Berry <stereotype441 at gmail.com> writes:

> On 16 October 2013 13:33, Jordan Justen <jljusten at gmail.com> wrote:
>
>> On Wed, Oct 16, 2013 at 10:58 AM, Eric Anholt <eric at anholt.net> wrote:
>> > Jordan Justen <jordan.l.justen at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20131018/53bd7bd2/attachment.pgp>