3

I need to render certain scenes and read the whole image back in main memory. 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

lurscher
  • 25,930
  • 29
  • 122
  • 185
  • thanks for the close vote - any suggestion instead about what would be a better SE to ask? – lurscher Jul 28 '11 at 14:09
  • The people over on gamedev.stackexchange.com will probably be better placed to ask, although I wouldn't have voted to close this myself as it's not strictly gamedev-related either. (Although I think that you need to clarify why you think a slow read is a problem, as this will better inform the answers.) – Kylotan Jul 28 '11 at 14:14
  • slow read-back is a problem because absolute throughput is the main design concern - i think this would not be relevant to gamedev, since i don't intend to develop a game, or even a tool that would be relevant for game developers, in any case, i could try asking there too if i don't get an answer in here – lurscher Jul 28 '11 at 14:15
  • game developers are by far the main people who work with accelerated graphics, and are the main target for the video card manufacturers, so that's where you'll find the experts in that field. As for throughput, it's not clear why your read performance is relevant to throughput - the graphics card is typically an output device (which is why they're optimised for writes at the expense of reads). If future writes are dependent on current reads then it sounds like you're attempting the wrong thing, or using the wrong tools. – Kylotan Jul 28 '11 at 14:21
  • Is the problem the actual duration of the readback? Or that it blocks other processing? (in both cases the answer is most likely: use FBO's, but it makes a difference ...). – KillianDS Jul 28 '11 at 14:33
  • @KillianDS, wouldn't i be losing all the benefits of hardware-acceleration with FBOs? – lurscher Jul 28 '11 at 14:42
  • @lurscher: why should you? FBO's are still built in, you still use the whole GPU pipeline, the result is just your own defined buffer iso the default (back) buffer. Odds are that it's equally fast, up until swapBuffers/glReadBack, but that has little to do with the actual buffer. Small edit: when I'm home and if I have time I'll try to post an example ;). Do you have any dimensions and fps of your readback? – KillianDS Jul 28 '11 at 14:44
  • sorry - i don't have any actual benchmarks yet, i'm just researching and gathering requirements: An example would be great :-) – lurscher Jul 28 '11 at 14:55
  • 1
    this may be helpful: do a search for CUDA pinned memory – kert Aug 11 '11 at 18:05
  • Is there any particular reason why you need to read the graphics buffer back into main memory? – Thomas Sampson Aug 15 '11 at 08:47
  • @Sampson, frame by frame screenshots – lurscher Aug 15 '11 at 13:22

1 Answers1

0

I don't know if the performance would be any different, but you could at least try rendering to an off-screen buffer, then setting that as a texture of a full-screen quad (or outputting that to video in some other way)