05:38soreau: mareko: to simplify things, does this look correct? http://ix.io/4HI5
08:08mareko: it's a start
11:50soreau: I'm still not sure about GB_TILE_MODE0, GB_MACROTILE_MODE0 and GB_ADDR_CONFIG.. I see their definitions and use in some places and I'm guessing it would require more definitions in drm_fourcc.h but it's not clear exactly what is needed
11:51soreau: I skimmed through addrlib but that didn't really help my understanding
11:56soreau: but I assume the registers need to be written wherever applicable and not read
14:13MrCooper: soreau: the registers are already being programmed as needed; the modifier values need to encode the relevant register (field) values being programmed
14:14MrCooper: such that the same modifier value results in the same register values, and the same GPU memory access pattern
14:23agd5f: soreau, s/AMD_FMT_MOD_TILE_VER_GFX8/AMD_FMT_MOD_TILE_VER_GFX6/ since it applies to gfx6-8
14:30agd5f: soreau, GB_TILE_MODE[x], GB_MACROTILE_MODE[x] and GB_ADDR_CONFIG represent the buffet of options available. you need to encode those possibilities into the 56 bits or so that you have available so that userspace components can pick one ones it wants. The kernel side in DRM would expose the encoding that the display hardware can support and mesa would expose the encodings that the accel engines support
14:56soreau: MrCooper: ok
14:56soreau: agd5f: so this means changes are needed in drivers/gpu/drm/amd/amdgpu/si.c too?
14:59soreau: I am having difficulty knowing what needs to go where
16:39soreau: something like this? http://ix.io/4HI5
16:39soreau: still doesn't do anything with GB_TILE_MODE[x] and GB_MACROTILE_MODE[x] though
21:04bnieuwenhuizen: soreau: gfx6-gfx8 have significantly different tiling setup, you don't really (or at least not directly) have pipe_xor_bits/bank_xor_bits
21:05soreau: bnieuwenhuizen: oh ok
21:05bnieuwenhuizen: my original header patch is probably a good start on the fields you need (though can be simplified a bit by making multiplanar formats linear only)
21:07bnieuwenhuizen: also https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c#L180 is a good intro on the bits you need to set on the display HW
21:08soreau: ah, I was looking at a patch on the web that had some of this information
21:08soreau: didn't know it was right in front of my face ;)
21:09bnieuwenhuizen: note that there is some mess since the display HW is almost infinitely flexible but the render HW can only use an array of 32 configs, so you may need to be careful wrt how many modifiers to expose from the kernel
21:09soreau: I see
21:10bnieuwenhuizen: this is the array definition for gfx8 cards: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c#L2074
21:10soreau: bnieuwenhuizen: so what is the function or bits that expose to userland?
21:10bnieuwenhuizen: the add_modifier stuff
21:11soreau: ok thanks
21:16soreau: bnieuwenhuizen: in your original RFC, I see AMDGPU_CHIP_* but I don't see this in the kernel 6.5 amdgpu_drm.h header..
21:16soreau: what happened there?
21:17soreau: though I do see the AMDGPU_FAMILY_* stuff
21:18soreau: grep doesn't show anything for AMDGPU_CHIP_* either, that I can tell
21:31soreau: oh the AMDGPU_ part is gone
21:33soreau: and in amd_asic_type.h
21:37soreau: so it looks like that part has everything
21:38soreau: and that just leaves AMDGPU_MODIFIER_GFX8_*
21:40soreau: then there's s/AMDGPU_MODIFIER_SET/AMD_FMT_MOD_SET/ I assume
21:40soreau: but I'm still a bit confused on where GB_TILE_MODE[x], GB_MACROTILE_MODE[x] and GB_ADDR_CONFIG comes in
21:47soreau: for AMDGPU_MODIFIER_GFX8* I did s/AMDGPU_MODIFIER_/AMD_FMT_MOD_TILE_/ and put the defines in drm_fourcc.h but something feels wrong about this
21:47soreau: since it doesn't seem to match anything surrounding
22:45vaxry: hey, I have this weird issue, in cs2, and only cs2, after I implemented tearing updates (DRM_MODE_PAGE_FLIP_ASYNC) I get artifacts like these: https://streamable.com/a694h3 on both vulkan-radeon and amdvlk. It's definitely below wayland because buffers from my compositor look pristine. Only happens when moving my mouse about. drmModePageFlip fails with "Device or resource busy" very often when that happens. Asked two other people on amd to test...
22:45vaxry: ... and they don't seem to get the issue. Any clue on how to debug this even?
22:45vaxry: if I don't commit with the ASYNC flag the artifacts are gone
23:40soreau: vaxry: have you looked at kmscube at all?
23:40vaxry: kmscube? no, what's that?
23:41vaxry: a demo app for kms graphics, why's that?
23:44soreau: have you tried radv?
23:45vaxry: isn't that vulkan-radeon?
23:52soreau: well I guess if it happens with both drivers, and they both use amdgpu, it could be a kernel issue
23:52soreau: have you tried a different kernel version?
23:55vaxry: hm, that is true. I'll try. Is it better to try just downgrading or rather using something like -zen?
23:55soreau: you can try an older kernel. 'different' is the key I think
23:56soreau: but it's not impossible it's in your use of drm. are you using multiple bo's for flipping?
23:58soreau: and yet another option (if you haven't already) is to ask in #dri-devel, but here on irc, the weekends are kinda slow
23:58vaxry: no worries, it's just cs2, no other game. I'm not in a massive hurry
23:58vaxry: my use of drm is the wlroots mr I made https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3871/diffs
23:58vaxry: no clue about bo usage there tbh...
23:59vaxry: what I know is that something does go wrong on my setup as I get a spam of logs about pageFlip failing with resource / device busy and wlroots complaining about "unexpected flips for crtc 82"
23:59soreau: eh, you're implementing tearing protocol and wondering why it tears? that seems kind of ironic :)
23:59vaxry: it does tear thats good
23:59vaxry: but the artifacts are not tearing