XDMA transfers of images on the 290X calculation

Page 3 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

Tempered81

Diamond Member
Jan 29, 2007
6,374
1
81
But there was no good guide to what multistream DP could handle.

....so don't discount the screens running @60HZ

Just some hacks for 60HZ @ 4k and a MST hub. The cards are capable of enormous resolutions like 16,000 x 16,000 60hz, need to bypass limitations of DP, MST, hdmi & the panels themselves.

In the configuration on the monitors in question though they are configured to drive a multi-stream display.

Though I didn't take the PQ321Q apart, I have seen a development board from STMicro and the logic and processing on the system is not insubstantial, with a couple of downscalar boards and quad LVDS connections to the panel itself. Each display head is responsible for half the screen - up to 1920x2160 at 60 Hz.

Because of the odd configuration, I have seen some comments from readers calling what ASUS, Sharp and STMicro are doing a "hack" to get 4K working at 60 Hz refresh rates. While you could label it that way I consider it an innovative use of current technologies - by utilizing the multi-stream technology in a single panel we are able to basically push twice the amount of pixels per second than you would otherwise get in a monitor like this. And the truth is that while DisplayPort 1.2 has the bandwidth to support 4K resolutions at 60 Hz with a single stream, the necessary controllers for that option are not yet available. Because timing controllers needed for that much bandwidth aren't going to ship at all until early to mid 2014 (likely in small quantities) you can expect the tiled display option to be around for some time to come and remain the budget 60 Hz 4K option as well.
http://www.pcper.com/reviews/Displa...w/DisplayPort-12-MST-and-STMicro-Athena-Contr
 

ViRGE

Elite Member, Moderator Emeritus
Oct 9, 1999
31,516
167
106
I tried getting more information on the subject and got confused, but it seems like it can run 4k@60hz through DP and HDMI
http://www.hardocp.com/article/2013/10/23/amd_radeon_r9_290x_video_card_review/4#.UnAiLRCmZqI

But there was no good guide to what multistream DP could handle.

But I found AMD had been doing this before with custom drivers http://www.tested.com/tech/gaming/456899-triple-monitor-4k-gaming-15-billion-pixels-second/ so don't discount the screens running @60HZ
That's off of a 7970 with 4 DisplayPorts, so of course there would be no problem doing 3x4K@60Hz, since you have plenty of ports. 290X doesn't have that many ports, hence the issue.

Quick Math: 4K@60Hz is ~12Gb/sec (3840 x 2160 x 24bpp x 60Hz), not counting the overhead. DP1.2 tops out at 17.2Gb/sec. So you can't drive multiple 4K monitors off of a single DP connection.

Multi-stream DP1.2 meanwhile will top out at 3 displays with the current implementation, and of course you need to have enough bandwidth to drive all of them. That's 3x1080p or 2x1440p.
 
Last edited:

Granseth

Senior member
May 6, 2009
258
0
71
If you read the article from tested.com they state that they run 6x2k2k screens instead of 3x4k, and DVI-D supports 2k2k@60HZ, hdmi supports 2k2k@60HZ, and 3x2k2k@60HZ is 16,7 Gb/sec bandwith and within what DP 1.2 supports.

I'm not saying it's not 3x4k@30HZ though, just pointing out that maybe AMD put some work into having the system run at 60Hz because they have done custom drivers with that purpose before.

For us normal users it seems like 2x4k@60HZ is the best we can hope for.
 

BrightCandle

Diamond Member
Mar 15, 2007
4,762
0
76
You're assumption is the secondary and tertiary cards are both sending their display to the primary card at the same time. Do we know that to be true?

All I have done is averaged it over a second, so in practice I have only looked at the total bandwidth needed as if it was uniform and these things didn't collide.

But you do make an interesting point that they may or may not interleave/collide with each other. Having tri-xfire could cause at worst a doubling in transfer latency if they both finish a frame at the same time. Frame pacing it seems is not just about outputting frames evenly but also ensuring good separation of the bus usage as well, because you have a bottleneck on the primary card if they come at the same time. But this might be dealt with using signalling, where the primary card tells the other card its OK to transfer now, allowing it to delay the card that has the younger frame and taking the eldar frame first. But pure speculation on my part about how it could work, chances are its much more complex than that!