<mlankhorst>
jfalempe: I'm looking through the code, is there an alternative for using per-file static variables?
<mlankhorst>
It should be doable to pass intel_fb for panic setup instead, and pass that along instead of bo
<mlankhorst>
Contrary to i915, xe has a very strict separation between xe_bo and display, so adding a member to intel_fb for panic stuff would make sense (or put it in xe's i915_vma)
<jfalempe>
mlankhorst: I find static variable was the least intrusive, and due to the callbacks, it's hard to get back the data you need.
<mlankhorst>
drm_panic is only ever being called once right?
<jfalempe>
Yes, but the get_scanout_buffer is called for each plane of each GPU.
<mlankhorst>
Yeah so on each gpu each primary plane gets set. Do other planes get disabled?
<jfalempe>
No, currently I just overwrite the primary plane.
jsa1 has quit [Ping timeout: 480 seconds]
normalpan has quit [Remote host closed the connection]
<sima>
mlankhorst, I'm talking about testcases in igt
<sima>
otherwise this stuff will break
<mlankhorst>
sima: Yeah should be easy to add, only thing we can do is verify no errors occurred from hw, no idea if the results would look sane. :)
<sima>
yeah can't validate the output, but at least make sure it doesn't blow up
<sima>
which is like the most important thing of panic code
<jfalempe>
Also the debug interface doesn't allow to see if you miss some "flush" commands, because you will continue to do page flips. (for example, I only noticed the psr2 issue with real panic).
<sima>
jfalempe, yeah there's limitations, but we can at least exercise the code and make sure we run all the paths in CI
<mlankhorst>
igt_display is a reasonably sane interface for testing
<sima>
and if we go with an igt ideally it'd have a super basic one that uses dumb buffers
<sima>
so that other drivers also have some automated testing for those that do have igt ci
<mlankhorst>
thought I would also be interested into testing what happens with partial primary plane, etc
<jfalempe>
yes, I only tested the basics, so panic in gnome desktop and in VT.
<mlankhorst>
Or like Xorg, too big a primary plane, with parts not visible
<jfalempe>
Also discrete GPU won't work yet, because I don't have a way to ioremap from the panic handler. But that can be added later, and iGPU are the vast majority in use.
<mlankhorst>
There's no guarantee on small bar that ioremap will even succeed
<mlankhorst>
should not be needed to ioremap
<sima>
amd has peek/poke registers, dead slow but guaranteed to work
<sima>
but I think we don't have those?
<kode54>
I had fun when I tried to read a panic qr code from someone's web posting of a video capture output
<kode54>
seems Apple's iOS QR code decoder chokes on that much data
<kode54>
it tries to inline it into the tooltip that pops on the screen to let you open/select it
xroumegue has quit [Ping timeout: 480 seconds]
<jfalempe>
kode54: Yes some QR code reader don't like bigger code. I use Binary eye on Android, and it works good (and is open-source https://github.com/markusfisch/BinaryEye)
<kode54>
I think Apple's coder can handle it
<kode54>
but they try to stuff the entire block of data into a tooltip control
<jfalempe>
hum, yes that's a lot of digits, because they can be encoded efficiently in QR code and are valid URL. Using Base64 would be much shorter, but also waste 25% of data.
<kode54>
I thought the QR code from the panic was the full text of the panic message?
<kode54>
or does it also include the dmesg loop?
xroumegue has joined #dri-devel
<kode54>
since I've never had a panic successfully bring up the qr code
<kode54>
every time I have a panic, it's a gpu related panic, and all my monitors cease outputting a picture when that happens :D
<psykose>
i had it once and thought i got hacked because of the screen clear animation :-)
<kode54>
though there was that period where I was testing bcachefs
<kode54>
can't test GPU code at the same time as bcachefs, as bcachefs is still in a state of flux in current kernels, so down/upgrading will lead to applying down/upgrade to your filesystem
kts has joined #dri-devel
<mlankhorst>
jfalempe: poking around, is it possible to include the private member for testing? Makes things easier. :)
lplc has quit [Ping timeout: 480 seconds]
<jfalempe>
mlankhorst: I'll try to do the change this afternoon, and send a v10.
<jfalempe>
kode54: the dmesg data are compressed, so you can put more of them. if you compile with QR_CODE set and QR_CODE_URL unset, you will have the dmesg in clear text in the QR code.
<mlankhorst>
remove the xe_ttm_vram, was from original code
<mlankhorst>
though need to put xe_ttm_resource_visible () check somewhere
<jfalempe>
mlankhorst: thanks nice to have also a solution for vram, the problem is I don't have hardware to test. The only discrete intel card I have is a dg2 prototype.
<mlankhorst>
I do
<mlankhorst>
DG2 mostly runs on xe btw if you use force probe, only HuC doesn't load
warpme has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
lsntvt_ has joined #dri-devel
lsntvt__ has quit [Read error: Connection reset by peer]
nerdopolis has joined #dri-devel
YuGiOhJCJ has quit []
blaztinn_ has joined #dri-devel
blaztinn has quit [Read error: Connection reset by peer]
vliaskov_ has quit [Ping timeout: 480 seconds]
<mlankhorst>
hmm I added some debug for testing, it's way too realistic
<mlankhorst>
should probably export a function to get the vram base pointer and create or look for a xe_bo_mappable()
<mlankhorst>
but it worked on my battlemage
asrivats_ has joined #dri-devel
asrivats_ has quit [Remote host closed the connection]
asrivats_ has joined #dri-devel
<sima>
mlankhorst, we really don't have peek/poke registers anywhere?
<mlankhorst>
I haven't looked for them
<mlankhorst>
But this works on everthing except small bar alread
vliaskov_ has joined #dri-devel
<sima>
yeah I guess assuming we have a big enough bar isn't that stupid any more
<mlankhorst>
though I didn't check what happens if we keep the FB in stolen memory on recent hw
<mlankhorst>
I would say it should still work, but that's always a special case
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
asrivats_ has quit [Remote host closed the connection]
asrivats_ has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.6.3]
<jfalempe>
mlankhorst: I've done the change to remove the static variables, moving them to struct intel_framebuffer. I won't have time clean and send that today, so I will finish it tomorrow.
<mlankhorst>
No worries, feel free to re-use the work I did for VRAM
rgallaispou has quit [Read error: Connection reset by peer]