[Mesa-dev] [PATCH] llvmpipe: Implement TXQ.

[Roland Scheidegger]

Am 16.05.2012 09:50, schrieb Olivier Galibert:
> On Wed, May 16, 2012 at 01:51:14AM +0200, Roland Scheidegger wrote:
>> Wouldn't it be easier (and more efficient) if you could just reuse the
>> sampler code which does mipmap minification, i.e. get the texture sizes
>> from bld.int_size and do a lp_build_minify (followed by extract shuffles)?
> 
> We can try that, but I'm not really convinced it will be any better
> (or more readable).  You'd have to slot the 1-3 dimensions in one
> vector, call minify, unslot the values and broadcast them in
> individual soa vectors.
For the hw it will definitely be easier. extract/broadcast is just a
single shuffle (same as a scalar broadcast really). So essentially the
only additional effort you have is constructing the width/height/depth
vector - on reasonable x86 cpus that amounts to one instruction per
element (pinsrd) except for the first element which is free. But on the
flipside you can do both the shift and the max only once.
That said, if you open-code this it won't look less complicated. This
was the main motivation why I wondered if you couldn't use the already
existing code.


> 
> 
>> Also, is it on purpose that the non-explicit lod path doesn't handle all
>> cases (using lp_build_minify would handle both cases equally if you pass
>> zero as the level)?
> 
> If you mean the commented lines (there is one in the non-explicit lod
> path too), these are the cases where the enumeration value doesn't
> actually exist.  Well, TGSI_TEXTURE_BUFFER exists now.  And damn, it's
> supposed to be a PIPE_TEXTURE_* there and not a TGSI_TEXTURE_*, fuck.
Ok I see those non-explicit lod cases won't happen. I was confused
because the explicit_lod is required yet optional (because it's dropped
for resources which don't have mipmaps).
Well if you'd use lp_build_minify you wouldn't need any branches or
anything you could just hardwire the lod to zero.
btw I think for array sizes you could just return the value from
dynamic_state->depth.

Roland



> 
> And why the hell do we have multiple enumerations describing the same
> thing with different values, some more or less complete ?  I
> understand not wanting to use the GL_TEXTURE_* numbers, since they
> make dispatch tables hard, but TGSI_ and PIPE_ ?
> 
> Other than that, the lod is not optional at the glsl level, whether
> it's there is sampler-type dependant, but there's no "simplified"
> version.
> 
>> Otherwise looks like a good idea to me (well ok I'm not too sure why
>> this opcode is terribly useful in the first place but it exists...).
> 
> Probably more useful with data-as-texture when uniform buffers aren't
> big enough.
> 
>   OG.