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
azonenberg has quit [Ping timeout: 268 seconds]
azonenberg has joined #scopehal
massi has joined #scopehal
bvernoux has joined #scopehal
massi has quit [Remote host closed the connection]
florolf has quit [Remote host closed the connection]
<azonenberg> Thinking about what makes sense for accessing signal generators in glscopeclient
<azonenberg> wrt menu hierarchy etc
<azonenberg> easiest option would be something under window| but i'm not sure if that makes the most sense
florolf has joined #scopehal
bvernoux has quit [Read error: Connection reset by peer]
<azonenberg> balrog: so i just tested running using llvmpipe in a Xen instance with the demo driver
<azonenberg> (and no gpu acceleration)
<azonenberg> it was horribly slow but worked
<azonenberg> (meaning less than 1 FPS rendering)
<azonenberg> i didnt even have to do an explicit override
<azonenberg> apparently mesa supports software rendering of compute shaders
nelgau_ has joined #scopehal
nelgau__ has joined #scopehal
nelgau has quit [Ping timeout: 246 seconds]
nelgau_ has quit [Ping timeout: 268 seconds]
<azonenberg> ok so 96% of total glscopeclient run time in my test in the xen VM is in an unknown function called by cs_exec_fn within swrast_dri.so
<azonenberg> which i bet is my JITted shader code
<XMPPwocky> yeah cs = compute shader, it just calls into llvm's jitted output
<azonenberg> yeah. so there's no good way to trace from GLSL source out to the jit output right?
<azonenberg> in order to figure out what part of the shader is the bottleneck?
<azonenberg> (vtune doesnt even display disassembly for it because it doesn't save a memory image, it just expects to pull code from binaries)
<azonenberg> but hey, if you don't mind 10 sec per frame glscopeclient runs in a xen instance with no gpu :p
<azonenberg> ultimately i think we will want to build three different rendering paths
<azonenberg> a) current compute shader based one
<azonenberg> b) partially implemented OpenCL based one that needs to be finished
<azonenberg> c) full cairo fallback
<azonenberg> keep the opengl compositor as it's trivial
<azonenberg> but it will just be taking three cairo-generated textures (vs two and an opengl generated one like we have now) and compositnig them
GenTooMan has quit [Quit: Leaving]