[Mesa-dev] llvmpipe lp_build_context

[Jose Fonseca]

----- Original Message -----
> >
> > That is, lp_bld_arit.c functions such as lp_build_add() are be
> > confident that passed the values and types are consistent, and all
> > assertions to test that should be preserved.
> >
> > I hope this makes sense.
> 
> Thanks Jose, this seems sensible and I'll try and go in that
> direction, some issues I've noted so far
> 
> a) lp_build_select, you have to tell it the type of the values so it
> can do the proper operations internally with them, I'm not sure we
> can
> hide that easily inside the tgsi_soa,c file, we currently don't pass
> it a build context, which maybe if we start doing that it'll fix it.

lp_build_select already takes the type:

LLVMValueRef
lp_build_select(struct lp_build_context *bld,
                LLVMValueRef mask,
                LLVMValueRef a,
                LLVMValueRef b)

And bld context will be either the floating, or the integer one.

The problem here is SSE domain: for many operations SSE has two semantically identical instructions with the difference of being executed in two different arithmetic units (integer unit vs float unit), and moving data between units implies a penalty.

If we emit intrinsics, then the int/float domain will be set in stone. But if we always use bitwise arithmetic for selection (OR/AND/NOT), or LLVM vanilla IR, then LLVM will choose the appropriate float/int SSE instruction for us, based on the surrounding intrusctions.

That is, we should only emit SSE instrinsincs inside lp_build_select if: a) they make a significant difference and b) we can be absolutely sure that those values were/will be used by the appropriate int/float domain.

I think that LLVM 3.0 supports vector selections in the language, so we should be able to eliminate intrinsics from inside lp_build_select without loss. 

> b) its hard to infer a type for MOV, but I'm creating a ptr that is
> the same as the fetch pointer. This matters more for MOVs from
> immediates if my memory serves (its a bit blurry after staring at
> this
> most of the day). In theory you'd think we could just use float, but
> that broke down in a fair few corner cases.

IMO, there are two approaches here:

1) State tracker only emits integer MOVs without absolute/negative, ie, pure data transfer moves. 

  In this the pipe driver implements all transfers as floats, even when the values are integers -- once LLVM optimizes the SSA IR all intermediate float values will disappear.

2) Add a new opcode for integer moves, i.e., IMOV.

Either way, I think the pipe driver should not need to worry about type inference, as it is very difficult to get it right in face of indirect assignments.

> I hacked out a lot of the asserts earlier but I'm slowly putting them
> back in as I get things into better shape.

Sounds good.

> I've no idea yet about fetch/sampling, I'll try and get the internals
> done first.

It's fine. At an intermediate stage, we can do all fetching/sampling w/ floats, appended of a float to int cast. In a second stage we we actually implement fetching everything as integer by relying on u_format. Lastly we implement full code generation.

The good thing is that filtering is not needed for ints, so it is less hairy than the floating point path.

Jose