Should AMD make kernel and Xorg-server updates for their legacy drivers?

[fat_chris]

So knock off the "I'm a gamer and I expect my 3 year old gaming card to still run the newest games with a decent frame-rate." That argument holds no weight.

I have a x1900xt and can run new games with decent performance (in windows of course). I haven't exactly measured my FPS because I don't really care about it, all I care about is whether games play well, and they do.

[dungeon]

DoDoENT
And when can we expect Gallium? It doesn't look like it'll be ready for usage soon, or am I wrong?

Overall Gallium is allways ready i think (it works for intel, but that drivers Tungsten developed - r300>= are community developed driver only!), but lagging is because radeons don't have any memory manager "yet" (funny word) and showstopper also is because someone make up KMS thing for which drivers must to ex/im/plode. I think, all just sits and wait for things to happen... i mean devs... So, i think, users will wait some years for that, but who knows maybe something happens "internally" (bridgman's word). He promise classic Mesa/DRI drivers for HD card/s "soon" (funny word), but no one even mention who is responsible to make memory manager and when this will happen... deep sigh.

[bridgman]

but no one even mention who is responsible to make memory manager and when this will happen... deep sigh.

There are really two parts to the work; the memory manager itself, and the fairly big changes which need to be made in all of the OTHER components in order to make use of the memory manager.

At the risk of stepping on TIRDC toes...

Airlied is working on the memory manager and it has been running for some time in the Fedora development trees. Anyone running KMS on a Radeon GPU is using the memory manager already. The memory manager was running last fall, but it (along with DRI2) was pulled back in order to build a GEM API on top of the existing TTM code.

The memory manager uses an initial TTM implementation which is not felt to be ready to go into the upstream kernel tree without some cleanup, so right now the memory manager is only available in the Fedora development repositories (although I think the code has been experimentally pulled into a couple of other distros as well).

My understanding is that Thomas at TG (now VMware) has released some new TTM code which Airlied is hoping to integrate soon, but I'm not 100% sure about that last part or whether the changes are enough to let the resulting code go into the upstream kernel tree.

There is a branch of xf86-video-ati (aka radeon driver) which runs over the memory manager, and an early version of this code (along with KMS and memory manager) shipped in F10.

The r3xx-r5xx classic mesa driver has been modified to use the memory manager (airlied, glisse, nha mostly AFAIK), and airlied then merged r1xx/r2xx support into the r3xx-r5xx mesa tree (in the "radeon-rewrite" branch) rather than separately adding mm support to the r1xx and r2xx mesa drivers.

Internally we are working on adding initial 6xx-7xx support to the classic mesa driver. That work was built on the pre-mm mesa code rather than the work-in-progress changes to support mm in mesa. We got surprised a bit by the progress on radeon-rewrite (which uses "bufmgr" code to provide a common interface for mm and non-mm environments) and we are going to change our code to be compatible with radeon-rewrite since it is likely to merge into mesa master before our code. Not sure of the schedule impact yet, but since radeon-rewrite is getting close to merge-ready state we really need to match up with that code immediately.

[dungeon]

Thanks for explaination, it IS a hard work when user see the bigger picture! OK, airlied is responsibile to prepare/pick/negotiate MM and KMS to be ready both for Mesa/DRI and kernel and you have your HD driver almost ready code and radeon which are now and will be non-mm capable when airlied is merge ready? As i understood, you basically must wait for that merge to see if changes will be needed and then from that stage we can expected new ogl features to be added for DRI radeons?

All together, that is a lot of work! I'll bet maybe, two years or more to become ogl-2.1 ready It will be OK schedule for me, but don't know for others.

[DoDoENT]

I'll bet maybe, two years or more to become ogl-2.1 ready It will be OK schedule for me, but don't know for others.

So, in these two years it would be very nice if AMD made kernel and XServer updates for their legacy driver...

[bridgman]

But then it would take even longer

There's more work going on than what I mentioned above. MostAwesomeDude is also making great progress on a Gallium3D implementation for r3xx-r5xx parts, built over DRI2 and GEM/TTM/KMS. Once our guys get basic 3D running on 6xx-7xx they'll probably work on Gallium3D as well.

The cool thing about Gallium3D is that "in theory" all of the higher level Mesa changes to deliver GL 2.x are already in place, and once the Gallium3D driver comes up then those higher level functions will start to light up as well. Obviously it's never that simple in practice but it does mean that a lot of the GL 2.x work is already done.

[Kano]

How about an official fglrx patch for 9-2 (and next 9-3/9-4) for kernel 2.6.29? The only unofficial one which worked is >1700 lines, nothing that I like.

[dungeon]

But then it would take even longer

Thats for sure.

[d2kx]

So when TTM is going into the kernel - what benefit do we get from GEM?

[Kjella]

So when TTM is going into the kernel - what benefit do we get from GEM?

GEM is the kernel API, which is very high level and generic. It essentially only divides memory into different domains and lets you manipulate those. TTM is a much more detailed interface which worked well in many cases, but turned out didn't work well in every situation but it's still in use, just not as a kernel interface, The result is that some drivers have a meta-layer implementing TTM on GEM. Like:

a) Mixed GEM/TTM

GEM (kernel)
------------
TTM on GEM
Driver on TTM

b) Pure GEM

GEM (kernel)
------------
Driver on GEM

Least, that's my understanding of it.