<_whitenotifier-8>
[scopehal-apps] azonenberg a5198ca - ngscopeclient can now load markers from scopesessions. See #512.
<_whitenotifier-8>
[scopehal-apps] azonenberg 120c03f - Fixed bug where glscopeclient created version-1 files but failed to write a version header, leading to them being loaded as version 0
<azonenberg>
@louis: please check if 120c03f fixes your scopesession issues
<azonenberg>
also, please test loading of scopesessions in ngscopeclient. i think it now supports almost the entire glscopeclient file format
<azonenberg>
you will not be able to *write* a scopesession from ngscopeclient yet
<azonenberg>
but you should be able to capture a dataset in gl and open it in ng
<azonenberg>
Latest (not yet pushed) code can write a metadata blob and version header to a scopesession but doesnt actually save anything useful. Continuing on that after work tomorrow
bvernoux has joined #scopehal
<bvernoux>
For information I have bout with PC Medium Tower (Ryzen 9 7950X3D, 96GB DDR5, RTX 4070) today stay tuned for more details on how it works with glscopeclient / ngscopeclient under Windows 11Pro & Linux(Ubuntu 22.04 LTS or more)
<bvernoux>
bout=> bought
<d1b2>
<edgetriggered> The only non-i915 configuration I can test with at the moment is GTX 1080 on QEMU/KVM with vfio-pci.
<d1b2>
<edgetriggered> Maybe it's still a useful data point?
<bvernoux>
It will be fun to test glscopeclient/ngscopeclient on Ryzen9 7950X3D iGPU too I'm pretty sure it will work correctly
<tnt>
Heh, my AMD GPU hard kernel panics with it so it'd be interesting to see if newer gen are better.
<azonenberg>
tnt: yeah i really want to figure out what's causing that
<tnt>
Well being a POLARIS series, it's now like 4-5y old ... so not sure how much interest there is.
<bvernoux>
tnt, yeah could be interesting to check if I have same issue with the iGPU of 7950X3D
<tnt>
If it works for the 5000/6000/7000 series.
<azonenberg>
well i dont know how ti works on modern gpus
<azonenberg>
and apparently people are still having issues on intel cards too
<tnt>
yeah, intel is easy to reproduce (for me at least) and just takes out the application, no wider system impact.
<tnt>
and given it's always when "zooming out" I'm sure it's just a "quantity of work" thing.
<bvernoux>
tnt, kernel panic is clearly very bad and it is a driver bug (robustness) issue as in worst case it shall have timed out exit and reload I saw that a lot on my Nvidia GeforceGT 650M ;)
<azonenberg>
tnt: yeah but i still want to work on not doing that
<azonenberg>
e.g. maybe i can add some function to decimate or otherwise cap the amount of points per pixel at low zooms
<azonenberg>
in order to avoid more than X amount of work in a given shader call
<tnt>
Yup. I'd need to dig in the gpu code to see exactly how those hangs are detected, see how long one has to run things.
<tnt>
But then again, it's a very old iGPU so it's also probably very slow.
<azonenberg>
yeah
<azonenberg>
my point being, this is a fundamental issue with the current renderer having no caps
<azonenberg>
you just will need bigger datasets to hit it on newer hardware
<azonenberg>
but there is always some threshold where it will happen
<bvernoux>
I remember of a similar issue on my Geforce GT650M with big data in glscopeclient when zooming out the NVIDIA driver crashed and reloaded
<bvernoux>
also in the demo in fact with some version of NVIDIA driver which was fixed using latest available drivers
<azonenberg>
bvernoux: also there have been some bugs in the past related to race conditions between various threads
<azonenberg>
which i think are now fixed but may have broken some drivers
<bvernoux>
azonenberg, yes probably too
bvernoux has quit [Read error: Connection reset by peer]
<d1b2>
<tnt> @azonenberg So a couple of observations :
<d1b2>
<tnt> In glscopeclient I add the demo scope and zoom out. When I get to the point where I see 2 us of data displayed, it refuses to zoom out more and it works just fine.
<d1b2>
<tnt> In ngscopeclient I do the same and when I zoom out to see 2 us of data displayed, it also works fine. But then, if I give it one more zoom out "click" on the mouse, it does zoom out a tiny bit more (not really showing more data because the demo scope only has 2 us of real data), but then crashes GPU.
<azonenberg>
interesting
<azonenberg>
glscopeclient has a cap where it wont let you zoom out more than the waveform length
<azonenberg>
ngscopeclient currently doesnt
<azonenberg>
but it shouldnt crash when that happens
<azonenberg>
the cap was just added to avoid you accidentally zooming too far and putting like an entire waveform on a single pixel and taking forever to render
<d1b2>
<tnt> It might be 100% coincidental but I thought that was worth noting.
<azonenberg>
Yes definitely interesting
<d1b2>
<tnt> Because that's probably why I "feel" that I get more crash with ngscopeclient, just zooming out to see all my data, then going 1 too far and boom.
<azonenberg>
Yeah
<azonenberg>
I mean it would be easy to add a stop
<azonenberg>
but the correct solution is to not crash :p
<azonenberg>
when you say "crash GPU" does it take down your entire desktop or just crash ngscopeclient?
<d1b2>
<tnt> Ah yeah sorry, this is my issue on intel, so just ngscopeclient.
<d1b2>
<tnt> Console shows terminate called after throwing an instance of 'vk::DeviceLostError' what(): vk::Device::waitForFences: ErrorDeviceLost Aborted
<d1b2>
<tnt> and dmesg [11855433.156363] i915 0000:00:02.0: Resetting chip for hang on rcs0
<azonenberg>
yeah that looks like its a timeout. interesting that it times out after only zooming out a tiny bit too far
<azonenberg>
makes me wonder if we have a shader bug
<azonenberg>
Have you tried running under the vulkan validation layer with a bunch of stuff enabled to see if it dumps any more useful info?
<d1b2>
<tnt> TBH I haven't looked how to run under the validation layer 🙂
<d1b2>
<tnt> Ah looks like I don't have it installed.
<azonenberg>
run "vkconfig"
<azonenberg>
select the validation layer and under 'validation layers' enable a bunch of stuff
<azonenberg>
i suggest disabling "break" under debug action, since this will trap to the debugger (or abort) whenever any message is printed
<azonenberg>
and you dont need debug printf enabled
<azonenberg>
but turn on as much as you can of the rest and then run ngscopeclient while vkconfig is open
<azonenberg>
and see if anything interesting shows up on stdout
<d1b2>
<tnt> Ok, will try that when I get the change. (I started updating mesa in the mean time to see if 23.0 improved things)
anuejn has quit [Remote host closed the connection]