[Mesa-dev] [PATCH 01/10] i965: Split sampler count variable to be per-stage.

[Kenneth Graunke]

On 08/16/2013 09:57 PM, Ian Romanick wrote:
> On 08/14/2013 06:55 PM, Kenneth Graunke wrote:
>> Currently, we only have a single sampler state table shared among all
>> stages, so we just copy wm.sampler_count into vs.sampler_count.
>>
>> In the future, each shader stage will have its own SAMPLER_STATE table,
>> at which point we'll need these separate sampler counts.
>>
>> Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
>> ---
>>   src/mesa/drivers/dri/i965/brw_context.h          |  5 ++++-
>>   src/mesa/drivers/dri/i965/brw_vs_state.c         |  4 ++--
>>   src/mesa/drivers/dri/i965/brw_wm_sampler_state.c | 12 +++++++-----
>>   src/mesa/drivers/dri/i965/brw_wm_state.c         |  6 +++---
>>   src/mesa/drivers/dri/i965/gen6_vs_state.c        |  2 +-
>>   src/mesa/drivers/dri/i965/gen6_wm_state.c        |  2 +-
>>   src/mesa/drivers/dri/i965/gen7_sampler_state.c   | 12 +++++++-----
>>   src/mesa/drivers/dri/i965/gen7_vs_state.c        |  2 +-
>>   src/mesa/drivers/dri/i965/gen7_wm_state.c        |  2 +-
>>   9 files changed, 27 insertions(+), 20 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
>> b/src/mesa/drivers/dri/i965/brw_context.h
>> index 74e38f1..63136b1 100644
>> --- a/src/mesa/drivers/dri/i965/brw_context.h
>> +++ b/src/mesa/drivers/dri/i965/brw_context.h
>> @@ -1065,7 +1065,6 @@ struct brw_context
>>
>>      /** SAMPLER_STATE count and offset */
>>      struct {
>> -      GLuint count;
>>         uint32_t offset;
>>      } sampler;
>>
>> @@ -1109,6 +1108,8 @@ struct brw_context
>>
>>         uint32_t bind_bo_offset;
>>         uint32_t surf_offset[BRW_MAX_VS_SURFACES];
>> +
>> +      uint32_t sampler_count;
>>      } vs;
>
> There's a lot of commonality between these structures.  If
> BRW_MAX_VS_SURFACES, BRW_MAX_GS_SURFACES, and BRW_MAX_WM_SURFACES are
> the same, we should make this common stuff common.  Yeah?

They're not, but you're right, there is a lot of duplication here.  It's 
probably worth creating a common struct for most of the fields (but 
still creating separate instances in the vs, wm members).

I think that would be best as a follow-up series.