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

[Zack Rusin]

On Monday 20 September 2010 01:34:18 Luca Barbieri wrote:
> > It's because I never had the time to actually test it properly. The
> > interface is right though, the implementation is supposed to follow the
> > D3D semantics and we should stick with that, instead of passing cso's
> > and making behavior switch based on magic null arguments.
> 
> I think you need that to implement ARB_transform_feedback2.
> 
> How would you implement this (note the id parameter) without a
> corresponding CSO parameter in Gallium?
>     void DrawTransformFeedback(enum mode, uint id);

The difference between this and the D3D semantics is that in D3D you bind the 
buffer explicitely and in GL implicitly i.e. the buffer associated with the 
stream output object id is bound for you. So for GL the state tracker would 
have to bind the appropriate buffers on DrawTransformFeedback.

> Of course you can do it with a SO_STATISTICS queries, but it's awkward
> and requires the CPU to wait on the GPU (also, if the user is using
> such a query himself, it might be an issue).
> 
> The NULL argument might be avoided, but that would cause D3D state
> trackers to need to track and keep alive the last stream output CSO,
> and might force the driver to unnecessarily write out the value to a
> buffer instead of just keeping it in an hardware register.

draw_stream_output is the reason for this. If we assumed that we always need 
to collect the number of verts written to a buffer we wouldn't need 
draw_stream_output at all, we'd just call util_draw_arrays but having 
draw_stream_output allows the driver to do whatever it has to avoid the 
expensive fetches for PIPE_BIND_STREAM_OUTPUT resources.

z