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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
