The strides are useful, although they can be computed by summing up
all the NumComponents fields for each buffer. Note that I also take
into account ARB_transform_feedback3, which allows having interleaved
attribs in more than one buffer. For the EXT_transform_feedback case
and separate attribs, BufferStride is really equal to NumComponents.
I'd like to ask about something here.
There is yet another property which can be computed from the other
variables: the destination offsets. Assuming the outputs are supposed
to be interleaved in one buffer, the offset is always 0 for the first
output. The second output has an offset equal to
Outputs[0].NumComponents. The third output has an offset equal to
Outputs[0].NumComponents + Outputs[1].NumComponents, and so on. This
will become more important when we start supporting
ARB_transform_feedback3, which allows holes between attribs via
gl_SkipComponents{1,2,3,4}. It would be useful for Radeons too,
because r600g must already compute the offsets from NumComponents. So
the structure for ARB_transform_feedback3 would look like:
unsigned NumComponents;
+ unsigned DstOffset;
} Outputs[MAX_PROGRAM_OUTPUTS];
Are you okay with this change as a way to express gl_SkipComponents?
Marek
On Wed, Dec 14, 2011 at 11:20 AM, Kenneth Graunke <kenn...@whitecape.org> wrote:
> On 12/13/2011 03:35 PM, Paul Berry wrote:
>> This patch adds the field gl_transform_feedback_info::BufferStride,
>> which records the total number of components (per vertex) that
>> transform feedback is being instructed to store in each buffer. The
>> i965 gen6 back-end needs this information in order to set up binding
>> tables, and it seems better to have the linker provide this
>> information rather than force the back-end to recompute it.
>> ---
>> src/glsl/linker.cpp | 4 +++-
>> src/mesa/main/mtypes.h | 5 +++++
>> 2 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
>> index b8a7126..5eb2a20 100644
>> --- a/src/glsl/linker.cpp
>> +++ b/src/glsl/linker.cpp
>> @@ -1599,6 +1599,7 @@ tfeedback_decl::store(struct gl_shader_program *prog,
>> info->Outputs[info->NumOutputs].NumComponents = this->vector_elements;
>> info->Outputs[info->NumOutputs].OutputBuffer = buffer;
>> ++info->NumOutputs;
>> + info->BufferStride[buffer] += this->vector_elements;
>> }
>> return true;
>> }
>> @@ -1863,7 +1864,8 @@ store_tfeedback_info(struct gl_context *ctx, struct
>> gl_shader_program *prog,
>> tfeedback_decl *tfeedback_decls)
>> {
>> unsigned total_tfeedback_components = 0;
>> - prog->LinkedTransformFeedback.NumOutputs = 0;
>> + memset(&prog->LinkedTransformFeedback, 0,
>> + sizeof(prog->LinkedTransformFeedback));
>> for (unsigned i = 0; i < num_tfeedback_decls; ++i) {
>> unsigned buffer =
>> prog->TransformFeedback.BufferMode == GL_SEPARATE_ATTRIBS ? i : 0;
>> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
>> index 1934349..d4c600a 100644
>> --- a/src/mesa/main/mtypes.h
>> +++ b/src/mesa/main/mtypes.h
>> @@ -1822,6 +1822,11 @@ struct gl_transform_feedback_info {
>> unsigned OutputBuffer;
>> unsigned NumComponents;
>> } Outputs[MAX_PROGRAM_OUTPUTS];
>> +
>> + /**
>> + * Number of components stored in each buffer.
>> + */
>> + unsigned BufferStride[MAX_FEEDBACK_ATTRIBS];
>> };
>>
>> /**
>
> I must confess that, looking at this structure alone, I wasn't sure what
> the difference between NumComponents (above) and BufferStride was.
>
> But this is definitely useful. With or without improved comments:
> Reviewed-by: Kenneth Graunke <kenn...@whitecape.org>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
