RadeonHD Driver To Use AtomBIOS

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

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

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

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

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

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

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]

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]

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]

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.