ChanServ changed the topic of #asahi-gpu to: Asahi Linux: porting Linux to Apple Silicon macs | GPU / 3D graphics stack black-box RE and development (NO binary reversing) | Keep things on topic | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-gpu
darkapex has joined #asahi-gpu
chadmed has joined #asahi-gpu
<yuni> lina: It looks like 16-bit pixel formats use 128x64 tiles, and 64-bit pixel formats use 64x32 tiles.
<yuni> This seems annoying to deal with... non-square tiles sound complicated.
<yuni> It's sensible -- it means that 1 tile is exactly 1 page.
<yuni> 16384 = 128 * 128 * 1 = 128 * 64 * 2 = 64 * 64 * 4 = ...
<yuni> It raises tons of questions, though.
PhilippvK has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-gpu
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-gpu
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-gpu
<kode54> wow, that's wacky
<kode54> but sensible
chadmed has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-gpu
MajorBiscuit has joined #asahi-gpu
<yuni> kode54: seriously
<yuni> Tiling pattern for a 256x256 RG8 image:
<yuni> y₇ y₆ x₇ x₆ y₅ x₅ y₄ x₄ y₃ x₃ y₂ x₂ y₁ x₁ y₀ x₀
<yuni> Now to remember how to interpret that ...
jakebot6 has quit [Quit: The Lounge - https://thelounge.chat]
<yuni> For reference, tiling pattern for a 256x256 RGBA8 image:
<yuni> x₇ x₆ y₅ x₅ y₄ x₄ y₃ x₃ y₂ x₂ y₁ x₁ y₀ x₀
jakebot6 has joined #asahi-gpu
<yuni> er that's missing some rows
<yuni> For reference, tiling pattern for a 256x256 RGBA8 image:
<yuni> y₇ y₆ x₇ x₆ y₅ x₅ y₄ x₄ y₃ x₃ y₂ x₂ y₁ x₁ y₀ x₀
<yuni> which is... the same? what?
<yuni> I guess 128x64 and 64x64 tiling looks a lot alike.
<yuni> I don't know.
<yuni> I guess focus on the task at hand, calculating the layouts.
<yuni> 1/3 mesa:asahi / asahi_layout_tests OK 0.01s
<yuni> :-D
MajorBiscuit has quit [Quit: WeeChat 3.5]
<yuni> So now I'm trying to fix the linear<-->tiling routines given what we've discovered
<yuni> dEQP-GLES2.functional.texture.specification.teximage2d_align.2d_rgba8888_47_1 presents an interesting problem
<yuni> Level 0 of 47x27, that's bpp 32, tile size 16x16 Fail (Image comparison failed)
<yuni> Level 0 of 47x27, that's bpp 32, tile size 32x32 Pass (Pass)
<yuni> I just dumped the correct layout, we're generating that correctly.
<yuni> And the tiling pattern:
<yuni> x₅ y₄ x₄ y₃ x₃ y₂ x₂ y₁ x₁ y₀ x₀
<yuni> So that's legitimately a 32x32 tile (or equivalently 64x32).
<yuni> The layout unit test has the first tile as 0x2000 bytes
<yuni> 0x2000 = 64 * 32 * 4, so that's consistent with a 32x32 (or 64x32) tiling.
<yuni> but *not* with a 16x16 tiling
<yuni> For 32-bit, the max tile size is 64x64
<yuni> But this is "small", so we can't use that one.
<yuni> The minor axis is 27 pixels, the "round down" rule gives a 16x16 tile.
<yuni> The "round up" rule gives a 32x32 tile.
<yuni> Oh -- but this is a "small" case
<yuni> So for the size calculation, the width/height are both rounded up to powers of two, giving 64x32
<yuni> and then the tile size within that is irrelevant
<yuni> After rounding up to a power of a two, we get 64x32, and then the minor axis used directly is 32
<yuni> but that's equivalent to the round-up rule!
alyssa has joined #asahi-gpu
<alyssa> yuni: That's all super cursed...
<yuni> Seriously.
<yuni> I have a hack that splits out the cases, which fixes the test. But I think I'm missing the bigger picture
<yuni> Still breaking a pile of dEQPs.
<Ella[m]> this sounds like it's gonna be fun to implement 👀
<Ella[m]> i seem to have other issues rn tho :3
alethkit has joined #asahi-gpu
<yuni> Oh my
<Ella[m]> yeah trying to hook up the shader compiler into the vulkan driver :)
<yuni> good luck!
<Ella[m]> thanks <3
<yuni> The layout code is being moved to src/asahi/layout, so when that's working and merged you'll be able to use for VK
<Ella[m]> oh cool
<yuni> and not worry about all this nonsense.
<Ella[m]> very nice :)
<yuni> Of course that depends on the code working ....
<Ella[m]> 🤞
<yuni> And every time I think I understand how the twiddling works, the hardware throws another a curveball at me.
<alyssa> Ella[m]: btw, where's the vk driver code living?
<Ella[m]> uhhh currently locally on my machine :3
<alyssa> Maybe create an account on https://gitlab.freedesktop.org/ and push to a Mesa fork?
<Ella[m]> alyssa: i have a very old commit is at https://gitlab.freedesktop.org/Ella-0/mesa/-/tree/agxv
<Ella[m]> haven't pushed in a while since my current changes need lots of cleanup
<alyssa> 👀
<Ella[m]> i have a habit of forgetting to push stuff 😩
<alyssa> Would appreciate getting a peak -- there are lots of ways to screw up driver dev and maybe I can keep you from going down a bad path or two
<alyssa> admittedly I don't know much VK driver dev yet myself ...
<Ella[m]> the only other driver dev experience i've had is with relatively small contributions to v3dv
<Ella[m]> but yah i'll push my unclean code now to a wip progress branch :3
<alyssa> awesome :-)
<Ella[m]> oh well this is embarrassing. last time i pushed was from my linux install. I don't even have my ssh keys on macos
<yuni> relatable
<Ella[m]> <alyssa> "Would appreciate getting a peak..." <- ight https://gitlab.freedesktop.org/Ella-0/mesa/-/tree/agxv-mega-wip
<Ella[m]> warning: it's cursed and messy :) no cleanup at all
<alyssa> Ella[m]: Ok, something I notice off the bat:
<alyssa> You have the idea of "CPU jobs" for copies and such...? I know it's not implemented but I have bad news -- that won't work even if it is implemented.
<Ella[m]> oh that's old :) i already know
<alyssa> Unlike in OpenGL (where the driver can "stop the world" at any time and takeover --
<alyssa> got it will shut up :)
<Ella[m]> i just haven't removed it
<alyssa> for the benefit of others reading backlog
<alyssa> Unlike in OpenGL (where the driver can "stop the world" at any time, split the render pass, and do some work on the CPU, and ping pong back), Vulkan really requires everything to happen on the GPU (except where the API specifically happens on the CPU)
<alyssa> Ella[m]: Also, to actually implement those copies and things, there's a bit of talk around building a "vk_blitter" like we have u_blitter in gallium, but this is nontrivial unfortunately :(
<alyssa> there's also maybe hardware support for some(?) blits and copies, lina thinks she saw something relevant in the kernel, but I haven't looked at all because on the gl side I don't really care
<Ella[m]> alyssa: oh cool, i think i was gonna do something similar to what v3dv has (which i think some of the other drivers also have) with meta pipelines blitting (v3dv_meta_copy, v3dv_meta_clear, ...) i'll poke around a bit to see if i come across any hardware support for this stuff tho.
<alyssa> for panvk, I'd really like the v3dv meta pipeline approach to be generalized to common code
<alyssa> realistically if that's an option for agxv you'll want that for the first draft of the driver at least, more pressing matters.
<Ella[m]> yup i'll probably do that at first :) idk first thing is getting my triangle thingy to render properly.
<Ella[m]> it's meant to be like this
<alyssa> nod
alyssa has quit [Quit: Lost terminal]
yuyichao has joined #asahi-gpu
LunaFoxgirlVT has joined #asahi-gpu
LunaFoxgirlVT has quit [Quit: Leaving]
manawyrm has joined #asahi-gpu