[Cogl] [PATCH] texture: expose mipmap level in set region apis

[Robert Bragg]

On Tue, Nov 27, 2012 at 3:15 PM, Neil Roberts <neil at linux.intel.com> wrote:

> Robert Bragg <robert at sixbynine.org> writes:
>
> > + * A mipmap @level of 0 corresponds to the largest, base image of a
> > + * texture and @level 1 is half the width and height of level 0. If
> > + * dividing any dimension of the previous level by two results in a
> > + * fraction then round the number down (floor()), but clamp to 1
> > + * something like this:
> > + *
> > + * |[
> > + *  next_width = MAX (1, floor (prev_width));
> > + * ]|
>
> Is there supposed to be a ‘/ 2’ in there somewhere?
>

er, oops, yeah


>
> > +  /* The OpenGL spec clarifies that this is how you can calculate the
> > +   * number of mipmap levels a texture requires... */
> > +  return 1 + floorf (log2f (max_dimension));
>
> I think this is essentially equivalent to doing ‘fls’ (find last in
> set). It seems a shame to use floating point math for something that is
> quite
> simple to calculate. Apparently there is usually an instruction to do
> this directly. Mesa has this bit of code, maybe it would be worth
> stealing it?
>
> static inline unsigned int
> _mesa_fls(unsigned int n)
> {
> #if defined(__GNUC__) && ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304)
>    return n == 0 ? 0 : 32 - __builtin_clz(n);
> #else
>    unsigned int v = 1;
>
>    if (n == 0)
>       return 0;
>
>    while (n >>= 1)
>        v++;
>
>    return v;
> #endif
> }
>

ah yeah that makes sense


>
> > +  /* NB: The OpenGL spec (like D3D) uses a floor() convention to
> > +   * round down the size of a mipmap level when dividing the size
> > +   * of the previous level results in a fraction...
> > +   */
> > +  for (i = 0; i < level; i++)
> > +    {
> > +      current_width = MAX (1, current_width >> 1);
> > +      current_height = MAX (1, current_height >> 1);
> > +      current_depth = MAX (1, current_depth >> 1);
> > +    }
>
> Isn't that loop equivalent to this?
>
> current_width = MAX (1, current_width >> level);
> /* etc */
>

right, I was originally worried that calculating it iteratively vs directly
from the base could be different since an iterative calculation could
cumulate imprecision and so since I saw the spec gave an example of
calculating iteratively I went with that. Actually looking at the spec
again though they do also show calculating level sizes from the base size
and given the way the calculation is done in this case it does look like
you're right, they would be equivalent.


>
> I guess both of those are pretty unnecessary optimisations, so I don't
> really mind either way.
>

thanks for taking a look, I'll update with your suggestions.

- Robert


>
> Reviewed-by: Neil Roberts <neil at linux.intel.com>
>
> Regards,
> - Neil
> ---------------------------------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> _______________________________________________
> Cogl mailing list
> Cogl at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/cogl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/cogl/attachments/20121127/379dc34b/attachment-0001.html>