<_whitenotifier-b>
[starshipraider] azonenberg pushed 15 commits to master [+39/-1/±35] https://git.io/JMq31
<_whitenotifier-b>
[starshipraider] azonenberg 3d794a6 - Initial work on AKL-PT5
<_whitenotifier-b>
[starshipraider] azonenberg f87f578 - Added a bunch of AKL-AD3 simulations
<_whitenotifier-b>
[starshipraider] azonenberg dd66f15 - Added a bunch of sma-test simulations
<_whitenotifier-b>
[starshipraider] ... and 12 more commits.
massi has joined #scopehal
someone-else has joined #scopehal
Stephie- has joined #scopehal
Yamakaja_ has joined #scopehal
electronic_eel_ has joined #scopehal
vup2 has joined #scopehal
tnt_ has joined #scopehal
laintree has joined #scopehal
Yamakaja has quit [Ping timeout: 260 seconds]
vup has quit [Ping timeout: 260 seconds]
electronic_eel has quit [Ping timeout: 260 seconds]
lain has quit [Ping timeout: 260 seconds]
Stephie has quit [Ping timeout: 260 seconds]
tnt has quit [Ping timeout: 260 seconds]
someone-else has quit [Quit: Connection closed]
<d1b2>
<dannas> Oh https://www.crowdsupply.com/eevengers/thunderscope looks interesting. Same capabilities as a picoscope but hopefully to a less hefty pricetag. The demo showed some software that didn't make me very excited, but I read on twitter (in a conversation where @azonenberg was also participating) that they intended to use glscopeclient for the host software.
tnt_ is now known as tnt
someone-else has joined #scopehal
<azonenberg>
dannas: yeah the designer of the scope is actually in the discord chat
<azonenberg>
he plans to sponsor development of a libscopehal driver and hopefully even throw some budget our way to fund ongoing development
<d1b2>
<Aleksorsist> Yup, we were a long ways off from where we wanted the software to be, so we're in the process of switching to glscopeclient!
<azonenberg>
yeah glscopeclient is not where i want it to be but it's a heck of a lot closer than nothing
<azonenberg>
In other news some of my recent OpenCL rendering experiments seem to have triggered some GPU issues
<d1b2>
<Aleksorsist> Looking forward to helping it get there, it's already very powerful compared to the 1000-series scopes my project aims to compete with
<azonenberg>
several times, my X server would crash and restart when i terminated a sonnet simulation (wtf)
<azonenberg>
and now glscopeclient is taking several seconds to initialize and i have errors in the x server log
<azonenberg>
i've logged out and in since it happened but not done a full reboot, going to try that in a few minutes
<azonenberg>
aleksorsist: yeah my intention has never been to build tools competitive with rigol
<azonenberg>
i want to take on the big names
<azonenberg>
Which is why you see me adding features like PCIe protocol decoding and jitter decomposition
<azonenberg>
ok rebooting to reset my GPU, then hopping in the shower and doing a bunch of chores around the house. Hoping to spend some time on the OpenCL rendering later today though
<azonenberg>
It's already paying dividends even though it doesn't work though
<azonenberg>
running oclgrind on my early port of the rendering shader found multiple potential out-of-bounds memory accesses that were also present in the compute shader (but went undetected because I had no similar tool for the shader)
<azonenberg>
So now the OpenGL renderer should be more reliable and stable
<d1b2>
<Aleksorsist> That's the best part, the cost for the user is just the hardware, so why shouldn't the software be Tier 1, even for someone's first scope.
electronic_eel_ is now known as electronic_eel
<azonenberg>
Exactly
<someone-else>
azonenberg: do I understand correctly that current OpeGL/upcoming OpenCL rendering is mostly just doing normal polyline rasterization?
<azonenberg>
That's why I get along so well with Pico
<someone-else>
thinking about how much slower a CPU backend could be
<azonenberg>
They're a commercial company making closed source hardware
<azonenberg>
But they give away the software with all features free
<azonenberg>
So they have nothing to lose and everything to gain from supporting glscopeclient
<azonenberg>
someone-else: The CL and GL renderers are both doing raw rasterization, yes. With some optimizations to take into account the fact that the segments are sorted in the X direction
<azonenberg>
and parallelized so i can draw each column of pixels in a separate thread group from the rest (so any kind of iterative algorithm like Bresenham is out - you need to be able to random-access the value of each pixel)
<azonenberg>
A full software fallback would likely be done in Cairo, not running the OpenCL implementation on the CPU
<azonenberg>
But CL on CPU is a start
<azonenberg>
my main reason for doing the CL implementation is to get access to oclgrind so i can debug it more completely, and to run on macs
<azonenberg>
with full acceleration
<someone-else>
azonenberg: so I suppose any existing line rasterization should in principle work for this purpose
<someone-else>
with maybe additional vertex pruning prior to rasterization for large waveforms
<someone-else>
asking since the GPU stability issues seems not to be unresolvable with the current driver infrastructure and a fully-software fallback might be handy to ensure the software is accessible to anybody no matter what their GPU/driver/OS situation is
<someone-else>
I could contribute the CPU backend (if its viability is understood as likely) in a reasonable timeframe
<azonenberg>
Yes, i definitely want a software fallback eventually
<azonenberg>
The new rendering model i'm working on will let you switch renderers based on a preference setting
<azonenberg>
and also include fallback if the one you selected can't be initialized
<someone-else>
azonenberg: great, will look into it after finishing current driver work
massi has quit [Remote host closed the connection]
<azonenberg>
Give me some time to get the CL/GL switch working well
<azonenberg>
I also just found a regression causing a multi-second GPU hang during startup in GL mode with my new bug fix
<azonenberg>
i thought it was a gpu driver problem but it's not
<azonenberg>
my fix for the out of bounds memory apparently causes things to run slowly but only the first frame after startup
<someone-else>
sure
<_whitenotifier-b>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JMOZD
<_whitenotifier-b>
[scopehal-apps] azonenberg 93bc3fb - Continued initial work on OpenCL renderer
<_whitenotifier-b>
[scopehal-apps] azonenberg 1f47d35 - Restructured bounds checks to avoid some performance issues
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+5/-0/±0] https://git.io/JMOnk
<_whitenotifier-b>
[starshipraider] azonenberg e5d4e85 - Added a bunch of AKL-PT5 simulations
someone-else has quit [Ping timeout: 245 seconds]
someone-else has joined #scopehal
someone-else has quit [Quit: Connection closed]
laintree is now known as lain
someone-else has joined #scopehal
someone-else has quit [Remote host closed the connection]