How does Frustum render texture images of different sizes?

[Noiecity]

Suppose I have two identical rendering scenarios:

The camera's far plane and frustum culling ensure that only 8 triangles are rendered.
The shader, number of fragments, UV mapping, filtering, and mipmap level are identical in both cases.
The visible texel area is effectively 256×256 in both cases.

The only difference is:

Scenario A: the 8 triangles sample from a dedicated 256×256 texture.

Scenario B: the same 8 triangles sample the exact same 256×256 texel region, but it is part of a much larger 4096×4096 texture.

Ignore VRAM usage, loading times, and draw call overhead. I'm only interested in the GPU work performed during rendering (texture sampling, memory accesses, cache behavior, texture unit activity, etc.).

Is sampling from the larger texture inherently more expensive for the GPU, even though only the same 256×256 texel region is actually sampled? Or should both cases have essentially the same runtime cost because the texture units only fetch the required texel blocks?

[CuteAlien]

My guess: Sampling itself should be same cost. Uploading texture needs more data, so that is slower. Creating mipmaps can be slower (but also only done once). Needing less texture switches (assuming you also use other blocks of same texture) will be cheaper.

The hard part: Avoiding texture-bleeding from neighboring blocks can sometimes be a bit tricky. Thought with 2^x sizes and careful uv placement it might work.

[Noiecity]

My guess: Sampling itself should be same cost. Uploading texture needs more data, so that is slower. Creating mipmaps can be slower (but also only done once). Needing less texture switches (assuming you also use other blocks of same texture) will be cheaper.

The hard part: Avoiding texture-bleeding from neighboring blocks can sometimes be a bit tricky. Thought with 2^x sizes and careful uv placement it might work.

Thanks. Are you referring to the UV seams that appear when you activate mipmaps as a bilinear filter? Yes, it usually happens because the UV map works with vector-like coordinates, instead of pixel coordinates. I don't know why (the effect is similar to viewing the texture from a distance; the same thing happens). It's fixed by rebaking the texture and adding extra pixel margins (in Blender, you just select a texture connected to an emission node or similar and configure the margin in the bake settings).

The same thing happens as with irrlicht's rendering software and its culling; it completely discards the triangle if part of it is not within the culling area. Something similar happens here; it seems to completely discard some pixels right on the edge.

[CuteAlien]

Even without mipmaps. Like when rotating your area border points might be interpolated from neighbor with biliniear already. And I'm not sure on borders - like if your uv's are on 0,1,2,3,4... etc (grid-like), I'm not sure if that works. Or if you need a bit offset like: x = 1/screenresolution. And then have to use 0+x, 1-x, 1+x, 2-x, 2+x, ... (skypmap node does something like that to avoid gaps/lines at corners).

It's something I've not yet experimented with myself. So maybe it's easy, maybe it's tricky. But I heard from others that texture bleeding is one of those constant annoyances you run into a lot when working with texture maps.

[Noiecity]

Yes, and in fact, when you add more pixels to the edges and enable bilinear smoothing, the smoothing improves, since without bilinear you can still see a kind of seam (you can see the pixels cut off). However, I don't know if bilinear smoothing in Irrlicht softens the edges of UV islands or not