03:16mareko: Venemo: the compression type is determined by the swizzle mode: if it's Z, metadata is HTILE; if it's R, metadata is DCC
03:19mareko: Venemo: that logic is also used by shaders
03:20mareko: that's why descriptors don't need a separate bit to choose between color and depth
03:23mareko: in gfx11, Z and R swizzle modes are actually identical in memory, and the only reason they still exist to determine whether metadata is HTILE or DCC in the texture unit
03:24mareko: *exist is to
03:38soreau: mareko: To get the modifier info for each chip in gfx6-8 from addrlib, would I need the hw or what is the path forward?
04:06mareko: soreau: you don't need the hw, you only need the GB_ADDR_CONFIG and MC_ARB_RAMCFG values for each chip
04:07mareko: and GB_TILE_MODEn and GB_MACROTILE_MODEn values
04:07mareko: everything is in the kernel except MC_ARB_RAMCFG
04:07mareko: I think
04:14soreau: when I grep for those in addrlib, I only see instances for gfx9-11 and r800
04:14soreau: so I'm not sure where I would put code to walk the chips and dump the information needed
04:15soreau: at least the addrlib in mesa
08:11Venemo: mareko: there seem to be a bunch of other Z swizzle modes besides the ones that Alex said were supported by the SDMA, and i'm not sure if addrlib will select the right ones
09:55mareko: Venemo: the whole purpose of addrlib is to select the right one
09:56Venemo: mareko: how would it know that the image is going to be used with the SDMA?
09:57mareko: Venemo: SDMA supports all swizzle modes, only DB and CB support a smaller set
09:57mareko: if not all, then at least a superset of of CB and DB support
09:59Venemo: I see
09:59Venemo: then I think I misunderstood what Alex said yesterday
10:00mareko: he was talking about DB
10:00mareko: DB only supports 64KB_Z_X and gfx11 also supports 256KB_Z_X
10:14mareko: SDMA doesn't care about compression because that's handled by the cache
10:19mareko: and the cache doesn't care about swizzle modes because SDMA converts image ops to buffer ops
10:55mareko: hakzsam: can you ack https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25558 ?
10:55Venemo: mareko: okay, so the conclusion is that HTILE should just work on GFX10 with SDMA and I don't have to worry about it?
10:56mareko: correct
11:02Venemo: awesome
11:02Venemo: thanks :)
11:49Venemo: mareko: what is the difference between the PKT3 packets COPY_DATA with an imm vs. WRITE_DATA?
12:17mareko: Venemo: WRITE_DATA can write more dwords, that's it
12:18Venemo: which engine executes COPY_DATA? PFP or ME?
12:20mareko: Venemo: you can select that
12:21Venemo: I see
12:21mareko: ME by default, PFP if you set the last bit of the first dwords of the body
12:21mareko: *dword
12:21Venemo: so they are basically the same then
12:21mareko: yes
14:19hakzsam: agd5f: any ideas how to proceed with that?
14:33agd5f: hakzsam, file a bug
16:14hakzsam: agd5f: https://gitlab.freedesktop.org/drm/amd/-/issues/2902 hope it will help
16:29hakzsam: agd5f: I'm continuing to bisect...
16:29agd5f: hakzsam, thanks
21:43Venemo: mareko: can you shed some light on how to program the T2T subwindow copy packet to support DCC? there are two peculiarities about it: (1) the packet only has fields for one DCC configuration, and unclear how to program it when the source and destination images don't have the same config, and (2) there is a dcc_dir field which PAL never sets, but without which I get some failures. can you tell me what this field is supposed to mean?
22:13agd5f: Venemo, bit 31 of the packet header is the S/D DCC selector.
22:13Venemo: S / D = source / destination?
22:13agd5f: yes
22:14agd5f: 0 - compress copy; dst is compressed
22:14agd5f: 1 - decompress copy; src is compressed
22:14Venemo: what if both are compressed?
22:14agd5f: not supported as far as I can see
22:15agd5f: SDMA doesn't really have full DCC, it just picks up limited support via GL2
22:18Venemo: so if I want to to copy a DCC compressed image to another DCC compressed image, I need two copies?
22:19agd5f: also bit 28 of DW 17 should be set to 1 on compression
22:19agd5f: Venemo, yeah, I think so
22:20Venemo: this makes no sense to me to be honest
22:20Venemo: it makes me wonder how they intended this to be useful at all
22:23agd5f: I think the main use case for SDMA is kernel stuff (paging and GPUVM updates) and host/vram or p2p transfers
22:24Venemo: I get that, but it's so weird that it has all this half-useful functionality