Metal texture sampling questions

Question

rsebbe OP

Created Aug ’15

Replies 4

Boosts 0

Views 2.5k

Participants 3

Hi there,

Got a few questions about Metal textures:

- When declaring a texture parameter as texture2d<float, access::sample>, what does the float means exactly? It's a the conversion that is applied from whatever internal type the texture has to floating point? They don't have to match. Is that correct?

- Are these things roughly equivalent then:

mediump Sampler2D <-> texture2d<half, access::sample>

- about texture sampling, with GL, I used to have the computation of varyings in vertex shader code to avoid dependent texture accesses in the fragment shader. The word was that dependent texture reads are no more a problem with A7+ archs. Is that cost close to zero or zero? Is there still an advantage of pre-computing coordinates in vertex shader, or not?

- How does this translate to Metal? Any advantage of using varyings?

- In GL, I was sometimes making use of texture2DProj() to sample a texture using homogenous coordinates (vec3). There does not seem to be a way to do that in Metal, so division by z (v.xy/v.z) is used instead, which in turn disables any advantage varyings might have. Is that the recommended approach for homogenous texture sampling? Other ways?

Boost

Answer 1

Jessy OP

Aug ’15

… Is that correct?

It sounds like you've got it. Check out "Texture Addressing and Conversion Rules".

"Is that cost close to zero or zero?"

I don't know, but I'm assuming "no performance cost" means it's close enough to zero to not think about. What kind of situations do you get into, where your dependent texture read calculation is something other than a swizzle? While I've been happy that the cost has decreased for my reads that are based on calculations using other textures, it hasn't changed the way I've been programming: I still calculate as much as possible in the vertex program.

division by z (v.xy/v.z) is used instead, which in turn disables any advantage varyings might have. Is that the recommended approach for homogenous texture sampling?

I wonder how long GPUs haven't actually had specialized hardware for the division. You can certainly test whether moving the calculation to the vertex shader will give you good enough results, but I've never found that to be the case.

0

Answer 2

rsebbe OP

Aug ’15

Thanks.

I'm using multi-sampling for image processing. Think convolutions, where I need multiple input pixels to generate one output, generally processing a single texture. For constant offsets, I can certainly have them in vertex shader yes. I also noticed an integer offset in metal sampling functions, that may be interesting performance-wise too.

Division by z is required in my case (per fragment), as a way to evaluate homography transforms (for tex coords) in some of my shaders. I guess division is already well supported in hardware, because perspective-correct interpolation does that for all varyings by default when fragment is processed. But at the same time, it's well possible that GLSL's texture2DProj() was just evaluating the division, I just don't know. Metal does not expose such API, as far as I know.

0

Answer 3

robertc OP

Aug ’15

In regards to dependant texture that are caused by the .zw components of a texture coordinate being used in a texture fetch then yes these are not an issue anymore afaik (at least on A8 devices and maybe also A7?).

Reads that are caused by changing the texture coordinate in the pixel shader before doing a tex-fetch can still be performance no-no if the GPU can't hide the latency so if you can you should do all of your texture coordinate generation in the vertex shader (which it sounds like you do) and pass them through to the pixel shader.

0

Answer 4

rsebbe OP

Aug ’15

OK, thank you, but it looks like projective sampling is not available (unlike OpenGL's texture2DProj(vec3)), which mean the division must be done in the fragment shader.

I'll file a bug report about that.

0