And I don't really understand your answer. I asked one simple question and am getting big answer where you tell me that I don’t understand.Originally Posted by JumpingJack
The key to performance on the video card is the same as when they compress videos as much as possible. You just redraw what needs to be redrawn. Don’t refresh data that hasn’t been changed. This isn’t a problem if there isn’t any action in the game. Having as high FPS then isn’t that important. You don’t want low performance when there is action though and when there is action then much data needs to be processed. When there is action in the game then the need for fast communication is very important. Processors are extremely fast. They mostly sit and wait for data and moving all that data needs to be fast.
If you mean that they write to memory on the motherboard first and then copy memory from there to the GPU that would seem rather stupid. If the call is asynchronous they could get more performance (the processor will only need to wait to copy it to ram) for that command but that is very hard to do because you don’t know when the command is ready (you need synchronization). You have to check that (or the driver). If it is synchronous then you need to wait for two memory transfers for the same data. Also I don’t think that is one improvement compared to prepare buffers on the stack and just send it to allocated data on the video card. Stack data is normally in L1 or L2 (for both amd and intel) cache if it isn’t too big if I am right.
HyperTransport 3.0 is 20.8 GB/s, I have read that they can’t use all that bandwidth on the pc mothterboards for amd but the same goes for the FSB. You need some insane OC to go over 10 GB/s and that is only achieved if data is transferred in long "trains".
That would be very interesting, I looked some before but finding data on speed between cpu and gpu was not easy to find. I did find other data on the speed but it seemed to low to be true for video comunication.
Bookmarks