[Mesa-dev] [PATCH 2/3] gallivm: add uint to float arit function.

[Jose Fonseca]

----- Original Message -----
> On Fri, Feb 17, 2012 at 10:01 PM, Jose Fonseca <jfonseca at vmware.com>
> wrote:
> > Note that SSE doesn't have vectorized UI to FP. Only SI to FP. At
> > one point LLVM was breaking down the conversion to scalar, which
> > is overkill. I think that since I look at it, LLVM has been
> > updated to generate better code. Please take a look generated
> > assembly for LLVMBuildUIToFP before commiting. Otherwise put a XXX
> > comment warning about this so that we don't forget about this
> > issue.
> >
> >
> > I'd prefer to have this one in lp_bld_conv.c .  Because eventually
> > this function will be superseeded by lp_build_conv().
> >
> > The reason I don't recommend you to simply use lp_build_conv() is
> > that lp_build_conv doesn't do the right thing with unsigned ints
> > due to the issue above, and in many places (e.g., texture
> > sampling), it doesn't matter. This needs to be cleaned up so that
> > uint -> fp is done properly, and places that don't need uints
> > don't use them.
> 
> Well ideally we won't be doing any ui->fp conversion except we get an
> opcode instructing us to do it, anywhere else would be a bug that
> would need to be fixed. 

But the point of functions like lp_build_conv() is not just TGSI translation, but simply an all purpose building block for converting values between arbitrary vector types. They are not supposed to be handicapped just to find bugs. They are merely convenience wrappers around LLVM IR building functions.

If you don't fore see any other use of this function, then just call LLVMBuildUIToFP directly from where you need it. 

> I don't accept at all that we should be
> allowing texture fetches from unsigned to end up as floats at any
> point in the pipeline.

Sorry, I meant conversion of texture coordinates, not texels themselves. And it's actually the other way around, i.e., fp->ui, so doesn't quite apply to this case.  Anyway, just to finihs the story, the gist is that even though texture coordinates are guaranteed to be positive after de-normalization and wrapping, we use fp->si instead of fp->ui when obtaining the integer coordinates to achieve maximum throughput. Which is fine, given that there are no textures with size >= 0x8000000.

Jose