multitextures

[thenwithexpandedwingshesteershisflight]

can a penumbra map read from multiple textures ? i.e. using opengl's
multitextures. I want to compute one thing on one textures and use the
results in another texture.

[Zach Tellman]

Yes, it uses the same %1, %2 syntax as a normal map function in Clojure.

[thenwithexpandedwingshesteershisflight]

cool. do I have to create the extra textures ? also how do I write to
another texture ? i need to compute on 2 separate textures, but they
each need to read the other's state

[Zach Tellman]

Yes, the input values need to be created/initialized before being
passed into the operator. An operator can also return a vector of
values, which will mean that the operator returns a vector of
textures.

[thenwithexpandedwingshesteershisflight]

ok, finally, can I create a texture without initializing it (from a
vector, as the examples tend to do) ? I would prefer to initialize it
using a shader program rather than sending floats to the gpu

[Zach Tellman]

Yes, you can create a map operator that doesn't have an input texture.
Check out the input-density or input-velocity functions in
https://github.com/ztellman/penumbra/blob/master/test/example/gpgpu/fluid.clj.

[thenwithexpandedwingshesteershisflight]

there's an odd problem i'm having. I have several textures to do work
on, and they each depend on reading their own and another texture's
state, then writing back to their own state. I based the code on your
fluid.clj example and I believe I'm initializing and detroying the
textures correctly and updating them right.
Sometimes it works fine, othertimes it doesn't and the compuations go
awry. It's as if the GPU is being left in a wrong state sometimes and
if I get lucky and roll an even number it'll work, otherwise it won't.
Looking at the ids of the textures I'm using I noticed they often
share the same id - is that id the 'name' of the attachment/texture in
GLSL speak ? I'd expect it to generate a unique attachment/texture
combination for each, otherwise different (defmap ) functions would be
sent the same texture as input - i.e. uniform sampler2DRect _tex0;
uniform sampler2DRect _tex1; <- these would be the same, which would
be bad.

On Oct 31, 4:14 pm, Zach Tellman <ztell...@gmail.com> wrote:
> Yes, you can create a map operator that doesn't have an input texture.

>  Check out the input-density or input-velocity functions inhttps://github.com/ztellman/penumbra/blob/master/test/example/gpgpu/f....

[thenwithexpandedwingshesteershisflight]

in fact I just looked at penumbra.opengl.texture, and it's generating
textures almost every iteration - after the first iteration, none of
the dimensions or other params of my maps change, so surely they
should each become identified with a unique pair of textures (read
from previous state, write to next state) which would be cached and
used throughout ?

On Nov 15, 10:15 am, thenwithexpandedwingshesteershisflight

[Zach Tellman]

When a texture is "generated", it looks in the cache of unused,
pre-existing textures to see if there's one that already has those
dimensions. If so, it will return that texture to be overwritten.

I suspect you're freeing a texture too early, and that it is
non-deterministically being re-allocated and overwritten.

Zach

[thenwithexpandedwingshesteershisflight]

how might I be freeing a texture ?

here's my code:

(defn update [[dt t] state]
(let [dt dt]
(assoc state
:a (if (< t 10.0) (x (:a state)) (y (x (:a state)) (:b state)) )
:b (f4 (:b state) (:a state))
:c (z (:c state) (:a state))
:d (display ((:view-what state) state)) ; this just normalizes the
texture we want to view
)
)
)


(defn reshape [[x y w h] state]
(when (:a state)
(data/destroy! (:a state))
(data/destroy! (:b state))
(data/destroy! (:c state))
(data/destroy! (:d state))
)
(assoc state
:a (reset-a dim)
:b (reset-b dim)
:c (reset-c dim)
:d (reset-c dim)
)
)

[Zach Tellman]

If you don't wrap a texture being passed into a shader program with
square brackets, it's considered "transient" and is freed after the
operation is complete. Notice how in the update function in
fluid.clj, the velocity texture is used twice, and the first time it's
passed in as [velocity].

I know documentation for all this is sparse or nonexistent, and I'm
sorry. I'm perfectly willing to answer any questions you have now or
in the future.

Zach

[thenwithexpandedwingshesteershisflight]

no worries! life goes too fast and you've moved on.

in fluid.clj [velocity] is actually the final reference to velocity -
does the [use of vector] to indicate retain texture have to be used
every time you use that texture in a compuation, or only once per
iteration ? I mean, does it amke any difference if you do it multiple
times per iteration ?

[thenwithexpandedwingshesteershisflight]

one more question: why the nested (let [dt dt] (let [... in
fluid.clj's update function ?

[Zach Tellman]

Each 'velocity' value is used only once, with the exception of the
last, which is used to calculate the density and is then called with
(normalize-velocity ...). To make sure it's not wiped out when
calculating the density, it's surrounded by brackets.

If you have a texture that needs to be used more than once, make sure
it's surrounded in brackets for all but the last usage.

Zach

[thenwithexpandedwingshesteershisflight]

- ignore that last post - I didn't read it properly - it works - the
key is "all but the last usage" because if you [do this] in the final
use then it does slow to a halt. - cheers

[Zach Tellman]

You want to not discard the texture if you still plan to use it ever again. However, when you're creating a new 'a', you're never allowing the old 'a' to get consumed. I assume that's the issue.

Zach

On Nov 15, 2011, at 4:47 PM, thenwithexpandedwingshesteershisflight <math...@gmail.com> wrote:

> the program slows to a halt & takes forever to recover memory after
> quitting if I do that in certain places! I can't see the pattern...
>
> here's an example of when it slows to a halt:
>
> (let
> [
> a (:a state)
> b (:b state)
> c (:c state)
> ]
> (assoc state
> :a (if (< t 1) (g [a]) (g1 (g [a]) c) )
> :b (if (or (< t 2) (:reset state)) a (c1 b [a]) )
> :c (f4 c b)
> )
> )
>
> whereas if I say
>
> :b (if (or (< t 2) (:reset state)) a (c1 b a) )
>
> it runs fine - I don't understand when to [do this]