WGF11 Streamout

This automated test verifies that graphics drivers/hardware D3D stream-out behavior meets Microsoft Direct3D specifications.

This topic applies to the following test jobs:

• WGF11 Streamout

• WGF11 Streamout (WoW64)

Test details

Running the test

Before you run the test, complete the test setup as described in the test requirements: Graphic Adapter or Chipset Testing Prerequisites.

Troubleshooting

For troubleshooting information, see Troubleshooting Device.Graphics Testing.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures. The test might return SKIP if it is run with a feature level that doesn't support the feature being tested. The test might return BLOCKED if there is an uncaught exception (framework catches it at the end and logs it). To review test details, review the test log from the Windows HCK Manager.

More information

The following outlines the StreamOut Conformance Test Plan:

• General Stream Out Test Cases

  • Pass input data into the pipeline by using VB and stream out transformed data from VS or GS.

    Note  

    In the GS case, consider amplification issues by emitting more than one output primitive per input primitive.

     

  • Cycle on different primitive types, buffer sizes, emit counts, vand buffer offsets.

  • Test appending SO data by making multiple Draw() calls.

  • For GS, cycle on shaders with different "maxvertexcount" properties.

    Occasionally overflow this value, making sure that only complete primitives are kept.

  • Possibly cycle on different input primitive types and output topologies.

  • Verify expected query results

    • STREAMOUTPUTSTATS

    • STREAMOVERFLOWPREDICATE

  • Test incomplete primitive writes.

  • Test winding order and leading-vertex handling.

  • Up to 227 SO vertices per SO buffer are allowed.

    Note  

    Because this is such a large resource, this works for probably one or two test cases.

     

• Simple Single-Buffer Tests

  • Cycle on several declaration scenarios:

    • Simple.

    • Leave gaps.

    • Split output registers across multiple SO elements.

    • Merge output register into a single SO element.

  • Cycle on different SO vertex sizes.

    Verify limit of 64-component SO vertices.

• Simple Multi-Buffer Tests

  • Mix up buffer sizes/offsets so that buffers overflow at different times.

  • Cycle on several declaration scenarios:

    • Simple.

    • Skip output slot.

    • Split output registers across multiple SO elements.

    • Stream out partial register components.

    • Stream out to single buffer in non-zero slot.

• Ping Ponging of Stream Output Buffers

  • Similar to simple single-buffer and simple multi-buffer tests with a twist:

    • Initially bind buffers A and B with a positive offset.

    • Bind buffer A using -1 offset value.

    • Draw()

    • Bind buffer B using -1 offset value.

    • Draw()

    • Repeat as needed.

  • In multiple buffer scenarios, consider optionally ping-ponging only some of the SO buffers between Draw() calls.

• Changing SO Vertex Size Using Same Target Buffer

  • Custom test case that focuses on setting "fat" vertex strides to a single buffer, then Draw(), then sets "skinny" SO vertex stride, then Draw() again.

  • Examine STREAMOUTPUTSTATS.

  • Watch for overflow during "fat" vertex streaming and make sure that skinny vertices cannot be appended to target.

    Note  

    Consider ping-ponging during this step to make sure that the overflowed state is "sticky" on the buffer.

     

• Addressable Stream Output (D3D11)

  Test RasterizedStream and multiple vectors of data:

  • When sending a stream to the rasterizer, make sure that the final result uses the vertex data from that stream.

  • Make sure that more than one vector of data can be output from a stream under feature level 11, even when using a gs_4_x shader.

  • Test strides that aren't tightly aligned to the size of an element in a stream output buffer.

  • Verify that stream output works when the runtime determines strides based on the size calculated using the stream output declaration. The runtime does this when the stride parameters in the create call are both NULL.

• Test feature level and query behavior:

  • When using feature levels 10 and 10.1, make sure only stream 0 can be used for stream output.

  • When using feature levels 10 and 10.1, make sure that only gs_4_x shaders can be used. If multiple buffers are used, make sure that only one vector of data can be output from stream 0 i.

  • D3D11_QUERY_SO_STATISTICS and D3D11_QUERY_SO_OVERFLOW_PREDICATE queries should return the correct data for the sum of all streams. D3D11_QUERY_SO_STATISTICS_STREAMn and D3D11_QUERY_SO_OVERFLOW_PREDICATE_STREAMn queries return the correct data for each stream. There are currently test cases for the single stream case. The following will be verified:

    • Expected number of primitives written to stream output buffers.

    • Expected size of the primitives (if they are all to be output to buffers).

    • Overflow predicate is triggered when one buffer overflows when writing to it.

    • If one buffer in a stream is filled, writes to all buffers in that stream are prevented.

    • Results of queries for undefined streams should not be affected.

Command Syntax

Note  

For command line help for this test binary, type /?.

File List

Send comments about this topic to Microsoft