alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
enunes has quit [*.net *.split]
Green has quit [*.net *.split]
vstehle has quit [*.net *.split]
italove has quit [*.net *.split]
macc24 has quit [*.net *.split]
dhewg has quit [*.net *.split]
urjaman has quit [*.net *.split]
BenG83 has quit [*.net *.split]
tgall_foo has quit [*.net *.split]
cowsay_ has quit [*.net *.split]
bbrezillon has quit [*.net *.split]
anarsoul has quit [*.net *.split]
zkrx has quit [*.net *.split]
Net147 has quit [*.net *.split]
l-as has quit [*.net *.split]
exit70[m] has quit [*.net *.split]
ids1024 has quit [*.net *.split]
afaerber has quit [*.net *.split]
bnieuwenhuizen has quit [*.net *.split]
nlhowell has quit [*.net *.split]
tlwoerner has quit [*.net *.split]
Venemo has quit [*.net *.split]
robink has quit [*.net *.split]
Stenzek has quit [*.net *.split]
dstzd has quit [*.net *.split]
leah has quit [*.net *.split]
phh has quit [*.net *.split]
lvrp16 has quit [*.net *.split]
ezequielg has quit [*.net *.split]
steev has quit [*.net *.split]
milkii has quit [*.net *.split]
leper` has quit [*.net *.split]
Stary has quit [*.net *.split]
dschuermann has quit [*.net *.split]
mifritscher has quit [*.net *.split]
krh has quit [*.net *.split]
ChanServ has quit [*.net *.split]
gcl has quit [*.net *.split]
pmjdebruijn has quit [*.net *.split]
Lyude has quit [*.net *.split]
mani_s has quit [*.net *.split]
kinkinkijkin has quit [*.net *.split]
wiizzard has quit [*.net *.split]
Ke has quit [*.net *.split]
tomeu has quit [*.net *.split]
chrisf has quit [*.net *.split]
alyssa has quit [*.net *.split]
mmind00 has quit [*.net *.split]
mchehab has quit [*.net *.split]
paulk-leonov has quit [*.net *.split]
klaxa has quit [*.net *.split]
megi has quit [*.net *.split]
jolan has quit [*.net *.split]
robmur01 has quit [*.net *.split]
felipealmeida has quit [*.net *.split]
griffinp- has quit [*.net *.split]
yawniek has quit [*.net *.split]
Ashleee has quit [*.net *.split]
samueldr has quit [*.net *.split]
AreaScout_ has quit [*.net *.split]
karolherbst has quit [*.net *.split]
nhp has quit [*.net *.split]
austriancoder has quit [*.net *.split]
cwabbott has quit [*.net *.split]
cyrozap has quit [*.net *.split]
robher has quit [*.net *.split]
sigmaris has quit [*.net *.split]
Werner has quit [*.net *.split]
rcf has quit [*.net *.split]
remexre has quit [*.net *.split]
empty_string has quit [*.net *.split]
solidhal has quit [*.net *.split]
andrey-konovalov has quit [*.net *.split]
rellla has quit [*.net *.split]
tomboy64 has quit [*.net *.split]
MoeIcenowy has quit [*.net *.split]
HdkR has quit [*.net *.split]
jgmdev has quit [*.net *.split]
thecycoone1 has quit [*.net *.split]
maciejjo has quit [*.net *.split]
hl has quit [*.net *.split]
icecream95 has quit [*.net *.split]
rtp has quit [*.net *.split]
taowa has quit [*.net *.split]
br_ has quit [*.net *.split]
doublej41 has quit [*.net *.split]
stepri01 has quit [*.net *.split]
Prf_Jakob has quit [*.net *.split]
indy has quit [*.net *.split]
ckeepax has quit [*.net *.split]
Depau has quit [*.net *.split]
robertfoss_ has quit [*.net *.split]
endrift has quit [*.net *.split]
tchebb has quit [*.net *.split]
ente has quit [*.net *.split]
embed-3d has quit [*.net *.split]
xperia64 has quit [*.net *.split]
xdarklight has quit [*.net *.split]
clementp[m] has quit [*.net *.split]
youcai has quit [*.net *.split]
cphealy has quit [Remote host closed the connection]
icecream95 has joined #panfrost
nlhowell has joined #panfrost
dstzd has joined #panfrost
rcf has joined #panfrost
gcl has joined #panfrost
klaxa has joined #panfrost
karolherbst has joined #panfrost
tomeu has joined #panfrost
megi has joined #panfrost
Stenzek has joined #panfrost
griffinp- has joined #panfrost
Venemo has joined #panfrost
chrisf has joined #panfrost
taowa has joined #panfrost
jgmdev has joined #panfrost
macc24 has joined #panfrost
remexre has joined #panfrost
nhp has joined #panfrost
tomboy64 has joined #panfrost
tlwoerner has joined #panfrost
robher has joined #panfrost
jolan has joined #panfrost
robmur01 has joined #panfrost
kinkinkijkin has joined #panfrost
felipealmeida has joined #panfrost
leah has joined #panfrost
stepri01 has joined #panfrost
Ke has joined #panfrost
wiizzard has joined #panfrost
clementp[m] has joined #panfrost
phh has joined #panfrost
thecycoone1 has joined #panfrost
alyssa has joined #panfrost
pmjdebruijn has joined #panfrost
endrift has joined #panfrost
xperia64 has joined #panfrost
maciejjo has joined #panfrost
yawniek has joined #panfrost
Lyude has joined #panfrost
austriancoder has joined #panfrost
Prf_Jakob has joined #panfrost
steev has joined #panfrost
solidhal has joined #panfrost
indy has joined #panfrost
tchebb has joined #panfrost
youcai has joined #panfrost
cwabbott has joined #panfrost
empty_string has joined #panfrost
mani_s has joined #panfrost
robink has joined #panfrost
br_ has joined #panfrost
hl has joined #panfrost
mifritscher has joined #panfrost
Stary has joined #panfrost
milkii has joined #panfrost
Ashleee has joined #panfrost
rtp has joined #panfrost
leper` has joined #panfrost
ente has joined #panfrost
embed-3d has joined #panfrost
krh has joined #panfrost
cyrozap has joined #panfrost
ckeepax has joined #panfrost
sigmaris has joined #panfrost
paulk-leonov has joined #panfrost
mmind00 has joined #panfrost
lvrp16 has joined #panfrost
ezequielg has joined #panfrost
HdkR has joined #panfrost
mchehab has joined #panfrost
dschuermann has joined #panfrost
ChanServ has joined #panfrost
robertfoss_ has joined #panfrost
MoeIcenowy has joined #panfrost
samueldr has joined #panfrost
Werner has joined #panfrost
andrey-konovalov has joined #panfrost
AreaScout_ has joined #panfrost
rellla has joined #panfrost
Depau has joined #panfrost
xdarklight has joined #panfrost
doublej41 has joined #panfrost
l-as has joined #panfrost
ids1024 has joined #panfrost
afaerber has joined #panfrost
bnieuwenhuizen has joined #panfrost
exit70[m] has joined #panfrost
enunes has joined #panfrost
Green has joined #panfrost
bbrezillon has joined #panfrost
urjaman has joined #panfrost
anarsoul has joined #panfrost
tgall_foo has joined #panfrost
italove has joined #panfrost
BenG83 has joined #panfrost
vstehle has joined #panfrost
dhewg has joined #panfrost
Net147 has joined #panfrost
zkrx has joined #panfrost
cowsay_ has joined #panfrost
wiizzard has quit [Ping timeout: 246 seconds]
Ke has quit [Ping timeout: 246 seconds]
l-as has quit [Ping timeout: 240 seconds]
exit70[m] has quit [Ping timeout: 240 seconds]
clementp[m] has quit [Ping timeout: 268 seconds]
daniels has quit [Ping timeout: 274 seconds]
daniels has joined #panfrost
ric96 has quit [Ping timeout: 264 seconds]
ric96 has joined #panfrost
atler has joined #panfrost
Ke has joined #panfrost
wiizzard has joined #panfrost
Ke has quit [Ping timeout: 246 seconds]
wiizzard has quit [Ping timeout: 246 seconds]
BenG83 has quit [Quit: Leaving]
clementp[m] has joined #panfrost
karolherbst has quit [Ping timeout: 272 seconds]
Ke has joined #panfrost
exit70[m] has joined #panfrost
l-as has joined #panfrost
wiizzard has joined #panfrost
bbrezillon has quit [Ping timeout: 246 seconds]
bbrezillon has joined #panfrost
atler has quit [Ping timeout: 246 seconds]
vstehle has quit [Ping timeout: 264 seconds]
kaspter has joined #panfrost
kaspter has quit [Excess Flood]
<icecream95> I suspect the bug is related to the tiler heap
kaspter has joined #panfrost
<icecream95> Does that give me an excuse for reverse-engineering the tiler datastructures?
bbrezillon has quit [Remote host closed the connection]
<alyssa> icecream95: On Midgard or on Bifrost? ;P
<icecream95> alyssa: Bifrost
<alyssa> glhf ;P
bbrezillon has joined #panfrost
<icecream95> Oh, seems it wasn't anything to do with the tiler that fixed it, it was me accidentally removing the call to panfrost_batch_add_fbo_bos
<icecream95> Though maybe that just changed the timing so the bug didn't reproduce. I hate timing related bugs
ndufresne has joined #panfrost
davidlt has joined #panfrost
vstehle has joined #panfrost
vstehle has quit [Ping timeout: 246 seconds]
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #panfrost
vstehle has joined #panfrost
icecream95 has quit [Read error: Connection reset by peer]
icecream95 has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #panfrost
<bbrezillon> alyssa: yep, as anarsoul said, as long as you have a FD you should be good, you can even close the FD after importing the BO in your DRM context
archetech has joined #panfrost
archetech has quit [Quit: Konversation terminated!]
<icecream95> I'm just going to give up debugging this and claim it's a kernel bug
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
alpernebbi has joined #panfrost
<icecream95> alyssa: I wonder if we should keep using madvise, but only for resource BOs
<icecream95> And maybe just for non-BUFFER resources
karolherbst has joined #panfrost
atler has joined #panfrost
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #panfrost
warpme_ has joined #panfrost
<icecream95> Firefox usually only has about 2M of non-(non-BUFFER resource) BOs in the cache
<icecream95> (That's two megabytes worth, not two million)
<icecream95> On gitlab.fd.o, it spikes all the way up to 3.5 MB
raster has joined #panfrost
stikonas has joined #panfrost
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #panfrost
<icecream95> alyssa: On the subject of resource BOs, I have a patch for AFBC compaction, which can cut resource size in ~half
<icecream95> (BTW, "body ... must also be cache-line aligned" in pan_afbc.c is a lie, at least on Midgard it works fine with no alignment at all)
nlhowell has quit [Ping timeout: 260 seconds]
<icecream95> The operation is relatively expensive, needing to wait for writes to finish, and then two passes need to be made over the resource by the CPU
<icecream95> (it could be done in compute shaders, and might even be faster than doing it on the CPU, but...)
<icecream95> Just doing it after rendering won't work very well, and for mipmaps the resource would need to be copied many times
karolherbst has quit [Quit: duh 🐧]
<icecream95> I considered triggering it after the resource is used as a texture a certain number of times, but that won't compress textures that aren't used, which still take up space
<icecream95> Maybe it would be best to at the BO to a list, and then after ~two seconds check if the BO is still there and not being used as an FBO
<icecream95> *add
<icecream95> Any better ideas?
<icecream95> (the checking could be done in a separate thread, which might also handle freeing cached BOs...)
karolherbst has joined #panfrost
rcf has quit [Quit: WeeChat 2.9]
icecream95 has quit [Ping timeout: 256 seconds]
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #panfrost
kaspter has quit [Remote host closed the connection]
kaspter has joined #panfrost
BenG83 has joined #panfrost
<robmur01> re AFBC alignment: in a toss-up between what seems to work on a particular implementation and what the architecture spec says, I'd still go with the spec every time
<robmur01> Midgard says 64 bytes
<stepri01> AFBC buffers can be shared - so it's quite possible the GPU doesn't enforce the spec alignment, but if you end up sharing it with a display controller the alignment might be necessary
<stepri01> also worth remembering that the hardware is unlikely to have been tested with the spec-violating alignment... ;)
tomboy64 has quit [Write error: Broken pipe]
<robmur01> also if it were the case that the hardware implementations for both writeout and readback simply ignore the low-order bits, and you deliberately pad the buffer to force a misaligned start, then typically the end result *will* work out fine, just not quite for the reasons expected
<kinkinkijkin> switched on a random cap and am not having any new bugs, PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT
<kinkinkijkin> guess ARB_buffer_storage is ready to be switched on soon
<kinkinkijkin> but there's probably a big reason why it's not on by default
kaspter has quit [Ping timeout: 246 seconds]
tomboy64 has joined #panfrost
kaspter has joined #panfrost
rcf has joined #panfrost
raster has quit [Remote host closed the connection]
raster has joined #panfrost
chewitt has joined #panfrost
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #panfrost
<alyssa> icecream95: Perhaps, would need to look at the ttrade offs (re: madvising textures)
<alyssa> As for AFBC compaction, I don't know any of the internals of AFBC so I can't really comment.
<robmur01> FWIW the internals of AFBC have even *more* alignment rules ;)
karolherbst has quit [Quit: duh 🐧]
<alyssa> Lovely
kaspter has quit [Quit: kaspter]
karolherbst has joined #panfrost
kaspter has joined #panfrost
karolherbst has quit [Quit: duh 🐧]
kaspter has quit [Quit: kaspter]
karolherbst has joined #panfrost
<felipealmeida> jstultz: hi, I'm trying to use your kernel on a hikey960 with panfrost
<macc24> felipealmeida: doesn't kirin 960 have G71?
<felipealmeida> yes, isn't g71 bifrost?
<macc24> short answer is it won't work
<felipealmeida> why?
<macc24> long answer alyssa will tell you if you ask her
<felipealmeida> ah, I do expect to need some development
<felipealmeida> I have some developers idle, and I want to start some development on the vulkan driver
<macc24> felipealmeida: here's a copypaste from backloog when g71 was talked: <alyssa> G71 omits support for fp32 transcendentals so is totally broken on panfrost rn
<felipealmeida> macc24: yeah, I know, I was in that dicussion
<macc24> oh yeah
<macc24> q4a does/did/talked about doing some vulkan stuff
<felipealmeida> what/who is q4a?
<macc24> i don't know
<macc24> they don't have a bouncer
<felipealmeida> I did see some mention of vulkan
<felipealmeida> but it was using llvm generation I think?
<macc24> llvmpipe can be hacked to use harwdare acceleration but patches won't be accepted
<jstultz> felipealmeida: cool! I've not had the bandwidth to look at panfrost (and the few times I did much earlier, folks hinted I should wait a bit before trying to run AOSP on it), but I'd love to see it going!
<felipealmeida> jstultz: I'm not really focused on aosp yet, I'm building with openembedded
<felipealmeida> jstultz: why did you use mail-midgard in dts? was that to get mali drivers to pick it up?
<felipealmeida> iirc, g71 is a bifrost mali
<macc24> felipealmeida: IIRC they can be distingueshed without different compatible nodes
<jstultz> felipealmeida: so, that's what was in the original BSP using the mali driver and blob, and we've just forward ported thing along
<felipealmeida> ok, I'll try mali-bifrost and see if panfrost drm is loaded instead
<jstultz> felipealmeida: and your right, it is bifrost.
<macc24> felipealmeida: panfrost doesn't have mali-midgard dts compatible
<felipealmeida> jstultz: I used your WIP kernel branch for 5.11
* macc24 points at ttps://github.com/torvalds/linux/blob/master/drivers/gpu/drm/panfrost/panfrost_drv.c#L668-L683
<felipealmeida> macc24: that's why I'll change it to mali-bifrost
<jstultz> felipealmeida: cool. do let me know how it goes. if there are additional patches you need to make it work, send them along and I'll add them to my tree.
<felipealmeida> jstultz: it failed compilation, so I added dsi_encoder_[enable,disable] declarations and removed static from their definitions
<felipealmeida> dw_drm_dsi.c and kirin_drm_dsi.c
<felipealmeida> jstultz: thanks, btw, do you know ricardo salveti?
<jstultz> felipealmeida: yea! its been awhile since i've seen him, though.
<felipealmeida> he lend me the boards, we studied in the same computer science class
<jstultz> felipealmeida: nice! they are sadly hard to come by these days.
<jstultz> felipealmeida: tell him hey for me next time to see him.
<felipealmeida> jstultz: will do, we live like 2km from each other. Which is equivalent to a thousand km now in this pandemic
<jstultz> felipealmeida: yea, i know how that goes :)
<felipealmeida> well, did get some panfrost messages
<felipealmeida> not good ones though :-D
<HdkR> Getting closer at least :)
<macc24> HdkR: i got a 3d printer :D
<HdkR> Whoa
<macc24> when i'm done procrastinating i will make a custom keyboard for duet
<macc24> i got schematics for it, need to make pcb, order stm32, couple of caps, resistors and crystals and ill share it
<macc24> will probably work with regular phones too
<alyssa> felipealmeida: I'd write the compiler patches for G71 if it means someone starts spending time on Vulkan..
<macc24> alyssa: is G71 the oddball of bifrosts?
<alyssa> macc24: Yes, it's the T6xx of Bifrost ;P
<macc24> knew it
<macc24> glad to have gpu with not the worst support in panfrost
<alyssa> FRCP, FRSQ, FEXP2, and FLOG2 are missing.
<macc24> i like your funny words
<alyssa> 1/x, 1/sqrt(x), 2^x, log2(x)
<macc24> ah
<macc24> is this missing in hardware or in compiler?
<macc24> coz some are useful
<alyssa> Hardware
<macc24> oh
<macc24> does g72 support sqrt(x)?
<HdkR> Turns out when you remove transcendentals, things slow down :P
<alyssa> AFAIK no Bifrost has sqrt(x), you compute 1/sqrt(x) and multiply by x
<macc24> HdkR: g72 still is fast in comparison to t860 and t760
<macc24> when optimizations hit panfrost i'm gonna do some benchmarking
<HdkR> Sure, they added the transcendentals back :D
<alyssa> ok this is stressing me out
<HdkR> \o
<macc24> alyssa: for me rendering triangles is impressive
<macc24> i'm not "gpu driver" person
<alyssa> Going to give the G71 patches a go since I don't have cycles to spend on scheduler right now
<alyssa> Disconnecting IRC since this is stressful, bbiab
icecream95 has joined #panfrost
karolherbst has quit [Ping timeout: 240 seconds]
davidlt has quit [Ping timeout: 256 seconds]
<felipealmeida> alyssa: that's great. Let me see how far I can go without any funding. If I get anywhere, then that would really help.
alpernebbi has quit [Quit: alpernebbi]
<bbrezillon> alyssa: so I'm looking at indirect draws and varyings allocation is kind of problematic. The amount of mem to attach to varying ATTRIB_BUFs depends on vertex_count/instance_count which we don't know when we pre-allocated the descritpors
<bbrezillon> should we use growable buffers for that, or is there a way to estimate the worst case scenario based on the static bits passed to the ->draw_vbo() call?
raster has quit [Quit: Gettin' stinky!]
jolan has quit [Quit: leaving]
<alyssa> felipealmeida: root@kevin:/home/alyssa/mesa/src/panfrost/bifrost# dmesg -k | grep panfrost | grep id
<alyssa> Run that on the board and paste it here
<alyssa> bbrezillon: Ugh..
<alyssa> Let me check the spec...
jolan has joined #panfrost
atler has left #panfrost [#panfrost]
Elpaulo has joined #panfrost
atler has joined #panfrost
<felipealmeida> alyssa: I've modified to get the clock "core" but didn't compile yet
<felipealmeida> but the errors are:
karolherbst has joined #panfrost
<alyssa> I don't touch clock stuff, sorry
raster has joined #panfrost
<alyssa> felipealmeida: Rephrasing, could you printk the register GPU_ID and send that to me?
<felipealmeida> how do I do that?
<alyssa> 🤷
<felipealmeida> static inline int panfrost_model_cmp(struct panfrost_device *pfdev, s32 id) <-- this id?
<alyssa> yeah
<felipealmeida> never opened a gpu driver before :D
<macc24> alyssa, felipealmeida: wish you luck getting G71 to work :D
<icecream95> alyssa: There's a magic function which halves resource size at the cost of making it non-renderable (and may or may not violate specs). Where does it get called?
<alyssa> icecream95: What's the effect on texturing performance? (Is memory b/w reduced, or is it just RAM footprint?)
<icecream95> alyssa: For the spec-violating variant, b/w may be slightly reduced, but probably not otherwise
<alyssa> Observation: "non-renderable" only applies for true partial updates (where we manage to scissor the tile writeback), which... are comparatively rare
wiizzard has quit [Ping timeout: 246 seconds]
<alyssa> For the average resource, even if you call magic function on it,you can still render to it after since that would incur a texture operation, and write to a completely new resource' with a renderable layout.
Ke has quit [Ping timeout: 246 seconds]
<alyssa> (Resource state transitions. Believe me, I know about transition.)
<alyssa> That isn't to say magic function is free or even cheap, but it means the tradeoff probably isn't as big as it appears.
<alyssa> So all else being equal, magic function makes sense to call for _any_ texture that's not expected to be rendered to (noting in the worst case, we just make a new allocation and carry on)
<alyssa> Almost sounds like you'd want to call it at transfer_map time, depending on the cost. But of course this being AFBC, that doesn't make sense because we're using the 3D pipe for linear->AFBC.
<alyssa> So maybe question #2 is whether there is a magic function that halves the size of a linear texture? (i.e. composing the original magic function with a s/w AFBC encoder)
<alyssa> If so, depending on costs involved, it might make sense to just use that the same way we currently use store_tiled_texture
<alyssa> But that's a big if, regular texture tiling isn't cheap and if this new magic function is significantly more expensive than that, we may end up at a loss w.r.t CPU usage.
<alyssa> As for "calling in low memory situations" ... I'm not convinced this is reasonable on Linux.
<alyssa> First of all because userspace doesn't have a great way to handle low mem (it's supposedly kernel job, and I don't think anyone wants this magic function running in kernelspace ;P)
<alyssa> And second because starting a big CPU-taxing magic compression when things are already under pressure doesn't seem terribly sustainable.
<alyssa> (Is it better than swapping? Probably, but this is sufficiently divorced from the original question that I'm not sure what to do with that information.)
<alyssa> There is the option of just opportunistically compressing things in the background (with u_queue), prioritizing based on sampling/rendering statistics.
<alyssa> I know some drivers do those sorts of tricks but I'm a bit uncomfortable with reasoning about that sort of code.
<alyssa> (Hiding the latency doesn't make up for the effect on general system performance, it's still competing for resources with the app, etc.)
<alyssa> That's not an explicit NAK but for 'just' halving memory it seems premature.
<alyssa> TL;DR If we can do the magic efficiently at texture upload time, that'd be neat, but if we can't for { technical, legal, performance } reasons, I don't think it makes sense to upstream with the current state of the driver.
<icecream95> Most applications won't use all CPU cores, though the magic function would take memory bandwith from the other cores
<alyssa> Even so - I saw much better memory behaviour from software rasterizers than we're doing with Panfrost.
<alyssa> And that'd just be linear textures, most likely.
<icecream95> The magic function is probably a bit faster than tiling, and will use about half the memory bandwith
wiizzard has joined #panfrost
<alyssa> So presumably we're doing something fundamentally stupid somewhere, throwing GPU-specific optimizations at the problem seems premature.
<icecream95> I think llvmpipe can sample from compressed textures directly, but most games use DXTn, which is (apart from RK3288W) Bifrost only
<robmur01> alyssa: FWIW the ID I've hacked in for my G71 is 0x60a0, although it's possible it might be a slightly different revision from Hikey's
<alyssa> [Finding out why Krita is buttery smooth with their software paths on RK3288, yet unusable with the GPU even on RK3399 is.. on my infinite todo list]
<icecream95> alyssa: Krita is in the Void Linux repos, so I can transfer that to my TODO list
youcai has quit [Read error: Connection reset by peer]
youcai has joined #panfrost
<alyssa> todo.txtL
<alyssa> 1. Figure out why Panfrost sucks so much
<alyssa> 2. Fix it
<alyssa> Unfortunately everyone has a different opinion about #1 :p
Ke has joined #panfrost
<icecream95> alyssa: Oh, it's because you don't use zram
<alyssa> (my perf-focused todo list: https://rosenzweig.io/todo.txt )
clementp[m] has quit [Ping timeout: 268 seconds]
<chrisf> is krita well-behaved with any other drivers?
<HdkR> alyssa: But panfrost doesn't suck =o
<robmur01> (ignore all the other crap in that patch)
<felipealmeida> robmur01: interesting
<alyssa> chrisf: I only started digital painting after switching to malis :p
<alyssa> But I assume it's well behaved at least on intel
<chrisf> intel's not a super twitchy tiler though ;)
exit70[m] has quit [Ping timeout: 260 seconds]
<alyssa> True.
<alyssa> robmur01: hey, want to go test a bunch of g71 patches? :p
<robmur01> alyssa: got a G52 on there at the moment, and I need to be good and go to bed soon, but if you manage to throw a branch out I can have a play over the weekend
<alyssa> robmur01: :p
clementp[m] has joined #panfrost
<robmur01> (reflashing the FPGA isn't *that* much of a pain TBH, but it's still more than I feel like starting at bedtime)
<robmur01> ...and still easier than trying to remember how to convince the bloody Hikey to work :D
rtp has quit [*.net *.split]
br_ has quit [*.net *.split]
taowa has quit [*.net *.split]
doublej41 has quit [*.net *.split]
rtp has joined #panfrost
<HdkR> Each time the kernel corrupts on my ARM board, I have to copy and paste a bunch of terminal commands that I figured out a month or two ago D:
doublej41 has joined #panfrost
archetech has joined #panfrost
<HdkR> What's more concerning is that the kernel flashed to fastboot manages to corrupt but eeeeh
exit70[m] has joined #panfrost
Elpaulo has quit [Ping timeout: 265 seconds]
<macc24> HdkR: *laughs in kernel not corrupting itself*
<macc24> alyssa: i have found that performance of kevin is noticeably lower than my minnie, not sure if it's resolution or gpu
<alyssa> macc24: right, kevin has nearly 4x the pixels to push
<alyssa> so even if the GPU is 2x faster, that'd still be 1/2 the speed :p
<icecream95> alyssa: Using a separate thread for compression would allow using uncompressed AFBC or linear for initial texture uploads, which could significantly cut loading times
<icecream95> (that's actual uncompressed AFBC, not AFBC compressed but usual size AFBC)
<alyssa> icecream95: Depending on code quality and benchmarks, I could certainly be persuaded into merging that :)