RadeonHD Driver To Use AtomBIOS

[libv]

I seem to remember a thread about some AMD cards only doing TV-out via NTSC while others only via PAL, and someone saying that they only thing stopping them from outputting via both formats is the AtomBIOS selectively advertising which protocols are allowed.

The NTSC versus PAL thing is indeed limits imposed in the specific atombios implementation for the specific card.

Proponents of AtomBIOS are using the Windows driver and fglrx as examples of existing drivers that already use AtomBIOS. How about Mac OS X -- does it access the registers directly?

We have repetively asked ATI to provide us with information about the apple versions of radeonhd hardware, as most of the long standing bugs are related to apple. We have yet to receive any relevant information.

Don't get me wrong, I really appreciate that AMD is opening up their driver (they are light years ahead of NVidious when it comes to being FOSS-friendly), but the best thing would be to let the open-source X.org drivers know how to use the registers directly.

The free hardware documents are indeed the winner here. But sadly we're straying more and more from our initial proposal to AMD in this respect.

[jeffro-tull]

Not sure I understand about "two versions of the -ati driver". I expect that once kernel modesetting is available all drivers will have the option to use it rather than using the modesetting code built into the X driver. Once the modesetting drm is in common use I expect modesetting in the X driver will pretty much go away and the X server will finally be able to run as regular user code. I expect the modesetting code in the X driver will stay in the source tree for a while, for cases where a drm is not available, although there are relatively few OSes which don't support a drm today.

What do you see as the benefit of direct register programming in a general sense ? The cost to develop and support the code is perhaps 5x as high and there seem to be relatively few cases where it is needed.

yeah, I was in a hurry, on my way away from the computer and posted before I read anywhere near as much as I should have. you can just ignore my previous post.


After reading all the posts in this thread, I understand but still have some concerns. AtomBIOS doesn't seem to do that much, in the grand scheme of things (initialization and modesetting are certainly non-trivial, but other stuff I've read made it seem much more prominent in driver writing). Now I'm thinking "AtomBIOS? What's the big deal? Use it, dammit!"

At the same time, I'm concerned, like others, as to why there will be two drivers. It's like they're using the same means to the same end. Aside from legacy support in one, what will be the difference between the two? Looks like some developers need to kiss and make up.

[drag]

The way I see it.. I don't see any point on not using the Vbios if it's open source and all that. Sure it's written in byte-code and not C, but so what? This vbios stuff isn't dependent on a particular architecture, is it?

Anyways any resources being spent on producing 3D drivers is time well spent. If the vbios solves problems and allows people to concentrate on getting good 3D support then thats a terrific thing.

After all.. That's the reason people buy these cards, isn't it? It's not like anybody really cares that some 2D optimization allows Firefox to render a page imperceptibly faster. If that is all that mattered then everybody would be using Intel cards and not give a crap.

But for some things I want to do having good 3D support is very important.

[bridgman]

so, what you're telling me is that we're going to have two versions of the xf86-video-ati driver?

I can appreciate using the AtomBIOS for initial support. At the same time, I'm with the radeonhd developers in that I would much prefer the driver go straight to the registers. And it just so happens that "ati" uses the former while "radeonhd" does the latter. So it seems the two drivers have unique puproses - one to let people use new cards NOW without fglrx, and one down the road which is "more ideal". I kinda like it that way, even if I don't have money to blow on new video cards every couple months.

Not sure I understand about "two versions of the -ati driver". I expect that once kernel modesetting is available all drivers will have the option to use it rather than using the modesetting code built into the X driver. Once the modesetting drm is in common use I expect modesetting in the X driver will pretty much go away and the X server will finally be able to run as regular user code. I expect the modesetting code in the X driver will stay in the source tree for a while, for cases where a drm is not available, although there are relatively few OSes which don't support a drm today.

What do you see as the benefit of direct register programming in a general sense ? The cost to develop and support the code is perhaps 5x as high and there seem to be relatively few cases where it is needed.

[jeffro-tull]

so, what you're telling me is that we're going to have two versions of the xf86-video-ati driver?

I can appreciate using the AtomBIOS for initial support. At the same time, I'm with the radeonhd developers in that I would much prefer the driver go straight to the registers. And it just so happens that "ati" uses the former while "radeonhd" does the latter. So it seems the two drivers have unique puproses - one to let people use new cards NOW without fglrx, and one down the road which is "more ideal". I kinda like it that way, even if I don't have money to blow on new video cards every couple months.

[bridgman]

keep an eye on airlied's blog, I guess...

http://airlied.livejournal.com

[SheeEttin]

So kernel modesetting is on the way? Cool...

Any estimate on when we'll be seeing it in the a release? It's one feature I'd love to get my hands on.

[bridgman]

With these opensource drivers, will there still be a difference between the FireGL and their Radeon counterparts and will that difference be forced upon the open source drivers through AtomBIOS? (Like the way the Windows driver decides what features are to be enabled on a specific adapter, as can be observed from the many succesfull hacks).

It varies from one generation to the next, but AtomBIOS doesn't force anything -- it just identifies the card as a FireGL product and lets the driver decide what to do. There are other mechanisms we use to force different behaviour -- and when we don't use them, the cards do occasionally get hacked.

AtomBIOS commands only cover initialization and modesetting. All the rest -- including 2d, 3d and video acceleration -- are done via the on-chip command processor (cp) or by poking the same registers used by the command processor. I guess at a very abstract level you could say that AtomBIOS does for display & modesetting what cp does for acceleration -- it provides well-tested programming sequences which "just work" for most situations and can be bypassed where necessary.

On the 5xx parts I don't believe there will be any behavioural difference between Radeon and FireGL products with the open source driver. Not sure yet about 6xx and up yet.

[Louise]

One of the differences betwee the open source world and regular commercial development is that where there are strongly held differences you often get a code fork rather than everyone stopping work or one person making an arbitrary decision -- it's not the fastest way to a solution but it's not necessarily all that bad either.

I think there have been a couple of these cases. Probably the most famous is Beryl/Compiz

Sorry, I forgot about XFree86/Xorg

And Rhythmbox/netRhythmbox, that like Beryl/Compiz merged again.

[some-guy]

Hello everyone. I have a very brief question for brigman: will kernel modesetting also be available on r300?
9800pro owner here :-)

afaik kms can be enabled on any card, it probably will eventually come