<d1b2>
<johnsel> well, 24 hours later I still hate PSpice
<d1b2>
<johnsel> shader caching progress looks good though
<d1b2>
<johnsel> definitely standard good practice (and there are some guidelines available from the GPU vendors + Vulkan people)
<azonenberg>
johnsel: yeah the big thing missing is caching the native shader binaries for vkfft
<azonenberg>
that needs an upstream fix
<d1b2>
<johnsel> weird that they don't by default, though it is really an app responsibility not a library one
<d1b2>
<johnsel> but exposing some interface for it would have been nice
<azonenberg>
well the issue is they create the kernels internally
<d1b2>
<johnsel> yeah exactly
<azonenberg>
you dont have direct access to the native vulkan pipeline handles
<azonenberg>
you just pass in a command queue and buffers
<azonenberg>
they have a caching mechanism already
<azonenberg>
but it only caches the generated spi-rv
<azonenberg>
spir-v*
<d1b2>
<johnsel> that's generally the only part that is cached, though, no?
<azonenberg>
no
<azonenberg>
when they create a fft plan they generate glsl
<azonenberg>
this is then compiled into spir-v
<azonenberg>
which is passed to vulkan and compiled to a native binary
<azonenberg>
They cache the code generation output (first two steps)
<azonenberg>
not the native compilation (third step)
<azonenberg>
i.e. there is no VkPipelineCache in play at any time
<d1b2>
<johnsel> right
<d1b2>
<johnsel> then my original comment stands
<d1b2>
<johnsel> an interface would have been nice
<azonenberg>
yeah. and i have a ticket open upstream requesting one
<d1b2>
<johnsel> I don't like libraries deciding their own caching rules
<d1b2>
<johnsel> Random and somewhat offtopic but I have a weird issue with PSpice for TI library not showing parts it used to before nor the reference/testbench designs. I have downloaded those files from the TI website and somehow they showed up in the library and after a Windows reinstall my designs are broken, the library included with PSpice for TI doesn't have the files, and reinstalling the library with the interface made the already downloaded files
<d1b2>
dissappear entirely. Does that sound familiar to anyone?
<azonenberg>
johnsel: yeah my ticket requests that they allow you to provide your own vkpipelinecache
<azonenberg>
as far as how libscopehal does it, there is a global PipelineCacheManager object that you can interface with
<azonenberg>
There are explicit methods to load from disk, save to disk, and empty it
<d1b2>
<johnsel> azonenberg: can you test something unrelated for me?
<d1b2>
<johnsel> nvm
<d1b2>
<johnsel> for fuck fuckers sake
<d1b2>
<johnsel> ms defender has been detecting random crap as virusses the past days
<d1b2>
<johnsel> including the fucking TI library update
<d1b2>
<johnsel> obviously 0 feedback to the user about any of this by PSpice
<d1b2>
<johnsel> it just starts updating silently and fails silently
<d1b2>
<johnsel> worse, it thinks it succeeded and stops retrying
<d1b2>
<johnsel> so now I have the files but the library database doesn't have the delta applied
<azonenberg>
lol
<azonenberg>
that would explain a lot :p
<d1b2>
<johnsel> yep and then on top if you retry too often their WAF kicks in
<d1b2>
<johnsel> so you get no response at all
<d1b2>
<johnsel> which, you guessed it, they don't handle
<d1b2>
<johnsel> it's a big clusterfuck
<d1b2>
<johnsel> but 36 hours, 2 reinstalls and 25 restarts of the app (you can't kick off the update process manually) I solved it
<d1b2>
<johnsel> and the original problem is their database has a missing extension for that specific reference design
<d1b2>
<johnsel> so I didn't have a problem even other than I though using their 'debugging' step of reinstalling the database might help
<d1b2>
<Darius> whenever I've had to use windows for dev work I always find it such a chore
<d1b2>
<Darius> so many annoyances get in your way
<d1b2>
<johnsel> while true this is just bad programming on Cadence/TI's end
<azonenberg>
yeah i hate windows in general as a platform
<d1b2>
<johnsel> ever since they added WSL it got about 1/3rd less bad though
<d1b2>
<Darius> the problem with WSL is it gives corporate an excellent reason to deny you running Linux (or OSX) on your computer
<d1b2>
<Darius> but it is a nice escape hatch if you are already there
<_whitenotifier-7>
[scopehal] azonenberg 1de823a - VulkanInit: enable extensions required by glfw, verify that render queue type is glfw presentation compatible
<_whitenotifier-7>
[scopehal-apps] azonenberg 8113c4f - Updated scopehal. Added glfw3 dependency. Added "ngscopeclient" test app skeleton for initial glfw/imgui experiments
<lain>
nice @ recent commits
<azonenberg>
lain: if you pull latest you'll need to have libglfw3-dev installed
<azonenberg>
at this point, we initialize glfw, we make sure that the vulkan device we create is compatible with glfw, and we allocate queues for rendering
<lain>
kk
<azonenberg>
(this has to be done in scopehal because we need the extension list from glfw in order to create the vulkan context)
<azonenberg>
next step is to actually start creating a window and such in the test app
<azonenberg>
lain: also see the CI builds, it seems some of them have also failed wrt glslang headers if memory serves me right
<azonenberg>
there is some discussion on those tickets that may be helpful
<azonenberg>
it seems the SDK is wonky on windows too iirc
<lain>
kk
<_whitenotifier-7>
[scopehal] azonenberg opened issue #682: VulkanInit fails to initialize if the Vulkan loader supports 1.1 or 1.2, but no installed ICD does - https://github.com/glscopeclient/scopehal/issues/682
<_whitenotifier-7>
[scopehal] azonenberg labeled issue #682: VulkanInit fails to initialize if the Vulkan loader supports 1.1 or 1.2, but no installed ICD does - https://github.com/glscopeclient/scopehal/issues/682
<_whitenotifier-7>
[scopehal] azonenberg labeled issue #682: VulkanInit fails to initialize if the Vulkan loader supports 1.1 or 1.2, but no installed ICD does - https://github.com/glscopeclient/scopehal/issues/682
<_whitenotifier-7>
[scopehal] azonenberg assigned issue #682: VulkanInit fails to initialize if the Vulkan loader supports 1.1 or 1.2, but no installed ICD does - https://github.com/glscopeclient/scopehal/issues/682
<azonenberg>
Also, test app (ngscopeclient until we come up with a more permanent name) is now able to create a window with a vulkan surface, and run a glfw event loop. nothing is actually drawn yet
<azonenberg>
So far it's been pretty painless. just lots of reading docs to figure out new libraries
<_whitenotifier-7>
[scopehal] azonenberg b39dbbd - Enable VK_EXT_debug_utils if available. See #680.
<azonenberg>
Also, preliminary simulations suggest that adding a 20 ohm series resistor right near the amplifier input should provide a better impedance match and hopefully remove some of the ripple in the response curve on the AKL-AD4
<azonenberg>
it will have to be an 0201, and i dont have any of those in stock. Ordered them to play with and will update once they arrive
<azonenberg>
spent like $5 on shipping for 75 cents of passives lol
massi has quit [Remote host closed the connection]
<electronic_eel>
none of those fancy rf specced resistors?
<electronic_eel>
they were a few dollar per piece iirc
<azonenberg>
Not for 20 ohms
<azonenberg>
The main point of the fancy rf resistors is to have low parasitic capacitance
<azonenberg>
so that the resistance stays flat over frequency
<azonenberg>
but it takes a LOT of capacitnace to make an appreciable difference in a 20 ohm resistor
<azonenberg>
anyway, my early sim is showing like a 10 dB improvement in return loss at the amplifier input with the resistor
<azonenberg>
which hopefully will flatten out the ripple that i think is due to reflections in the tip area