Log in


March 2015
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]
initial kms for radeon r500 atombios pushed

AMD today announced the source code to that atom parser from their kgrids project, I've been playing with this code for a few weeks to see if we could use it for kernel modesetting (kms).

So I've just pushed my initial radeon kms code to the "gem-modesetting" branch of the drm git tree.
The corresponding DDX code is in the radeon-gem-ms branch of my personal xf86-video-ati repo.

This contains 2 major things - and doesn't contain lots of other major things:

1. GEM style API to userspace layered on top of TTM internals.
- Only really does pinned allocations - no superioctl support yet, working with Jerome on tying that down.

2. atombios parser from AMD + modesetting code.
- This only support rs690 and r500 devices so far. We don't have r600 code in the drm tree properly yet,
and legacy bios is TODO.

So the major TODOs are:

add support for modesetting on legacy cards (r100/r200/r300/r400) - ported from -ati driver. We need a fixed point
implementation of the bandwidth calculation code.

proper command submission - Jerome is looking into this and I think we have a solid plan. for now I'm just abusing the old
style command submission routines with GEM ioctl.

3D - cmdbuf work on the Mesa drivers needed, RH has some in-progress code.

EXA pixmaps - still using one big EXA offscreen area, probably need to move to EXA pixmaps for DRI2 and also to use the superioctl properly.

Could you add Rage 128 to the legacy TODO?

I'd love to see kms on Rage 128 (r128) cards, too. Hopefully there're not too different from early radeons.


GEM style API to userspace layered on top of TTM internals.

Why this? I'm not up of date with recent development (going to read the dri-devel archives) but I understood that GEM and TTM were alternative...


no-one ever said they were alternatives, GEM is a memory manager suitable for Intel hw, with a simple API. The API is the nice part, however the underlying memory manager is specific to Intel hw in most ways, and cannot just be used on other hw.

TTM is actually a better fit to a lot of hw, however its API was fairly unmaintainable going forward, and some of its internals still need work. The thing is APIs are set in stone, internals can change.


You said "The thing is APIs are set in stone, internals can change."

Does that mean that GEM will be improved in the future so that it fits the needs of other hardware like ATI/AMD?



"The thing is APIs are set in stone, internals can change."

I guess that this is one advantage of NVIDIA's approach. AFAIK, they don't really have an API here, so they can change it whenever they want to - an NVIDIA driver speaks to the kernel, their libGL implementation is used by everyone doing opengl, and X uses their driver, so the interface between those components can be whatever they want it to be.

I love how things are going =)

I love how things are going =)

atombios for r400?

can atombios also be used for atombios-enabled r400 cards, eg. rv410?

Re: atombios for r400?

For some things it can. For example we already use atombios for external tmds chips. However, atombios on r4xx was a transitional series, so not all of the atom commands work as expected. We may be able to utilize more than we do now, but it would take some work to sort out the details.

Re: atombios for r400?

question is, does r4xx support the atombios functions which are used for kms? ie. could the modesetting code be easily extended for r4xx?

Re: atombios for r400?

In theory, yes, in practice some stuff works, some doesn't. As I said it would take some work to figure out what parts could be used.


legacy support

Could my work I talked about on irc long ago prahal.homelinux.net/~prahal/patches/ati/radeonfb_supportforsuspend.diff be of any help to add legacy support ?
It works for me 100% but only if I start s2ram from X . If started from console it does not restore the graphics (but at least it does not freeze as without the patch). This I don't know why but this was only a hackish attempt at making things works (which they do hurray) for my day to day use. This is based on the xorg ati driver BIOS code and radeonfb . Using radeonfb instead of kms which was not ready at this stage monthes ago is the reason I did not spend to much time cleaing it and making it ready for inclusion (I also did not port the atombios part though you ve done it so thanks).