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
<cphealy>
I'm attempting to build panwrap with recent Mesa and it's failing with the following errors: https://pastebin.com/PNEQ0Y2P Can anyone here confirm that they are able to build panwrap themselves? Alternatively, is there an obvious issue with how I'm building that could lead to this build failure?
<icecream95>
cphealy: I remember fixing that a while ago.. I'll rebase the fix now
<cphealy>
Assuming this combination works, is there any reason these should not land in the respective upstream repos?
* icecream95
goes off to create merge requests
<cphealy>
;-)
wolfshappen has joined #panfrost
wolfshappen_ has joined #panfrost
wolfshappen__ has joined #panfrost
rasterman has quit [Quit: Gettin' stinky!]
wolfshappen has quit [Ping timeout: 480 seconds]
wolfshappen_ has quit [Ping timeout: 480 seconds]
jenneron[m] has quit [Server closed connection]
jenneron[m] has joined #panfrost
wolfshappen__ has quit [Ping timeout: 480 seconds]
camus has joined #panfrost
vstehle has quit [Ping timeout: 480 seconds]
wolfshappen has joined #panfrost
toggleton[m] has quit [Server closed connection]
toggleton[m] has joined #panfrost
bbrezillon has quit [Read error: Connection reset by peer]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #panfrost
bbrezillon has joined #panfrost
vstehle has joined #panfrost
stebler[m] has quit [Server closed connection]
stebler[m] has joined #panfrost
CalebFontenotHaileysCuteNerdyB has quit [Server closed connection]
CalebFontenotHaileysCuteNerdyB has joined #panfrost
soreau has quit [Read error: Connection reset by peer]
soreau has joined #panfrost
`join_subline has joined #panfrost
<icecream95>
alyssa: You can decide what to do about the commit linked above, whether to apply it or just delete print_varying_parameters
pjakobsson_ has joined #panfrost
pjakobsson has quit [Ping timeout: 480 seconds]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #panfrost
rasterman has joined #panfrost
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #panfrost
MajorBiscuit has joined #panfrost
Major_Biscuit has joined #panfrost
MajorBiscuit has quit [Ping timeout: 480 seconds]
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #panfrost
<alyssa>
icecream95: without a very good explanation of why we need it, [Clone] is a NAK for upstream..
<alyssa>
as for the varying thing, that'll require paging back in the midgard ISA from long term storage :)
<alyssa>
icecream95: I guess delete print_varying_parameters.
<alyssa>
In general, LD_VAR takes a register describing the mode, not an immediate.
<alyssa>
So we have the same problem as disassembling TEXC on Bifrost.
tjcorley has quit [Ping timeout: 480 seconds]
tjcorley has joined #panfrost
JulianGro has quit [Remote host closed the connection]
nlhowell has joined #panfrost
JulianGro has joined #panfrost
nlhowell is now known as Guest1464
nlhowell has joined #panfrost
Guest1464 has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit []
robmur01_ has joined #panfrost
robmur01 has quit [Ping timeout: 480 seconds]
macc24 has joined #panfrost
<icecream95>
alyssa: (about the NAK) I'm not surprised..
nlhowell has quit [Ping timeout: 480 seconds]
nlhowell has joined #panfrost
<alyssa>
I guess I don't understand the background of it
<icecream95>
The original purpose was to make it easier to debug applications with long startup times
* alyssa
is listening
<icecream95>
..So you can fork before doing whatever is broken, and then attach to the child in gdb to have another go at it
<icecream95>
But it doesn't have any winsys integration, so it's only useful for surfaceless (or I guess GBM) ApiTrace
nlhowell has quit [Ping timeout: 480 seconds]
<alyssa>
I think renderdoc has a feature to splice frames out of a trace unlike apitrace.
<icecream95>
That isn't helpful for D3D9 or non-core OpenGL, though
<alyssa>
I've never used renderdoc, but I think that helps with the long start up time, especially if it's only useful for trace replays.
<alyssa>
right, okay
<icecream95>
I have used renderdoc a couple of times, and being able to edit shaders and quickly see the new output is helpful
<icecream95>
But maybe it would have been useful to remember about renderdoc for the last couple of GLES apps I debugged...
<alyssa>
Sure
<icecream95>
On the topic of things that will be NAK upstream, I suppose that users won't want to use Panfrost inside an OpenBSD VM at 1 fps?
<alyssa>
I don't know any users who want that upstream, no 😅
<icecream95>
Time to get started on optimisation work then
<macc24>
icecream95 is back? O.o
<alyssa>
for what it's worth:
<alyssa>
[RA perf] nodearray looks good, undecided about the NEON
<alyssa>
[!13203] I think I landed this?
<alyssa>
[Nine] clip control looks good, would prefer a DBG or fprintf(stderr) on the stubbed out clears but in general if you want to spearhead nine/panfrost and it doesn't hurt support for Khronos APIs, I'm happy to merge
<alyssa>
[CRC] overall looks good, I suspect we need to introduce a new modifier (at the kernel level) for sharing in-band CRC across processes and disable CRC for resources without the modifier, but that's a small code change
<alyssa>
[Perf] sure
<alyssa>
[!12928] happy to merge, still unsure if using a sparse u_dynarray is better/worse than a dense bit vector, but either one is much better than a nondeterministic set
<alyssa>
[drm-shim] I don't maintain drm-shim and have no opinions on the patches
<alyssa>
[Swrast, Blob, Clone, Replay] all have the same "I need a lot more background to justify a change like this upstream, but is it a problem to carry downstream? do you need my approval?"
<alyssa>
It seems these are all debugging features. TTBOMK no other driver has analogues of these. I'm not opposed to trying to something new, but in general I assume jekstrand, Kayden, and anholt know better than I do on how to write a driver.
<alyssa>
[Bug] all good
<alyssa>
[Workaround] If this fixes a real issue in an app (and we can't fix the upstream app), it might be time for drirc. If this is a debugging aid (including to figure out if we should add a drirc rule), I'm fine to upstream. Change looks localized anyway
<alyssa>
[Firefox] all good in principle, I am terrified of the midgard spill code and have not reviewed in practice.
<alyssa>
[Push] I agree that pushing ranges is better. On the other hand, reordering is a real win. Also, when cwabbott's nir_opt_preamble work lands, the way we push uniforms will change with it (so we can push UBOs on the GPU, which avoids the expensive read from WC memory). So I'm not sure where to go with these patches.
<alyssa>
(I'm also unsure if this is still a hotspot with dirty tracking?)
<icecream95>
I think dirty tracking didn't reduce the number of ubo uploads as much as I expected..
<alyssa>
[OpenCL] I like OpenCL... Largely similar to Nine situation, if adding support does not hurt GLES/VK, and you want to spearhead it, I'm happy to merge.
<alyssa>
[Magic] In all honesty I don't understand these patches enough to have an informed opinion. I don't know how AFBC works internally, the CL kernel infrastrure hurts my head... I don't know if those patches are upstreamable because I can't understand them.
<alyssa>
[BO dump] Probably fine
<alyssa>
[Shader clock] Never finished up the kernel side of these did I...
<alyssa>
[Timestamp] See shader clock
<alyssa>
[Lima] Not my jurisdication :-D
<alyssa>
[Enhancement] Should be fine
<alyssa>
[TexBO] Undecided. Need more data. Planning to talk to jekstrand about it. Buffer textures on Mali are weird.
<alyssa>
[Tiler] Sure I guess? You know more than I do.
<alyssa>
[Minor] Good
<icecream95>
"Magic" has quite significant memory savings, about 400 MB for SuperTuxKart
<alyssa>
[CRCDump] Need a lot more context, this might be in the blob/clone/replay bin.
<icecream95>
Yeah, I don't think CRCDump is useful except for debugging
<alyssa>
I think that's everything
<icecream95>
"[Tiler] Sure I guess". What about the half-finished work for doing tiling on the CPU?
<alyssa>
Disclaimer: "sounds good" is not an r-b, code review might uncover issues, but should make it clear which MRs are likely to land, which are likely NAK, and which are liable to sit open for months before I can will myself to remember how the midgard RA works
<alyssa>
was that for debug or for fast mipmap or something else?
<icecream95>
The fast-mip-mdg branch exists, but I was also trying to write a complete GPU emulator
<alyssa>
regardless of the code, the r/e is impressive and if you write docs (or even headers) I can probably merge that ;-)
<alyssa>
complete GPU emulator is cool but out of scope for upstream Mesa
<alyssa>
and maybe out of scope for Mesa at all?
<icecream95>
But if LLVMPipe and Softpipe are allowed in Mesa.. :)
<alyssa>
Heh, well
<alyssa>
if you want a gitlab.freedesktop.org/panfrost/emulator or something, happy to accommodate that
<alyssa>
I don't know what your goals were, but if I were starting a Mali emulator, I'd swipe src/panfrost/lib/genxml and go.
<alyssa>
(and the ISA files and disassemblers)
<icecream95>
That reminds me of the Bifrost assembler I wrote..
<icecream95>
I guess that the Valhall processor definition in Ghidra can already execute some code sequences, but it isn't really suitable for an emulator
<alyssa>
speaking of, you should've gotten an email from gitlab.fd.o just now
* alyssa
whistles
<icecream95>
alyssa: Oh dear, do I have to write v10 support in Rust?
<alyssa>
whatever you are accusing me of, I have plausible deniability!
<icecream95>
Ah.. I thought of doing something like that, but would probably have tried to just use QEMU. "use unicorn_engine::{RegisterARM, Unicorn};"
<icecream95>
alyssa: I assume this is the most we are allowed to do with the firmware.. no decompiling?
<alyssa>
/* no comment */
<icecream95>
I'm surprised that you managed to find a 32-bit DDK for v10, I would have expected RegisterARM64
<alyssa>
The CSF microcontroller is a 32-bit arm chip
<alyssa>
Has nothing to do with the CPU it's paired with
<alyssa>
(or the fact that Mali GPUs are 40-bit....)
<icecream95>
40-bit? They seem 48-bit to me, at least v6 and v10
<alyssa>
mh, might be
<alyssa>
either way it's >32 and <64
<icecream95>
Right.. I have some very difficult homework that I need to be doing now, "Introduction to the Linux command line"
<icecream95>
"And it says 'Welcome to NetBSD!' And that's it, so welcome to the black and white world of Linux command line."
<alyssa>
You are reminding me of my "intro to OpenGL" homework I have due Wednesday...
<icecream95>
alyssa: It may come as a surprise to you, but /home/alyssa does not exist on my machine
<icecream95>
(This is for the patch.crates-io section of Cargo.toml)
* alyssa
mumbles
* alyssa
makes a note to figure out what she patched
JulianGro has quit [Read error: No route to host]
<icecream95>
alyssa: ..You missed [Annotate] when going over all of my patches. That currently prints blend shader and sysval names in pandecode.dump, and might eventually do more. But if it is upstreamed, should it be compiled in for NDEBUG builds?
<alyssa>
[Annotate] is good in principle
<alyssa>
though push uniform stuff I would need to think about
<icecream95>
Because I'm using kbase for v10 RE, I was wondering how I could get the kernel to call into a userspace library.. and then I remembered that the blob uses SAME_VA for everything so I can run it directly on CPU user address space
<icecream95>
alyssa: I don't think it makes sense to write a whole new Gallium driver, so pan_cmdstream_csf.rs?
nlhowell has joined #panfrost
tlwoerner has quit [Ping timeout: 480 seconds]
tlwoerner has joined #panfrost
<icecream95>
alyssa: Seems to work.. "DBG: Halting"
rasterman has quit [Remote host closed the connection]
Lyude has quit [Quit: WeeChat 3.4]
Lyude has joined #panfrost
DPA has quit [Server closed connection]
rasterman has joined #panfrost
DPA has joined #panfrost
<alyssa>
heh
<alyssa>
pan_cmdstream_csf.rs?
<alyssa>
I expect relatively few changes to Mesa between v9 and v10.
<icecream95>
Looking at pan_cmdstream.c, many things will be similar to v9, such as sysval uploads, textures/samplers, probably even varyings, so maybe just panfrost_direct_draw and launch_grid will need some rethinking
<icecream95>
So.. maybe we could at least use Rust for the firmware rewrite? It's not winsys, jekstrand can do that.