AMD's Initial Radeon Driver Changes For Linux 3.12

[CalcProgrammer1]

The main things left for me are CrossFireX, Eyefinity (single large surface mode), and AMD Dual Graphics support. My desktop has dual HD5870's and right now only one works (fine for single monitor gaming though) and my second idles. At least now it idles quietly with 3.11 but I'd like it to actually contribute. Combined with working Eyefinity single surface across 3 displays that would bring up Linux to truly competing with Windows on high end systems. On the mobile front, my laptop has dual graphics (AMD APU 7660G + AMD GPU 7730M) and the 7730M cannot be used by the open driver. It's muxless, so frames are copied from 7730M into the APU to display, but it seems most implementations are written for AMD/nVidia + Intel integrated setups. The fglrx driver does let me use the 7730M but it gets worse performance than the 7660G for some reason, probably a bad frame copy algorithm. Other than those I've been incredibly impressed with the work poured into the open source driver over the past two releases. Running 3.11-rc4 on Debian and I have smooth, excellent 2D performance, hardware accelerated video decoding, and now cool and quiet operation that scales up under load for the best FPS I've ever seen from an open source driver. That's impressive, and I hope the trend of pushing the open driver over the closed one continues, it has so much more potential at this stage.

[agd5f]

Eyefinity (single large surface mode)

That's already supported. randr has always used a single large surface for multi-head.

[droste]

That's already supported. randr has always used a single large surface for multi-head.

This is only per GPU isn't it? I think he wants to use both his GPUs to create a single large surface.

[agd5f]

This is only per GPU isn't it? I think he wants to use both his GPUs to create a single large surface.

The display buffer has to live on the card that's displaying it. Rendering by other cards has to be copied to the card with the display buffer. If you have displays spread across multiple cards, each card has it's own display buffer.

[droste]

Well yes of course.

Scenario:
card A has 2 monitors attached, card B as has 1 attached. I want a single large surface over all the 3 monitors.

This is already possible with zaphod mode, but is moving windows between all monitors possible without xinerama?
AFAIK you still need to enable xinerama if you want to do this.

[agd5f]

Well yes of course.

Scenario:
card A has 2 monitors attached, card B as has 1 attached. I want a single large surface over all the 3 monitors.

This is already possible with zaphod mode, but is moving windows between all monitors possible without xinerama?
AFAIK you still need to enable xinerama if you want to do this.

That's not a single surface then. If you have multiple displays spread across multiple cards, you have multiple surfaces (at least on per card). You need xinerama or some other mechanism to copy windows between surfaces.

[droste]

That's what I was trying to say 1 per GPU and you can't setup this with RandR (e.g. no dynamic setup).

Sure that's not the most seen scenario, but I actually build something like this with 2 GPUs and 10 monitors. Work without any problems in windows

/edit:
The next step is 24 monitors with 4 radeon hd 7950 later this month. I really hope this works

[agd5f]

multi-gpu multi-head is not considered single surface or eyefinity. That was my point. That was what the original question was about.

[droste]

Ah ok, I thought multi-gpu was also under the umbrella of eyefinity. Is there a marketing name for this?

[Luke]

Try driconf

Alex, any chance we could ever see a Radeon Settings Panel / Radeon Control Panel? For display management (multi-monitor) the various DE's handle that themselves, fine, but what about for tuning power settings? Enabling CrossFire if it would ever get written and merged? Fine-tuning MSAA? Changing handling setting of module options? etc etc etc.

Not asking AMD themselves to write it-- there's no reason another contributor couldn't do it. I'm just wondering if the idea has come up already in team talks for the paid staff, or if it's come up on mailing lists, or anywhere else you've noticed.

Driconf already has a lot of those features, works with all the open drivers. You can set up sync to vblank on or off not only globally but for particular applications, same for AA and other image quality and performance variables. With Radeon it is critical to set sync to vblank OFF for games, but you might want it ON for the desktop and all video applications. There is one bug right now: You need to change the driver name in the ~/.drirc file it makes from the name of the driver (r600, etc) to dri2 for it to work.