azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
<d1b2> <tnt> Mostly fixed by using eImmediate for swap chain instead of eFIFO, so I guess it's not too bad.
massi has joined #scopehal
<azonenberg> @tnt: interesting
<azonenberg> iirc eImmediate turns off vsync and eFIFO enables vsync
<azonenberg> with no vsync it will be potentially be wasting cpu/gpu rendering faster than the display can keep up, etc
<azonenberg> but it should function
<d1b2> <tnt> Given the above video I posted yesterday, vsync doesn't seem to work anyway 😄
<tnt> I'm wondering if this comes from the haswell driver or if it's because I don't have a composited display.
<tnt> Ah yeah, indeed, intel_gpu_top shows GPU at 80% busy and I can feel the machine being sluggish in anything graphics.
<d1b2> <tnt> Although, not sure it really works at all, because this doesn't look right https://i.imgur.com/C6NS9De.png
massi_ has joined #scopehal
massi has quit [Ping timeout: 252 seconds]
massi_ has quit [Ping timeout: 256 seconds]
massi has joined #scopehal
<azonenberg> that looks fine to me
<azonenberg> your eye just doesnt have enough points in it to be filled out
massi has quit [Remote host closed the connection]
<d1b2> <johnsel> for sure no compositing will be a vsync issue
<d1b2> <johnsel> did you ever implement a non-vsync method of limiting framerate @azonenberg ?
<azonenberg> johnsel: there is a preference under power iirc
<azonenberg> that changes the main event loop to block until a gui event (keystroke/mouse movement) happens or a ~4 Hz timer elapses
<d1b2> <johnsel> perhaps making that a command line parameter will be useful
<d1b2> <johnsel> and @tnt give enabling that a shot
<azonenberg> i dont want to add too many hacks for working on ancient GPUs that dont support vulkan
<azonenberg> (this is also only limiting framerate, it still uses eFIFO for rendering aka vsync as well)
<azonenberg> what this pref does is avoid drawing at 60 Hz if nothing is changing
<azonenberg> it's meant for power saving when on a laptop
<d1b2> <johnsel> sure but in his current setup it should lower the load on the GPU
<azonenberg> yes it will be useful there if he manually patches the code to use eImmediate
<azonenberg> (this feature also as a side effect limits WFM/s)
<d1b2> <johnsel> seems he did, because he has a display
<d1b2> <david.rysk> tnt: what mesa are you on?
<azonenberg> in general though, running on broken vulkan implementations is very far from a priority for dev
<azonenberg> if someone wants to hack it up and get something working, more power to them
<azonenberg> but i cant justify spending dev time to support that
<d1b2> <david.rysk> I can do more testing on my Intel HD 4000 in a few weeks
<d1b2> <johnsel> sure, I just think in general it is a good option to expose to the command line for enabling
<azonenberg> yeah it would be nice to have for benchmarking if nothing else
<azonenberg> (as uncapped framerate is more useful than a constant 60)
<d1b2> <johnsel> yes, indeed. And I would probably build my own frame limiter not driven by vsync, but that's me.
<d1b2> <johnsel> there's a few weird edge cases when vsync skips a frame
<azonenberg> yeah my feature here is meant to limit GPU load to save power
<azonenberg> not to hit a target framerate
<azonenberg> e.g. it renders fast when the mouse is moving and slow when idle
<d1b2> <johnsel> yes I understand, different feature.
<d1b2> <johnsel> I have access to a 4x A100 80GB box for a couple hours
<d1b2> <johnsel> anything requests for things to do with it?
<azonenberg> oh fun. not off the top of my head
<d1b2> <johnsel> yeah I wanted to run the Galactica-120B model. See what all the fuzz about it is. I tried with some smaller boxes but they just did not have enough GPU RAM so they offered me this machine
<d1b2> <johnsel> not sure if it'll lead anything but you can be sure that if I ever have the need I know which company to rent the GPU servers from
<d1b2> <johnsel> for reference, it's LeaderGPU
<d1b2> <tnt> Well if the issue is not the vulkan driver but the fact I'm running a non-composited display, it'll be the same on my new setup because it's also non-composited. But OpenGL has no issue with vsync on both setups.
<tnt> david.rysk: mesa 22.2.3
<d1b2> <david.rysk> Yeah I believe I had better results using arch’s mesa-git (23.0.0 dev)
<d1b2> <david.rysk> This was on ivy bridge which is a generation older than your haswell one
<tnt> I'll try the same non-composited setup on my workstation with a more modern gpu to see if the intel driver is the issue or not.
octorian has quit [Ping timeout: 252 seconds]
octorian_ has joined #scopehal
octorian_ is now known as octorian
bvernoux has joined #scopehal
<tnt> Anyone seen "Error copying file (if different) from "/tmp/sw/scopehal-apps/_build/lib/scopeprotocols/shaders/CMakeFiles/protocolshaders" to "/tmp/sw/scopehal-apps/_build/src/ngscopeclient/shaders". ?
<tnt> Looks like get_target_property(SPIRV_SHADERS protocolshaders SOURCES) isn't working on the ubuntu 20.04 cmake
<tnt> Ok, well after working around that got that built on my workstation with a AMD RX580 GPU. glscopeclient seems to work fine. ngscopeclient froze the whole X display unrecoverably.
<d1b2> <louis> azonenberg:
<d1b2> <louis> RTO64 actually allows multiple concurrent SCPI connections in a useful way
<d1b2> <louis> moves them up in the vendor rankings significantly