Am 07.02.2014 04:37, schrieb Dave Airlie: > On Fri, Feb 7, 2014 at 12:36 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 07.02.2014 02:56, schrieb Ilia Mirkin: >>> On Thu, Feb 6, 2014 at 8:52 PM, Dave Airlie <airl...@gmail.com> wrote: >>>> From: Dave Airlie <airl...@redhat.com> >>>> >>>> This just adds the TG4 opcode, and a CAP for the >>>> max texture gather components. >>> >>> Is this different from GATHER4? If it is, should probably be >>> documented in docs/source/tgsi.rst... >> I'm pretty sure this is the OGL-equivalent of gather4 (as gather4 is >> d3d10-style, that is separate sampler and resource reg). >> You are quite right though this is definitely missing documentation >> (looking at it I have no idea for instance how the component selection >> is going to work). >> > Doh, yes because GL has ARB_texture_gather then has stuff hidden away > in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we should > do. > > So I've reposted with the component selection in src1 now.
Hmm seems a bit excessive to use an extra reg for that (gather4 but only in d3d11 form uses a src_sel on the sampler reg, but that might not work). I realize this is actually more messy than I thought, since the initial ARB_texture_gather had the ability to query if multi-channel formats are allowed, but had no way to select the channel (somewhat relying on ARB_texture_swizzle to do it, though of course you can't issue multiple gathers with the same texture to get different channels that way). But glsl 4.00 version could select the channel. Is the ARB_texture_gather version actually all that useful or could you merge the two caps? That is, if you have the ability to fetch from multi-channel textures, assume you can also select the channel. The sm4 version of gather4 also has the single-channel format restriction - I guess though some hw really can do 4 channels without channel selection. Other than that, what about shadow samplers? Gather4 of course can't do it (because the d3d10-style opcodes have different opcodes for shadow comparisons), but the GL style opcodes are usually the same if shadow samplers or not are used. Maybe you don't want to handle that right now, just saying that if you'd want to use the same opcode you'd be missing a component in case of texture cube arrays... Since this can't be used for fixed function though I'd guess nothing would stop you from using a different opcode for shadow samplers. Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev