How to debug OpenGL patches

Aug 20, 2007 at 4:29pm

How to debug OpenGL patches

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

#33328
Aug 20, 2007 at 4:40pm

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
>

#110891
Aug 20, 2007 at 4:42pm

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 //

http://www.vade.info
abstrakt.vade.info

#110892
Aug 20, 2007 at 5:12pm

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*
>
>
>

#110893

You must be logged in to reply to this topic.