I have been working on porting radeon kernel modesetting to new ttm developed at VMware by Thomas Hellstrom. Just to avoid confusion ttm is used inside the driver the API we expose to userspace is the GEM api. I cleaned up the radeon code along the way and i feel it's now ready for wider range of tester ! Few words on the code itself, there is now a split between old drm path and new kernel modesetting path, i did so in order to avoid breaking old path while also being able to have a clean design & code for new kernel modesetting path. I am quite happy with how the code looks now, of course i am not the only one guilty about all this work Dave Airlie and Alex Deucher did lot of the original modesetting work, Dave also worked hard in last few month on mesa radeon rewrite which has root into Nicolai Haehnle initial work. Big kudos to Maciej Cencora (aka Osiris) for all improvement he done on the code. So here is a screenshot of what you can get with kernel modesetting, a decent ddx and proper mesa (radeon-rewrite branch) :



So if you feel adventurous here are things you need:

Kernel:
git clone git://people.freedesktop.org/~glisse/drm-next
cd drm-next
git branch drm-next-radeon origin/drm-next-radeon
git checkout drm-next-radeon
Then usual kernel configuration just enable fbcon,ttm and radeon kernel modesetting.

git clone git://anongit.freedesktop.org/git/mesa/drm
cd drm
git branch modesetting-gem origin/modesetting-gem
git checkout modesetting-gem
./autogen.sh --prefix=/usr --libdir=/usr/lib64
(libdir is only needed if on x86-64)
make
sudo make install

git clone git://people.freedesktop.org/~glisse/xf86-video-ati
cd xf86-video-ati
git branch radeon-gem-cs3 origin/radeon-gem-cs3
git checkout radeon-gem-cs3
./autogen.sh --prefix=/usr --libdir=/usr/lib64
(libdir is only needed if on x86-64)
You also need the Xorg dev package from you distribution sudo yum-builddep xorg-x11-drv-ati.x86_64 (on fedora)
make
sudo make install

git clone git://anongit.freedesktop.org/git/mesa/mesa
cd mesa
git branch radeon-rewrite origin/radeon-rewrite
git checkout radeon-rewrite
./autogen.sh --prefix=/usr --libdir=/usr/lib64 --with-dri-drivers=radeon,r200,r300
(libdir is only needed if on x86-64)
make
sudo make install

Now once you reboot under new kernel you need to load radeon module with modeset=1, then your userspace should be all set, i know this needs many things to build but hopefully soon we could start merging little by little thing upstream and so it should end up in your distro. Anyway if you own an x200 (igp) or x1250/x1200 with intel CPU i would love to know if you got any issues with this code. Early tester are always appreciated and i would like to thanks spstarr, dilex, osiris, ... for their early testing and reporting on this code.

Forget to mention that suspend/resume should work flawlessly even if you are in a middle of quake3 game while spinning compiz cube (don't think it's a normal use case but you never know).

Of course performance are not yet what it used to be, but here is my todo list which should also bring us back somewhere near old performance and maybe even outperform old path :
-erase memory on bo allocation (security needed before upstreaming)
-more check on command stream (security needed before upstreaming)
-port & cleanup Dave's page allocator to avoid heavy cache flushing (performances)
-buffer swapping (performances)
-buffer tiling (performances)

The plan was to quickly hackup DRI2 inside mesa to test new command stream submission and memory manager. Many things were lacking to get compiz working, add bugs to the equation and i end up way beyond my schedule :( Anyway today i am allmost there and i got compiz working =) i need to thank Kristian Høgsberg for all the help and advices on getting dri2/compiz working, Dave Airlie also helped me in the painfull process of tracking bugs. Sadly they are still a bunch of issues with today, as you can see on the screenshot my dri2 is still rendering to front buffer... i need to sort this out, i also stumble on a bug in the idr stuff in gem, need to track down this one too.

The biggest task is to convert r100 & r200 driver to new buffer object and command stream scheme, then we need to do regression testing and in the end, hopefully, we can merge with mesa. That's for userspace, but the tedious bits are the kernel one, they are many things that need to be cleaned up, and many other pieces that need to be written like a full command checker (summary is we need to check that command userspace wants to executed and gpu won't access unauthorized memory area or won't have access to previous memory content, doing this is not easy and need a lot of code). Also their is few aspects in the today memory manager that i don't like, fence and buffer object movement being the top two items i can think of, hopefully TTM work that is underway will obsolete my concerns. To sumup it's pretty useless to have userspace if kernel space is not upstream :)



You can see that the gears are at the right position, note also that you don't see the uncomposited window in live experience, only the screenshot exhibit this uncomposited content. For curious people code is at the same place as before :

git://anongit.freedesktop.org/mesa/drm modesetting-gem
git://people.freedesktop.org/~glisse/xf86-video-ati radeon-gem-cs-dri2
git://people.freedesktop.org/~glisse/mesa r300-bo-cs

Hey,

It has been a while since my last post :) So i have spending sometimes this week on DRI2 and new command stream submission for radeon (well to be accurate i only done r300 but much of the work should apply to others asics as well). This new command stream submission is here to replace the old one which was basically a wrapper around the hardware format, now we directly use hardware format so no more translation, every one speak the same language. The new command stream format is also designed to handle what we call relocation, with memory manager only the kernel side know what is the hardware address of memory object so the kernel as to change command which reference a memory object and write the hardware address to the command stream before sending the command stream to the hardware. In all this, DRI2 is just a bonus, low hanging fruit i wanted to taste (i can be greedy sometimes :)). It's not ready at all yet, as it suffers from a massive slowdown (expect to see one frame every minute :o)). Maybe i will have more stuff to blog about in coming weeks.



Oh for curious people you need the following (giturl branchname) :
git://anongit.freedesktop.org/mesa/drm modesetting-gem
git://people.freedesktop.org/~glisse/xf86-video-ati radeon-gem-cs-dri2
git://people.freedesktop.org/~glisse/mesa r300-bo-cs
None of this is supported i tend to break things and delete branch once in a while

Well i should have posted this before new year but i was in a rush to get to Barcelona (nice city between) anyway here it's glxgears working with radeon modesetting and softpipe as software render. So of course you wonder what the hell does this means :) In others words i am putting all together  pieces to start working on gallium driver and this by far the most painful part. To sum up:
- drm kernel part have to supply and ioctl to get command from userspace
- ddx driver (here an hacked fbdev driver) have to init dri for xserver
- winsys driver have to do some others dri initialization and also init gallium infrastructure

So now i am going to polish all this as right now there is plenty of hack in several places. Once i am happy with this code i will the gallium driver for r300/r400 hw and r500 too.

All code are in my private repo cgit.freedesktop.org look for ~glisse



Side note: color are wrong due to softpipe not my code :)

My kernel modesetting code is finaly accessible :)

git clone git://people.freedesktop.org/~glisse/drm

The beast is in modesetting-radeon code. This is primilary work ie this is not intended for end user but for developer, curious people or people living beyond the edge. Here is a todo list that pop from the top of my brain:
    - add crtc2
    - tmds
    - lvds
    - add bios data table so we don't need to hardcode dac/crtc infos
    - separate clock control to make power saving easier & cleaner
    - tiling (warning tiling shouldn't be enable in double scan or interlace)
    - surface reg manager (this goes along with tiling)
    - suspend/resume hook
    - avivo & r500 family support
    - atom bios support (for posting card mostly)
    - finish superioctl skeleton

Well of course i welcome any patch on this topics :) Now my plan is to work on dri2 and gallium driver for r300/r400 family i hope to be able to demonstrate this at fosdem 2008. You will likely see  xserver & mesa repository popup soon in my private area at fdo.

I also would like to thanks every people who helped me to better understand this hw and to help me fixing bug i did encouter.

So I am writing a blog, such things happen, but don't worry this will be mostly about linux graphic world and especialy on what kind of dumb stuff i am doing on radeon hardware. I might cover others topics from time to time and i hope you will forget any time i get lost in life topic :)