• Advertisement
Sign in to follow this  

Enabling the video card's second adapter

This topic is 3480 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all Is there a way to enable the second adapter on the video card if there is nothing plugged on it? I'd want to use both adapters on the video card in my d3d application but I don't need to output anything on the second one. For example I can use both of the adapters when I have a screen on both of them, but when I unplug the 2nd screen d3d can't use the second adapter. So is there a way to activate it without anything plugged on it?

Share this post


Link to post
Share on other sites
Advertisement
I suspect not - you're entirely at the mercy of what the driver wants to tell you via API enumerations. It seems reasonable to me for a driver to disable additional adapters if there is no way of presenting to them.

That said, you could look into any public control-panel API's (not sure about Intel/AMD/ATI but Nvidia definitely had something available) to see if there is a way of overriding this behaviour.


hth
Jack

Share this post


Link to post
Share on other sites
that's what I suspected, thanks.

We might do something hardware (I need to do it on 4 computers) like plugging the second outputs on a video matrix or just custom build a connector to simulate a signal to the video card

Share this post


Link to post
Share on other sites
Quote:
Original post by NineYearCycle
This begs the question why render to a display port with no display? I'm sure you must have a reason I'm just curious what it might be?

Andy
Something like offscreen rendering maybe? Or rendering complicated backgrounds to textures and then transferring them to the other card to render as impostors?

Share this post


Link to post
Share on other sites
it's for stereoscopic rendering, I actually posted a thread one month ago:

http://www.gamedev.net/community/forums/topic.asp?topic_id=497292

I've come a long way since then and now it's working in directx9. The only thing is that you need both adapters for it to work (one device per thread, per adapter).

Share this post


Link to post
Share on other sites
Quote:
Original post by Eti307
it's for stereoscopic rendering, I actually posted a thread one month ago:

http://www.gamedev.net/community/forums/topic.asp?topic_id=497292

I've come a long way since then and now it's working in directx9. The only thing is that you need both adapters for it to work (one device per thread, per adapter).


So in this setup you basically have two instances of DirectX devices targetting two different display adapters (vga/dvi ports) but using the same single physical gfx card. Yes?

Hmm, in that case couldn't you just have both adapters target the same adapter? Much like running two DirectX programs simultaneously. They both target a single adapter but have seperate instantiations of the device. Then when you've got the stereoscopic setup running with something plugged into both adapters they simply target the different adapters.

I think I might have mangled the terminology above but hopefully what I'm asking is understandable.

Andy

Share this post


Link to post
Share on other sites
Quote:
Original post by NineYearCycle

So in this setup you basically have two instances of DirectX devices targetting two different display adapters (vga/dvi ports) but using the same single physical gfx card. Yes?


Yes that's right

Quote:
Hmm, in that case couldn't you just have both adapters target the same adapter?


No, the problem is that I have to compensate for the lack of frames by the application by presenting a frame faster than what the application is feeding me. Having 2 devices on the same adapters means that they both use the same Present call, hence one will call present while the other device is drawing something (between begin and endscene) and the application will crash. By having both devices on different adapters they have their own frame buffer so their own present calls.

edit: oh and if you meant the present calls on the second adapter, I'm not actually doing them. I'm hooking the directx present function and instead of presenting something I'm only returning a D3D_OK. That way the second adapter never present anything, only the first adapter receives frame. I only need the second adapter so I can create 2 threads with 2 different framebuffers in fullscreen.

Share this post


Link to post
Share on other sites
Quote:
Original post by Eti307
No, the problem is that I have to compensate for the lack of frames by the application by presenting a frame faster than what the application is feeding me. Having 2 devices on the same adapters means that they both use the same Present call, hence one will call present while the other device is drawing something (between begin and endscene) and the application will crash. By having both devices on different adapters they have their own frame buffer so their own present calls.

edit: oh and if you meant the present calls on the second adapter, I'm not actually doing them. I'm hooking the directx present function and instead of presenting something I'm only returning a D3D_OK. That way the second adapter never present anything, only the first adapter receives frame. I only need the second adapter so I can create 2 threads with 2 different framebuffers in fullscreen.


Will you eventually be doing that present on a real device though? If not, why do you need the 2nd thread and the 2nd framebuffer?

The thing running through my mind with all of this is that for stereoscopic work you're basically rendering a single scene from two viewpoints slightly apart. This is really no different to having multiple viewports in, for example, a 3D editor such as Max it's just that you've placed them relative to each other to generate the desired positioning effect.

What I guess I'm trying to say is that you don't really need to fake an adapter. You just need to render to a seperate "window". You can even use the same device and just render the two viewports sequentially since it sounds like you're targetting a single physical graphics device and it'll be done sequentially anyway.

i.e. this seems like a lot of effort, for no actual benefit.

I'm not trying to discourage your methodolgy as I obviously must be missing something, but tricking DirectX into thinking you've got another device there looks to me to be a waste of time and effort.

Andy

PS: I'll just add that I may be completely wrong with all of this as I'm more of an OpenGL guy, never tried to do dual-head displays either ;) Please forgive my questioning as I'm just trying to understand.

Share this post


Link to post
Share on other sites
To do what you are implying you need quad buffers (OpenGL has that). I can't have multiple windows (or swapchains) since I am in fullscreen. Also, it's not only for stereoscopy it's for offaxis projection (tracking the head and adjusting the projection in consequences. How do you intend to present a constant 96 fps on a single device when you don't control anything other than the directx calls? Keep in mind that I'm hooking directx, I'm not drawing by myself only intercepting the buffer once it's done.

Quote:
Will you eventually be doing that present on a real device though? If not, why do you need the 2nd thread and the 2nd framebuffer?


Because the first device is the hooked device for the application (Unreal Tournament 3 if you want to know) and the second one is the rendering device. The application device will never present, only feed the frames to the rendering device. We then have one device going as fast as it can (the application) and the other vsynced at 96Hz (the rendering).

Quote:
What I guess I'm trying to say is that you don't really need to fake an adapter. You just need to render to a seperate "window". You can even use the same device and just render the two viewports sequentially since it sounds like you're targetting a single physical graphics device and it'll be done sequentially anyway.


You won't be able to get a constant 96fps by doing that with only the application device

I tried a lot of things before I came up with this solution, it's so much complicated doing stereo in DirectX compared to OpenGL since you only have one buffer to work with.

Share this post


Link to post
Share on other sites
Sadly I'm going to have to bow out of this because I'm quite baffled by it :)

Y'see it sounds to me like you might be trying to use the graphics card in a parallel manner, but thats not how it works. Regardless of how many threads you've got running, or framebuffers you're targetting, you've still only got one card and if you can't generate the frames you desire sequentially within a single threaded app' then you also can't do them in a parallel/multi threaded one.

At the moment I'm imagining you've got the UT3 engine rendering a scene, the player avatar is controlled via a head tracked HMD to replace the mouse/keyboard etc(?), you've hooked the d3d DLL for the present call (how are you actually getting the framebuffer btw since this call only starts the rendering that you've "setup"?), and you then take that framebuffer and store it away to be presented on tyhe other device that may or may-not be plugged into the 2nd VGA port on the same gfx card, you present that stored framebuffer to your other device (presumably a HMD) at a constant 96Hz.

Is the above correct? Sorry I'm not being any help if you'd like to leave the discussion here that's fine.

My initial understanding was that you were writing all of the software rather than hooking into an existing application.

Andy

Share this post


Link to post
Share on other sites
Quote:
Y'see it sounds to me like you might be trying to use the graphics card in a parallel manner, but thats not how it works. Regardless of how many threads you've got running, or framebuffers you're targetting, you've still only got one card and if you can't generate the frames you desire sequentially within a single threaded app' then you also can't do them in a parallel/multi threaded one.


I know the numbers of frames will necessarily be the same, the only reason I'm having a parallel thread on another device is to have control over the present calls and to present the last frame stored if the application didn't generate a new frame fast enough

Quote:
At the moment I'm imagining you've got the UT3 engine rendering a scene, the player avatar is controlled via a head tracked HMD to replace the mouse/keyboard etc(?), you've hooked the d3d DLL for the present call (how are you actually getting the framebuffer btw since this call only starts the rendering that you've "setup"?)


I initialize the UT engine device on the second adapter of the videocard. I hook the present call and instead of presenting like the usual I copy the backbuffer and send it to my other device on the first adapter. The rendering device will then update is current right/left frame with the new one and continue to present at 96Hz.

So my rendering thread is on the first adapter (the one we see on the screen) and the game is working on the second. I don't present anything to the second adapter, i just need it so I have 2 devices with different buffers.

And no it is not an HMD it's a CAVE environment (1front, 2 lateral and 1 bottom screen) and we use 4 computers (one rendering each screen) :)

Quote:
and you then take that framebuffer and store it away to be presented on tyhe other device that may or may-not be plugged into the 2nd VGA port on the same gfx card, you present that stored framebuffer to your other device (presumably a HMD) at a constant 96Hz.


I present it to the game window, so basically I override whatever the game is presenting and replace it with my own

Long story short, the idea is now working properly and we can use about any directx9 application/games in 3D in our environment(if we know the good registry for the proj/view matrix in the shader) The only problem is that both of the videocard adapter must be active and we must find enough screens for all of them :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement