20:11 enunes: anarsoul: I made some progress in the 4096 texture issue, by creating a smaller reproducer and being able to dump with the blob driver
20:11 anarsoul: great!
20:11 anarsoul: so what's the issue?
20:12 enunes: I think it has to do with how we calculate BLOCK_STEP and BLOCK_STRIDE for that specific size
20:12 anarsoul: oh
20:12 anarsoul: so kusma was right
20:16 enunes: basically this https://paste.centos.org/view/raw/9c7a6d66
20:19 anarsoul: block_num is incorrect?
20:19 anarsoul: oh
20:19 anarsoul: block_stride is also different
20:20 enunes: shift_w too
20:20 enunes: indeed he was in the right direction
20:21 anarsoul: :\
20:21 enunes: my smaller reproducer actually reads the texture in half so I guess it makes sense
20:26 anarsoul: so I assume block_w: 0 is invalid
20:26 anarsoul: and that's why we hit it
20:32 anarsoul: maybe it makes sense to add an assert for that
20:33 enunes: it doesn't seem to be possible to be 0 so I wonder how we end up with it
20:36 anarsoul: overflow?
20:38 anarsoul: well, we are shifting it right, so it can reach 0
20:38 anarsoul: width = (width + 1) >> 1;
20:42 enunes: with some prints I see fb->block_w 256 so I'm quite confused now
20:43 enunes: wow #define PLBU_CMD_BLOCK_STRIDE(block_w) PLBU_CMD((block_w) & 0xff
20:43 anarsoul: yet I get width: 256, height: 2, shift_w: 0, shift_h: 0
20:43 anarsoul: ouch
20:43 anarsoul: :)
20:44 anarsoul: well, sounds like width cannot be 256?
20:44 anarsoul: or can it?
20:48 anarsoul: yeah, I think it's 8 bit
20:48 anarsoul: so 4096 needs a special handling
20:52 anarsoul: enunes: something like https://pastebin.com/U361wyHK ?
20:54 enunes: seems like it, I was just coming up with something similar to test
21:08 enunes: yep bug is gone
21:46 anarsoul: great!