Issue with 32x8 textures

[RSDuck]

This issue seems to be very weird. For some reason textures with a size of 32*8 pixels display wrongly. Instead of the right 16*8 pixels it reads from something else (it's noticable in situations where there are more textures around).

To reproduce it's enough to change this line in the textured cube example: https://github.com/switchbrew/switch-examples/blob/master/graphics/deko3d/deko_examples/source/Example04_TexturedCube.cpp#L189

to

texImage.load(*pool_images, *pool_data, device, queue, "romfs:/Unbenannt.data", 32, 8, DkImageFormat_RGBA8_Unorm);

here is the texture data I used:
Unbenannt.zip

This is the result:

Note that if the height is reduced to 4 pixels, everything works fine (except ofc that only the first 4 lines of the texture are used):

The texture transfer seems to work fine, I already tried retrieving the texture data from vram.

[RSDuck]

it works if the tile size is set to fixed one gob

[RSDuck]

RSDuck@f3a1249 is what I've come with as a fix for it and I've been running this successfully for a while now in melonDS (though I haven't tested some things like mip maps).

[averne]

Hi, I also encountered this issue, with a 128x8 r8 texture (padded to 256b).
I attach the texture data before and after the transfer. I inspected manually some portions of it and couldn't find anything regarding the data swizzling.

Below is the corresponding TIC. Again, not sure whether if something is wrong.

(gdb) p (('maxwell::TextureImageControl' *)0x52b957000)[2]
$10 = {
  format_word = {
    image_format = 29,
    component_r = 2,
    component_g = 2,
    component_b = 2,
    component_a = 2,
    swizzle_x = 2,
    swizzle_y = 0,
    swizzle_z = 0,
    swizzle_w = 7,
    pack = 0
  },
  address_low = 82116608,
  address_high = 5,
  view_layer_base_3_7 = 0,
  hdr_version = 3,
  load_store_hint_maybe = 0,
  view_coherency_hash = 0,
  view_layer_base_8_10 = 0,
  {
    width_minus_one_16_31 = 8,
    pitch_5_20 = 8,
    {
      tile_width_gobs_log2 = 0,
      tile_height_gobs_log2 = 1,
      tile_depth_gobs_log2 = 0,
      sparse_tile_width_gobs_log2 = 0,
      gob_3d = 0
    }
  },
  lod_aniso_quality_2 = 1,
  lod_aniso_quality = 1,
  lod_iso_quality = 1,
  aniso_coarse_spread_modifier = 0,
  aniso_spread_scale = 0,
  use_header_opt_control = 0,
  depth_texture = 0,
  mip_max_levels = 0,
  width_minus_one = 127,
  view_layer_base_0_2 = 0,
  aniso_spread_max_log2 = 0,
  is_sRGB = 0,
  texture_type = 1,
  sector_promotion = 1,
  border_size = 7,
  height_minus_one = 7,
  depth_minus_one = 0,
  is_sparse = 0,
  normalized_coords = 1,
  color_key_op = 0,
  trilin_opt = 0,
  mip_lod_bias = 0,
  aniso_bias = 0,
  aniso_fine_spread_func = 2,
  aniso_coarse_spread_func = 1,
  max_anisotropy = 0,
  aniso_fine_spread_modifier = 0,
  {
    color_key_value = 0,
    {
      view_mip_min_level = 0,
      view_mip_max_level = 0,
      msaa_mode = 0,
      min_lod_clamp = 0
    }
  }
}

Do you happen to remember what the x1.5 factor (heightAndHalf) was for? I can't make sense of it.
From what I can tell, nouveau and nvk do no such thing. Perhaps a carryover from nvn?

Finally, a possible workaround for those unwilling to build a modified version of deko3d:

if (height <= 8) {
    layout_maker.flags   |= DkImageFlags_CustomTileSize;
    layout_maker.tileSize = 0;
}

[averne]

Probably related: mpv-player/mpv#13909 (comment).
NVDEC always outputs a GOB-height of 2, for both the luma and chroma planes, however here chroma has a height of 8, leading to a situation similar to this bug (2-GOB layout with height <= 8). The 3D engine then fails to properly sample from it.
I reproduced this behavior on switch/deko3d, jetson nano/gles and multiple dGPUs/vulkan, so I'm wondering whether this could be a hardware issue.