<alyssa>
Maybe even add a `const char *label` arg to panfrost_add_bo to force everyone to label right
<alyssa>
And then concatenate/deduplicate labels as they're added (be _very_ careful with the choice of data structure/algorihtms for this for perf reasons)
<shadeslayer>
that char *label approach is what I've been thinking about
<bbrezillon>
shadeslayer: can you ask anholt why he didn't use strings in the first place?
<alyssa>
Er actually I guess have enums for fixed labels as powers-of-two so you have a uint32_t label and then stringify it on print time, much cheaper and makes concatenation/dedplucation as easiy as bitwise OR
<bbrezillon>
there might be a good reason
<shadeslayer>
alyssa: yeah that's kind of where I'm a tiny bit stuck, and how we want to label will determine what we use
<bbrezillon>
alyssa: yes, I think that's better
<bbrezillon>
shadeslayer: I don't think the kernel needs to know what the labelid means
<shadeslayer>
bbrezillon: the way that vc4 does it is that it string'ify's the labelid and prints the debug info to a /sys interface
<bbrezillon>
shadeslayer: we probably want to move that to debugfs
<bbrezillon>
and how does that work for userspace labels
<bbrezillon>
?
<shadeslayer>
bbrezillon: it's really iffy for userspace labels
<shadeslayer>
and they just assume that user labelling is infrequent
<shadeslayer>
my plan was to just have the mesa driver pass a string via the args at BO creation time, and then we use that string as a key in a hash table
<shadeslayer>
but then ... string hashing penalties and what not
stikonas has joined #panfrost
<alyssa>
shadeslayer: The labeling I'm talking about can be all within-mesa
<alyssa>
which is good since anything we can keep out of the kernel, we want to
<alyssa>
10 lines of Mesa is better than 2 lines of kernel code, imo
<alyssa>
(Don't take that to an extreme, but conceptually)
davidlt has quit [Ping timeout: 245 seconds]
<bbrezillon>
alyssa: it really depends what you're interested in, if it's about dumping all BOs allocated by the driver, you can't really do that in mesa
<alyssa>
Fair
<bbrezillon>
but I agree on that we shouldn't add new ioctls if there's no need for the feature
<alyssa>
My intended use case is "we got a fault with this address. what caused it?" and that's an in-mesa problem
<alyssa>
currently solved by littering printfs
<bbrezillon>
because once it's there it has to stay forever