two displays off of one card, if you want to stretch it. This is because a single card has a single instance of a texture or resource, and does not need to sync across to another card, over PCIe. Keeping the two cards in sync is slow, and youd hit a framerate hit faster as the two graphics cards are not using the same vbl/timing to draw, so youd typically get half the framerate. I could be wrong, but this is my understanding. So one issue is drawing sync, the other is resource sync. Neither help, and a single card driving two displays solves both those issues.

The only drawback with using a single card across two displays is you have less VRam per display, but with a high end card, I dont think it should be a huge issue.

Id be curious what the consensus is on this though, as im no expert, and this is knowledge ive picked up from speaking to others.

On Aug 22, 2008, at 11:50 AM, Adrian Ward wrote:


Hi everyone,

I'm planning on running a single 2800x1050 composition across two displays of 1400x1050, most likely via a QCView stretched to the appropriate size.

Does anyone know whether it's better to run two displays off one graphics card, or to have two separate cards running the two displays? I'm not worried much about the CPU load of the QCView and don't really want to wrangle with running the two screens in different threads, this is more about being optimal regarding what is running on the GPU and how resources are transferred across the bus.

I can imagine benefits either way but if anyone has any experience or conclusive knowledge which is better I'd be most grateful.

Thanks!


Ade.

PS. Just finished doing a controlled comparison of different graphics cards for a project I'm working on, and the ATI Radeon HD 2600 XT whoops the NVIDIA's GeForce 8800 GT in terms of overall perceived performance. Thanks to those people who recommended I tried the ATIs, I think we'll be saving money and getting better quality results... w00t!

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected] )
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com

This email sent to [EMAIL PROTECTED]

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to