[Piglit] [PATCH 04/15] arb_direct_state_access: Testing NamedBufferData.

Laura Ekstrand laura at jlekstrand.net
Thu Feb 19 15:12:38 PST 2015


More specific to this actual test, as I go along adding more entry points
for an object, I go back and refactor existing tests to use them.  In the
case of NamedBufferData, I started out with just this one line in this one
test, but then as I added tests for later entry points, I made them use
NamedBufferData as well.

I want the suite of DSA tests to "evolve naturally," ie. hopefully match
the way that game developers will use DSA "in the wild" of writing game
engines.  DSA functions tend to be used together as a group: CreateTextures
with TextureParameter and BindTextureUnit, etc.

Along the way of developing DSA, in the in-between of testing entry points,
I test what happens if you mix DSA with non-DSA.

On Thu, Feb 19, 2015 at 3:01 PM, Laura Ekstrand <laura at jlekstrand.net>
wrote:

> The general consensus I've gotten [not specific to this particular test]
> is that Piglit tests should mostly be functional in nature.  Conformance
> (as in the types of errors thrown) is tested by the official Khronos
> conformance suites.  For instance, before I pushed arb_dsa texture objects,
> Anuj ran gles-3.0 conformance suite on it.
>
> For DSA, when a completely new function is added (such as Create*), I tend
> to add some conformance tests for that.  (Especially since there isn't much
> else you can test with Create* if it is the only DSA entry point you have
> for that type of object.)  For the others, since they share so much code
> (especially for error-checking) with the traditional entry points, I assume
> that other tests are doing a more thorough check.  So I mainly add a test
> or two that tests the function of the new entry point.
>
> On Wed, Feb 18, 2015 at 9:52 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>
>> On Wed, Feb 18, 2015 at 9:59 AM, Martin Peres
>> <martin.peres at linux.intel.com> wrote:
>> [...]
>> > and you only test the differences you introduced in mesa but is this
>> really
>> > how
>> > we are supposed to write the tests?
>> >
>> > I really don't know, hence why I am asking.
>>
>> In case there's any doubt, no, you're supposed to write self-contained
>> tests that don't in any way rely on mesa impl details, or what other
>> tests are out there for unrelated features. [And I say this without
>> making any sort of judgement on the actual test being discussed.]
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20150219/b6e38269/attachment.html>


More information about the Piglit mailing list