Quadbuffered stereo in D3D10 ?
Author
Hey there,
My first post ever in this forum :) Well, as some might know, I'm coming from the evil side (OpenGL), but I'm currently converting a GL based engine to D3D10, mainly due to ATI/AMDs incompetence of delivering functional OpenGL drivers... The conversion was surprisingly painless, and works quite flawlessly. For one exception: quad buffered stereo support.
I'll give a quick explanation for people unfamiliar with the term. The idea is to have two separate framebuffers, both double-buffered, where each one will be displayed on a separate DVI (or double-DVI) output of your graphics card. While rendering your frame, you may specify to which framebuffer the output should go to (typically called left and right). The two or four DVI outputs are then usually connected to a polarization based stereoscopic display or projection system. Both outputs display an excact 1:1 copy of your desktop, except for the quadbuffer-enabled 3D windows, where the left or right framebuffers will be displayed respectively.
So essentially, does anyone know of a way to get such quad buffered stereo in D3D10 ? Has native support been introduced since version 10 ?
Of course, there is a way to fake it (ab)using dual screens. However, this will only work in fullscreen mode, and with a custom (software) mousepointer. Unfortunately, being an industrial visualization application rather than a game, this is not an option for our software.
Any ideas from the D3D pros ?
I'm wondering, is this functionality widely supported in OpenGL? From your description it sounds like there's a very limited context in which it is useful.
Direct3D doesn't support stereo natively, although you can create two different view chains for two different windows and display into them. It still won't duplicate all the other windows automatically (as I said, this sounds like functionality that's not useful in consumer space).
Direct3D doesn't support stereo natively, although you can create two different view chains for two different windows and display into them. It still won't duplicate all the other windows automatically (as I said, this sounds like functionality that's not useful in consumer space).
This seems like something that would most likely be implemented as two adapters, kind of like a dual-head video card. You'd effectively have two devices that you use, one for each of the adapters.
This is, of course, just a guess, since I have absolutely no experience with these kinds of things.
Surely makers of these types of hardware devices document how the system works?
This is, of course, just a guess, since I have absolutely no experience with these kinds of things.
Surely makers of these types of hardware devices document how the system works?
Author
Quote:Original post by ET3D
I'm wondering, is this functionality widely supported in OpenGL? From your description it sounds like there's a very limited context in which it is useful.
It's part of core OpenGL. Hardware support is available on most highend cards from NVidia (Quadro FX line). It's a very commonly used feature in highend CAD systems. These all use OpenGL, but they don't use DX10 style features (which is our main motivation for the D3D port). We'd like to avoid maintaining two different rendering backends.
Quote:
Surely makers of these types of hardware devices document how the system works?
Well, as I mentioned, this feature is supported by all highend NVidia cards (in fact, every dual-DVI Geforce could technically do it, but the feature is not exposed through the driver due to marketing reasons). It's easy to access through OpenGL, but I was wondering if there was a way to access it (or fake it reasonably well) through D3D10.
Honestly, I'd suggest contacting NVIDIA developer support and seeing what they have to say about it. There may be some largely unknown hack to enable it in D3D 10, or it might just not be exposed at all there.
Author
Quote:Original post by Promit
Honestly, I'd suggest contacting NVIDIA developer support and seeing what they have to say about it. There may be some largely unknown hack to enable it in D3D 10, or it might just not be exposed at all there.
That's probably what I'm going to do, but getting a technical response from NVidia within a reasonable delay is, uhm, a challenge... [wink]
I'm not yet familiar with all details of D3D10, as you might imagine, it's only been a couple of weeks I jumped into it. So I was wondering if there was a standard way of doing it that I somehow missed.
There is no support for this out of the box. I expected that not enough (if anyone at all) have asked Microsoft to include this feature.
From my own experience you are the second person who asked for this in the last 5 or more years.
From my own experience you are the second person who asked for this in the last 5 or more years.
There was some sort of stereoscopic viewing option in the DX 7.1a SDK.
But I wasn't interested in it. Besides, I don't even know if what they claimed was actually true stereoscopic viewing. (you'll see... I've never seen it!)
If it's worth mentioning, they used little DX specific content
Try getting a copy of DX 7.1a (samples) and see how they achieved it, and if it can be done in DX 10..... it's a long shot, but better than nothing.
Good luck
Dark Sylinc
Edit: Dont waste your time (more official DX 9.0 though)
Seems you can't do it with a special driver
[Edited by - Matias Goldberg on July 6, 2008 3:16:27 PM]
But I wasn't interested in it. Besides, I don't even know if what they claimed was actually true stereoscopic viewing. (you'll see... I've never seen it!)
If it's worth mentioning, they used little DX specific content
Try getting a copy of DX 7.1a (samples) and see how they achieved it, and if it can be done in DX 10..... it's a long shot, but better than nothing.
Good luck
Dark Sylinc
Edit: Dont waste your time (more official DX 9.0 though)
Seems you can't do it with a special driver
[Edited by - Matias Goldberg on July 6, 2008 3:16:27 PM]
Author
Quote:
Direct3D 9 does not support stereo view, so Direct3D does not use the D3DBACKBUFFER_TYPE_LEFT and D3DBACKBUFFER_TYPE_RIGHT values of this enumerated type.
Damn, that's exactly what I would've needed. I guess this hasn't changed with D3D10 ? That's a shame, because it would've been pretty easy to expose.
Matias: I know about these special stereo drivers, but even if they worked on DX10, they're far too primitive to be useful for us. They're mostly designed to make typical 3D games stereo-like on shutter glasses. We're doing things like IR head tracking and adaptive stereo frustum convergence, so we need full and direct access to the two separate backbuffers.
Oh well, thanks for your help guys. I guess I'll see with NV devrel if they have some kind of undocumented feature somewhere. If not, we'll have to maintain two different rendering backends. Ugh.
I've been working on something similar for the past month or so, we have our opengl wrapper for offaxis projection and stereoscopic view but couldn't do the same in directx9 since there is no quadbuffer.
I found a way to do it, it's not optimal yet but at least it's partially working for now. Basically you have to simulate the quadbuffer.
Our application is a directx wrapper since we're using UT3 for our demo. So we only have access to the surface once it's done rendering. The basics is to have 2 devices in 2 different threads, one for each adapter. You intercept the Present call, copy the backbuffer into memory and then get it with your thread. The application act as a feeder and the thread is the renderer. We had to be at 96Hz so when the application isn't capable of feeding the frame fast enough we're reusing the last frame and present it.
So the basics:
- Copy Backbuffer into a surface in the memory
- memcpy that surface into another owned by the second device
- Copy it to the Backbuffer of the second device
- Present
The thread is on the first adapter and the application is on the second, application doesn't present at all, only the thread does.
There is some little tricks to it too. Locking and unlocking surface is taking too long for an application like ours, so I Lock and unlock the mem surface only at the initialization so I can get the rect pointer then use it in the memcpy.
It's not optimal yet, I got to stabilize it because it's losing sync depending on the app framerate but I can get to a constant 96hz with that method. Using directx10 or directx9ex could be better too since you have access to shared surfaces.
I found a way to do it, it's not optimal yet but at least it's partially working for now. Basically you have to simulate the quadbuffer.
Our application is a directx wrapper since we're using UT3 for our demo. So we only have access to the surface once it's done rendering. The basics is to have 2 devices in 2 different threads, one for each adapter. You intercept the Present call, copy the backbuffer into memory and then get it with your thread. The application act as a feeder and the thread is the renderer. We had to be at 96Hz so when the application isn't capable of feeding the frame fast enough we're reusing the last frame and present it.
So the basics:
- Copy Backbuffer into a surface in the memory
- memcpy that surface into another owned by the second device
- Copy it to the Backbuffer of the second device
- Present
The thread is on the first adapter and the application is on the second, application doesn't present at all, only the thread does.
There is some little tricks to it too. Locking and unlocking surface is taking too long for an application like ours, so I Lock and unlock the mem surface only at the initialization so I can get the rect pointer then use it in the memcpy.
It's not optimal yet, I got to stabilize it because it's losing sync depending on the app framerate but I can get to a constant 96hz with that method. Using directx10 or directx9ex could be better too since you have access to shared surfaces.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
