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?
<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
<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 :)