<azonenberg>
elms: ok so plans changed, i'm back now. I'm not sure a github issue is the best place for it so i'll just summarize here
<azonenberg>
Implementation language: C or C++
<azonenberg>
License: permissive non-copyleft (BSD, MIT, or something along those lines). LGPL is OK if dynamically linked, GPL/AGPL are a hard no
<azonenberg>
Supported platforms: windows/linux at minimum, osx and bsd strongly preferred
<azonenberg>
The only input type we use is 32-bit ieee754 float
<azonenberg>
number of ports is currently always power of two, we pad if necessary. Can range from tiny (say 32 points) out to an entire deep-memory acquisition (hundreds of millions of points)
<azonenberg>
number of points*
<balrog>
azonenberg: generally speaking if software is portable between windows and linux, macos and bsd are trivial ports
<balrog>
maybe not pretty, but fairly trivial
<azonenberg>
Yeah
<azonenberg>
at least for basic stuff, opengl being a big exception :p
<balrog>
macOS has full opengl up to and including v4.1
<balrog>
it's "deprecated" but it's not going away anytime soon
<azonenberg>
yeah and when you need compute shaders
<azonenberg>
you're still screwed :p
<azonenberg>
Hence why we're looking at building a parallel accelerated rendering path in OpenCL
<azonenberg>
which seems to be the most plausible alternative to compute shaders given our constraints
<balrog>
I would instead suggest Vulkan
<balrog>
it looks like MoltenVK has support for Vulkan 1.1 compute shaders
<balrog>
(MoltenVK is a Vulkan shim on top of Metal)
<sorear>
to confirm the plan is simultaneous support of GL4.2 compute shaders and OpenCL for all of the GPU stuff?
<balrog>
that's also the way Linux is going
<balrog>
OpenCL is kinda dead it seems
<azonenberg>
sorear: Only for GPU *rendering*
<azonenberg>
Compositing and final display will remain GL 4.1
<balrog>
I'm seeing more progress with SYCL (which is much more CUDA-like)
<azonenberg>
And accelerated compute will probably be dual tracked OpenCL and CUDA
<balrog>
AMD has a pretty decent implementation of SYCL for their GPUs
<balrog>
tooling is still a mess though
<azonenberg>
balrog: We can't use Vulkan until GTK gets better integration in a GTK version that trickles down to debian stable
<balrog>
azonenberg: ahh, relying on GTK :/
<azonenberg>
So GTK 4.x series which is rpobably not going to happen until the release after the one coming up
<azonenberg>
The only way to avoid THAT would be a complete rewrite of *all* of the GUI logic
<sorear>
is there a reasonably correct and as efficient as possible impl of SYCL for CPUs?
<azonenberg>
Which is a much more involved task than just ripping out a couple of shader invocations and replacing them with opencl equivalents
<azonenberg>
Basically OpenGL is our only option for rendering, and OpenCL and CUDA are our options for compute
<azonenberg>
Right now we don't do any CUDA but i'm planning to try dual tracking CUDA and OpenCL for the compute pipeline because I have all nvidia cards and nvidia's profilers and dev tools for OpenCL are basically nonexistent
<azonenberg>
while for CUDA they're quite decent
<azonenberg>
the kernels will likely be very close copies of one another
<azonenberg>
not sure if i could make them identical enough to just have a script to generate one from the other
<azonenberg>
but certainly very close
<elms>
azonenberg: ok thanks for the summary. Arm, x64, or other to consider optimizing for?
<azonenberg>
Current targets are amd64 and arm64
<azonenberg>
Right now it looks like FFTS is the best baseline to build on
<azonenberg>
Which is what i'm using, but it will need to be updated for AVX/AVX512 instructions
<azonenberg>
and i dont know the status of arm64 for it
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 248 seconds]
Degi_ is now known as Degi
someone--else has joined #scopehal
someone--else has quit [Quit: Connection closed]
someone--else has joined #scopehal
bvernoux has joined #scopehal
esden has quit [*.net *.split]
vup has quit [*.net *.split]
Ekho has quit [*.net *.split]
_whitenotifier-3 has quit [*.net *.split]
lain has quit [*.net *.split]
lain has joined #scopehal
esden has joined #scopehal
vup has joined #scopehal
esden has quit [*.net *.split]
esden has joined #scopehal
Ekho has joined #scopehal
_whitenotifier-7 has joined #scopehal
<_whitenotifier-7>
[scopehal-apps] umarcor opened pull request #363: ci/msys2: FFTS is now available in MSYS2 repos - https://git.io/JGnfF
<_whitenotifier-7>
[scopehal-apps] azonenberg commented on pull request #363: ci/msys2: FFTS is now available in MSYS2 repos - https://git.io/JGnZX
<_whitenotifier-7>
[scopehal-apps] umarcor commented on pull request #363: ci/msys2: FFTS is now available in MSYS2 repos - https://git.io/JGnRJ
<_whitenotifier-7>
[scopehal-apps] azonenberg commented on pull request #363: ci/msys2: FFTS is now available in MSYS2 repos - https://git.io/JGnRu
<_whitenotifier-7>
[scopehal-docs] umarcor opened pull request #30: FFTS is now available on MSYS2 repos - https://git.io/JGnuW
<_whitenotifier-7>
[scopehal-docs] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JGnuw
<_whitenotifier-7>
[scopehal-docs] umarcor d083553 - FFTS is now available on MSYS2 repos
<_whitenotifier-7>
[scopehal-docs] azonenberg 37a6914 - Merge pull request #30 from umarcor/msys2-ffts FFTS is now available on MSYS2 repos
<_whitenotifier-7>
[scopehal-docs] azonenberg closed pull request #30: FFTS is now available on MSYS2 repos - https://git.io/JGnuW
<_whitenotifier-7>
[scopehal-apps] umarcor synchronize pull request #363: ci/msys2: FFTS is now available in MSYS2 repos - https://git.io/JGnfF
<_whitenotifier-7>
[scopehal-apps] umarcor commented on pull request #363: ci/msys2: FFTS is now available in MSYS2 repos - https://git.io/JGnzA
<_whitenotifier-7>
[scopehal-apps] azonenberg closed pull request #363: ci/msys2: FFTS is now available in MSYS2 repos - https://git.io/JGnfF
<_whitenotifier-7>
[scopehal-apps] azonenberg pushed 3 commits to master [+0/-2/±4] https://git.io/JGnV3
<GenTooMan>
wouldn't the board material have just as much an affect?
<azonenberg>
Yes, I'm optimizing for the oshpark stackup
<azonenberg>
Rogers RO4350B has almost the same dielectric constant
<azonenberg>
so as long as the thickness from signal layer to ground plane is the same it will transfer to a high end rogers board
<azonenberg>
For flex, i'll have to tune separately. I bet the AKL-PT2 can be optimized further but it's still good enough for now
<GenTooMan>
if they are using polyimide that should be fairly consistent as long as the thickness is consistent for the material. Then it comes to the number of layers and chrome thickness they use for the flash plating. I assume you are using a 2 layer flex?
<azonenberg>
For the AKL-PT2 yes it's 2 layer flex. I'm pretty happy with performance on them though, the VNA response was quite good
<azonenberg>
the limiting factor on the response there was loss
<azonenberg>
the S21 was flatter than any of the competing probes i looked at
<azonenberg>
If I can improve the connector match a little bit that won't hurt, but it's close now
<GenTooMan>
I remember there is also another issue with using polyimide let me check on that.
<GenTooMan>
it'
<GenTooMan>
the issue I am refering to is a problem with ageing like kevlar has.
<GenTooMan>
here is a paper on it file:///tmp/mozilla_cyberman0/2004_AgingPolyimide_Hillman-Murray.pdf
<GenTooMan>
fudge local download from mozzila can suck