>> 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 singl
On Monday 20 September 2010 15:21:40 Luca Barbieri wrote:
> >> 2. How do you pass to Gallium the id parameter to DrawTransformFeedback?
> >
> > You bind the buffer with the given id before issuing draw_stream_output.
>
> Bind to what?
As the vbo.
> Note that the id parameter to DrawTransformFee
>
>> 2. How do you pass to Gallium the id parameter to DrawTransformFeedback?
>
> You bind the buffer with the given id before issuing draw_stream_output.
Bind to what?
Note that the id parameter to DrawTransformFeedback is _not_ the place
to write to stream output to, but the place to take the cou
On Monday 20 September 2010 13:50:43 Luca Barbieri wrote:
> > No, you don't store it at all. Storing it in the client side data
> > structures implies fetching.
>
> Well, of course you don't store it in the client data structure.
> In the driver-specific part of the data structures, you store some
> No, you don't store it at all. Storing it in the client side data structures
> implies fetching.
Well, of course you don't store it in the client data structure.
In the driver-specific part of the data structures, you store some
kind of reference to the GPU-side object where you instruct the GPU
On Monday 20 September 2010 11:10:59 Luca Barbieri wrote:
> > 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 w
> 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
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 beha
> 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
On Sunday 19 September 2010 13:44:33 Luca Barbieri wrote:
> The current version of draw_stream_output in softpipe seems to attempt
> to draw using the currently bound stream output buffer as input.
It's because I never had the time to actually test it properly. The interface
is right though, the
The current version of draw_stream_output in softpipe seems to attempt
to draw using the currently bound stream output buffer as input.
This does not match D3D10/11's DrawAuto, which instead draws with the
current vertex buffer (and requires having only one bound), but using
the primitive count fr
11 matches
Mail list logo
