<d1b2>
<johnsel> sprinkle some good old timestamps and counters in there and that should at least tell something
<azonenberg>
going old school with vkDebugPrintfEXT
<d1b2>
<johnsel> oh shit haha, damn these newfangled extension thingamajigs
<azonenberg>
x=1161, y=30, iSamples=1281612
<azonenberg>
x=1161, y=31, iSamples=1281612
<azonenberg>
so one particular column of pixels is trying to draw 1.2M samples per thread
<azonenberg>
for exactly one X value, every thread is doing this only when the hang happens
<azonenberg>
so that's pretty conclusive. all the other columns of pixels are fine, this column is fine the rest of the time
<d1b2>
<johnsel> damn you aliasing
<azonenberg>
anyway so this is proof positive, my initial hypothesis of this being a race condition or sync issue goes completely out the window
<azonenberg>
it's something going haywire in the actual shader and the reason for near zero gpu utilization is that only one thread is actually diong anything :p
<d1b2>
<johnsel> yep good work
<azonenberg>
1281563, 1281612
<azonenberg>
1281766
<azonenberg>
are the iteration counts i'm seeing
<azonenberg>
interesting they're all very similar
<azonenberg>
across consecutive runs of the app
<azonenberg>
But not identical
* azonenberg
logs more variables
<azonenberg>
innnnteresting
<azonenberg>
we have 32 threads per block
<azonenberg>
and at this zoom we calculate 31 samples in this pixel
<azonenberg>
i wonder if that's related...
<azonenberg>
So it looks like the actual final values of "i" at the end of the shader are right about the memory depth
<azonenberg>
so basically we're not stopping when we should, and trying to integrate the entire waveform into this one pixel
<_whitenotifier-9>
[scopehal-apps] azonenberg 2f4cf45 - Waveform rendering shader: fixed bug where if the start of a pixel was offscreen, the shader would fail to terminate correctly
<azonenberg>
bvernoux, johnsel: please verify 2f4cf45 fixes the issue for you
<d1b2>
<azonenberg> @johnsel
<azonenberg>
I haven't been able to reproduce the hang with that change
<d1b2>
<johnsel> Oh sorry I just went to bed
<d1b2>
<johnsel> I’ll test after I wake up
<azonenberg>
Ok great thanks
<azonenberg>
I was *completely* barking up the wrong tree with this bug lol
<azonenberg>
the root cause had literally nothing in common with all of my initial hypotheses
<azonenberg>
ok so lesson learned: all these fancy visual debuggers and profilers have nothing on printf when you're grasping at straws to find an infrequent issue :p
bvernoux has quit [Read error: Connection reset by peer]
<bvernoux>
With this PR anyone could test glscopeclient and ngscopeclient from portable apps or msi installer
<bvernoux>
That could be a game changer to have more tester which do not want to rebuild all them self and just use the binaries or install it on Windows
<bvernoux>
johnsel do you understand what happen in the src/glscopeclient/shaders/CMakeLists.txt ?
<bvernoux>
it seems the ngrendershaders is not built at the first step
<bvernoux>
so there is waveform-compute.* shaders are missing at end during install/packaging zip/msi install
<bvernoux>
-there is
<d1b2>
<johnsel> I will take a look
<d1b2>
<johnsel> I got angry at the zipped .msi file
<d1b2>
<johnsel> guess we need to release for that not to happen
<d1b2>
<johnsel> or guess, know
<d1b2>
<johnsel> I can write it if azonenberg is fine with releases
<d1b2>
<johnsel> and I will take a look bvernoux but probably it'll take me a little while to get setup again after dinner
<bvernoux>
I'm testing a crappy fix ;)
<bvernoux>
I have found the issue
<bvernoux>
in fact the compute shader are built when we want to copy them
<bvernoux>
so I will just do a copy again after
<bvernoux>
it is a workaround I'm testing
<azonenberg>
I want to avoid a formal release until we've done a bit more polishing (and probably deprecated glscopeclient so we don't have to deal with it)
<bvernoux>
the aim here is not to do any formal release but just have working msi/zip for both glscopeclient & ngscopeclient for test purpose
<azonenberg>
yeah that i'm fine with
<d1b2>
<johnsel> it'd be on the releases bit in github
<d1b2>
<johnsel> it's not a big announcement but it would be easier to download
<d1b2>
<johnsel> aww alright then I will hate the double-compressed/zipped msis a little longer
<d1b2>
<johnsel> yep we can make a plan for that
<azonenberg>
yeah. i'm not saying we shouldnt release, but it should be a decision made by multiple folks in agreement
<d1b2>
<johnsel> perhaps something bvernoux and I can work on together
<azonenberg>
There's a lot of cleanup and refactoring i've wanted to do as soon as gl is dumped
<d1b2>
<johnsel> it's fine, for me it is just a tag but if you value timing it I understand
<d1b2>
<johnsel> yes we want gl and msys gone
<bvernoux>
msys2/mingw64 will be not so easy at start
<bvernoux>
Visual Studio will have tons of fatal error to build the code
<azonenberg>
So we need to fix those
<bvernoux>
I can told you it will be a real mess
<bvernoux>
yes of course but that will take time
<d1b2>
<johnsel> I don't know, I got a pretty far end into the build with my attempt
<d1b2>
<johnsel> but I -think- I used ninja
<bvernoux>
and that will need lot of specific Linux POSIX only rewrite
<bvernoux>
which was ok with mingw64
<bvernoux>
For 0 gain at end as the mingw64 build is a native build
<d1b2>
<johnsel> well there is gain, for one I hate working with it, and I'm sure others do too
<d1b2>
<johnsel> msys that is
<bvernoux>
today it is not msys it is mingw64
<azonenberg>
bvernoux: yeah i think you are the only one who can tolerate it :p
<bvernoux>
we are not speaking about cygwin crap exe but native mingw64 executable without crappy dependencies
<bvernoux>
the only dependency for windows is msvcrt.dll en kernel.dll
<d1b2>
<johnsel> well you need the msys package and then you need to get the things, and the weird depencies and your custom tool and it's a mess
<d1b2>
<johnsel> I have to put in a few hours to get setup
<bvernoux>
other dependencies will be exactly the same on Visual Studio with -MT except we can remove msvcrt.dll dependency in that case (with bigger exe)
<bvernoux>
which weird dependencies ?
<bvernoux>
check ngscopclient.exe it is clean
<d1b2>
<johnsel> PKGBUILD
<bvernoux>
PKGBUILD is nothing
<d1b2>
<johnsel> and the sorta kinda the same packages that you get but not always
<bvernoux>
you can totally avoid it today alraedy
<d1b2>
<johnsel> sure but you run into it often when you do change things
<d1b2>
<johnsel> at least I have
<bvernoux>
I do not use it at all in fact for fast build
<d1b2>
<johnsel> it has cost me many hours to figure it out
<d1b2>
<johnsel> and that limits people
<d1b2>
<johnsel> I saw the value in the project so I figured it out
<d1b2>
<johnsel> but many people will just skip over it
<azonenberg>
bvernoux: that sounds more interesting
<bvernoux>
the only drawback is the msi & zip is not done automatically in that case
<bvernoux>
but that build everything
<bvernoux>
note in that exemple I use cmake -G"Ninja" -DBUILD_TESTING=OFF -DCMAKE_BUILD_TYPE=Release ..
<bvernoux>
you can also use Debug
<bvernoux>
Release is optimized build with debug symbol anyway
<bvernoux>
not stripped
<d1b2>
<johnsel> that does hide all the interdependencies, but they will still be there
<bvernoux>
which one ?
<bvernoux>
it is exactly like the Linux build in that case
<d1b2>
<johnsel> yes, so the interactions with any windows components that are handled by mingw64
<bvernoux>
good luck to solve the lib dependencies with VisualStudio yes
<d1b2>
<johnsel> you also still need msys
<bvernoux>
like glew, glfw
<d1b2>
<johnsel> there's only a few, I had little issues in fact
<bvernoux>
yes you need a minimal msys in all case
<d1b2>
<johnsel> using vcpkg
<bvernoux>
yes anyway there is lot of work
<azonenberg>
bvernoux: why do we need msys if we're doing a fully native visual studio build?
<bvernoux>
I suspect we will need msys for some stuff
<d1b2>
<johnsel> the end product is native
<bvernoux>
like wget
<azonenberg>
why can we not just install the vulkan sdk and other stuff directly and then just have cl.exe and link.exe point to them?
<bvernoux>
git
<bvernoux>
or to have them in path with is a nightmare
<azonenberg>
for the CI build, sure
<azonenberg>
none of that is needed for end users
<bvernoux>
it is why I say Mingw64 is a dream in comparison to VS ;)
<bvernoux>
furtunately we can generate the Visual Studio project with the cmake
<bvernoux>
but you will see all the mess to solve things which are available only in Linux world
<azonenberg>
i dont care if we use some mingw/msys tools to get git, wget, and such in the CI environment
<azonenberg>
i do not want to force posix stuff on end users doing dev on a windows system
<d1b2>
<johnsel> even that isn't necessary
<bvernoux>
yes the hard part will be to discover all the posix stuff not existing with Visual Studio to be fixed one by one
<d1b2>
<johnsel> I think it's best we inventarize how either approach would work and what it would actually need and then decide
<azonenberg>
agreed
<bvernoux>
a basic msys2 env is not a big pain until all is built with vs2019 or 2022
<d1b2>
<johnsel> we know what value each direction brings, but the amount of work is not clear
<bvernoux>
I just think it is a big work
<bvernoux>
On my side I will prefer to have ngscopeclient fully replacing glscopeclient
<d1b2>
<johnsel> that's a given 🙂
<azonenberg>
yeah that was always the goal and i think we're not too far
<azonenberg>
Just need to get some time to spend on it
<bvernoux>
I do not really see the point with a VS build is so mandatory for you ?
<bvernoux>
it does not bring a lot of things better than mingw64
<bvernoux>
visual studio compiler is a bit better than gcc for memory or stuff but it is not amazing
<azonenberg>
bvernoux: the second biggest reason i wanted to move to imgui - only behind the slow performance with gtk - was getting rid of mingw/msys
<bvernoux>
azonenberg, The question is why ?
<bvernoux>
azonenberg, The performance will be clearly not better with a VS build not even 5% I think
<d1b2>
<johnsel> to me its that it's more accessible to other devs, and that we want as little external dependencies as a principle
<azonenberg>
yes, exactly
<azonenberg>
its not for performance its ease of setup
<bvernoux>
we already have as little dependencies as possible with ngscopeclient on mingw64
<bvernoux>
see the dll packed with the portable version
<bvernoux>
tell me what is bloated
<bvernoux>
for me nothing
<d1b2>
<johnsel> it's not the end product that matters here, it's the source
<bvernoux>
I'm totally agree that for mid/long term VisualStudio build with environnment is better to have more developers interested
<bvernoux>
but it is just because they want their IDE
<d1b2>
<johnsel> look I can work on it alone and see how far I get, I did that before and was able to replace a lot of dependencies easily with vcpkg
<bvernoux>
in all case all the stuff dependencies we use shall be used also with VS
<bvernoux>
glfw is required by imgui and so on
<bvernoux>
anyway the dependencies are not so much compared to glscopeclient and the crappy GTK
<d1b2>
<johnsel> yep and you can pull those in easily with a vcpkg
<d1b2>
<johnsel> it would be ngscopeclient only
<d1b2>
<johnsel> we specifically removed some stuff already for it
<bvernoux>
ha you are speaking about a static executable ?
<d1b2>
<johnsel> I mean you can do both
<bvernoux>
in that case you will need to rebuild all source for all dependencies from scratch to avoid DLL
<bvernoux>
we can do the same on mingw64
<bvernoux>
but that will add just lot of time lost to rebuild all from scratch to have a bigger exe including for example libpng, pcre2 ...
<azonenberg>
yeah i dont want static linking, that would make the binaries enormous. and also potential licensing issues around third party libs
<azonenberg>
if we pull in anything lgpl
<bvernoux>
yes
<d1b2>
<johnsel> it's about having a Windows way of pulling in deps and building it with vs that is easy
<bvernoux>
That will bring nothing I think vs what we have today for ngscopeclient
<d1b2>
<johnsel> except devs that won't touch msys
<bvernoux>
ngscopeclient have 31dll today
<d1b2>
<johnsel> which I would be if it wasn't for this project
<bvernoux>
including it's own DLLs of course
<d1b2>
<johnsel> I understand you put a lot of work in, and it will be used for quite some time still but I really think it has a lot of value stripping it out entirely
<bvernoux>
the issue on windows dev is the shell is crap
<bvernoux>
and there is no default tools like we have on Linux or msys2
<bvernoux>
but yes we can probably replace fully msys2 stuff with vcpkg package and just a cmd to start the build with cmake
<bvernoux>
or even build all from VS IDE which use cmake
<d1b2>
<johnsel> bvernoux your pastie way of building gave me: -- Found PkgConfig: C:/msys64/mingw64/bin/pkg-config.exe (found version "1.8.0") -- Checking for module 'gtkmm-3.0' -- Package 'gtkmm-3.0', required by 'virtual:world', not found CMake Error at C:/msys64/mingw64/share/cmake/Modules/FindPkgConfig.cmake:607 (message): A required package was not found Call Stack (most recent call first):
<d1b2>
C:/msys64/mingw64/share/cmake/Modules/FindPkgConfig.cmake:829 (_pkg_check_modules_internal) CMakeLists.txt:50 (pkg_check_modules) -- Configuring incomplete, errors occurred! ninja: error: loading 'build.ninja': Het systeem kan het opgegeven bestand niet vinden.
<bvernoux>
I'm fixing the mess
<bvernoux>
I'm testing locally it is faster
<d1b2>
<johnsel> yep, just wanted to let you know
<bvernoux>
I think I have found the error
<bvernoux>
bad directory ;)
<bvernoux>
we was copying src shader directory instead of built shader ...
<bvernoux>
fortunately the full build take less than 3minutes here
<bvernoux>
when it take >40mins on GitHub so I can test different things quickly from scratch
<bvernoux>
I confirm that work without external dependencies
<bvernoux>
I have even renamed my C:\msys64 dir to C:\msys64_ and executed all from portable dir from a new cmd
<bvernoux>
the demo now work again ;)
<d1b2>
<johnsel> ok I will do my much slower than yours build then 😉
<d1b2>
<johnsel> bvernoux -- Package 'gtkmm-3.0', required by 'virtual:world', not found CMake Error at C:/msys64/mingw64/share/cmake/Modules/FindPkgConfig.cmake:607 (message): A required package was not found Call Stack (most recent call first): C:/msys64/mingw64/share/cmake/Modules/FindPkgConfig.cmake:829 (_pkg_check_modules_internal) CMakeLists.txt:50 (pkg_check_modules)
<d1b2>
<johnsel> this is from your pastie build script
<d1b2>
<johnsel> just to be clear
<bvernoux>
this pasties is minimalist
<d1b2>
<johnsel> oh wait
<d1b2>
<johnsel> this might be my mistake
<bvernoux>
when you have solved all the dependencies before
<bvernoux>
in the manual
<bvernoux>
especially if it is the 1st time you install mingw64
<d1b2>
<johnsel> no this is fresh install
<d1b2>
<johnsel> I had a bios issue that plagued me for months and kept corrupting my windows
<d1b2>
<johnsel> yes I am aware of the procedure, I was just curious if it would work from scratch
<bvernoux>
especially you need latest VulkanSDK 1.3.250.0
<bvernoux>
it is new
<bvernoux>
before we was using an old version
<d1b2>
<johnsel> since it's dev-ux (user experience, to be verbose) that we're talking about
<bvernoux>
but your error seems more linked to gtkmm stuff
<d1b2>
<johnsel> yeah missing package
<d1b2>
<johnsel> probably easy fix
<d1b2>
<johnsel> but it's not there now
<bvernoux>
ha yes I understand
<d1b2>
<johnsel> include that script somewhere in the repo
<bvernoux>
the missing stuff are installed by the PKGBUILD ;)
<d1b2>
<johnsel> and that's how we come full circle haha
<bvernoux>
they shall be installed at least 1 time before
<azonenberg>
anyway, gtk is going by-bye as soon as we dump glscopeclient
<bvernoux>
I understand why you hate the PKGBUILD ;)
<bvernoux>
let me clear that
<bvernoux>
to avoid it at first install
<bvernoux>
yes gtk crap are only for glscopeclient build
<d1b2>
<johnsel> -- Found Vulkan: C:/VulkanSDK/1.3.250.0/Lib/vulkan-1.lib (found version "1.3.250") found components: glslang shaderc_combined glslc glslangValidator CMake Error at CMakeLists.txt:88 (message): Glslang_BUILD_INCLUDE_DIR Not found -- Configuring incomplete, errors occurred! ==> ERROR: A failure occurred in build(). Aborting...
<bvernoux>
What you want is mingw64/msys2 does not have the Windows Path for your other tools ?
<bvernoux>
the ones configured in Windows Environment Variables (user & System) ?
<bvernoux>
johnsel could you check if all work fine for you with the pre-built version installer/portable apps here https://hydrabus.com/scopehal-apps/