1 |
Hi, |
2 |
|
3 |
On Thu, 09 Jun 2016 23:16:37 +0200 lee wrote: |
4 |
> > As far as I understand your e-mail, you are trying to mux video |
5 |
> > outputs of two GPU cards to a single monitor (excuse me if I'm |
6 |
> > wrong, but it is hard to understand what your hardware is), this is |
7 |
> > also doable if your monitor supports dual input (most modern |
8 |
> > monitors do). This way separate X screens may be used to achive |
9 |
> > your goal. (Xinerama setup is also possible, but GL acceleration |
10 |
> > will be limited to abilities of the weakest card). |
11 |
> |
12 |
> Exactly, but I don't want to use the picture-in-picture feature of the |
13 |
> monitor, and I don't want separate X screens, and I don't have room to |
14 |
> fit another monitor on my desk. |
15 |
> |
16 |
> I simply want to use one of the graphics cards to handle an application |
17 |
> that uses open gl and the other one to play a video. |
18 |
|
19 |
Let's suppose that you connected video outputs of both your cards |
20 |
to the same monitor. It is possible to use single X screen with |
21 |
xinerama here and configure it to mirror outputs on both cards, |
22 |
e.g. (output names may vary depending on hardware): |
23 |
xrandr --output LVDS1 --same-as VGA1 |
24 |
This way you can select using monitor's hardware switch from what |
25 |
input to take picture. So you'll have dual-monitor mirrored output, |
26 |
where both outputs are connected to the same single monitor. |
27 |
|
28 |
But the last time I tried similar scheme, OpenGL acceleration is |
29 |
limited to the lowest card capabilities. This was several years |
30 |
ago, maybe things are changed since and you'll be able to use full |
31 |
power of a newer card. In order to select which card to use you can |
32 |
select xinerama screen (mplayer can do that, not sure about others). |
33 |
|
34 |
> > But honestly I don't get why you need this: if you have a powerful |
35 |
> > GPU and it is not a laptop, where power consumption is critical, |
36 |
> > why just don't use that card? Most cards have multiple outputs, so |
37 |
> > it is not a problem to setup multihead with a single card either. |
38 |
> |
39 |
> The GPU isn't quite powerful enough for some of what I'm doing. |
40 |
> Otherwise, it's a perfectly good card. |
41 |
> |
42 |
> So I need to get a better graphics card, and once I do, it would be a |
43 |
> pity to have the current one laying around uselessly. I wouldn't get |
44 |
> much if I tried to sell it, so I rather keep it in case I need a spare. |
45 |
> Buying another one which is the same, to use SLI, won't help, either. |
46 |
> |
47 |
> IIUC, it takes some processing power to decode a video, so why not use |
48 |
> one of the cards for just that? Multiple cards should be able to work |
49 |
> together. |
50 |
|
51 |
There is a severe problem here: how to multiplex outputs of |
52 |
different cards to the same monitor? Either outputs should be |
53 |
independent (as described above), or single video output should be |
54 |
used and hence one card must write to the buffer of another. |
55 |
|
56 |
It is possible to done this either via SLI (not your case |
57 |
apparently) or PCI Express. The latter solution requires very |
58 |
special driver support (e.g. NVidia Optimus or ATI Hybrid |
59 |
Graphics). AFAIK both of them work only on IGP <-> PCI-E setup, |
60 |
where one card is Integrated Graphics Processor using system |
61 |
memory and another one is powerful (and energy consuming) PCI-E |
62 |
graphics card. On such setup driver allows to transfer display |
63 |
surface from GPU frame buffer, to system RAM mapped for IGP and |
64 |
then IGP is used to display this surface. |
65 |
|
66 |
IOW such solution will not work if you have a couple of fully |
67 |
fledged PCI-E GPU cards with their own memory. In theory it should |
68 |
be possible to rewrite GPU driver in a way that will allow to |
69 |
transfer display surface from one video card RAM to another using |
70 |
PCI-E bus, but no sane developer will do this: coding efforts will |
71 |
be tremendous and benefits are unclear up to the point when PCI-E |
72 |
will be a bottleneck. |
73 |
|
74 |
I still don't understand why you need an older card for a video |
75 |
decoding, since newer one can do this perfectly. |
76 |
|
77 |
Still there is a place to use both cards: GPGPU computing, both |
78 |
cards can be used to run OpenCL or CUDA applications or one card |
79 |
may be used for a vdpau video decoding, while another one will mine |
80 |
you bitcoins :) |
81 |
|
82 |
Be warned however, that if you will use both card for the same |
83 |
GPGPU application (e.g. OpenCL or CUDA), care should be taken to |
84 |
allow asynchronous computing of such application. Since cards will |
85 |
operate on different speeds, memory and number of cores, |
86 |
synchronous application will be faster no more then as twice as the |
87 |
same app on the slowest card, which will be likely slow than runnig |
88 |
the same app only on the fastest card. Also you must remember, then |
89 |
PCI-E is terribly slow compared to in-GPGPU data exchange rate, so |
90 |
it will likely be a bottleneck for your tasks. Of course, most |
91 |
OpenCL/CUDA apps are synchronous and will not be able to run |
92 |
properly on heterogeneous GPGPU setup. |
93 |
|
94 |
So probably your best option will be to use one card solely for |
95 |
GPGPU computing, while another one for rendering and output. |
96 |
Another interesting application is that some codecs (e.g. |
97 |
x264) allow to use OpenCL, though from tests I saw it still gives |
98 |
worse results then vdpau-based decoding. |
99 |
|
100 |
Best regards, |
101 |
Andrew Savchenko |