1
\$\begingroup\$

I need to render certain scenes and read the whole image back in main memory for further processing which is not suitable for rewriting into shaders of CUDA, and saving to disk. I've search for this and it seems that most video cards will accelerate the rendering but the read-back will be very slow. After a bit of research i only found this card mentioning "Hardware-Accelerated Pixel Read-Back"

The other approach would do software rendering and the read-back problem doesn't exist, but then the rendering performance will be bad.

Likely, i will have to implement both in order to be able to find the optimal trade-off, but my question is about what other alternative can i have hardware-wise; i understand Quadro is for modelling and designer market segment, which is precisely the client target of this application, Does this means that i'm not likely to find better pixel read-back performance in other video card lines? i.e: Tesla or Fermi, which don't even have video outputs btw

\$\endgroup\$
1
  • 1
    \$\begingroup\$ To anybody who has or is thinking of closing this as being off-topic - I recommended the poster post this here because this is where most of the high performance rendering experts are going to be. (eg. Compared with StackOverflow.) \$\endgroup\$
    – Kylotan
    Commented Jul 28, 2011 at 18:41

1 Answer 1

Reset to default
1
\$\begingroup\$

We're talking about relative performance here, it's not like suddenly your bitmap gets transferred at baudot speeds back to your main memory. Is it slower than a main RAM copy? Absolutely. Is it slower than software rendering? Absolutely NOT.

Do you need to do this at interactive speeds, 30-60Hz, or is a slower overall throughput an option? What bitmap sizes are you rendering, 4Kx4K will always be slow, 800x600 you could probably even do simple shaders in software at reasonable rates.

If you want comparisons on what's possible in the consumer space, Fraps has spent a lot of time doing compressed captures to disk from video memory http://www.fraps.com/ and if you're trying to get performance that exceeds their limits you're looking at some heavy R&D and probably hardware specific.

\$\endgroup\$
4
  • \$\begingroup\$ interactive speeds are not a hard requirement, however maximise overall throughput (even if the best throughput is not interactive) it is \$\endgroup\$
    – lurscher
    Commented Jul 28, 2011 at 16:19
  • \$\begingroup\$ Your best bet is to triple buffer the rendering. Basically you have one, active output buffer currently being rendered to then a second that's just been page flipped, and finally a third that's queued up to be the next active render buffer. You would pull your data from that third during the time the second is page flipping and the first is getting rendered to. More or less. Disc access, you'll want to cache as many frames as you can before outputting them in a block to help the file system work in the background. \$\endgroup\$
    – Patrick Hughes
    Commented Jul 28, 2011 at 16:54
  • \$\begingroup\$ I thought fraps was uncompressed only? \$\endgroup\$
    – AttackingHobo
    Commented Jul 28, 2011 at 17:26
  • \$\begingroup\$ Fraps does some light compression, nothing major. I mainly bring it up because it's a data point to what kind of data rates are sane because lurscher is doing research. \$\endgroup\$
    – Patrick Hughes
    Commented Jul 28, 2011 at 19:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .