ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
camus has joined #panfrost
camus has quit []
camus has joined #panfrost
davidlt has joined #panfrost
pendingchaos_ has joined #panfrost
pendingchaos has quit [Ping timeout: 480 seconds]
davidlt has quit [Ping timeout: 480 seconds]
Daanct12 has joined #panfrost
davidlt has joined #panfrost
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #panfrost
MajorBiscuit has joined #panfrost
MajorBiscuit has quit [Ping timeout: 480 seconds]
alarumbe has quit [Remote host closed the connection]
nlhowell has joined #panfrost
MajorBiscuit has joined #panfrost
rasterman has joined #panfrost
Daaanct12 has joined #panfrost
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #panfrost
davidlt has quit [Ping timeout: 480 seconds]
Daaanct12 has quit [Ping timeout: 480 seconds]
davidlt has joined #panfrost
rkanwal has joined #panfrost
rcf has quit [Quit: WeeChat 3.4.1]
Daaanct12 has joined #panfrost
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #panfrost
Daaanct12 has quit [Ping timeout: 480 seconds]
alarumbe has joined #panfrost
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #panfrost
Daaanct12 has joined #panfrost
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #panfrost
Daaanct12 has quit [Ping timeout: 480 seconds]
rcf has joined #panfrost
rcf has quit []
<hanetzer>
on another note. do mali gpus support opencl/compute? is there kernel/mesa support for that yet?
<HdkR>
The hardware supports it yes. Proprietary stack gives you full CL profile as well
<HdkR>
Panfrost supports GL/ES compute. OpenCL less likely to be usable
<hanetzer>
neat. just idle curiosity tbh
rcf has joined #panfrost
Daanct12 has quit [Remote host closed the connection]
nlhowell has quit [Ping timeout: 480 seconds]
<CounterPillow>
not sure how much hardware-specific plumbing clover needs but at least clinfo on my G-52 reports opencl 1.1
camus has quit []
nlhowell has joined #panfrost
pendingchaos_ is now known as pendingchaos
<macc24>
hanetzer: i remember icecream95 doing something cl related
<robclark>
there is clover which can (with a bit of driver support, which IIRC panfrost has) give you cl.. but passing conformance tests is a whole other thing
digetx has quit [Remote host closed the connection]
nlhowell has quit [Ping timeout: 480 seconds]
digetx has joined #panfrost
MajorBiscuit has quit [Ping timeout: 480 seconds]
<CounterPillow>
admittedly, opencl < 1.2 is also a little too barren for many things
* hanetzer
was thinking about wiring in some tracepoints in panfrost like lima has.
<alyssa>
greenjustin: Yeah, ChenYu (and Angelo) have been doing great work :-D
rcf has quit [Ping timeout: 480 seconds]
rcf has joined #panfrost
rcf has quit [Quit: WeeChat 3.4.1]
rcf has joined #panfrost
icecream95 has joined #panfrost
<icecream95>
If people actually cared about having OpenCL, I might spend more time on it.
<icecream95>
But instead they complain that it doesn't work, and then never get back after I give them help with debugging that
<alyssa>
that sounds about right
<icecream95>
That reminds me to get back to implementing driver-internal OpenCL kernels
<icecream95>
wondering if it would be better to switch out the options to clang so that it compiles ANSI C rather than OpenCL C
<alyssa>
I'm not sure. I was thinking about that recently.
<icecream95>
Still doesn't give you features not in SPIR-V, unfortunately
<icecream95>
(Like pointers to functions)
<icecream95>
Though always_inline could at least get rid of uses to that
<alyssa>
My first instinct is to run away screaming and hide, because running general pupose C on a GPU is terrifying :-)
<icecream95>
Could CSF be used to implement syscalls?
<alyssa>
I imagine the `ANSI C -> SPIR-V -> NIR` path has received little-to-no testing.
<alyssa>
(Whereas the `OpenCL C -> SPIR-V -> NIR` path is conformant for a few different backends now.)
<icecream95>
Waaait a second, Rust compiles to LLVM bitcode, doesn't it?
<icecream95>
In other news, sqlite pandecode is coming along, but I don't know whether to rip out the existing text dump or not
<icecream95>
I suspect that writing SQL to recreate it might not exactly be trivial
<icecream95>
I guess that it doesn't *have* to be done in a single SQL statement
<jekstrand>
Why are you rewriting pandecode to use SQL?
<jekstrand>
Mesa does not need to grow an SQL dependency.
<robclark>
re: syscalls.. io_uring ;-)
rasterman has quit [Quit: Gettin' stinky!]
davidlt has quit [Ping timeout: 480 seconds]
guillaume_g has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: leaving]
rkanwal1 has joined #panfrost
rkanwal has quit [Read error: Connection reset by peer]
anholt has quit [Ping timeout: 480 seconds]
anholt has joined #panfrost
<icecream95>
jekstrand: The existing text-based format is not great, so having a more structured dump format would make debugging a lot easier
<jekstrand>
a) I'm skeptical. Having to do SQL queries sounds like a whole lot more work than grep.
<jekstrand>
b) I really don't want to see mesa grow an SQL dep. If it's super optional and VERY justified, then maybe. But, as dependencies go, SQLite is a pretty big ask.
<icecream95>
In terms of .so size, sqlite is only twice the size of zstd
<icecream95>
Though I guess applications that link to sqlite are less common than zstd
<jekstrand>
And zstd serves a very clear and very useful purpose.
<jekstrand>
Specifically, it's required for shader caching
<jekstrand>
Or used for, anyway.
<icecream95>
I suppose it's possible to emit dumps in a format that can optionally be later converted to SQL, but using sqlite directly would produce much smaller files
<icecream95>
Maybe zstd compression could help with that? :)
<jekstrand>
Using SQLite as part of a tool which is very very optional might be ok. Building it into the driver... Yeah, no.
bluebugs has quit [Quit: Leaving]
<icecream95>
hanetzer: The DRM scheduler already has a few tracepoints, how much would separate ones for panfrost add?
rkanwal1 has quit [Ping timeout: 480 seconds]
<robclark>
icecream95: it sounds a whole lot like you are trying to reinvent perfetto
<robclark>
(which admittedly is not a small dependency, but is at least optional)
<icecream95>
robclark: Is perfetto suited for looking through the contents of GPU descriptors? I thought it was mostly for tracing
<robclark>
well, it is structured, and the web ui has some sort of sql query mechanism that I've not looked at before but know it exists
<robclark>
maybe you could use it for logging too, idk
<robclark>
for msm/freedreno we just dump bo addr+contents plus addr of toplevel cmdstream into a binary file with a fairly simple structure
<robclark>
and then have offline "cffdump" tool that figures out how to decode it and follow gpu pointers from one thing to the next
<icecream95>
I implemented that using ELF...
<icecream95>
But the files get pretty large, so dumping everything per frame isn't practical for long-running applications
<robclark>
yeah, it could have been elf or something else.. the toplevel format is stupid simple.. and really has been good enough
<robclark>
gzip works well
<robclark>
typically
<icecream95>
gzip is too slow
<icecream95>
Maybe I was trying to compress WC memory directly, though
<robclark>
we use libarchive (?) IIRC to decompress in the parsing tool
<robclark>
I mean, I'm not sure I'd try to capture 1000'
<robclark>
I mean, I'm not sure I'd try to capture 1000's of frames of some game
<robclark>
more because the amount of data to go thru than overhead capturing
<icecream95>
I guess doing `frame_count = (frame_count + 1) % 20` to limit the number of captures could help
<robclark>
usually we us cmdstream capture for one of two things (1) simplified test case or deqp test, or replay of frame or few frames of data, and (2) capture contents of submit which hung the GPU (kernel devcore stuff)
<robclark>
we also have debugfs (/sys/kernel/debug/dri/n/rd) that was can cat into a file to capture cmdstream if we want just a second or two worth of cmdstream from somewhere in middle of game
<icecream95>
Capturing from the kernel does mean that data which is only in userspace (BO labels, shader source code) cannot be included
<robclark>
having uabi to pass debug label to kernel is a thing I'd recommend, regardless.. we use it in (for ex) $debugfs/dri/n/gem
<robclark>
at least for us, shaders are just another bo that we set MSM_BO_DUMP flag on so they are one of the N (many) bo's we capture with cmdstream snapshot.. these are all things you want in drm/panfrost to make devcore dumps useful
<icecream95>
Do you dump texture contents? That would be useful for replaying the dump, but wouldn't be required for debugging a hang unless it is compression-related
<robclark>
we specifically do *not* mark texture bo's w/ MSM_BO_DUMP flag for privacy reasons
<icecream95>
Oh, do the dumps get automatically uploaded or something?
<robclark>
right.. well we do have debugfs to make it dump *everything*, but what gets automatically uploaded doesn't have that
<icecream95>
In this Collabora tweet: "We are working on G610, both GL and Vulkan"
<icecream95>
Can I assume that it should be s/are/will be/ ?
<icecream95>
Because I thought that it was only me looking at CSF userspace so far
<icecream95>
Or maybe it just means that kernel work is happening, and GL and Vulkan will eventually be supported?