You are viewing airlied

airlied
airlied
:.:..:.

July 2014
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

airlied [userpic]
whats he building in there....

So some people have noticed I dropped two branches yesterday. One in the ATI driver entitled atombios-support and one in the DRM called r500-support. These are just some recent developments from myself and Alex Deucher to use the atombios in the standard radeon driver, to drive r400, r500 and r600 cards, along with leveraging the radeon acceleration code on the r500 hardware.

So I suppose Q&A time...

1) What does this driver support?
This driver adds atombios support to the current radeon driver. This enables the use of R500 and R600 cards with the current radeon driver. It also uses some atombios functionality on r400 cards.

2) Does it do 2D acceleration?
It provides 2D acceleration both XAA/EXA on r500 cards, and no acceleration at all on r600 class cards. The DRM supports CP (command processor) acceleration on R500 cards (need to add pci ids) which should make the r500 work the same as r300 for 2D acceleration.

3) Does it support 3D?
Not yet. I'm hoping to get some time or someone with some time in the community to port the r300 driver to r500. I've already done an initial patch to the mesa 3D driver to get the framebuffer address correctly, but not even the trivial clear demo draws anything yet. But the r5xx 3D engine is very like the r3xx 3D engine so I suspect it isn't going to be a major effort. I'd like to have compiz on r5xx sooner rather than wait for ever. R600 is not going to be supported anytime soon as it has a completely new 3D engine which requires a new driver from scratch.

4) What about modesetting?
So with Alexs help we've integrated some code from radeonhd to talk to the atombios and calculate the PLLs for these cards. Thanks to SuSE for this work. We are missing one bit where we parse the r600 object tables but this is coming soon, just need to get some time for it. So on r500 we should have full DDC and BIOS parsing support mostly, but for r600 you might find the outputs don't light up yet or DDC doesn't work. I'm also working on the r600 memory controller setup with some info from AMD that was missing from the official docs. We support randr-1.2 interfaces we just need a lot of testing to confirm things work. We also support dual-link TMDS outputs, which I've tested on ajax's 30'inch rigs. On r400 we now support driving the external TMDS chips used on some cards due to the atombios code.

5) Why not radeonhd?
Alex and myself wanted to explore using atombios to drive the card with randr-1.2, as this is what fglrx and ATIs windows drivers do. Having shared code for this area means we should be able to setup stuff exactly like fglrx so if they have a problem we have as well, but we can also use the fact that they fix problems for fglrx/windows drivers a lot more often. At the time radeonhd didn't want to use atombios and didn't have any inkling of randr 1.2 support. I hear randr-1.2 is in the pipeline now but they are against using atombios in any form for actually driving the cards outputs etc. Also when I wrote my driver a few years ago it was a branch of radeon and I really wanted to enable 2D and 3D acceleration on r500 as quickly as possible which I realised meant leveraging off the radeon driver which has DRI and accel support.

6) Future directions?
Well we are going to work with AMD/SuSE to see where we can go next. I'm currently working with AMD to get enough info on the r600 released so we can do 2D acceleration for it using microcode emulation. As the r600 has no regular 2D block we are going to have to init the basics of the 3D engine and use some pre-packed shaders to do 2D accel. These are most likely to be initially just blobs we program into the card. R600 accel will require DRM support also so we will need microcode for the r600. For the r500 3D acceleration should be at least playable with for developers.

7) Legal?
So I've been quiet on the r5xx/r6xx scene since joining Red Hat due to the legal issues with that hardware and a previous NDA I was under. So last week Red Hat and AMD finally agreed on the strategy and am now allowed work on supporting this hardware in public.

I'd like to thank Red Hat for allowing me some time to work on this in between all the other time they let me work on upstream software. Hopefully the customers who care about this will be happy with the result :-), thanks to Alex for working on this for the past few weeks undercover while I've been waiting for legal clearance from RH/AMD legal, thanks to SuSE for releasing radeonhd code and figuring out some of the more niggly aspects of the cards in the PLL setup and the initial atombios interface code. Thanks to AMD for this process of opening up things, when they asked me to advise them on how best to do this 6 months ago I never thought they might actually listen ;-)

Comments
(Anonymous)
Thanks for all your work

Thanks a lot for your hard work on free graphics. People like you make a difference!

(Anonymous)

I don't really get it. Is it not better to co-operate with radeonhd? Is there any sense of working about something that is already being prepared by other open-source team? Are radeonhd developers so problematic in co-operation?

It's great someone work on drivers but I am afraid that time you spend on writing this driver could be used better.

Could you explain how it looks, please?

(Anonymous)
what about RS690?

From what I've read, RS690 (X1200 IGP) are basically RV410 (X700) cards 3D wise. Does that mean there could be 3D support for them soon? Or are additional obstacles to overcome?
In your code, CHIP_FAMILY_RS690 > CHIP_FAMILY_R600

(Anonymous)

way cool,

i'll be checking this out next rainy Sunday.


ochar

(Anonymous)

I tried it on F8 system with X1900XT card - installs & works flawlessly! The only problem I see is that window dragging and switching between windows is a bit laggy sometimes; i.e. when you start dragging some window, it'll lag for a few moments (you can see spike in cpu usage at that moment), then dragging becomes smooth; and switching between windows isn't instant and cpu usage also is a bit high when one does that. Sometimes (though rarely) scrolling produces the same problem, laggy start. Though these are minor issues and mostly acceleration (XAA) works fine.

The only thing that stops me from using this driver is missing xv overlays - and from what I heard, R500/600 don't have the same kind of overlay as previous models - is this true? I.e. xv won't be working untill some descent work would be done and that avivo thing would be supported (something that never happend in fglrx)? Or is it just another buzz from ati and one can utilize colorspace conversion/scaling using old simple ways even on newer cards (at least vidix tries to accomplish something like that)?

Hell. Yes. You guys are awesome.

totally agree, just insane

zed

(Anonymous)

Why do you want to talk to atombios? This seems like a bit of a step backward, compared to the various efforts to do native modesetting in drivers for instance. Or does atombios not actually mean what its name suggests (common enough in marketing terms)?

well AMD use the bios scripts for setting up the card in the BIOS/Windows/fglrx drivers so we are trying to use the same code as they are so we don't have to go fixing bugs everywhere twice..

it isn't like we are doing 16-bit code excection here, we are just reading scripts from the BIOS and running them...

(Anonymous)

To clarify, I'd rather have a working driver that relies on the BIOS than no driver at all. I'd just prefer one that didn't need to use the BIOS.

Awesome

Got this up and going on my Radeon Mobility X1600. Pretty awesome. In just a few months time, the number of driver options have gone from 1 (fglrx) to 4 (radeonhd, ati, avivo).

I posted a patch to the xorg list for the r500-support branch of drm.

(Anonymous)
Thanks

Just a "thank you".

Thanks for your work!
I have mobility Radeon X1700 and it much faster in 2d than fglrx :)
But it uses XAA mode
how to enable EXA?
Option "AccelMethod" "exa" haven't effect.

(Anonymous)
Idetrorce

very interesting, but I don't agree with you
Idetrorce

(Anonymous)
Great news

David, thank you (and Red Hat & contributors) very much for your efforts. I look forward to try out the 6.7.198 version with support for my X1300. It seems almost surreal that in the near future I can use an Open Source driver for my X1300. Compiz support only adds to the joy. Big thanks!

> We also support dual-link TMDS outputs

This is great, and the first time I've seen dual-link DVI support on ATI with free drivers. Could you tell me which card/chipset you tested with so I can go buy one? :)

Thanks!