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]