The Linux 2.6.36 Kernel Will Have Some Fun DRM

[pingufunkybeat]

can anyone explain benefits of this? " R600/700 tiling support"

Performance due to better memory layout.

Some people have reported 60-100% improvement in some games. On others, it doesn't matter much.

[agd5f]

For reference:

http://www.phoronix.com/forums/showpost.php?p=131301&postcount=37

[movieman]

Yeah, as the linked post says, video memory is traditionally arranged in rows but rendering typically occurs in triangles, so by arranging the memory in rectangles you can better optimise your memory reads and writes for triangle rendering.

The problem is that Windows expects the video memory to be arranged linearly when it performas a direct video memory access, so you need magic to convert between the two memory arrangements. The bigger problem is that some buggy applications don't abide by the published and documented methods of accessing video memory and then explode when they discover that the memory is really tiled and not linear ('but locking video memory every time hurts performance and it works fine anyway'... until it doesn't).

I don't know whether Linux even provides a means of direct video memory access?

[agd5f]

For software fallbacks you need to provide a span routine to access the tiled buffers in video memory, or you need need to blit to a linear buffer as software expects linear.

[movieman]

For software fallbacks you need to provide a span routine to access the tiled buffers in video memory, or you need need to blit to a linear buffer as software expects linear.

I assumed that all chips did the conversion in hardware, because I don't believe DirectX allows you to tell applications that it's a tiled surface and repeated blitting seems incredibly slow. I was also going to say problematic given the number of applications which don't lock the memory when they're supposed to, but I guess if they don't lock it then whatever they write to the memory will be corrupt anyway.

[agd5f]

I'm not familiar with DX programming, but in mesa all software access goes through the span functions, so it's transparent to the application. That said, if you are hitting a software fallback, you've already lost. Note software fallbacks are handled in the driver itself, not in the application. Applications manage their own buffers.

[iVistux]

Questions

It's already in 2.6.35. I'm sure some bugs will be found but AFAIK we are running EXA, Xv and 3D on 2.6.35 today.

Good, is known when the non-kernel code will be non-dev-ready for R800?
Is known, how fast the new ATI-chips (due this fall/winter) will be supported (and support 3D), since these chips may contain some bunch of changes?

[bridgman]

Non-dev-ready is hard to say; we haven't done much application testing yet. We were seeing serious problems on even the simpler tests until very recently.

That said, any problems that show up should either be HW-specific stuff (mostly done, we think) or things that worked on previous GPUs but got accidentally broken in the process of adding new support (presumably we'll have one or two of those as well).

We are starting to look into the changes for the next generation discrete GPU now, in parallel with looking at the first Fusion parts, but I don't have specifics on how much work will be required for the next generation parts yet. There are definitely some significant changes, but what we don't know yet is whether there we will be able to find shortcuts which let us get drivers running quickly and make the "real" changes later.

[smitty3268]

@bridgman - once the Evergreen code is out, is development for new parts going to focus entirely on gallium? Or will you still be working on the classic drivers?

[bridgman]

For the next generation GPUs I think the approach will be roughly :

- start with the assumption we are only going to support Gallium3D
- build a sufficiently detailed list of EG->next gen changes so we can have a good idea how long adding support will take
- go bug the internal PMs to make sure we know when new parts will launch
- make sure we/community can port Evergreen support to 600g quickly enough to keep a reasonable schedule
- make sure that distros will be able to ship the Gallium3D driver even if it's still a bit rough and they're still shipping classic for earlier HW
- if all of the above seem OK, go with the Gallium3D driver from day 1
- if any of the above seem like a problem, do initial support on the classic Mesa HW driver then jump across to Gallium3D after