<azonenberg>
ehntoo: and the bigger issue is that a native osx menu likely isnt going to play well with the imgui menus. so we'd have to write a bunch of platform specific marshalling code etc
<azonenberg>
it would be essentially a completely new ui element
<azonenberg>
So it will probably be a while before we did it
<d1b2>
<ehntoo> agreed
<azonenberg>
hmmm seems i still have a handle leak
<azonenberg>
just not in the buffer pool anymore
<azonenberg>
i'll work on that once i finish cursors
<d1b2>
<ehntoo> a short summary of what I've discovered so I (or someone else) can find it in the log: when given only a single instance of a function with attribute((feature)) on it, clang will only apply different cpu/arch/subarch feature flags for the compilation of that function , not treat that function as if it doesn't exist on architectures that don't support that feature flag, as GCC does. To make it do multiversioning dispatch, you need a second,
<d1b2>
"default" implementation. These multiversioned implementations need to appear before any usage of them within a source file. clang seems to treat the feature attribute as part of the function signature, and will refuse to match a candidate in a class declaration without that feature. (https://github.com/ehntoo/scopehal-apps/actions/runs/3171025671/jobs/5164080164#step:7:289)
<d1b2>
<ehntoo> if If find some time to look at this again tomorrow maybe I'll try without doing some of the gymnastics I was trying in order to support the existing software --noavx2/--noavx512f flags.
<azonenberg>
ehntoo: we are not using gcc function multiversioning
<azonenberg>
We are using the target attribute to say "use the flags for this function"
<azonenberg>
then we ifdef to disable that function on ISAs lacking that feature
<azonenberg>
we are also using different *names* for each of the alternate implementations, and then doing our own dispatch based on cpuid checks
<azonenberg>
because this works on PE targets as well as ELF targets
<azonenberg>
and with visual studio (althuogh this will likely need some vc++ specific pragmas instead of the __attribute declaration)
<d1b2>
<ehntoo> hmm
<d1b2>
<ehntoo> I guess it may just not be possible to do avx512f under clang then, since it errors on incompatible ABIs.
<azonenberg>
so the thing that confuses me is, the immintrin stuff is all inlines
<azonenberg>
there should be no abi for an inline function
<azonenberg>
as it's not actually a call/return structure
<azonenberg>
and i dont think we have any functions that return 512 bit vector types
<azonenberg>
i'm not super concerned about that though because most of our linux builds are gcc and our primary mac targets are arm
<Bird|otherbox>
@ehntoo: can you reproduce the crash with the llvm symbolizer on?
<d1b2>
<ehntoo> not handily, I'd have to go fetch another machine.
<azonenberg>
to __attribute__((target("arch=avx512f")))
<azonenberg>
see if that changes anything
<azonenberg>
it's saying "avx512 not enabled" which implies that it isnt recognizing the target attribute
<azonenberg>
that said, the ngscopeclient version of that same code will probably be all vulkan and the glscopeclient version may or may not get vulkan-ized
<azonenberg>
So dont beat yourself up too much over avx512 not working. we only use it in a handful of spots and i think many but perhaps not all of them can go to GPU
<azonenberg>
Unrelated, i'm thinking of changing how cursors work in ngscopeclient
<d1b2>
<ehntoo> yeah. come to think of it, I'm not sure any apple platforms ever shipped with avx512 support?
<_whitenotifier-7>
[scopehal-apps] azonenberg 1212cb5 - Initial X axis cursor support in ngscopeclient. Incomplete, just a movable line with no readouts.
massi has joined #scopehal
nelgau has quit [Ping timeout: 250 seconds]
<azonenberg>
So i'm thinking about how to do cursors in ngscopeclient now that we support arbitrarily many waveforms in a plot
<azonenberg>
i no longer have a single analog waveform that i can display a value of right next to the cursor line
<azonenberg>
So i'm wondering about maybe displaying the value next to the channel button?
massi has quit [Remote host closed the connection]
<azonenberg>
lain: thoughts on this? ^
<azonenberg>
also consider the case of multiple cursors and in-band power on fft traces
<azonenberg>
how do we display this information usefully if we have six or eight channels in one plot?
<azonenberg>
or do we give up and do what most scopes do, and have the concept of an "active" channel and only display the info for the active channel?
<lain>
azonenberg: I'm torn. on the one hand, I like having the trace information next to the cursor when I'm quickly examining a waveform, but on the other hand, it would get crowded fast if we put many values there...
<azonenberg>
another possible approach is to display next to the cursor if only one or two channels are active
<azonenberg>
and if more than that, switch to next to the buttons?
<azonenberg>
but that could be confusing
<lain>
yeah I was thinking that also, but then it could be confusing because... yeah
<lain>
"where'd they go?"
<_whitenotifier-7>
[scopehal-apps] azonenberg closed issue #273: [Windows] Going into fullscreen mode and out again causes the window title bar to permanently disappear - https://github.com/glscopeclient/scopehal-apps/issues/273
<azonenberg>
lain: how far are we from ready to merge the queue allocator stuff?
<lain>
some day I will be awake :P
<azonenberg>
lol
* azonenberg
opens a socket and pours coffee into it
* lain
goes to poke the merge right now
<lain>
ok wow we stepped on each other a lot here
<azonenberg>
lol oh?
<lain>
ehh ok not as bad as it initially seemed
<lain>
it looks like you removed the global vkFFT queue, cmd pool, and cmdbuf, and instead are using the transfer buffers for that?
<azonenberg>
Not exactly. we're using the transfer buffer for initializing vkfft
<lain>
oh, hm
<azonenberg>
the transfer queue*
<lain>
I don't see any of the vkFFT globals being used?
<azonenberg>
For actually running the fft we use whatever queue is passed in to Refresh()
<azonenberg>
correct
<azonenberg>
they got refactored out
<azonenberg>
we now need one less queue
<azonenberg>
they shouldn't be there at all anymore
<lain>
or wait, hm
<lain>
ah, yeah
<lain>
ok yeah they're gone
* lain
baps git merge
<azonenberg>
tl;dr it was a misunderstanding of how vkfft actually worked
<azonenberg>
they have a bunch of fields you can specify at creation time or when you actually run a fft
<azonenberg>
many specified at creation time are not actually used until you run a transform,
<lain>
oic
<azonenberg>
so basically we never actually used many of those fields i was allocating. it was easier to get rid of them entirely
<lain>
ok let's see if she builds now
<lain>
the other big changes are in WaveformArea, for the tone mapping.. looks like you pulled a lot of that out and put it into the new DisplayedChannel class. not too bad, just a lot of shuffling
<azonenberg>
yeah that was needed to handle multiple channels per waveformarea
<d1b2>
<Mughees> A general comment: I see that in tektronix scope we have an option of gating the signal. There is full record gating, screen gating (perform calculation only on what is visible in the oscilloscope window), custom gating etc. In the filters we perform full record gating. Do we have a way to perform other types of gating or is it planned?
<lain>
ok well it's building and running, that's progress... it seems to have deadlocked while trying to render the waveforms, I'm sure that's a bug in my queue manager introduced in the merge
<azonenberg>
mughees: we're going to be doing that with louis's new "extract region of waveform" filter
<d1b2>
<Mughees> Cool!
<azonenberg>
There will eventually be nice gui integration
<azonenberg>
where you can drag start/stop of the extracted region or something
<azonenberg>
but that's a ways out
<lain>
correction: glscopeclient works fine, ngscopeclient is the one that is hanging on rendering waveforms, will debug in a moment.
<azonenberg>
yeah ngscopeclient is more heavily multithreaded
<lain>
hmmm
<azonenberg>
glscopeclient i think runs the render compute shader in the gui thread
<lain>
VUID-vkCreateDevice-ppEnabledExtensionNames-01387(ERROR / SPEC): msgNum: 307460652 - Validation Error: [ VUID-vkCreateDevice-ppEnabledExtensionNames-01387 ] Object 0: handle = 0x11e832a00, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x12537a2c | Missing extension required by the device extension VK_KHR_swapchain: VK_KHR_surface. The Vulkan spec states: All required device extensions for each
<d1b2>
<azonenberg> We have preferences! Only bools are functional so far
<lain>
yaay
<azonenberg>
one thing i need to think about very soon is how much to diverge from glscopeclient and whether to share the prefs storage location or not
<azonenberg>
because the ui is different so some settings only make sense for one side or the other
<azonenberg>
i think a clean split might be better
<lain>
agree
<lain>
OH
<lain>
ok yeah, the deadlock is obvious, derp :3
* azonenberg
watches lain's philosophers fall over from starvation one by one
<lain>
azonenberg: pushed my changes to macos branch, I'll merge master again either tonight or tomorrow
<lain>
there's a handful of vulkan validation issues with the macos branch presently, haven't had time to assign blame for them yet but there's a decent chance most of them were introduced with QueueManager, will chase those down after I merge master again
<lain>
azonenberg: but, given how much I'm diverging from master at this point, if you could test this branch and see how you feel about a PR, that'd be great
<azonenberg>
yeah i dont want to diverge too far
<azonenberg>
i'll pull and check later tonight and see. there's a few validation errors related to resources not freed at shutdown
<azonenberg>
chased down a few and still have one ongoing