[Mesa-dev] draw_stream_output seems to be broken by design

Luca Barbieri luca at luca-barbieri.com
Mon Sep 20 15:10:21 PDT 2010


>> Note that the id parameter to DrawTransformFeedback is _not_ the place
>> to write to stream output to, but the place to take the count of
>> primitives to draw from.
>
> Which is size of the buffer / pipe_stream_output_state::num_outputs.

Huh?
Surely if I allocate a 10MB buffer, output a single triangle to it
with stream output, and then draw it with DrawAuto, then it's supposed
to draw that single triangle and not thousands or millions of
triangles.
No?

>> OK, but how do you tell the GPU to start writing from 0 and reset the
>> count in some cases, and to append and not reset the count in the
>> others?
>
> SO will always append and if the state tracker wants a reset it should simply
> create a new pipe_resource and use that.

I don't think either Direct3D or OpenGL works like this, and it would
be a terrible interface since you would need to create buffers all the
time.

For instance in D3D10 calling SOSetTargets will reset the offset to
what you specify unless you pass -1.
BTW, Gallium also has an offset parameter with I suppose works the same.

>> > The question is "how much data is in this pipe_buffer" so you hold that
>> > in the pipe_buffer itself.
>>
>> No, the question is "how many primitives were streamed out when that
>> transform feedback object was bound to GL and not paused between the
>> last Begin and End GL calls?".
>
> No, that's a question that's asked by a query and it should stay in the query.
Maybe, but then you need to pass the query to draw_stream_output since
DrawTransformFeedback in ARB_transform_feedback2 needs exactly that
info as far as I can tell (and you need to be able to pause/restart
the query, or equivalently rebinding it without resetting it).

Anyway, rereading the D3D10 documentation, it seems that it does
indeed associate the count to the stream output buffer, since that's
probably why it requires only one buffer to be bound.
And it looks like it resets it when SOSetTargets is called, but
possibly does not reset it when it's called with -1.

This means as far as I can tell that we either need two completely
different interfaces for D3D and GL (one with count in the buffer, the
other with count in the CSO), or we need to put the count in a query
(and add begin_query_from_where_it_left_off) or in some new bind
point.


More information about the mesa-dev mailing list