NVIDIA's 302 Linux Driver Finally Has RandR 1.2/1.3

[RealNC]

The display controllers are isochronous clients of the memory controller, so you can not change the frequency of the memory while the dc does the scanout without distorting pixels on the screen. So to reclock memory you have to wait until the display is in VBlank and do the reclocking in this short timeslice. As soon as you connect two monitors, which always have a slightly different scanout rate (maybe just because of circuit tolerances) the two VBlank periods practically never sync up, so you have no chance to reclock memory without distorting the content of at least one screen. So the driver just goes to the highest mem clock and stays there, to work around this issue.

It's quite amazing that current display technology still tries to emulate CRT displays (it's for compatibility, I suppose), even though TFTs don't need sync at all since there's no electron beam. I wonder if there's any effort going on currently to do away with that and use digital displays in a natural manner, without refresh rates and sync.

[brent]

By the way, I hacked around the problem by changing the performance levels. Just change all presets to the same memory clock and PowerMizer should work even with multiple displays attached. This will not save quite as much power as clocking down everything, but it's an acceptable compromise.

Video BIOS editors like NiBiTor are suitable for hacks like that. Also, you should be aware that this might brick your GPU, make your PC blow up and/or kill a cute kitten.

[Lynxeye]

It's quite amazing that current display technology still tries to emulate CRT displays (it's for compatibility, I suppose), even though TFTs don't need sync at all since there's no electron beam. I wonder if there's any effort going on currently to do away with that and use digital displays in a natural manner, without refresh rates and sync.

It's not that ridiculous if you think about it some more: even modern TFT displays need a full image refresh every time one pixel on the screen changes because they have no internal framebuffer or logic to handle partial updates (smart mobile displays may have this), so the easiest way to do this is to do the scanout at a fixed refresh rate.

Second: your wires are limiting the available bandwidth, for modern screen resolutions you need almost all of those 16,6ms till the next screen refresh to get your image over the wire. So from a hardware POV it's pretty much the same if you call this a digital bandwidth or a mode.

And then the last point: yes, VBlank is a thing originating from the old CRT days, but as I explained it has actual uses cases in a modern display setup. And again the hardware doesn't care if you call this "VBlank" or "the full wire stop after finishing transmitting an image", it has to be there anyway.

So for traditional display setup there simply isn't any need to change anything. Mobile devices have smart displays with internal framebuffer that help to safe memory bandwidth on the host side and may even enable memory reclocking with more than one display, but they cost a lot more than the traditional LCD screen in your monitor.

[RealNC]

I don't think this is entirely correct. TFT monitors do have a framebuffer, on which they perform scaling. It is not possible for a digital display to operate without a framebuffer. They have at least one. And many monitors can actually hold two or more frames. When DFPs were first introduced, I remember reading that they operate this way only because of compatibility, so that current hardware driving CRTs does not need to change much.

So when considering the rest of your explanation, it would seem natural to move page flipping to the monitor. This would eliminate vsync issues in the most optimal way, ridding graphics hardware from quite a big headache.

But of course I'm not very familiar with display technology, so I might be talking nonsense here?

[kazetsukai]

Weird how everyone is so un-optimistic about this... all the ATI/AMD fanboys had to complain about NVIDIA drivers was "No RandR", "Not open source" and "slow 2D". Well, the last one more NVIDIA users complained than AMD users...

What they need to do is get KMS and then Wayland up on their hardware... at this point all signs point to Wayland being the future of the display server on the Linux desktop. My short few Wayland tests have been extremely impressive, "perfect frames" and truly fast stuff.

[johnc]

like what?

I've opened a thread regarding ViewPortIn/Out here: http://www.nvnews.net/vbulletin/showthread.php?t=179892

Yeah when I saw the release notes and it was like "removed this from nvidia-settings... removed that from nvidia-settings...", I began to feel a little uneasy. lol. Hopefully they'll rebuild the GUI options back up in coming releases.

Regarding the 300 series drivers on Windows (still in beta also), check out:

http://www.geforce.com/drivers/results/44246

They have some more info in other places on the site. But mostly FXAA, vSync changes, performance improvements, etc.

[RealNC]

Regarding the 300 series drivers on Windows (still in beta also), check out:

http://www.geforce.com/drivers/results/44246

They have some more info in other places on the site. But mostly FXAA, vSync changes, performance improvements, etc.

That's just the update for the GeForce 600 cards. The new features were introduced a while back in this driver:

http://www.nvidia.com/object/win7-winvista-64bit-301.24-beta-driver.html

[johnc]

That's just the update for the GeForce 600 cards. The new features were introduced a while back in this driver:

http://www.nvidia.com/object/win7-wi...ta-driver.html

Yeah that's what I was referring to. It was just a month ago... I guess that's an eternity in terms of software though.

[enrico.tagliavini]

I have to say that besides I'm not an NVIDIA fan: well done! Missing randr support was really a bad point of your driver. And given AMD supports old hardware a lot shorter then NVIDIA I wonder if I have to switch vendor when I can't buy intel for a reason or another. To be honest I might.