A Big Comparison Of The AMD Catalyst, Mesa & Gallium3D Drive

[pingufunkybeat]

I upgrade to latest git once every few days, and I seem to remember that adding the color tiling option in xorg boosted OpenArena framerate by about 60%, and other people here reported similar things.

I might have been related to a number of other optimisations which landed at the same time, I'm not sure. Bridgman should know better than I do, in any case.

I can imagine that it is more important at higher resolutions, due to the additional bandwith needed, so maybe the gain is much smaller at lower resolutions.

EDIT: you're right, I wasn't talking about averages.

[bridgman]

Yeah, I think we are saying the same thing. I'm going from memory so you may actually know better than me here

Either way, all of the improvements add up over time and good things are happening.

[agd5f]

With the current 1D tiling code, we only implement 1D tiling for the back buffer. Ideally we'd 2D tile all buffers and textures. r600g has preliminary support for this but it requires 2.6.37 and some ddx and r600g patches. These patches against the kms-pflip branch of the ddx:

http://people.freedesktop.org/~agd5f/all_2D_tiling.diff

and mesa:

http://people.freedesktop.org/~agd5f/2D_tiling_mesa.diff

add preliminary support.

[agd5f]

arent they rdy for primetime like your pageflipping patches?
id love to enable pageflipping without building from git and patching the source manualls. just an xorg.conf option like color tiling

The drm pageflipping patches are scheduled to go upstream in 2.6.38, so for now you'll need to use development versions. As for the 2D tiling patches, they require 2.6.37 and probably some more stability testing before I commit them. Hopefully after I pull the ddx pflip stuff into master I'll have some time to get them integrated.

[pingufunkybeat]

Woah, exciting things ahead! Thanks.

[RealNC]

The drm pageflipping patches are scheduled to go upstream in 2.6.38, so for now you'll need to use development versions. As for the 2D tiling patches, they require 2.6.37 and probably some more stability testing before I commit them. Hopefully after I pull the ddx pflip stuff into master I'll have some time to get them integrated.

I asked this many, many times, but never got an answer: Can I use the development DRM drivers on the current stable kernel? If so, how?

[agd5f]

I asked this many, many times, but never got an answer: Can I use the development DRM drivers on the current stable kernel? If so, how?

You can either use the drm development tree as is, or merge the changes in drm-next into your current kernel tree (2.6.37) using git.

[RealNC]

I unpacked the 2.6.37 tarball. Not sure what to do next in order to update its DRM drivers :-P

[agd5f]

I unpacked the 2.6.37 tarball. Not sure what to do next in order to update its DRM drivers :-P

You can't use a tarball to do a git merge. You need to clone either Linus' tree (http://git.kernel.org/?p=linux/kerne....git;a=summary) or Dave's (http://git.kernel.org/?p=linux/kerne...ed/drm-2.6.git) and then add the other one as a remote, fetch the branch you want, do the merge and resolve any conflicts. It's probably easiest to just check out Dave's drm-next branch (2.6.37-rc8 based) and use that directly:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
cd drm-2.6
git checkout -b drm-next origin/drm-next

[RealNC]

Wouldn't that leave me with an rc8 kernel instead of .37 final?