<azonenberg>
louis: so whats the status of your zero hold PR, ready to merge now?
<azonenberg>
lain: how's the queue manager going?
<d1b2>
<louis> I think it should be ready to merge
<d1b2>
<louis> Need to merge w/ corresponding patch to scopehal for the zero-hold flag
<d1b2>
<louis> modulo whatever naming change you'd like for the flag
<lain>
azonenberg: just finished the code, now integrating it into VulkanInit.cpp and such, should be able to test it soon
<lain>
azonenberg: oh hm. this is going to mess with the queue debug names
<lain>
I'm commenting it out for now. a fix might be to allow a QueueHandle to append a name, though in that case I'd probably want QueueHandle instances to be unique instead of a shared_ptr, they would *contain* the shared_ptr and the name, so the name can be removed from the list when the handle is destroyed
<lain>
¯\_(ツ)_/¯
<azonenberg>
So to start, how about the most recent user of a handle gets the debug name?
<azonenberg>
i.e. pass a name when you create the queue
<azonenberg>
lain: and it overwrites the previous name if there is one
<azonenberg>
the thinking being, at least for now i'm the main one messing with low level vulkan code and that's all on nvidia with plenty of queues to go around
<azonenberg>
actually better idea, append the names or somethin
<azonenberg>
so all of the names get mishmashed into one if you have two handles sharing one physical queue
<azonenberg>
that will also make it more obvious in the debugger which logical queues are sharing one physical queue
<lain>
kk
<lain>
yeah that's what I was thinking above
<lain>
for now I won't worry about removing names if a queue is destroyed, since I think currently that only happens at exit?
<azonenberg>
correct
<azonenberg>
well... if we start doing accelerated processing of scope waveforms
<azonenberg>
during acquisition
<azonenberg>
we'll have one queue per scope that's destroyed when you disconnect from that scope
<lain>
alright
<lain>
well it's a relatively trivial change but I'd like to avoid it now if I can, so, I'll just append and we'll go from there
<azonenberg>
yeah
<azonenberg>
louis: and you only changed the glscopeclient side? or did you make any changes to the shader in ngscopeclient?
<d1b2>
<louis> Yes, correct. Should I have been making changes to both?
<azonenberg>
The two shaders are the same. so any changes you made to one should be replicated on the other
<azonenberg>
there's no CPU side code for the new feature yet, we only support interpolated analog rendering for the moment
<azonenberg>
of uniform waveforms even
<azonenberg>
but copy the shader changes
<azonenberg>
and any changes you might need to the push constants
<azonenberg>
also hmm, seems ngscopeclient has a sign flipped in the texture rendering
<azonenberg>
the waveforms are all upside down
<lain>
azonenberg: hmm.. so this change is going to require an api change to Filter, or a change to QueueHandle
<lain>
Filter::Refresh() takes a vk::raii::Queue&, but if we want to use QueueHandle::Submit, then we'll need to change that...
<lain>
thoughts?
<azonenberg>
Hmmm
<azonenberg>
one option: add a method to lock the QueueHandle, return a shared_ptr<vk::raii::Queue> or similar
<azonenberg>
(blocking if the queue is in use by another thread)
<azonenberg>
and another method to free it
<lain>
that's an alright interim strategy
<azonenberg>
we do need to be able to access the raw queue handle because e.g. vkFFT needs it
<azonenberg>
so there has to be a way to secure exclusive access
<lain>
I see
<lain>
alright
<lain>
I'll do that for now then
<azonenberg>
maybe provide a wrapper lock object similar to std::lock_guard
<azonenberg>
QueueLock lock(queue)
<lain>
ah, yeah
<azonenberg>
filter.Refresh(*lock)
<azonenberg>
add an operator*() that returns the underlying queue
<lain>
I could just expose the mutex and use lock_guard on it <.<
<azonenberg>
then when it goes out of scope it frees the lock
<lain>
oh but it needs to wait on fence, right
<lain>
so yeah, a custom QueueLock makes sense
<azonenberg>
yeah and by forcing RAII it's more mistake proof
<azonenberg>
wrt forgetting to unlock etc
<lain>
agreed
<azonenberg>
In other news, i'm about to assemble a prototype AKL-PT5 with a (bodged on) 3rd order Bessel-Thomson low pass filter integrated to flatten the tip peaking
<azonenberg>
it uses, among other parts, a 200 fF capacitor and a 300 pH inductor
<lain>
hehehe
<azonenberg>
this is what happens when you try to build a filter with response into the X band with discrete passives instead of distributed element lol
<azonenberg>
but i can't afford the space for distributed
<lain>
oh god help I've typed "lock" too many times, it doesn't look like a word anymore
<azonenberg>
lol
<azonenberg>
oh i've been debugging thread safety issues all day in the new rendering path
<azonenberg>
there's still at least one more left
<azonenberg>
reminds me of the sign they used to have on the wall at the IOA lab about 6" below the ceiling
<azonenberg>
saying "you must be this tall to write multithreaded code"
<lain>
XD
Degi has quit [Ping timeout: 268 seconds]
Degi has joined #scopehal
<lain>
hokay
<lain>
it's getting late, time for me to start winding down. made great progress today on the queue manager, should be able to finish it tomorrow :3
<lain>
rather, the queue manager is done, tomorrow I'll finish the trivial refactoring to get everything using QueueHandles where appropriate, and QueueLock where they need the queue reference
<azonenberg>
woo
<d1b2>
<louis> Oh jeez I somehow made my zerohold PR against the pre-Vk patches? Doing some git wrangling here
<d1b2>
<louis> OK, It's clean and working against HEAD glscope. I will look at ngscope compat later, gotta go to bed :)
<d1b2>
<louis> Ty lain... Much neater shader build system!
bvernoux has joined #scopehal
massi has joined #scopehal
<lain>
:D
bvernoux1 has joined #scopehal
<d1b2>
<azonenberg> So I didn't get a chance to post these pics last night
<d1b2>
<azonenberg> But i reworked a v0.7 AKL-PT5 (without the filter I had been using)
<d1b2>
<azonenberg> to add the experimental Bessel filter. I still need to try on the actual v0.9 PCB layout, as well as experimenting with small tweaks to component values
<d1b2>
<azonenberg> (these are adjusted from the nominal calculated Bessel values due to both standard component values and to compensate for parasitics)
<d1b2>
<azonenberg> Nominal is 335 pH, 2192 pH in the series branch and 386.2 fF in the shunt
<d1b2>
<azonenberg> I adjusted the inductors to 300 and 2200 to match standard values in the Murata LQP03 series and found that after other parasitics, a 200 fF Kemet CBR02 looked like a good option
bvernoux1 has quit [Ping timeout: 260 seconds]
<d1b2>
<azonenberg> Here's measured probe head S21
<azonenberg>
Top eye is straight off probe, bottom is with cable de-embedded
<azonenberg>
you can see the peaking actually gets worse with the cable but ultimate bandwidth is higher
<azonenberg>
O optimally you'd create a de-embedding transfer function to flatten the full system response
<azonenberg>
This is with an experimental homebrewed 500 ohm tip resistor, not a 450 ohm HML. With a 450 of this same series (Vishay CH), insertion loss would be about a dB less and the peaking at 3.5 GHz might be slightly less pronounced
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 250 seconds]
bvernoux has joined #scopehal
bvernoux1 has quit [Ping timeout: 248 seconds]
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 264 seconds]
bvernoux has joined #scopehal
bvernoux1 has quit [Ping timeout: 268 seconds]
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 268 seconds]
bvernoux has joined #scopehal
bvernoux1 has quit [Ping timeout: 250 seconds]
massi has quit [Remote host closed the connection]
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 264 seconds]
<electronic_eel>
which kind of tip brew were you using?
<electronic_eel>
the 0402 flip chip one with leads soldered&epoxied on?
<azonenberg>
this was an 0201. but it performed almost identically to the 0402 in the same series
<azonenberg>
so i intend to use the 0402 moving forward as it's far easier to work with
<azonenberg>
and it's uv cure polyurethane not epoxy
<azonenberg>
but close enough
bvernoux has joined #scopehal
bvernoux1 has quit [Ping timeout: 268 seconds]
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 246 seconds]
bvernoux1 is now known as bvernoux
<bvernoux>
@azonenberg, I have built latest version of ngscopeclient today
<bvernoux>
and strangely is it slower than 1 day before
<bvernoux>
about 5fps slower
<bvernoux>
also glscopeclient is now 11fps before it was a bit faster
<azonenberg>
well i didnt change glscopeclient at all
<azonenberg>
so that's likely something on your system
<azonenberg>
i did fix some thread safety bugs in ngscopeclient
<azonenberg>
but the mutexes are only locked when you create/destroy a window
<azonenberg>
so should be fairly lightweight for the most aprt
<bvernoux>
yes I will retry with a clean reboot
<bvernoux>
it was also strange glscoplient was slower I suspected there was no any major update/change
<bvernoux>
I have relaunched ngscopeclient and yes it is fast
<bvernoux>
even a bit faster in fact
<bvernoux>
it was a bug with my PC after a relaunch it is better
<bvernoux>
oups crashed when resizing during demo
<bvernoux>
I will check tomorrow if I can reproduce that issue
bvernoux has quit [Quit: Leaving]
<azonenberg>
so there is a bug in glscopeclient related to filter autoranging and initial sizes being garbage the first frame after rendering or something