RadeonHD Driver To Use AtomBIOS

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