<azonenberg>
but there will be one more dependency soon :p
<azonenberg>
we need a library for loading image files to get icons etc off disk
<azonenberg>
thoughts on freeimage? i've used it in the past, it's dual licensed GPL or a custom LGPL-esque license allowing arbitrary linking as long as you use an unmodified version or provide source to any changes you may have made to the library
<_whitenotifier-7>
[scopehal] azonenberg 35203eb - Updated vkFFT to support pipeline caching. Pass pipeline cache pointer as needed.
<bvernoux>
I'm trying to build latest scpopehal-apps on MinGW64
<azonenberg>
also hmmmm
<azonenberg>
i'm seeing crashes again on my lab machine
<bvernoux>
[ 3%] Building CXX object lib/scopehal/CMakeFiles/scopehal.dir/scopehal.cpp.obj
<bvernoux>
In file included from C:/msys64/mingw64/include/ws2tcpip.h:17,
<bvernoux>
from C:/msys64/home/bvern/scopehal-apps/lib/xptools/Socket.h:42,
<bvernoux>
from C:\msys64\home\bvern\scopehal-apps\lib\scopehal\SCPISocketTransport.h:39,
<bvernoux>
from C:\msys64\home\bvern\scopehal-apps\lib\scopehal\scopehal.h:83,
<bvernoux>
from C:\msys64\home\bvern\scopehal-apps\lib\scopehal\scopehal.cpp:35:
<bvernoux>
C:/msys64/mingw64/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h [-Wcpp]
<bvernoux>
15 | #warning Please include winsock2.h before windows.h
<bvernoux>
| ^~~~~~~
<bvernoux>
In file included from C:/msys64/mingw64/include/minwindef.h:163,
<bvernoux>
from C:/msys64/mingw64/include/windef.h:9,
<bvernoux>
from C:/msys64/mingw64/include/windows.h:69,
<bvernoux>
from C:\msys64\home\bvern\scopehal-apps\lib\scopehal\AlignedAllocator.h:40,
<bvernoux>
from C:\msys64\home\bvern\scopehal-apps\lib\scopehal\AcceleratorBuffer.h:38,
<bvernoux>
from C:\msys64\home\bvern\scopehal-apps\lib\scopehal\scopehal.h:79:
<bvernoux>
C:\msys64\home\bvern\scopehal-apps\lib\scopehal\AcceleratorBuffer.h: In member function 'void AcceleratorBuffer<T>::CopyToGpuNonblocking(vk::raii::CommandBuffer&)':
<bvernoux>
C:\msys64\home\bvern\scopehal-apps\lib\scopehal\AcceleratorBuffer.h:884:29: error: '_mm_mfence' is not a member of 'vk'; did you mean '_mm_mfence'?
<bvernoux>
In file included from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/xmmintrin.h:1316,
<bvernoux>
from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/immintrin.h:31,
<bvernoux>
from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/x86intrin.h:32,
<bvernoux>
from C:/msys64/mingw64/include/winnt.h:1658:
<bvernoux>
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/emmintrin.h:1532:1: note: '_mm_mfence' declared here
<bvernoux>
1532 | _mm_mfence (void)
<bvernoux>
| ^~~~~~~~~~
<bvernoux>
C:\msys64\home\bvern\scopehal-apps\lib\scopehal\ComputePipeline.h: In member function 'void ComputePipeline::AddComputeMemoryBarrier(vk::raii::CommandBuffer&)':
<bvernoux>
C:\msys64\home\bvern\scopehal-apps\lib\scopehal\ComputePipeline.h:90:29: error: '_mm_mfence' is not a member of 'vk'; did you mean '_mm_mfence'?
<azonenberg>
bvernoux: that's a known issue. it's a namespace collision between vulkan and windows
<bvernoux>
| ^~~~~~~~~~~~~
<bvernoux>
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/emmintrin.h:1532:1: note: '_mm_mfence' declared here
<bvernoux>
1532 | _mm_mfence (void)
<bvernoux>
| ^~~~~~~~~~
<bvernoux>
There is clearly something wrong in latest code
<azonenberg>
you need to #undef MemoryBarrier after the windows includes
<bvernoux>
towards _mm_mfence
<bvernoux>
It does not build anymore on windows mingw64
<bvernoux>
AcceleratorBuffer.h is new code
<bvernoux>
It seems to start here => C:\msys64\home\bvern\scopehal-apps\lib\scopehal\AcceleratorBuffer.h:884:29: error: '_mm_mfence' is not a member of 'vk'; did you mean '_mm_mfence'?
<azonenberg>
We're not calling _mm_mfence
<bvernoux>
ha ok
<azonenberg>
windows #define's MemoryBarrier to _mm_mfence
<azonenberg>
so you have to #undef it
<azonenberg>
that's a known issue that other folks are working on but we dont have an upstreamed fix for
<bvernoux>
Maybe you can push it if it is a known issue ?
<bvernoux>
ha ok
<azonenberg>
i dont have a windows box to test on
<bvernoux>
I was trying to fix glslang
<bvernoux>
on windows
<azonenberg>
johnsel is working on it
<bvernoux>
and now I have that error
<bvernoux>
for glslang the only way to fix it seems to rebuild all from the git
<bvernoux>
I do not remember who work on the MacOS build but he/she shall check the MacOS SDK is full and have not the same issue as Windows VulkanSDK (missing includes ...)
<bvernoux>
as it is a real mess
<azonenberg>
Yeah that's lain. she should have updates for us soon
<bvernoux>
It is crazy I'm the first to report that in VulkanSDK for windows
<azonenberg>
anyway glfw and vulkan-raii handles all of the vulkan loading for us
<bvernoux>
but volk from VulkanSDK is volk is a meta-loader for Vulkan
<azonenberg>
we dont have to deal with any of that low level platform sutff ourself
<bvernoux>
yes it was just to do a check on what options of VulkanSDK could be great to add
<azonenberg>
johnnsel: so it currently looks like the first issue, not finding surfaces and the crash in glfw surface checking, was the library collision
<azonenberg>
the second issue, the glscopeclient crash, is some weird vulkan / opengl / gtk combo crash
<azonenberg>
i'm about to push a workaround for that which disables glfw in glscopeclient
<azonenberg>
and then uses it in ngscopeclient which isnt using gtk
<azonenberg>
and all of this is just a yak to shave because i need to use my picoscope as a function generator
<azonenberg>
to spit out a 10 MHz refclk for the thunderscope i was trying to test :p
<electronic_eel>
azonenberg: before you port everything to imgui, did you consider using ncurses instead? it is fast, stable, doesn't require fancy gpus or drivers and you can easily use it over ssh
* azonenberg
drops 2500 pound tuna on electronic_eel because a trout is not nearly sufficient
<electronic_eel>
ouch
<azonenberg>
in all seriousness
<azonenberg>
if someone wants to write a curses frontend i wont stop them
<azonenberg>
but i will have no part in it :p
<azonenberg>
ascii art eye patterns
<azonenberg>
decoding pcie in a headless console
<azonenberg>
that *would* be fun to see
<electronic_eel>
consider you could use your trusty vt100 and control your 100 ghz labmaster with it ;)
<_whitenotifier-7>
[scopehal] azonenberg 785e36a - Added workaround to disable GLFW init in glscopeclient since some driver/software stacks seem to choke on it
<azonenberg>
This of course assumes the crash you're seeing is the same one I was just chasing
<azonenberg>
if it's not please let me know :)
<d1b2>
<Mughees> ok
<d1b2>
<Mughees> on it....
<_whitenotifier-7>
[scopehal] bvernoux opened pull request #683: Fix build on WIN32 (missing ; at end of decalartion of std::string NarrowPath(wchar_t* wide)) - https://github.com/glscopeclient/scopehal/pull/683
<_whitenotifier-7>
[scopehal] bvernoux edited pull request #683: Fix build on WIN32 (missing ; at end of declartion of std::string NarrowPath(wchar_t* wide)) - https://github.com/glscopeclient/scopehal/pull/683
<bvernoux>
Good news is with several small fixes in actual scopehal-apps the build is in progress on mingw64
<_whitenotifier-7>
[scopehal] azonenberg closed pull request #683: Fix build on WIN32 (missing ; at end of declartion of std::string NarrowPath(wchar_t* wide)) - https://github.com/glscopeclient/scopehal/pull/683
<_whitenotifier-7>
[scopehal] bvernoux a086d99 - Fix build on WIN32 (missing ; at end of decalartion of std::string NarrowPath(wchar_t* wide))
<_whitenotifier-7>
[scopehal] azonenberg df2a286 - Merge pull request #683 from bvernoux/master Fix build on WIN32 (missing ; at end of declartion of std::string NarrowPath(wchar_t* wide))
<bvernoux>
What is annoying since lot of time is with windows build we have tons of warning "#warning Please include winsock2.h before windows.h"
<bvernoux>
I have tried to fix that but so far I cannot fix that warning
<azonenberg>
that sounds like something johnsel is probably already working on
<d1b2>
<Mughees> This loop ran about 10 times then seg fault occurs
<d1b2>
<Mughees> this is my yesterdays built that I reported... I have yet to try the revisions mentioned by azoneberg
<azonenberg>
Good news
<azonenberg>
that's the same backtrace as what i just fixed
<azonenberg>
So very likely same bug
<d1b2>
<Mughees> cool so that means if I try a fresh clone it should work?
<azonenberg>
Yeah just pull latest git head. in general you should always be working with the current revision or close to it, because things are evolving pretty rapidly
<d1b2>
<Mughees> Yes sure
<d1b2>
<Mughees> thanks
<azonenberg>
I would also be interested in you trying to run ngscopeclient when you get a chance. this is the experimental next generation UI which is far from complete, i just want to know if you have problems getting it to actually run and draw stuff
<azonenberg>
(in the same repo)
<azonenberg>
we'll talk about it more on the dev call but tl;dr GTK has some issues especially wrt windows portability and performance, and we're looking at migrating away from it
<azonenberg>
it's an early stage research testbed and can't even display a waveform yet, so glscopeclient will remain the frontend for the next few months at least
<azonenberg>
the backend filter graph and scope drivers in libscopehal/scopeprotocols are the same for both, so should be no change to your dev work for the most part
<azonenberg>
just a new frontend UI
<d1b2>
<Mughees> Ok sure. For now I think @louis wants me to work with filters etc mostly
<azonenberg>
Yeah. he said you had little or no UI experience and was going to put you entirely on backend
<azonenberg>
You're doing an IIR filter block to start right?
<d1b2>
<Mughees> Louis told me to work on measurements filters first
<azonenberg>
ah ok. That works too
<d1b2>
<Mughees> then IIR I guess
<azonenberg>
Yeah not a big deal from my end, i have no urgent need for either but both need to happen
<azonenberg>
Start with writing generic CPU versions of all the blocks, don't worry about GPU accelerated implementations when you're getting started
<azonenberg>
we can go back and throw a GPU version in down the road
<azonenberg>
(long term I want as much signal processing as possible happening on GPU for performance)
<d1b2>
<Mughees> Awesome. Acknowledged
<d1b2>
<Mughees> I come from embedded software background. I am ramping up
<d1b2>
<Mughees> So far so good
<azonenberg>
Sounds good
<azonenberg>
one thing to be aware of wrt measurements
<azonenberg>
most of them output a *vector* value
<azonenberg>
with one value per instance of whatever it's measuring
<azonenberg>
so for example, the frequency filter outputs one value per cycle of the input waveform
<azonenberg>
which allows you to view trends over time
<azonenberg>
you can then use statistics to reduce that to min/max/avg scalar values
<azonenberg>
There are some measurements that output scalars, like some of the jitter analysis ones, but they're actually degenerate vectors with a single value
<azonenberg>
which means that plotting them is silly but they fit into the same data model
<azonenberg>
when you open the context menu, you'll see measurement filters show up with both "graph" and "stats" options under them
<azonenberg>
graph shows a plot of the vector output. stats hides the plot, runs the filter in the background, and only shows you the summarized values
<azonenberg>
but the filter is still producing a vector under the hood
<d1b2>
<Mughees> Hmmmm....right.....I still have to develop understanding of what goes in and what shoudl come out... I'll definitely keep this in mind
<azonenberg>
So for each new filter, think about whether a vector model makes sense or if the only sane way to implement that particular measurement is a scalar
<azonenberg>
if you can do a vector, do so
<azonenberg>
The other thing you may have seen skimming the code already is that the data model is strongly typed and waveforms can be either sparse (samples occurring at arbitrary times and durations, potentially with gaps between them) or uniform (samples at regular intervals with no gaps)
<d1b2>
<Mughees> do we have github issues created for measurement filters as well?
<azonenberg>
We have some, but i don't know if it's all inclusive wrt the list of measurements we want
<azonenberg>
check under scopehal
<d1b2>
<Mughees> ok wil do
<azonenberg>
anyway, so any given filter block needs to consider the possibility of input being sparse or uniform
<d1b2>
<Mughees> i did see some top, base ones implemented
<azonenberg>
in some case, it may not make sense to handel both cases
<azonenberg>
for example an FFT normally requires uniformly sampled input
<azonenberg>
but you need to check and not crash if given somethign you can't take. fail gracefully and produce no output
<azonenberg>
you may output a sparse or uniform waveform at your discretion. If you have the option of making the output uniform in a given case do so, as it gives better performance and uses less ram (not toting around timestamp values for each sample)
<azonenberg>
but for protocol decodes and measurements, typically the output will be sparse as edges, packets, etc can occur at arbitrary timestamps
<d1b2>
<Mughees> can you elaborate what is a sparse and a uniform waveform? sorry if i ask stupid questions
<azonenberg>
Uniform = what you typically get off a scope
<azonenberg>
each sample represents an equal length region of time
<azonenberg>
the end of one sample and the start of the next are consecutive with no gaps
<azonenberg>
so we don't store timestamps, they're implicit. it's just a vector of values
<azonenberg>
sparse = a series of values taken at strictly increasing points in time, but without any guarantees of regularity
<azonenberg>
so you can have one sample from T=0 to 1, then no data, then another sample from T=50 to 55
<azonenberg>
each sample in a sparse waveform has an offset (beginning of the sample) and duration (time from beginning to end)
<d1b2>
<Mughees> got it
<azonenberg>
A uniform waveform is effectively a sparse waveform where offset is 0, 1, 2... N-1 and duration is 1 for all samples
<d1b2>
<Mughees> thanks
<azonenberg>
but to save memory and CPU time we do not atually store those values
<azonenberg>
so you have to check if the input is an object of SparseWavefor or UniformWaveform type and process it appropriately
<azonenberg>
For analog waveforms the sample value is a float, and represents a value in the waveform's Y axis units (typically volts, but can also be current, frequency, power in dBm, or whatever else makes sense)
<azonenberg>
for digital waveforms it's a bool
<azonenberg>
for protocol data it's arbitrary class/struct type
<azonenberg>
Then a Waveform object, from which all of the rest is derived, also includes some metadata
<d1b2>
<Mughees> Now it worked. Yayyy!
<azonenberg>
The time scale is a multiplier for offset/duration values, and is measured in X axis units (typically femtoseconds for a time series waveform)
<azonenberg>
so for example if you're sampling uniformly at 1 GHz it would be 1e6 because there's a million femtoseconds per sample
<azonenberg>
then there's real world timestamps for when the data was acquired (seconds in time_t format, and femtoseconds since the utc second)
<azonenberg>
for a filter, you should propagate the timestamp value from your input
<azonenberg>
it's not when the data was processed, it's when the measurements it was derived from were taken
<azonenberg>
then there's a 64 bit revision number, which we use to determine if the waveform has been altered
<azonenberg>
if you have some expensive preproecssing like resampling to do, as long as the input pointer and revision have not changed you can cache state
<azonenberg>
if the revision changes, you should ignore any caching you may have done
<azonenberg>
every time you produce new output this should be incremented
<azonenberg>
(helper methods in the Filter class, like Setup*OutputWaveform() hide a lot of this in typical use cases)
<azonenberg>
Finally, there's a "trigger phase" value which represents an offset in timebase units (*not* multiplied by the time scale) for the waveform
<azonenberg>
typically this is used for sub sample trigger interpolation and such
<azonenberg>
to move the entire waveform by a fraction of a sample so it lines up better with other acquisitions
<azonenberg>
but in some special cases, such as de-embedding a channel, it can be arbitrarily large. So do not assume it's less than the time scale, or has a particular sign
<azonenberg>
e.g. if you de-embed a cable that's 1ns propagation delay you will see -1ns of trigger phase
<azonenberg>
(plus the phase of the input signal)
<azonenberg>
Yes, it's a fairly complex data model. it evolved over time to represent all of the different possible ways we can get data, be as efficient as possible and not waste time doing math we don't have to, etc
<d1b2>
<Mughees> Noted!
<azonenberg>
the idea is that you can ignore a lot of the conversions to real time and work with integer sample numbers most of the time
<azonenberg>
even if the samples aren't at regular intervals, things like measuring top/base are unaffected
<azonenberg>
so you can just loop over the data values and copy the timestamps without wasting time looking at them
<_whitenotifier-7>
[scopehal] bvernoux opened pull request #684: Fix MINGW64 Build vk::MemoryBarrier (undef Windows MemoryBarrier which have a conflict with vk::MemoryBarrier) - https://github.com/glscopeclient/scopehal/pull/684
<_whitenotifier-7>
[scopehal] bvernoux edited pull request #684: Fix WIN32 (MINGW64) Build vk::MemoryBarrier (undef Windows MemoryBarrier which have a conflict with vk::MemoryBarrier) - https://github.com/glscopeclient/scopehal/pull/684
<_whitenotifier-7>
[scopehal] bvernoux edited pull request #683: Fix WIN32 (MINGW64) (missing ; at end of declartion of std::string NarrowPath(wchar_t* wide)) - https://github.com/glscopeclient/scopehal/pull/683
<_whitenotifier-7>
[scopehal-apps] azonenberg f826112 - Updated to latest scopehal
<azonenberg>
bvernoux: we added a boolean argument to skip glfw init in glscopeclient
<azonenberg>
because apparently glfw and gtk dont play well together
<_whitenotifier-7>
[scopehal] azonenberg closed pull request #684: Fix WIN32 (MINGW64) Build vk::MemoryBarrier (undef Windows MemoryBarrier which have a conflict with vk::MemoryBarrier) - https://github.com/glscopeclient/scopehal/pull/684
<_whitenotifier-7>
[scopehal] bvernoux 8d9ffbf - Fix MINGW64 Build vk::MemoryBarrier (undef Windows MemoryBarrier which have a conflict with vk::MemoryBarrier)
<_whitenotifier-7>
[scopehal] azonenberg c21d70a - Merge pull request #684 from bvernoux/master Fix WIN32 (MINGW64) Build vk::MemoryBarrier (undef Windows MemoryBarrier which have a conflict with vk::MemoryBarrier)
<bvernoux>
ha ok but somewhere the definition was not updated in that case
<_whitenotifier-7>
[scopehal-apps] azonenberg d78a703 - WaveformArea: continued work on drag-and-drop
<azonenberg>
bvernoux: try pulling latest
<azonenberg>
let me know how fullscreen works, i know we had issues with that in the past
<bvernoux>
yes
<azonenberg>
this is using glfw fullscreen which so far seems to be ok
<azonenberg>
also play with the drag-and-drop
<bvernoux>
there was lot of issue in full screen with dialog too
<azonenberg>
this is still experimental and dropping just logs to stdout, it doesnt actually do anything yet
<bvernoux>
as the dialog was in background or with ugly color (even not in full screen)
<azonenberg>
but the "ohai" and "asdf" buttons in each plot are intended to be something you can double click to open the channel properties
<azonenberg>
ordrag to move the waveform to a new area
<azonenberg>
there's docking-style drop areas that are highlighted, and displayed
<bvernoux>
yes the drag & drop experience is already better even with the demo
<bvernoux>
where we clearly undertand where we can drag & drop
<azonenberg>
this is separate from the full imgui docking
<bvernoux>
it is the magic of imgui ;)
<azonenberg>
because the waveform areas have different scrolling behavior etc
<bvernoux>
ha ok
<bvernoux>
but waveforms will be in a draggable ImGui window ?
<azonenberg>
waveform *groups* are draggable using the normal docking flow
<bvernoux>
yes groups
<azonenberg>
waveform *areas* are not
<bvernoux>
yes it is not really an issue
<azonenberg>
the way waveform are dragging will work is, dropping into the middle of another area moves the waveform into that plot
<azonenberg>
dropping in top/bottom/left/right edge splits and creats a new group
<bvernoux>
to be checked later if waveform could be draggable and more friendly but it was not a big issue on glscopeclient
<azonenberg>
containing a snigle waveform area with the new waveform
<azonenberg>
well one of the things we'll get in ngscopeclient that glscopeclient lacked was support for multiple stacked analog waveforms in a single area
<bvernoux>
yes it is a great feature
<azonenberg>
there's no longer going to be a concept of a single "main" waveform for an area
<azonenberg>
so because of that i can't use imgui docking
<azonenberg>
it doesnt really have a conecpt for multiple widgets co-occupying the same space
<bvernoux>
but you can use multi viewport ?
<azonenberg>
I'm using docking and multi viewport already, for waveform groups
<bvernoux>
as Imgui have both feature docking & multi viewport
<azonenberg>
and dialogs
<azonenberg>
But waveform areas / waveform objects are special since they're not 1:1 with window objects
<azonenberg>
i intend to copy the UX of imgui docking as much as i can
<azonenberg>
to make them feel the same
<azonenberg>
even though it's different code paths
<azonenberg>
anyway, i'll do a demo on the zoom monday of wherever i've got to by that point
<bvernoux>
ha yes it can be an alternative way to install the SDK
<bvernoux>
main issue it is not available for Ubuntu 22.04
<bvernoux>
only old 18.04 & 20.04
<bvernoux>
so it does not work
<bvernoux>
as the CI Build use latest Ubuntu so 22.04 LTS
<Johnsel>
hmm, bvernoux I'm not sure if you noticed but I had solved the glslang issue in my repo already. Although not very cleanly yet as at master it was not building at that point so I couldn't confirm that it worked. If you hadn't seen it perhaps we should agree on some way how to plan such things better
<bvernoux>
@Johnsel, yes clearly I have pushed my solution locally
<azonenberg>
So I think i'm going to try and add power supply support to ngscopeclient before anything else
<azonenberg>
a) because i actually want a good remote power supply UI
<azonenberg>
and b) because i can do it using all imgui widgets and no need to wait for the vulkan renderer work
<bvernoux>
FFT crash with laltest glscopeclient build
<bvernoux>
I tried to add a FFT on demo
<bvernoux>
On Windows
<azonenberg>
bvernoux: stack trace? and have you tried on linux?
<azonenberg>
also try with --nogpufilter and let me know if it still crashes
<bvernoux>
I have no stack trace so far
<bvernoux>
yes it works now with --nogpufilter
<azonenberg>
ok so it's something vulkan or vkfft related
<bvernoux>
do you have tested on your side with latest master ?
<azonenberg>
now try with --debug --trace PipelineCacheManager
<bvernoux>
I will test later with Linux native
<azonenberg>
yes, it works fine for me on linux. i just did a fft earlier. my first guess is it's related to the pipeline cache manager not handling some cases for windows yet
<azonenberg>
but it *should* still work, it just won't have caching so it will take longer to initialize a new fft
<bvernoux>
it crash but it add details
<bvernoux>
[PipelineCacheManager::Lookup] Miss for pipeline VkFFT_FWD_65536.spv
<bvernoux>
[PipelineCacheManager::LookupRaw] Miss for raw VkFFT_FWD_65536
<azonenberg>
yes, cache misses the first time you've used the filter are normal and expected
<azonenberg>
with a ven number of points
<azonenberg>
a given*
<bvernoux>
I need to launch it with gdb to check the crash
<azonenberg>
ok
<bvernoux>
unfortunately I do not have a debug build just release
<azonenberg>
make one? trace from a release build is a lot less useful
<bvernoux>
just to see if other reproduce the crash
<bvernoux>
when adding an FFT on demo
<bvernoux>
any signal
<azonenberg>
bvernoux: try the subtract filter on the demo scope
<azonenberg>
that is not using vkfft, but is also using vulkan
<bvernoux>
ha yes
<azonenberg>
so if it fails, it's likely a problem with all gpu accelerated filters
<bvernoux>
I'm trying to debug it with the release
<bvernoux>
to at least have a crash dump
<bvernoux>
even if the most interesting is debug build
<bvernoux>
Interesting
<bvernoux>
hread 21 received signal SIGSEGV, Segmentation fault.
<bvernoux>
[Switching to Thread 6488.0x850]
<bvernoux>
0x00007ffe876a1095 in ?? () from C:\Program Files\glscopeclient\SPIRV.dll
<bvernoux>
so the issue seems related to SPIRV
<bvernoux>
substract work fine
<azonenberg>
Innnteresting. so it's fft specific?
<azonenberg>
ok we're gonna have to troubleshoot that more
<bvernoux>
yes clearly FFT specific
<azonenberg>
let me know what you find
<azonenberg>
also try the sinc upsample filter
<azonenberg>
that one is also accelerated
<bvernoux>
related to something in VkFFT
<bvernoux>
to be checked with debug build
<bvernoux>
I will also check native Ubuntu 22.04 LTS build
<bvernoux>
Upsample work fine
<bvernoux>
I obtain 20 FFPS
<bvernoux>
FPS
<bvernoux>
before without Vulkan it was something like 10FPS
<bvernoux>
and sometimes there was some freeze too that I cannot reproduce with that new version
<bvernoux>
when I say freeze it means the UI was frozen during few seconds then restart
<bvernoux>
Anyway I have installed latest NVidia drivers too to support correctly Vulkan on Windows
<bvernoux>
On Windows I use NVidia Drivers v425.31 that the last supporting my Geforce GT 650M
<bvernoux>
On linux Xubuntu 22.04 LTS I use nvidi driver 390
<azonenberg>
the old upsample filter used opencl (which may or may not have worked on windows the way we had the build set up) and had some inefficiencies
<bvernoux>
at C:\msys64\home\bvern\scopehal-apps\lib\scopehal\VulkanFFTPlan.cpp:125
<bvernoux>
#7 0x00007ffe5d6cc2ff in std::make_unique<VulkanFFTPlan, unsigned long long&, unsigned long long&, VulkanFFTPlan::VulkanFFTPlanDirection> ()
<bvernoux>
at C:/msys64/mingw64/include/c++/12.2.0/bits/unique_ptr.h:1065
<bvernoux>
#8 0x00007ffe5d516905 in FFTFilter::ReallocateBuffers (this=0x1d94b398c20, npoints_raw=100000,
<bvernoux>
npoints=65536, nouts=32769)
<bvernoux>
at C:\msys64\home\bvern\scopehal-apps\lib\scopeprotocols\FFTFilter.cpp:180
<bvernoux>
#9 0x00007ffe5d516af3 in FFTFilter::Refresh (this=0x1d94b398c20, cmdBuf=..., queue=...)
<bvernoux>
at C:\msys64\home\bvern\scopehal-apps\lib\scopeprotocols\FFTFilter.cpp:211
<bvernoux>
#10 0x00007ffe78bea15d in FilterGraphExecutor::DoExecutorThread (this=0x1d93bbb6960)
<bvernoux>
at C:\msys64\home\bvern\scopehal-apps\lib\scopehal\FilterGraphExecutor.cpp:227
<bvernoux>
#11 0x00007ffe78be9e14 in FilterGraphExecutor::ExecutorThread (pThis=0x1d93bbb6960, i=7)
<bvernoux>
at C:\msys64\home\bvern\scopehal-apps\lib\scopehal\FilterGraphExecutor.cpp:175
<bvernoux>
#12 0x00007ffe78db0c5d in std::__invoke_impl<void, void (*)(FilterGraphExecutor*, unsigned long long), FilterGraphExecutor*, unsigned long long> (
<bvernoux>
--Type <RET> for more, q to quit, c to continue without paging--
<bvernoux>
__f=@0x1d9456fa478: 0x7ffe78be9df4 <FilterGraphExecutor::ExecutorThread(FilterGraphExecutor*, unsigned long long)>) at C:/msys64/mingw64/include/c++/12.2.0/bits/invoke.
<bvernoux>
h:61
<bvernoux>
#13 0x00007ffe78dbf173 in std::__invoke<void (*)(FilterGraphExecutor*, unsigned long long), FilterGraphExecutor*, unsigned long long> (
<bvernoux>
__fn=@0x1d9456fa478: 0x7ffe78be9df4 <FilterGraphExecutor::ExecutorThread(FilterGraphExecutor*, unsigned long long)>) at C:/msys64/mingw64/include/c++/12.2.0/bits/invoke
<bvernoux>
.h:96
<bvernoux>
#14 0x00007ffe78d63130 in std::thread::_Invoker<std::tuple<void (*)(FilterGraphExecutor*, unsigned long long), FilterGraphExecutor*, unsigned long long> >::_M_invoke<0ull,
<bvernoux>
1ull, 2ull> (
<bvernoux>
this=0x1d9456fa468) at C:/msys64/mingw64/include/c++/12.2.0/bits/std_thread.h:252
<bvernoux>
#15 0x00007ffe78d63158 in std::thread::_Invoker<std::tuple<void (*)(FilterGraphExecutor*, unsigned long long), FilterGraphExecutor*, unsigned long long> >::operator() (this
<bvernoux>
=0x1d9456fa468)
<bvernoux>
at C:/msys64/mingw64/include/c++/12.2.0/bits/std_thread.h:259
<bvernoux>
#16 0x00007ffe78d62f8c in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(FilterGraphExecutor*, unsigned long long), FilterGraphExecutor*, unsigned long
<bvernoux>
long> > >::_M_run (
<bvernoux>
this=0x1d9456fa460) at C:/msys64/mingw64/include/c++/12.2.0/bits/std_thread.h:210
<bvernoux>
#17 0x00007ffea4aabf8f in ?? () from C:\msys64\home\bvern\glscopeclient_debug\libstdc++-6.dll
<bvernoux>
#18 0x00007ffed90a4b4b in ?? () from C:\msys64\home\bvern\glscopeclient_debug\libwinpthread-1.dll
<bvernoux>
#19 0x00007ffee596af5a in msvcrt!_beginthreadex () from C:\Windows\System32\msvcrt.dll
<bvernoux>
#20 0x00007ffee596b02c in msvcrt!_endthreadex () from C:\Windows\System32\msvcrt.dll
<bvernoux>
#21 0x00007ffee61b7034 in KERNEL32!BaseThreadInitThunk () from C:\Windows\System32\kernel32.dll
<bvernoux>
#22 0x00007ffee65826a1 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
<bvernoux>
#23 0x0000000000000000 in ?? ()
<bvernoux>
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
<bvernoux>
any idea ?
<bvernoux>
I can output full bt too
<bvernoux>
thread apply all bt
<azonenberg>
No, not sure
<azonenberg>
nothing jumps out at me
<bvernoux>
I could try to rebuild the famous SPIRV.dll
<bvernoux>
it is strange as in VulkanSDK SPIRV is a static lib and not a dll
<bvernoux>
it is what is installed with pacman -S mingw-w64-x86_64-glslang
<azonenberg>
that might be a problem
<azonenberg>
if you are messing with a mix of static and dynamic libs
<azonenberg>
and their state is getting mixed
<azonenberg>
so some calls use static and some dynamic
<azonenberg>
idk, i could see it going bad
<bvernoux>
I have no idea if it is normal or not about SPIRV.dll or SPIRV.lib static
<bvernoux>
as SPIRV.dll is provided in pacman -S mingw-w64-x86_64-glslang
<bvernoux>
which could be potentially not compatible with VulkanSDK
<bvernoux>
VulkanSDK does not have SPIR.dll on windows anyway it is incomplete for glslang ...
<Johnsel>
it crashes here too on Win11 when I try to add FFT filter
<bvernoux>
ok so it is not related to my old GFX card
<bvernoux>
or potentially old Nvidia Driver ;)
<bvernoux>
I see in C:\VulkanSDK\1.3.224.1\Lib\SPIRV.lib
<bvernoux>
But I do not know if it is the same things as SPIRV.dll provided by mingw64
<bvernoux>
Anyway C:\VulkanSDK\1.3.224.1\Bin does not include any SPIRV.dll
<Johnsel>
I copied over my local SPIRV.dll included w/ glslang and it produces a crash as well