On Tue, Mar 9, 2010 at 6:37 AM, José Fonseca <jfo...@vm...> wrote:
> On Mon, 2010-03-08 at 15:28 -0800, Brian Paul wrote:
>> 1. Rename pipe_sampler_state:min_mip_filter to mip_filter.
>>
>> I don't know that the "min" part of that field refers to.
>>
>>
>> 2. Remove PIPE_MAX_TEXTURE_LEVELS from p_state.h
>>
>> This token isn't used anywhere in the gallium interface anymore, nor
>> the state trackers. I've already removed the use of this token in the
>> gallium drivers (use per-driver #defines instead). There's still some
>> use in the blitter code though.
>
> This looks fine.
>
>> 3. BTW, none of these #defines are used in the gallium interface
>> header files:
>> PIPE_MAX_CONSTANT_BUFFERS
>> PIPE_MAX_ATTRIBS
>> PIPE_MAX_SAMPLERS
>> PIPE_MAX_VERTEX_SAMPLERS
>>
>> They are used in the utility code and drivers though. Should we
>> define these in the gallium interface if they're not used by the
>> interface itself?
>
> PIPE_MAX_SAMPLERS / PIPE_MAX_VERTEX_SAMPLERS are the maximum argument
> set_fragment_sampler_textures/set_vertex_sampler_textures. These are
> indeed unnecessary given that there are corresponding caps queries. So
> state trackers should use arrays big enough to represent the API limits,
> and pipe drivers should use arrays big enough to represent the hardware
> limits, and both should agree on what's passed via the caps.
>
> Ditto for PIPE_MAX_CONSTANT_BUFFERS.
>
> I'm not sure about PIPE_MAX_ATTRIBS though. Can't find a caps for it.
Since the drivers need to know those limits, can we doc them? I've
been looking them up in the headers when I need to see their values,
and I know I'm not the only one.
~ C.
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
<Mos...@gm...>
|
