[Mesa-dev] [PATCH] draw: don't clear the so targets until we stream out
brianp at vmware.com
Fri Jun 14 06:06:34 PDT 2013
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,
> 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?
Reviewed-by: Brian Paul <brianp at vmware.com>
More information about the mesa-dev