00:23 illwieckz: bnieuwenhuizen, I posted the report there: https://gitlab.freedesktop.org/drm/amd/-/issues/2860
00:24 illwieckz: airlied ↑
00:28 illwieckz: I don't really know what is a “power supply transition”, but that computer is made of top-quality components all the way down.
00:52 illwieckz: And before I replaced my old GCN1 and GCN2 GPUs with that new RDNA3 one, I had uptimes of months and only rebooted on purpose to get kernel updates.
00:56 illwieckz: Damn, I probably had to solve 30 captchas to validate my edit on the report…
10:40 pepp: soreau: made some (small) progress on the glClear issue (see my gitlab comment)
14:29 soreau: pepp: yep, that works :)
14:31 pepp: soreau: nice. Now I need to figure out why this is solving the issue :)
14:31 soreau: heh
14:40 pepp: soreau: btw does AMD_DEBUG=nohyperz work (without the patch)?
14:47 soreau: pepp: It seems kinda obvious to me that the comment says DCC only but it's not guarded by the vi_dcc_enabled() condition
14:47 soreau: I will test, one sec
14:49 soreau: no, disabling hyperz doesn't help
14:49 pepp: ok
14:53 soreau: but trying to pass level to the function and testing with vi_dcc_enabled() doesn't help
15:10 soreau: pepp: This fixes it too: http://ix.io/4GUc
15:13 soreau: and this http://ix.io/4GUf
15:18 pepp: yeah but these are ways to make si_set_clear_color incorrectly return true
15:21 soreau: right
15:22 soreau: maybe you can explain a bit how this part is supposed to work?
15:23 soreau:becomes a rubber duck
15:23 soreau: I see color_clear_value is unsigned (int) [2]
15:24 soreau: and uc.ui is uint32_t [4]
15:26 soreau: and and color->ui is unsigned int [4]
15:26 pepp: it depends on tex->surface.bpe
15:30 soreau: and what is bpe?
15:31 pepp: errr no.. let me take a look
15:31 soreau: I see it's defined as uint8_t bpe : 5;
15:31 soreau: in amd/common/ac_surface.c:299
15:31 soreau: but no comment afaics
15:32 agd5f: soreau, IIRC, bytes per element
15:36 pepp: agd5f: yes
15:38 pepp: soreau: so AFAICT fast clears only support bpe <= 8. In this case, instead of clearing all the bytes of a texture, only the small cmask buffer is cleared to 0. This cmask==0 special value is interpreted as "the texture has been cleared to the value stored in CB_COLOR0_CLEAR_WORD0/CB_COLOR0_CLEAR_WORD1" (each register being 4 bytes)
15:39 pepp: that's why si_set_clear_color only checks the first 2 uint
15:46 soreau: well it seems there's a condradiction because if vi_dcc_enabled() is true, it continue;s if bpe > 8 but in si_set_clear_color(), it says if bpe == 16, DCC fast clear only in a comment
15:48 soreau: and cmask path is slow clears?
15:55 pepp: cmask is fast clear too (and I'm not looking at dcc clear because I'm testing with nodcc)
15:57 soreau: oh ok
16:14 soreau: well shouldn't the memcmp call be dependent on the bpe somehow?
16:15 soreau: in my case, bpe == 4
16:16 soreau: so that's 32 bits, but it's comparing 2 * sizeof(uint32_t) bytes
16:19 MrCooper: taking a step back, even if fast clear was used when it shouldn't be, it shouldn't prevent later drawing from appearing; that indicates the fast clear state somehow gets applied after the later drawing commands
16:27 soreau: MrCooper: yea that was one of my first guesses
16:27 soreau: because looking close up, it seems like it's doing The Right Thing
16:28 soreau: like a scheduling issue
16:45 soreau: but still, I don't understand currently, how tex->color_clear_value[0] is 0 and *((uint64_t *)&uc) is 0, but somehow memcmp(tex->color_clear_value, &uc, 2 * sizeof(uint32_t)) doesn't return 0?
16:46 soreau: oh it does
16:47 soreau: when it memcmp returns 0, the function returns false
16:49 soreau: so it doesn't set the fb dirty flag(s) and then it gets out of order
16:49 soreau: but only sometimes
17:02 soreau: is gfx6-8 kinda grouped together?
17:02 soreau: because gfx6_compute_level() is called here on gfx8
17:07 soreau: I see a comment in that function /* GFX7 - GFX8 */ so I guess so
21:20 soreau: I guess it's possible that the draw command renders to the wrong buffer somehow (front?) and then swap buffers reveals the transparent buffer since the clear call actually cleared the correct buffer
21:22 soreau: of cours, despite mesa_glthread=false GALLIUM_THREAD=0 being set, gdb can't reverse-step since it says it's a threaded context
21:49 soreau: or that the rendering call silently fails somehow
23:17 soreau: I added glReadPixels to detect when a blank texture happens, and read pixels fills the fb with all 0's, before the texture is actually blank on screen. The texture shows up blank on screen on the next buffer swap