azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
<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 -
<_whitenotifier> [scopehal-docs] azonenberg opened issue #22: Add full text of third party licenses as appropriate -
<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 -
<_whitenotifier> [scopehal-apps] azonenberg labeled issue #298: Look into not requiring GL_ARB_gpu_shader_int64 -
m4ssi has joined #scopehal
<azonenberg> Sooo I feel dirty for writing this
<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]
<_whitenotifier> [scopehal-docs] azonenberg de5c902 - Clarifications to getting-started section
<_whitenotifier> [scopehal-apps] azonenberg pushed 1 commit to master [+3/-0/±3]
<_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 -
juli966 has joined #scopehal
<_whitenotifier> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier> [scopehal-apps] azonenberg 3845945 - Fixed bug in OpenGL extension detection
<_whitenotifier> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_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 -
<_whitenotifier> [scopehal-apps] azonenberg labeled issue #299: Eye pattern gradients on Windows appear to have red/blue switched -
<_whitenotifier> [scopehal-apps] azonenberg labeled issue #299: Eye pattern gradients on Windows appear to have red/blue switched -
<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
<azonenberg> DuncanHaldane: unmolded the latest experiment
<azonenberg> complete success, it's fully cured
<azonenberg> it is, however, far too floppy. I definitely need to switch to a harder rubber for the final version
<azonenberg> and of course i still have to respin the mold with the fatter cavity, proper SMA connector opening, etc
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
nelgau has joined #scopehal
bvernoux has joined #scopehal
<bvernoux> hello
<bvernoux> azonenberg, woo impressive you can run glscopeclient in your Lecroy scope now ;)
<bvernoux> let me try that on my CoreI7 GPU ;)
<bvernoux> If you are interested I have a new laptop Dell Latitude 5550
<bvernoux> I could test it on it
<azonenberg> bvernoux: i could run on the scope before
<azonenberg> then lost the ability when i required int64 on the gpu
<bvernoux> it is CoreI7 Serie10 and it has also Quadro 2000 GFX card
<azonenberg> i've since added a compatibility shader for older GPUs
<azonenberg> as far as performance goes, 2 channels 800K points runs at 20 WFM/s
<azonenberg> fullscreen doesnt work, for reasons unknown
<bvernoux> ha nice
<bvernoux> yes full screen is buggy with windows so far
<bvernoux> but maybe you have other issues on your scope as I'm not sure it is normal WIndows7 ...
<bvernoux> maybe embedded version limited ?
<azonenberg> This is win10
<bvernoux> ha ok
<azonenberg> the HDO is 7 but has too old a gpu to run glscopeclient
<bvernoux> a normal Win10 not a cheaty embedded version limited ?
<bvernoux> I ask that because in paste WIndows Embedded was not normal windows very limited
<azonenberg> You're thinking windows CE
<bvernoux> in fact there was hybrid like CE ;)
<bvernoux> for Windows7 and 10
<azonenberg> This is win 10 enterprise 2016 LTSB
<bvernoux> they have abandonned them since few years
<azonenberg> Running on an i3-6100 with 16GB of RAM
<bvernoux> ha ok
<bvernoux> win10 2016 woo
<bvernoux> 160x build ?
<azonenberg> I dont see an obvious build number
<bvernoux> if you type cmd winver
<azonenberg> anyway, so far the only issue i see running glscopeclient on the scope is that in the eye patterns the red and blue channels are switched
<bvernoux> ha yes I read that something related to RGB ...
<bvernoux> ARGB or RGBA ...
<azonenberg> 1607
<azonenberg> and no normal windows pixel order is BGRA
<bvernoux> 1607 was end of service on April 9, 2019
<azonenberg> but i thought the way i had my texture formats set up that shouldnt have changed anything
<azonenberg> This is LTSB
<azonenberg> so presumably it gets extended support/updates
<bvernoux> ha yes maybe until 2021 ...
<bvernoux> Does Lecroy update their old scope with newer Win10 ?
<azonenberg> This scope came to me with win10
<bvernoux> as IIRC there is no reason you cannot upgrade to latest Win10
<azonenberg> older scopes can be updated but they charge a fair bit for it
<azonenberg> i wouldnt attempt it myself without a hdd backup
<azonenberg> in case i lost cal data or something
<bvernoux> even if newer version consume more and more ram and have tons of bloated apps/services ...
<bvernoux> what a shame this WIndows ...
<bvernoux> I dream of a clean version without all this cheat Cortana, and spy stuff for stat ...
<bvernoux> I see the impact of performance between Win7 & Win10 on my new PC ;)
<bvernoux> WIn7 is so much faster/responsive without all those bloated stuff of Win10
<bvernoux> I do not even speak about Ubuntu it fly ;)
<bvernoux> Do you know if someone have done some tests of glscopeclient with AT Radeon GFX card ?
<bvernoux> In theory it shall work like a charm as they support very well OpenGL
<azonenberg> Not to my knowledge
<azonenberg> but i dont know what hardware everyone here is running
<bvernoux> will be nice to add a Todo Feedback from user on the github
<bvernoux> to report on which computer all work fine at least with demo and sample if they do not have real scope
<bvernoux> will be interesting
<bvernoux> as the future on PC is clearly AMD
<bvernoux> Intel is out of buisness for any innovation since lot of years
<bvernoux> next AMD CPU will use 5nm
<bvernoux> and Serie 5000 already explode all Intel even Xeon
<bvernoux> in multithread and single thread now with better power consumption
<bvernoux> azonenberg, are you sure the issue is not ARGB <=> RGBA ?
<bvernoux> so that mix color as alpha is not at right place
juli966 has quit [Quit: Nettalk6 -]
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]
<_whitenotifier> [scopehal-apps] azonenberg af81b3b - Fixed bug in negative number handling
<_whitenotifier> [scopehal] bvernoux commented on issue #15: Add Picoscope scope driver(s) -
<azonenberg> bvernoux: I have the MSO option, yes
<bvernoux> Ok great
<azonenberg> the qspi used it
<bvernoux> you have 16chan ?
<azonenberg> Yes
<azonenberg> at up to 1.25 Gsps
<bvernoux> ok like Rigol MSO5000 ;)
<bvernoux> even if Rigol5000 is limited to 1GSPS
<bvernoux> DO you have a setup to test max speed on MSO with FPGA ... ?
<bvernoux> I'm searching something to check different Channels up to 16 with test pattern at different speed
<bvernoux> to check cross talk and latency between channels ...
<bvernoux> I have some test pattern on my old OLS board IIRC and DSLogic LA to be checked
<bvernoux> But if you have something it could be interesting mainly to validate things with known/expected pattern
<bvernoux> I see the DSLogic U3Pro16 is not intended to output pattern ...
<bvernoux> only input in their implementation will have been a nice feature to test other LA ;)
<bvernoux> as it can go up to 1GHz as input so I think the same for output
<azonenberg> I do not have such a test setup. LeCroy quotes the sample rate in the GUI though
<bvernoux> which is too slow :(
<azonenberg> you can see it scale as you change the display scale
<azonenberg> they also have a datasheet spec for max skew
<bvernoux> I want something which reach up to 1GSPS as pattern generator
<azonenberg> which is i believe +/- 1 sample
<bvernoux> yes interesting
<bvernoux> do you have pushed it to recover 500MHz Digital ?
<bvernoux> like SDRAM/DDR ?
<bvernoux> it could be a good cheap test pattern for highspeed IO
<bvernoux> like Octal SPI ;)
<azonenberg> The datasheet quotes max 250 Mbps data rates
<azonenberg> i have not attempted to push it harder than that
<azonenberg> i've pushed the analog channels to their limit though :p
<bvernoux> like those HyperRAM
<bvernoux> maybe it is possible to design a cheap board with HyperRAM ;)
<bvernoux> without using costly FPGA ...
<bvernoux> to be used as "test pattern" for HighSpeed LA
<bvernoux> I see OctoSPI on STM32L4+ is limited to SDR 86MHz
<bvernoux> so too slow ;)
<bvernoux> but on newer STM32H7 the MCU run at up to 550MHz ;)
<bvernoux> so Octo Spi can run at >200MHz
<azonenberg> well, i guess i can use a maxwell for that :P
<bvernoux> interesting
<bvernoux> latest STM32H723 support Octo SPI up to 275MHz ;)
<bvernoux> in theory I will like to go up to 500MHz but it is clearly not possible today with OctoSPI and MCU ;)
<bvernoux> so 275MHz could be very interesting too
<bvernoux> but anyway Octo SPI peripheral at 3V are limited to 133MHz so far
<bvernoux> 1.8V device can reach 200MHz
<bvernoux> the good things with such device (SRAM ...) is the pattern is what there is in RAM ;)
<bvernoux> so it is a good hack to test LA ;)
<bvernoux> and with Dual OCTA Spi we can test 16 bits too
maartenBE has quit [Ping timeout: 240 seconds]
juli966 has joined #scopehal
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
maartenBE has joined #scopehal
nelgau has joined #scopehal
<_whitenotifier> [scopehal] zhengbenchang forked the repository -
<_whitenotifier> [scopehal] azonenberg opened issue #382: Add Red Pitaya driver -
<_whitenotifier> [scopehal] azonenberg labeled issue #382: Add Red Pitaya driver -
<_whitenotifier> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4]
<_whitenotifier> [scopehal-apps] azonenberg 87c9190 - Fixed incorrect printing of GL_ARB_gpu_shader_int64 support
<_whitenotifier> [scopehal-apps] azonenberg 72a976b - Updated no-int64 shaders to use uaddCarry for massive simplification
m4ssi has joined #scopehal
<azonenberg> bvernoux: also for future reference, -MS at the end of a lecroy part number means MSO option
balrog has quit [Ping timeout: 240 seconds]
balrog has joined #scopehal