21:35 <azonenberg> Thinking about what makes sense for accessing signal generators in glscopeclient

21:36 <azonenberg> wrt menu hierarchy etc

21:36 <azonenberg> easiest option would be something under window| but i'm not sure if that makes the most sense

22:13 <azonenberg> balrog: so i just tested running using llvmpipe in a Xen instance with the demo driver

22:13 <azonenberg> (and no gpu acceleration)

22:13 <azonenberg> it was horribly slow but worked

22:13 <azonenberg> (meaning less than 1 FPS rendering)

22:15 <azonenberg> i didnt even have to do an explicit override

22:15 <azonenberg> apparently mesa supports software rendering of compute shaders

23:28 <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

23:29 <azonenberg> which i bet is my JITted shader code

23:30 <XMPPwocky> yeah cs = compute shader, it just calls into llvm's jitted output

23:32 <azonenberg> yeah. so there's no good way to trace from GLSL source out to the jit output right?

23:32 <azonenberg> in order to figure out what part of the shader is the bottleneck?

23:33 <azonenberg> (vtune doesnt even display disassembly for it because it doesn't save a memory image, it just expects to pull code from binaries)

23:33 <azonenberg> but hey, if you don't mind 10 sec per frame glscopeclient runs in a xen instance with no gpu :p

23:34 <azonenberg> ultimately i think we will want to build three different rendering paths

23:34 <azonenberg> a) current compute shader based one

23:34 <azonenberg> b) partially implemented OpenCL based one that needs to be finished

23:34 <azonenberg> c) full cairo fallback

23:35 <azonenberg> keep the opengl compositor as it's trivial

23:35 <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