RadeonHD Driver To Use AtomBIOS

[phoronix]

Phoronix: RadeonHD Driver To Use AtomBIOS

We've talked all too often about AtomBIOS and there being two different open-source drivers that support the same ATI Radeon hardware with the key architectural difference between the two just being the use of this video BIOS abstraction layer. From the beginning, AMD was planning to have their Novell partners use AtomBIOS when writing this new (at the time, R500/600) driver, but the developers ultimately declined. These developers have expressed their opinions on AtomBIOS, which range from it being an unbearable mess to this design being nothing more than writing open-source code to power someone else's closed-source work. However, under pressure by AMD, the developers are now preparing to use AtomBIOS to a much greater extent within the xf86-video-radeonhd driver. In this article we'll tell you more about what's gone on and where you can checkout this AtomBIOS-bearing RadeonHD driver.

http://www.phoronix.com/vr.php?view=12563

[d2kx]

and settling for a de facto standard driver for the R600+ GPUs

I think you meant R500+.

they will begin focusing on open-source 3D support for the Radeon HD 4800 series

...and Radeon HD 3000 series, I assume.

...

Interesting changes, I like that the development will be a lot faster from now on... who knows where we would have been now if they had used AtomBIOS from the beginning? :)

[Michael]

I think you meant R500+.

Nope, for R600+ according to where they are in development and those that I've talked with -- since the R500 3D is quite similar to the R300/400 and is already up and running for R500.

...and Radeon HD 3000 series, I assume.

Nope, RV770 Radeon HD 4800 series 3D.

[stan]

AtomBIOS might be a way to create an artificial market segmentation: AMD/ATI could sell the exact same hardware with two versions of AtomBIOS burnt on each. One version of AtomBIOS would advertise a higher functionality and thus command a higher price. With a FOSS driver that accesses the registers directly you can't hide trickery like that. 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.

It might be cheaper for AMD to mass produce the same card than multiple hardware permutations of it, so differentiating them through binary blob BIOS would make economic sense. As far as users are concerned, this sucks 100% because they can't use the hardware to its full extent. Any way you look at it, it's an anti-consumer measure.

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?

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.

[bridgman]

I have to jump in here. I don't see why this discussion keeps turning into "using AtomBIOS *instead of* getting documentation to use the registers directly". It's not one or the other, it's both.

I fully expect that over time developers will need to hard-code around AtomBIOS in places, and we are providing documentation to allow that. The documentation is needed anyways in order to understand and troubleshoot what the driver is doing.

The question is simply what should happen *first*. Using AtomBIOS for the initial implementation means that functionality gets into users hands faster, and that we don't have to write "here's how to write a driver for this chip" documentation just "here's what the blocks and registers do". Remember that we have to *write* all of this documentation -- it's not just a question of pulling it off the bookshelf and dumping it on a web site.

[mycroes]

Could it perhaps be a possibility that ATI will open up atombios? I think that would be great for all ATI drivers. I think there's no fundamental issue with a partly universal layer, especially since on top all drivers try to deliver a totally universal layer. So if every ATI driver were to use atombios, and atombios would be open source this means everybody can be happy about it, it means developers can propose changes to how atombios works which might benefit ati for it's proprietary driver and in the end I think it will improve the quality of drivers for ati hardware overal.

I know it's not always possible to open up any piece of proprietary software, but it seems to me atombios should be purely ati's property.

Also, if the drivers all use atombios and it won't open up, some group can focus on creating an atombios equivalent with the same api, might be useful, might not. Either way I would think of it as a plus if the atombios part is open source too.

[bridgman]

Actually we did open up the atombios interpreter and header files at the start of the project, so understanding the command and data tables is not a problem. The remaining concern is that the atombios command tables themselves are in bytecode form and have to be disassembled, but since we *write* the command tables directly using bytecodes the disassembly output is identical to the source code in most cases. The only "lost information" is comments... but BIOS developers don't seem to be big on commenting their code in the first place :D

If you're interested, you can look in the radeonhd source code at : http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd;a=tree

src/atombios/ contains the source code we provided, and the includes folder contains the atombios.h header which shows how to interpret the command and data tables. It's pretty cryptic but it's what we use in house as well. We started writing more intelligible atombios documentation at the start of the project but back-burnered the work when it became clear that atombios was not being used. We should probably restart that effort.

[remm]

This should have been obvious ... Use AtomBIOS first to get 2D support quickly and work on the useful part (3D), then go back to do cleaner 2D later on. Six months (almost) wasted. Too bad the Novell folks are far less religious dealing with tainted technologies when it is about Microsoft.

[bridgman]

It's water under the bridge now. Probably easiest for everyone if we just focus on all the cool new things we will be doing ;)

[Kano]

How about fixing all compiler warnings in the Atom BIOS code? Also what about supporting older Radeon cards with radeonhd? I can not test that driver with my RV410.

[val-gaav]

the good question right now is...

Since the differences between radeonhd and radeon drivers start to disappear, shouldn't the both drivers just merge or agree that radeon is for chips up to r400 and radeonhd for r500+ ? radeon driver already has ATOM bios support and supports new chipsets too ... What's the point in doing the same in 2 drivers ? what's the point of having two open drivers for the same cards ?

I mean shouldn't the X guys on both sides agree to work together and don't do "double work" ?

[Melcar]

I always thought that both drivers would specialize on different chips, and not overlap as they are doing right now. I was expecting radeon to take care of r400 and lower type hardware, and radeonhd r500 and above. Now with radeon starting to support even the newest cards, I don't see the need for 2 driver sets. The whole AtomBIOS thing seemed like the only real difference (and a rather "philosophical" one at that) between the two, and now with that difference gone, I see even less of a reason for having seperate sets, for basically the same hardware. I guess future performance differences (like 3D) that may pop up could justify one over the other.

[bridgman]

Actually both drivers use the same 3d code so that isn't likely to be a difference either ;)

Seriously, this will take time while all the philosophical differences are worked out. Everyone has to feel comfortable working in the same code base and confident the code base will deliver what they need from it.

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.

[some-guy]

This should have been obvious ... Use AtomBIOS first to get 2D support quickly and work on the useful part (3D), then go back to do cleaner 2D later on.
Wait. If that's how it's going to be, why is radeonhd moving to atombios, they can implement the better version, while radeon implements the quicker and easier version.

Then radeonhd can get the 3D code ported, and the focus could be switched to radeonhd and gallium, no more duplicated effort

[bridgman]

The problem with having two different drivers is that you have to do all the acceleration work in the atombios-based driver because you CAN'T SEE THE SCREEN on the other driver 'cause the modesetting code isn't there yet :D

Nobody is particularly fond of the idea of doing all the development work in one driver then porting it across to the other driver... over and over again.

[some-guy]

The problem with having two different drivers is that you have to do all the acceleration work in the atombios-based driver because you CAN'T SEE THE SCREEN on the other driver 'cause the modesetting code isn't there yet :D

Nobody is particularly fond of the idea of doing all the development work in one driver then porting it across to the other driver... over and over again.
I see the point, thanks for clearing that up :)

[izual]

they will begin focusing on open-source 3D support for the Radeon HD 4800 series
Maybe it's some sort of paranoia, but this sounds like "let's skip the R6xx family".

But it's just paranoia right?
It would be stupid.

[rbmorse]

It only matters if you own an R6XX product.

(I do).

[bridgman]

No plans to skip the 6xx family. I have one in my home PC, there's no damn way we're skipping it ;)

The issue is that we have sample code for 7xx that actually works, while we're still having problems with the 6xx sample code (it seems to have been broken on 6xx in the process of making it work on 7xx). Starting with code that works (even if it's in the wrong environment and has to be totally rewritten for X/DRI) is "highly attractive".

6xx and 7xx are pretty close from a driver POV, so rather than getting things working on 6xx this week and same thing on 7xx next week we might go the other way. On the other hand, now that we have sample code working on 7xx we may suddenly figure out why it doesn't work on 6xx.

Either way, we plan to do 6xx and 7xx in parallel; trying to design code that will work on both.

[c0un7d0wn]

So kernel modesetting will also use atombios, right?

[bridgman]

So kernel modesetting will also use atombios, right?

That's the way it's looking today. Dave Airlie has been cleaning up the parser to go into the kernel, and Ben H has been working on fixing the big-endian issues. There was a rumour that one of our driver devs had already fixed the big-endian support but it turned out the fixes were for the pre-Atom BIOS instead.

<deleted the comments about the new AtomBIOS parser we discovered internally 'cause it just confuses things ;)>

[c0un7d0wn]

Awesome. So there are two drivers for ati hardware and now it turns out there are also two atombios parsers. If we combine them we can have 4 drivers that does the same thing. :)

Actually forgot about kms, so that makes, what, 6? :D

[Michael]

Actually forgot about kms, so that makes, what, 6?

You forgot about the xf86-video-Avivo driver too :D

[c0un7d0wn]

Ah, Operation "Extreme Redundancy" is carrying on! :D

[bridgman]

Hey, there used to be four drivers, now there are only two-ish :

http://www.phoronix.com/forums/showthread.php?t=7032

Seriously, the X community is going through some very cool times right now. There are a lot of good ideas competing for attention and developer time, and in most cases you get some forking while the pros and cons of each approach are understood, then everyone comes together on a single approach after a while.

That said, there are a lot of different worlds co-existing in X right now and both drivers have attributes which are useful to some users. The challenge is to get everyone to agree on what the good and bad bits are.

Kernel modesetting will make things seem complicated for a while, but the benefits are going to be significant, particularly the potential for fixing suspend/resume once and for all, or at least making sure the problem is not with the graphics drivers.

Finally, you need to look at both the atombios and "quick & dirty 2d" radeonhd branches together if you want to get the whole picture. If anyone feels like testing the "quick & dirty 2d" branch on a 5xx or 690 it should have full EXA acceleration, textured video Xv, and 2d/3d coexistence from radeon, plus the driver abstraction and modestting code from radeonhd, plus a bunch of other recent changes to make all the bits fit together nicely.

[StefanHamminga]

Maybe slightly off topic, but I'm a 3D designer with a strong interest in both Linux and FireGL products, so I was wondering...
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).

[Kern3lP4nic]

That's the way it's looking today. Dave Airlie has been cleaning up the parser to go into the kernel, and Ben H has been working on fixing the big-endian issues. There was a rumour that one of our driver devs had already fixed the big-endian support but it turned out the fixes were for the pre-Atom BIOS instead.
Hello everyone. I have a very brief question for brigman: will kernel modesetting also be available on r300?
9800pro owner here :-)

[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 :)

[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.

[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.

[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]

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

http://airlied.livejournal.com

[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]

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.

[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.

[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.

[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.

[libv]

Could it perhaps be a possibility that ATI will open up atombios? I think that would be great for all ATI drivers. I think there's no fundamental issue with a partly universal layer, especially since on top all drivers try to deliver a totally universal layer. So if every ATI driver were to use atombios, and atombios would be open source this means everybody can be happy about it, it means developers can propose changes to how atombios works which might benefit ati for it's proprietary driver and in the end I think it will improve the quality of drivers for ati hardware overal.

I know it's not always possible to open up any piece of proprietary software, but it seems to me atombios should be purely ati's property.

Also, if the drivers all use atombios and it won't open up, some group can focus on creating an atombios equivalent with the same api, might be useful, might not. Either way I would think of it as a plus if the atombios part is open source too.

ATI has always been squarely against being able to replace your graphics card bios. Even when specific BIOS versions might have noticeable bugs, you will still not be allowed to work around them by just flashing in a new BIOS.

[libv]

This should have been obvious ... Use AtomBIOS first to get 2D support quickly and work on the useful part (3D), then go back to do cleaner 2D later on. Six months (almost) wasted. Too bad the Novell folks are far less religious dealing with tainted technologies when it is about Microsoft.

There are several aspects to an answer here.

First of all, in a project like this, you have two sorts of people, those who do the talking, and those who do the coding. Where the coders usually get bogged down is one of many possible issues: Being stalled on hardware or documentation, or waiting for answers to technical, undocumented questions. Human factors, like Matthias breaking a bone in his right hand. Or being bogged down to the talkers mode.

Mostly though, those 6 months you use there were not wasted while waiting for code to be written, they were wasted everywhere else.

Then, you state that you want to see work done one the "useful part" right away. Do you realise that this means brushing all problem under mat, and leaving a lot of users in the cold, who can never see this useful part as their hardware doesn't come up properly in the first place? And when you say that the modesetting bit will be solved afterwards, you are mistaken. Such a thing only happened once, where the pressure of the free software community was horribly high, and where some smart people in intel hired a lot of developers who were forced to work on modesetting. In all the other situations, there never was time spent on going back and doing some things Right.

[libv]

the good question right now is...

Since the differences between radeonhd and radeon drivers start to disappear, shouldn't the both drivers just merge or agree that radeon is for chips up to r400 and radeonhd for r500+ ?

This was the original intention, sadly some people saw this differently and then wasted a lot of resources.

[libv]

No plans to skip the 6xx family. I have one in my home PC, there's no damn way we're skipping it ;)

What driver are you using?

[libv]

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.

This figure is greatly exagerated, especially since radeon, when it came around, took a lot of the hard work straight from radeonhd.

The difference between both drivers is this; the intention to provide for everyone, or the intention to provide only for 80% of the users. The former means that one gets bogged down figuring out what's wrong, the latter means people running straight back to fglrx (which, given ATIs recent push there, might not be entirely undesired).

[libv]

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.

BIOS is software treated like a black box, both by the developers of the bios and the people using this black box. It is hardly ever perfect, and especially in this case, hard to fix.

What problems do you want to see fixed in your case? In a perfect world, your display lights up correctly, and everything is well... But the world is never perfect, and you'll swear to nvidia all of a sudden if you happen to be unlucky.

[bridgman]

This was the original intention, sadly some people saw this differently and then wasted a lot of resources.

In fairness, the complete "original intention" was that radeonhd would initially be built on AtomBIOS and would replace radeon beginning with R5xx.

I know there were other proposals but our plan was always to use atombios. That said, I think we were all a bit surprised by how much of the existing radeon acceleration infrastructure "just worked" on 5xx, so if we were doing the project again splitting between 5xx and 6xx might have been the better choice. Hard to say.

You nailed the big question in one of your earlier posts -- whether our first priority is getting full functionality for *most* users or basic functionality for *all* users, where "all" includes platforms such as Mac systems running without BootCamp, non-x86 CPUs and OSes which do not yet have DRM support. We see "full functionality for most users" as our first priority, although I suspect that "most" in this case is closer to 95% than 80%.

What driver are you using?

Right now I'm using the VESA driver :rolleyes:, at least until (a) I get a reliable modem connection when running Linux, and (b) I figure out why the PC is locking up occasionally even with the VESA driver or with "that other OS".

ATI has always been squarely against being able to replace your graphics card bios. Even when specific BIOS versions might have noticeable bugs, you will still not be allowed to work around them by just flashing in a new BIOS.

Yes and no. We are still generally against re-flashing the ROM because of the warranty and support problems that come along with it, but I believe we leave the final decision to our board partners. I think there was a fan controller profile issue with some early 3870 boards which was addressed with a BIOS reflash. As a safe alternative to flashing, we put a mechanism into the atombios framework which allows tables to be replaced on the fly by the driver.

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.

I agree you have not received all the information you need, although obviously we need to get that information from Apple since it's their hardware design and they provide a portion of the driver stack.

[Louise]

I was wondering, when it have been decided to stay with TTM or move to Intel's GEM.

Does that change anything in regards to the ati and radeonhd drivers?

[bridgman]

I was wondering, when it have been decided to stay with TTM or move to Intel's GEM. Does that change anything in regards to the ati and radeonhd drivers?

The memory management code is all in the kernel (the drm component) so most of the work is outside the ati and radeonhd drivers. Once memory management is up and running, however, both drivers will need to be modified to use the drm's memory manager rather than performing those functions itself.

Kernel modesetting is easier by comparison, since the driver can choose whether or not it wants to use KMS, but AFAIK memory management will require more coordination across the components.

As far as TTM vs GEM goes, the general consensus seems to be to use the GEM calls for "core" functions, since non-driver components such as DRI2 need to use the memory manager and therefore require commonality across drivers, and to allow the rest of the API calls to be driver-specific. There seem to be some areas where TTM is preferable, at least for discrete graphics, and it sounds like the final solution is likely to be a mix of GEM and TTM concepts.

The TTM/GEM discussion may have delayed development of memory manager and kernel modesetting by a month or two but it was probably all for the best, since the devs generally seem to feel that some of the ideas in GEM help to address some long-standing problems.

[airlied]

The memory management code is all in the kernel (the drm component) so most of the work is outside the ati and radeonhd drivers. Once memory management is up and running, however, both drivers will need to be modified to use the drm's memory manager rather than performing those functions itself.

Kernel modesetting is easier by comparison, since the driver can choose whether or not it wants to use KMS, but AFAIK memory management will require more coordination across the components.


Hmm not really, the plan to stop the X server running as root, means you have to use kernel based modesetting with a DRM exposed acceleration architecture. This is part of securing X properly not with duct tape and bonghits.

There will be one kernel memory manager for radeon and one modesetting implementation, Userspace drivers are for accel only via submission of command buffers to the DRM.

Dave.