On Mon, Nov 21, 2011 at 9:53 AM, Jose Fonseca wrote:
> I think that PIPE_CAP_FLOAT_XXX is too long and that the non-abbreviated
> _FLOAT_ word is distracting and misleading, as it sounds like it's related
> with floating point features, which is not. Something more subtle, such as
> PIPE_CAPF_
I think that PIPE_CAP_FLOAT_XXX is too long and that the non-abbreviated
_FLOAT_ word is distracting and misleading, as it sounds like it's related with
floating point features, which is not. Something more subtle, such as
PIPE_CAPF_XXX, would be OK though. It's consistent with get_param and
g
Looks good, for the u_caps.c code you might as well just change
the macro to include the FLOAT_ prefix instead changing where
they are used. Fix that and you have my
Reviewed-by: Jakob Bornecrantz
Cheers, Jakob.
- Original Message -
> The motivation behind this is to add some self-docum
The motivation behind this is to add some self-documentation in the code
about how each CAP can be used.
The idea is:
- enum pipe_cap is only valid in get_param
- enum pipe_cap_float is only valid in get_paramf
Which CAPs are floating-point have been determined based on how everybody
except svga
