How to debug OpenGL patches


    Aug 20 2007 | 4:29 pm
    One of the things I find difficult when working with OpenGL stuff, is
    finding good approaches towards how to debug patches. I often find that
    either it work, and I can see whatever I am attempting at, or one or
    more layers do not show up when rendered. I often wish that I would be
    able to monitor what the signal looks like along the chain from one
    OpenGL object to the next, the way that is so easy to do with ordinary
    Jitter objects. Are there any smart ways of doing this that I have
    missed out on, or other recommended strategies for debugging OpenGL
    processing?
    Thanks,
    Trond

    • Aug 20 2007 | 4:40 pm
      seconded. a reverse jit.gl.texture might be a really useful gl object.
      On Aug 20, 2007, at 12:29 PM, Trond Lossius wrote:
      > One of the things I find difficult when working with OpenGL stuff,
      > is finding good approaches towards how to debug patches. I often
      > find that either it work, and I can see whatever I am attempting
      > at, or one or more layers do not show up when rendered. I often
      > wish that I would be able to monitor what the signal looks like
      > along the chain from one OpenGL object to the next, the way that is
      > so easy to do with ordinary Jitter objects. Are there any smart
      > ways of doing this that I have missed out on, or other recommended
      > strategies for debugging OpenGL processing?
      >
      >
      > Thanks,
      > Trond
      >
    • Aug 20 2007 | 4:42 pm
      One of the not very well known techniques is that texture and slab
      processing let you do inline texture readback to a matrix.
      you can go from
      jit.gl.slab mycontext @file vade.awesome.shader.jxs
      |
      jit.matrix 4 char 320 240
      |
      jit.pwindow
      it seems as though you cant go straight to a pwindow however. I
      sometimes use this to troubleshoot things.
      However, without using slabs/texture processing, you are going to
      have to do a bit of work, and disabled things you dont want to draw.
      This is why I use @automatic 0. You can simply gate any bangs to
      objects you want to disable. They no longer render, and voila, you
      can see what is happening before they are drawn into the buffer.
      On Aug 20, 2007, at 12:29 PM, Trond Lossius wrote:
      > One of the things I find difficult when working with OpenGL stuff,
      > is finding good approaches towards how to debug patches. I often
      > find that either it work, and I can see whatever I am attempting
      > at, or one or more layers do not show up when rendered. I often
      > wish that I would be able to monitor what the signal looks like
      > along the chain from one OpenGL object to the next, the way that is
      > so easy to do with ordinary Jitter objects. Are there any smart
      > ways of doing this that I have missed out on, or other recommended
      > strategies for debugging OpenGL processing?
      >
      >
      > Thanks,
      > Trond
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Aug 20 2007 | 5:12 pm
      Thanks, vade, that's immensely useful.
      Best,
      Trond
      vade wrote:
      > One of the not very well known techniques is that texture and slab
      > processing let you do inline texture readback to a matrix.
      >
      > you can go from
      >
      > jit.gl.slab mycontext @file vade.awesome.shader.jxs
      > |
      > jit.matrix 4 char 320 240
      > |
      > jit.pwindow
      >
      > it seems as though you cant go straight to a pwindow however. I
      > sometimes use this to troubleshoot things.
      >
      > However, without using slabs/texture processing, you are going to have
      > to do a bit of work, and disabled things you dont want to draw.
      >
      > This is why I use @automatic 0. You can simply gate any bangs to objects
      > you want to disable. They no longer render, and voila, you can see what
      > is happening before they are drawn into the buffer.
      >
      >
      > On Aug 20, 2007, at 12:29 PM, Trond Lossius wrote:
      >
      >> One of the things I find difficult when working with OpenGL stuff, is
      >> finding good approaches towards how to debug patches. I often find
      >> that either it work, and I can see whatever I am attempting at, or one
      >> or more layers do not show up when rendered. I often wish that I would
      >> be able to monitor what the signal looks like along the chain from one
      >> OpenGL object to the next, the way that is so easy to do with ordinary
      >> Jitter objects. Are there any smart ways of doing this that I have
      >> missed out on, or other recommended strategies for debugging OpenGL
      >> processing?
      >>
      >>
      >> Thanks,
      >> Trond
      >> jitter@cycling74.com
      >
      > *v a d e //*
      >
      > *www.vade.info*
      > *abstrakt.vade.info*
      >
      >
      >