Log in

No account? Create an account

July 2017
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]
radeon 3d drivers merge plans

In order to further Red Hat's commitment to KMS on radeons, I've been adding support for a bufmgr to all 3 radeon 3D drivers.

The bufmgr essentially abstracts the lowlevel buffer management from the state machine of the driver, so we can implement a simple userspace buffer manager which operates on the current system, and a memory managed buffer manager which operates on the GEM kernel API we defined for radeon.

Jerome Glisse and Nicolai Haehnle wrote the initial r300 bufmgr, texturing and mipmap tree code. I decided that instead of trying to port it to r100/r200, I took the opportunity to merge as much of the common code in radeon/r200/r300 drivers.

So armed with piglit to fight regressions and a lack of sleep, I started merging.

So I've pushed the results to the radeon-rewrite branch of mesa, it works for me on all the radeons I've played with in legacy mode.

My future plans for the codebase are:
1. get libdrm_radeon on modesetting-gem autodetected
2. Implement radeon/r200 userspace clear code. This is in-kernel at the moment but kms needs it out.
3. Play with DRI2 - should already be supported on KMS/GEM stack. I suspect I need to fix some state handling for this.
4. make it go fast on kms - work with compiz and a few games for F11.

Oh I forgot to mention the best bit:
100 files changed, 11289 insertions(+), 15487 deletions(-)

4000-5000 less lines of code ftw. I have a few more license headers in new files :)

Good job

I've been following your radeon-rewrite branch through cgit and I'm really impressed about the code quality. You improved the code from "copy and paste" to something that uses common code together. Looking forward for your next steps.

Great !

Great job, like you always do.
AMD owes you some money, because you're one of the guys that will make me buy more ATi cards.

This is what i think

Sorry for the useless comment but...



What is the easiest way to test this new code? I have a notebook with r200 which I'm ready to sacrifice for this task :)

How to help testing

I'd also like to help test this. I have a laptop with RS482 [Radeon Xpress 200M] and desktop with RV350 AR [Radeon 9600] if that would be of any help. So are there any instructions on Wiki or somewhere on how to help by testing this.

Re: How to help testing

All the code is available in http://cgit.freedesktop.org/mesa/mesa/log/?h=radeon-rewrite Simply do: mkdir /usr/src/mesa cd /usr/src/mesa git clone git://anongit.freedesktop.org/mesa/mesa . git checkout --track -b radeon-rewrite origin/radeon-rewrite And now build mesa as you usually do (sh autogen.sh && ./configure && make). After that export LIBGL_DRIVERS_DIR=/usr/src/mesa/lib and run your program. !!!Note that I wrote all this from memory and cannot garantuee it is valid!!!

Re: How to help testing

Don't we need a kernel with GEM and KMS? If so, which one?

Re: How to help testing

Yes, you will need a kernel with at least GEM (I'm not sure about KMS, and I haven't tested this myself yet). Probably your best bet is to build the DRM modules from git, as well. You probably don't want to do this on anything earlier than 2.6.29.

Great Job!

Really good job you do. Especially thanks that you bring the new life for R200 and R300 graphic cards. I've got RV350 and many people here have still RV250/RV280/RV350 and we don't want to change the cards for another ~2-3 years. When AMD dropped support for R300 hardware in their binary blob I've migrated to yours open source driver and I've just loved it - many things which didn't want to work on AMD/ATI binary driver work out of the box here and even if the driver is 2 times slower on 3D games and has not as many OpenGL extensions as binary driver has I feel it's more responsive in Compiz/KDE Desktop Effects and better 2D. I can finally watch TV from analog TV card with XV and SHM support without flickering or X crashing with good framerate and without noticed CPU usage. What am I missing is Wine Direct3D support as good as in Nvidia binary driver, but I can live with that for now. Keep up the good work. Many thanks from me and friends from Poland.


Nice work :)

I've been collecting passively cooled r200 cards because their working OpenGL line smooth and availability as recycle scrap. Any chances you'll look into adding that to r300 and/or FSAA too?


Re: Great Job!

Unfortunately, fixing Wine3D will be a bit of a challenge, as it was essentially written around the Nvidia drivers. The good news, however, is that it may be possible at some point to implement it directly over Gallium3D.

As seen in the World of Goo linux-issues.txt file

"Some users reported rendering problems when using the open source AMD/ATI
drivers for their graphics card. Users of ATI graphics cards are advised to try the proprietary Catalyst (fglrx) driver instead."


Re: As seen in the World of Goo linux-issues.txt file

Some users experienced problems using the proprietary proprietary Catalyst (fglrx)drivers for their graphics card. Users of ATI graphics cards are advised to try the open source AMD/ATI driver instead.

So I have a goal to get a radeon driver that works on a bufmgr and that
then can be used on non-mm/mm, and also where I can make DRI2 and FBOs