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]