alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - https://gitlab.freedesktop.org/panfrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
tgall_foo has joined #panfrost
vstehle has quit [Ping timeout: 268 seconds]
robink has joined #panfrost
<alyssa> Woah woah that was something about the hardware I didn't need to learn.
<urjaman> o.O?
<alyssa> urjaman: The polygon list BO has to be larger than reported in `polygon_list_size`
<urjaman> okay good, nothing exploded :P
<alyssa> :p
<alyssa> urjaman: How goes the Chromebooking and Panfrosting these days?
<urjaman> i guess i'm still kinda on a break ... will get back to it soon(TM) but have had both other things to attend to and also the kernel grind started feeling too much like work
<urjaman> i mean i am running the C201 obviously but havent touched the software in a while :P
<alyssa> Relatable :p
<alyssa> // Plist BO size 14E000
<alyssa> .polygon_list_size = 0x13fe00,
<alyssa> // body offset 20992
<alyssa> 0x14E000 != 0x13FE00
<urjaman> oh i was at Assembly 2019 (computer festival, demoparty, lan party, whatever) and my C201 photobombed in an "official" (by assembly photo people) picture of my 3D printer
<alyssa> :)
<alyssa> Okay, 30 bytes per tile... seems arbitray
<alyssa> ---And not even right either hrmph
<urjaman> very arbi tray indeed
<alyssa> Never such a thing in hw..
<alyssa> Also it's possible the blob overallocates somewhat
<urjaman> that is a random amount to overallocate by ...
<alyssa> urjaman: I mean I might not have anything to do with the tile count
davidlt has quit [Ping timeout: 244 seconds]
_whitelogger has joined #panfrost
davidlt has joined #panfrost
_whitelogger has joined #panfrost
_whitelogger has joined #panfrost
megi has quit [Ping timeout: 246 seconds]
davidlt_ has joined #panfrost
davidlt has quit [Ping timeout: 272 seconds]
bshah has joined #panfrost
vstehle has joined #panfrost
davidlt__ has joined #panfrost
davidlt_ has quit [Ping timeout: 244 seconds]
davidlt__ has quit [Read error: Connection reset by peer]
davidlt_ has joined #panfrost
davidlt_ has quit [Remote host closed the connection]
davidlt__ has joined #panfrost
davidlt__ has quit [Read error: Connection reset by peer]
davidlt has joined #panfrost
krh has quit [Ping timeout: 248 seconds]
pH5 has quit [Quit: bye]
davidlt has quit [Ping timeout: 245 seconds]
anarsoul has quit [Remote host closed the connection]
anarsoul has joined #panfrost
pH5 has joined #panfrost
jernej has quit [Ping timeout: 264 seconds]
davidlt has joined #panfrost
davidlt has quit [Remote host closed the connection]
davidlt has joined #panfrost
<tomeu> Prf_Jakob: is there a profiling mode that can tell me which are the tests that take most of the time?
afaerber has quit [Quit: Leaving]
davidlt_ has joined #panfrost
davidlt has quit [Read error: Connection reset by peer]
megi has joined #panfrost
davidlt_ has quit [Ping timeout: 246 seconds]
davidlt has joined #panfrost
<tomeu> Prf_Jakob: also, how can I print regressions and improvements but not already-known failures?
<daniels> alyssa, urjaman: i don't think it is related to the tile count - 0x13fe00 is only aligned to 512 bytes, whereas 0x14e000 is aligned up to 4096 bytes
<daniels> which makes sense - no sense allocating BOs which aren't aligned to page size
<urjaman> yes, but it's not the next 4k
<urjaman> (that'd be at 0x140000, so there's atleast 56k extra space)
<daniels> good point, and that would also be the next 64k boundary
<urjaman> but i suppose alyssa will figure it out, atleast if there's more examples ... tho i have one maybe silly thought
<urjaman> does the blob perform it's own memory allocation for these things? maybe it just padded upwards to the next thing instead of leaving a tiny hole
raster has joined #panfrost
raster has quit [Remote host closed the connection]
raster has joined #panfrost
davidlt has quit [Read error: Connection reset by peer]
davidlt has joined #panfrost
davidlt has quit [Read error: Connection reset by peer]
<shadeslayer> could someone shed some light on what CANARY means in a ralloc context?
davidlt_ has joined #panfrost
<cwabbott> shadeslayer: if you hit that assert, it probably means you passed a mem_ctx to a ralloc function that isn't actually a ralloc context or NULL
<cwabbott> or there's some kind of memory corruption
<cwabbott> it's a constant stored in every ralloc context and checked when you pass in a context
<shadeslayer> aha I see
<shadeslayer> thank you! :)
tgall_foo has quit [Read error: Connection reset by peer]
<daniels> right - generally with allocators, any kind of failure like that means that you're using memory after free, or have double-freed, or overflowed an allocation
<shadeslayer> what I'm confused by is the assert(info->canary == CANARY)
<daniels> shadeslayer: is this still the Plasma thing? if so, it's probably quicker to run it under valgrind than to spend two days trying to figure out what's going out without valgrind :P
<shadeslayer> so it will assert when the known value is found?
<daniels> err, other way around
<daniels> it will assert when the 'canary' member is not the static value CANARY
<shadeslayer> uhhh ...
<shadeslayer> assert(info->canary == CANARY);
<daniels> yeah
<daniels> if info->canary == CANARY, then it will continue
<daniels> if info->canary != CANARY, it will abort
<shadeslayer> oh right, ofcourse
<shadeslayer> right, what I see in gdb :
<shadeslayer> (gdb) print info->canary
<shadeslayer> $1 = 5902598
<shadeslayer> which is int for the hex value
<daniels> usually you use them to implement a pretty weak form of memory-overrun detection - for instance, struct { char my_buffer[128]; uint32_t canary = 0xdeadbeef; }
<daniels> doing that, if you write past 128 bytes of my_buffer, you'll overwrite the 'canary
<shadeslayer> so the value seems correct, but it still asserts?
<daniels> ' member with whatever you were going to write
<daniels> is that what you see at the assert point?
<shadeslayer> daniels: yeah
<daniels> ... when the assert has failed?
<shadeslayer> yes
<shadeslayer> which is why I'm so confused :P
<daniels> shadeslayer: is your access to the ralloc ctx protected by a mutex?
<shadeslayer> daniels: not that I can see
<daniels> shadeslayer: that would explain the value changing from underneath you then!