<d1b2>
<DuncanHaldane> Interesting product - I've had some version of it around but never had to use it before. Interesting to note that it bonds incredibly well to silicone, so your plan with the release agent sounds like a good one. (which release agent are you using?)
<azonenberg>
Polytek Pol-Ease 2500
<azonenberg>
Which was listed as being compatible with platinum cure silicone, and when i did a test pour in a little plastic cup with no acrylic contamination, it worked fine
<azonenberg>
So that. at least, i am fairly confident is not the source of my problems
<d1b2>
<DuncanHaldane> Yeah 2500 is the right one for this.
maartenBE has quit [Ping timeout: 246 seconds]
maartenBE has joined #scopehal
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #scopehal
maartenBE has quit [Ping timeout: 246 seconds]
<azonenberg>
DuncanHaldane: Next attempt is curing now
maartenBE has joined #scopehal
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #scopehal
<_whitenotifier>
[scopehal-apps] CyberpunkDre forked the repository - https://git.io/JI633
<_whitenotifier>
[scopehal-docs] azonenberg opened issue #22: Add full text of third party licenses as appropriate - https://git.io/JI6sF
<azonenberg>
Hmmm
<azonenberg>
So skimming around some OpenGL data dumps, it seems like GL_ARB_gpu_shader_int64 is not well supported on intel integrated graphics, period
<_whitenotifier>
[scopehal-apps] azonenberg opened issue #298: Look into not requiring GL_ARB_gpu_shader_int64 - https://git.io/JI6Wp
<_whitenotifier>
[scopehal-apps] azonenberg labeled issue #298: Look into not requiring GL_ARB_gpu_shader_int64 - https://git.io/JI6Wp
<azonenberg>
But it appears to work. Now I need to make no-int64 forks of the other compute shaders
<azonenberg>
and add code to WaveformArea to dynamically detect presence of GL_ARB_gpu_shader_int64 and load the fast or the ugly shader
<azonenberg>
In case it's not obvious, this is a GLSL function for summing two 64-bit signed integers and returning the result as a 32-bit float, which does not require 64-bit integer support on the GPU
<_whitenotifier>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JI6oB
<_whitenotifier>
[scopehal-docs] azonenberg de5c902 - Clarifications to getting-started section
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+3/-0/±3] https://git.io/JI6o2
<_whitenotifier>
[scopehal-apps] azonenberg 3b4d779 - Added bignum versions of all shaders that depended on GL_ARB_gpu_shader_int64. Fixes #298.
<_whitenotifier>
[scopehal-apps] azonenberg closed issue #298: Look into not requiring GL_ARB_gpu_shader_int64 - https://git.io/JI6Wp
juli966 has joined #scopehal
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JI66E
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JI66S
<_whitenotifier>
[scopehal-apps] azonenberg ff867a4 - Aaand same bug in another spot
m4ssi has quit [Remote host closed the connection]
<tnt>
azonenberg: I'm a bit confused by float f = (float(sum_hi) * 4294967296.0) + float(sum_lo);
<tnt>
I mean, if sum_hi is != 0 then sum_lo won't matter, it's going to be lost in float limited precision.
<_whitenotifier>
[scopehal-apps] azonenberg opened issue #299: Eye pattern gradients on Windows appear to have red/blue switched - https://git.io/JI6iH
<_whitenotifier>
[scopehal-apps] azonenberg labeled issue #299: Eye pattern gradients on Windows appear to have red/blue switched - https://git.io/JI6iH
<_whitenotifier>
[scopehal-apps] azonenberg labeled issue #299: Eye pattern gradients on Windows appear to have red/blue switched - https://git.io/JI6iH
<azonenberg>
tnt: I don't necessarily need >32 bits of precision. the problem is i dont know which 32 bits
<azonenberg>
if you look later in the code, you'll see i multiply this by a scaling factor (basically fs per pixel)
<azonenberg>
it's very plausible i could have a situation in which the high N bits of sum_lo and the low M bits of sum_hi are valid
<azonenberg>
yes, the low bits of sum_lo are lost
<azonenberg>
but that's what happens when you squish femtosecond-accurate timestamps down to pixels for display
<azonenberg>
as you change zoom different bits within the 64 are of interest
<azonenberg>
the offset i'm subtracting in this function ensures that the bits of interest are roughly centered at zero (this is the horizontal scale)
<azonenberg>
also i just pushed a few more fixes past that commit related to the logic that detected 64 bit int support, or lack thereof
<tnt>
mm, right. And wouldn't fp64 have done the trick ? You "only" have 53 bits mantissa (instead of full 64 bits of int64) but that's still like 2.5h at 1Tsps.
<azonenberg>
I considered it, but being able to index samples as integers is really nice when doing signal processing stuff
<azonenberg>
int64 really makes the most sense. this is a backwards compatibility shim i'm only keeping for as long as GPUs without this extension are reasonably common
<azonenberg>
in ten years or so i'll probably get rid of it
nelgau has quit [Remote host closed the connection]
<bvernoux>
azonenberg, how do you have captured the spiflash (you have provided) with your WaveRunner 8404M-MS as you have only 4chan and in this example there is 6 chan captured ?
<bvernoux>
IIRC you do not have MSO options
<bvernoux>
hmm I'm probably wrong as I see in Filter Graph that those channels are Digital Chan
<bvernoux>
so you have the MSO options
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JI6Aa
<_whitenotifier>
[scopehal-apps] azonenberg af81b3b - Fixed bug in negative number handling