AMD Catalyst 14.6 brings Eyefinity with mixed resolutions support

Shouldn't they be more concerned about the actual game and not a test environment for that game. While I understand its importance, there is bigger fish to fry, period :)
 
dragonstongue said:
Shouldn't they be more concerned about the actual game and not a test environment for that game. While I understand its importance, there is bigger fish to fry, period :)
Click to expand...
The CTE represents upcoming builds of the game. I would rather they support the CTE so that problems are caught ahead of time, rather than problems making it into the live game.
 
Rizen said:
The CTE represents upcoming builds of the game. I would rather they support the CTE so that problems are caught ahead of time, rather than problems making it into the live game.
Click to expand...

Seems dice screws up the game and AMD has to go back and fix it. However AMD still has their own issues with drivers, but when it comes to BF4 it's all Dice.
 
Thanks Venomous, that was my point.

DICE/EA has had uber time, and many opportunities to fix the issues with their oh so state of the art engine that they have been now using for years( and for virtually every game they have ever made to have the exact same issues)

Really shouldn't be AMD to blame (nor have to waste their resources) unless it is a hardware specific issue (like for some of the 7k series when first launched they weren't using their memory properly) for virtually all other issue in regards to BF series/games as a whole, the ONLY ones to blame cause it is mostly software causing issues in game balance, hit detection, latency compensation etc, that is DICE/EA, period.

AMD needs to and has to worry about getting great products out there, that are a good cost, good temperatures, much better reference cooling etc If the devs cannot be bothered to provide ongoing support once AMD or even Nvidia did all the hardwork in the first place with hotfixes etc, then people should be sending hatemail to the devs and refuse to support their product.

So again, yes long winded, why should AMD worry about making sure CTE has best drivers, there is thousands of games out there, and in many cases cost as much or more, so no EA/DICE shouldn`t get prime support for anything but Mantle, they have already shown in many ways they really don't care about their fanbase IMO
 
25% boost to Watch_Dogs could be nice. Maybe it'll resolve the speed fluctuations when driving around. It's driving me batty.
 
dragonstongue said:
So again, yes long winded, why should AMD worry about making sure CTE has best drivers, there is thousands of games out there, and in many cases cost as much or more, so no EA/DICE shouldn`t get prime support for anything but Mantle, they have already shown in many ways they really don't care about their fanbase IMO
Click to expand...

Because Nvidia has a CTE profile now

http://www.geforce.com/whats-new/articles/nvidia-geforce-337-88-whql-watch-dog-drivers

And t1gge has stated in the battlelog forums, they have been working with NV and AMD about getting a fix.

t1gge said:
We are looking into fixing this (it's due to our .exe file being named differently, resulting in not getting the driver tweaks for BF4 that is applied normally. We're in contact with nvidia and AMD about this today to get you the same result here as in main game.
Click to expand...
 
It looks like the new eyfinity should theoretically support PLP configurations, as the driver has no clue how the monitors are rotated, it just goes by the horizontal vs vertical pixels. Windows configures the rotation.
 
KazeoHin said:
It looks like the new eyfinity should theoretically support PLP configurations, as the driver has no clue how the monitors are rotated, it just goes by the horizontal vs vertical pixels. Windows configures the rotation.
Click to expand...
It's not that simple. Rotated displays use a completely different set of display timings.

You'll only get "PLP" if you can find a tall-screen monitor that scans from top-to-bottom (in spite of being taller than it is wide). You need a monitor that is NATIVELY 1080x1920.
 
This news makes me very happy. Though I'm not sure if this means I can manually set my side monitors to lower resolution or if all monitors have to run native.

Anyone can clear this up?
 
Yep, just tested these and no PLP support on this one either. :(

I still can't believe that a program made in a back of garage can handle PLP but AMD / nVidia with their software engineer platoons can't make it happen.
 
Last edited:
great news.

i'd love to see some small 2160x1600 monitors.

could then run portrait / landscape / portrait with a 32" 4k monitor in the middle.

[edit] sad, looks like no PLP support after all [/edit]
 
R3MF said:
sad, looks like no PLP support after all
Click to expand...
There is if you can find a monitor that is natively portrait (a display that DOES NOT require rotated display timings to run in portrait orientation).

Not many of those around, but they will work with this new driver.
 
This is freaking awesome, with a simple driver update AMD made the entry price for Eyefinity gaming extremely cheap. Just find a pair of old low max res monitors and use FIT mode. :cool:
 
Lorien said:
This is freaking awesome, with a simple driver update AMD made the entry price for Eyefinity gaming extremely cheap. Just find a pair of old low max res monitors and use FIT mode. :cool:
Click to expand...

Honestly for me, the center should be of the highest quality. I use left and right just for peripheral vision so quality doesn't have to be as important. Your HUD is Reticle is center anyhow. I'm sure others feel they should be of equal performance.
 
Someone please test this out and report back.

Looks like I'll be selling my titan!
 
The Mac said:
I think thats what he meant, the cheapos as satelites..
Click to expand...

This

You can take your current 1920x1080 display and add a pair of $40 1600x900 satellites, in FIT mode you'd end up with a 5120x900 Eyefinity group. Now let's compare:

5120 x 900 = 4608000 Pixels
2560 x 1600 = 4096000 Pixels

Performance will be just a couple of percentage points from 1600P while retaining the increased peripheral vision and other benefits of Eyefinity.
 
Last edited:
Unknown-One said:
It's not that simple. Rotated displays use a completely different set of display timings.
Click to expand...

To my knowledge a display does not know its orientation and is always driven with the same timings.
Its handled entirely by the operation system / graphics driver.
 
Osjur said:
Yep, just tested these and no PLP support on this one either. :(

I still can't believe that a program made in a back of garage can handle PLP but AMD / nVidia with their software engineer platoons can't make it happen.
Click to expand...
Thanks for testing.
I would have gotten an AMD just for PLP with bezel correction.

I guess nVidia doesn't care or wants people to pay extra for their Quadro cards.

AMD on the other hand simply is incompetent.
If their driver was open-source (not saying it should be!) I could and would add PLP support myself.
 
dowant120hz said:
To my knowledge a display does not know its orientation and is always driven with the same timings.
Its handled entirely by the operation system / graphics driver.
Click to expand...
And when you create an Eyefinity group, the OS (and most parts of the graphics driver) only sees one large display. See the problem? Even if timings aren't an issue... suddenly, none of the parts of the system that usually handle rotation can work. Everything was designed to rotate whole-screens, not parts of a single screen.

And if you attempt to brute-force a solution by chopping up the back-buffer and rotating chunks of it before output, you create even more problem. For example, Windows has to use a very different sub-pixel anti-aliasing arrangement when rendering text on a rotated display (because rotating a normal display changes the sub-pixel layout). If you use the brute-force method, you're throwing text with the wrong sub-pixel layout on all of the rotated displays, which will look horribly manged with all kinds of color fringing.

Only solution for that is to disable ClearType and fall back to the older whole-pixel AA method used on Windows 2000 and previous. Problem is, modern versions of Windows still use ClearType for various parts of the UI even when you turn ClearType off. You have to do a few registry hacks to disable ClearType globally (and doing so can cause other problems). There's simply no way to ensure all text will look semi-decent in a PLP setup, at-present.

And THEN you have the issue of keeping all of these displays synced... and how weird tearing is going to look when it occurs horizontally on the center monitor and vertically on the peripheral monitors.

It's really pretty obvious why they haven't implemented PLP support. There are a lot of challenges associated with handling mixed rotations.
 
On Windows 7 ClearType font rendering does not seem to be affected by display rotation either way.
And apart from ClearType I can't think of anything else that would require Windows to know the current display's sub-pixel layout.

Also I don't see any issues with keeping the displays synced as well.
Everything is the same as regular Eyefinity except the rotation of the final images has to be set per display instead of setting it per Eyefinity group.

"chopping up the back-buffer and rotating chunks of it before output" (or whatever they do) is already being done with PPP setups.
 
dowant120hz said:
On Windows 7 ClearType font rendering does not seem to be affected by display rotation either way.
Click to expand...
ClearType only supports landscape and inverted landscape (RGB and BGR). Monitors in Portrait mode should fall back to the older whole-pixel AA method (so as to avoid color-fringing artifacts)

Source: http://msdn.microsoft.com/en-us/library/dd183433(v=vs.85).aspx

dowant120hz said:
And apart from ClearType I can't think of anything else that would require Windows to know the current display's sub-pixel layout.
Click to expand...
Doesn't really matter if everything else is perfect if something as basic as text-rendering is screwed...

dowant120hz said:
Also I don't see any issues with keeping the displays synced as well.
Click to expand...
There's a huge issue with sync. Two of the displays need an additional step (rotation) performed on their output. This adds delay on those monitors.

Output to the center screen will have to be delayed to keep it synced to the sides.

Last time I checked, AMD had no good way of controlling per-display sync delays. Their inability to resolve tearing on v-synced content when using mixed (DP + DP + DVI) outputs is proof enough of that. The slight delay added to the DVI output in a mixed-output Eyefinity group causes the sync to be slightly off, which results in a fixed (or slowly scrolling) tear on the DVI display.

Same thing is likely to happen if they attempt PLP. The odd-display-out (center) will end up with a sync problem.

dowant120hz said:
"chopping up the back-buffer and rotating chunks of it before output" (or whatever they do) is already being done with PPP setups.
Click to expand...
No, it's not...

PPP mode can simply fill the buffer sideways and chop it up for output (The buffer is filled using a flipped axis. No rotation required, and certainly no rotation of specific chunks). Everything is even, everything happens to all outputs simultaneously with the same delays. No adjustments to sync need to be made.

This effectively means that PPP doesn't doesn't have any concept of rotation, as odd as that might sound (the image generates already facing the correct direction). PLP requires that the buffer be handled completely differently from any current Eyefinity mode.
 
Last edited:
You must log in or register to reply here.
Back
Top