<d1b2>
<246tnt> Just tried ngscopehal on my new laptop. Although the "present" bug (causing weird refreshes) isn't present on this as opposed to my old Haswell one, the GPU hang is still there 😢
<d1b2>
<246tnt> Also, I have a weird bug with tooltips and my window manager.
<d1b2>
<246tnt> When a tooltip would "go out" of the window area, it creates a new X window but that window isn't marked as being a popup style thing and so the tiling manager tries to tile it but then that in turn cause the current scopehal window to move (because of retiling), which causes the tooltip to disapear and then the ngscope window comes back to the original place, causing the tooltip to show ... and it oscillates.
<d1b2>
<azonenberg> That's an imgui issue, not a scopehal issue
<d1b2>
<azonenberg> In general, windows within the main app window are a single X window
<d1b2>
<azonenberg> but as soon as they stick out they become a new top level window
<d1b2>
<azonenberg> So if they're not given the right flags, the bug is on their side and should be filed against imgui upstream
<d1b2>
<azonenberg> wrt gpu hang, hmmmmm. definitely need to look into things, i thought we had fixed all of them
<d1b2>
<azonenberg> is it a true hang or is it just something takes too long and it times out before rendering finishes?
<d1b2>
<azonenberg> Adding some early outs for reduced intensity grading on low end GPUs is definitely on the todo list
<d1b2>
<246tnt> [851102.375286] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:85dcfdfb, in ngscopeclient [9436] [851102.375291] i915 0000:00:02.0: [drm] ngscopeclient[9436] context reset due to GPU hang
<d1b2>
<246tnt> But it does "hang" for a couple of seconds.
<d1b2>
<246tnt> And I'm not 100% convinced it's "just" something taking too long because the zoom level before the one that crashes is perfectly fluid.
<d1b2>
<246tnt> I would have expected some FPS degradation before getting a few sec of complete hang.
<d1b2>
<azonenberg> Yes that's what i would expect too
<d1b2>
<azonenberg> Very interesting and the more information you can collect the better
<d1b2>
<azonenberg> It has not happened on any system i have access to
<d1b2>
<azonenberg> and right now i think me and lain are the only ones who have ever worked on the renderer code so we know it best
<d1b2>
<david.rysk> @246tnt what specific GPU?
<d1b2>
<246tnt> 12th Gen intel iGPU.
<d1b2>
<david.rysk> @azonenberg have you tested with your laptop with the nvidia dGPU disabled?
<d1b2>
<azonenberg> yes, my recollection was that it was a lot slower but worked just fine
<d1b2>
<246tnt> CPU is i7-1260P. GPU identifies as 00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-P Integrated Graphics Controller [8086:46a6] (rev 0c)
<d1b2>
<azonenberg> i actually did that a lot when demoing to people since i was usually on power and using less power
<d1b2>
<david.rysk> the other bit of information would be what versions of mesa are installed on both systems. I think we should have a template for such reports including: CPU make/model GPU make/model OS type/kernel/architecture/output of uname -a Mesa version GPU driver version
<d1b2>
<azonenberg> We should make a "bug report helper" tool accessible via some menu
<d1b2>
<azonenberg> that spits out some template info you can paste into a ticket