<alyssa>
If the whole image is 16x16, there is a single 8 byte compression tile
<alyssa>
But that formula would give stride of compression == 8 * (16 / 16) = 8
<alyssa>
implying that the compression plane as a whole is stride * height = 8 * 16 = 128 bytes
<alyssa>
from Mesa's perspective it doesn't matter regardless, it's just an arbitrary number anyway
<alyssa>
but if we're trying make dumb dump-and-copy work, that's going to blow up
<alyssa>
maybe more to the point, there's no integer value of stride that "works" in the sense that stride * height = 8 for height=16
<alyssa>
in effect, the "stride" should be 1/2
<alyssa>
i'm sure the modifier-unaware dump-and-copy is going to love a fractional stride though >.<
<alyssa>
if making this work is a hard requirement, I can invent something dumb adding extra padding but I'm.. not sure what problem we're trying to solve here exactly, and I don't know of userspace that actually does this dance
<alyssa>
(please enlighten me so I can test..)
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
<alyssa>
"stride of compression == max((8 * round to power of two(w)) / 256, 1)"
rsalvaterra_ has joined #dri-devel
<alyssa>
I /think/ that works
rsalvaterra_ is now known as rsalvaterra
<alyssa>
in the pathological 16x16 case, it sets stride to 1 and so we overread by 8 bytes but that's fine
<alyssa>
and in all real cases it's correct.
<alyssa>
so i guess just a lack of creativity on my part :p
CME_ has joined #dri-devel
CME has quit [Ping timeout: 480 seconds]
anholt has quit [Ping timeout: 480 seconds]
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
sally has joined #dri-devel
anholt has joined #dri-devel
odrling has quit [Remote host closed the connection]
odrling has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
<alyssa>
no but that's not quite right either because that fails to model the fact that the height must also be padded to power-of-two for the metadata plane but not for the main plane
classactatcode has joined #dri-devel
<alyssa>
how are strides supposed to work at all for nonlinear images?
<alyssa>
is any of this documented?
<alyssa>
just blindly setting to (width*bpp) is the only thing that actually makes sense in my brain
<alyssa>
since stride.. doesn't make sense for these nonlinear formats at all, we just need to plug in the thing that the core is expecting (and if not for that legacy tradition I'd be setting to zero.)
anholt has quit [Ping timeout: 480 seconds]
<classactatcode>
I did not understand what was unreadable for that pdf content at all. I was telling you the whole time that one alu is somewhere between 32768 to 65536 digits worth of allocated range in a storage location, because they handle carry and sum for 0 and 1 , they do it in 17-18bits or so instead of the former in hardware in the pdf. In other words there was binary distribution which is
<classactatcode>
well elaborated and explained in the pdf and if that happens to summed up sequence of size 1500 decimal digits for example you take base 2 logarithm of 1500 multiplied by base two logarithm of 32, cause every field in the bitfield of powers is equiprobable, so the author concludes exactly the same as i did say all the time so round about i mean moreover perhaps. But me splitting ways
<classactatcode>
for me applies i suppose, and i am better off leaving.
rsalvaterra has quit []
rasterman has quit [Quit: Gettin' stinky!]
sravn has quit []
<alyssa>
actually thinking it more.. yeah, any tool that uses the stride for *anything* without understanding the modifier itself is fundamentally broken
<alyssa>
we just don't have the information standardized to do anything generically other than "memcpy the entire bo->size"
<alyssa>
so the correct thing to do is choose some convention arbitrarily (as long as the core's checks are satisfied) and stick to it
<alyssa>
and the simplest possible convention that satisfies the core's checks is what I'm doing right now so I see very little reason to do otherwise
<alyssa>
ditto for planes at that point
<alyssa>
so that's back to "copy how AFBC works"
anholt has joined #dri-devel
cphealy_ has quit []
<misyl>
Anyone know what I need to try out DRM native context for AMDGPU? It seems like maybe the qemu side wasn't merged yet? Or am I mistaken and I am missing it somewhere?