Queue (Texture) mem violation on dual monitor

vvvv beta bug
1

OK, another odd one. But this time it happens on two systems and two different version of Windoze.

If I have a texture queue that eventually feeds into a renderer, where that renderer is on another screen, the queue is dead. Displaying the console (Renderer TTY) finds bunch of access violation messages scrolling away.

This happens with 23 and 25.1, on a Win7 x64 machine, and an XP SP3 machine. Both machines have nVidia cards, a GTX 570 and a GTX 285 respectively, running 275.33 drivers.

The even odder thing, is that on the Win7 system, if I change the 2nd monitor to a lower res one (from 1920x1080 to 1024x768) I do not have the problem. Haven’t tried that on the XP system.

This used to work, so I am suspicious that the new nVidia drivers may be the source; I’m seeing all sorts of other odd behaviors too. I’ll try backing up a few revs, but would like to know if anyone else does or does not see this problem.

Here’s a small and quick test file. Any and all help GREATLY appreciated!

queue_memfail.v4p (5.2 kB)

2

Went back to 270.61, same problem. Hrmph.

3

Hi mediadog, queue(ex9) is buggy. Maybe you could try:

-setting renderer queued to 1920x1080 ?
-sending with S(node) the texture
-avoid to translate renderer connected to 2nd screen

yours ;-)

4

… no text …

queue_workaround_by_joreg.v4p (6.2 kB)

5

Huzzzah! THANK YOU THANK YOU THANK YOU! That workaround, well, works!

Many of my patches use texture queues, and I have been fighting all SORTS of erratic behavior - it had gotten so every time I saved a change I would save it under a different name, because they would so often stop working. Hopefully the memory splatter from this is the culprit, we’ll see.

Thanks again! @karistouf - I had already set the backbuffer to 1920x1080 so the processing in the feedback loop would always be in full def. Thanks for the suggestion in any case.