Shortage of AMD HD3D monitors, CES2011 didn't bring much

[DmitryKo]

CES 2011 has come and gone, and there were no new AMD-compatible monitors announced at the show, AFAIK. For now it's only Zalman, iZ3D, Viewsonic V3D241wm-LED (with V3D242vm-LED originally slated for Q1 2011), two notebooks from Lenovo and HP, and two all-in-one PCs from MSI. There are however quite a few Viewsonic DLP projectors to follow in 2011, and of course Mitsubishi DLP TVs and 2010 LCD and plasma 3D TVs are supported in frame-compatible modes.

I wonder when we should see more HD3D-compatible DisplayPort 1.2 monitors from different manufacturers, as AMD was promising? Viewsonic was one of the first to offer a 3D Vision monitor - will others follow, or the "open" 3rd party approach chosen by AMD has no credibility with manufacturers?

[cybereality]

What we need is for some 3rd party to license existing technology (ie from Bit Cauldron) and bring out a universal shutter glass solution that is compatible with all 120Hz PC monitors. Once the hardware is out there it should be fairly easy for AMD and/or iz3D/DDD to incorporate this into their drivers. Right now the AMD HD3D is not really competitive with Nvidia on the PC front and there is no indication they will be in 2011. Really, it would be great if AMD would bring out the glasses themselves and step up to the plate. I could even imagine a scenario where AMD would create a reference model shutter glasses and license it to OEMs (like they do with their video cards). This would mean companies like XFX, MSI, Sapphire, etc. could bring out their own branded HD3D glasses. The companies like Asus, Acer, Sasmung, Viewsonic, etc. that are making 120Hz LCDs would surely want to support this as it would open their product up to a whole new market. The only issue is if Nvidia has forced display manufacturers into some sort of exclusive deal (which wouldn't surprise me).

[Fredz]

Unfortunately DisplayPort 1.2 has not made its way to consumer stereo 3D displays this year as I feared, and I'm really afraid the situation is not going to improve in a forseable future despite your hopes (DmitryKo) for 2011-2012 in a previous topic.

And this CES does also seem to confirm what I feared about AMD/ATI and their 3D initiative, they're still not relevant in this field and don't really seem to show any credible dedication to it. I guess their goal was just to not be completely distanced in the 3D war and just sell some more graphic cards, but without any intent of playing a leading role by winning some battles.

As for the universal glasses, I'd say that the only hope would be if some sort of consensus started to exist between 3D TV makers so they settle on some standard for IR signaling. I don't see any other actor (like glasses manufacturers) being relevant enough to succeed in imposing such a needed standard.

[DmitryKo]

But didn't Bit Cauldron tout themselves as this "universal shutter glasses provider" of sorts, promising multiple OEM deals for their USB and VESA Stereo models? And didn't AMD tout DisplayPort 1.2 and VESA Stereo as the universal shutter glasses standard as opposed to proprietary emitters and wired glasses?

So far, only Monster Cable licensed Bit Cauldron, at their usual "monster" prices and with the additional burden of being an "universal" all-in-one IR and Bluetooth solution for 3DTVs, which I personally do not need as I'm only interested in games, and current HDMI 3D products suffer from the infamous 720p60 limitation. I don't understand this predominant focus on 3D TVs either, since it has been said a million times before that 3D games provide much much more stereoscopic content than all Blu-ray 3D releases and TV programming combined.


Everyone other is using their own proprietary solution, like MSI all-in-one PCs which use AU Optronics technology, and Viewsonic V3D241wm-LED which uses wired glasses, with the promise of built-in "universal" emitter in V3D242wm-LED - but then again, what would it be: IR, Bluetooth, ZigBee, we don't really know, and the level of support is uncertain.

At present, we only know that iZ3D has made licensing deals with Zalman, MSI and ViewSonic, so at least these should get at least some level of support; but what about the two notebooks? Will TriDef support these monitors and PCs, or am I limited to iZ3D only? No answer.

[Fredz]

And didn't AMD tout DisplayPort 1.2 and VESA Stereo as the universal shutter glasses standard as opposed to proprietary emitters and wired glasses?

The VESA stereo connector is just a connecting standard, it doesn't say anything about the type of IR signal that is sent. What's really needed is a standard for the IR sequence so that any glasses can be made compatible, wether the emitter is connected to a VESA stereo port or placed directly inside a TV, monitor or laptop.

[DmitryKo]

The VESA stereo connector is just a connecting standard, it doesn't say anything about the type of IR signal that is sent.

VESA Stereo does define the synchronisation protocol, though it's very simple - basically "on-off" TTL logic, signal ground and +5V DC power. (If it were just a connector, it would be called "3-pin mini-DIN", just like those analog TV outs found in older video cards.)

What's important, VESA Stereo plug allows much tighter sync than what is achieveable with USB-based emitters, since you're directly syncing to the video signal in the exact moment it's being displayed by the panel's controller, not some arbitrary moment the driver somehow guesses as appropriate, so less crosstalk (ghosting). AMD intended to support both approaches though.

What's really needed is a standard for the IR sequence so that any glasses can be made compatible, wether the emitter is connected to a VESA stereo port or placed directly inside a TV, monitor or laptop.

Why IR, most vendors are already switching to RF (Bluetooth, ZigBee, whatever)...

We just need the emitter that plugs into VESA Stereo port; unfortunately the industry is moving away from this freedom of choice...

[Fredz]

VESA Stereo does define the synchronisation protocol, though it's very simple - basically "on-off" TTL logic, signal ground and +5V DC power. (If it were just a connector, it would be called "3-pin mini-DIN", just like those analog TV outs found in older video cards.)

This still doesn't define the IR protocol, it does only tell to the connector which eye the glasses must open or block, as such it's only a connector standard for me. Every glasses manufacturer can design its own protocol or use IR leds with different wavelengths. Heck, even Xpand didn't standardize the IR protocol for their own various implementations of shutter glasses.

What's important, VESA Stereo plug allows much tighter sync than what is achieveable with USB-based emitters, since you're directly syncing to the video signal in the exact moment it's being displayed by the panel's controller, not some arbitrary moment the driver somehow guesses as appropriate, so less crosstalk (ghosting).

Synchronizing the glasses to the vertical refresh is not necessarily the best method, you can't adapt the shuttering to the different delays needed by multiple technologies if you do this. Considering the long experience NVIDIA has in the stereo 3D field (10 years), I guess there is a reason why they did choose a USB emitter with a clock instead of something directly connected to the vertical refresh. Here you can read about the adaptation they did for the SyncMaster 2233RZ to not produce too much ghosting by adjusting the delays, you can't do that if you rely only on the vertical refresh for synchronization :
http://www.xbitlabs.com/articles/multim ... ion_5.html" onclick="window.open(this.href);return false;

Why IR, most vendors are already switching to RF (Bluetooth, ZigBee, whatever)...

You are right, RF would be a better choice (longer range, no light of sight, no interference with remotes or other emitters) but I guess it's more costly since NVIDIA does only use this in their 3D Vision Pro kit which costs $349 for the glasses and $399 for the RF hub. I don't at what price others are selling their RF glasses and emitters though.

We just need the emitter that plugs into VESA Stereo port; unfortunately the industry is moving away from this freedom of choice...

As I said it won't be enough, the real standard shouldn't be only in the connector but in the IR protocol too. I'm not even sure that keeping the old VESA stereo standard is a good idea also, I don't know if it's able to tell the glasses to block both eyes at the same time which is needed for some display technologies (namely LCD).

[DmitryKo]

VESA Stereo does define the synchronisation protocol

This still doesn't define the IR protocol ... the real standard shouldn't be only in the connector but in the IR protocol too.

Tell me please, WHY does it need to? Wired glasses do not need any complex transmission protocol; for wireless glasses, just plug the wireless emitter which does the necessary conversion to whatever transmission technology it uses (IR/optical, radio/microwave, ultrasound, tachyon, whatever).

Synchronizing the glasses to the vertical refresh is not necessarily the best method, you can't adapt the shuttering to the different delays needed by multiple technologies
I don't know if it's able to tell the glasses to block both eyes at the same time which is needed for some display technologies (namely LCD)

And why don't you think the emitter (or the display itself) can't have built-in duty cycle adjustment? All you need is tight sync with the start of the frame, which is best obtained directly from the video signal.

The USB approach has inherent stability problems, iZ3D developers have specifically said that maintaining precise sync is not possible with USB emitter due to various OS issues.

what price others are selling their RF glasses and emitters though

Bit Cauldron glasses (ZigBee) were cited at $150, which is cheaper than IR-based 3D Vision.
BTW Samsung switched to Bluetooh emitters/glasses entirely in their 2011 3DTV line-up.

[Fredz]

Tell me please, WHY does it need to? Wired glasses do not need any complex transmission protocol;

Wired glasses are useless and a thing of the past.

for wireless glasses, just plug the wireless emitter which does the necessary conversion to whatever transmission technology it uses (IR/optical, radio/microwave, ultrasound, tachyon, whatever).

The situation would be a little bit better than today with this solution, ie. you could use any type of glasses with any type of display, but only ONE type of glasses at the same time, not different type of glasses from multiple vendors. To be able to use any type of glasses at the same time you need to standardize the wireless communication between the emitter and the glasses (be it IR, RF or whatever).

And why don't you think the emitter (or the display itself) can't have built-in duty cycle adjustment? All you need is tight sync with the start of the frame, which is best obtained directly from the video signal.

Yes, the emitter can incorporate the duty cycle adjustement, that's what the 3D Vision emitter does already. But how the sync is obtained has no particular importance (VGA DDC, USB, VESA stereo, etc.).

The USB approach has inherent stability problems, iZ3D developers have specifically said that maintaining precise sync is not possible with USB emitter due to various OS issues.

It seems the NVIDIA engineers would differ on this point... Aren't the iZ3D developers the same that are not even able to produce correct hardware page flipping, although the guys from NVIDIA are doing this since 2001. And don't tell me that's because NVIDIA is locking their system, they bought the 3D driver from Elsa who were able to do this in 1999. And I've also shown in other topics that it's doable on Linux and Windows (not complete yet). When you choose an argument from authority try to find a better source...

Bit Cauldron glasses (ZigBee) were cited at $150, which is cheaper than IR-based 3D Vision.
BTW Samsung switched to Bluetooh emitters/glasses entirely in their 2011 3DTV line-up.

3D Vision glasses are available for $149 on NVIDIA's shop and for $115 on many other sites, the ZigBee glasses are not cheaper. What I would also like to know is the cost of the emitter or the glasses + emitter, the only reference I could find was $229 for the kit. On NVIDIA's site the 3D Vision kit is available for $199. Anyway, the costs are quite similar so my original assumption that RF could be a lot more expensive than IR seems indeed wrong. They're still more expensive than IR glassses from 3D TV makers though.

[cybereality]

I don't think this is a technological problem. They have had cheap consumer-level shutter glasses working on all sorts of platforms since the 1980's. Fast-forward 30 years and its like we've gone back in time. Any company with a little bit of capital could bring out these universal shutter glasses in a matter of months. The issue is getting all these companies working together and cooperating, and it doesn't seem like they have any incentive to do so.

[DmitryKo]

And don't tell me that's because NVIDIA is locking their system, they bought the 3D driver from Elsa who were able to do this in 1999. And I've also shown in other topics that it's doable on Linux and Windows (not complete yet). When you choose an argument from authority try to find a better source...

Well, Fredz, thank you for clarifying your position. Believe whatever you want to believe, I won't bother to tell you anything from now on.

[Chiefwinston]

Okay I'll let you guys in on a manufacturing secret. The shutter glasses you see on the market cost somewhere between $5 and $10 to make each pair. And its probable closer to the $5 mark. The current selling price point looks to be $150. All the guys in this to make money like that ratio. And would rather keep it at these margins. There's very little incentive to upset this balance.

cheers everyone

[Likay]

Not only iz3d has problem with shutterglasses drivers (tridef also has). Iz3d have no problem controlling the glasses (they had support for shutterglasses in quite a few earlier drivers but had problems with eyeswaps asa the fps from the game drops too much). The actual problem is finding out which image that's for the moment is rendered in the gpu. Fps drops and whoops it renders two left eyeviews in a row thus breaking the sync. They implemented both blue line, white line, custom line/pattern support in their driver as well but only a very few hardwares supports it though. Am i wrong if i say that all homebrewed shutterdrivers have problems with eyeswap unless using the quadbuffered solution (or using the trick below).
Btw: Have anyone actually tried what the iz3d/interleaved+e-d activator does but in one "driver" (iz3d outputs interleaved to the activator which then splits it into two images thus guarantees that each eye gets the right image)?
This is proven working without any eyeswap at all. Problem is halved resolution but a good coder should be able to get around it.

For "proper" hardware shuttersupport i still think that nvidia are able to do this better since they have access directly to their hardware (they do make the displaydrivers). When i gamed with e-dims + nvidia stereodrivers i never experienced eyeswap which seem to occur in the others i've tried (openstereo by dragon something (sorry but i only remember dragon....) and the iz3d-driver...). It seems like a logic conclusion that nvidia can do this better. Probably not because they're better coders but because they make the drivers.

[Fredz]

Well, Fredz, thank you for clarifying your position. Believe whatever you want to believe, I won't bother to tell you anything from now on.

I'm sorry you take it like that DmitryKo, I was only saying that the iZ3D developers are not the most qualified to talk about low level programming (like synching to an USB port). They've achieved something great with their driver but they lack the skills to write low level drivers to support shutter glasses, page flipping or other things of this kind.

When they say that maintaining precise sync is not possible with USB they ignore the fact that NVIDIA has been doing it for years with their 3D Vision kit and that NaturalPoint also uses USB for head tracking at 120Hz with their TrackIR product.

My answer was maybe a little bit harsh, but that was on purpose, I don't like it when people use arguments from authority as I previously said.

[Fredz]

Iz3d have no problem controlling the glasses (they had support for shutterglasses in quite a few earlier drivers but had problems with eyeswaps asa the fps from the game drops too much). The actual problem is finding out which image that's for the moment is rendered in the gpu. Fps drops and whoops it renders two left eyeviews in a row thus breaking the sync.

It's because they didn't really have shutter glasses support, they only abused some DirectX (and maybe OpenGL) features but those are too limited for this kind of things.

Shutter glasses support needs only three things, that must be done in a WDM driver because you don't have enough rights in a user-land application :
- intercept the vertical retrace (needs to intercept the IRQ of the graphics card) ;
- flip the buffers very fast (hardware page flipping using VGA or GPU specific registers) ;
- send a signal to the glasses (VGA DDC signal using GPU specific registers or any other type of signal like USB, parport, etc.).

For "proper" hardware shuttersupport i still think that nvidia are able to do this better since they have access directly to their hardware (they do make the displaydrivers). (...) It seems like a logic conclusion that nvidia can do this better. Probably not because they're better coders but because they make the drivers.

The only advantage NVIDIA has is that they know the addresses of the registers that can be used for hardware page flipping and VGA DDC signaling. As I said in several previous topics, I've already implemented both these things on NV40 and NV50 generations of their GPUs. So NVIDIA has really no more advantage than anyone else since these informations are already available (found in SofGenLock/Genlock, nvclock and the nv and nouveau NVIDIA drivers for Linux).

[Likay]

I'm a noob at this, agrees, but i'm curious. The explanation you give seems like you indeed is able to implement shuttersupport on hardwarelevel but: This is actually what iz3d also managed to do. But how do you manage the l/r identification from the directx calls (assuming that the stereodrivercode intercepts directx, changes it for stereo and send to the displaydriver). This is what i mean and had explained to me is the problem. You know: Tridef for example also haven't managed proper shuttersupport. I can imagine that reading a 2d-buffer which e-d probably is doing and then extract l+r out of it is a lot easier but the extraction from the buffer to the l+r buffers has to be done on low level.
Nvidia are probably (i assume) changing the dxcalls (or maybe not anymore dxcalls) within their displaydriver which also gives a natural easy way to implement the proper l/r id. E-dimensional probably reads the (2d) buffer which the stereodriver writes and then splits/writes it into two buffers l+r. This is made on low level just as your code but imo it's quite a waste of memoryresources. Maybe this is the way nvidia always did idk.

Now: If iz3d, tridef or anyone else should implement proper shuttersupport it seems like they need to "crack" every different chipsets to implement a proper function. One code that works for one chipset is probably (not necessary since close gen cards might work in a very similar way) useless for another. Then there are also different cardmanufacturers which makes it quite a task with cracking/verifying the function. There has to be a logical explanation but i just can't buy the thing that they and everybody alse trying this are dumb. Maybe you're overtalented?

[Fredz]

But how do you manage the l/r identification from the directx calls (assuming that the stereodrivercode intercepts directx, changes it for stereo and send to the displaydriver).

The driver must be in two parts. The first part is a low level WDM driver that intercepts vertical retraces, flips the two rendered images and send the signals to the glasses. The second part is not a driver (in the WDM sense), it's only an user land application that intercepts Direct3D or OpenGL calls to render the scene twice. The iZ3D and TriDef drivers only do the second part, which is why they can't correctly support shutter glasses.

Then, you have to make these two parts communicate so the WDM driver knows which eyes to open or close. With the technique I've tried it's quite simple since I basically create a virtual screen twice the width of the display, so you've only got to define that the left part will always be for the left eye for example. Then the WDM driver can flip the images and send the signals to the glasses without even knowing that the Direct3D or OpenGL calls are intercepted.

NVIDIA must be using a different technique since in their nvapi they say that to add 3D Vision support for your application you need to create an offscreen render surface twice the width and with an additional line containing a signature. I guess the NVIDIA driver then only scan the video memory to find the address of this surface thanks to the signature, and then modify the zone the CRTC is pointing too to display the correct image at each vertical retrace. As in the technique I used, they only need to define that the left part of this surface is for the left eye for example.

To do that without the 3D Vision driver we should know the registers that are used to modify the address the CRTC is pointing to, since the legacy VGA registers can only work for non-offscreen surfaces.

I think these registers have already been identified for the majority of GPUs since the introduction of Per CRTC pixmaps in RandR for the X Window System under Linux, but some work is needed to extract their values from the different code implementations. I also think that by knowing these registers, windowed stereo would be possible as NVIDIA is doing it with their latest drivers.

I can imagine that reading a 2d-buffer which e-d probably is doing and then extract l+r out of it is a lot easier but the extraction from the buffer to the l+r buffers has to be done on low level.

You don't have to extract anything, you only need to intercept 3D calls and double them so they render the scene two times (one for each eye) using a modified projection matrix (off-axis camera).

Nvidia are probably (i assume) changing the dxcalls (or maybe not anymore dxcalls) within their displaydriver which also gives a natural easy way to implement the proper l/r id.

That's also what the iZ3D and TriDef drivers do, but they are missing the additionnal low level driver to control the glasses and the flipping. I think they only use the DirectX equivalents of glXGetVideoSyncSGI/glXWaitVideoSyncSGI OpenGL calls, but this does only work when your frames are rendered faster than half the frequency of your display. I also had some success using this technique to display stereo images on Linux, since they can be displayed quite fast.

Now: If iz3d, tridef or anyone else should implement proper shuttersupport it seems like they need to "crack" every different chipsets to implement a proper function. One code that works for one chipset is probably (not necessary since close gen cards might work in a very similar way) useless for another. Then there are also different cardmanufacturers which makes it quite a task with cracking/verifying the function.

Yes, you need to find the registers for all the combinations of maker/model graphic cards, but as you said cards of similar generation generally work the same way. For example for VGA DDC the registers are different between the generations of NVIDIA cards I tested (NV30 and NV40), but the code for hardware page flipping did work on any card I tried and should work on any GPU with compatible VGA registers.

There has to be a logical explanation but i just can't buy the thing that they and everybody alse trying this are dumb. Maybe you're overtalented?

I don't say anyone is dumb nor that I'm overtalented - which is quite far from reality - the tests I've implemented are based on already existing code, I didn't invent anything. It's just that it's a different programming paradigm, you need to know (or learn) how to write low-level WDM drivers which is quite different from writing end-user application. It's a lot easier to do in Linux though, that's why I didn't yet implement all these ideas on MS Windows.

[Likay]

Thank you for explaining. I'm a tiny bit wiser. Seems like the biggest obstacles are doing some assembly and the effort to add support for all the different chipsets. Can driverupdates from cardvendors brake shuttersupport using the above method, like changing interrupts (the vertical retrace~vsync? is a softwarebased interrupt yes,no?). There just has to be some major obstacle unsecurity somewhere. Once the assembling is done for all the necessary chipsets there would only be need of an update once a new is out. Shouldn't be a big issue for somebody who do stereodrivers for a living...

[Fredz]

Seems like the biggest obstacles are doing some assembly and the effort to add support for all the different chipsets.

Assembly is not even needed, accessing the registers is just a matter of calling the _outp function with the correct parameters.

As for the different chipsets, on NVIDIA there are not many variations, graphic cards from the GeForce 6 to the latest models use only three different architectures (NV40, NV50, NVC0). So for NVIDIA cards you may only need three different functions to drive VGA DDC glasses for current cards (of less than 10 lines each). I don't know what the situation is on AMD/ATI GPUs but I guess they are also not changing their architectures very often.

For page flipping, I guess the code may work unchanged on any generation of NVIDIA GPUs (tested on two of them) but I didn't have any report from others in the topic where I posted my test application, so I'm not really sure.

Can driverupdates from cardvendors brake shuttersupport using the above method, like changing interrupts (the vertical retrace~vsync? is a softwarebased interrupt yes,no?).

IRQs are hardware interrupts and they have existed for as long as the PC architecture itself. Changing the value of an interrupt is possible and was often done in the past when there were hardware conflicts, but it's no longer necessary now that there is plug & play. To write a driver you'd have to read the value of the IRQ the GPU is connected to anyway, so it's not really a problem.

There just has to be some major obstacle unsecurity somewhere. Once the assembling is done for all the necessary chipsets there would only be need of an update once a new is out. Shouldn't be a big issue for somebody who do stereodrivers for a living...

Yep that's also what I think and I don't understand why no company producing stereo drivers hasn't taken the plunge already.

I tried to write what would be the second part of a stereo driver some years ago (OpenGL on Linux) and it did more or less work for anaglyphs in several games. But I didn't have much incentive to continue that and to incorporate the first part that is need for shutter glasses (page-flipping and VGA DDC) since I'm using very old hardware that is already working quite well in stereo 3D using my Windows hard disk.

I understand that it's less interesting now than it was in the past because the world has moved on with other technologies (VGA -> DVI, HDMI or DisplayPort), but I don't get why no stereo 3D company did try to do that some years ago, before 3D Vision was so ubiquitous.

[ERP]

The issue comes down to buffering both the left and right images and swapping them continually while the next pair is being rendered.
Quad buffered support gives you the ability to do this without having to touch the low level display driver.

The easy (and I use that term losely) way to do this with the NVidia driver, would involve intercepting the intital surface creation, creating a Stereo surface (1 line bigger with the marker in it) and intercepting present (or whatever it's called in this weeks version of DX) and copying the stereo pair into your stereo surface.

NVidias drivers would then deal with the keep swapping the images thing, and the shutter glasses timing because it just sees the stereo surface.

The issue would be having your stereo driver work with the nvidia stereo driver enabled, or in some state that allowed you to still create the stereo surface, it should be doable, otherwise you wouldn't be able to create an application that explicitly renders left and right frames, but I suspect there are hidden issues.

You're certainly not going to get any help from NVidia in doing this and they actively try and stop you by breaking you per driver release.

[cybereality]

Well I am very interested to see something like this happen. As soon as I complete my DIY auto-stereo project, I am going to jump right on this. I think Likay's suggestion actually sounds really good. Referring to running the DDD/iz3D driver in interlaced mode and then having a separate driver to just handle the line-blanking and glasses sync. With that system there should be no way for the eyes to swap or go out of sync. However I am not sure how reliable a software-only line-blanking driver would be (or even if its possible). If something like that could work, though, then maybe a sync-double solution could work as well. So iz3D drivers would be run in side-side/over-under mode @ 60Hz and then this second driver would stretch the images and swap the buffers at 120Hz. Maybe some hardware would have to be built to do this, I don't know. But the idea is that this would allow use of 120Hz LCDs with generic shutter glasses and AMD cards, or even Nvidia cards (but without 3D Vision). I think there is definitely enough talent in this forum to accomplish this if we really all put some serious effort into it.

[Fredz]

Well I am very interested to see something like this happen. As soon as I complete my DIY auto-stereo project, I am going to jump right on this.

Nice, I would be glad to help.

I think Likay's suggestion actually sounds really good. Referring to running the DDD/iz3D driver in interlaced mode and then having a separate driver to just handle the line-blanking and glasses sync. With that system there should be no way for the eyes to swap or go out of sync. However I am not sure how reliable a software-only line-blanking driver would be (or even if its possible).

I don't see how this could work, when the DDD/iZ3D drivers generate an interleaved stereo 3D view the graphics mode is not changed at all, it's still in a progressive mode. In this case you don't have an IRQ between the two half frames but still only after the complete frame that contains the two interleaved images.

If something like that could work, though, then maybe a sync-double solution could work as well. So iz3D drivers would be run in side-side/over-under mode @ 60Hz and then this second driver would stretch the images and swap the buffers at 120Hz. Maybe some hardware would have to be built to do this, I don't know.

Same thing for this, I don't think you can do that without a hardware sync doubler like the eDim one.

But the idea is that this would allow use of 120Hz LCDs with generic shutter glasses and AMD cards, or even Nvidia cards (but without 3D Vision). I think there is definitely enough talent in this forum to accomplish this if we really all put some serious effort into it.

I also think full resolution page flipping could be implemented for most graphic cards without the need of a 3D Vision kit. As I said before the unknown would be how to obtain the IRQ value for the GPU, get the values of the registers for hardware page flipping and VGA DDC if needed (works also for DVI DDC it seems) for different maker/models GPUs and a consistent way accross systems to create a virtual screen on MS Windows (XP, Vista, 7). Support for NVIDIA 3D Vision could probably even be added for non-NVIDIA GPUs, there are already some topics dedicated to this on this forum which showed some success.

[cybereality]

Ok, so I guess software line-blanking doesn't make any sense. Sort of what I figured. It seems that full page-flipping is the only thing worth spending time on anyway. I am not exactly too knowledgeable of low-level programming like this, but I am willing to give it a shot.

Also, somewhat related: Maybe I am reading too deeply into this, but judging from a recent post on the iz3D blog it seems they might be considering bringing out these universal glasses that we all want (read the post and the comments). This could be a very significant move if they did this.

http://forum.iz3d.com/blog/?permalink=3884" onclick="window.open(this.href);return false;