[Mesa-dev] [PATCH] draw: don't clear the so targets until we stream out

[Brian Paul]

On 06/13/2013 07:01 PM, Zack Rusin wrote:
>>> Though I find stream output very confusing...
>>
>> I agree. I was digging a bit more and I think I was correct the first time.
>> The D3D spec is very clear that "a buffer cannot be bound as both an input
>> and an output at the same time", so I think the current behavior is correct,
>> or at least one of the correct options given that the behavior is simply
>> undefined. So I think I'm going to skip this patch, especially that is is
>> subtly wrong (because it will clear so target buffers on each invocation of
>> the stream output stage which isn't correct behavior since the buffers
>> should only be cleared when new so targets are set).
>
> Actually I'd just like to commit the attached patch. All it does is move
> the clearing of the so targets from the drivers to the draw module. It fixes
> a bug in softpipe, because softpipe would never clear the buffers and would
> always append.

>
> diff --git a/src/gallium/auxiliary/draw/draw_context.c b/src/gallium/auxiliary/draw/draw_context.c
> index 22c0e9b..53f515e 100644
> --- a/src/gallium/auxiliary/draw/draw_context.c
> +++ b/src/gallium/auxiliary/draw/draw_context.c
> @@ -809,12 +809,20 @@ draw_get_rasterizer_no_cull( struct draw_context *draw,
>  void
>  draw_set_mapped_so_targets(struct draw_context *draw,
>                             int num_targets,
> -                           struct draw_so_target *targets[PIPE_MAX_SO_BUFFERS])
> +                           struct draw_so_target *targets[PIPE_MAX_SO_BUFFERS],
> +                           unsigned append_bitmask)
>  {

Can you document how the append_bitmask works?

Otherwise, LGTM.

Reviewed-by: Brian Paul <brianp at vmware.com>