[Mesa-dev] Sandybridge ARB_gpu_shader5 gather bits
Chris Forbes
chrisf at ijw.co.nz
Tue Jan 28 12:17:30 PST 2014
Hi Ian,
Replying to IRC:
< idr> chrisf: You know if SNB can do the enhanced textureGatherOffset
modes from ARB_gpu_shader5?
Sandybridge has per-slot offset support (gather4_po) but lacks:
* Channel select bits in the message header
* Any ability to sample from a multi-component texture. Only red/alpha
formats are supported.
* Depth compare (although you can emulate this since there's no filtering)
That's enough that ARB_gpu_shader5 is impossible.
There are also bugs in even what ARB_texture_gather requires, which is
why it's not enabled:
* gather4 on UINT/SINT only returns good data for two of the texels.
Getting all four texels requires a second gather4 with an adjusted
offset. I had a workaround written for this which works for 2D
surfaces, but the sampler can't do offsets with cubes. I stopped short
of doing cubemapping in the shader by hand, although it's not too
awful. :) This also reduces the available range of offsets for these
formats to -7..7, whereas the spec requires -8..7.
An alternative workaround might be to treat the surface as something
completely different (UNORM, and possibly switching to FLOAT for large
formats?) and reinterpret the bits in the shader. The workaround would
require custom surface state, some format bits in the sampler key, and
some format-dependent unmangling of the bits back into the proper
int/uint value, but would allow proper offset range, hardware cube
sampling, etc.
Ken and I discussed a third possibility when I was working on this, of
converting the gather to four texelFetch or texelFetchOffset, but
that's messy and still requires a lot of special handling for cubes
etc.
-- Chris
More information about the mesa-dev
mailing list