rtPrintf() output not visible when program output redirected to a file

Why isn’t rtPrintf() output showing up when all program output is redirected to a file?

program.exe > out.log 2>&1

I tried disabling buffering but it didn’t help

setvbuf(stdout, NULL, _IONBF, NULL);

Have you enabled device printing and set a print buffer size?


context->setPrintEnabled( true );
context->setPrintBufferSize( 1024 );

Yes. I see the output in the console (when not redirecting to file). I also tried set the buffer to 10 MB.
Does it output to file for you?

Yes, I’ve never had any trouble doing that. I should note that I use linux, though. I don’t know if your problem is with OptiX…

By the way, the output from printf() does show up.
I’m using Win 8.1 Pro x64, Optix 3.6. Tested on 3 different machines (similar config though)

Can any other Windows user verify?

Am I the only one not liking Windows console?

I was chasing yet another bug/weird behavior caused by printfs, use of std::printf within a loop was somehow corrupting buffer access index variable or rtTrace would just crash (REALLY ANNOYING !!), so I switched to rtPrintf. Then I noticed that rtPrintf output appears in the redirect file.

Turns out it shows up only after second launch. And only partially, it sort of “cuts off”, stops in the middle of arbitrary line.

As I mentioned before disabling buffering didn’t help. Flushing the streams after first context launches doesn’t help. std::printf calls from the first launch does show up.

Given that printfs are the primary debugging way it ridiculous how problematic they are. Optix team really should fix that instead of adding more features.

It’s too bad rtPrintfs are giving you a problem. I personally haven’t had trouble with them, but I can understand the frustration. I’ve had related issues, such as callable programs not executing unless there is an empty rtPrintf in there, and other odd things.

One thing though, I wouldn’t say that you should rely on printfs being the primary debugging tool. Maybe these days that’s a fair statement, and truthfully I use them for debugging too, but it wasn’t too long ago we didn’t even have printing from the GPU. It’s a relatively new feature.

A more reliable approach is to save output and/or error messages to a buffer and print it out after the rtTrace, as much of a pain as that may be.

@voldemarz, I’ve had some issues with rtPrintf that might be similar to yours. For one thing, it does tend to cut off in the middle, or intersperse with other printf commands (see https://devtalk.nvidia.com/default/topic/658167/send-rtprintf-to-standard-error-stream/). As far as I can tell, the cut-off isn’t related to the size set by rtContextSetPrintBufferSize.

You mentioned that you were printing from within a loop. When I use rtPrintf within a loop, I tend to get this error:

OptiX Error: Invalid value (Details: Function "_rtContextLaunch2D" caught exception: Error in rtPrintf format string: "", [7995426])

Do you get that also?

I’ve seen multiple other issues as well:

I’m sure I forgot to mention something. I’ve spent more time working around issues and debugging than actual productive work… Basically at this point I don’t really “trust it”.

Well, OptiX is around already for a while and rtPrintf is there from the start, so I’d expect it work correctly by now. Primary way should be single stepping in debugger, but that is not possible unfortunately. :)

I usually see this when multiple rtPrintf() calls follow one another. Could be that its more likely to happen within a loop, a saw a lot of those when debugging then infinite loop mentioned above. I had a macro that was printing spaces depending on trace depth and only then the actual message. It seems that printing same thing twice cause this error

I still occasionally still see this, then I usually switch to std::printf.