<azonenberg>
Starting to tinker with the groundwork for an OpenCL based renderer
<azonenberg>
There's going to be an enum based preference to select the GL or CL based renderer
tiltmesenpai[m] has quit [K-Lined]
fridtjof[m] has quit [K-Lined]
sajattack[m] has quit [K-Lined]
mikolajw has quit [K-Lined]
CarlosEDP has quit [K-Lined]
<azonenberg>
and of course i'm stuck trying to find a name for the preference :P
<bvernoux>
azonenberg, interesting what is the advantage of OpenCL vs OpenGL renderer ?
<azonenberg>
bvernoux: three big ones
<azonenberg>
1) It lets us bump the OpenGL version down from the current 4.3 / 4.2 + extensions to probably something 3.x based
<bvernoux>
ha the 1) is very nice
<azonenberg>
Which will allow us to run on way more platforms, possibly even virtual machines
<azonenberg>
as well as macs
<bvernoux>
yes VM will be amazing or even Android phone
<azonenberg>
2) it allows fallback to CPU based OpenCL on lower end platforms without a discrete GPU, etc
<azonenberg>
3) it allows use of oclgrind to find bugs, there's no analogous tool for compute shaders AFAIK
<azonenberg>
At least for now, I plan to support both
<bvernoux>
Ok so it seems it is clearly a good idea to switch to OpenCL
<bvernoux>
Do you think performance will be similar ?
<azonenberg>
I do not plan to switch, I plan to dual stack
<bvernoux>
yes dual stack is even better like that we can choose
<azonenberg>
someone was saying that opengl compute shaders are supported on the open source AMD drivers, I think
<azonenberg>
while opencl is not unless you use the proprietary blob
<azonenberg>
So dual stacking is likely the best route at least for now
<azonenberg>
i might support a CUDA backend eventually too as that might give better performance on nvidia and would also have much better tooling support
<bvernoux>
compute shaders is a real mess on lot of old 3D GFX card
<azonenberg>
nvidia's tools for opencl and compute shaders are poor
<azonenberg>
Yeah
<azonenberg>
oh and also, opencl based filters and rendering can interop better long term
<azonenberg>
without any cross API messes
<azonenberg>
Anyway, at least for now I don't plan to remove the compute shader renderer
JSharp has quit [Ping timeout: 265 seconds]
CarlosEDP has joined #scopehal
sorear has quit [Ping timeout: 264 seconds]
mxshift has quit [Ping timeout: 240 seconds]
_florent_ has quit [Ping timeout: 265 seconds]
elms has quit [Read error: Connection reset by peer]
esden has quit [Read error: Connection reset by peer]
_florent_ has joined #scopehal
sorear has joined #scopehal
mxshift has joined #scopehal
elms has joined #scopehal
esden has joined #scopehal
fridtjof[m] has joined #scopehal
mikolajw has joined #scopehal
tiltmesenpai[m] has joined #scopehal
sajattack[m] has joined #scopehal
JSharp has joined #scopehal
fridtjof[m] has quit [Quit: Client limit exceeded: 20000]
tiltmesenpai[m] has quit [Quit: Client limit exceeded: 20000]
CarlosEDP has quit [Quit: Client limit exceeded: 20000]
massi has quit [Remote host closed the connection]
someone-else has quit [Quit: Connection closed]
<_whitenotifier-1>
[scopehal] azonenberg opened issue #521: eMMC: Decode of 8 bit data path - https://git.io/J1amN
<_whitenotifier-1>
[scopehal] azonenberg labeled issue #521: eMMC: Decode of 8 bit data path - https://git.io/J1amN
CarlosEDP has joined #scopehal
fridtjof[m] has joined #scopehal
tiltmesenpai[m] has joined #scopehal
someone-else has joined #scopehal
<Degi>
I wonder if that extra performance is worth messing with nvidia. Like OpenCL on my GPU already gets about 2.5 TFLOPs based on my tests, while it is advertised with 4 TFLOPs (presumably in CUDA?)
<azonenberg>
well 4 is the peak performance under optimal conditions
<azonenberg>
doesnt mean you can achieve it with anything other than a giant loop full of FMA operations :p
<azonenberg>
just like how the peak flops on an x86 chip is with a giant loop of avx512 fma's
<azonenberg>
and you rarely will hit that with realistic workload
<azonenberg>
My main interest in switching to CL from GL for rendering is easier interop with CL based filters, ability to run on no-compute-shader platforms, and better debuggability with oclgrind
<sorear>
(are you measuring flops for the same precision they're advertising? that's another way they get you...)
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J1aQs
<_whitenotifier-1>
[scopehal] azonenberg a4a94f1 - PicoOscilloscope: multithread digital waveform deduplication
someone-else has quit [Quit: Connection closed]
riv has joined #scopehal
<azonenberg>
ooh ps6000aGetTriggerTimeOffset looks like it does TDC (or interpolation) for me
<azonenberg>
i might have to add support for that soon
bvernoux has quit [Quit: Leaving]
<Degi>
Hm, I think I used float32. Also on my CPU I got like 400 GFLOPs (on its iGPU?)
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J1aj8
<azonenberg>
Is that picosecond,io thing something we have a driver for in mainline>?
<someone-else>
not yet
<azonenberg>
thought so
<azonenberg>
also did you change the theming to not be dark mode?
<azonenberg>
or is something wrong with the theming on your system
<azonenberg>
The icons etc were all configured to look good on a dark background
<someone-else>
just changed it temporarily to light mode
<someone-else>
proper one would need some more work
<azonenberg>
I'm fine with having a light mode theme eventually, but doing it right would require retheming the entire app including the waveform areas
<azonenberg>
mixing them just looks bad, the waveform areas started out dark, so i themed the whole thing around that
<azonenberg>
and that seems to be the general way most test equipment UIs are done
<azonenberg>
long term to do it right we'd want to have a setting under preferences for light/dark mode
<azonenberg>
Feel free to file a ticket so we don't forget about that
<azonenberg>
even if you're not going to work on it right away
<someone-else>
I agree about doing this properly later, that thing on the screenshot is just for my own testing for now
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 4 commits to master [+1/-0/±12] https://git.io/J1VfR
<_whitenotifier-1>
[scopehal-apps] azonenberg 8660813 - PreferenceManager: added initial preference for enabling the future OpenCL accelerated renderer
<_whitenotifier-1>
[scopehal-apps] azonenberg cf6fe3c - Initial detection and sanity checking to figure out whether to use OpenCL or OpenGL rendering
<_whitenotifier-1>
[scopehal-apps] azonenberg 816c4d4 - Renamed OscilloscopeWindow::RemoveHistory() to RemoveProtocolHistoryBefore() to correctly reflect its functionality. Protocol analyzer now correctly deletes all history from waveforms that went off the buffer, rather than keeping one waveform worth of dead packets with no corresponding waveform data.
<azonenberg>
someone-else: you gonna file a ticket or want me to?
<azonenberg>
It's a good thing we should have eventually
<someone-else>
I can file it later or you can if you want it done sooner
<someone-else>
anyway, the point of the screenshot was to prove emitter follower is not so hopeless wrt stability
<riv>
hey what's the cheapest scope i could use with this?
<azonenberg>
riv: as of now, probably rigol ds1000 series?
<riv>
cool ty :)
<azonenberg>
on the ultra low end, we have a pending ticket for using a PC sound card as an AC coupled "oscilloscope"
<azonenberg>
but nobody's sat down to write the driver code yet
<azonenberg>
you can already kinda-sorta do that by recording a WAV file then importing that, but you can't do interactive control that way
<azonenberg>
Siglent 1000 series is i think partially supported, i'm not sure of details as I don't have one
<azonenberg>
I know we have support for most of the midrange siglent scopes
<azonenberg>
someone-else: if you want to send me one of those prototypes I can VNA it to 6 GHz
<azonenberg>
in the future i will be able to do full 2-port S-parameters to 8.5 GHz and S21 to 16 GHz
<someone-else>
azonenberg: sure, I'll send some together with the sampling scope when it's ready
<azonenberg>
What does the tip etc look like? How long is it?
<azonenberg>
The AKL-PT2 is 6 GHz BW, but that's primarily limited by how long the shaft is
<azonenberg>
a shorter, lower loss flex would easily get way beyond that
<Degi>
I wonder how well carbon film resistors could work which you directly deposit on the PCB
<azonenberg>
I looked into it, it was just unreasonably expensive
<someone-else>
azonenberg: don't have a photo handy, but it's just a normal solder-in flex probe with ~2mm between (thin wire) tips and 1-4mm tip length which seem to be a good compromise between convenience and signal integrity
<someone-else>
btw the active probe is much less tolerant to longer tips because of very capacitive (vs mostly resistive) loading
<azonenberg>
Makes sense. and i meant between your RF cable and the resistor
<azonenberg>
how long?
<someone-else>
Degi: could work, but (expensive) smd resistors have better controlled geometry/resistance and are physically smaller (which is important for high bandwidths)
<azonenberg>
i'm actually thinking of starting a new probe project soonish, the AKL-PT5, which will be a fairly small flex "tail" maybe 1" long with a solder-in tip, then a surface mount SMPM connector
<someone-else>
azonenberg: ah, the 50ohm section is ~10cm
<azonenberg>
which will mate to a SMA-SMPM cable
<azonenberg>
the idea being to jump to coax as quickly as possible to maximize bandwidth and reduce losses, since flex tends to be lossy
<Degi>
someone-else: Why are they physically smaller? I mean a PVD coating could have a wide range of possible resistance values and with some simple photolithography < 0.1 mm features should be doable
<someone-else>
azonenberg: sim shows 1.5db or so of attenuation in the flex microstrip at 10GHz which seem acceptable for me
<someone-else>
Degi: I meant the cheap pcb carbon ink printing process; using proper thin/thick film deposition tech would of course produce nice results
<someone-else>
but you can already get the same thing in a packaged form..
<Degi>
Hmm, but you might get a better performance since you could use like a triangular or similar geometry which tapers in such a way that there is no impedance mismatch
<someone-else>
would be useful for something not available off the shelf though like precision RC dividers
<someone-else>
Degi: I think as long resistor width is not too different from the transmission line's exact geometry doesn't matter much
<someone-else>
the smaller it is the more it behaves like a resistor
<Degi>
Hmm, isn't the problem that on one side you have a 500 ohm and on the other a 50 ohm transmission line so they have very different widths?
<someone-else>
500ohm side doesn't have a ground plane so width can be anything
<someone-else>
and it won't be 500ohm anyway
<Degi>
Hmm not really but yeah that makes it a bit more variable I guess
<Degi>
Why not have a ground plane? Would the trace be too thin?